如何做好项目管理

我把管理技能分为两类，分别为项目管理和团队管理，这篇文章教你如何做好项目管理。

在讲述这篇文章前，先简单介绍一下我的管理经验：之前在百度呆了3年半，系统学习了百度的项目管理流程，19年来到小米后，带领ShareSave团队做了1年项目管理和团队管理工作，之后带领海外商城基础服务后端团队，做了1年团队管理工作。

纵观我带过的项目，在保证项目质量的同时，少有延期的情况，主要还是源于自己的一套项目管理经验，下面我以ShareSave为例，将这套经验分享给大家。

没有考过PMP证书，也没有经过系统的项目管理培训，文章内容全凭经验之谈，如有偏颇，欢迎指出，定会改进！

一、项目流程

我把项目管理分为4个阶段，分别为需求阶段、研发阶段、测试阶段和上线阶段。

项目管理过程中，需要借助项目管理工具，我们以TB（Teambition）为例。 

1、产品规划

为什么我需要将“产品规划”单独列出来，因为这个真的太重要了，产品规划就像是海上的灯塔，指引你前进的方向。

有了产品规划，产品可以将需求提前放入需求池，每个迭代只做高优需求。

下面是产品规划要求：

扫描二维码关注公众号，回复： 14515824 查看本文章

2、需求评审

需求评审阶段，一定是需要产品给出完整的需求文档，如果有UI交互的地方，需要提前给出原型图，拒绝没有原型图的需求评审。

需求一定是要非常明确，最好是能细化到具体的功能点，拒绝模糊需求（比如一句话需求）。

下面是需求评审要求：

为了提高需求评审的效率，我们在需求评审前，需要做很多准备工作，比如需求前期沟通、研发初步评估，前期工作准备到位后，需求评审期间就可以主要讨论问题，避免一个需求反复沟通的情况。

下面是需求阶段流程（有些环节可以删掉，仅供参考）：

 

3、研发阶段

技术方案是整个项目的灵魂，很多项目到后期出现问题，很大原因就是技术方案没做好。

项目排期用于控制整体项目的节奏，有以下几点经验之谈：

1. 项目排期每天不要排满，建议预留 20% buffer;

2. 如果项目时间紧，可以采用分批提测的方式；

3. 排期要有里程碑，开发、联调、提测、上线、验收等；

4. 项目排期不能仅到上线阶段，还需包括线上灰度和项目验收；

5. 前端排期依赖UI设计。

下面是项目排期要求：

下面是研发阶段流程（有些环节可以删掉，仅供参考）： 

4、测试&上线阶段

上线方案可以为线上的稳定性保驾护航，重要性不言而喻。 因为上线导致严重的线上问题，这个项目可能就白干了。

关于测试&上线流程，有以下几点经验之谈：

1. 测试环节需要大家一起过测试Case；

2. 提测前，有的项目还需要做项目演示；

3. 上线前，需要一起过上线方案，突出风险点；

4. 上线后可能需要小流量验证，或者灰度；

5. 有的项目还有项目验收环节，最后才全员开放。

下面是测试&上线阶段流程（有些环节可以删掉，仅供参考）：

5、需求变更

重点说一下需求变更，这也是很多程序员头疼的问题，只要做到正确把控，其实也没那么可怕。

下面是需求变更要求：

总结一下：需求变更越早越好，变更需求，需要调整排期，临近上线，原则上不再允许需求变更，否则需要领导审批。 

总结一下项目管理的几个重要的点：

1. 产品规划就像是海上的灯塔，不能乱打一气；

2. 需求文档一定要尽可能详细，拒绝无原型的需求评审；

3. 技术方案是整个项目的灵魂，这块多投入时间绝对不亏；

4. 项目排期有里程碑、有buffer，排期需包括线上灰度和项目验收时间；

5. Code Review、测试Case都不能少；

6. 上线方案要预知风险，为线上的稳定性保驾护航。

二、每日站会

为什么要提这个呢，因为有的同学平时闷声不响，最后给你憋大招。所以你需要知道大家每天的工作进度、问题和风险，方便你推动和协调解决，甚至会对项目节奏临时调整。

站会怎么开，这个也有讲究，10-15分钟最佳，每位同学都要参与：

1. 昨天做了什么？

2. 今天打算做什么？

3. 遇到什么问题？

备注：站会时间早上或晚上最佳，方式比较灵活，前期可以每周2-3次，后期就每天都开。

三、敏捷开发模式

1、什么是敏捷开发

我们一般习惯用瀑布模型，它以文档为驱动，将软件生命周期划分为固定的六个基本活动，并且规定了它们自上而下、相互衔接的次序，如同瀑布流水，逐级下落。

那什么是敏捷开发呢？敏捷开发是一种以人为核心、迭代、循序渐进的开发方法，它能应对快速的需求变化，以交付客户满意的软件为最终目标，其中 Scrum 就是实现敏捷开发的标准和流程之一。 

2、Scrum

Scrum 就是实现敏捷开发的标准和流程之一，这个必须掌握，要不然后面的实战会有点蒙圈，大家如果对 Scrum 非常清楚，这部分内容可以直接跳过。

Scrum 主要术语：

• 产品建议表（Product Backlog）：整个项目被切分成许多Backlog并形成研发团队的原始工作任务池；

• 用户故事（User Story）：团队从技术的角度对Backlog的一种细化与分解并可投入开发的产物；

• 任务（Task）：比User Story粒度更小的任务；

• 每日的工作会议（Sprint Daily Standup Meeting）；

• 看板（Kanban）：一个可以写字的白板，用于展现项目进度等；

• 时间燃尽图（Burning Down Chart）：用于管理任务的进度，剩余量工作的一张图。

Scrum 的三个角色：

• 产品负责人：需求方，提出需求，能对功能流程，业务流程拍板的人。

• 团队负责人：负责解决团队问题，领导项目。

• 项目执行人员：开发项目一般包括前后端开发、UI、QA等。

Scrum 的三个工件：

• 产品建议表（Product Backlog）：头脑风暴，如果产品负责人对产品需求非常清楚，就可以省略这个步骤，开发一个原则“先紧后松”， 必须先把需求了解清楚，这里产品负责人可以召集技术团队对其需求进行公开征求意见，最后输出一个产品建议表。

• 产品需求表（Release Backlog）：产品负责人对产品建议表进行筛选，做减法提炼最核心的需求。在确定了需求后，这个时候由团队负责人进行输出技术方案文档，这里就和传统的瀑布流一样了，该有的文档都必须有了，必须由团队负责人和产品负责人确定好需求，包括业务逻辑，功能流程等。

• 时间燃尽图（Burning Down Chart）：时间燃尽图是 Scrum 的精华，通过该表格可以可视化任务的时间进度，每天按照任务完成度更新剩余时间，或者增加时间（例如发现一个技术难点，团队成员请假等要增加开发时间）。

Scrum 运作框架：

前方高能，这个图非常重要！！！ 掌握了这个，就知道敏捷是怎么玩的，里面包含 4 个阶段（需求梳理、任务拆分、迭代开发和总结回顾）和 5 个会议（需求评审会、计划会、每日站会、演示会和回顾会）。

什么，还是看不懂这个图？我简单串一下：

• 需求梳理：我们开始和产品梳理出需求，将需求落入需求池，然后再将这次需要迭代的需求，通过需求评审会进行评审；

• 任务拆分：需求评审完毕后，我们会再开一个计划会，对任务进行拆分，即初步评估每项任务的工时，然后根据大家的时间，将任务拆分到本次迭代中；

• 迭代开发：本次迭代任务确定后，进入迭代开发，我们会通过每日站会，保证项目进度；

• 总结回顾：开发完后，会开个演示会（评审会），业务方会验收产品，项目全部结束后，会再开个回顾会（反思会），总结项目经验。

大家可能会说，这还不简单，那我抛 2 个问题：

1. 任务拆分中，你都没进行方案设计，是如何评估工时的呢？

2. 本周五项目上线了，你可能连下个迭代的需求都不知道，下周一你能正常开下一期的迭代会么？

这两个问题，你要是能回答上来，证明你项目管理还有些本事，后面的实战会告诉你答案。

3、项目实战

敏捷的基础其实不难，但是当结合具体实践，还是会遇到很多问题，我之前带领团队同学走敏捷，也是摸爬滚打几个月，才把这套敏捷流程跑通，下面就以之前做的海外电商 ShareSave 项目为原型，给大家讲讲我们如何实践敏捷。

1）需求池

为了明确 ShareSave 存在哪些问题，团队成员通过头脑风暴的方式，将自己的想法通过卡片的方式展现出来，然后进行投票筛选，流程如下：

• 核心流程：产品负责人先将 ShareSave 整个的拼团流程，包括开团、分享、下载和支付等12个核心流程，用蓝色卡片贴成一条水平直线；

• 优缺点描述：大家对对这12个核心流程，说明每个流程存在的优点和缺点，优点用绿色卡片表示、缺点用黄色卡片表示；

• 情感曲线图：根据优缺点卡片个数及重要程度，将绿色卡片多的流程上移动，并将黄色卡片多的流程下移，形成一条上下波动的曲线；代表用户使用产品时的心情曲线，越高代表体验越好，越低代表体验越差；

• 流程建议：针对曲线中突出的问题，大家给出自己的想法和改进意见，通过红色卡片表示；

• 投票表决：团队成员每人5票，用绿色圆点表示，然后贴到红色的卡片上，票数最多的红色卡片就是比较好的建议。

温馨提示：这个只是收集需求的一种方式，大家可以借鉴这种玩法，很有意思，当然我们也可以跳过需求收集，让产品和业务方确定需求即可。

产品负责人根据 ShareSave 目前的“痛点”，结合团队成员的意见，并结合运营和竞品调研，输出如下产品代办列表。需要重点强调一点，为了更好满足整个迭代的节奏，产品负责人需要整理出至少满足2个迭代的需求，来保证整个项目的正常迭代开发。 

产品负责人对产品代办列表进行筛选，做减法提炼最核心的需求，在输出产品需求表的过程中，产品负责人需要和项目负责人进行沟通，确保梳理的需求能基本满足一个迭代，同时项目负责人也需要对需求进行初步的方案评估，包括业务逻辑和核心功能流程，如果发现有些需求的工作量比较大，需要对需求进行拆分和取舍。这个流程会比较长，可能会反复几次，最后就会输出最终的产品需求表。

2）任务拆分&日常迭代

梳理完本次迭代的需求后，会举行迭代会议，该迭代会议主要有3个主要事情：

• 决定本迭代要做哪些需求，也就是 What To Do；

• 将需求进行任务拆分，并将任务录入 TB，每个任务需要明确责任人,也就是 How To Do，以及 Who To Do；

• 对任务进行排期，确定任务是否有人力瓶颈，如果存在人力瓶颈，调整任务优先级，将不紧急的列入下一个迭代。

迭代会结束后，大家将自己的任务写入卡片，然后贴到任务看板上，任务看板，我们有如下3条规定：

• 看板中任务进度的更新，全部通过团队成员自己维护；

• 通过每日站会，实时更新看板中的任务进度，并周知任务下游的同学；

• RD 提测前，需要进行“冒烟自测”（ DoD 之一），然后才能提测给 QA。

冲刺燃尽图是 scrum 的精华之一，通过该图表可以可视化任务的时间进度，如果实线在虚线下面，表示任务完成度超前，如果实线在虚线上面，表示任务有延期风险。 

每日站会是为整个团队最有效的沟通方式，会议不超过 15 分钟，需要回答以下 3 个问题：

1. 你昨天做了什么？

2. 今天打算做什么？

3. 有没遇到什么困难？

3）验收&总结

当迭代结束，且在产品正式交付前，需要全队成员进行迭代评审，即对产品功能进行演示，然后团队成员会充当用户的角色，体验本次迭代完成的所有的功能，并给出相关建议。

当迭代评审结束后，需要对本次迭代进行迭代回顾，为了避免会议过多，我们团队每两个迭代进行一次回顾，回顾时间一般 1 小时左右，本次分享的回顾方式为“海星回顾”。

温馨提示：总结回顾的方式很多种，“海星回顾”是一种玩法，你也可以百度更多玩法。

“海星回顾”是将一个平面区域划分为5个象限，形状类似于海星，包括以下5个方面的内容：

• 继续保持——团队做的好，并且能从中发现价值的活动；

• 少做一些——一些已经做了的，虽然能看到一些收获，但是宁可少做一点的事；

• 多做一些——一些已经做了的，而且已经被确信做的多就能带来更大的收益的事；

• 停止做——那些不能带来收益，甚至更糟，正在阻碍团队前进的事；

• 开始做——一个全新的想法，或从其他地方看到，并且能帮助团队的想法。

团队成员以轮流发言的方式，将每个人的想法通过卡片的方式贴到对应的象限，大家对上述观点进行投票（卡片上的小绿点），并选出核心的建议（卡片上的小红点），最后由项目负责人总结并讨论改进的地方，由大家一起给出问题的解决方案。

4）如何控制迭代节奏

如果一轮迭代完毕之后，再开始梳理第二轮迭代的需求，那么第二轮迭代在进入开发前，估计还需要花费至少 3 天的时间去梳理需求、UI 交互以及方案评估等。目前我们的迭代周期为 2 周，为了解决两个迭代的时间衔接问题，我们团队制定了一套迭代日历，全是大家摸索出来的：

• 迭代第一周周二，开始开迭代计划会，拆分需求，确认排期；

• 迭代第二周周二，项目负责人需要提前评估下一轮迭代的需求，然后让 UI 出交互设计、RD 评估设计方案；

• 迭代第二周周五，项目负责人需要确定下一轮迭代需求的初步方案，便于在迭代计划会时，能准确并快速进行任务拆分，提前规避风险；

• 对于回顾会，为了尽量少打扰大家，我们是每 2 个迭代回顾一次。

通过这个迭代日历，就可以回答最开始提的两个问题，我们是在第二周进行方案设计，第三周周一就可以直接开迭代会，所以能完美衔接两个迭代，且能避免没有进行方案设计，就随意给出项目排期的情况。 

5）敏捷是万金油么

敏捷如果用好了，真的可以提高产研效率，拥抱变化、快速迭代，但是敏捷也不是万金油，需要满足天时地利人和，条件有些苛刻，下面是一些经验之谈：

• 老板大力支持：这个是一切的前提，比如我们之前是老板大力推广敏捷，全部门就能搞起来，后来老板方向变了，敏捷就不搞了；

• 项目能支持小步迭代：敏捷比较适合探索类的项目、或者是 APP 之类的迭代快的项目，因为需求非常容易变更、任务好拆分；如果是传统项目，需求一开始就定好了，任务也不好拆，你就还是老实用瀑布模型吧；

• 团队成员闭环：敏捷的团队成员，需要全部 follow 到该项目中，因为迭代节奏很快，任何一个人不可能再去搞别的项目，否则他会成为敏捷的瓶颈；

• 团队成员目标一致：因为迭代节奏非常快，所以产品、研发、测试和UI必须目标一致，如果有任何一位同学心不齐，敏捷也很难搞起来。

我理解的敏捷，更像是一把利刃，用好了能威力无比！但是这把利刃并不是所有人都用得好，也不是任何场景都需要这把利刃，很多时候，我们只需要一把菜刀。

四、如何写好文档

1、确定主题

很多同学写文章时，文章风格千篇一律。

其实写文章前，你需要明确你的读者群是谁，老板？项目成员？广大用户？面对不同的读者群，你的文章风格会很不一样：

• 如果你的读者是领导，比如日常的工作汇报，内容需要简明扼要，突出重点，要知道领导都很忙，没时间看些长篇大论的内容；

• 如果是需求评审，你的读者群是研发和测试，你需要详细讲述每个需求点，尽量不要产生分歧；

• 如果你的读者是广大用户，你的文章内容必须充实，且浅显易懂，最主要是能让他学有所思、读有所获，你才能吸引更多流量。

所以说，文章落笔之前，先确定你的读者群，文章类型是技术分享、业务实践、团队管理，还是技术理论，不同类型的文章，写作方式也千差万别。

2、文章标题

如果你的文章需要引起更强的关注度，好的标题非常重要。

比如我之前写公众号，最开始写了一篇敏捷开发的文章，标题为“敏捷开发流程讲解”，结果阅读量只有几十，后来改成“只会用传统开发模式？10 分钟教你玩转敏捷！”，效果就完全不一样。

但如果是需求、方案评审等，啥标题都不重要，因为你的目的不是为了吸引关注度。

3、文章内容

如果把一篇好的文章比喻成一个美女，那么文章标题、排版、配图都是她漂亮的外衣，这个“美女”是否真的很漂亮，主要看内容。

可能有同学会说，我就高中写过作文，现在除了写项目方案，我都好久没写过文章了，现在让我写，我都不知道怎么下笔，别着急，下面就告诉你方法。

确定写作主题后，我们一定需要先列提纲，一定要带着问题，你的提纲就很容易列出来。

这个框架就非常清晰了，所以当大家不知道如何写文档，不妨问自己几个问题：

1. 是什么？

2. 为什么？

3. 怎么办？

4. 这么做以后有啥结果？

有了提纲，就可以开始写了，如果文章内容比较长，建议采用“总-分”结构，让读者能一开始就能 Get 到你要讲的内容，然后再依次展开。

文章写完后，还需要检查错别字、语句不通顺等问题，并对文字进行打磨。我平时每写完一篇文章，都会再修改 3 - 4 遍，最后从头到尾再读一遍，确认没有问题后，才会定终稿。

所以，从现在开始，不会写文章不应该成为你的借口，一起行动起来！

温馨提示：写文章其实也是一个熟能生巧的过程，前期可能会比较困难，你多写几篇，应该就能驾轻就熟。然后，我认为文字功底也非常重要，但是这个并非一朝一夕，我们不要求人人都是鲁迅，但是中国文化博大精深，基本的文学素养，大家还是要有的。

4、文章排版

文章排版重不重要，我感觉太重要了，你给我一个乱糟糟的排版，我看的心情都没有了，就好比一道菜，看的像一坨，你还有吃的欲望么？

那什么是好的排版呢，我简单列一下：

• 避免低级错误：我们要避免出现错别字、词语误用、标点符号错误等现象；

• 首行不用缩进：小时候老师经常教我们首行缩进，但是个人建议不缩进，因为你不是写论文；

• 段落区分：通过“空一行”来区分段落，并且每个段落的文字不要过长，否则你会发现一堆的文字堆砌在一起，密密麻麻的让人失去继续阅读下去的兴趣；

• 保留空格：当英文、数字和中文相遇的时候，他们之间要留一个空格，这样阅读起来会更舒适；

• 专有名词：很多人把 Java 写成 JAVA，MySQL 写成 mysql，会显得你很不专业。

首行缩进和段落区分：

当英文、数字和中文相遇的时候： 

比如一些专有名词： 

5、主题美化

写好了内容，很多人又会问了，我不是专业编辑，不知道怎么美化文章样式，咋办？

配图可以使用 draw.io 会话，地址：Flowchart Maker & Online Diagram Software

推荐大家使用 Markdown 语法来编辑文章内容，作为程序员我们很有必要去了解 Markdown 语法。把你写好的 Markdown 内容粘贴到 https://www.mdnice.com/ 即可完成主题美化。

五、项目风险控制

1、项目中常遇到的风险

产品：这个项目非常着急，业务方希望月底能使用，已经完成需求评审，你看今天可以出排期么？

我：我靠，既然项目这么重要，那为啥不提前说呢，还给我整个倒排，这不坑我们么？

产品：昨天和业务方沟通，他们想改成另外一种方式，我感觉改动应该不大，要不帮忙改一下呗。

我：你又不是研发，你咋知道改动大不大，要不你来？

产品：我发现有个地方需要加个功能，这个能加么？

我：怎么又加需求，前两天不是刚加了么，这还有完没完。。。

领导：怎么这个项目功能越做越多，时间越做越长，都临时给你加了好几个人了，你说说怎么办吧。

我：嗯嗯。。。这个，之前的方案设计有问题，还遗漏了很多功能，所以。。。哎！

除了上面几种，还存在其它项目风险情况：比如工时评估乐观、小组同学延迟暴露问题、中途其它高优需求插入、测试一堆Bug、上线后出现严重的线上问题、用户体验不好等，下面给大家大白话解答一下。

2、项目风险控制五把斧

第一把斧：方案设计要完备

方向不对，努力白费，如果连技术方案设计都有问题，你这个项目十有八九会延期。

之前在百度工作，一个半月的项目，方案设计至少需要2周，甚至很多时候方案设计和项目开发的时间是五五开。

我们不可能让所有公司的方案设计做到和百度的一样，但是多年的工作经验告诉我，方案设计多花时间，肯定不会错，大致需要做到以下几点：

• 概要设计要全面，不要遗漏功能；

• 详细设计要考虑清楚，避免给自己埋雷；

• 技术方案评审，大佬把关，方向不会跑偏；

• 上线方案要考虑，因为上线方案也会包括功能开发，比如白名单，小流量等。

基本做到以上几点，胸有成竹，你的项目其实就成功了一半。

第二把斧：项目排期留Buffer

重要的事情说三遍，项目排期要留Buffer！留Buffer！留Buffer！

不要老实巴交的，评估10天的工时，就给自己排10天，你平时不开会么？不和产品Battle么？不处理线上问题么？能保证所有的工作都能按部就班么？

这就是为什么要给自己留Buffer，我们宁愿把项目提前做完，也不要到后面加班赶进度，下面告诉大家项目排期要注意哪些点：

• 项目预留Buffer，每天预留20%-30% Buffer，比如开发4天，你给自己排5天；

• 不要遗漏联调时间；

• 上线也有时间，不要傻傻给自己排1天，大项目1天上不完；

• 预留线上小流量时间，或者产品验收时间，否则上线后直接交付，出了问题，项目白做。

第三把斧：不要怕需求变更

记住，没有一成不变的需求！  产品不是神，她不可能把所有的细节都考虑清楚，所以你要有心理预期。

那需求变更，或者新增需求，怎么办呢？也简单给大家唠唠：

• 切记不要自己一个人默默承受！

• 需求变更不要随便答应产品，先评估详细改动；

• 新增需求增加开发工时，可以砍掉非高优需求，如果只增不减，那就加排期；

• 需求变更要立规矩，让产品需求变更有成本，比如同步风险、发邮件等。

这个其实很灵活，毕竟我们和产品合作，关系不能僵，有的需求改动小，就顺手改了，要是改动大，可以再讨论一下，看有没有更优的方案，如果实在不行，那就增加工时，原则上上线前就不要变更需求，但是特殊情况，也需要特殊考虑。

第四把斧：每日同步风险

项目正常进入开发，我不怕需求变更，也不怕测试提的Bug多，怕就怕小组同学不告诉你风险，最后给你憋大招，然后一脸委屈“我怕打扰你，本来想自己解决，结果搞了几天没有搞定”，我只想说“你咋不早点打扰我呢？”

所以这就是为啥要开项目站会，建议每天都开，时间控制在10-15分钟即可，会议只讨论进度、问题和风险，不过细节。

第五把斧：详细的上线方案

如果项目比较复杂，上线方案需要尽可能详细，如果出现重大线上事故，之前的努力真的就白费了，需要注意以下几点：

• 项目上线要考虑上线顺序，因为系统存在依赖关系；

• 要提前评估上线风险点，比如核心支付环节；

• 上线方案要尽可能详细，每个环节明确责任人；

• 上线前，需要测试准备好线上回归Case；

• 上线后需要小流量验证，或者灰度等；

• 不要忘记写回滚方案，要是能一键开关，最屌！

最后送上一首打油诗：

• 技术方案设计全，前期苦痛后期爽，

• 项目排期要预留，心中有粮不会慌。

• 需求变更不可怕，产研一起共协商，

• 上线方案要详细，出了问题都白忙。

• 风险每日要同步，不要最后憋大招，

• 一切尽在帷幄中，我是风控好榜样！