项目管理：问题探讨与解决方案

虽然在项目开发前期，我们已经做好准备工作，一个环节到一个环节有条不紊地执行，但不可否认，在这个过程中，难免会出现需求变更的情况。作为项目负责人，应该怎么去处理这件事呢？ 项目遇到需求变更，通常都是新增需求，很少是减少需求的变更。简而言之，就是增加了工作量。而项目负责人面临的难题在于：如何在不影响整体计划的前提下，高效应对这种变化。需求变更的规模有大有小，不可一概而论。如果是小的变更，那无伤大雅，适当微调即可。但倘若是很大的变更，比如新增的功能开发需要一两周甚至更长时间，那么整个项目计划可能就需要推倒重做，这无可厚非。 我们要探讨的是介于这大小之间的需求变更——那些有机会在当前计划里解决掉的需求，比如增加了一周的工作量。你有信心能按当前制定的计划如期交付吗？现在的情况是，我们可能只是将需求变更分为大小两个情况：小的微调，大的立刻调整项目计划，然后项目上线时间就会变更。久而久之，这种处理方式可能会让人觉得理所当然。 事实上，大部分项目开发工作是有协商空间的，并未被完全限定死。遇到突发情况，比如客户需求变更，但交付时间没有任何商量余地时，项目负责人该怎么办？有人可能会说加班，但有时加班未必能解决问题。 也许现在我们可以慢慢培养这方面的意识和能力，在平时多积累这方面的经验，避免真正遇到事情时手忙脚乱、无从下手。也就是说，我们可以将需求变更分为三种情况：小的变更，微调即可；大的变更，比如需要增加两周工作量，那就变更项目计划；中等变更，比如需要增加一周工作量，我们先不急于调整计划 ，而是先想一想：有没有什么办法可以在不变更计划的情况下解决这个问题？然后将各种可能的解决方案列出来（1、2、3……），召集项目其他成员一起讨论。也许经过多轮讨论，我们就能找到解决方案。如果讨论后仍无法解决，再根据实际情况变更项目计划。

在项目开发过程中，我们常常会遇到一些任务需要多人共同负责的情况。例如，某个功能任务需要前后端同步开发，如果把前后端的开发人员都归到同一条任务上，就会出现一些问题。 举个例子，设备管理模块的开发需要张三负责后端，李四负责前端。如果将他们的任务写在一起，当前进度显示为60%，我们无法直接了解具体情况。这个60%可能意味着后端已完成，只是前端还在开发；也可能是后端和前端都还未完成。这样一来，项目负责人就不得不去沟通询问，才能知道真实情况，这无疑降低了工作效率。 因此，项目开发计划里的任务最好是一人一条，拆分清晰。这样做的好处有两个：一是可以明确职责，避免出现责任不清的情况；二是任务状态会更加透明，项目负责人能够一目了然地掌握每个环节的进展，从而减少管理难度。 如下图所示，当任务拆分清晰后，我们可以立刻知道设备管理功能模块的后端开发进度为100%，已经完成，而前端开发进度为20%。这样一来，项目负责人就能根据这些信息及时调整计划，合理安排后续工作，确保项目顺利推进。

项目中有时会有一些任务的时间是不可控的，不可控的原因在于该工作完全受制于他人。意思就是如果其他人没有做好，比如前后端同步开发，前端通常可能会快一些，然后要等后端提供接口，这个时候联调工作是没办法开展的，也不知道什么时候可以，自己就会很被动，走走停停，既浪费时间精力，也容易没有任何产出。这种通常是其他人还没做好的情况，最怕的是那一种，比如设备那边说已经很OK了，现在可以开发了，然后去试用了，发现还是不行，然后一下子不知道该干嘛了，也不知道什么时候可以改好，等的话可能要很久，就浪费时间了，不等的话可能一下子就修复好可用了，自己完全处于左右为难的状态。 之前有APP项目就是这样的情况，本来APP功能已经开发好了，然后测试阶段，设备经常出现问题，可以用但是又不稳定，经常测到一半就测不下去了，然后反馈给到设备那边，改了好几次，觉得可以了，又继续测试了，后来还是不行。反复多次我才醒悟苗头不对，不能再这样下去了，立马中止项目测试，和设备那边沟通，设备需要确保完全没有问题，再继续这个项目的工作，可以说是血的教训。 这个问题之所以会造成那么大的影响，是因为我们在和他人协作的时候，没有和对方明确一个具体的时间节点，而是很含糊地回答道：“等某某完成了我才可以对接”，然后再问一句：“那他什么时候可以做完呢？过几天吧”，到底是几天？哪一天的？不知道呢。这样是有隐患的，因为这些模糊的信息，负责对接的开发同事完全就是看天吃饭了，任何结果完全是随机的。过几天，可能是一天，也可能是两天，甚至是一周或者更多，再者，项目负责人调整项目任务的时间也会变得很困难。 我们需要和对方明确一个具体的时间节点，比如前端同事需要问下后端的同事，接口是哪一天可以提供使用，而这个使用的意思，基本上是自测过的，不说一个Bug都没有，至少是相对稳定的。我们知道这个具体的时间节点之后，就可以先安排其他事情了，项目开发工作的开展就会很清晰，而不是完全混乱的。

在项目当前版本的功能开发任务都完成之后，人就空出来了，通常这个时候，项目负责人还有很多繁琐的工作要做，比如项目内部验收、提交测试申请和版本发布等等。为了给项目成员找事情做，就匆匆忙忙安排下个版本的任务，然后项目成员只是简单了解下需求，就开始敲代码了。前期的需求分析、方案设计、开发计划，项目负责人是没有时间系统地去梳理的，这就容易造成项目成员在新功能开发过程中，需求理解有偏差，加上当前版本发布时间节点不明确，目标感也不强。 项目负责人的开发任务应比项目成员提前3天左右时间结束，这个时候项目的其他功能还在继续开发，项目负责人可以借机着手准备下个阶段的任务（之所以是下个阶段，而不是下个版本，是因为有可能不是迭代这个项目了），将需求进行梳理分析，编写方案设计和制定开发计划，等到其他项目成员开发任务完成之后，就接着下个阶段的任务进行，项目负责人这时再回到当前项目，去做内部验收和提交测试申请，整个衔接是很清晰顺畅，不至于那么被动，捉襟见肘。

我们在制定项目计划的时候，如果只是把功能开发部分列出来，如下图所示： 可能会造成项目延期，在上一篇文章《05-项目为什么总是延期》中已经分析过了，这里就不再赘述了，我们现在要探讨的是，如何制定一个项目计划呢？ 在开始项目计划制定之前，可以先了解一下开发模式的相关知识，这部分主要是《【清华大学】项目管理的逻辑（全6讲）》里面的内容，有兴趣的可以去看一下，还是很不错的。 1. 瀑布式开发 预测型开发，在还没有开始着手编写代码前，就可以提前预知结果如何，之所以叫瀑布式，是因为整个开发流程都是有序的，就像水从上往下流，每一步做很到位就到下一阶段。 2. 迭代式开发 迭代式开发，顾名思义，就是一个版本接着一个版本进行迭代，先将项目整体框架搭建好，然后基础布局全部铺开，就好像画人物肖像一样，先勾勒草图，画出人物整体轮廓，然后才依次画出脑袋、眉毛、眼睛、鼻子、嘴巴等等，全部画出来之后，才是着色。 3. 增量式开发 增量式开发，咋听之下，与迭代式开发的意思一样，实际上是不一样的，增量式开发的意思是，每次只构建一点，每个阶段就交付一部分，然后组合在一起，还是用画人物肖像来举例子，一开始先画头发，画完之后上色，然后接着是眉毛，画好之后着色，以此类推，全部画好一个地方再接着画另一个地方，如下图所示： 4. 敏捷式开发 适应型开发，灵活性很高，需求可以随时提，然后放到需求池里，可能两周一个周期发一个版本。因为能干的活儿很有限，就像坐地铁一样，人很多，挤不上去那就下一趟，所以敏捷开发的思路就是，未必做得到，所以下个版本实现需求，可以有节奏地持续开发。 以上就是常用的开发模式，但是我们在实际应用中，应该怎么选择哪一种开发模式呢？为此有一个STACEY矩阵图可以作一些参考，如下所示： 从上图中可以知道，选择哪种开发模式，是基于需求和技术两个维度去评估的，所以项目负责人在编写项目需求与方案文档的时候，可能就可以做出判断了。说回我们自身，开发模式毕竟只是项目管理中的一种技巧，要深刻认识到它并不是万能的，如果掉入盲目迷信权威的陷阱，那么就太死板了，真正应用的时候，还是要考虑实际情况，在遵循基本原则的基础上，要明白事物变化的重要性，在变化的世界里使用不变的方法是不现实的，没有任何一种开发模式能够适用全部的项目。 现在部门按照项目来管理，每个人都比较清楚自己要做的事情，也没有那么多交叉的任务，所以变更理应很少才对，在制定项目计划的时候，我们可以把项目开发的周期全部列出，虽然项目计划通常都会有变更，但项目计划最好能够做到有始有终，把全部任务时间明确一下，然后项目交付时间基本就确定了，其中的任意环节有变更，很有可能是不会影响到项目交付时间的。我们可以把项目计划分为11个环节，如下所示： 需求分析 原型设计 方案设计 开发计划 开发阶段 下版计划（下一阶段任务计划） 内部验收 产品验收 测试阶段 模拟升级 正式发布 复盘会议 如下图所示，就是根据这11个环节制定的项目开发计划，虽然实际情况会有所出入，但是可以知道这个项目12月底基本上就可以交付了，有这样很清晰的时间节点，对于接下来的开发工作，会更有目标和方向感，其中经常出现任务变更，大多是在开发阶段，但是并不代表做好这个环节就没事了，接下来的环节如果遇到问题，也是会影响到项目交付的，所以怎么能管理好一个项目，是需要多方面去思考和解决问题的，并不是只做好开发任务环节就行了。