03｜法则一：如何找到唯一且正确的架构目标？

感谢东白老师的精彩分享，听完这一章，我想说的是：从最初设定且完成论证的架构目标，它是一个项目和平台的输入条件之一，而在整个项目或者平台构建发展过程中，它一直在不断地完善与进化，它又同时是一个输出。所以，架构师在整个架构活动中，需要不断提取成果（哪怕是失败成果）来完善架构目标，得以完善后的架构目标，再重新成为整个项目的输入，这样周而复始循环下去，直到项目完成。 可能有人会提到，定好的架构，为什么要不断优化完善呢？因为外界一切环境都在变，当时当刻制定的架构目标，是以当时背景作为起点，即使有一定的技术前瞻性，但是市场、企业，都在不断地再变化来更好的满足客户的需要，那么就回归到东白老师提到的，架构的目标要和企业战略目标保持一致，且能够创造价值。既然要达成这样一个目的，那么它必然不是一成不变的，而是完善中。 最后，我认为架构目标以及架构方案，是持续完善进化的，它既是一个明确的状态，也同样意味着它代表一个过程。

感觉老师教的是“做人”，只是拿“架构”来解释说明一下，哈哈，人生高度确实让人折服。通过传授的内容可以看出，老师是一个正直的、有职业操守的、有道德的人！ 思考题一： 我在16年参与了公司的比较大的项目，帮助客户从1 到 1 的产品重构，项目本身使用asp.net做的，不知道出于什么原因，要迁移到WNMP架构。当时我算做开发小组比较资深的程序吧，让我做这个项目的技术负责人，以我当时的职位视野，是完全看不到这个项目的出发点、有没有给企业带来“创造生存优势”的这类问题，我只是能判断在周期为3个月（2个月的产品调研、1个月的开发），并且带领一个JAVA团队完成这个项目的计划是完全不赞同的。首先，项目本身完整的需求是没有的，产品文档还在持续的变更；其次，技术团队在WNMP架构中，只有2个人曾经学过一点PHP，其他人都没用过（10个人的技术团队）；3. 由于是1 到 1的项目重构，所以哪些是原来保留的功能，哪些是优化新增的功能没有明确的产品文档；4. 产品对接人身在外地，不能很好的沟通。我把这些问题整理好，找到技术经理（我当时的领导），想直接终止这个项目，或者抽身而退，跟领导解释了很长时间，最终的到的答复是，“你要有自信，没问题的！！我也在这个项目里，到时候有困难我帮你出面解决！”（当时我都有掀桌子的冲动）。。没办法，最后这个活儿还是接了下来，当时我的状态至今记忆犹新，开发小组基本上是晚上12点左右下班，他们下班后，我代码review，弄到1点左后，然后下班回到家，大概凌晨2点，凌晨4点就行了，翻来覆去睡不着，于是起来收拾收拾上班，大概凌晨5点半又回到了工位，整理今天要完成的功能模块。最终项目在计划的时间内完成。运行了一个星期，我基本上是住在工位上的，就早上8点左右去某个会议室趴会。因为客户返回的bug很多，很多销售不理解新系统的功能，于是项目就被下线了，换回了原来的老的产品。。。在过了大概半年，大老板业务重点转型，整个项目组都被裁了。。。这段经历是我最最最不想回忆起来的。。又是选择很无奈，甚至是没的选择！但是只要责任在，就必须拼出一条路来！！哪怕粉身碎骨～我虽然不能保证结果，我却能保证过程是向着结果努力的前进着！！结果就交给大佬们吧～不知道我的选择或者做法是否正确，也不知道我今后是否对这段经历有新的认知。总之往各位好运，珍惜机会，做好自己！

1.感觉这里用达尔文进化论不大合适。达尔文进化轮是适者生存，讲的是被动的适应了趋势，而不是主动的看对了趋势。解读达尔文进化轮下适者的基因，是为了理解当下的趋势，而不是获得一个成功的方法论。千团没人猜到美团最后胜出，聚划算也不过是一个做IM系统的临时做的小玩意。但凡基业长青没有不经历波折的，也就是目标都可能会错，关键是及时适应趋势。 2.感觉东白老师这里有块内容，提到了但没点开。求之于势，不责于人。布置/借用趋势去驱动人，而不是责备人不胜任。文中提到要站在他人的视角去理解他的出发点的正确部分是什么，并加以引导。没点开的是这背后其实是在借助趋势帮助个人成长。让他去负责调研全面替代的成本，这是布局。基于这个局他可以感知到你的视角，这是成长。基于成长利驱动他用心完成战略目标，这是最终结果。 3.评论有看到反对人血馒头的说法，我觉得这个观点也是对的。不是每个领导都会从人出发，将下属个人发展的目标和公司战略目标做出正确的关联。当两个目标不匹配时，下属出于自身利益优先追求自己的目标是人之常情，错不在下属而在制度和领导（为什么？求之于势，是自己没把局布置好）。而故意做出错误的架构决策就能说是人血馒头吗？感觉也不合适，当皇帝讲究正大光明，但夺嫡成功之前为了达成特定目标，难免也得用些阴谋诡计。

🤔☕️🤔☕️🤔 * 我参与过的架构，争论技术优势和可行性，就已经把脾气都摩擦出来火花，代入几个案例，就更加是火上浇油，你能举出的例子，别人可以举出更多例子。然后就会在现有架构里，修补一下继续过日子。印象中，从来没有始终围绕过为企业创造生存优势。现在想来，能够知道和能够做到之间，差距不仅在于认知，更在于认知的匹配，以及匹配认知后的坚定执行。 * 这次课程后，给自己播下一个种子，后面参与的架构活动，都不停追问自己：战略在哪里，目标是什么，架构是否在创造生存优势。还有一个困惑，那就是这个种子，如何不会在后面的架构活动时被遗忘，怎么能够真发芽🌱，这也是值得提前思考的问题。

1.请领导做取舍； 2.帮领导做取舍； 3.夺领导的取舍； 4.等领导做取舍。 第3种方法太猛了，注意安全。

东白老师，想请教两个问题 1. 就技术项目而言，技术架构的目标和项目目标是一样的吗，有没有区别呢？比如说统一网关作为一个项目。 2. 如果自己在技术决策的时候，目前掌握的信息或者技术细节不确定是否能做出最优的决策。是应该把所有东西都搞清楚再决策，以免返工。还是应该尽量决策，后续再做架构调整或者升级呢？ 谢谢。

第二个问题： 几年前在2B行业，做企业信息管理工具，这个项目最终失败了。原因我觉得最重要的一点是公司短期定的目标过于宏伟，属于“既要”、“又要”、“还要”的类型，远远超出了公司现有资源和能力所能过承载的，有很多的功能都是浅尝辄止，甚至都没来得及上线，严重打击团队信心很多不错的人选择离开。还有一点在于大环境下，企业微信和钉钉等工具的冲击，在当时的资源和能力下无论是产品体验、运营推广、客户维护都相距甚远。如果现在站到当时的场景下决策，应该不会定那么多不切实际的目标，可能会在某个领域深耕来建立竞争优势，毕竟整个2B盘子足够大，拿下一小块也能活的不错吧

郭老师好，其实不仅是美国的三甲医院，中国三甲医院系统同样十分复杂，也要100~200个系统去支持医院的日常运行了，还不包括很多科研类的小系统。您说的问题普遍存在，系统的使用方和采购决策方不一致，经常导致错误决策，即使能局部最优，放到全局有时也是个灾难。 提到失败的项目，我这里也有一个反面例子。曾经有一个软件研发项目，由CTO和研发部门负责推动，大家对项目期望很高，投入了很多的人力财力，经过近两年的研发，试点项目成功上线了。 项目上线之后，国家恰巧也出台了相关政策，公司希望快速推广。此时才发现，根本没人准备好，销售同学没有高质量销售资源、市场和售前同学无法出产品方案、项目经理入场后无法和用户在同一频道沟通、产品安装部署复杂实施同学压力山大、研发部门被要求补齐各方短板，最后拖来拖去错过了整个产品的时间窗口，大家相互指责，部门间对立严重。更可悲的是，公司的现金流产品被边缘化了两年多，后果可想而知。 事后诸葛亮，反思一下。虽然当时大方向是对的，但每个人目标从来没有真正统一过，公司在各维度上距离想做的事情太远。在产品研发期间，不仔细考虑产品目标，不提前准备积累，不提前培养人才，不提前考虑后面怎么办，失败是必然的。

问题一 我在14年的时候做过一款硬件产品，产品形态为Android机顶盒，当时高层希望将Android机顶盒做出PC体验，后面在设计整个框架的时候，都是按照这个思路来进行的。那个时候刚毕业，对于系统的理解不深入，最后按照这样的架构设计做出来的产品失败了。这个对我自己的影响很大，我认为技术的出发点一定是产品需求的正确性，所以未来的开发过程中我一定会问清楚这个产品给用户带来的价值。 使用今天的原则，在上面的案例里面是非常适用的。在做任何产品的时候，需要去考虑产品带给用户的价值，带给企业的价值，哪怕老板要求不要管，也需要我们自己独立思考。 独立思考的勇气，这点难得可贵，我们不能因为别人而改变自己的思考，或者是不去思考。或话，在人生的长河中我会遇到挫折，遇到不公，但所有的这些不能改变我独立思考的勇气，不能改变我对理想的追求。

分享一下我的一个架构复杂度上升的经历。在传统金融行业做风险管理，曾主导过公司内部的大数据风控决策平台建设，采取外采产品二次开发的模式，一开始项目不被看好只得到一个业务条线的试运行。结果刚好赶上行业内大数据的风口被全公司推广，高管要求覆盖所有条线，需求复杂度上升几倍，性能压力很大。不得不又论证系统架构，是在现有产品传统架构上完善和扩容还是采取厂商新的分布式架构的产品，当时论证了很久。后来考虑到未来扩展成为风控中台以及分布式架构的优势，引入了新的分布式架构产品。新老平台并行使用应对不同条线需求，后期又涉及到老平台是否需要保留的问题，运行了几年决定把老平台下架，数据迁移和改造量巨大。现在回想，一开始也想不到需求复杂度会上升那么多以及分布式架构的流行，导致长时间内有多套引擎在并行。虽然最终实现了业务目标，但是也增加了成本和管理复杂度，如果换成东白老师会怎么选？