“明明定好的计划，怎么总是延期呢？”

项目经理小徐在项目例会上咆哮着。

“不怪我啊，开发交付的质量不行。测试根本没办法按照之前预估的工期工作。”

测试负责人小李摊手，表示自己也无能为力。

“需求文档写的不清不楚，我们开发只能按照自己的理解开发了”。

开发组长老孙也在抱怨，工期紧任务重。他认为能交付成这个样子已经很不错了。

产品经理临时有事没参加例会。

“额......”

断不完的“家长里短”

“清官难断家务事”。成年人的世界里，没有谁是容易的。往往一件事情没做好，原因有很多方面。这个时候突然发飙，除非你是老总，否则会议剩下的时间除了争吵就是沉没。

其实项目经理最怕这样的情况。所谓“法不责众”，你总不能将项目里所有的人都叫到会议室，看着你喷唾沫吧。你一通“操作”后，开发经理告诉你进度要延期一天（因为程序员看完喷涂抹表演后，心情都不好了。开发效率大大降低）。

那如何应对这种“万金油”一样的队友呢？你甭指望在项目里面突然出现这样一个人：拍着胸脯说，徐经理你放心，耽误的工期我们加班搞回来！（清醒一点吧）不直接面对客户的人，永远不会有这样的觉悟。

责任分摊

别以为进化了这么多年，其实现代人还是受原始人影响很大的。虽然承担责任算不上趋利避害，但承担责任会给生物体造成压力（古今中外很多的心理实验已经验证这一点）。原始人面对压力最最直接的反应肯定是逃避，现代人虽然做不出“逃跑”这种事儿，但心理上或者说潜意识层面，还是会选择“逃避”。

既然不指望Office Body们主动担责，就被动的把责任强加到他们身上吧！

首先，在流程的各环节上，明确指定唯一一位负责人。

就像课堂上老师点名回答问题一样，在没有具体点到谁回答之前，所有人都低着头。不幸的被点中的哪位，就只能站起来回答问题了。项目管理也是一样，如果一件事儿（比如需求定义）没有明确责任人或者责任人不是一个人，那这个需求肯定定义不好。要不很多部门的一把手都是一个人呢。

明确唯一负责人之后，那么在他负责的环节一旦出现任何问题，都指定他来解决。

否则“踢皮球”的现象会经常出现。

“额......这个事情我不清楚，你问问B吧”

“啊？这个事情不是我负责啊，应该是A吧。你去问问A”

然后，认定成果物是否达标的权限交给下游环节。

我是工科学校毕业的，在校期间我们有一个到工厂参观的机会。参观组装流水线的时候，每个工件在组装的时候质量规格都必须严格遵循设计的方案。出现一点差错或者不一致的地方，整个组装工作就要暂定。

项目管理也是同样的道理。

谁主要决定需求文档的质量？想象一下整个项目的人都在一条流水线上。产品组将原材料从源头输入，由传送带输送到开发组。开发组那个原材料后加工在放到传送带上交给测试组。测试组拿着产品验证质量后交给客户。

所以需求文档的质量需要由开发组的负责人判断：开发人员是否可以拿着这份需求文档开发。一旦开发组负责人认为文档的质量可以进入开发，那后续出现的任何关于“不清楚”的部分，就不可以再作为质量底的借口了。同样测试组长在启动全面测试之前，也要提前验证软件的质量。质量不达标，就不可以启动全面测试工作。（具体验证质量的方案，后续文章再详细介绍吧）

那么文章最开始的对话，可能会变成这样：

“明明定好的计划，怎么总是延期呢？”

项目经理小徐在项目例会上咆哮着。

“不怪我啊，开发交付的质量不行。测试根本没办法按照之前预估的工期工作。”

测试负责人小李摊手，表示自己也无能为力。

“开发在提交测试之后，你有进行必要的软件功能验证吗？质量不合格为什么要启动测试工作？”

“额......”

“需求文档写的不清不楚，我们开发只能按照自己的理解开发了”。

开发组长老孙也在抱怨，工期紧任务重。他认为能交付成这个样子已经很不错了。

“开发时明明已经遇到描述不清楚的地方，为什么没有及时与产品人员沟通？如果文档质量不合格，为什么没有在开发之前提出来呢？”

“额......”

别给项目内任何成员一个错误认知：“反正有项目经理呢。”很多时候，项目经理也无法承担这种不断延期的风险的。要让他们明白，所有人交付的成果物都是能用的，并且是经过下游人员认可的。

心法

以上情景过于理想，现实情况往往很复杂。但万变不离其宗，“明确唯一责任人并将责任分摊下去”。掌握此道，方能成事。同时也要不断的实践，实践后的理论才是真金。

另外还有一句口诀：“who do what by when”，百试百灵。下期再聊~~