被滥用的项目管理
项目管理,在我看来,这个词已经被大多数人用滥了。的确,什么样的事情只要有起点和终点,你都可以简单的称其为项目。所以和很多人聊天的场景下,你经常可以听到这样的对话:
最近在忙什么呢?
没啥,忙一个项目呢
啥项目啊?
噢,公司想开个年会,选个场地定个饭!
的确,通俗意义上来说,这也是一个项目。按照“传说中权威机构”PMI对于项目管理的定义:
项目是为了创建独特的产品、服务或成功而进行临时性工作
传统的瀑布型项目管理

我,曾经也是个项目经理,负责金融机构的一些项目的执行和落地。少说也得有快10年的项目管理经验了吧。而所做过的那些项目,可能在复杂度要比上面例举的定个场地定个饭 (可能也不一定) 要高,至少对于项目的几大特征还是了解和运用的非常透彻的。

- 进度管理:设立好项目执行的时间轴,根据不同的工作流(Workstream),按照甘特图的方式进行排布,并保证同步进行的工作的可控以及高效。而关键路径这种东西,是根据不同节点的重要程度排布的。
- 资源管理:从最初写项目方案(Business Case)开始,拿项目预算直到项目执行过程中对于项目成本和预算的把控。
- 风险管理:这东西只有遇上了才能应对,但是有些风险是一开始就可以判断到的,比如说合同风险,合规风险等。基本上这些风险都绕不开,坦然面对探讨个解决方案就好。
- 干系人管理:我也不知道这中文翻译的这么拗口,其实用英文说就是 Stakeholder Management,这部分其实简而言之就是“见人说人话,见鬼说鬼话”
这一套流程做下来,按照项目规模的大小,最终的组织过程资产(别蒙,人家PMI就爱这么念,其实就是最后留下的遗产)往往非常多,从项目期初的计划,开始的需求文档,执行过程中的变更,之后的测试安排,投产安排,上线安排,以及最终投产后的回顾总结等等,一堆东西可以把你无线键盘鼠标的电全部用完。
敏捷性的项目管理

传统的项目管理可能已经不太适应当下快节奏的需求,尤其是在互联网大浪潮的冲击下,更快,更迅速的项目往往能够达到最大的效应。
Agile这个词最早是出现在软件开发行业,翻译成中文叫做敏捷性开发,之后才引发了APM敏捷项目管理这个概念。它其实和开发相类似,运用迭代的方法进行项目管理。每个迭代都由项目团队审查和评判;从迭代的评判中获得的信息用于决定项目的下一个步骤。通常来说,每个项目迭代通常是安排在两周内完成。(在我工作的单位,装逼的人们喜欢叫这个为Sprint)
敏捷项目管理也是有些特定名词的:
- Product Backlog:项目需求池,也可以理解为项目的待办事项列表。这个列表标明了待开发的任务和其任务的优先级。而相对于传统的Project Manager,在敏捷开发中,也会有个类似的角色,叫做Scrum Master(或者叫做Product Owner),他负责对所有待开发事项的排布、分解成更为细致的任务。
- Story Board:故事版是任务流转的可视化窗口,一般有“待开发”,“开发中”,“待测试”,“返工”等几个区块。所有任务一目了然,以供任何项目成员看到。
- Burndown Chart:燃尽图。前面说到敏捷项目管理是以每个开发周期来进行迭代的,在一个周期(Sprint)里面,人/时是固定的值,在这个时间框架下充分安排开发任务,每天进行时间结算,并且绘制时间燃尽图来提供给项目组成员时间进展的通告。通过燃尽图可以中时间和预期的契合点,可以判断安排的合理性和预测下一个Sprint调整的方向。
我自己用Trello,也参与了Setapp的Trello看板,下面这张图就是Setapp对于安排软件上线的一张很明确的Story Board。

中西医之争的孰优孰劣
我们通过用几张图来直观的感受一下吧:
传统项目管理
按照PMBOK的内容,项目管理应该长成这样(逼格真的可以):

它的特点就是严谨,每个环节都必须要进行严格的规划,而一旦在规划内发生变更,则需要根据变更流程重新审视规划。
敏捷项目管理
其简化了繁琐的流程和文档,主张沟通和交流。如果按照现在主流Scrum方法论的概述,就是简单、持续集成、不断交付、价值优先。所以画出来的图就是一个洋葱圈:

如果硬要总结,我的观点是(还是要有自己判断的嘛):
传统的瀑布式项目管理会要求提供风险登记表,并且记录风险应对措施和在处理已被识别风险及其根源方面的有效性,完成风险再评估和风险审计,直到风险被降到最低。
敏捷项目管理在项目没有正式结束前,交付产出是允许风险存在的,并且是根据风险的优先级来进行排期修复的。
因此,不同的项目管理框架,其实适用于不同的项目类型,切他们的容错程度也是不一样的。如果你要举办一场奥运会,那敏捷项目管理肯定不会被采纳的。而一般普通的项目,可能用敏捷项目管理成本更低,速度更快。
不论孰好孰坏,这些角色不能少
虽然存在中西医之争的嫌疑,但不论对于传统的瀑布式还是现在追求高效的敏捷式,在项目执行过程中,项目组中的有些角色特别重要,但现在却越来越不注重区分了:
- 项目组经理:Programme Manager,这可不是项目经理,因为对于大型项目来说,它其实是一个项目组,而旗下的子项才是真正意义上每一个独立的项目。所以总体上要有一个项目组经理。
- 项目经理:Project Manager,顾名思义就是对这个自己所负责的项目承担责任,按时按需完成任务的人。项目经理对项目组经理负责,而项目组经理则需全力支持项目经理。
- 业务分析师:Business Analyst,这个角色现在最容易和项目经理的角色重叠。大家都认为这样的人可有可无,可这种理解是大错特错的。的确这样的人本来就不多见,必须对于业务非常熟练,而对于技术也相当的精通。这样的人需要审慎的将业务的需求和开发的文档进行衔接和评估。
- 开发经理:Development Manager,一听这名字就是个IT,没错,这个开发部分就是由开发经理负责。他需要协调开发内部的资源,时间安排等以保证项目的交付。
- 流程分析师:Process Manager,这个就更少见了,因为对于整套流程管理有很强知识面的人就不是太多,而他的职责就是确保交付以后的项目在流程上也是最优的。而不是一个项目完工上线以后,整个处理流程反而更长了。
- 测试经理:UAT Manager,这个角色负责所有测试环节的工作,但至少在我现在工作的单位,我对于这个岗位是最不满意的。测试现在的确花里胡哨的名字很多,比如说:
— SIT:系统集成测试
— UAT:用户接受度测试(UAT里面还要绕圈圈呢)
— PVT:投产验证测试
最后来炒个菜吧
每篇博客总得说点有趣的东西,用一张表,来画一画两者的区别的,虽然结论可能偏向敏捷项目管理的,但过程中的好坏估计也可以直观反映当下的现状吧。
瀑布式项目管理
- 客人到餐馆点菜(新项目)
- 不确定客户想吃什么,就看大众点评推荐菜(用户往往提不出具体需求)
- 根据大众点评,点了10个菜(根据原型提需求)
- 后厨开始准备(项目启动)
- 根据客人的菜单配菜,炒菜(一切以需求文档为准,不会反复确认)
- 半个小时了,没有菜上桌,客人表示非常饿(项目启动很长一段时间对于客户来说啥都看不到)
- 再过了20分钟,10个菜一起上来了(项目最终一次性交付)
- 客人说,有几个菜不错,但有几个菜淡了,还有两个不够辣,另外两盘有点重复想换掉(客户是上帝,当然可以主动提需求变更)
- 这时候大堂经理来了说:嗯,不好意思,味道淡了可以加盐,不辣的可以加辣,但幻彩不行,已经炒了的菜也是有成本的(需求变更之复杂)
- 于是,后厨加了盐加了辣(用户妥协)
- 客人吃完表示不太满意,以后不来了(没有满足最终需求)
敏捷项目管理
- 客人到餐馆点菜(新项目)
- 不确定客户想吃什么,就看大众点评推荐菜(用户往往提不出具体需求)
- 根据大众点评,点了10个菜(根据原型提需求)
- 后厨开始准备(项目启动)
- 配菜、炒菜、先上了两盘,让客人尝尝味道(先提供可用实例给客户)
- 客人说还不错,后厨继续准备后面的菜,陆续上菜(不断迭代,不断测试)
- 上菜过程中,有几个菜淡了,让后厨加了点盐又上来了(敏捷的好处,可以不断测试需求变更)
- 又来了两盘,客户说不够辣,又让后厨加了辣(敏捷的坏处,需求无法提前明确,反复迭代也是成本)
- 到最后两盘了,客人表示要换菜,幸好还没开始炒(迭代的好处)
- 客人吃完表示味道一般般,但还是不错的(满足客户最终需求)
孰好孰坏,孰优孰劣,自行判断。