项目管理从改变团队开始

Tuesday, September 23 2003 2:09 PM 项目背景：中国建设银行数据集中工程（简称DCC）于2002年7月份启动，目标是在全国建立南北两个数据中心。项目完成后，38个分行的数据将全部集中到总行数据中心，而部署在分行的是大前置系统（简称大前置）和网点前端系统（简称前端）。大前置是这次数据集中项目的核心，除了接入前端的柜面业务外，还整合龙卡、清算、重客、网银等二十余种重要业务系统。该项目中神州数码负责大前置和前端系统的开发、切换，IBM负责后台主机系统升级改造。自2002年10月起，神州数码投入了60余人的开发队伍在建行外高桥开发基地进行了为期10个月的封闭开发。至2003年8月24日，经过24小时的系统切换，DCC在首个试点行—上海分行成功上线。全行327个网点一次切换成功，目前整个系统运行稳定。

笔者在DCC项目中任神州数码的项目总监，统一管理大前置和前端两个项目。本篇文章将结合笔者在项目中的切身经历，谈谈大型软件项目管理中的一些实际体验。

发现问题

笔者是在中途被匆匆调入项目组的，之前只被告知项目遇到一些困难。进入项目组还不到一周即发现：尽管项目中聚集了神州数码各方面的骨干，但项目中存在的主要不是技术难题，而是管理的问题，主要包括三个方面：

在管理模式上，因神州数码与客户分别签定了分行大前置和网点前端两个项目，所以项目由两套几乎独立的团队分别管理，各组之间推诿、争执时有发生！这一方面造成项目组效率低下（客户反映总是面对两组人，沟通困难）；另一方面，像系统切换这样一些在中间地带的重要工作却无人问津。在工作方法上，压力没有得到传递，项目骨干压力巨大，但组员却相对轻松；另外由于工作量严重不平衡，存在人浮于事的现象。

在客户沟通上，缺乏必要沟通技巧和客户意识，造成客户关系紧张；而对于这种情况，项目组一些成员却认为是客户在故意找茬。

分析和解决问题

经过分析，产生上述三个问题的原因主要有以下几点：一是缺乏一个统一的核心班子；二是缺乏有效的工作方法，特别是工作重点工作不突出；第三是缺乏与客户在正式场合之外的非正式沟通渠道。

在明确问题原因之后，陆续采取了以下一些措施：

调整了组织结构 不再按合同划分大前置和前端两个项目，而是按系统平台、应用开发、切换和推广划分为四个小组，并明确了各小组职能。

确定重点工作 核心组第一件要确定的事便是项目的重点工作。因资源有限，要确保上海分行按时上线，必须确定项目重点工作策略。当时确定的两个重点包括：

一是分行大前置系统。一旦出现问题将造成整个分行业务瘫痪，所以系统的性能、可靠性事关全局。因此，对于大前置系统的压力测试和性能优化是第一重点。

二是系统切换。切换工作必须由经验丰富、组织协调能力强的人员担负。因切换工作启动已经晚了，再从公司调集人员已经不可能，权衡再三决定让前端的项目经理负责切换小组。事后证明虽然这一定程度上削弱了前端组力量，但系统切换工作确实完成得非常出色。

两个非重点包括：

一是对于网点前端系统，因当时认为应用上变化不大，测试中发现的问题不多，所以比较放心。因为未作为一个工作重点，反而从该组调出了不少资源支持其他小组。但事后证明这个判断是错误的，一是当时测试密度低，暴露的问题少，才造成了系统缺陷少的假象；二是后期突然修改凭证，客观上大大增加了工作量；三是全行有近330个网点，多点版本管理的风险未引起足够重视。所以，在后期大量进行修改时不仅人员工作强度极大，还一度造成版本管理的漏洞。

二是分行推广。因推广工作有一定的时间缓冲，所以当时的策略就是在不从项目组抽人的情况下尽量满足分行支持的需求，同时优先从公司其他项目调集资源。事后证明，当时这个策略是非常正确的，对集中优势资源保证上海分行上线起到了不容忽视的作用。

明确各组的工作目标 通过会议落实各组的目标，如大前置性能必须通过的专门的压力测试；前端组必须24小时内对变更和缺陷修改做出反馈；切换组要求将切换方案细化到单个任务的命令清单和验证清单；分行推广组力保不从项目组抽取人员。

稳定队伍，严肃纪律和鼓舞士气 核心组任务明确后，下一步要完成的就是“带队伍”。首先，根据重点工作和目标要求，项目组减少了8个工作任务不明确的人员，这对留下的项目成员反而是种触动；其次，与个别不稳定的员工进行了谈话，在解决了具体问题后一些员工表现出的活力远远超出想象，最终只有一个人真正离开项目；第三，严肃纪律，对于不经同意擅自离开的人员如无明确理由一律严肃处理；第四，因项目周期长，所以跟公司协商按阶段进度落实了部分奖金，一定程度上提升了士气。

培训骨干，改进工作方法 首先强调干部要以身作则和亲临一线。其次，学会用合理的方法分配工作，如修改PTM（测试缺陷）过程中，将收到的PTM分配到每个人头上，并在白板上公布，同时及时更新完成状态。

提高客户意识，加强客户沟通 要求大家重视非正式沟通渠道。比如，在正式会议之前，对于要汇报的内容与客户通气，也要提前了解客户要反映的情况。一次，在一个重要的会议前客户反映大前置监控系统“根本不能用”，经进一步了解情况其实是用户界面不友好，而我方的工程师态度又比较生硬，造成客户不满做出上述结论。如果按“根本不能用”报告，会议上没有时间解释，也很容易发生争执，势必对我方极为不利。而经过会前沟通，我方同意限期修改，客户也同意在会上报告是“界面问题”，于是这个问题的性质就发生了根本的变化。

经过上述一系列调整措施之后，项目组的情况得到了很大的改观。在随后的4个多月中，各个小组都克服的重重困难按规定完成了任务。一个典型的例子是前端小组。前面也提到，由于判断失误对重视不足，提前从前端组调出了过多的人力，从而使项目后期前端小组遇到了前所未有的困难和空前的工作压力，但他们不仅创造了2天完成60余种凭证打印程序开发测试的奇迹，并在连续2周的白天整体测试、晚上修改PTM和发布新版本的高强度工作中表现出了惊人的能量。上线过程中，在公司高层对建行客户进行拜访时，建行高层领导对神州数码项目组的成绩给予充分的肯定，特别对前端组的这种拼搏精神和取得的战果给予了高度的评价。

笔者对该项目有几点感触至深：一是成功的项目对于团队的依赖性不容忽视，没有好的团队即使再完美的计划也得不到实现；二是好的项目管理方法不在于多先进的理念而在于把准脉，有时一块白板的作用远远大于一套理念，与客户几分钟的会前沟通远强过30页的PPT文献。第三，要记住团队的个体是一个个活生生的有感情的“人”，而非“6个二级程序员”，他们有不同的性格和思想，只有在唤醒他们的团队意识和潜能之后，你才能看到一个无所不能的巨人，那就是你的团队。

项目沟通管理

    回想一下你所经历的项目，有没有出现过以下这样的情况：客户在检查项目阶段成果时，指出曾经要求的某个产品特性没有包含在其中，并且抱怨说早就以口头的方式反映给了项目组的成员，糟糕的是作为项目经理的你却一无所知，而那位成员解释说把这点忘记了；或者，你手下的程序员在设计评审时描述了他所负责的模块架构，然而软件开发出来后，你发现这和你所理解的结构大相径庭……  

    可能你遇到的情况比上面谈到的还要复杂。问题到底出在哪儿呢？其实很简单，就两个字——沟通。以上这些问题都是由于沟通引起的，沟通途径不对导致信息没有到达目的地。“心有灵犀一点通”可能只是一种文学描绘出的美妙境界。在实际生活中，文化背景、工作背景、技术背景可以造成人们对同一事件理解方式偏差很大。   

    在项目中，沟通更是不可忽视。项目经理最重要的工作之一就是沟通，通常花在这方面的时间应该占到全部工作的75%～90%。良好的交流才能获取足够的信息、发现潜在的问题、控制好项目的各个方面。

    沟通管理的体系

    一般而言，在一个比较完整的沟通管理体系中，应该包含以下几方面的内容：沟通计划编制、信息分发、绩效报告和管理收尾。沟通计划决定项目干系人的信息沟通需求：谁需要什么信息，什么时候需要，怎样获得。信息发布使需要的信息及时发送给项目干系人。绩效报告收集和传播执行信息，包括状况报告、进度报告和预测。项目或项目阶段在达到目标或因故终止后，需要进行收尾，管理收尾包含项目结果文档的形成，包括项目记录收集、对符合最终规范的保证、对项目的效果（成功或教训）进行的分析以及这些信息的存档（以备将来利用）。   

    项目沟通计划是项目整体计划中的一部分，它的作用非常重要，也常常容易被忽视。很多项目中没有完整的沟通计划，导致沟通非常混乱。有的项目沟通也还有效，但完全依靠客户关系或以前的项目经验，或者说完全靠项目经理个人能力的高低。然而，严格说来，一种高效的体系不应该只在大脑中存在，也不应该仅仅依靠口头传授，落实到规范的计划编制中很有必要。因而，在项目初始阶段也应该包含沟通计划。   

    设想一下，当你被任命接替一个项目经理的职位时，最先做的应该是什么呢？召开项目组会议、约见客户、检查项目进度……都不是，你要做的第一件事就是检查整个项目的沟通计划，因为在沟通计划中描述了项目信息的收集和归档结构、信息的发布方式、信息的内容、每类沟通产生的进度计划、约定的沟通方式等等。只有把这些理解透彻，才能把握好沟通，在此基础之上熟悉项目的其它情况。   

    在编制项目沟通计划时，最重要的是理解组织结构和做好项目干系人分析。项目经理所在的组织结构通常对沟通需求有较大影响，比如组织要求项目经理定期向项目管理部门做进展分析报告，那么沟通计划中就必须包含这条。项目干系人的利益要受到项目成败的影响，因此他们的需求必须予以考虑。最典型也最重要的项目干系人是客户，而项目组成员、项目经理以及他的上司也是较重要的项目干系人。所有这些人员各自需要什么信息、在每个阶段要求的信息是否不同、信息传递的方式上有什么偏好，都是需要细致分析的。比如有的客户希望每周提交进度报告，有的客户除周报外还希望有电话交流，也有的客户希望定期检查项目成果，种种情形都要考虑到，分析后的结果要在沟通计划中体现并能满足不同人员的信息需求，这样建立起来的沟通体系才会全面、有效。

    语言、文字还是“形象”

    项目中的沟通形式是多种多样的，通常分为书面和口头两种形式。书面沟通一般在以下情况使用：项目团队中使用的内部备忘录，或者对客户和非公司成员使用报告的方式，如正式的项目报告、年报、非正式的个人记录、报事帖。书面沟通大多用来进行通知、确认和要求等活动，一般在描述清楚事情的前提下尽可能简洁，以免增加负担而流于形式。口头沟通包括会议、评审、私人接触、自由讨论等。这一方式简单有效，更容易被大多数人接受，但是不象书面形式那样“白纸黑字”留下记录，因此不适用于类似确认这样的沟通。口头沟通过程中应该坦白、明确，避免由于文化背景、民族差异、用词表达等因素造成理解上的差异，这是特别需要注意的。沟通的双方一定不能带有想当然或含糊的心态，不理解的内容一定要表示出来，以求对方的进一步解释，直到达成共识。除了这两种方式，还有一种作为补充的方式。回忆一下体育老师授课，除了语言描述某个动作外，他还会用标准的姿势来教你怎么做练习，这是典型的形体语言表达。像手势、图形演示、视频会议都可以用来作为补充方式。它的优点是摆脱了口头表达的枯燥，在视觉上把信息传递给接受者，更容易理解。

    两条关键原则

    在项目中，很多人也知道去沟通，可效果却不明显，似乎总是不到位，由此引起的问题也层出不穷。其实要达到有效的沟通有很多要点和原则需要掌握，尽早沟通、主动沟通就是其中的两个原则，实践证明它们非常关键。   

    曾经碰到一个项目经理，检查团队成员的工作时松时紧，工期快到了和大家一沟通才发现进度比想象慢得多，以后的工作自然很被动。尽早沟通要求项目经理要有前瞻性，定期和项目成员建立沟通，不仅容易发现当前存在的问题，很多潜在问题也能暴露出来。在项目中出现问题并不可怕，可怕的是问题没被发现。沟通得越晚，暴露得越迟，带来的损失越大。   

    沟通是人与人之间交流的方式。主动沟通说到底是对沟通的一种态度。在项目中，我们极力提倡主动沟通，尤其是当已经明确了必须要去沟通的时候。当沟通是项目经理面对用户或上级、团队成员面对项目经理时，主动沟通不仅能建立紧密的联系，更能表明你对项目的重视和参与，会使沟通的另一方满意度大大提高，对整个项目非常有利。

    保持畅通的沟通渠道

    沟通看似简单，实际很复杂。这种复杂性表现在很多方面，比如说，当沟通的人数增加时，沟通渠道急剧增加，给相互沟通带来困难。典型的问题是“过滤”，也就是信息丢失。产生过滤的原因很多，比如语言、文化、语义、知识、信息内容、道德规范、名誉、权利、组织状态等等，经常碰到由于工作背景不同而在沟通过程中对某一问题的理解产生差异。   

    如果深层次剖析沟通，其实可以用一个模型来表示：   

    从沟通模型中可以看出，如果要想最大程度保障沟通顺畅，当信息在媒介中传播时要尽力避免各种各样的干扰，使得信息在传递中保持原始状态。信息发送出去并接收到之后，双方必须对理解情况做检查和反馈，确保沟通的正确性。   

    如果结合项目，那么项目经理在沟通管理计划中应该根据项目的实际明确双方认可的沟通渠道，比如与用户之间通过正式的报告沟通，与项目成员之间通过电子邮件沟通；建立沟通反馈机制，任何沟通都要保证到位，没有偏差，并且定期检查项目沟通情况，不断加以调整。这样顺畅、有效的沟通就不再是一个难题。