针对一位在系统工具上存在疑惑的公司高管提出的问题，我在回信中给出了如下的答复：

推广:
系统只是一个工具，如果希望提高开发的生产率，要对员工进行时间管理与项目管理的培训。
让员工理解为什么要这样做，才有动力改变以往工作习惯。

序

发完上面这封给某个研发总监的汇总邮件后，我想起一个月前，另一位研发总监看了我的WBS分享文章后问：“为什么你建议WBS可设置较大的颗粒度？与我的认知和做法相反。” 通过下面的一个案例，解释为什么研发型项目不同于实施项目，WBS的活动颗粒度不一定越细越好。

公司背景

案例公司人员三百人左右，为政府部门服务，主营软件产品和定制开发，在前段时间已经用工具做WBS管理: 对于实施项目，WBS管理问题不多，项目经理把一些主要部分分解到下面的组长，由他们再细分活动，要求这些成员每周在工时表按WBS填写完成情况,但研发项目就一直很难推进。

研发总监知道我来杭州出差，便问我有什么建议，我便晚上到他公司了解情况：研发一直用一个免费的开源工具来管理缺陷与任务。我看到有些研发项目，开始时还是按WBS去填写，但后面项目忙碌，在不同迭代的时候，基本上只是填了些活动，没有跟进填写完成情况，失去了WBS管理的作用。

WBS项目管理

从管理层的角度，他们不一定对这WBS管理工具熟悉，主要想了解项目实际和计划的对比，比如进度偏差，成本偏差。 （可利用项目管理工具即时展示这些偏差）

系统如何帮助监控项目实际进展 

本来没有系统的话，项目经理或者那些组长都要花大量精力去监督进展——完成了多少？BUG花了多少时间去修复？实际的生产率是多少？是否按计划完成？这样靠面对面监督，会花很多沟通的精力和时间。用系统的话，可以直接看，节省项目经理时间。

在计划WBS时，先制定每一个活动的产出物，并需要评审。团队就可以靠评审自我监督完成情况，不需要项目经理花时间每次去问，因为产出物未评审通过，活动就不是100%完成，这可避免填工时表时，无论活动是否完成都按计划完成日期填，导致项目活动显示不出真实的偏差。

研发项目的特点

不像实施项目可以预先知道活动的开始和结束，研发项目会有许多临时的变化。

导致像足球比赛一样，谁也不知道会不会加时，所以无法预先准确地估算出开发所需要的时间。

所以只能在计划时初步猜测。如果要求团队提供准确的估算，反而会导致抗拒，所以建议取一个敏捷的方式——把2周定为一个迭代。

只需要写两周需要完成多少个任务。比如有15个功能，在冲刺的策划阶段自己团队讨论，预先设好WBS。

跟敏捷冲刺概念一样有一个计划，只是计划只局限在2周的冲刺，在2周的冲刺里面是不允许有任何变化，新增需求、变更都要放到下一个迭代。

这可以与敏捷用的看板双互配合，互补不足 - 1）看板 （白板）很灵活，让所有团队成员现场即时沟通； 2）WBS 纪录每次冲刺的计划与实际，成为公司历史数据。

其实这也利于变更管理，从天天变到每两周一变。总经理很熟悉市场客户的要求——其实客户不是不让你两周（或四周）后做变更，最怕是他的变更会被排到最后。

反过来，对于团队来讲，固定两周一冲刺可以减少对开发人员无谓的骚扰，开发人员起码可以自己定这两周集中精力做好哪些模块和功能。

可以避免以前开发团队依靠组长分派任务，今天这个活动急就先做这个，明天有另外一个客户，有个更急的需求就做另一个的典型家长式管理；导致开发人员完全没有自主控制，违背了要尽量让团队可以自我管理时间的概念。

关于这点，研发总监说：“其实这只是个别的情况，不应该是常态，很赞同敏捷迭代的概念，2周一个冲刺，有几个人团队去定要完成多少任务。实际情况也确实有可能每个人同时间支持好几个项目，但是在项目管理工具填写工时的时候，就要写明时间用在哪个项目。”

时间管理：个人 每周定计划，把本周的任务按优先级排序，再定当天要做什么。有计划才可以驱动你把每天时间用好。不然就会像给老师交作业一样，最后几天才赶工，截止前15分钟才提交。

所以一个公司要做好项目管理，每个人都应先有时间管理的概念，不仅仅是项目经理，项目管理才可以帮助团队提升生产率。

如何监控研发迭代

回到本来研发总监希望用偏差 (SV, CV)监控项目的要求。

他问:“如果我按你两周颗粒度没问题，但是要怎么知道实际进展？例如，怎么知道某一个BUG修改实际用了多少天去做，完成了没有？”

我说:“这个取决于你希望他的颗粒度有多细，如果不需要很细,让大家容易填写的话，还是用两周一个单位，例如，本来两周策划完成15个功能，现在实际两周过去后，工时表还是用了三个人总共10个工作日，每天8小时，所以 Planned value (PV), Actual Cost (AC) 都是100%，但是因只完成了12个功能，不是15个，所以 Earned Value (EV)是 12 / 15 = 80%，也会反映在工具中。”

管工具的工程师问:“这不行，会不会那个活动永远是80%,完成不了？”

我答：“不会，因为团队会有下一个迭代把本来未完成的三个功能完成变成。开发人员下一次填工时表时，把本来上一次的三个活动完成，再加上本次次迭代活动，完成新迭代的多少功能。虽然准确度没有细到每个功能是否完成，但这可以简化WBS，减轻项目团队的时间。我通常建议最终由用的人决定，可以接受细到多少。需要所有干系人 - 包括总经理，项目经理，组长，团队成员和使用的人一起讨论。”

我建议需要做一个简单的培训、交流，介绍系统可以帮助什么，由他们自己去探索和决定，怎么去实际操作，满足自己个人的信息需要，这才最实际，不应该单靠我们两三位在这里定下来，也不一定要按照PMP硬推，因为不接受还是用不上。

研发总监说“很对，重要是让他们去试试。”

监控项目实际成本

财务为了知道研发花在不同项目的实际成本，因为没有数据，以往只能年终请研发中心把人力成本分摊到项目，占百分之多少，因没有数据，都靠猜。 如果用了WBS系统管理，便可即时看出每个项目的实际成本（包括差旅费)。

我说：“我们一位香港客户也用这工具。它们引进这个工具的主要目的是为了监控项目实际成本，因他们大部分做政府项目，利润很薄。项目最大的成本就是人手，他们也有ERP,但如果没有项目管理工具便无法即时监控，只能在项目结束才知道是否亏本。但管理层也清楚如WBS管得太细，大家也受不了，他们也是两周填写一次，也可以达到监控项目成本效果。他们用了这个系统以后，在一年时间，把整个公司亏本项目从本来的30% 左右降到10%以下。”

人手分配

WBS工具还有一个功能，可以协调各项目中的人员分配，如果有些人已经被某项目占用，另一新项目要用这个人的话，就要在系统申请，让本来项目把那人放出来，才可以使用。这功能可减少很多用于人手调配的内部会议。

效果

大家都说希望以数据说话，用WBS管理便可体现。

2个月后，再拜访研发总监时，他说：“管理者都希望IT系统可以帮我们记录那些本来是口头、邮件、白板上的东西，避免遗忘，现在这WBS管理系统确实可以帮助项目组记录真实数据，用于监控，还会累积数据，给新项目的策划提供了参考。”

联系我们

电话：18921395967

QQ：1228021190

微信：processis2009

地址：香港/北京/江苏

官网：www.processis.org