如何做好项目管理

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

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

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

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

一、项目流程

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

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

1、产品规划

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

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

下面是产品规划要求：

2、需求评审

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

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

下面是需求评审要求：

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

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

3、研发阶段

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

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

项目排期每天不要排满，建议预留 20% buffer;
如果项目时间紧，可以采用分批提测的方式；
排期要有里程碑，开发、联调、提测、上线、验收等；
项目排期不能仅到上线阶段，还需包括线上灰度和项目验收；
前端排期依赖UI设计。

下面是项目排期要求：

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

4、测试&上线阶段

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

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

测试环节需要大家一起过测试Case；
提测前，有的项目还需要做项目演示；
上线前，需要一起过上线方案，突出风险点；
上线后可能需要小流量验证，或者灰度；
有的项目还有项目验收环节，最后才全员开放。

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

5、需求变更

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

下面是需求变更要求：

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

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

产品规划就像是海上的灯塔，不能乱打一气；
需求文档一定要尽可能详细，拒绝无原型的需求评审；
技术方案是整个项目的灵魂，这块多投入时间绝对不亏；
项目排期有里程碑、有buffer，排期需包括线上灰度和项目验收时间；
Code Review、测试Case都不能少；
上线方案要预知风险，为线上的稳定性保驾护航。

二、每日站会

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

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

昨天做了什么？
今天打算做什么？
遇到什么问题？

备注：站会时间早上或晚上最佳，方式比较灵活，前期可以每周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 个问题：

任务拆分中，你都没进行方案设计，是如何评估工时的呢？
本周五项目上线了，你可能连下个迭代的需求都不知道，下周一你能正常开下一期的迭代会么？

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

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 个问题：

你昨天做了什么？
今天打算做什么？
有没遇到什么困难？

3）验收&总结

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

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

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

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

继续保持——团队做的好，并且能从中发现价值的活动；
少做一些——一些已经做了的，虽然能看到一些收获，但是宁可少做一点的事；
多做一些——一些已经做了的，而且已经被确信做的多就能带来更大的收益的事；
停止做——那些不能带来收益，甚至更糟，正在阻碍团队前进的事；
开始做——一个全新的想法，或从其他地方看到，并且能帮助团队的想法。

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

4）如何控制迭代节奏

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

迭代第一周周二，开始开迭代计划会，拆分需求，确认排期；
迭代第二周周二，项目负责人需要提前评估下一轮迭代的需求，然后让 UI 出交互设计、RD 评估设计方案；
迭代第二周周五，项目负责人需要确定下一轮迭代需求的初步方案，便于在迭代计划会时，能准确并快速进行任务拆分，提前规避风险；
对于回顾会，为了尽量少打扰大家，我们是每 2 个迭代回顾一次。

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

5）敏捷是万金油么

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

老板大力支持：这个是一切的前提，比如我们之前是老板大力推广敏捷，全部门就能搞起来，后来老板方向变了，敏捷就不搞了；
项目能支持小步迭代：敏捷比较适合探索类的项目、或者是 APP 之类的迭代快的项目，因为需求非常容易变更、任务好拆分；如果是传统项目，需求一开始就定好了，任务也不好拆，你就还是老实用瀑布模型吧；
团队成员闭环：敏捷的团队成员，需要全部 follow 到该项目中，因为迭代节奏很快，任何一个人不可能再去搞别的项目，否则他会成为敏捷的瓶颈；
团队成员目标一致：因为迭代节奏非常快，所以产品、研发、测试和UI必须目标一致，如果有任何一位同学心不齐，敏捷也很难搞起来。

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

四、如何写好文档

1、确定主题

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

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

如果你的读者是领导，比如日常的工作汇报，内容需要简明扼要，突出重点，要知道领导都很忙，没时间看些长篇大论的内容；
如果是需求评审，你的读者群是研发和测试，你需要详细讲述每个需求点，尽量不要产生分歧；
如果你的读者是广大用户，你的文章内容必须充实，且浅显易懂，最主要是能让他学有所思、读有所获，你才能吸引更多流量。

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

2、文章标题

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

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

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

3、文章内容

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

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

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

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

是什么？
为什么？
怎么办？
这么做以后有啥结果？

有了提纲，就可以开始写了，如果文章内容比较长，建议采用“总-分”结构，让读者能一开始就能 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；
上线后需要小流量验证，或者灰度等；
不要忘记写回滚方案，要是能一键开关，最屌！

最后送上一首打油诗：

技术方案设计全，前期苦痛后期爽，
项目排期要预留，心中有粮不会慌。
需求变更不可怕，产研一起共协商，
上线方案要详细，出了问题都白忙。
风险每日要同步，不要最后憋大招，
一切尽在帷幄中，我是风控好榜样！