一个大型项目从立项到完成会需要多方合作，涉及到很多人员的调动，工作也会比较的繁琐。

一套科学有效的（敏捷）项目管理方法是保证项目成功落地的必要条件。

项目管理贯穿于产品的全流程管理，大致分为5个里程碑，分别为需求（需求管理、需求评审）、研发（研发前准备、研发中）、测试（功能测试、集成测试、压力测试、POC验证（培训，业务人员验证））、上线运维、复盘。接下来，我将从这几个维度分别描述我们是如何进行高效管理的。

一、 需求管理

产品的需求总是源源不断的，有的来自于用户直接的需求反馈，有的则来自于公司对产品的宏观愿景。这些需求我们究竟要如何进行管理呢？

1. 需求池管理

1）从目标出发对需求池进行管理

需求池的需求总是超出我们的预期的，需求不是做的越多越好，需求的目标也不是为了把需求做完。需求的管理指的是在有限的团队和有限的时间范围下，找到优先级更高的需求，解决用户最关心的问题，满足用户的最大价值和公司的最大价值。

所以确定产品的愿景和目标，从愿景、目标出发对需求池进行管理而不是从功能出发进行管理。

对于目标的确定，首先，我们需要明确产品的愿景，再在产品整体愿景的基础上确定产品年度目标，产品的roadmap，再将目标拆解为季度和月度目标，进行细化。一方面通过目标确定当年的需求方向，并因此能够标记出池需求的优先级，另一方面，拆解到月度范围的目标能让我们有条不紊稳步前进。

但同时，虽然我们以目标为导向，大目标一般是稳定的，但小周期的目标实际上是允许灵活变动的，需要根据用户以及当前环境的变化做出灵活的应对。

目标管理是为了让团队和项目有清晰的指引和前进的动力，但目标管理本身并不是我们追求的目标，所以千万不要觉得目标是不可改动的，就像敏捷宣言中所说：响应变化高于遵循计划才是正确的处理方式。我们需要根据客户的影响度适当对目标进行调整，同时也对需求优先级进行调整。

2）和用户一起建立沟通和闭环机制

需求池的管理不仅仅能够对产品本身的迭代进行管理，同时也能够和用户之间建立关系桥梁。

一份清晰的需求清单表，应该包括需求的描述、提出人、提出时间、产品评估结果，当前进度，优先级等字段，这样就能够辅助产品对需求进行管理。

同时，如果需求和业务方密切合作，也应该通过将需求清单共享给用户查看，不断更新需求池状态，让用户和项目组同学知道对于用户需求的响应状况，建立积极的用户关系，和用户一起建立起沟通和闭环机制。

2. 迭代需求管理

当我们从需求池捞出需求进入迭代完成原型后，并不是马上进入需求评审阶段。

如果需求较为复杂或产品无法判断需求的数量以及方案的可行性，需要产品在需求评审前拉起主要研发同学进行小范围讨论，目的是确定需求方案的可落地性和迭代需求范围。

为什么要确定迭代需求范围呢？因为在敏捷开发中，迭代的周期是稳定的，比如2周一个迭代，通过稳定而较短的开发周期，一方面保证了需求响应的及时性，也符合MVP快速市场验证的理念。同时，通过稳定的开发周期，能够提高研发同学对需求评估的精准度（迭代周期稳定，需求数量较为稳定，通过越多的相似规模的需求实际开发时间作为样本，对开发工作量的评估就会越来越接近实际值），以及积极的项目节奏氛围。当然，如果不是敏捷开发，可能就另当别论了。

所以，我们进行迭代范围的确定，也就是在正式需求评审前，将优先级较低的需求砍掉，以免浪费大家的时间。

二、 需求评审

1. 团队成员了解需求背景了吗？

现在，我们来做一个测试，问问你的团队，项目的定位和愿景是什么，有多少人能回答上来？你的成员们真的知道迭代为什么要规划这些功能吗？他们知道目标用户是谁、场景是什么、解决了用户什么痛点吗？

答案是不是有些许扎心？那我有理由怀疑你没有做好真正的需求评审。

一个好的需求评审，需要告诉团队项目的目标，迭代的目标，同时，在进行需求讲解时，不仅仅需要阐述功能的流程，还需要阐述需求的背景。即什么用户在什么场景下遇到了什么问题，我们提供的这个功能解决了他什么问题，满足了用户什么需求。

在这样的前提下，研发同学才会知道产品建设的意义和价值，也才会对产品有认同感，而不是觉得自己只是来开发个功能而已。也只有研发同学对产品有认同感之后，才会有主人翁意识，并去和产品一起思考如何做的更好，现有的方案是不是最优的。

记住，一个好的团队一定是有目标有梦想的，咸鱼一样的团队是做不出极致的产品的。而这份目标和梦想的植入需要产品在需求评审阶段就去努力。

此刻，你还以为需求评审只是为了把要做的功能流程讲清楚吗？

2. 需求的优先级

除了讲清楚需求的背景，在完成需求评审后，我们还需要对需求优先级进行评估。

一方面保证研发顺序按照优先级进行，保证高优先级需求的交付。另一方，低优先级但可能完不成的需求，作为迭代冲刺目标，是可以根据完成情况移入下迭代，而不影响迭代的。

这里，我们的方法是，除了高中低的优先级排序，我们还会把这些需求标上阿拉伯数字，表明各需求整体的优先级排序。

3. 将确定的需求录入到相应的项目管理系统

需求的线上管理我们之前使用jira，市面上也有一些其他的项目管理工具，比如腾讯的tapd 以及很久前我用过一个叫trello的工具。如果没有，用excel 和便利贴进行管理也是可以的。

需求的拆分，粒度是比较难的一件事儿。

从用户的角度来说，大小规模合适的需求，是一个可以满足某一需要达成某一业务目标的故事，比如删除一条任务，就是能够独立作为一个需求单的需求。而从项目组研发的角度上来说，一个大小规模适当的需求是可以在几天时间内完成开发和测试的故事，因此，同样删除也是满足的。

通过拆分这样的小模块，对于开发、测试和最终的发布上线都是大有裨益的，因为将需求划分为这样的小故事，团队就可以并行开发各个模块，而无需彼此等待。也就不会出现需求开发堆积到后期的风险。因此我们建议将需求拆分为可以在两三天时间内完成开发和测试的模块。

拆分完需求后，就需要把需求录入线上系统。在需求录入时，需求的标题需要简单直接，我们一般会采用的描述如下：

除此还需要标注需求的优先级，需求负责人、故事点、开始时间、结束时间等信息。完整和简洁的信息有助于后期进行故事墙管理。

三、 研发&测试

如果需求评审结束就立即进入研发，极大可能会出现事倍功半和混乱的局面，所以，研发前的准备工作是不可忽略的。那研发前有哪些准备工作呢？

1. 技术评审会

技术评审主要由研发侧发起和负责，目的是前后端同学对各需求所需要的技术能力以及风险进行对齐，尤其是当功能复杂，对应技术复杂的时候，充分的技术评审能够规避迭代研发过程中可能出现的技术风险，确保迭代进度和质量。

一般这时候，研发负责人需要和大家一起确定每一个需求的前后端研发同学。前后端对各自的需求进行阐述，后端主要是接口文档的定义（格式和地址待定）。当项目需要引入新组件、新技术时还需要进行技术预演，去熟悉新的技术，评估怎么整合到系统、有没有风险等。

2. 拆分研发任务和确定需求开发节奏

完成技术评审会之后，研发同学对于每一个需求的完成需要做哪些工作以及怎么做也就清楚了。这个时候就可以开始进行研发任务的拆分了。

研发任务的拆分是为了对于每一个需求的跟进提供切实可依的依据，并在后期的项目故事板进行展示，辅助项目能够有序稳步前进，而不是让项目管理进入无序的黑盒子。因此，在任务拆分的时候需要遵循几个点：

• 研发任务需要分别拆分前端、后端研发任务，分别确定负责人进行跟进。
• 研发任务的粒度尽量小于3 天的开发周期，否则很难跟进和评估风险。
• 研发任务需要标记owner、研发开始时间、研发结束时间、故事点信息。

基于以上，我们又能对需求进行一些信息的补充，包括：

• 根据单个需求下所属的全部研发任务的开始时间和结束时间确定需求的提测时间，即需求的研发开始时间和结束时间。
• 确定需求的研发owner ,研发owner 对需求的开发周期负责。包括确保需求按时进入联调，按时完成联调，按时提测。

3. 需求反讲和计划会

1）需求反讲

我们经常会听到研发和产品经理撕的事情，有些时候我们也会听到因为前期需求沟通不一致，导致研发结果和产品需求出现偏差的事情。为了规避这样的问题，我们加入了需求反讲环节。

所谓的需求反讲就是让研发同学来讲需求，产品同学听需求。在这个过程中，需求的前后端研发负责人会先讲一讲整体的功能流程，同时会阐述自己需要准备什么。如果信息不对称能够很快发现。当然，如果需求很简单，也可以忽略这一环节。

2）计划会

计划会的目的主要是和大家一起确定迭代节奏。包括每一项需求的开始时间和开发结束时间（包括联调，也就是开发结束就应该进入测试），并由此确定全面提测时间，并由测试同学确定测试完成封版的时间以及发布的时间。

如果前面的任务拆分都做的很好，每一项任务前后端都评估了时间，同时大家对需求理解没有问题，在这样的前提下，计划会其实是很快的。

如果考虑会议太多，其实可以将计划会和需求反讲放到一起进行。

计划会结束后，整体迭代中的需求节奏，迭代发布节奏基本也就确定了。这时候作为项目经理，可以整理邮件，将迭代目标，计划发送知会全员。

4. 完成故事墙

故事墙顾名思义是一面墙或者白板，线上或线下都可以。而墙上则是迭代中的用户故事以及研发任务，项目管理中通过把这些故事和任务贴到故事墙上并根据进度挪动，从而实现项目中的进度管理。

1）故事墙的结构

 

顶部是项目进度的叙事主线，通过一个个的活动阶段将故事和任务组织起来。并通过对正常状态和风险项的细分，有效的反映出故事和人物的变化性，让项目成员对项目进度能够有效把控。

迭代目标的展示是为了让项目组同学目标一致前进，也能明白大家做的事情的意义和价值。

我们把所有规划到迭代中的需求以及对应的研发任务放到规划中，分两列放置。

当需求下的任务启动开发后，就可以将任务拖动到实现中，当任务状态进入联调中时，我们就需要把需求和任务一起拖动到联调中状态。为了方便查看，进入联调后会建议大家把需求和对应任务放到一起开始进行拖动，如果你的故事墙是便签纸制作，这个时候你可以把需求和任务叠到一起进行拖动。

接着需求进入到测试、待发布的流程，并最终随版本全部发布上线。

在实际操作中我们发现在进程中部分需求可能出现风险延迟，因此我们在纵向上又将需求划分为正常进度和风险项，一旦需求或任务出现风险就需要将需求和任务拖入到风险项一行，解除后可回到正常一行。

当然，根据需要你也可以增加更多的状态栏来辅助管理，比如我们之前的故事墙是这样的。敏捷教练甚至会在顶部打印出大家的头像，来让大家有更明确的团队归属感。

2）故事卡片

故事墙由一个个的需求和任务卡片组成，对于故事卡片来讲，需要包括如下内容：故事标题、故事描述、优先级、负责人、开始时间、结束时间、状态

而对于任务来说则需要包括：

任务标题，依赖的需求、负责人、开始时间、结束时间、状态、故事点信息。

通过这些信息，我们能够清晰的看到每一天应该做哪些需求，哪些需求应该进入测试，哪些需求出现延期，需求的负责人是谁。从而对需求的完成进度，项目的节奏能够有较强的把控力。

四、 研发阶段过程跟进

1. 站立会

研发正式开始后，为了正常推进项目进度，我们会进行每日站立会。

站立会阶段主要需要明确每一个成员的进度和计划，以及同步风险。即项目成员昨天完成了什么，今日要做什么，当前是否有风险项或项目阻塞，每人不会超过1分钟。

站立会上若遇到需要解决的问题，我们会督促大家会议结束后立马小范围拉上相关人员讨论解决，而不会在站立会上直接解决，因为如果在站立会上解决，会让整个站立会的时间拉的特别长，耽误其他同学的时间。

成员在同步的同时，需要同步拖动卡片的位置改变卡片状态。这样，站立会结束，目前各个需求以及任务对应的开发状态和进度也就一目了然了。

2. 需求的验收

随着需求不断被交付，产品逐渐进入测试阶段。在这个过程中，除了研发要做好开发和自测，测试同学要做好功能测试，也需要产品经理在各个环节深度参与，把控质量。

为了从源头上阻断功能开发和产品理解不一致，我们一般会在研发完成联调后先让产品经理先做功能测试，这个过程中主要看功能主流程是否跑通，是否和需求开发一致。产品测试通过，则可转测试状态，并知会测试同学开始功能测试。

为了保证各流转环节的无缝衔接。我们采用的方式是群知会，比如研发完成联调后群里@产品进行开发环境测试，产品测试通过后群里立马@测试同学可开始测试，以保证流程的顺畅。虽然我们通过jira或者邮件都可以实现转单以及通知，但从沟通的实效性以及流程的完整性上，我们更建议通过群通知方式进行。

如果因为开发群消息太多会淹没消息，甚至可以单独开一个测试群，专门周知测试流程周转。

测试同学在收到测试单以后开始进行测试（功能测试、集成测试、压力测试），并将发现的问题和对应研发同学沟通后提单bug。修改并测试完成后将需求改为待发布状态。

进入全面提测阶段后，还需要邀请UED同学进行交互、视觉还原度测试，并及时将发现的问题反馈给项目组。

大型项目需要进行POC验证及用户培训。

3. 迭代发布

迭代发布代表着产品研发完成终于可以上线了，但一旦功能存在问题，上线就会给用户造成较为糟糕的体验和印象，因此迭代正式发布前的验收也至关重要。

一般情况下，测试同学按照封版时间完成测试后发出测试验收邮件，产品在收到邮件后开始进行全局产品验收。验收无误则可知会大家产品验收通过，进入发布状态。

此时，研发同学需要召集运维同学进行发布评审，各研发同学报备准备无误，各项准备就绪，运维同学确定发布的具体时间点，即可发布。

五、上线&运维&复盘

在项目迭代中，并不是产品上线后就大功告成可以撒手不管了，产品上线后我们需要去进行回顾和持续跟进，回顾的目的不是为了纠错，还是为了从过程中不断的学习和进步。

1. 关注上线后产品的质量

首先，需要关注产品的质量和用户反馈，第一时间去观察用户的行为和反馈，并将用户反馈纳入需求池进行管理。

同时，也需要通过指标客观进行观测，看看用户对新功能的使用情况。

2. 回顾和关注工作计划是否合理。

工作计划的合理有序是保证项目推进有序的必要条件，如果不合理是哪里不合理，就需要考虑如何在下一个迭代中进行调整。针对这一块我们可以看的包括需求燃尽图、迭代需求完成率、需求变更率等报表。

需求燃尽图反映了在迭代下需求完成的趋势。正常情况下，需求完成数是匀速上升的，如果出现前期上升缓慢，则表明需求极有可能堆积在后期交付，故事和任务可能都拆的过大，项目存在极大风险。若前期上升速度过快，则可能是需求评估不准，导致需求提前完成，或前期堆积的都是小需求。

 

迭代完成率指的是，迭代实际完成的需求数或故事点数占规划需求数或故事点数的比率。度量研发团队在核定的时间内稳定交付需求的能力。

需求变更率则主要指由于前期考虑不周导致需求的大变更，或研发中临时撤换需求。在客户需求变更或特殊情况下，我们允许一定情况的需求变更，拥抱变化，但同时，频繁的需求变更也会对研发团队带来交付和资源上的压力，因此并不建议这样的操作。

同时，由于前期需求考虑不充分导致的频繁需求变更，还会让研发团队对产品产生不信任感，降低项目的凝聚力。

3. 关注过程是否有序

比如开发的节奏是否根据大家估算的开始时间、结束时间进行推进，是否及时提测，整体需求的延迟交付率是怎样的等等。

产品从需求到上线，整体是多方协作共同的结果，如果一方在过程中无序，就会形成多米诺连锁反应，造成项目的混乱。经常看到有些项目的现象是，研发团队延迟提测，压缩测试时间，导致测试不充分情况下上线，测试不充分又导致产品问题没有被发现而影响用户体验，最终，用户体验受损，产品品牌受损，造成不可挽回的损失。

六、谁对项目管理负责

项目管理是一件繁琐而专业的工作，一般稍微大型的公司和团队都会配有专业的项目经理，如果是敏捷开发还会配置敏捷教练。但无论如何，项目管理一定不是某一个人的事情，而是需要团队一起努力的结果。

一方面，产品经理和项目经理需要进行配合管理，同时，研发端也需要有一个研发经理能够协助产品和项目经理一起进行管理。

产品经理对产品全流程最终交付负责，因此，产品经理其实需要时刻关注团队，同时配合项目经理的一切推进工作。

项目经理需要积极推动项目有序进行，遇到阻碍需要及时同步产品，督促或帮助团队解决问题。甚至在遇到资源问题时项目经理也需要帮助进行协调，始终为团队的稳定产出，凝聚力而努力。

研发经理作为研发端的负责人，需要对研发过程及交付负责，因此需要带领研发团队一起完成各节点事项，配合项目经理工作。否则也可能导致研发侧的无序。

而因每个团队特点和配置都不一样，为了明确成员的角色和职责，便于管理的顺利进行。所以需要公开明确团队各角色及职责范围，并作为项目约定之一执行下去。

七、小结

根据我们上面的整体的流程总结，可以用一张流程图做一下整体的描述，供大家参考。

主体流程是稳定的，但我们始终要记住，流程的制定是为了服务于项目、服务于人，因此，并没有一成不变的流程，也没有万能的解药，而需要我们在项目管理中不断的调整、优化、回顾和学习，并摸索出一套适合自己项目的管理方法。

同时，流程是死的，人是活的。我们始终要学会拥抱变化，高效灵活的沟通永远高于死板的流程，应变和解决业务的态度永远高于对流程的遵守。时时刻刻为用户、为产品着想，发挥出人的能动性，是我们始终要去倡导的。