如何做好项目管理

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

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

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

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

一、项目流程

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

项目管理过程中,需要借助项目管理工具,我们以TB(Teambition)为例。 

1、产品规划

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

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

下面是产品规划要求:

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;

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

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

最后送上一首打油诗:

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

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

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

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

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

  • 一切尽在帷幄中,我是风控好榜样!

猜你喜欢

转载自blog.csdn.net/qq_35029061/article/details/126740166