21｜节点三：如何通过可行性探索来帮助架构活动避免重大失误？

非常感谢老师提供的关于可行性探索准备工作的Framework，如果早些学习到，就不会碰那么多壁！ 最近学生刚好在推进一个自己认为风险极小的架构活动，不过除“赞助者”外，都认为有“巨大的风险”。最后是通过快速开发demo，测试数据到统计分析，用∂评估风险。目前仍然在等待决策者决策。 从这次遇到的阻力，学生总结的是：无论任何方案，都是有利有弊的。即使回报是给用户带了很好的体验，给企业带了更高的毛利。然而任何新的架构，都必然会损害老架构中组织或团队的利益，也就会触动之前课程提到的“马斯洛人性需求”，应该以谦逊为基础，尽一切可能去帮助他人。

这边文章多处验证了组织的高阶理论。一个组织最后只能存留高层试图保留的意愿和风格。自下而上的东西要存留，如果不符合高层期望，是困难的。

有种大开大合搞架构畅快，但是都是公司刚开业，或者不计成本探索新业务。 但是总体不可行。 创业公司要第一时间接入外包，最快方式跑起业务获客。而不是技术架构。这是刚吃饱，才能首要做的事 探索新业务，调查各方风险承受度，也不可行。 甩给你一块新业务，就是要在有限资源，有限时间，目标不合理情况下，做出成绩，才有可能让你承接更大项目。 所以核心关键是MVP，技术架构最小可行性，产品核心点最小可行性，运营产出有限资源下最大化

老师，问一个非专业问题，赞助者具体指哪些角色的人，决策者也有可能是赞助者

个人视角 我所在的部门对于开发制造的风险几乎零容忍

第一个问题：最近临时去填一个需求，需求已经完成但是完全不符合用户的需要，修修补补实在没办法，产品以及架构都是新人去投入，那时候保交付优先的思想，所以做了很多定制化的工作，而且对于临时填的这个需求的业务背景以及上下文环境也了解的不够透彻，可想而知，后面就是为了定制而无休止的进行处理。这个事情给我带来的最大一个教训就是：千万要做好风险评估工作，如果自己确实接不了，没必要强接，不然本来不是你的问题，最后强行变成自己接锅了！！

这期的图片怎么是剪纸的骷髅头。。这俩结合还是第一次见

🤔☕️🤔☕️🤔 * 📖：可行性探索，可以帮助架构活动避免重大失误 * 🤔：除非这事情做过，否则都存在说起来容易，做起来难，甚至极难的情况。自己的经验里，发现做是否能达到认识同步的可行性探索，比做技术可行的探索，要难得多得多。自己认为可行，在自己认知的框架和视角下，在某个瞬间感觉到信心满满。可是一旦开始推进工作，就会发现大家都在表面的信心满满之下，实际并没有对目标和过程有相同的认识，甚至一开始就心念不合，还一直勉强追赶节奏，这种出格的变扭感，只有一起走几步，一起探索一下，才会发现是否真的适合一起干下去。所以说到可行性探索，居然我先想到的是认识同步的可行性探索，不得不说，必定是我曾经掉进这样的坑里。这些掉坑经验带给我的教训就是，团队一开始的海誓山盟，不如一起在小路上走一段来得更加真情实意。 * 📖：冒风险的机会，是上帝给架构师的筹码，而风险判断力不断提高的过程，就是一个架构师逐步走向资深的过程。 * 🤔：曾经我有过这样的念头，在一个选择的关口，我做出选择时所面临的风险，实际上是回报的杠杆。而且这个念头我曾经在小团队试验过，当时的错觉是因为只有我说了算，所以我不得不这么去选择和决定。后来在较大的团队，反而把这个念头给整没了。觉得我把风险挑明，冒不冒风险不是我的事。现在看来，能识别出风险，算是我的基本能力，但是不去冒风险，可能是我被关在资深门外的重要原因。该如何能打开资深这扇门？绝对不是看到风险，就冒失去挥霍上帝的筹码吧？如果找到几个人，都认可这次得冒失点，必须去挥霍一次上帝出筹码，算是一把钥匙嘛？

郭老师，take away~~~ 我最近负责了一个项目，根据我理解的公司战略意图，一些关键目标，可能有决策风险，我没告诉大家我的思考。设计了一个“坑”，让总裁和我，双线PK，同时执行A计划、和B计划。结果我也掉在“坑”里了，辞职干不下去。，有一个体会，战略意图，首先需要对应的思维方式支撑。一个架构师需要有很强的战略意图和相应的思维方式，不然结果会打折扣，A计划和B计划都失败~~~

风险和回报是伴生关系，高风险高回报，需要把风险降低到可接受的程度以内，不然就是赌博心理。