软件开发流程关键岗位职责定义：按交付物切分与准入准出设计

1. 为什么一个二十人的团队也需要把岗位职责写清楚我带过几个规模不大的研发团队最头疼的从来不是技术难题而是“这件事到底该谁拍板”。需求文档谁写、接口谁来定、上线前谁签字、出了问题谁先顶上——这些看起来是常识的东西一旦团队超过十个人就会开始互相踢皮球。软件开发流程关键岗位职责定义这件事说白了就是把“谁在什么时候对什么负责”提前谈明白让流程跑起来的时候不需要每次都靠吼。我见过太多团队是这么干的老板拉了个群产品、开发、测试、运维全在里面需求丢进群就算交接完成代码合并靠喊测试报告靠截图上线靠运气。团队小的时候勉强能转人一多、项目一复杂立刻原形毕露。所以标题里这个“关键岗位职责定义”本质上是给开发流程建立一套责任坐标系——不是画组织架构图而是定义在流程的每个关键节点上哪个角色必须提供输入、哪个角色必须做出决策、哪个角色必须留下可追溯的记录。它的价值在于三点第一减少沟通成本新人进来照着职责表就能知道找谁对接第二降低交付风险避免关键环节没人兜底第三让复盘有据可依出了问题能定位到是流程缺失还是人没做到。适合谁看我建议三类人重点读刚从小团队转到大团队的技术负责人、正在搭建研发流程的初创公司骨干、以及准备跳槽到流程规范公司的中高级工程师。哪怕你现在只有五个人提前把职责定义想清楚后面扩到五十人的时候会省下无数扯皮的时间。2. 软件开发流程关键岗位的整体设计与分工逻辑2.1 岗位划分的底层原则按交付物切不按人头切很多团队一开始就走偏了按照“谁有空谁干”来分工结果职责表写了一堆名字流程还是乱的。我的经验是岗位职责要按交付物来切而不是按人切。所谓交付物就是流程往下走的“准入凭证”——没有这个东西下一个环节就不能开始。这样一来职责定义就有了锚点谁负责产出这个交付物谁就对这个环节的质量负责。举个例子需求评审要进入开发准入凭证是一份经过确认的需求清单包含验收标准和优先级。那么产出这份清单的角色就是产品经理或需求分析师他必须对清单的完整性和可执行性负责。开发要做技术方案评审准入凭证是设计文档和接口定义产出者是技术负责人或架构师。测试要开始执行准入凭证是提测版本加冒烟测试通过记录产出者是开发。上线要执行准入凭证是测试报告加回滚方案产出者分别是测试和运维。这样一条线拉下来每个岗位的职责就不再是模糊的描述而是明确的“我交什么、你接什么”。这么做还有个隐藏好处当某个环节反复出问题时你能快速发现是交付物定义不清还是产出者能力不足而不是笼统地骂“流程有问题”。流程从来不会自己有问题有问题的是人没有履行定义好的职责或者定义本身就不合理。按交付物切分就是把这两类问题分开来处理。2.2 常见角色矩阵与协作边界一个典型的软件开发流程通常需要六到八个关键角色。我先把它们列出来再讲边界怎么划。产品经理负责需求源头和优先级需求分析师负责把业务语言翻译成可开发的需求规格技术负责人或架构师负责技术方案和关键技术决策开发工程师负责编码实现和单元测试测试工程师负责质量验证和缺陷管理运维或SRE负责环境、部署和线上稳定性项目经理或研发管理者负责节奏、资源和风险。规模小的团队可以一人多岗但角色本身不能省因为省掉某个角色的后果不是“少个人干活”而是“某个交付物没人产出”。协作边界是最容易出问题的地方。我列一个表把这几个角色最常见的争议点摆清楚争议事项建议归属理由需求优先级调整产品经理决策项目经理同步产品对业务价值负责项目经理对节奏影响负责接口定义变更技术负责人审批涉及多模块影响评估需要全局视角提测标准是否达标测试工程师判定质量门禁不能由开发自己说了算线上回滚决策运维或SRE主导技术负责人确认稳定性优先但需评估业务影响缺陷是否可延期修复产品经理与测试共同评估一个管业务影响一个管质量风险发布窗口安排项目经理协调运维执行需要平衡业务节奏和技术准备度这张表不是标准答案但它代表了一种思路每个争议点都要有明确的最终决策人而不是“大家一起商量”。商量在信息收集阶段是好的在决策阶段是灾难。我见过一个团队因为“接口改不改”讨论了三个小时最后谁也没拍板开发各自按自己的理解写了联调的时候发现两边根本对不上。如果当时有个技术负责人说一句“按这个版本定下周再评估优化”这三个小时就省下来了。2.3 流程节点的准入准出设计职责定义清楚之后还要把它挂到流程节点上否则就是悬空的。我习惯用准入准出条件来固化职责每个关键节点都写清楚“满足什么条件才能进入”和“满足什么条件才能离开”。准入条件由上一环节的产出者负责准出条件由本环节的负责角色确认。需求阶段准入是业务目标已经明确准出是需求清单经过评审且验收标准可测量。设计阶段准入是需求清单已冻结准出是技术方案通过评审且接口文档完成。开发阶段准入是方案和接口无异议准出是代码通过review且单元测试覆盖率达标。测试阶段准入是冒烟测试通过准出是遗留缺陷达到发布标准。发布阶段准入是测试报告和回滚方案齐备准出是线上监控指标正常。这些条件写在纸上的时候很多人觉得是形式主义。但真正跑过几个迭代就会发现凡是准出条件没满足就硬往下推的后面都要加倍还回来。最典型的就是单元测试没写完就提测测试环境一跑全是低级错误测试工程师一天里三个小时在帮开发做冒烟真正的问题反而没时间深挖。把准出条件和职责绑定就是给每个角色一个明确的“我没做完后面就不能动”的依据而不是靠个人面子去推。3. 每个关键岗位到底要产出什么、守住什么3.1 产品与需求侧把“要做什么”变成“能验收什么”产品和需求这两个角色很多人混着用但在职责定义里最好分开。产品经理对“为什么做”和“做多大”负责需求分析师对“做成什么样”和“怎么验收”负责。小团队可以一人兼任但在职责表上要写清楚这两层责任否则很容易出现需求写了一堆验收标准一个都没有的情况。产品经理的核心产出是需求池和优先级排序他需要持续回答三个问题这个需求解决谁的什么问题、不做会怎样、做了之后怎么衡量效果。这三个问题答不上来的需求不应该进入开发流程。需求分析师的核心产出是需求规格说明包含功能描述、边界条件、异常流程、验收标准。我特别强调异常流程因为开发过程中最容易扯皮的就是“这种情况怎么办”如果需求阶段没写清楚开发按自己的理解处理了测试又按自己的理解验证了最后吵起来谁也不服谁。注意需求评审不是走过场。我要求每个需求在进入开发前必须有一个测试工程师能复述出来的验收标准。测试复述不出来说明需求没写清楚打回去重写而不是让开发硬着头皮开始。这里有个实操心得验收标准尽量用“给定—当—则”的结构写。给定用户已登录且购物车有商品当用户点击结算且余额不足则系统提示余额不足并引导充值。这种写法让开发和测试对同一个场景的理解完全一致减少大量口头确认。需求分析师不需要写代码但必须懂业务语言的翻译能把“用户觉得快一点”翻译成“列表加载时间在两秒以内”。3.2 技术与架构侧对方案负责而不是对代码行数负责技术负责人或架构师这个角色在职责表上最容易被写成“负责技术方案”但具体负责什么往往很模糊。我的定义是他对技术决策的长期后果负责。短期能跑通但半年后维护成本爆炸的方案他有责任说不。这就意味着他在流程中的核心动作是设计评审和关键技术决策而不是埋头写业务代码。具体产出上技术负责人需要提供技术方案文档、接口定义、关键技术选型说明、风险评估。技术方案不要求写得多长但必须回答几个问题这个功能怎么拆、模块之间怎么交互、数据怎么流转、异常怎么处理、性能预期是多少。接口定义尤其重要它是前后端、模块之间协作的契约一旦定下来就要走变更流程不能今天改一个字段明天换一个返回结构。架构师在大型项目里还需要做跨系统的方案协调这时候他的职责边界是“确保各子系统方案之间不冲突”而不是替每个子系统做决策。我见过架构师把所有设计都抓在自己手里结果自己成了瓶颈团队等他评审等一周他还觉得是团队效率低。好的做法是定框架和边界具体模块的方案由模块负责人定架构师只评审跨模块和跨系统的部分。提示技术方案评审的目的不是证明方案完美而是暴露假设和风险。我习惯让方案作者主动说出“这个方案最可能出问题的地方”说不出来的评审不通过。3.3 开发侧交付可运行、可测试、可维护的代码开发工程师的职责在很多人眼里就是“写代码”但这三个字太笼统了。我把它拆成四件事按接口定义实现功能、写单元测试、参与代码review、维护自己负责模块的文档。按接口定义实现功能是底线但现实里经常有人觉得接口设计得不合理就自己改掉改完也不通知前端联调的时候才发现对不上。所以职责里要明确接口变更必须走流程不能私自改。写单元测试这件事争议最大。很多开发觉得单元测试是额外负担写业务代码已经够累了。但从流程角度看单元测试是开发对“我的代码在隔离环境下是正确”的承诺没有这个承诺测试工程师拿到的就是一堆黑盒任何一个小改动都要全量回归成本成倍上升。我不要求百分之百覆盖率但核心逻辑和边界条件必须有测试这是提测的准出条件之一。代码review的职责也要写清楚不然就是“有空就看看”。我的做法是每个合并请求至少一个非作者的开发review涉及公共模块的必须有技术负责人参与。review的重点不是代码风格而是逻辑正确性、边界处理、安全风险和可维护性。风格问题交给自动化工具人只看机器看不出来的东西。开发还需要维护模块文档至少包括模块职责、对外接口、依赖关系、已知限制。文档不要求漂亮但要能让人在三个月后看懂这段代码是干什么的。3.4 测试侧质量门禁的执行者不是背锅侠测试工程师的职责边界不清是团队里最常见的内耗来源。很多人把测试当成“找bug的人”上线出问题就怪测试没测到。我的定义是测试是质量门禁的执行者他负责判断当前版本是否达到发布标准并对这个判断负责。注意是对“判断”负责不是对“所有bug”负责。代码是开发写的缺陷是开发引入的测试的价值在于尽早发现和准确评估。测试的核心产出包括测试计划、测试用例、缺陷报告、测试报告。测试计划要说明测试范围、策略、资源、风险不是所有功能都要穷举要根据风险等级分配精力。测试用例要覆盖正常流程、异常流程、边界条件并且要能追溯到需求否则需求改了测试没跟上就出现漏测。缺陷报告要可复现、有环境信息、有日志或截图不能只写一句“点不了”。测试报告要给出明确的发布建议是建议发布、有条件发布还是不建议发布。注意测试报告的结论必须是明确的。我见过测试报告写“发现若干问题具体情况见缺陷列表”然后项目经理不知道该不该上线。这不是测试的问题是职责定义里没要求测试给出明确结论。测试还有一个容易被忽略的职责参与需求评审和设计评审。很多缺陷在需求阶段就能发现测试如果等到提测才介入就只能在后面被动救火。我要求测试工程师在需求评审时就提出“这个需求怎么验证”的问题在设计评审时提出“这个设计怎么构造测试数据”的问题。前期多花两小时后期省两天。3.5 运维与SRE侧把“能上线”变成“能稳定运行”运维或SRE的职责在开发流程里的位置越来越靠前。以前是开发写完、测试测完丢给运维上线现在是运维从设计阶段就参与评估部署方案、监控指标、容量规划、回滚策略。这个变化的逻辑很简单线上稳定性不是上线那一刻决定的是设计和开发阶段就埋下伏笔的。运维的核心产出包括部署方案、监控配置、回滚预案、上线检查清单。部署方案要说明部署架构、依赖服务、配置项、数据库变更。数据库变更是线上事故的高发区必须有单独的评审和回滚脚本。监控配置要覆盖关键业务指标、系统指标、日志告警不能等用户投诉了才发现服务挂了。回滚预案要明确回滚条件、回滚步骤、回滚后的验证方法而且要在测试环境演练过。上线检查清单是运维的看家本领我列几个必查项新版本的健康检查接口是否正常、数据库变更是否执行、配置是否生效、依赖服务是否可达、日志是否有异常、监控是否无告警。每一项都要有人确认不能靠“应该没问题”。上线后至少观察一个业务周期比如电商大促要观察完整的高峰时段不能上线十分钟没报错就说成功。3.6 项目管理层让流程跑起来而不是让流程写在纸上项目经理或研发管理者的职责是保证整个流程按定义运转并在出现偏差时及时纠正。这个角色最容易犯两个错误一是过度干预技术决策二是只做进度催收不做风险预警。好的项目经理核心动作是组织评审、跟踪交付物、暴露风险、协调资源而不是替各个角色做决定。项目经理的核心产出包括迭代计划、风险登记表、交付物跟踪表、复盘报告。迭代计划要明确每个迭代的目标和范围以及各角色的交付时间点。风险登记表要持续更新把技术风险、需求风险、资源风险、依赖风险都列出来标注概率和影响并指定责任人。交付物跟踪表就是前面说的准入准出条件的具体落地每个节点是否满足条件谁确认的都要有记录。复盘报告要基于事实和数据而不是感觉讨论改进项时要有明确的责任人和完成时间。我在实际带团队的时候会要求项目经理在每个迭代开始前把“这个迭代最可能出问题的地方”写出来中期检查一次结束后对照复盘。这么做最大的好处是团队逐渐养成风险意识而不是每次出问题都归因于“运气不好”。流程管理不是加表格加会议而是让每个人都知道自己在什么时候该交什么、交不出来会有什么后果。4. 把职责定义落到流程里的完整实操4.1 从零梳理职责的五个步骤如果你现在手上有个团队流程挺乱想从头梳理岗位职责我建议按这五步走别一上来就写文档。第一步画出当前的真实流程。不是理想流程是实际怎么跑的。找个白板把从需求到上线的每个环节写下来标注每个环节的实际负责人和实际产出物。你会发现很多环节的产出物是“口头确认”或者“微信群消息”这就是问题所在。第二步识别关键节点和缺失交付物。关键节点通常是那些“卡住就全停”的地方比如需求冻结、接口定稿、提测、发布。缺失交付物就是那些本该有但没有的比如验收标准、回滚方案、测试报告。第三步给每个交付物指定唯一责任人。注意是唯一不是“产品和技术一起负责”。一起负责等于没人负责。责任人可以是某个岗位也可以是某个具体的人但在流程定义里写岗位在迭代执行里写具体人。第四步定义每个节点的准入准出条件。条件要可验证不能是“需求写好了”这种主观判断而是“需求清单包含验收标准且测试工程师确认可测”。可验证的条件才能执行不可验证的条件只能靠自觉。第五步跑一个迭代试运行然后复盘调整。职责定义不是一次写完美的是在实际运行中磨出来的。第一个迭代肯定会有人觉得不习惯觉得多了很多“不必要的步骤”这时候要坚持因为流程的价值恰恰体现在那些你觉得不必要的步骤上。4.2 职责落地的配套机制光有职责表不够还要有配套机制让它活起来。我用的最有效的三个机制是交付物检查清单、评审记录模板、变更控制流程。交付物检查清单是每个节点的具体检查项比如提测检查清单包括单元测试是否通过、代码是否review、接口文档是否更新、冒烟测试是否通过、变更说明是否填写。检查清单由交付者自查然后由接收者确认。自查是为了减少低级错误接收者确认是为了明确质量门禁。评审记录模板是为了让评审有输出。模板包括评审时间、参与人、评审对象、提出的问题和结论、遗留事项和责任人。很多团队的评审开完就完了问题和结论都没记录过两周没人记得当时说了什么。有了模板评审就变成了可追溯的决策过程。变更控制流程是为了防止中途乱改。需求变更、接口变更、方案变更、发布范围变更都要走这个流程。流程核心是三件事变更内容是什么、影响哪些模块和角色、谁批准。小的变更可以由对应角色批准大的变更必须升级到技术负责人和项目经理。我见过团队因为一个接口字段改了没走流程导致前端、后端、测试三方理解不一致多花了两天返工。配套机制解决的问题关键要求交付物检查清单低级错误漏到下一环节检查项可验证接收者确认签字评审记录模板评审结论无追溯问题、结论、遗留事项都有责任人变更控制流程中途变更导致返工评估影响、明确批准人、通知所有相关方4.3 不同规模团队的职责裁剪方案职责定义不是一成不变的要随团队规模调整。我按三个规模段给出裁剪建议。五到十人的团队角色可以合并但不能缺失。产品经理和需求分析师可以由一个人做但需求规格和验收标准不能省。技术负责人和架构师可以合一但技术方案和接口定义不能省。测试必须有人哪怕是兼职提测准出条件不能省。运维可以由开发兼但部署方案和回滚预案不能省。项目经理可以由技术负责人兼但迭代计划和风险跟踪不能省。十到三十人的团队角色应该开始分开。产品和需求分开技术和架构分开开发和测试分开运维单独设岗或至少有人专职负责。项目经理需要有专人或者由研发管理者承担。这个阶段最重要的是明确接口产品给需求技术给方案测试给报告运维给环境项目经理协调节奏。接口不清就会开始出现“我以为他会做”的问题。三十人以上的团队角色进一步细分比如测试分功能测试和自动化测试运维分应用运维和基础运维技术分业务架构和基础架构。但不管怎么分每个交付物的唯一责任人原则不能变。规模大的团队最容易出现的病是“职责过细导致协作成本上升”所以每个季度要复盘一次职责定义看哪些边界需要调整。我做过的项目里一次典型的调整是把“接口文档”的责任从开发转到技术负责人因为开发改接口太随意导致联调频繁出问题。4.4 一个真实场景的职责演练讲个具体场景把上面的东西串起来。假设要做一个用户积分兑换功能从需求到上线走一遍。产品经理提出需求用户可以用积分兑换优惠券。他产出需求池条目说明业务目标和优先级比如优先级高因为能提升复购。这一步的准入是业务方已经确认要做准出是需求分析师接手。需求分析师写需求规格积分规则、兑换限制、优惠券类型、有效期、异常处理。验收标准包括积分不足的提示、兑换失败的退回、并发兑换的防重。这一步的准出是测试和开发都确认需求可测可实现。技术负责人做方案积分扣减用数据库事务还是消息队列、优惠券发放怎么保证幂等、高并发下怎么防超卖。他产出设计文档和接口定义。这一步的准出是前端、后端、测试对接口无异议。开发和测试并行开发按接口实现写单元测试测试写测试用例准备测试数据。开发提测前自查检查清单测试收到提测后先跑冒烟。这一步的准出是冒烟通过且单元测试达标。测试执行功能测试、边界测试、并发测试。发现并发兑换有重复发放问题缺陷报告写明复现步骤和环境。开发修复后回归。测试报告结论有条件发布建议先小流量灰度。这一步的准出是遗留缺陷不影响核心流程。运维上线部署方案包括灰度策略、监控指标、回滚脚本。上线检查清单逐项确认。上线后监控兑换成功率、积分扣减准确性、系统响应时间。观察一个业务高峰后确认稳定全量放开。这个场景里每个角色都有明确的产出和准出条件。如果中间任何一步出问题很快就能定位到是谁的交付物没做好。比如并发兑换出问题是需求阶段没写并发要求还是设计阶段没考虑还是测试阶段没覆盖一查就知道。这就是职责定义的价值它不保证不出问题但保证出了问题能快速归因和修复。5. 职责定义执行中的常见坑与排查技巧5.1 职责推诿的四个典型信号职责定义写在纸上容易执行起来容易变形。我总结了四个推诿信号出现任何一个就要警惕。信号一会议上频繁出现“我以为你会做”。这说明某个交付物的责任人没写清楚或者写了但当事人不知道。解决办法是把交付物跟踪表贴在团队看板上每个节点谁负责一目了然。信号二问题反复出现在同一个环节。比如每次上线都出配置问题说明运维的配置检查职责没落实或者检查清单缺失。解决办法是把这个环节的检查项细化并指定确认人。信号三review和评审变成形式。大家点个头就过了没人提反对意见。这说明评审的准出条件没有约束力或者提问题的人没有得到正反馈。解决办法是让评审负责人主动要求提出风险并把提出有效风险纳入正向评价。信号四延期总是归因于“需求变更多”。如果每次延期都这么说很可能是变更控制流程没执行或者需求分析阶段没把边界谈清楚。解决办法是统计变更次数和影响范围看看是需求质量的问题还是变更管理的问题。提示职责推诿不是人的问题是定义的问题。当一个人说“这不是我的活”的时候先别急着批评态度先看看职责表里有没有写清楚这件事归谁。没写清楚就是管理者的责任。5.2 小团队最容易踩的三个坑小团队资源少职责定义更容易走形。我踩过的三个典型坑你可以对照看看。第一个坑是“全能选手”依赖。团队里有个什么都会的人需求、开发、测试、上线全包。短期效率极高长期风险极大。这个人一旦休假或者离职流程直接中断。我的建议是哪怕他能力再强也要在职责表里把他的多个角色分开写并且培养备份。至少要有人能接他的关键交付物。第二个坑是“跳过评审直接干”。小团队觉得评审浪费时间需求聊两句就开始写代码。结果是开发到一半发现方向不对返工的成本远高于评审的时间。我的经验是评审不一定要开会但交付物必须产出。需求规格可以是一页纸技术方案可以是几段话但不能没有。第三个坑是“测试靠开发自测”。没有专职测试的团队很容易把质量责任全压在开发身上。开发自己测自己的代码盲区很大。我的做法是即使没有专职测试也要指定一个“质量负责人”角色可以由开发轮流担任专门负责验收标准确认和发布前检查。轮换的好处是每个人都有质量视角不会觉得测试是别人的事。5.3 职责冲突的仲裁机制职责定义得再清楚也会有冲突。比如开发和测试对某个缺陷是否达标有分歧产品和项目经理对优先级有分歧。这时候需要一个仲裁机制不能靠嗓门大。我的仲裁机制分三层。第一层按职责定义里的决策人直接决定。比如提测标准由测试判定测试说没达标就是没达标开发可以申诉但不能直接跳过。第二层升级到共同上级或技术负责人。比如产品和项目经理对优先级有分歧升级到业务负责人由他对业务价值做最终判断。第三层复盘机制。如果同类冲突反复出现说明职责定义本身有问题要在复盘中调整。仲裁的关键是快。我见过团队为了一个缺陷是否阻塞发布讨论了三天最后上线延期。其实这个问题的本质是发布标准没定义清楚。如果提前定义好“核心流程缺陷必须修复非核心流程缺陷可以带病发布并记录”五分钟就能决定。所以仲裁机制的核心不是仲裁本身而是通过仲裁暴露定义缺失然后补齐定义。5.4 常见问题速查表问题现象最可能的原因排查动作解决方向联调时接口对不上接口变更没走流程查变更记录和接口文档版本建立接口变更审批和通知机制提测后大量低级bug开发单元测试和自查缺失检查提测检查清单执行情况把单元测试和冒烟作为准出硬条件上线后配置错误运维检查清单不完整核对上线检查项补充配置项核对和双人确认需求反复变更需求边界和验收标准不清统计变更次数和原因需求评审增加边界确认环节测试报告没有明确结论职责定义未要求结论检查测试报告模板模板强制填写发布建议问题反复出现在同一环节该环节准出条件未执行检查准出确认记录明确确认人并纳入考核团队成员不知道自己的职责定义未宣贯或未更新抽查职责表知晓度新人和迭代开始前必须宣贯这张表我建议每个团队根据自己的实际情况补充它是排查问题的起点不是终点。6. 我在实际带团队中沉淀的几条经验职责定义这件事我做了几年最大的体会是它不是一个文档工程而是一个共识工程。你写得多漂亮如果团队不认就是废纸。所以我在落地的时候特别注重让每个角色参与定义自己的职责而不是我写完发给大家。参与感带来认同感认同感带来执行力。另一个体会是职责定义要随着项目阶段调整。项目初期速度和灵活性优先职责可以粗一点但关键决策点不能少。项目稳定期质量和可维护性优先职责要细一点准出条件要严一点。我见过一个团队在项目紧急期也坚持全套评审和全量测试结果交付延期被业务方骂也见过团队在稳定期还按初期的方式跑技术债越积越多。所以职责定义不是死的要根据阶段动态调整。还有一点职责定义的落地必须靠工具不能靠记忆。我们用的项目管理工具里每个迭代的每个节点都有交付物字段和确认人字段不填不能流转到下一状态。工具不是为了监控人是为了让流程有痕迹。人在忙的时候最容易被跳过步骤工具的强制确认能有效减少这种跳过。最后分享一个我一直在用的小技巧每个迭代结束后让每个角色用一句话总结“这个迭代我最重要的交付物是什么有没有做到”。不用写报告就一句话在复盘会上说。坚持几个迭代每个人对自己职责的理解会越来越清晰流程也会跑得越来越顺。这比任何复杂的考核都管用因为它逼着每个人对自己的交付负责而不是对流程负责。