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

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

当前一个项目在开发新需求的时候，我们制定的计划只是列出功能开发的部分，并不是整个项目全部的周期，这就造成项目从开始到能够正式上线，时间规划是不全面、不清晰的（只是代码编写部分有时间计划），项目负责人基本上只会关注功能开发的部分，至于内部验收、Bug修复、测试周期和版本发布时间等等环节，有点听天由命，完全是看前一个环节进展的情况而定——前一个环节进展顺利，那就到下一个环节，进展不顺利就变更下个环节的时间，反复几次，项目上线的时间一拖再拖，遥遥无期。 之所以会这样，是因为在项目推进过程中，我们聚焦的一直是解决项目当前遇到的难题，为了解决这个难题，不断地调整项目任务计划时间，明天后天下周下个月等等。也许我们可以转换一下思路：项目推进过程中，以终为始，以最终结果为导向，聚焦项目上线发布这个目标。为了达成这个目标，我们要采取不同的做事情方式，也就是多维度思考如何解决问题。 导致项目进度受阻的问题有大有小，如果是不可抗力的情况（比如有的项目需要用到设备，结果设备完全用不了），那当然没有办法，但这种情况相对来说还是比较少的。其他的那些问题就要想一下，是不是当下一定要解决，或者说一定要从技术层面解决才行呢？那当然不是，我们的需求只是解决问题，问题解决了就行，并不关心用了什么方式。就好像要从广州到北京，需求只是要去到北京，并不在乎你怎么过去，是要坐飞机、坐动车、自己开车或者打车什么都可以，只要能到北京就行。 在项目推进过程中，项目负责人遇到问题时，以前可能是这样思考的：“这个问题解决起来很困难，可能需要5天的时间，我要问一下，项目计划能不能变更，调整一下上线的时间？“现在的话，如果是以终为始，可能就需要这样思考了：“这个问题解决起来很困难，可能需要5天时间，这个版本计划11月15日上线，时间有点紧张——这个功能是不是必须的？一定是这个版本要加的么？能不能下个版本？为什么需要5天的时间，有没有其他更好的解决方案？5天的时间里，我是不是可以先做其他事情？测试阶段、发版阶段还有没有什么潜在的问题？第三方编译走通过了么？时间有点赶，问题有点多，可能要动员一下，让大家知道现在时间有点紧张，加加班才行了，宁愿赶在前面，也不要后面遇到问题了没时间解决。” 我们倾向于哪怕只是一点点可能性，也要挣扎一下，不要那么容易就缴械投降。还是要回到小平同志说的那句话：“不管黑猫白猫，能捉老鼠的就是好猫。”

一直以来，项目管理中存在一个较为突出的问题：项目负责人在接到产品需求后，往往只是简单浏览一眼，便着手制定项目开发计划。计划制定完成后，负责人通常只深入研究自己负责开发的模块，而对其他模块则不再深入了解。对于由其他同事负责开发的功能模块，项目负责人通常连三个基本问题都无法准确回答：一是“是什么”，即这个功能具体是什么；二是“为什么”，即客户为什么需要这个功能，这个功能对客户有什么实际用途，是否可以不开发；三是“怎么做”，即这个功能在前端和后端分别是如何实现的。即便能回答到第三个问题，通常也仅能涉及前端或后端的部分内容。而实际情况往往更为糟糕，有时连第一个问题都无法准确回答。负责开发该功能模块的同事，可能也是在开发过程中逐步了解需求，其对需求的掌握程度，刚好足以完成功能开发即可。 这种状况容易导致项目管理出现诸多问题，表面上看似平静，实则处于一种失控状态，主要体现在以下几个方面： 任务时间评估不到位：项目负责人由于对整体功能和需求缺乏深入了解，导致在评估任务所需时间时不够准确，经常需要变更任务计划，影响项目进度的稳定性。 风险意识不足：由于对业务不够熟悉，项目负责人无法提前识别潜在的延期风险因素，也无法有效判断是否需要安排加班来应对可能出现的问题，从而增加了项目按时完成的不确定性。 任务验收困难：在验收功能时，由于项目负责人对业务和需求不够了解，只能依赖开发同事的回答来判断功能是否实现以及是否与需求一致。这种情况下，验收工作往往流于形式，难以深入和全面地评估功能质量，导致验收工作的积极性和效果都不理想。 为了解决这些问题，项目负责人需要自行梳理一份详细的项目需求与功能实现文档。比如下图所示的文档格式。在文档中，将每个功能按照“是什么”、“为什么”、“怎么做”这三个问题进行清晰的梳理和记录。在项目推进过程中，一旦出现需求变更，应及时更新文档，确保项目负责人对项目的整体情况有清晰的把握和了解。

我认真思考了一下，觉得项目负责人的能力可以分为五个阶段，分别对应的关键字是开发、方法、产品、整体、市场。虽然看起来好像呈递进关系，但是我发现实际上不是这样的，很多人可能没办法将其划分在哪个阶段，有些是好几个阶段都覆盖，各阶段要求的能力都有一点，但又不完全具备；有些是第二阶段了，可能第一阶段还没达到等等，所以这个划分只是参考。 1. 开发能力 项目里自己负责开发的功能高质量完成，基本可以认为是可以直接给客户演示的标准：功能没有特别重大的Bug（例如不会突然崩溃或无法使用）；功能边界定义清晰（例如手机号输入有格式限制，且包含正确提示和异常处理）；界面交互流畅，避免出现逻辑混乱的页面跳转；视觉细节完善，连一个像素的偏差都会调整到位。 2. 方法论沉淀 项目里自己开发的模块业务非常熟悉，但其他人负责的部分了解不足；能够独立完成需求理解、方案设计、开发计划制定、内部验收、测试提交和项目上线全流程，对分配到的模块有完整把控力。 3. 产品化思维 对项目中所有业务需求的关联性和实现路径一清二楚；熟练使用项目涉及的硬件设备及相关配套产品；如果由你主导，能够完成产品需求文档和原型设计，并对需求合理性提出专业建议。 4. 技术全局观 突破单一技术栈限制，例如前端出身的负责人掌握后端核心技术逻辑，后端负责人熟悉前端核心实现原理，能够主导跨技术栈的方案设计与协作。 5. 市场价值洞察 从技术执行转向产品驱动，深入理解产品的市场定位与核心价值（例如清楚产品解决什么痛点、目标用户是谁）；关注产品的市场推广策略与用户增长，推动技术方案适配市场需求。

我们探讨项目管理的意义，只会聚焦于关联密切的那部分。至于关系到公司成本投入等问题，虽然是不争的事实，但对于我们而言，有点遥远，就不再过多拓展。 对于项目负责人而言，他需要明白项目管理的意义。根据我个人的一些经验，总结了以下三点，分别涉及一个项目完整的周期，即开始、过程和结束。 一致性 目标一致、步伐一致，项目中的全体成员都需要知道，我们的目标是什么？并将全部精力投入到达成目标的要事上面。在这个过程中，间接实现了项目降本增效，还有提高团队的凝聚力。 及时性 项目进行过程中，无时无刻都在发生变化，不管是项目制定的计划，还是遇到了业务或技术难点，及时了解到当下的情况，尽快解决问题，可以避免项目进度受阻。 高质性 项目完成并不意味着没有问题，质量如何保证，就需要项目负责人进行项目的验收，不然怎么知道已经完善了呢？ 以上这三点都是对于项目而言，那么对于项目负责人来说，意义又在哪里呢？ 那就是一个人的成功（做好事情）固然值得肯定，但如果他能将这种成功因地制宜地在团队其他人身上应验，那将意义深远。一方面，团队里的成员能力有所提升，对项目上面的工作肯定是有帮助的；另一方面，我们都知道每个人都有自己对世界的一套认知，怎么做事情，都有自己的方式，我们只是一直在摸索那条规律，不断应验和调整。如果其他人也适用，那至少说明，你的一整套理论是有可取之处的，越来越靠近那条规律；如果不适用，那也可以借机进行反思和完善，对你而言是大有裨益的。这也是教员《实践论》里提到的观点：“人类认识的历史告诉我们，许多理论的真理性是不完全的，经过实践的检验而纠正了它们的不完全性。”