最近要多带一个架构团队做一个新版本,我写一些基本逻辑来给团队建第一层策略建模,以便我们后面的讨论有基础,由于这种问题是普适的,也不会涉及什么具体的保密问题,所以我公开来写。
架构是一个充满了自由度的工作,是一个最不适合用过去的成功指导下一波策略设计的领域,无论你过去的领域和这个领域有多相像,你过去的成功经验都只能拿来参考,不适合用来拷贝。
因为即使是完全相同的领域,时间已经不同了,行业生态,技术发展已经不同了,你面对的人不同了,业务的瓶颈已经不同了,生态的各个利益体的投资已经不同了,成熟的领域人员可能减少,当初的绩优股可能已经失败,你面对的是一个新的领域,我们做架构,永远不能被过去的“定义”,左右了我们的判断。所以,做新的架构设计,你可以参考过去的成功pattern,但你的分析,必须建立在现在的条件上,不能离开对现在问题的调查,直接打算使用过去的模式。
这是我对我们进行产品战略设计的第一个建议。
架构设计是一个非常微妙的设计领域,它是完全建立在形而上的逻辑上的,它是抽象的,非具象的。但这种抽象必须要以可以实施为底线,否则就沦为纸上谈兵了。所谓高以下为基,贵以贱为本。所以,我们不要出现“架构上我们应该如何如何,但我们现在人力不足啊”这样的思维角度,这是废话,架构就是建立在准备实施这个角度上的,你不能把架构设计和实施隔离,说一堆“我们要如何如何,只是某某条件不成熟。”这样的鬼话,如果某某条件不成熟,你就不该做出这个设计来浪费我们的时间。
架构设计是实施团队的一部分,没有独立于实施的架构设计。架构设计90%的工作是辅助实施团队实施架构战略和挑战架构战略,不是实施之外的独立设计。把人分离出来是为了保证投入,不是为了让这个团队成为实施团队的竞争者。
但反过来说,你不能说我们现在只有多少多少人,我们就做一个基于现在有多少人的方案,因为事情是变化的,在架构设计初期,给你很多的人,你也用不了,人力多了是个累赘,看在财报上每个月花出去的钱就让人害怕,但如果你的设计只是现在有多少人,那后面开始展开了,你根本就发展不了。没有准备,未来有可能给你补人你也接收不了。如果人力不是这样从小到多的一个变化过程,我们也不需要架构设计,架构设计必须可以响应这种人力,资源,市场等各方面的变化。
所以,我们从一开始就做好了做这种多步的策略的打算,考虑整体目标的时候,要用整个市场域的机会作为我们发展的上限,在实施的时候,要考虑好怎么一步步增强投资者和市场的信心,从而可以有序扩大整个业务,不要用“我的架构没有错,错的是市场,错的是人力资源没给够人,错的是……”来给自己做理由。架构设计包括对这些“别人的错”的预判。架构设计和实施是和整个产品的所有其他力量(开发,销售,维护,财务,法务等等)融合在一起的,没有独立于这些开发力量的架构设计。
这是第二个建议。
但对于这个建议,我有个直接的工作技巧可以分享。当我们确切落笔写一个架构设计的时候,要考虑:以客户为目标,以工程为准绳。
什么意思呢?就是说,你在架构设计的第一个部分,要明确说你打算卖一个什么样的东西到市场上去,你的客户打算买你的东西,这个决定的控制要素是什么?有这样一个标准在最前面,我们中间的所有变化,遇到的障碍,我们都知道往哪里绕。也知道我们绕完了,应该继续向什么方向走。
而在你的架构设计的最后一段,你要把你的所有设计落实为“版本”和“项目”。所有的人力管理,都是以项目为基础的,因为项目有确切的目标和人力资源投入,而不是“小李你去帮帮他们”这种尽力而为的东西,架构策略一旦展开,所有人都会面对无限的要求,没有确切的资源分割,凡是长远的东西都会被忽略和放弃。所以,要把架构策略得以实施的希望建立在人力资源管理上,不要建立在“期望”,“正义”,“道德”,“道理”这些依赖上。所谓子非不辨也,老子忙起来谁都不认也。
当然,我这里说的项目,是广义的项目,不一定是你流程中说的那个项目。
而项目,要输出确切的版本,你有硬件,有软件,有插件,这些都是有版本的,不要说什么做一个my-wonderful-app,里面支持这特性,那特性的。
你的软件上了市场,遇到一堆的客户,这些客户的要求都会不一样,你是用一个版本还是用多个版本去响应他们?产品是会有Bug的,是要有新特性开发的,修复Bug和增加新特性是会引入新的Bug的,所以,客户可能可以接纳升级你修复他的Bug的版本,可不一定肯接纳你发布的修复其他人问题的版本的。
这样,你在市场上就会有很多版本,这是天然的,版本一多,开发,测试,维护,管理的成本会大幅上升,这是一个重要的工程控制要素。你用my-wonderful-app这一个概念来考虑你的设计,你实施的时候就会怎么搞怎么不正常,因为你以为你开发的是my-wonderful-app,其实你开发的是my-wonderful-app-v1、my-wonderful_app-v2、my-wonderful-app-v2.1、my-wounderful-app-v2.1-without-tso-llvm_v7_specific-edition……你对人力和项目的预判都是错误的,当然执行不下去了。
所以,很多人其实不明白“开源交付”是个什么东西,开源交付其实是一种减少版本的方法,一个源代码树是可以编译出很多二进制版本的,我给你源代码,编译产生多个版本的的维护成本就是你的了,很多人以为交付源代码是对用户友好,是为行业做贡献——那得看客户是想当你的竞争对手,还是想解决他的问题了。(但即使你用“源代码交付”,如果是商业交付,你的测试还是需要落实到一组二进制版本上的,而且你必须很清楚,这些二进制版本都是会升级的,死版本支持的生态是死的生态)
但无论如何,架构设计一个基本的要求,高以下为基,不要离开你的工程成本想得天花乱坠,只要涉及工程,什么美好想法都得给我从天上掉下来。
第三个建议:调查和设计也是要结合起来的。架构设计初期,我们有无数的“未知”:竞争对手的战略是什么?客户的期望是什么?研究机构有什么新的突破?市场份额的预测是什么?国家政策的走向是什么?……
如果你要调查完这些东西才做决定,你就永远都不用做了。所以,进行架构设计,要勇敢进行“猜”,“预判”,哪怕错了,你也要“猜”,因为这是架构设计工作的基础。你的决策要同时决策:使用猜这个结论和再调查一下,哪个投资收益比更低?然后就要去实施。我在这个专栏中经常强调“守弱”,其本质就是这个:架构本身就是一种猜,我们在猜的基础上执行,如果你非要维护面子,在执行的时候收到当时猜错了的反馈,你死要面子不肯调整,那这个架构执行就失败了。
所以,做架构不能要面子,你眼中只能有产品的最后成功,到成功的时候,你坐在那里,旁边的人说什么,你都可以冷冷看着他,由他讲他的道理,你根本不用在乎。
这样就要提到第四个建议了:你不要指望实施团队会很喜欢你,你做的所有事情,都是为了未来让他们“绕路”走,你的结论他们不会喜欢的。你可以用你所有的个人魅力去尽量soften这种冲突,你可以下去和他们一起分担开发调试的压力,让他们没有那么恨你,但你要知道,如果实施团队很舒服,你的架构设计肯定变成在旁边说胡话了,根本没有设计效果。
所以,你决定来做架构了,就不要期望你有多nice。这是这个工作的特性,不能调和的。不要为了实施团队的一般抱怨就去改变你的设计去迎合,否则产品失败的时候,就没有人跟你抱怨了。吾之所以有大患者,为吾有身,及吾无身,何患之有?你应该多听实施团队的抱怨,但你要分清楚哪些是真正在反馈问题,哪些只是你战略实施的成本。
最后一个建议:架构团队来自不同的领域,不要用“领域代表”看待自己。不要说我只是做芯片设计,我只是做安全的,我只是做内核的,我只是做数据库的。架构团队存在的目的,就是为了设计那些多个模块互相甩锅的Gap,然后所有模块和协同起来,达到最优的效率。你尽然进来架构组了,你就不是某个模块的“甩锅代表”,你就是整个产品。
大部分投资者都是不懂技术的,就算他们来自技术背景,他们对你实施的这个技术也是外行,因为细节只是我们知道,否则他就不用你来做了,他自己做就好了。这些人决策的方式就是“多方确认”。
如果架构组自己都达不成共识,各说各话,那怎么说服投资人(其实包括准备用你的客户),所以,架构组每个人都应该对整个架构策略都很熟悉。我不要求做芯片的人就会写程序,但我需要做芯片的人知道软件部分的构架要求,在解决方案中所处的地位。你不要告诉我你只懂UEFI,不懂Kernel是怎么做的,我需要你知道ACPI表那些信息是给Kernel的哪个模块看的,你不是在做实施,等着别人给要求,你是那个负责知道少给一张EINJ表,Kernel会不会起不来的人。
推广起来说,作为一个产品的架构团队,你也不能只管“我的产品如何如何”,你必须从整个产业生态上开始设计。狼吃羊,羊吃草,你不能说你是狼,不管羊的死活。没有羊了,狼也死了。做架构设计的人,必须知道狼可以吃多少羊,吃到什么时候就要开始收手了。
所以,对于一个产品的架构师,必须知道整个生态链是怎么运作的,要为了整个生态的平衡,不怕把自己部分自己的业务让给其他产品,其他企业,也不怕自己背上别人不肯实施的业务,这样你才会有掌控生态的力量。
大概就是这样一些吧,再往下,就是具体业务怎么做的问题的。但当我们碰到困难的时候,不妨回头来看看我们的总体思路,也许觉得无路走的时候又发现有路了,觉得很顺利的时候,说不定就是危机的开始了。
推荐阅读:
《》
《》
推荐站内搜索:最好用的开发软件、免费开源系统、渗透测试工具云盘下载、最新渗透测试资料、最新黑客工具下载……
还没有评论,来说两句吧...