项目管理之道 - 可视化项目管理

项目经理经验谈

--可视化项目管理

-- 在所有我们认为做得不够好的项目执行中，总结一下，会发现大多数情况下不是因为我们可见的部分做的不好，而是因为我们忽略了项目某些关键的特性。

-- 在项目开过程中，经常感觉实际开发的工作量永远要比需求调研时了解的需要多，原因是我们容易忽略隐藏在业务需求背后的开发和约束性需求，而这部分需求内容往往不会比业务需求本身带来的工作量小。

-- 经常听到“客户的满意永远是第一位”的说法，我非常赞同这个观点，但我们同时不能忽略了项目团队成员的满意度也具有同等重要的意义，客户的满意主要来自于项目团队成员的努力，试想如果项目成员不满意，缺乏能动性，怎么可能做出满意的产品？更不可能提供令客户满意的服务？

-- 在项目执行过程中，出于各种压力，项目经理经常报喜不报忧，使“忧”变得不可见，管理层不能及时监控或及时提供指引，最终“忧”通通被留给项目经理自己解决，往往问题得不到及时解决甚至无法解决。

在澳博项目在执行过程中，项目组对以上几个问题体会较为深刻，在诸多教训后，项目团队意识到在项目各个环节实现“可视化”的重要性，非常乐意与大家一齐分享澳博项目组在项目执行过程中的相关经历。

“重视”项目个性

正如大多数人的印象一样，澳门是一个夜夜笙歌、灯红酒绿的城市，很多人认为，在澳门做项目是一件很惬意的事情。但在项目开垦阶段，由于未足够重视澳博项目的独特“个

性”，项目组在未完全进入状态之前遇到许多意料之外的麻烦，所以在开始阶段大部分时间是比较苦闷的。

由于业务的特殊性，在此之前我们从未接触过类似业务，除了文档中项目背景描述外几乎一无所知。在与客户项目团队的沟通、协作方面，也未曾想到会有如此大的不同，在没有搞清楚这些差异之前，我们以往在其他项目中行之有效的操作流程、沟通方式以及项目执行思路都不同程度地出现了水土不服。

在我们最初感受到澳博项目“个性”的是在项目生命周期定义阶段。按照一般的经验，项目组在经过初步分析后，参考常用的“瀑布+迭代”的混合模型为项目定义了生命周期，在与客户方项目团队在汇报会议上，客户方项目团队按照他们常规的做法提了若干要求，项目组逐一记录下这些要求，这些要求虽然比我们预想的细致，但亦都非常合理，项目组并没有太在意，只是感觉这些要求会稍稍增加一些我们Review的工作量，并直观估计我们在项目中事先预留的“Buffer”完全可以消化这部分多增加的Review工作。但不幸的是，我们没有对澳博项目的“个性”足够的重视，实际远远没我们想的那么简单，我们忽略很多“不可见”的因素，没意识到这部分内容所带来的影响。当我们其中一个项目组成员结合客户方项目团队的要求将完整的项目生命周期模型整理出来时，我们才意识到问题的严重性，在此之前，项目组从来没试过在一个项目中需要如此多的迭代，这完全打乱了我们在时间和资源方面的规划，这将有可能直接导致项目不能按时提交或资源的不足。幸好我们及时从这张“可视化”的项目生命周期的模型中发现了问题，并以此为基础与客户方项目团队进行讨论，并在相关问题上取得到了平衡，否则项目还没开始，其结果就已经注定，这是澳博项目对“可视化”的第一次印象深刻的体会，“可视化”使我们及时发现并有效规避了一次危险性相当高的项目风险。

澳博项目虽然是一个环境和业务都较为特殊的项目，但相信“个性”并非是澳博项

目独有，公司的每个项目都有自己的特性。对于一般性的问题，我们有很多现成的理论知识和经验支持，导致我们项目执行不顺利的原因大多与项目的“个性”相关，很多时候是因为对“个性”了解不够，没有将所有的关键因素“可视化”，缺乏相应的规划，才会在执行中出现问题。要降低类似问题发生的几率，我们必选先做到“知”，然后在“知”的基础上用一种方式将“知”的内容“可视化”后让大家看到，这种“可视化”不单是针对项目组成员，也包括客户在内所有干系人，大家对“可视化”的东西有了一致的理解后才会有“共识”，才有可能在项目过程中形成一致的行动，有了这些，项目的执行就有了一个良好的基础。

我想无论什么样的项目，只要我们能用有效的技术手段（如：项目生命周期模型、WBS、项目风险监控表……等）将项目的各部分内容“可视化”出来，将它们统统摆上台面，只要能被看到并获得足够的重视，相信都会有办法规避或缓解。

“透视”项目需求

项目需求是项目团队目标任务的最初蓝本，是一切后续规划和行动的基础，如果我们看不透需求，项目的执行将很大机会不停的有“Surprise”出现，这些“Surprise”通常轻则增加项目组的工作量，导致项目延期或成本超支；重则可能会直接导致项目失败。所以在项目开始全面的设计、开发之前，一定要彻底“透视”项目的需求，尽量避免“Surprise”出现。换句话说，就算有“Surprise”，我们也希望他早一些出现，因为越早出现，我们受到的影响会越小。

从需求转入设计时，因为制定方案过程中的复杂性，会激增出大量的衍生需求，这部分需求往往比原始的业务需求还要多，甚至会成倍的增长，所以在需求分析时，我们必须要完整的“看清楚”项目需求的全貌。

澳博项目是一个典型的定制化开发项目，由于其业务的和运作模式的特殊性，项目

组可复用的业务和技术资源非常有限，项目组必须从零开始对澳博项目的业务需求进行梳理、归纳和分析，虽然我们用了多种组合手段（如：访谈、设置需求问题、头脑风暴、问卷……等）获取用户的业务需求，并覆盖了所有的干系人，但我们完成需求后的规划、设计中仍然忽略了许多不太容易“看见”的东西，没有认真考虑开发需求和约束性需求方面的内容，这使得项目实际设计、开发工作量比我们预想的要多的多，项目一度因为未看清楚需求的全貌而陷入被动，这是澳博项目组在需求“可视化”重要性方面的一次深刻体会。

在我们的IT项目中，需求通常会包括3个级别，分别是业务级需求、用户级需求和开发级需求，我需要将各个级别的需求内容都“可视化”，并持续监控和更新，才能准确的为项目未来的行动进行规划。澳博项目组通常通过以下几个方法将各级需求“可视化”： 业务级需求：项目前景、视图、范围文档；

用户级需求：用例及补充规约文档；

开发级需求：详细需求规格说明书，包括设计、开发、测试及用户规约和详细业务、功能需求说明。

“正视”项目团队成员的需求

正如开篇所提到，客户作为项目最关键的参与方和受益方，他们的满意度当然至关重要，但依照澳博项目组的团队建设经验，项目团队成员的满意度同样至关重要，所以澳博项目组特别重视项目团队成员的需求，特别是比较高层次的需求（比如：尊重、自我实现……等），只有充分重视并尽量满足团队成员的这类需求，才能本质上提高项目团队能动性和战斗力。

项目团队成员受尊重需求包括自尊、名誉、他人的尊重、认同和自信。如果团队成员的受尊重的需求未得到满足，会较大程度上打击他们的创造性及激情，除了会降低整个项