29｜节点五：项目启动仅仅是一个仪式吗？

看了这篇文章。我突然意识到。其实很多中小企业。是根本没有架构师的。或者说，在这些地方架构师只是一个职位而已。因为在这些地方，所谓的架构师根本没有办法，根据推导出来的风险中止项目。只能被动的随着老板的命令到处救火。最后还要成为背锅的那个人。

至心感激东白老师的课程。这一课里用恋爱&婚姻来比喻项目的engage，实在是太生动了。通过这一课的学习，更深刻地理解了“架构师的角色如同律师”的类比，与律师一样，没有决策权，但是decision maker的最终决策，90%取决于律师（架构师）的建议。 关于本课的第一道作业，学生印象最深刻的是一次“与第三者的热恋闪婚”。几年前还在老东家时，与其他工程师一起，突然被老板叫进会议室，宣说高层已经与某中国互联网巨头达成战略合作，从今日起，中止global solution的开发，全部精力投入新项目开发，并以正常项目½的时间完成。当时，架构师从来没有与合作伙伴谈过架构方案，所有工程师更不清楚如何完成与global的“离婚”，并完成与新合作伙伴的“闪婚”。最终这个项目还是带着很多问题成功交付了，我们很多工程师，也凭借这个项目获取了其他竞争企业的橄榄枝。 然而，戏剧的是，正是没有东白老师提到的“婚前协议”，昔日“热恋闪婚”的双方似乎早已开始天天互撕。 综合思考作业的第二和第三道题，是否意味着“预警机制”是最重要的。因为学生经历的失败项目，往往是开发过程中，一些短板的拖后腿，导致整个项目错失最佳时机，也正如上海这次的疫情从3月初的华庭酒店事件开始，因为缺乏合理的预警机制，导致疫情很快地一发不可收拾。

我开过一个启动会，我说除非出现重大site issue , 不然这个项目就一定要进行到底。我的一个同事在会议上补充道：不对，应该是就算出现重大site issue , 那就先舔好伤口以后，然后我们还要继续。

🤔☕️🤔☕️🤔 * 📖：项目启动，参与一次有约束效应的目标与任务确认。 * 🤔：一个仪式，可有可无的话，先默认为无。然后，安静下来思考，为啥人家会有。千万不要想都没想，就开始拙劣得模仿。快速启动模仿，缺乏基本思考的模仿，过程里略有点困难，就容易积累起挥之不去的困惑，最终导致大家的不信任。这种没头没脑的模仿，每个人都会发自内心的厌恶。 * 🤔：释放一个信号，我知道这件事情，我重视这件事情。这是启动仪式的一个最基本功能。可是，我依然会在这样的启动仪式上，感到说我知道的人心里，其实都装满了各种困惑和不解。即使不说出来，在场的人都能感受到这不言自明的假装。 * 🤔：所以，把问题澄清楚，把过程梳清楚，把职责分清楚，大家内心都已经清晰，再开项目启动会，做出公开确认，会达到更大的目标确认和信心鼓舞的效果。就像一块玉，打磨得无暇，作为大家的目标，跟略有瑕疵作为大家的目标，实际上在内心深处的效果，就像一点点小虾壳卡在牙缝里，持续的难受感。 * 📖：启动会的准备，就是督促架构师去审视，哪些系统性风险？哪些潜在的失败因素？哪些必须实现、哪些随时准备放弃？ * 🤔：一次公开亮相，正好也是一次全面盘算的机会。只要拿上台面，就得说清楚来龙去脉，就得回答大家的疑惑，更要经得起质疑。准备这些，就是重新在整体和细节上，逼迫自己切换为评审方视角。再梳理一遍时，会发现原来有这么多直觉式的决议，这些都得在Why层面重新审视和解答。 * 📖：设计好问题预警和冲突解决机制。 * 🤔：如果项目推进没有遇到问题，这估计是该项目最大的问题。如果项目里的问题和冲突，都推脱到项目准备不充分，或者怪罪办事人不给力，这只能说大家都不够成熟，甚至已经做好甩锅都准备。 * 🤔：个人经验上，在设计这样的机制时，会有不同意见，而且都是比较强烈的情绪。这时候，大家做一次局面和处境对齐。也就是说，现在我们都在怎样的处境下，我们面对怎样的局面。如果我们一起破局后，能够打开新的局面，能够改善大家处境的局面。说得高级点，就是格局要大一点、远一点。这时候，只要对方能够情绪稳定下来，并且认可这样的困局到破局的过程，那么就能理解途中必定有很多问题和冲突，只有这些力量最终能破局。

请教郭老师几个问题： 建一个垂直领域的招聘网站，目标用户有一百万： Q1：开发人员需要多少人？ Q2：从人员齐备开始，到项目正式上线，需要多长时间？即开发时间需要多少？听说互联网公司都很快，三个月就能完成吗？ Q3：服务器和带宽成本大约有多少？

郭老师，take away~~~用逻辑思考问题，论据(包括假设条件)是否靠谱，论证推理逻辑是否严谨，结论是否跑题。如果用人情、大的原则思考问题，项目启动会就是大家都坐在地雷上开会~~~ 以前给华为客户做外包项目时，不能失败。项目启动会压力很大，WBS分解，客户压力也大。从此以后，我放下管理身段，走上了10年建立技术自信的道路~~~

一般来说，我们做取舍的原则是以保障用户价值和商业价值为前提，且尽量满足架构活动的技术目标。但执行方往往会以保障自己领域的交付时间为第一优先级。很明显，两者是互相冲突的。我从来没见过哪位决策者强制一个团队必须优先保障交付时间。哪怕是双十一大促这样的大项目，也要先确保商业效果，而不是交付时间。一旦碰到资源冲突，最终肯定是先砍掉低优先级的需求，而不是商业效果。 哎！我们现在只会看交互时间😭

“我从来没见过哪位决策者强制一个团队必须优先保障交付时间” 这个我还真经历过，开发工期一压在压，需求完全不砍，argue了很多次没有用。结果大家喜儿乐见

现实中一般都是 既是项目经理又是架构师

冲突的解决，本身就是一个政治问题。