云之讯：对于互联网项目管理中的PDCA

1. 互联网产品项目管理现状

根据Standish Group发布的报告，在2012年所研究的IT项目中，有18%的项目是失败的，43%的项目是有问题的，只有39%的项目是成功的，能够同时满足时间、范围和成本的要求。也就是说，在2012年有61%的项目是没有达成项目目标的。影响项目成功的因素很多，如不清晰的需求，频繁的需求变更，不合理的进度计划，低效沟通，风险管理的缺失，不稳定的项目团队等。

对单个问题进行分析时发现每个都能被解决，但当问题交织在一起时，整个项目就像陷进了焦油坑，如Brooks在《人月神话》中所说：“表面上看起来好像没有任何一个单独的问题会导致困难，每个都能被解决，但是当它们相互纠缠和累积在一起的时候，团队的行动就会变得越来越慢。对问题的麻烦程度，每个人似乎都会感到惊讶，并且很难看清问题的本质。”

2012年IT项目执行结果

而在互联网行业，产品功能需要快速迭代以解决用户痛点问题，并且需要根据用户对产品的反馈快速对功能做出调整，因而需求很难在项目初期被准确定义。

为了持续交付对客户有价值的功能特性，互联网产品的项目管理多采用敏捷开发，以“小步快跑”的模式来适应不断变化的需求。但每个项目团队所处的行业不同、公司文化不同、人员素质不同及对“敏捷”的理解程度不同，互联网型项目管理还存在很多问题，比如：

·迭代内需求模糊

·项目进度延迟严重

·缺乏风险管理意识

·项目团队不稳定

·进度与问题沟通不畅

·产品质量不高

如何解决这些棘手的问题，成为很多项目经理关注的焦点。

2. PDCA循环简介

如图2所示，PDCA是Plan(计划)-Do(执行)-Check(检查)-Act(行动)的首字母缩写，来源于质量管理领域，由著名统计学家休哈特 (Walter A. Shewhart)在20世纪30年代提出构想，后来由戴明( W. Edwards Deming)完善并加以广泛宣传，运用于持续改善产品质量，因此PDCA有时也被称为戴明环或休哈特环。

PDCA 循环是一个持续改进的过程，它是针对在计划和执行过程中遇到的问题进行分析，并通过制定相应的解决措施，在下次计划和执行中进行改进，从而达到流程和质量持续提高的目的。如下图所示，下一阶段在改进上一阶段问题的基础上执行，因而可以达到一个更好的水平，这四个过程周而复始，整个水平呈阶梯上升的趋势。

PDCA循环是一个发现问题、解决问题的过程，其适用范围不仅仅在质量管理领域，它的思想同样可用于互联网项目管理。

3. PDCA在项目管理中的运用

互联网产品的项目周期通常比较短，从需求导入到功能发布一般在2~4周，有的互联网公司可以做到每周发布新版本。频繁的项目需求导入以及固定的项目团队能够保证PDCA循环可以很容易的应用到项目管理中去，下面将探讨在项目管理中应用PDCA时需要注意的地方。

3.1 Plan阶段需要注意以下几个方面

·清晰明确的需求是计划的前提。

很多项目经理在需求没有弄清楚之前，因迫于管理层的压力而匆匆做计划，结果执行的时候发现很多问题，最后做出来的功能并不是产品经理想要的。如果在做之前没想清楚产品要做成什么样，那么如何保证开发出来的产品符合产品经理的要求。

需求清晰明确并不是要求一定要有详尽的需求规格说明书，因为那需要花费大量的时间和精力去维护这些重量级的需求文档，但是对于需求，产品经理、项目经理、开发团队和测试团队至少要有清晰一致的理解，即大家对需求的认识是一致的。

有了对需求一致的理解，才可以准确地将功能需求转化为设计、开发和测试任务，进而对每个任务进行准确的时间估算。通过产品需求文档结合产品原型的方式可以帮助项目团队更快更准确地理解产品需求，做到需求清晰明确其实并不困难。

·任务分解谁执行谁估算。

在很多公司，项目执行不好的原因之一就是从需求分解、任务拆分、工期估算、任务排期都是项目经理一个人依据自己的经验搞定，但是项目经理又不负责具体任务的执行，大多数情况下在做计划时往往很乐观，任务工期估算的偏少，结果就是项目总是处于延迟的状态。团队为了赶进度经常加班，如果再碰到一些技术难题，延迟就更严重了。

因此在计划阶段做工期估算时，需要让具体执行任务的人依据自己的知识和能力去估算，项目经理根据自己的经验可以针对估算结果做调整，但是调整时需要向任务执行的成员说清楚为什么做调整。敏捷开发中的“扑克法估算”是让每个项目成员都对同一个任务进行估算，这样得出的结果比较准确，如果有条件可以尝试这种估算方法。

·项目管理也是项目任务。

第一次担任项目经理的时候，我在计划里给自己安排了很多开发任务，基本上在工作时间都安排了开发任务，天真地认为项目管理就是每天与团队成员开个会了解一下进度，不会耽误太多时间，更不会影响项目进度。结果到了项目执行的时候，我需要花很多时间去和每个人沟通进度和问题，比如：每天组织项目晨会、组织设计评审会、整理会议纪要、与产品经理讨论需求有争议的地方、与采购同事沟通设备的采购进度、向领导汇报进度、处理突发问题、组织团队活动等等。

后来学习PMBOK时了解到项目经理75%~90%的时间都是在沟通，项目经理不在沟通就在沟通的路上，去沟通计划、沟通进度、沟通问题、沟通风险等等。所以，项目经理的时间就是被各种沟通碎片化，如果在计划时还要像其他项目成员一样排任务，那估计只能在加班时候完成了。所以，在项目计划里面一定要把项目管理工作当成一项重要的任务，它也需要时间。

·风险管理不可缺。

为什么要有风险管理计划，要回答这个问题，首先要想清楚我们做好的项目计划(准确说应该是进度计划)是在什么情况下制定的。我们假设项目组成员都不会生病、家里有事、不会离职，因此可以每天8个小时工作;我们假设项目里的技术难题可以在估算的时间内解决，不会影响进度;我们假设采购的设备可以在和供应商谈好的时间内交付，保证测试环境可以按时搭建;我们假设项目组成员小A每天心情都很好，可以在每天6个小时高效工作。

从这几点我们可以看出，我们的项目计划很多都是基于假设来做的，我们认为这些假设都是成立的，那么问题来了，当假设不成立的时候我们该怎么办?这就需要风险管理计划了，一般来说，在计划阶段，可以采用专家判断、头脑风暴和检查表等工具来识别风险，并通过定性分析和定量分析形成风险登记册，最后针对每个风险制定相应的应对措施。通过风险应对计划来解决假设不成立的问题，将实施过程中意外情况对项目造成的影响降到最低。

3.2 在Do阶段需要注意的几个方面

·控制需求变更。

在项目执行过程中，需求变更常常会会引起设计返工或项目进度计划的变更，频繁的变更会导致项目计划不具备可执行性，另外也会对团队士气造成影响，团队会认为反正计划会变，做了可能也是白做。在互联网项目中，2~4周的项目计划一般情况下都不应该进行需求的变更，如果有特殊情况必须变更，建议重新制定项目计划以保证项目计划具备可执行性。

·确保沟通高效。

项目经理75%~90%的时间都是在沟通，同时也要给团队创造一个便于高效沟通的氛围，尤其要提倡“面对面沟通”。在敏捷项目管理中，每日站立会是很好的方式，每天固定的时间，每个人通过回答“昨天做了什么”、“今天准备做什么” 和“有什么障碍”这三个问题向团队其他人同步自己的工作进度和问题，简单的问题在站立会上就会马上解决。

除了站立会外，很多成员习惯于QQ/RTX上说问题，有的甚至通过邮件来问问题，一个简单的问题当面沟通三分钟就解决了，结果在QQ上说了一上午也没搞定，所以项目经理要鼓励大家在有问题时尽量当面沟通，能“动嘴”的坚决“不动手”，做到沟通基本靠“吼”。

3.3 在Check阶段需要做什么

PDCA 循环中的Check可对应于敏捷项目管理中的项目回顾会议，团队通过对本次迭代的完成情况进行回顾，找出本轮迭代中团队中哪些方面做的好，哪些方面需要改进。在回顾会议上需要注意的是要营造一个开放安全的氛围，大家可以放心说问题而不用担心说问题会导致领导不高兴，从而影响自己的绩效，所以有的团队在做回顾会议之前会做安全测试，即大家对这次会议的安全性进行不记名投票，如果安全性过低，则ScrumMaster会将领导请出会议室，以保证大家可以放心说问题。

会议最后会选出在这次迭代中TOP 3 GOOD THINGS和TOP 3 NEED IMPROVEMENT，会议之后需要将这3件做的好的方面和需要改进的三个方面记录下来，以鼓励团队在下一次迭代中继续保持好的方面，改进不好的方面。

3.4 在Act阶段需要注意的两个方面

·确保改进措施可行。

在回顾会议上会选出3个需要改进的方面，但是具体的改进措施有时在回顾会议上不会制定出来，会后可组织团队专门针对问题改进措施进行讨论，制定可行的改进措施，可行的意思即为在下一次迭代中团队可以做到。如果改进措施团队无法做到，则改进没有意义。

·督促改进措施落实。

有些敏捷团队按照敏捷实践组织了项目回顾会议，选出了需要改进的方面，也制定了相应的措施。但是在下一次迭代中，没有人监督这些改进措施的落实，团队仍然按照上一迭代的方式做事，项目回顾会议完全沦为一种形式。PDCA是一个通过发现问题和改进问题达到持续改进目的的过程，如果只有发现问题而没有改进问题，则谈不上改进，更没有持续的项目管理水平的提高。因此，项目经理需要在每个迭代中监督上次回顾会议上制定的改进措施的执行情况，保证制定的改进措施执行到位。

4. 总结

大多数IT项目在项目收尾时都无法达到同时满足时间、范围、成本三方面预期的项目成功标准，在项目管理中通过引入质量管理领域的PDCA循环，可使项目管理水平持续提高，从而保证项目具备越来越高的成功率。

在Plan阶段，制定计划前需要确保所有的需求都清晰明确，还要保证由具体的任务执行人来做任务分解和工期估算，把项目管理作为重要的项目任务，最后要做好风险管理计划;

在Do阶段，需要控制需求的变更，同时要营造高效沟通的氛围;

在Check阶段，总结团队在本次迭代中做的好的方面和做的不好的方面，针对做的不好的方面制定相应的改进措施;

在Act阶段，有时需要适当修正改进措施以确保改进措施可行，最重要的是要监督改进措施真正执行到位。