20年研发管理经验谈（十三）

本文继20年研发管理经验谈（十二）。

初为项目经理

做者：Karl E.Wiegers
这一天终于来到了：你从一个一线开发人员被提拔为项目经理。也许你一直在期盼，也许你内心还忐忑不安，也许这是你的职业发展选择，也许你只是不情愿地答应老板“试一下”。无论哪一种状况，可能你并无项目和人员管理及领导的教育背景或者培训经历。

领导和管理（这二者是不一样的）远非简单的与Dilbert 的老板背道而驰（注：Dilbert 是一个漫画人物，以“拥有”一个“白痴老板”而著称）。当你计划如何作好项目管理时，考虑采起如下列出的行动。也许你想作的事情不少，但下面的这些建议会帮助你集中到那些能提升效率（你本身的效率和团队的效率）的事情上。

设立优先级

你要着手的第一件大事，极可能就是有意识地设立你做为项目经理的优先级。尽管你可能由于各类缘由还须要很大程度上参与软件的开发，但除此以外，你还有一些新的职责。不少新任的项目经理都摆脱不了技术的诱惑，以至忽略了项目成员向本身寻求的帮助。

富有效率的项目经理知道，他们最高优先的就是为项目成员提供服务。这些服务包括：指导和教育，处理冲突，提供资源，设立项目目标和优先级等等，适当时也要提供技术指导。我发现，把本身视为为成员工做，而非监工是颇有价值的。无论你正在作或者将要作多重要的事，来你这儿寻求帮助的项目成员应该有“非屏蔽中断”（注：非屏蔽中断是一个硬件术语，此处意即最优先的）优先级。

你第二优先的是让你所在组织的客户满意（注：在咱们公司，产品就能够理解为项目的客户）。做为一个项目经理，若是你再也不涉足产品的一线开发，也许你不多有直接的机会可让客户满意。但你必须为你的项目成员创造一个环境，使得他们在这个环境下工做，能够最有效地知足客户的需求。这是项目经理的一个重要职能。

你第三优先的是你本身的事情。多是一个与项目有关的技术问题（固然也是你感兴趣的），也多是你的老板要你作的某件事。但当这些事与上面两个较高优先级冲突时，你要作好延后处理的准备。

你最低优先的是那些纯粹取悦你的老板的事情。在一个正常的组织（非Dilbet 式的组织）中，若是你作好了前面所说的更重要的三件事情，你的老板已是很是惊喜了。尽管并不是每一个人都那么幸运能够在一个“正常”的组织工做，但仍是努力作好这三件最重要的事。把注意力放在尽量的帮助下属富有效率——而且快乐——上，而不是取悦于那些“上面”的人。

分析你的技能差距

初为项目经理，一般你会意识到你在领导和管理技能方面的差距，除非你已经为这个新职位作了充分准备。你有很强的技术背景，可能这也是提拔你领导技术团队的一个缘由，但你还须要一些其余的技能。你须要客观的评价本身的长处和短处，而且着手缩小本身的差距。

作软件的人经常被认为缺少出色的交际能力。你须要增强你的人际处理能力，诸如调解矛盾、说服他人、“推销”本身。你须要应付一些不想应付的场面，好比批评你的下属、为争取下属的绩效“吵架”。

伴我开始经理职业生涯的是倾听（Listening）技能的课程，我以为颇有价值。在一线开发时，每每咱们都有过人的精力来表达本身的技术观点。但做为管理人员，更须要一种包容和聆听的工做风格和交流方式。而后，从“听”的位置走到“说”的位置，你须要提升你的演讲（Presentation）技能。若是你对在公众场合演讲感到不适，你须要接受一些专门的演讲培训。这对你从此的工做颇有好处。

做为一个项目经理，协调他人的工做、计划和跟踪项目、必要时进行项目回溯并采起纠正措施等等都是你的职责。可能的话，接受有关项目管理的培训，学习如何设立优先级、如何主持高效的会议、如何明白无误地沟通等等技能；多看一些项目管理和风险管理的书籍和杂志，好比Project Management Institute 的月刊《PM Network 》。你还能够从SW-CMM（软件能力成熟度模型）中找到不少有关软件项目管理的有用建议。

定义“质量”

尽管绝大多数人都认真对待质量，也想生产出优质的产品；可是，有关软件质量的定义仍存在很大争议，好比高质量是“足够好”仍是更为经典的质量观点——“完好陷”。为了领导你的团队走向成功，你须要花些时间和你的下属以及客户一块儿来明确：对于他们，质量意味着什么。

你的下属和客户是不一样的两帮人，他们极可能对质量没有一致的见解，也容易抱有不一样的目的。若是客户很强调交货期，那他极可能没有耐心听程序员解释为何须要额外的时间去检查每一行代码。若是客户看重的是软件的可靠性，那他在增长功能和减小Bug 之间多半会选择后者。若是客户习惯了老版本的键盘操做，那他不多会对新的图形操做界面感兴趣。

在我曾经负责的一个项目中，为了更好地了解客户的质量要求，我举办了一次开放式讨论会（Open Forum），除了项目成员和客户参加外，我还请客户的上司们一块儿来参加讨论。此次讨论颇有价值，由于咱们发现不少原有的想法是和客户真正的质量需求背道而驰的。了解这些想法的差别，使得咱们能够把力量集中在让客户满意的事情上，而不是放在让“开发满意”的事情上。

软件质量一般被理解为合乎规格说明，知足客户需求，以及在文档和代码中尽可能少的缺陷（Defect）等等，这些都是比较“经典”的定义。“六西格码质量”（Six-sigma Quality，是一种质量标准及相应的质量管理方法）为缺陷密度（Defect Density）和/或失效率（Frequency of Failure）设定了一个很高的标准，可是，它没有涉及质量的其余方面，好比交货期、可用性、特性集和性能价格比等等。不管咱们是做为生产者仍是消费者，咱们都但愿产品的质量在全部这些方面都是尽可能高的，但事实上，咱们总要在其中作出权衡和选择。

咱们在需求阶段就考虑，对于客户哪些质量特性是重要的，并把它们列举出来（好比，交互性、正确性、易学性等）。而后，咱们找来一些关键的客户表明，请他们对这些质量特性打分。这样，咱们就能够掌握哪些质量特性是最主要的，哪些是次要的，从而就能够有的放矢，为这些质量特性而优化设计。

我据说的更有意思的一种软件质量定义是“客户回来了，但产品没有”（the customer comes back，but the product does not）（注：意思是客户的回头率很高，没有退货。）。和你的下属以及客户一块儿定义合适的质量目标，一旦定义了，则要竭尽全力地为达成这些目标而努力。你也要以身做则，以高标准要求本身。记住这句话：“非完美不争取，非卓越不知足”（Strive for perfection，settle for excellence）

表彰进步

表扬和奖励项目成员的成绩是很重要的激励方式。你要把创建奖励机制（Recognition Program）视为头等大事，除非你已经有了适当的奖励机制。奖励既能够是象征性的奖状、证书，也能够是实实在在的奖品和现金。发奖时记得说，“感谢您的帮助”，或者“祝贺您完成了……”。还要记得奖励的范围不要局限在你的项目组内部，客户表明和一些向你提供特别帮助的项目组外部人员也是要考虑的。

奖励机制不只须要你投入一小笔钱，也须要你多动动脑，想一想以何种方式奖励。和你的下属多交流，了解他们在意什么样的奖励。要把奖励活动变成团队文化的一部分。另外，尝试“隐形”的奖励，让你的下属明白你是真的知晓他们所作的贡献，而且对此心存感激。（注：在咱们公司，荣誉奖和荣誉奖券是很是好的激励资源。在微软，不少项目组中都有一顶小丑的帽子，在天天的Building检查中，若是有人出了问题就要把这顶帽子戴一天。）

前车可鉴，后事之师

你负责的项目极可能是半途接手的，并且你的前任作得并不怎么好；或者，虽然是新项目，但从前有相似的项目完成，固然有成功的，也有失败的。无论是哪一种情形，你做为项目的负责人，应该花些时间分析以往的成功经验和失败教训。你要了解这些项目曾经出现过什么问题，以此避免本身重蹈覆辙。失败是成功之母，但你没有太多的机会失败，因此你要多从别人的失败中学习。

不要戴着有色眼镜去看以往的项目，或许某个你不喜欢的家伙出色地完成了他的项目，你固然能够把这归结为运气或者侥幸，但若是你客观地分析，或许更有助于你的成功。

你也须要客观的去评价本身完成的一些项目（若是有的话），了解本身的团队究竟强在哪里，弱在何处。事实上，每一个完成的项目都要进行项目回顾（Post-project Review），有时这种总结式的项目回顾也叫作“开棺验尸”（Postmortem）。注意项目回顾不是为了追究谁的责任，发现问题、剖析问题是为了之后作得更好。你能够采起头脑风暴的作法，鼓励项目组成员各抒己见。另外，这种项目回顾也能够扩展到项目进行中，在每一个大的阶段结束时都进行回顾。

除此以外，你须要了解被软件业界广泛承认的最佳实践（Best practice）。在Steve McConnell 的《Rapid Development 》（Microsoft Press，1996）中介绍了27 个最佳实践和36 个软件开发的“经典”问题。此书曾获Jolt Award，是一个很好的学习起点。当你想把一些好的方法、工具和流程引入到你的项目中时，其余人可能会排斥、反对，甚至抵制，而这偏偏是你的职责所在，你要让项目成员明白为何要这样作，而且确保他们彻彻底底的执行。在你的团队内部，也会产生一些最佳实践，因此你要采起一些措施，促使在项目成员之间交流和采纳这些实践。

设立改进目标

当你回顾了以往的项目，而且肯定了“质量”的含义，你须要设立一些短时间的和长期的改进目标。只要可能，这些目标应该是能够量化的，这样你能够经过一些简单的指标来衡量本身是否在朝着这些目标前进。举个例子，你发现以往的项目因为需求多变而常常延后，因而，你能够设立一个半年的目标，力求将需求的稳定性提升50%。这样的一个目标要求你每周每个月作实际的工做：统计需求的改变数，查明需求的来源和改变的缘由，采起措施来控制改变。这极可能将改变你与那些需求更改者的交往方式。

你的这些目标和指标构成了软件流程改进的一部分。尽管流程改进常被人指责为“官僚做风”的体现，但事实上，每一个团队都能找到一些能够改进的地方。若是你停留在一向以来的作事方法上，你最好不要期望能得到比之前更好的结果。

改进流程的缘由一般有两个：纠正错误和预防错误。你要把精力集中到威胁或者可能威胁项目成功的因素上；带领你的团队一块儿分析大家目前作法的长处和短处，以及所面临的威胁。

我本身的团队就组织过一次两阶段的头脑风暴练习，以此来确认提升咱们的产量和质量的障碍。在第一阶段，参与者将本身想到的障碍写在即时贴上，每张即时贴写一个想法；而后，协调者就把这些即时贴收集起来，并进行分类；因而咱们获得了若干大的分类，咱们就把这些分类写在一张大的白纸上。在第二阶段，一样仍是这些参与者，针对前面写的障碍，把想到的克服方法写到即时贴上，而且粘贴到相应的分类上。通过进一步的讨论和分析，咱们得以把这些障碍细化，而且得到了一系列可操做的应对方法。

设立可度量的、可争取的目标将集中你为改进流程而付出的努力。你要和你的队员们一块儿按期检视改进的结果。记住流程改进的目的是为了项目和公司的成功，而不是为了知足书本上的条条框框。把流程改进当成项目来操做，有本身的进度、投入和产出。不然，流程改进老是得不到应有的重视，最终被琐碎的平常工做而淹没。

不要急于求成

本文所建议的一些作法将帮助你这个项目管理的新手和你的团队取得更大的成功，随着你天天面临的工做压力，你或许会沦为又一个“苟延残喘”者，可是，你要始终明白你肩负的一个任务（可能也是你得到成功的机会），那就是造成你的团队文化和一套作事的方法，这是一个长期的任务。你不可能一会儿把想作的事都作到，你能够根据本身的处境有所选择，从容上路。