前言
软件攻城狮（简称程序猿）在日常的生活中有且只有两个状态
- 被一个接一个的、无穷无尽的需求搞得焦头烂额，顺便处理下不知从哪里来、也不知谁造的bug【敏捷迭代】
- 被一个大型、或有deadLine的项目搞得焦头烂额，顺便处理下不知从哪里来、也不知谁造的bug【定向爆破】
当然以上是猿同学们的自嘲和乐趣所在（没错，自嘲就是乐趣），其实这些好同志们一直以来都是追求“如何更好的完成任务”，孜孜不倦，永不妥协。而在团队越来越壮大的形势下，规则和规范初步形成的过程中、沟通成本的提升带来的种种阵痛无时无刻不影响工作的效率和产出（初创型和成长型的公司都会面临这样的问题）。今天我想通过自己的亲身经历谈谈我对于年轻团队逐步扩大过程中如何更好的沟通的一些浅见和看法。
年轻团队如何做好一个“大项目”，可以通过我之前分享的《思考框架》去整体规划这件事，包括时间维度上的工作安排、内容维度的职责划分，对整体目标进行拆解、细分到一个个小目标，step by step等等。当然做好了了这些事情只是为项目整体推进描绘了一个蓝图，而如果真的涉及众多同学的职责划分的话，那么起到关键作用的一定是“沟通”。
举个栗子
- A君B君C君是三个团队的Leader，A君整体R一个项目要求BC配合
- ABC定好了设计和交付时间
- A中途改了设计（必要的），通知到B，认为不影响C而没通知C
- C的下游发现交付的接口跑不通，C问A并从A处得到设计已改的消息
- C工作推倒再来，A和C都很不爽。
这个问题是在工作中是很常见的沟通问题。由于一个小小的信息没有及时同步，导致别人需要返工、甚至推倒重做，浪费了人力资源和时间。
如何改进
1. 目标集中管理
团队协作无论是以项目组的方式还是多组协同并行的方式展开，最重要的是目标的传达和集中管理，包括整个项目的目标、时间节点、里程碑都应该有清晰的传达，甚至应该在醒目的地方有暗示和提醒。一旦某一环节出现差错或者有整体计划的调整，都应该集齐所有关键负责人集体决策，让每一个成员感知到目标的变化。
2. 书面化沟通
针对一个大型的项目或者较长时间线的有deadline的项目，不同团队之间、甚至同一团队不同分工下的成员之间，他们之间的约定（尤其是有相互依赖的）都应该以书面的形式存在而不是口头承诺。我就曾因为口头承诺或者口头通知而使得最后项目交付前才发现双方理解有偏差、对方工作要返工而自己也觉得很委屈~~~具体的做法是双方的协定以邮件或者书面形式定下来，一旦一方需要修改协定就需要以同样书面的方式发全员通知（之前需要面对面做好协调和沟通），切忌单方面鲁莽做决定，很伤感情。这也便于事后责任归属和复盘（追责不是主题，成长最关键）
3. 耐心
大型项目不是朝夕能完成，需要一步一步一点一滴的去做，去推进。一旦发现问题，沟通的双方都应该保持平心静气、冷静处理。有时候问题本就不大很容易就能解决，但就是因为从沟通的开始双方就有着某种情绪导致争吵的发生甚至需要多次后续沟通才能摆平，无形中浪费了极大的时间成本。（我先检讨，因为我脾气就比较急躁和火爆）
4. 沟通有道
沟通是有方法的，比如可以借鉴“MOT”的方式来衡量认知与期望的差距。具体方法是：
- 当问题发生时，双方冷静沟通，探索问题的真实原因和解决办法；
- 以提议的方式寻求认同，决定解决办法；
- 双方定好各自变化的工作和新的协定，互相复述自己的职责，互相确认；
- 按协定进行行动。
当然，还有“同理心”、“换位思考”等方法都是我们可以参考的。
5. 旁观者清
当真的发生沟通不畅而有矛盾或者不好协调时，可以发挥“旁观者清”的作用，寻求第三人的帮助（找双方共同的Leader或者完全不相关的第三人在场，一定要能从中立的角度去评判整件事）。结果不是为了“双方握手言和”，因为一切只对事不对人，矛盾也只限于双方对于“如何更好的完成工作”产生的分歧。如果这个不能保证就是人的问题了，我们不谈。
最后
OK，大型项目是难得的成长机会，通过对中途暴露的各种问题进行总结、复盘，可以让团队的战斗力和凝聚力更上一个台阶，所以所以，在项目结束后一定要召集大家进行一次深度的认知反思与总结！
成长的路上注定荆棘丛生，打造一支“能打仗”、“会打仗”的钢铁之师才是我们的目标！加油💪！
