1.3 乘务编制：角色与团队构成

1.3 乘务编制：角色与团队构成

知道了原则谁来守，本章就齐了。本节把一趟版本列车上的岗位逐个点名——谁排运行图、谁验货单、谁开车、谁试跑、谁值夜班——并给出一份能直接套进小团队的职责对照表。读完它，第 2 章讨论各种发车方案时，你会知道每个方案实际是在调动哪些人。

列一张岗位清单

软件项目的角色常被画成密密麻麻的岗位图，其实按职责可以收敛成七类。注意"角色"不等于"人头"——五人小队里一人常兼两三个角色，关键是每个角色都有明确的人对它负责，而不是"大家顺便都看着点"。

图 1-2：版本列车乘务编制

职责边界：一张 RACI 表讲清楚

多角色协作最容易出的事故不是"没人干"，而是"都以为对方干了"。RACI 是把职责钉死的常用工具：R 负责执行，A 拍板担责，C 被咨询，I 知会结果。每件事只能有一个 A——出现两个 A 等于没有 A。

看第 4 行"发布放行"：运维负责执行发布动作（R），但拍板的是项目经理（A），QA 的意见是必须咨询项（C）——这意味着 QA 有权按下暂停键，却没有义务替任何人签字。职责清晰的团队吵的是"该不该发"，职责含混的团队吵的是"这锅谁的"。

反模式：编制里的三个坑

• 司机兼任全部检修：写代码的人自己做全部测试，等于让司机自检出刹车故障——他倾向相信自己开得好。开发做单元测试没问题，验收性测试必须由别人接手。
• 调度长遥控驾驶：项目经理直接指挥"这行代码今天必须改完"，越过架构与开发的技术判断。调度长的职责是让列车准点，不是替司机打方向盘。
• 安检员归车队队长管：QA 向开发负责人汇报，安检结论就容易被"赶工期"压掉。QA 独立汇报线不一定适合每个组织，但发车前的一票否决权必须落在不对进度背锅的人手里。

⚠️ 还有一种隐形坑：角色齐了，闸口形同虚设。表格挂在墙上、RACI 谁也没看过，照样出"都以为对方测了"的事故。判断编制是否真在起作用，抽三件最近的事故问一句"按表上说的，这事该谁拍板"——答不上来就是空表。

案例演练：给云梯平台配编制

把本节工具用起来。云梯货运调度结算平台重建时按八人配置，下面是它的编制表与一次真实分工争议的裁决记录：

云梯平台编制（8 人）
  项目经理 1 名（兼过程改进）
  产品经理 1 名（兼客服接口）
  架构师 1 名（兼核心模块开发）
  开发 3 名（后端 2 · 前端 1）
  测试 1 名（兼自动化脚本）
  运维 1 名（兼安全基线）

争议现场：
  上线前一天发现运费分摊算法在满减叠加时有精度误差。
  开发：改动小，今晚改完明早发。
  测试：涉及金额，回归需一整天，明晚才能发。
  项目经理裁决：推迟一天发车。
  依据：产品经理确认涉及钱的缺陷按最高级处理（A = 产品经理），
        发布放行需测试报告结论（C = QA），赶工绕行无效。

复盘要点：
  编制表的价值不在纸面，而在争议发生时裁决有出处。
  这次推迟后来被证明正确——该算法同时影响三个仓的账单。
​

注意案例里的细节：项目经理没有亲自评估技术风险，而是依据职责表找到正确的拍板人。这就是编制表的真实用途——它平时不被想起，争议时一锤定音。

跨角色沟通：谁跟谁说什么，多久说一次

编制表之外，角色之间还需要一张"通信时刻表"——沟通不是越多越好，无结构的沟通同样吞掉产能。云梯的协作节奏表值得参考：产品经理与项目经理每日对一次优先级，十分钟站会解决；架构师与开发每两天一次技术对齐，只谈接口与风险；测试与开发在缺陷单里异步往来，只有争议缺陷才开会；项目经理对发起人每两周一次书面汇报，数据取自仪表盘而不是临时编。表的要害在于频次与载体都事先约定——沟通一旦依赖"想起来就说"，重要信息一定漏发，不重要的一定轰炸。

还有一种常见误解值得澄清：角色分工不等于各管一段互不越界。好的编制恰恰鼓励"越界观察"——测试看需求时发现的可测性问题，是需求质量的免费体检；开发看运维告警时的每一次皱眉，都是架构问题的早期信号。分工划的是责任的边界，不是关心的边界，把这两件事分开，协作就顺了大半。

三个高频疑问

问：一人身兼三个角色，RACI 还有意义吗？ 有，而且更有意义——兼职最大的风险是"不同角色帽子戴串了"。给自己立个小规矩：做决定前先默念"我现在戴的是哪顶帽子"。兼任测试时给开发同事（也是自己）挑毛病，就要以测试的标准而不是作者的标准；同一个人在同一件事上出现两个 A（比如既当产品定需求又当开发说做不了），冲突会被自己内部消化掉而无人裁决——这正是兼职团队事故的温床。

问：外包人员怎么进编制表？ 按闸口管理而非按人管理。外包伙伴可以负责 R（执行），但每个闸口的 A 必须留在内部——尤其是发布放行与生产数据访问两道。对外包的走查标准与内部一视同仁，反而能减少双方的返工；放松标准换来的"配合愉快"，账单会在上线夜送到。

问：架构师是不是一定要最资深的工程师担任？ 资深是必要条件之一，但"沟通翻译能力"常被低估。架构师每天在做的事，是把业务语言翻译成结构约束、再把技术约束翻译回业务代价——一个只会画图讲不清取舍的架构师，图纸再漂亮也会在执行中走样。选人时不妨问一个实测问题："给一个非技术的仓库主管讲清楚为什么这个功能要推迟两周"，讲得让对方点头，比多会三种框架更接近岗位本质。

本节要点回顾

• 角色收敛为七类：项目经理、产品经理、架构师、开发、测试、运维、QA，另有 UX 与业务专家供输入。
• 角色可以兼任，闸口必须实名：每道关口有且只有一个担责人（A）。
• RACI 用于钉死职责边界，典型用法是把"发布放行"这类高危事项提前写清。
• 三大反模式：自测自检、调度遥控驾驶、安检归车队管。
• 编制表的价值在争议裁决时兑现，平时谁也不看它不要紧，出事时必须答得出"该谁拍板"。

至此本章把车站的全景铺开：危机为什么发生、工程要守住什么、岗位怎么分。下一章我们进入运行图——同一套岗位，按哪几种时刻表发车。