编辑导语：说到“项目管理”我们会想到信息管理，建筑项目等，其实一切皆为项目，我们的人生也是一个大的项目，在这个大的项目中，拥有多个小的项目，多个阶段，构建了一个完整的人生。本篇文章谈谈如何做好项目管理，怎样把项目管理落实到工作的细节。

最近看到一段话，于我心有戚戚焉。这个世界我们看到的人和事，都有表层世界和底层世界。比如你看到一个人穿着、打扮、接人待物侃侃而谈，谦谦君子之风；或者你看到一个城市井井有条，马路上看不到一丝杂物，候车区大家秩序井然的排队等候出租车；或者你看到一场精彩无比的足球赛，双方球员激烈厮杀，贡献了一个个球场的高潮，让你兴奋不已。

这是我们所看到的表层世界，用手、眼、耳可及的东西。但是在这样的表层世界，一定隐藏了一个底层世界，侃侃而谈，游刃有余的朋友，他后面的教育、支撑他的资源；井井有条的城市，背后规划布局、执行安排的工作人员；

足球赛场上，教练和球员的排兵布阵，这些是你看不到的，也是隐藏在这个表层世界下面的底层世界。决定一个人是否成功，人生巅峰的恰恰是他的底层世界，而项目管理能力，就是一个人工作最基本的底层能力。

说到项目管理，我们会想到建筑项目，信息管理系统等，但其实一切皆项目，我们的人生也是一个大的项目，在这个大的项目中，拥有多个小的项目，多个阶段，构建了一个完整的人生，林林种种的活动，小的项目构建成不同大的项目。

当然今天的话题并不是谈如何构架这个大的人生项目的，而仅仅从项目管理的角度谈谈，做好项目管理，怎样把项目管理落实到工作的细节。

2020年，有幸为公司贡献了两款从0-1的软件产品，并且担任这2个项目的项目经理。两个项目均涉及到跨多项目组协作与资源协调，但最终2个项目都按期交付，没有延期1天，所产生的bug，两个项目均在350个以上，bug的修改率为99%。

其中1个项目被评为公司的创新项目奖，也算是为2020年画上了一个还算圆满的句号。在这里，结合2020年，我负责的1个项目，与大家分享一下项目管理的经验，与君共勉。

一、全盘规划

在2020年，我所带的第1个项目，是个数据分析类的产品，并且针对的是特殊的垂直行业，而我个人在这个行业里没有任何相关的产品和业务经验。忘了说，我本身是产品经理，兼任项目经理。按照敏捷项目管理里的专业知识来说，PO这个岗位是不适合兼任PM这个岗位，然而在国内的IT公司和互联网公司，PO和PM是同一个人的情况非常常见，我恰恰也是如此。

被分到这个项目，我是一头雾水的，第一个难处就是，要明确做什么，方向性的问题，但也需要全盘考虑，如何把这个项目做成。于是在整体上我列了1个简单的项目计划和阶段安排。

首先，分析了下当前公司的现状，以及我所负责的产品是0-1.这个产品还要拿出去销售，所以在2020年的10月前，希望能完成交付工作，这样赶在年前还有2个月的市场预热期。

最终的时间期限确定了，于是我倒推了各个阶段的大概时间点，大致分为了以下几个阶段：

1. 需求调研阶段；
2. 项目立项阶段；
3. 产品功能设计阶段；
4. 产品开发阶段；
5. 测试与验收交付阶段；
6. 交付后阶段。

这几个阶段并没有按照我们项目管理的知识来做严格的划分，而更向是1个瀑布式的开发方式。但是这样是有好处的，就是方便建立清晰的项目实现路径，即经过哪几个阶段我们能完成这件事，当前所进行工作可以归属到哪个阶段。

但是在实际的项目开发过程中我们采取的是瀑布式和敏捷相结合的方式来进行的。比如需求调研阶段是一个完整而独立的阶段，我们做了市场分析、用户需求分析、竞品分析，为了确保研发对产品的理解以及关键技术的应用，在做竞品分析的过程中，我们要求开发经理与我们一起来调研竞品所采用的技术方案。

目的不仅仅是用于技术选型，而是让开发的主要人员能了解我们在做什么，目的是什么，有什么样的技术可以选择，在他们的大脑中形成一个初步的印象，减少在立项阶段和开发阶段的沟通成本。

在需求调研阶段我们输出了需求调研报告、竞品调研报告、可研性分析报告，并对公司已有的系统的数据底层做了相关数据梳理，这部分工作由另外一名产品经理负责完成。

需求调研阶段的输出物，本质是为了为下一阶段立项阶段提供依据，当然需求调研也用到了项目管理中的专家访谈法、调查问卷、头脑风暴等各种方法，来搜集信息和获得结论。项目立项阶段，就是各方高层和项目相关者进行评审，即确定方向是否正确，做什么，不做什么，大概的产品框架范围和任命项目经理，很荣幸我被任命为项目经理。

在立项阶段我们输出了产品范围说明书，最基础的产品功能说明书，作为产品功能设计阶段的输入。产品开发阶段，我们采取了持续迭代的方式，把软件产品中涉及到的功能模块拆分为6个大模块，54个小模块，初步开发和迭代验证，即开发完一个模块，马上进行测试验证。整个验证过程也是由大到小，比如先保证主流程是通畅的，然后验证子模块的流程，最后验证功能使用体验以及UI交互界面。

在开发阶段，一开始我采取了项目排期是非常细致的排期计划，但是在工作大概一两周后，我发现该项目团队的主动性非常高，配合效果很好，果断放弃了详细的项目监控方式。

甚至连最基本的早会和周例会也取消了，因为研发人员希望更加全勤的投入到开发工作，不希望太多会议占用他们时间。于是我们采取了线上工作进度同步的方式，开发人员对自己开发的模块进行截止时间上报，完成进度上报，预计的完成时间也标上，方便上下游开发人员及时了解各方进度，合理安排自己的工作。

产品验收阶段和验收后阶段，就是测试及交付部门的各种验证，我们安排研发人员提交了各类文档来支撑交付部门做整体的验证，如数据库的迁移，部署到演示环境，整体的操作步骤，数据库表结构等移交，这个过程不再赘述。

整体而言，整个开发流程是按照事先划分的6个阶段进行演进的，大部分工作都在每个阶段的规定时间前完成了，在水平线之上，整个产品的研发居然提前15天完成开发工作。

二、逐步细化

上面的全盘规划章节，有说到6个阶段，但是这6个阶段的具体规划并不是一开始就非常详细了，它是一个渐进明细的过程，当下正在进行的阶段一定是最详细的，而没有经历或者未来的阶段则是比较粗略的。

比如当下进行的需求调研阶段，我把需求调研阶段所涉及到的工作进行逐级的拆分，比如标书的梳理工作、内部系统的数据梳理工作、专家访谈工作等，那标书的梳理工作其实又会向下进行拆分，如从哪些渠道获取标书，数量期望是多少，招标的客户规模多大，标书与当前产品的关联性是怎样的……（目标是具体的，可执行的，可衡量的，有关联性的）？

每个阶段的工作都是逐步去细化向下进行拆分，如果某一项工作觉得无法开展，那问题就是拆的不够细，太过粗略的工作会增加工作的难度，项目组的成员就无法去执行，并且执行的结果也无法预期。

因此，在逐步细化的基础上，把握的原则是，请研发团队和要做这件事的人来进行评估，是否做的下去。你可以让他跟你说，面对你安排的这项任务，他打算怎么干，如果他能很明确的讲出他该如何干的话，那说明这项任务的安排此人是可以胜任的。

当然每个阶段的细化并不是越细，拆的越充分越好，因为这会浪费很大的经历，首先拆的越细，作为项目负责人，代表你整个项目的执行事项会越多，控制点也越多，因此你所付出的经历也会多。我们都不喜欢事必躬亲的领导是吗？因为这代表你留给下属的发挥空间并不多。

同样的，项目组成员也不希望自己变成一个完全执行的机器，因此怎么细化，拆的有多细，完全取决于你的项目团队人员，能力强的人，拆的粗一点，让他有发挥的空间。执行能力差的人，能力弱的人，拆的更细一点，建立更多的控制点和考核点，把一项大的任务变成小的任务，降低执行的难度。

敏捷里面有个原则，合适就好，无需过度包装，因此逐步细化这个度，需要各个项目经理自己去把握。需要充分考虑项目的整体时间节点、团队资源的情况、团队合作的默契等等因素。

如果说跟团队成员是初次合作的话，可以对某些拆分的方式以及如何做，来做讨论，达成一致性，而非强求的执行。能够吸纳团队思想的执行方案一定是更佳的方案，因为团队成员参与了思考，对这件事有了更多的认知，对于该如何做也会有清晰的方向与感知。

三、及时解决问题

前面说了很多，似乎这个项目是一帆风顺的，但是如开篇所说的，顺利是表层，然而底层是，每天都会有各种层出不穷的问题。比如某个之前讨论好的逻辑在做的过程中发现走不通，要调整，得有方案，是大改还是小改，要去评估调整的代价与价值。

比如某个干得好好的研发人员，突然由于资源紧张，被调走了，然后你发现他被调走可能都没跟你商量。再比如，做的某个功能，都快做完了，结果几个领导不满意，不行，必须改，于是推翻重做，修改设计稿十几次。

每天都会遇到各种各种的问题，简直是被问题包围，每个人都会过来告诉你有什么什么问题，这样或者那样的问题，然后问你该怎么办？我相信这是每个项目经理都会经历的事情，那么到底该怎么办呢？

记得咱们学过的PMP里，似乎有一个关联的文件叫问题日志，当然你不会把问题一个个按照问题日志记下来的，那太多了，也不符合实际的情况。但是我们需要对问题做分析和定性，比如这个问题会影响什么，项目管理的三个基线，进度、成本、质量，是定性的基本条件。比如这个问题当下必须解决吗？不解决会影响什么，是进度还是成本还是质量？影响的程度大概多大？

这时候，一个项目经理的经验就起了很大的作用。因为有些问题表面上看可能是小问题，但是如果不解决，不作为，可能会引发更大的问题。

比如一个小的逻辑的修改会牵一发而动全身，改了可能解决当前的问题，但会引发后续更多的改动和变更成本。这就需要项目经理去平衡，如果说这个问题对当前的质量或者说客户以及用户体验的感知没有很大，但是修改了会产生牵一发动全身的影响，那么结果可能就是不改。

而有些问题，则是非改不可，比如我此前提到的，某个功能我们确实已经完成了，但是，干系人不满意呀，你不改，干系人回头验收就不签字，那没办法你得硬着头皮头皮改，并且要在改之前充分与干系人沟通，他们想要什么样的，你能给出不同的方案和让干系人做选择题非常的重要，记得前面所说的，充分沟通永远是不错的。

说到及时解决问题，又要说另外一个话题了，问题的解决是否越快越好呢，答案必然是否。记得敏捷管理里，学过一个知识点，在必须决策的时候进行决策，决策的时间越晚越好。因为一个问题暴露出来，她底层的原因分析，是困难的，你能获取的信息和原因随着时间会越来越清晰。

这就是一个初级项目经理和高级项目经理的区别，尝试充分定义问题是什么，产生的原因是什么，如何解决是否有多套方案，每个不同方案的付出的成本代价是多少，带来的价值是多少，基于这个方案该怎么做？何时做是比较恰当的时机。解决问题的节奏的把控是项目经理非常重要的一项能力。

四、carry 全场

项目经理需要carry全场的能力，文写的了文档，排的了计划，武能跟开发讨论计划，撕的了X。然后总结下来，carry全场需要横向与纵向拉通的能力。从纵向来看，你如何让公司的领导高层能够相信你，这个项目按照你的管理方式和计划执行是可以成功的。

你需要摆事实讲道理，专业的知识和经验都是加分的条件。从横向来看，如何协调与拉通资源，把一件千头万绪，看起来不可执行的事情，抽丝剥茧，尝试破局找到切入点开始干起来，并且能交出结果。

在疫情这个背景下，越来越多的公司会更趋向于短期回报，不管是资金的回收周期，利润获取周期，还是项目的运转周期，时间都在逐步压缩，成本也是逐步压缩的。投资回报率变成衡量一个项目的重要指标之一了。

所以一个好的项目经理更加需要为你的项目计算成本和收益，确切的说就是，你要明白你的项目付出多少成本，而多久能回收。这是你说服高层愿意做你这个项目的非常重要的原因。

所以补充项目管理的框架知识，并且把这些知识应用到你的项目当中去实践，不一定是全部，因为不同的项目有不同的特点。但是项目管理本质是在做一件科学管理的事情，工欲善其事，必先利其器。所以在项目管理的过程中结合项目管理框架知识，形成自己独特的方法论是你能carry全场的利器。

该篇文章写的比较仓促，希望能对大家的项目经理管理工作有所帮助。当然我所说的这个项目，并不是都说优点，没有缺点。比如我们预估的工期不准，导致提前开发完成，这也并非好事，说明项目资源没有得到合理的分配。

产品的范围和难度估计不足。没有100%完美的项目管理与项目，但是每次都能在以前的基础上精进那么一点，才会变得越来越美好，混乱会少一些，你的底层世界也会越来越清晰，与诸君共勉。

本文由 @弗瑞利 原创发布于人人都是产品经理，未经许可，禁止转载

题图来自 Unsplash，基于 CC0 协议