这是芃篙君的第【339】篇原创
本文适合在软件行业发展的朋友。大概1700字，阅读需要6分钟。
你好呀，我是芃（péng）篙，一个相信思考和努力能够拿到结果的家伙。
今天我们把视线从第三象限上移，到第二象限。
第二和第三象限，聊的都是需要协同完成的事务。只不过第三象限的协同具备更多的突然性，第二象限比较温和，具备更多的计划性。
01
就协同本身而言，之前聊过不少相关的话题。
芃篙之前把这篇内容命名为“清理协同齿轮中的沙砾”，后来想想，这个描述其实是对上面几篇文章的总结，并不是今天要聊的要点。
过去讲的更多的是如何在第二、三象限中把协同这个动作做得更好，并没有象限之间迁移的意思，甚至规避了迁移的可能性。
站在第二象限，排除优化协同能力本身不提的话，最重要的是如何把事务往第一象限推。也就是说，效率最高的协同是不需要协同。
02
所以，这是一个把有计划的协同性工作，变成有计划的独立工作的过程。
但也不用不着走极端，如果所有事情都一个人干得完，对这个人的要求也太高了。当然，未来 AI 如果可以替代一部分角色的工作，或许是另外一个局面。
目前来看，从第二到第一的过程，其实是一个尽量减少协同人数的思路。并不一定是要把一些协同工作变成一个独立完成的工作。
我们日常遇到最多的计划性协同型工作就是项目开发了，以此为例的话，如何才能减少项目开发的协同人数呢？
大概有几个思路。
其一是，在技术方案的设计上，做协同成本上的考虑。在保证需求的前提下，尽量选择降低协同交点的方案。
比如，内外部联调能规避就规避，不能规避就尽量降低交点的范围；涉及到多端协同的，尽量做好端侧之间的能力分配，规避不必要的联调。
沿着这个思路走，其实就是康威定律的体现了——软件的架构演进，一定跟组织结构成正向的关系。
其二是，在技术选型与组织发展节奏上做合适的努力。
这一点在客户端开发的角度比较容易举例。你的 APP 要不要走跨端的路线，如何选择技术栈，技术如何支持未来的业务发展，这些问题都会决定协同的复杂度和后续长期视角下的生产效率。
其三是，组织结构的设计，加入协同成本的因素。
还是以 APP 开发举例，组织结构设计成 iOS 团队+Android 团队合适；还是按照业务划分，每个业务中既包含 Android 开发，也包含 iOS 开发合适。这需要跟技术支持业务长期发展的基础决策之下，配合执行。
写到这里，就发现，看起来有三个思路，其实就只有一个思路——从各个角度来适应康威定律。
03
第二象限还有其他典型的事务吗？当然有。
比如，之前聊过的，从第三象限优化到第二象限的、需要协同解决的客户问题；
比如，需要定期召开的会议、面谈、汇报；
比如，周期性的规划制定和绩效考核；
再抽象精细一点，我们每天都会进行线上群聊沟通，那么线上群聊沟通是否也存在一定的优化技巧……
相对来说，这些事务更加不具备“行业特色”。软件行业才会涉及到软件项目开发，但是几乎所有行业都需要开会、考核、解决客户问题。
所以，这些事务的“不需要协同”的优化更具备通用性，但是又比较零散。这里不做展开。
尤其需要注意是的是，咱们聊尽量消除协同，并不是“反协同”。
消除协同只是在执行层面尽量减少人与人之间的交集，并不意味着我们要减少自己对其他人的链接。
消除协同，消除的是不必要的协同，让效率优先，也就是某种程度上的协同成本优先。
协同是必然存在的，现代社会就是标准的分工协同社会。所以，对外的链接是需要持续加强的。
换句话说，就是强化自己在更广泛产研运营销售链路上的影响是重中之重。
链接到更多的人和资源，你才能从更高视角看到更多的方案上的可能性；
链接到更多的人和资源，你才有更多协同选择方向的可选空间；
链接到更多的人和资源，你才能不断提高个人影响力，提高自己组织资源、把事情做成的概率。
相关链接
关注芃篙君⬇️，每日获取思考与践行的认知更新...
可获取软考备考资料；
亦可加微信探讨开发者、职场与管理、IoT行业等话题；
共同成长，穿越周期！
