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

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

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

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

这些内容是我在2022年8月编写的，当时在部门内部进行了分享，主要涉及项目管理知识和个人工作经验总结。最开始我是计划以写书的方式系统整理这些内容，但因种种原因一直搁置。现在我觉得，事情还是越早开始越好，因为不同阶段的工作重心会有变化。若一味拖延，可能错失深入处理细节的机会，而且时间越久，当初的感受和体会也会淡去，相应的观点也可能会有出入。因此，现在就开始着手整理吧。 你可能是项目中的开发能手，最佳情况也只是能保证自己负责开发的功能没有问题，其他的你是无法保证的。哪怕你承担了项目中全部的开发工作，测试阶段、验收阶段和发布阶段也是需要其他人协助的。假设这些你都可以自己完成，而且也做得很到位，但要是需要该项目在很短的时间内交付，想必你就没有办法了。一个人的能力不管多高，人的精力终究是有限的，任何事情能够得到一个比较满意的结果，都离不开众人的努力，对于项目而言也是如此。 在推进多项目管理过程中，反馈出来不少问题，我针对这些问题进行了分析，并且提供了一些相应的解决方案。不过这些方案不一定全对，只是我个人的一些反思总结和心得分享。我计划把内容分为意识、能力、方法、提升和附录这几个部分。意识主要是项目管理意识方面的探讨，意识是这一切的基础，意识没有到位，后面的其他方面做得再好，也是有局限性的，就像一棵大树，树根没有长好，枝干树叶的成长也是有限的。因为意识很重要，所以把它放在前面。能力主要是探讨项目管理应该具备哪些能力。方法主要是项目管理方法上面的探讨。至于附录，是一些有助于提升项目管理能力的书籍摘要。