公司大了以后

十几个人一起做产品时，许多事不需要专门分工。要不要做、做到什么程度、用什么办法、哪天上线，几个人坐下来谈一会儿，大致就能定。中途改了主意，也不过是在群里再说一声。

等到一次上线需要六七个团队参与，改一个日期就没那么简单了。客户端要重新安排版本，后端要调整接口交付时间，风控和法务有各自的审查周期，客服已经准备好了答复，市场也可能买好了投放。日历上只是往后挪了一周，实际要重新确认的，是一串彼此牵连的承诺。

不少公司会先让某个熟悉情况的人顺手把这些事接起来。等到他忙不过来了，才给这类工作起一个名字，正式设立岗位。第一张图画的就是这段变化。

图一：随着公司规模扩大，为什么做、做什么、怎么做、什么时候做和谁来做，通常如何分配。

谁来回答

第一张图更像一张问题的去向图。在初创团队里，创始人同时回答五个问题。他知道客户为什么需要这项功能，能够决定做什么，也清楚团队里谁有空、谁熟悉相关代码。此时的信息还比较集中，一个人可以从商业判断一路跟到具体实现。

业务铺开以后，回答这些问题所需的信息散到了不同地方。为什么做、做什么，需要了解客户、公司方向和取舍成本；怎么做，要熟悉系统；什么时候做、谁来做，还得考虑风险、依赖和人员状态。

图中把为什么做和做什么交给产品经理，把团队内部怎么做、什么时候做和谁来做交给工程经理。跨团队项目增多以后，技术项目经理开始处理团队之间的时间和责任关系。这是大型科技公司中常见的一种分法，并非所有公司都需要照搬。是否需要专人协调，和人数有关，更取决于一件事要穿过多少团队、系统和外部机构。

假设公司准备接入一种新的支付方式。产品经理要确认第一版支持哪些地区和场景，工程经理要判断系统怎么改、谁适合接手。项目牵涉到移动端、风控和法务以后，还得有人弄清各方在等什么，一处延迟会影响哪里。

做到这里，“什么时候”已经不能用一个日期回答，“谁来做”也不能只填一个名字。负责协调的人如果只会催进度，作用不会太大。他至少要听得懂各方为什么不能答应，分得清哪些困难可以协调，哪些问题需要回到产品范围或者公司优先级上重新决定。

图上的五个问题分得很开，现实中却经常往回走。日期赶不上，可能要缩小第一版的范围；实现风险太高，可能要重新考虑这件事是否值得做；团队里没有合适的人，方案也会随之改变。分工的作用不是让每个人只管一个问题，而是在问题互相冲突时，知道该由谁把它接过去，作出下一步决定。

许多职责调整之所以没有效果，原因也在这里。公司把项目表交给了新负责人，却没有交代此前做过哪些取舍，也没有给他调整优先级或者向上升级问题的权力。职位上写着他负责，遇到分歧时，大家还是去找原来的负责人。公司于是有了两套分工：一套写在岗位说明里，一套留在大家的习惯中。新负责人替别人收集信息，原来的负责人继续作出关键判断。

图二：软件开发、战略协同和人员管理，通常怎样占用不同岗位的精力。

一天不是八个一样的小时

岗位分开以后，还有一件事留在图外：接下这些问题，一个人的一天会变成什么样。第二张图把这件事补了出来。

软件开发需要相对完整的时间。写代码或者研究技术方案时，人会把不少尚未写下来的东西暂时放在脑子里：刚刚验证到哪一步，哪条路已经排除，两个模块之间有什么关系。中途去回复十分钟消息，回来以后未必能从原处直接继续。

战略与协同的节奏不同。其他团队正在等结论，某个依赖刚刚发生变化，早上确认的计划到了下午可能已经过时。负责这类工作的人需要参加会议、阅读消息，也要在信息并不完整时先作判断。他的时间很难完全关起来，因为保持联系本身就是工作的一部分。

人员管理又有另一种消耗。一对一谈话只占日历上的半个小时，对一个人的了解却要慢慢积累。最近为什么沉默，工作没有进展是能力问题还是协作出了问题，什么话现在适合说，什么话最好再等一等，都离不开长期接触。有些谈话结束以后，管理者还会继续想着，很难立刻切换到一段需要高度专注的技术工作。

一项结合四千九百一十条专业开发者任务记录和一百三十二人问卷的研究发现，中断造成多大影响，和任务类型、上下文变化、中断发生的时机及来源都有关系。研究没有给出一个适用于所有人的固定恢复时间。这一点反而符合日常经验：日历上同样空出半个小时，回复几封邮件以后还能接着做的事，未必能在一次复杂讨论之后立即接上。

第二张图中央的警示因此很实际。一个人可以懂技术、会协调，也能带团队，但这些工作对他的要求经常互相冲突。开发工作希望一段时间内没人来找，协同工作要求在关键时刻能够找到，人员管理则需要人在场时还有耐心，不把上一场会议的急躁带进谈话。

工程经理或者技术负责人很容易走到这三个圆的中间。他上午原本要写一份架构方案，刚开始不久，另一个团队来问接口日期。处理完依赖，已经到了例会时间。下午有两次一对一沟通，其中一次谈到团队成员最近的状态，需要继续跟进。晚上安静下来，才重新打开早上的方案。每件事都合理，整天也一直在工作，只是很少有一件事能在合适的状态里做完。

项目出问题、管理岗位暂时空缺或者团队正在重组时，这种安排很难完全避免。短时间多接一些事情，也可能是一个人扩大能力范围的机会。麻烦在于，临时安排很容易因为“目前还能运转”而被保留下来。几个月以后，所有人都习惯了找他，他自己也未必说得清哪些工作原本只打算代管。

即使有人有能力回答所有问题，他的一天也未必放得下。岗位分开，除了让答案更可靠，也是在给不同的工作留下合适的时间。

问题最后落到谁那里

正式的组织架构图能看出谁向谁汇报，却很难看出工作实际怎样流动。平时一切顺利时，这个差别并不明显。等到优先级说不清、两个团队的日期发生冲突、有人状态不对或者线上出了事故，可以看一件很简单的事：谁最先被拉进来。

不少公司都有这样的人。他记得某个方案去年为什么没有采用，知道法务最介意的是什么，也知道某位工程师在大型会议上不太会直接表达反对。他不一定拥有最高的职位，却能在几句话里补齐背景，让争论继续往下走。

这些工作很少直接表现为代码、文档或者收入。许多问题经过他以后很快消失，甚至不会进入正式流程。公司看到的是事情处理好了，不容易看到他一天被叫走多少次。因为每次找他都有效，下一次遇到说不清的事情，大家自然还会找他。

要检查这里有没有问题，不必再画一张更复杂的组织架构图。回看过去一段时间里的临时会议、求助消息和升级事项，把它们放回第一张图的五个问题中，通常就能看出一些东西。需求总要找同一个高层确认，说明为什么做和做什么还没有交出去；各团队反复追问日期，可能是跨团队依赖没有稳定的维护者；岗位已经设立，问题仍然绕回旧负责人，多半是背景没有交清、权限没有给够，或者团队还不信任新负责人。

再把这些事情放进第二张图里，还能看到工作是否长期压在同一种人身上。有人偶尔跨过几个圆很正常。如果一个人持续承担软件开发、战略协同和人员管理，又成了所有例外情况的入口，调整日程只能解决很小一部分问题。公司需要重新决定哪些事情必须由他处理，哪些判断可以交给别人，哪些信息应该有第二个人知道。

分工不需要做到彼此毫无交集。没有重叠，许多重要背景会在交接中丢失。更稳妥的做法，是让必要的信息由几个人共同掌握，同时把最后的决定放在明确的位置。交接一项职责时，也不能只移交任务清单。此前的取舍、相关的人、可以使用的权限，以及没有把握时去哪里求助，都要一起交过去。

两张图放在一起，我更关心的是两个接连发生的问题。第一张图问问题归谁，第二张图接着问，那些一直没有归好的问题，最后在占用谁的时间。

被称作“不可替代”，对个人来说常常是一种肯定。放到公司里，有时也说明某些地方一直没有接好。一个人总能把事情接住，当然是能力。可如果每件说不清、定不下、没人管的事都要靠同一个人接住，公司只是暂时省下了重新分工的麻烦。

这笔成本不会消失。它先记在那个人的日历上。

图与资料

第一张图据 Gergely Orosz 的 What TPMs Do and What Software Engineers Can Learn From Them 重绘。

第二张图据 Gergely Orosz 的 Engineering Leadership Skill Set Overlaps 重绘。

关于软件开发中任务中断的内容，参考 Zahra Shakeri Hossein Abad 等人的 Task Interruption in Software Development Projects。