20 节点二：架构师如何为企业找到一个正确的目标？
你好，我是郭东白。上节课我们讲了目标确认前的基本动作，那么这节课我们就来看看该怎么为企业找到一个正确的目标。
目标的正确性
上节课我们讲了，架构活动的目标大多是自顶向下给出的，因而架构师最初拿到的目标往往是模糊的，不够具体。那么在目标确认环节，我们就需要把这个模糊的目标变成一个正确的、满足SMART原则的目标。
举个例子。假设你在一家连锁的生鲜线上超市工作，主要服务于三四线城市的中等收入家庭。愿景则是在明年让每个三四线城市的中等收入家庭，在任何时候都能吃到新鲜水果。
但是公司现在面临着供应链的挑战：供应链似乎永远没法满足市场的需求，水果不是太贵就是质量太差。所以你收到了一个目标：在一个季度内，通过产品技术去解决水果供应链的问题。
这是一个比较模糊的目标，需要一步一步去细化。而细化的过程，你也会对自己将要解决的问题的本质和难度，形成一个比较清晰的认知。
首先，通过分析调研发现，水果在刚刚成熟时数量稀少，价格高，采购溯源难。在丰收的时候则是供应链能力不足，导致成本高，浪费严重。在下市的时候，水果质量就变得参差不齐。
紧接着，你又发现很多种水果在刚刚成熟时，价格不是你们公司的目标用户所能承受的。而水果过季的时候，则要关注质量标准化的问题。
但公司目前的体量太小，既没有能力靠供应链的强管控能力来解决商品质量问题，也没有足够的话语权把质量控制问题全部压给果农。与此同时，模型预测技术也不够成熟，因而不能完全靠技术来解决这个问题。所以最终只能把架构活动的第一期目标，锁定在解决处于丰收季节的水果供应链的优化上。
当然，这么做，不仅是因为价格和标准化问题在现阶段难以解决，更关键的是需要解决丰收季节的供应链的问题。供应链的问题一旦解决了，就可以帮助到更多的用户。而且，你认为通过第一期的尝试，增长后的业务体量可能会让价格和标准化问题变得更容易解决。
接着，通过讨论和调查发现，供应链的能力不足主要发生在首公里和末公里，而浪费主要发生在末公里。你还发现，无论是首公里还是末公里，公司的数字化能力都明显不足。
经过几轮讨论，你发现首公里和末公里的数字化存在很大的机会点。如果果农能使用App来通知你们上门收购，公司就有机会做收购环节的预约和路线规划，从而大幅提升收购效率，降低采购成本。如果再利用门店的消费记录来做补品预测，公司就又能做到及时的采销联动了。这样一来，就可以减少滞销库存浪费，提升供应链效率与时效。
在与相关同学讨论并进行BI的初步测算后，你最终制定了如下这个目标：
在三个月内，通过采销端数字闭环和供应链采销联动，将供应链时效缩短30%，总采购成本降低10%。同时，在维持当前缺货率的情况下，把店内商品平均周转时长减少到之前的75％。
可以看到，在定义目标的过程中，你做了充足的功课，放弃了其他两个不相关和不可达的目标。而最终选择的目标，除了能降低成本外，还能缩短供应链时效和周转时长。这会让水果更新鲜，从而带来更好的客户体验。
所以这个目标是符合公司愿景的，是长期正确的。具体的目标值也是你与技术团队讨论之后制定的，是合理且可达的。综合来看，这就是一个正确的目标。
这个案例为我们实际演绎了一个好的目标制定的方法：一个正确、合理且可达的目标，是靠多个职能之间反复讨论和反复演算得到的。这是一个发现的过程，而不是一个拍脑袋决策的过程。
这种目标不同于自顶向下强行输出的目标。后者是出于战略而设置的目标，往往有正确性的保障，但不一定合理或者可达。
实际上，目标制定过程的背后也有一个非常深刻的理念：目标的制定要靠科学决策。目标必须基于客观事实、自然规律和现实环境的约束。像“人有多大胆，地有多大产”“因为相信，所以看见”这些口号都只是用来鼓舞人心的，并不能用来指导目标的制定。作为架构师，你必须要为企业注入理智，用严密逻辑和真实数字来论证目标，而不是简单地相信。这也是架构师的核心价值所在。
当然现实情况远远没有这么简单，很多互联网公司的前景并不明朗。多数时候，架构活动的目标很难被量化预估。这都没有关系，因为你为架构目标注入科学决策和数据分析这个动作，是极具价值的。
那么怎么才能最大化这个价值呢？这就回到第18讲的话题了。如果你能在自己的架构活动里建设一个尊重事实、尊重数据、尊重规则的决策环境，那么项目参与者就会愿意表达自己的观点，分享他们的数据证据，指出你的疏漏或错误。
这样一来，你就不需要完全靠自己的力量来提升目标的正确性，而可以依靠全团队的力量。事实上，决策环境的作用会贯穿整个架构活动，直至复盘结束。
目标的合理性和可达性
在确认目标的过程中，我们还要检查目标的合理性和可达性。相对来说，这个验证过程是一个快速的、基于经验和思想实验的判断，而不是一个耗时巨大的工程。
确认目标时只需要和执行者确认一件事：在极限压力下，项目交付时间和KPI目标是可以被实现的，重大风险是可控的。
这个过程需要你确保：
- 执行团队不能为了减少考核和交付压力而故意压低目标。
- 如果目标不合理，你需要代表执行团队向上反馈，把目标调整到一个合理范围内。
- 重大风险需要有足够的预案，或者赞助者可以接受风险带来的后果，也就是赞助方支持冒险。冒险往往是互联网企业的常用选项，所以准备预案这种方法，仅仅在少数已经处于垄断地位的互联网公司中会使用，其他企业很少会把宝贵的人力资源耗费在准备预案上。关于风险的应对办法，我们下节课会专门讨论，这里就不展开了。
我先举个关于合理性的负面例子。我曾经经历过一个项目，项目的执行者在巨大的管理压力下，接受了一个完全不合理的目标。本来预估３个月就可以完成的项目，被强行压缩成了１个月。结果团队被迫选择了一个完全错误的架构方案。
但是一个月的期限很快就到了，上线验收的结果也完全失败。折腾了两个星期怎么都修复不了，最后只好向各方请求延期。很不幸的是，决策者决定用之前团队建议的日程去上线。然而三个月已经用去了一个半月，加上之前选择的架构方案完全错误。那么给三个月的时间，其实也是不够用的。
没想到决策者还是强压。结果上线后再次失败，失败后又再次重启，代码和数据模型搞得一团糟。这个时候，团队已经离职一小半人了。就这样反反复复，人才不断流失，项目越做越难做，最后花了14个月的时间终于上线。可是上线之后，团队经理、几名主管和所有一线员工，竟然一个都没有留下来，全部离职或转岗。
在这个过程中，执行者、决策者、赞助者和架构师之间几乎完全丧失了信任。而最初的导火索，就是决策者执意推行一个完全不合理的交付日期。
你肯定也会面临目标不正确、不合理或者不可达，但决策者却一味坚持的情况。绝大多数互联网公司在这方面的原则，都是“可以有不同观点，但必须坚决执行”。这个时候，我们作为架构师一定要充分沟通各个干系方。反正横竖都是一死，还不如顶天立地。
但也有个别架构师会在发现问题后故意隐瞒不沟通，强行推进架构活动，这就是在绑架企业的决策者、架构活动的执行者和赞助者了，是行霸道的做法。
目标可达性的关键在于妥善处理重大风险，关于这一点，我们下节课会详细讲解。
完成目标确认
完成目标确认后，有两个可能的结果，一个是输出符合SMART原则的正确目标（请参看第19讲）； 另一个是说服相关方放弃不正确的目标，重新设立一个正确、合理和可达的目标。
我想特别强调一下，后者其实也是一个好的选项。虽然放弃一个诱人的目标很可惜，但更可惜的是接受一个错误的目标。在互联网时代，时间和机会是最宝贵的资源。而且，能做好后者更难、也更有价值。
很多处在职业初期的架构师会不惜一切代价去承接一个大的项目，误以为项目越大，功劳和成长就越大。从我的经验看，当否定上级一个重大的错误决策后，才能真正成长为一个有主见的架构师。在此之前，都只是一个被动的、缺乏独立思考的任务完成者。
我就有类似的经历。我曾在几年里持续反对过一个项目，三次抗住了来自核心高管的压力。在四年三批人耗费了上千研发人年之后，事实证明我的判断是对的。所以说，不论过程多么痛苦，当时间最终证明自己决策的正确性时，就已经收获了成长。
小结
我们这节课讲了目标确认的过程。这个节点的重要价值在于帮助企业选择做正确的事情，同时也帮助企业放弃不正确的事情。其中行王道的做法就是站在决策者的角色上思考问题，为公司做正确的决策，让执行者做有挑战和有成就感的项目，也让赞助者的投资最终变成有价值的回报。
乔布斯曾经说过：“If you define the problem correctly, you almost have the solution（要是能把问题正确定义的话，你几乎就已经有了解决方案）。”作为一个架构师，我们往往没有定义目标的权力，但却可以确定一个目标是否正确、合理或者可达。如果能从目标里发现一个伟大的、值得长期探索的问题，可以说是一个架构师最大的才华了。
这个过程，你不是简单地相信，而是用理智对细节进行探索，用事实和数据把所有相关方引导到正确决策上去。此外，也要试图从目标中发现技术创新的机会，为执行者带来职业成长。做到了这点，就可以撬动更多的长期主义者加入到你的架构活动中来了。
思考题
三个思考题，任选一个：
- 有的目标虽然有挑战，但最后也达成了。你有类似的经历吗？这个目标制定的成功之处在哪里？
- 你有没有陷入到一个错误目标的泥潭的经历呢？结果呢？
- 在你经历的架构活动中，你得到的最有价值的长期回报是什么？为什么呢？
如果这节课对你有帮助，欢迎你把课程转发给你的同事或朋友。顺便打个小广告，我刚开了个人抖音号，我会定期发表一些比较新、但是不一定那么成熟的观点。欢迎在抖音上搜索“郭东白”并关注，也欢迎你的批评指正。我们下节课再见！
- Geek_sa2mt4 👍（6） 💬（1）
接自己的上一条评论，我一直觉得我司的CEO有种陈友谅的气质。 陈友谅算是当时朱元璋的一个劲敌，水军很厉害。他的水军战船的构造很有特点，一般的水军战船甲板上面作战，下面一帮人划桨，下面划桨的人是能听见甲板声音的，如果下面划船的人听见上面要战败了，就想着逃跑了，容易军心不稳；而陈友谅的不一样，他把甲板加厚了，下面划船的人听不见上面的声音，只能根据上面的只会拼命划船，就算上面已经战败了，下面也不知道，还在拼命划，直到被干掉。 这种独断加上强大的执行力会带来很强的战斗力，但我觉得这样的战斗力只是一时的，这是霸道，霸道能够成就霸业取决于霸主，霸主没了霸业就没了，而王道则有多助加持，王终而道犹在，传承得更久些。
2022-09-25 - spark 👍（6） 💬（1）
郭老师，take away~~~ 理性批判(不接受任何自己不清楚的真理)、化繁为简，化整为零(拆解问题)、先易后难(有次序，逐步解决)、归纳综合(证伪性，可重复性，可验证性)，这是笛卡尔思考的四个步骤。大道至简，只有像笛卡尔一样的少数人才能做到？~~~
2022-03-09 - 罗均 👍（5） 💬（2）
感谢老师的课程。经历过的成功项目，基本上就是: 1. 符合决策者的战略期望。 2. 资源需求未超出赞助者的能力。 3. 充分激发执行者热情——技术方案清晰，新颖且宜执行，大部分的坑已经被趟平了。 总而言之，核心是信任。
2022-03-11 - kq yang 👍（5） 💬（1）
这让我想起经典的软件项目是不是应该有截止日期的争议。三人以上皆运动。关键还得让正确的人上位并且被充分授权。那个要正确做事的人永远要记得需要4种角色。1 出主意的人，让不可能在构造路径后变成可能。2 负责拉人拉资源，把一个东西从可能变成现实的人。3 紧密实施，快速有力推动进度的人。4 那个总是能指出所有的想法多么愚蠢和多么重要的，能够喊cut, 说必须和绝不的人。
2022-03-08 - Geek_sa2mt4 👍（1） 💬（1）
思考题2太有感触了，例子就是我在前一讲中分析的CEO拍脑袋的直播电商项目。 后来我了解到，不止在公司的一条产线这么干过，而且都是以失败告终。 我对此的看法是，既然直播平台已成规模，肯定有详细的用户画像，根据这些画像作为探索的依据是否更合理些？如果推断出来无法盈利，我觉得可以暂时不做，继续等待机会，否则冒一次不会成功的险就是在浪费资源，特别在现在的疫情之下，不浪费资源就是收益。
2022-09-25 - evan 👍（0） 💬（1）
“可以有不同观点，但必须坚决执行” 这个我深有体会，之前从事的一家公司就是因为一个重点项目存在明显的挤兑风险，然后利益方着急于上线，在18年的时候因为政策的原因，大量用户开始退出，诱发挤兑风险，因为体量巨大，然后公司倒闭了...
2022-03-28 - 陈桐 👍（0） 💬（1）
不合理目标，会出现人相竞食，互相推卸责任。我提出几个问题来思考 1.作者只说这样做不对，但是没说不这样做后果是什么？ 2.为什么目标制定者，倾向于提出不合理目标？ 3.数据论证，科学决策的目标，如果缺乏想象和创新怎么办？ 4.为了适应互联网，公司倾向于选择是特种部队式练兵，还是普通正规流程部队？ 5.骨子里的决定文化，选择入职一家公司，骨子里已经改变不了，如何避免入坑？
2022-03-22 - 术子米德 👍（3） 💬（0）
🤔☕️🤔☕️🤔 * 📖：架构师为企业找到一个正确的目标？ * 🤔：第一眼看上去，还以为题目错了，架构师不是企业的打工仔嘛，企业要啥，架构师干出来就是，难道还要操企业目标的心嘛？其实，这里所谓的第一眼，不是看到标题当下的第一眼，而是半年前、大半年前，我都是这样的认知。最近半年来，架构认知有在改变。如果架构能把当下的钱赚到，算合格，赚到同时利润高点，算良好；如果架构能把未来的钱赚到，算优秀，未来更多利润赚进来，还不欠下技术债务，那就是无印良品。这么说来，企业的目标，大概率是当下赚到的钱，如何提高利润，如何赚到未来更多钱，算是架构师为企业找出的目标的动力源，算是第二眼看标题触发的思考。 * 📖：目标，正确、合理且可达，要多个职能之间反复讨论和演算，才得到这个被发现的目标 * 🤔：目标，领导说一不二嘛，以前愣是这么认为。自己做项目的经验，告诉自己，所谓目标在远处，更多是个方向，要在途中不停校准。这是目标的校准认知。如果大家都持有这样校准型的目标认知，一起推进项目时，会很有默契不停努力让目标清晰起来。否则的话，老是耳边听到抱怨，目标都不清晰，还干个啥嘞。如果是经验欠缺的新手，我会分享这种目标认知给他。如果是所谓的资深或经验丰富人士，我会自动屏蔽这样的老老新手，他们典型缺乏真正的经验，更缺乏反思和总结。
2022-03-18 - 小昭 👍（0） 💬（0）
在老师的文章里看到了自己正在经历的项目，可惜我只是个人微言轻的小测试，也表达过自己的观点和我认为不合理的地方，但都无疾而终。
2023-05-08 - 星晴 👍（0） 💬（0）
之前有经历过，多人团队开发项目迁移的项目。难点在于，文档缺失、核心人员基本流失。在经过几轮回溯和尝试，才勉强将数据迁移。最终线上正式部署，还是遇见部署失败问题。最终经过，反复推导解决细节问题，才能完成迁移。最开始的愿景，就是压缩成本、数据迁移，可能由于核心人员的变动，导致迁移流程复杂化。最终能成功迁移，应该也源于最初目标，让当前使用业务人员能正常运行。郭老师有个问题想咨询一下，就是在一个架构活动中，一个项目周期会有个长期远大的愿景。但是由于时间、交付、公司生存成本，如何取舍架构活动的整体生命周期呢？由于未知的不确定性，长期架构投入经历肯定更大，短期架构又不能适应长期需求的发展。这种改如何取舍 呢。您怎么看待过度设计这个问题
2023-03-09 - 黄秀萍 👍（0） 💬（0）
感觉所有实例都是电商领域，换了领域是否可行呢？
2023-01-17 - 海鱼美味 👍（0） 💬（0）
1.考虑到日志系统的通用性，后期的维护性，扩展性。上线前确认技术方案可行性，做性能压力测试。最终可以成功发布。
2022-08-30 - 术子米德 👍（0） 💬（0）
🤔☕️🤔☕️🤔 * 🤔：架构活动中，把“What-Why-How”的模型穿通，正着走，所谓Solution-Focused，倒着走，所谓Problem-Focused，来回走几遍，总算理解到其中的正确，这是让我自己受益最大的一个模型和思考方法。所谓How，知道怎么干，干出来就算成功。所谓What，知道是什么，能够从其它对比中区别开来就算成功。所谓Why，知道是为啥，能够从多个为啥中选择出最合适的为啥就算成功。
2022-03-18 - 欧阳绍聪 👍（0） 💬（0）
行业领域的专精深入，了解更多了
2022-03-09