16｜通用技能（上）：如何帮助团队达成共识与控制风险？

🤔☕️🤔☕️🤔 * 🤔：建立共识，特别难，一起跳到坑里，再一起爬出来，就会先建立大家都不容易的共识，然后才会对新目标，更容易产生共识，尤其是大家会觉得，要不一起先干一把，再回头看到底是怎么回事。 * 🤔：一直在推进嵌入式设备的软件模块进行UT的事情，一开始根本没人搭理，怎么说都觉得怎么可能。一方面没有直接经验，另一方面拿着设备调试惯了，经常要出现所谓联调，尽管效率低，这么多年还不是这么过来。后来我自己开始实践，写完模块写UT，发现UT不难写，但是设计怎样的UT，从哪些维度思考的UT，才能让模块真的在联调前达到预期质量，真需要实践和思考，才会掌握到位。可是我说给大家听，还是仅点头，不会自己动手。后来抓住机会，在某个项目里实践起来，真正体感到，原来自己UT通过，只要UT设计合适，就是能够一把冒烟测试通过。有了这种惊奇的直接经验，才会到处去传播。 * 🤔：所以说，共识，要自己认识到，要自己体验到，要别人认识到，要别人体验到，那才能真正产生共识。

感谢老师精彩的课程，看到老师的最后一个问题，非常感触，感觉这不仅是企业组织的问题，更是社会的问题。最被忽视的群体，往往是固步自封的个人或组织，例如改革开发导致了无数的小国企倒闭，无数国企工人下岗。能够做的，或许只能学习小平同志，首先自己“解放思想，实事求是”，然后帮助暂时落后的群体“解放思想，实事求是。” 例如在传统车厂，特斯拉时代的到来导致车内大量的开关（按键）零件被取消——由中控娱乐主机的显示屏软件化集成。这就不仅需要企业在方方面面帮助原来这些被淘汰的零件的责任工程师转型，更需要面临危机的工程师自寻破局之路。

🤔☕️🤔☕️🤔 * 🤔：利益被忽视，太常见，常见到都不敢去正视。个人觉得，虽然这里用了被字，但实际上也有活该，甚至可以说该死才忽略。作为个人，一直勤奋工作，当然得竖起大拇指，但如果不思考自己的价值，不思考自己的成长，不思考所处的环境跟自己的匹配，可以用比较实在来形容，但是更应该用责任感差来形容。每个人都不会一辈子只有一把键盘和一盒泡面，一定会经历上有老下有小的生活。尤其是已经在这个过程里，还让自己躲在老实人的外壳下，那被忽视不是他还是谁。所以我反而觉得，被忽视一次正常，反复被忽视，迟早会被当头棒喝。

这篇其实主要讲的是与人沟通，是道，而不是术。我认为它更像是一节情商课。同样，可能也只有有情商的人才能落地这节课的内容。。。

结合思考题说下个人感受吧 思考题1：说下之前公司金融域重构的事情。 要重构的是整个金融域，规模还是很大的。要重构的目的除了语言上融入新公司，还有就是业务需要，之前的架构已经不太好应对日益增长的单量了，需要更新更事实的架构。 这个项目最终上线了，不过由于老人几乎走光，给项目带来了很大的阻力。 走的原因是，架构师招了一批Java同学来重构系统，新老系统并行开发，python的同学觉得自己在这边得不到发展，而且当时python在上海还是有市场的，就差不多走了。 当时对这位架构师最不满的是招了Java同学，后来私下里问过这位架构师当初招Java同学的决策，说是感觉到python同学要走，想加快进度，没想到走得更快。 我也能感觉到当时的大环境很难留住这些python同学了，但在上面的压力下重构又不得不做，不知道东白老师碰到这种情况会怎么处理？ 思考题2 我理解的建设共识的过程是一个利益交换的过程，一个leader说的话给我的印象很深，他教我要发现身边同学的欲望，从欲望触发做利益交换，这人只要有欲望，就有办法做利益交换。我觉得这事也适用于架构活动建立共识，如果这人的欲望不在工作中，也可以是生活中的，比如迁根红线，违法犯罪违背道德的事情不能干。这样没准后面还能成为好哥们，相关事情也会更好推。 补充下这事的背景，就是当时这位leader想推UT，我问他怎么推动事情时，他跟我说的，我问他如果一个人没有欲望怎么办？他说这种人他不会招。不过UT这事还是推失败了。 思考题3 看到题目我就想到了之前的打车市场的优惠券大战。各公司参战时都觉得是一时的冒险，但后来大家都这么干了，就成了增长型的冒险了。冒险的性质不是不变的，可能及时识别风险，控制风险，及时止损更重要些

相较于老师讲的场景与方法,老师做人的道德更令我敬佩,确实,成为一个可信赖的人是做成事的基础,老师的课是我今年最大的收获,这课我买赚了。

所谓善人，人皆敬之，天道佑之，福禄随之，众邪远之，神灵卫之；所作必成，神仙可冀。

建设共识这块，我根据可观测项目进行的总结 https://mp.weixin.qq.com/s/jCnzsrcqwXOkK7zfRzV0Og

我目前负责可观测系统建设，其中一个目的就是当线上某个业务不正常时，能够通过数据观测到哪里出了问题。早先是各个部门各搭烟囱，自扫门前雪，一个问题需要几个部门的人挨个利用自己的工具分析排除，信息不共享，效率低。我想形成all-in-one的共识。我会充分考虑参与者的利益，合作后参与者有什么好处，为参与者着想。这样会稍微顺畅一些

捉个虫，“不够(过)这里可能还有其他更深层的理由” 另外，刚开始看，个人理解，“建设共识、控制风险、保障交付和沉淀知识” 这4个部分感觉分别对应， “建设共识”：项目开始前统一目标，确定方向 “控制风险”：项目开始前也有风险，需要确定规避，更多的是过程中的风险 “保障交付”：保证项目完美交付上线 “沉淀知识”：项目交付完成后需要累积经验，除了前面的代码服务，还要有知识库的内容完善 其实感觉和PMP的体系也非常相像