谈一谈跨部门协作

2021-08-18 创建

2021-08-18 更新

5分钟阅读时长

前言

这一篇博客想聊一些比较感性的话题，笔者工作至今已经满5年多，时常会思考一些作为程序员职业生涯所常见的困扰，这些困扰可能不一定存在着标准答案或者是最佳实践，但总是值得拿出来讨论分享。

这一次的话题是关于跨部门协作。软件工程发展至今，基本告别单打独斗的英雄主义，协作沟通是程序员需要具备的基本技能。跨部门通常会成为协作的一大痛点，根本原因可能是不同部门的人员关系疏远、短期目标不一致、沟通方法不对、信息不透明等等。

康威定律

设计系统的企业受限于生产设计，这些设计是企业沟通结构的副本 —— Melvin Conway(1967)

康威定律反应出系统架构和企业结构之间的联系。业务系统本质上仍然是由人来维护的，因此生产系统的架构会反馈出企业组织的结构，甚至决定企业组织架构的发展趋势。

假如团队的组成是前端、后端、DBA，那么系统架构很可能是：

而假如团队的组成根据不同业务来划分，例如电商业务、社交业务、O2O业务，那么系统架构很可能是：

关于康威定律的具体内容包括：

第一定律：企业沟通方式会通过系统设计表达出来。
第二定律：再多的时间也没办法让任务完美至极，但总有时间能将它完成。
第三定律：线型系统和线型组织架构间有潜在的异质同态特性。
第四定律：大系统比小系统更适用于任务分解。

这里笔者不对康威定律的细节做更多展开，主要想强调：在思考如何解决跨部门协作问题之前，我们要深刻理解企业组织的结构与业务系统的架构之间的核心关系，不能脱离这一层内在联系去想解决方案。

跨部门协作

达成共同愿景是第一要务

公司的组织架构是多样化的，在提及跨部门协作之前，我们需要首先达成一致的共同愿景。两个团队，无论各自内部的力量有多大，如果在合作之前没有达成共同的愿景，那么目标永远也无法完成！不仅如此，当决策方向存在错误时候，彼此之间的努力结果甚至会互相产生负面影响。

事实上，目标的聚焦和对齐反而是工作中比较容易忽视的核心环节。许多工程师甚至是Leader喜欢一上来就讨论需求、设计架构、排期开发等等，但其实我们可以先等一等，对需求的背景再多一些了解，对需求涉及到的上下游团队再多一些了解。我们需要先彻底排除团队中哪些拖累目标的因素，然后再开始考虑如何规划。

学会向上暴露风险

向上暴露风险是必要且作用强大的。不是每个公司都能做到“不讲Title”，当一个Title较低的员工跨部门向另外一个Title较高的Leader去沟通协商时候，很容易遇到合作意向低、沟通效率低、达成共识困难等等问题。

当你意识到这样的情况，请及时大胆地向上级汇报，暴露风险。我们要正确理解这种行为，这不是向上级打小报告，而是一种正确的方法论。向上暴露风险本质是给决策者更多的信息输入，帮助他们更好的规划整体节奏；另一方面，同Title的人沟通会更加引起对方的重视，这里倒不是说对方的Leader会故意不配合，更有可能是己方的员工对沟通流程和协作方法还没有很好的把控，选择私下直接找对方沟通，对对方的Leader产生了困扰，因此碰壁。

与技术中台、基础架构等下游团队的合作

当公司的组织有技术中台和基础架构等下游团队时候，我们需要注意遵守合作共建原则。重复发明轮子是软件开发的大忌，而且从企业的人力成本考虑来说，复用是更加节省成本的做法。

但是，业务部门不可避免地会遇到这样的场景：当前技术中台或者基础架构无法满足业务的需求，或者无法及时交付业务的需求，怎么办？

首先，我们要保证双方的最终愿景是一致的，这是上文提及的首要原则。其次是，我们要理解短期之内的目标是存在差异的，业务需求不永远是最高优先级，不能当做借口去盲目推进下游团队修改规划。因此，业务部门允许有短期方案去弥补业务抢占市场的时机，也要配合中台和基础架构去定制长期规划，新轮子的最高价值就是能够在更大的范围内去推广。

与产品、运营等跨职能团队的合作

与非技术人员沟通协作的关键是换位思考。从业多年，我发现某些技术喜欢鄙视产品，某些产品也喜欢把技术当做人力资源去使唤，这些都是现实生活中存在的。我们要学会换位思考，假设你是对方的角色，你是否有更好的建议和意见。只会抛出问题是不够的，也是不负责任的，在抛出问题的同时要有下一步的Action。

另一个与产品、运营合作的常见问题是需求倒排期。所谓的需求倒排期是指产品、运营在未经沟通的前提下，直接跟客户承诺需求的交付时间，导致研发在考虑技术方案和开发节奏上面处于被动局面。