20｜节点二：架构师如何为企业找到一个正确的目标？

郭老师，take away~~~ 理性批判(不接受任何自己不清楚的真理)、化繁为简，化整为零(拆解问题)、先易后难(有次序，逐步解决)、归纳综合(证伪性，可重复性，可验证性)，这是笛卡尔思考的四个步骤。大道至简，只有像笛卡尔一样的少数人才能做到？~~~

感谢老师的课程。经历过的成功项目，基本上就是: 1. 符合决策者的战略期望。 2. 资源需求未超出赞助者的能力。 3. 充分激发执行者热情——技术方案清晰，新颖且宜执行，大部分的坑已经被趟平了。 总而言之，核心是信任。

这让我想起经典的软件项目是不是应该有截止日期的争议。三人以上皆运动。关键还得让正确的人上位并且被充分授权。那个要正确做事的人永远要记得需要4种角色。1 出主意的人，让不可能在构造路径后变成可能。2 负责拉人拉资源，把一个东西从可能变成现实的人。3 紧密实施，快速有力推动进度的人。4 那个总是能指出所有的想法多么愚蠢和多么重要的，能够喊cut, 说必须和绝不的人。

接自己的上一条评论，我一直觉得我司的CEO有种陈友谅的气质。 陈友谅算是当时朱元璋的一个劲敌，水军很厉害。他的水军战船的构造很有特点，一般的水军战船甲板上面作战，下面一帮人划桨，下面划桨的人是能听见甲板声音的，如果下面划船的人听见上面要战败了，就想着逃跑了，容易军心不稳；而陈友谅的不一样，他把甲板加厚了，下面划船的人听不见上面的声音，只能根据上面的只会拼命划船，就算上面已经战败了，下面也不知道，还在拼命划，直到被干掉。 这种独断加上强大的执行力会带来很强的战斗力，但我觉得这样的战斗力只是一时的，这是霸道，霸道能够成就霸业取决于霸主，霸主没了霸业就没了，而王道则有多助加持，王终而道犹在，传承得更久些。

思考题2太有感触了，例子就是我在前一讲中分析的CEO拍脑袋的直播电商项目。 后来我了解到，不止在公司的一条产线这么干过，而且都是以失败告终。 我对此的看法是，既然直播平台已成规模，肯定有详细的用户画像，根据这些画像作为探索的依据是否更合理些？如果推断出来无法盈利，我觉得可以暂时不做，继续等待机会，否则冒一次不会成功的险就是在浪费资源，特别在现在的疫情之下，不浪费资源就是收益。

“可以有不同观点，但必须坚决执行” 这个我深有体会，之前从事的一家公司就是因为一个重点项目存在明显的挤兑风险，然后利益方着急于上线，在18年的时候因为政策的原因，大量用户开始退出，诱发挤兑风险，因为体量巨大，然后公司倒闭了...

不合理目标，会出现人相竞食，互相推卸责任。我提出几个问题来思考 1.作者只说这样做不对，但是没说不这样做后果是什么？ 2.为什么目标制定者，倾向于提出不合理目标？ 3.数据论证，科学决策的目标，如果缺乏想象和创新怎么办？ 4.为了适应互联网，公司倾向于选择是特种部队式练兵，还是普通正规流程部队？ 5.骨子里的决定文化，选择入职一家公司，骨子里已经改变不了，如何避免入坑？

🤔☕️🤔☕️🤔 * 📖：架构师为企业找到一个正确的目标？ * 🤔：第一眼看上去，还以为题目错了，架构师不是企业的打工仔嘛，企业要啥，架构师干出来就是，难道还要操企业目标的心嘛？其实，这里所谓的第一眼，不是看到标题当下的第一眼，而是半年前、大半年前，我都是这样的认知。最近半年来，架构认知有在改变。如果架构能把当下的钱赚到，算合格，赚到同时利润高点，算良好；如果架构能把未来的钱赚到，算优秀，未来更多利润赚进来，还不欠下技术债务，那就是无印良品。这么说来，企业的目标，大概率是当下赚到的钱，如何提高利润，如何赚到未来更多钱，算是架构师为企业找出的目标的动力源，算是第二眼看标题触发的思考。 * 📖：目标，正确、合理且可达，要多个职能之间反复讨论和演算，才得到这个被发现的目标 * 🤔：目标，领导说一不二嘛，以前愣是这么认为。自己做项目的经验，告诉自己，所谓目标在远处，更多是个方向，要在途中不停校准。这是目标的校准认知。如果大家都持有这样校准型的目标认知，一起推进项目时，会很有默契不停努力让目标清晰起来。否则的话，老是耳边听到抱怨，目标都不清晰，还干个啥嘞。如果是经验欠缺的新手，我会分享这种目标认知给他。如果是所谓的资深或经验丰富人士，我会自动屏蔽这样的老老新手，他们典型缺乏真正的经验，更缺乏反思和总结。

在老师的文章里看到了自己正在经历的项目，可惜我只是个人微言轻的小测试，也表达过自己的观点和我认为不合理的地方，但都无疾而终。

之前有经历过，多人团队开发项目迁移的项目。难点在于，文档缺失、核心人员基本流失。在经过几轮回溯和尝试，才勉强将数据迁移。最终线上正式部署，还是遇见部署失败问题。最终经过，反复推导解决细节问题，才能完成迁移。最开始的愿景，就是压缩成本、数据迁移，可能由于核心人员的变动，导致迁移流程复杂化。最终能成功迁移，应该也源于最初目标，让当前使用业务人员能正常运行。郭老师有个问题想咨询一下，就是在一个架构活动中，一个项目周期会有个长期远大的愿景。但是由于时间、交付、公司生存成本，如何取舍架构活动的整体生命周期呢？由于未知的不确定性，长期架构投入经历肯定更大，短期架构又不能适应长期需求的发展。这种改如何取舍 呢。您怎么看待过度设计这个问题