项目延期并非无药可解，项目延期原因及应对之道

（一）项目延期有解药？

最后，项目延期是客观存在的事实，你会选择红药丸，还是蓝药丸？

摘要：当我们要考虑如何让项目不延期时，我们是否做到让每个员工都满负荷了？我们追求的是不延期，还是追求更卓越的产品？

这一两个星期和同事讨论如何使用看板进行项目管理时，总的来说，我遇到最频繁的问题有：

如何能看出项目是否延期？
如何拆任务？
其实，我遇到的问题是：如何能看出项目是否延期？然后经我将问题深挖，才发现他们更本质的问题是：拿到需求，如何拆任务，拆到什么粒度。

讨论这类问题，最好举个例子，否则整个讨论过程会很虚。

比如我们的项目经理从产品经理那里拿到一个需求：改版APP。这款APP有12个界面，所有的界面都需要改。而你手下有6个人。

这时，可以以两种粒度来拆分：

以界面为粒度
拆分成更可以量化的粒度。
关于什么是可以量化的粒度，下文会阐述。

按界面粒度来拆分



可以看出，以界面粒度来拆分，简单粗暴：24人天的任务，我们有6个人，所以，理论上我们只需要4天完成“改版APP”。我们可以很容易看出这个项目是否延期，只要每个界面都没有延期。

放到看板上，理所当然，每个界面一张卡。

现实中，我们的项目经理可能还会这样分到人头上：

为什么一定要分到人头上？除了方便KPI（表面上），背后还有一定的文化因素：因为当项目延期时，我们就可以找出那个相应的人进行问责。这种问责的机制导致的后果：人们更愿意推卸责任，而不是共同协作。

放大一些这个问题，公司内部多个技术部门也会因为这种问责的文化，导致部门之间更趋向责怪对方不按期，而不是共同协作完成一件事情。

再再放大一些这个问题：在人们的意识里往往认为，问责后，坏的事情就可以避免问题再发生。放到我们本篇文章讨论的上下文里，也就是问责可以避免延期。但是，可能吗？因为延期已经发生，我们应该在延期发生前进行协调资源来解决延期。

我们举个例子：在项目进行的过程中，人员B在做界面3，4时，在第3天时被一个问题卡住了。而人员C其实在第3天时就已经完成了，第4天开始优化。其他人准时完成了自己的任务。最后人员B的延期导致项目延期了2天。这时，如果你问责人员B，那么，这次的延期能倒退吗？也许你会说，问责后，这个人下次就不会延期了。

我想说：

延期不延期和你问责没有任何关系。如果有关系，你在项目开始时，就每个人问责一下，这样项目就不会延期了？
我们应该追求的是每个项目都不延期，而不是下一个项目不延期
我们追求的是不延期，还是追求更卓越的产品？
回头看这次延期，也许我们是可以避免的，比如在第3天的站会上，人员C说出自己被某个问题卡住了。这时，可能其他人员一句话就点通人员C的问题了。还有可能是人员C遇到的问题是需要其它部门来协助才能根本解决，这时项目经理就需要与其它部门沟通了。

回到问题“按界面粒度来拆分任务”这个问题本身。

将界面再拆分成可量化的粒度



这种方式要我们的项目经理拿到需求后，让最熟悉这个APP的人或团队对需求再进行拆分成一系列工作单元，然后再分别估算这些工作单元在现有的人员基础上需要多少天。最后估算出一个总的交付时间点。我们假设完成这个需求，我们同样需要4天完成。

至于拆分到什么程度，就是我们上文提到的可量化的程度。

什么叫可量化？

上面我们看到将需求拆分成一系列工作单元后，我们可以更灵活的安排优先级。同时，这样也帮助我们发现界面1和界面2有一个工作单元3是有交集的。有交集的工作单元，我们应该让同一个人来完成以避免其中的沟通成本。总的来说，拆分成一系列可量化的工作单元后，我们可以：

更灵活的优先级调控
发现有交集的工作单元，也就能发现可减少沟通成本的空间。
但是，什么样的工作单元叫可量化？

代码行数是最简单的，估计完成APP改版需要写10万行代码。一个工作单元，我们定1万行？这种工作单元是可以量化，但是写完那么多行代码，你就是完成APP改版这个任务了？

我们举个例子来说明什么样的工作单元叫可量化，比如对于界面1，我们需要：

把“完成”按钮的颜色从绿色改成蓝色
当完成值为100时，不显示100，显示成“恭喜，已完成”
缓存从服务器获得的任务完成值，对于多次操作，只向服务器请求一次，以提升用户操作的流畅感
从这个例子，我们可以看出，每个工作单元都应该是：

准确的：将绿色改成蓝色，而不是红色
不可分割的：不显示100，显示成“恭喜，已完成”，这个工作单元，你不能再分割了
体现了业务含义：代码行数并不能体现业务含义，但是提升用户操作的流畅感有业务含义的。
可量化的工作单元、站会与看板

有了可量化的工作单元后，再结合站会和看板，这样，我们每天都可以知道（可视化）团队的工作状态了。延不延期，大家都可以看得到，大家都是成年人了：

谁做得快，谁捡更多的卡来做的。而且可以捡优先更高的卡先做，也降低延期的风险。我们可以从这个过程中识别人才。
站会的第3天，人员B还在做_#3_卡，我们其他成员可以加快速度做其它卡以弥补人员B的慢速度，同时项目经理也可以更早的介入这个可能延期的卡中帮助人员B
当出现质量问题时，人员D的卡会被打回Todo多次，因为有站会，我们所有人都很感觉到_#5_这张卡可能存在一定难度或者人员D在协作方式存在问题，这时，我们其他人就会主动帮助人员D解决问题，而不是责怪他。


慢慢地，团队的协作方式变得以解决问题为导向，而不是以问责为导向。

拆分成可量化的工作单元，一样会延期

但是，我个人的经验看来即使我们将需求拆分成可量化的工作单元，项目一样可能会延期。

看板只能帮助我们更可视化，更容易地了解到项目当前的状态，对于这个状态，我们的项目经理要如何反应，完成是个人问题了。

同时，看板也能帮助我们找到延期的根本原因，比如是某个人的卡在In Progress上拖了很长时间、某个人请假了、其它部门中间改需求了、项目人员在某项技术的能力问题……

所以，要延期的项目一定会延期，我们应该正确面对，找到原因并根本解决。我们要做的只是保证每个人每个工作日都是满负荷的。

这里，留给大家一个思考题：如果其它外部条件不变，每个人每个工作日都是满负荷了？如何不延期？

拆成可量化的工作单元会增加项目经理的工作量？

然而，又会有人说了，这么多项目，我每个项目都要拆分成可量化的，我们项目经理会增加很多工作量。

其实，如果真的有作用了，这些工作量是值得的，只要你真的理解可量化工作单元的作用。同时，当出现多个项目时，你忙不过来时，说明现在是你培养另一个项目经理的时机了。你可以尝试将一些项目管理的工作交给团队成员来完成。但前提是项目经理本身也是超负荷工作，影响正常工作了。

小结

想让项目不延期，我们首先关注的是如何将需求拆分成可量化的工作单元，然后想办法保证这些工作单元真正被有效的执行。办法通常可以有：

使用看板可视化所有的工作单元
通过站会了解工作单元执行过程可能的风险
通过协作来取长补短
通过优先级来降低延期时的风险
通过打包有交集的工作单元减少沟通成本
通过以上方法可以将团队“调”到可能的最优状态。但是如果还是延期，原因可能就不在团队了。

（二）项目延期原因及应对之道

每个项目经理都希望能有效地控制项目进度。但这件看似简单的事情，实际操作起来却常常不尽如人意。即使在成熟的大公司里，有着完善的项目管理流程，配备着一流的团队，项目延期事件还是频频发生。这里分析主要的三个原因。

常见的原因之计划不清

很多项目经理，计划做得很漂亮，却总是计划赶不上变化。原因 在于，有些时候，按工作量预估的发布日期却得不到领导的同意，领导有时会说我们现在就是和时间赛跑，这个项目必须在某某时间发布。这将致使计划推倒重来，一切都要赶进度。而对于其他团队成员来说，这份计划没有同他们商量，无异于强压任务。项目还没开始，抱怨声就不绝于耳。因此，项目工具选得好、任务划分细 致清楚只是做好计划的基础，更重要的是项目计划要得领导和团队成员的认同，并愿意为之全力以赴。

总之，想做好项目计划，要做好以下三点。

项目计划前，先和产品经理、上级领导沟通好，确定这个项目的轻重缓急。
团队成员要达成一致意见，项目经理不可独断专行。
项目计划要细化到天、功能点要责任到人、确定里程碑点。
常见的原因之需求问题

需求中的功能点要在PRD（产品需求文档）中罗列清楚，业务流程要写得完整清晰，交互细节要体现在视觉稿中。要组织项目组所有成员参加PRD评审，评审时要 针对具体的问题，给出明确的处理意见。暂时不能确认的问题，问题跟进人要在限定时间内给出反馈，项目经理可以制定问题跟进表格。

项目进行中 的需求变更，尽量在前期提出。在项目管理的过程中，当前期的需求和计划都确定后，项目经理不能只顾着跟进开发和测试的进度，也要阶段性地和需求方多沟通， 让他们及时反馈意见。不要等到临发布时，产品经理跑过来说“我要的不是这样的，这里要改一下”。永远不要把问题留到最后一分钟，要超前一步，留有余地。下 面是一个真实的案例。

案例情景：该项目的整个周期为2个月，有3轮功能测试。当第3轮功能测试结束时，也就是即将进入预发布阶段时，产品经理才给出用户反馈并要求按用户的反馈修改。改动的地方涉及到页面的样式、文案、SQL语句和校验逻辑等，总共可能有20多个文件要被改动。

项目经理建议只改页面的样式和文案，其他部分先不要改，等下次升级维护时再改，否则可能会影响发布。而在多次交涉无果的情况下，开发人员只能硬着头皮修改，测试人员只能再重新测一轮。虽然大家努力地按需求方的要求做了，但项目延期已不可避免了。

常见的原因之沟通不畅

为某项目临时组建的团队往往来自不同部门，团队成员之间不熟悉，此时，要为团队建立一个沟通通道，确保沟通顺畅。常用方式为：

建立一个内部网络空间，所有文档资源统一存放，供团队成员共享；
利用即时聊天工具，建立一个项目群，每天通报项目进度；
建立项目邮件组，所有变更达成一致后，发送邮件确认；
每天要开15分钟晨会，每周一次周会，每周发送项目周报；
跨团队项目，最好申请独立的项目室，所有项目组成员坐在一起工作，降低沟通成本。

（三）案例：项目经理如何面对项目延期？

我们公司准备开发一个软件产品。在项目开始的第一个月，项目团队给出了一个非正式的、粗略的进度计划，估计产品开发周期为 12~18 个月。一个月以后，产品需求已经写完并得到 了批准， 项目经理制定了一个 12 个月期限的进度表。
因为这个项目与以前的一个项目类似，项目经理为了让技术人员去做一些“真正的”工作（设计、开发等），在制定计划时就没让 技术人员参加，自己编写了详细进度表并交付审核。每个人都相当乐观，都知道这是公司很 重要的一个项目。然而没有一个人重视这个进度表。
公司要求尽早交付客户产品的两个理由 是：1）为下一个财年获得收入；2）有利于确保让主要客户选择这个产品而不是竞争对手的 产品。团队中没有人对尽快交付产品产生怀疑。 在项目开发阶段，许多技术人员认为计划安排的太紧，没考虑节假日，新员工需要熟悉 和学习的时间也没有考虑进去，计划是按最高水平的人员的进度安排的。除此之外，项目成 员也提出了其他一些问题，但基本都没有得到相应的重视。
为了缓解技术人员的抱怨，计划者将进度表中的计划工期延长了两周。虽然这不能完全 满足技术人员的需求，但这还是必要的，在一定程度上减少了技术人员的工作压力。技术主 管经常说：产品总是到非做不可时才做，所以才会有现在这样一大堆要做的事情。计划编制者抱怨说：项目中出现的问题都是由于技术主管人员没有更多的商业头脑造成 的，他们没有意识到为了把业务做大，需要承担比较大的风险，技术人员不懂得做生意，我 们不得不促使整个组织去完成这个进度。在项目实施过程中，这些争论一直很多，几乎没有一次能达成一致意见。商业目标与技 术目标总是不能达成一致。为了项目进度，项目的规格说明书被匆匆赶写出来。但提交评审 时，意见很多，因为很不完善，但为了赶进度，也只好接受。在原来的进度表中有对设计进行修改的时间，但因前期分析阶段拖了进度，即使是加班 加点工作，进度也很缓慢。这之后的编码、测试计划和交付物也因为不断修改规格说明书而 不断进行修改和造成返工。12个月过去了，测试工作的实际进度比计划进度落后了6 周，为了赶进度，人们将单 元测试与集成测试同步进行。但麻烦接踵而来， 由于开发小组与测试小组同时对代码进行测试两个组都会发现错误，但是对测试人员发现的错误响应很迟缓， 开发人员正忙于完成自己 的工作。为了解决这个问题，项目经理命令开发人员优先解决测试组提出的问题，而项目经 理也强调测试的重要性，但最终的代码中还是问题很多。现在进度已经拖后 10 周，开发人员加班过度，经过如此长的加班时间，大家都很疲惫，也很灰心和急躁，工作还没有结束，如果按照目前的进度方式继续的话，整个项目将比原计 划拖延 4 个月的时间。
案例问题：
1． 在本案例中，我们能吸取什么教训吗？
2． 编制计划时，邀请项目组成员参与有哪些好处？
3． 学习曲线对软件项目有哪些影响？
4． 编制进度计划时需要考虑哪些重要因素？
5． 一个成功的项目管理其基础是什么？