这一周被领导安排分析项目的数据库设计时候合理、监督同事的工作情况、检查项目的进展情况、对某些业务功能进行分析设计数据库，五天工作中天天加班，整个人累的实在是不行。以前是在项目中上班时候写写代码，完成任务后就回家看自己感兴趣的技术；现在却是，每天不用代码，要检查别人的工作情况，分析每个人的代码质量，要讨论业务需求要设计数据库，大家下班了，我却还在公司一个一个页面的检查bug一个一个代码的检查代码质量。。。。。。

这就是我这一周的主要任务，忙碌是其关键词，加班到四点半是生平的第一次。

以前是只写代码，现在要学着去管理整个团队，把握整个项目的进度，角色的转变真的是很困难！

以下是根据Karl E. Wiegers的《 A Project Management Primer》的中文翻译，写成读书笔记的。

英文原文：
http://www.processimpact.com/articles/proj_mgmt_primer.pdf

中文翻译：PMT  吴昊。

初为项目经理

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

从一个一线开发人员提拔到项目经理，你必须面对角色的转变。

设立优先级
你要着手的第一件大事很可能就是有意识的设立你作为项目经理的优先级。尽管你可能因为各种原因还需要很大程度上参与软件的开发，但除此之外，你还有一些新的职责。很多新任的项目经理都摆脱不了技术的诱惑，以致忽略了项目成员向自己寻求的帮助。

时间总是不够的，工作也总是做不完的。这无关于你的工作态度。你首先要考虑的，就是三个字：优先级。

富有效率的项目经理知道，他们最高优先的就是为项目成员提供服务。

你第二优先的是让你所在组织的客户满意。

作为一个项目经理，如果你不再涉足产品的一线开发，也许你很少有直接的机会可以让客户满意。但你必须为你的项目成员创造一个环境，使得他们在这个环境下工作，可以最有效的满足客户的需求。这是项目经理的一个重要职能。

你第三优先的是你自己的事情。

你最低优先的是那些纯粹取悦你的老板的事情。

尽管并非每个人都那么幸运可以在一个“正常”的组织工作，但还是努力做好这三件最重要的事。把注意力放在尽可能的帮助下属富有效率——并且快乐——上，而不是取悦于那些“上面”的人。

分析你的技能差距

初为项目经理，通常你会意识到你在领导和管理技能方面的差距，除非你已经为这个新职位做了充分准备。你有很强的技术背景，可能这也是提拔你领导技术团队的一个原因，但你还需要一些其他的技能。你需要客观的评价自己的长处和短处，并且着手缩小自己的差距。

做软件的人常常被认为缺乏出色的交际能力。你需要加强你的人际处理能力，诸如调解矛盾、说服他人、“推销”自己。你需要应付一些不想应付的场面，比如解雇你的下属、在进度上“讨价还价”、为争取下属的绩效“吵架”。

伴我开始经理职涯的是倾听（Listening）技能的课程，我觉得很有价值。在一线开发时，往往我们都有过人的精力来表达自己的技术观点。但作为管理人员，更需要一种包容和聆听的工作风格和交流方式。

然后，从“听”的位置走到“说”的位置，你需要提高你的演讲（Presentation）技能。如果你对在公众场合演讲感到不适，你需要接受一些专门的演讲培训。这对你今后的工作很有好处。

作为一个项目经理，协调他人的工作、计划和跟踪项目、必要时进行项目回溯并采取纠正措施等等都是你的职责。可能的话，接受有关项目管理的培训，学习如何设立优先级、如何主持高效的会议、如何明白无误的沟通等等技能；多看一些项目管理和风险管理的书籍和杂志，比如 Project Management  Institute 的月刊《PM Network》，当然还有很多网站也是很好的资源。

定义“质量”

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

我们在需求阶段就考虑，对于客户哪些质量特性是重要的，并把它们列举出来（比如，交互性、正确性、易学性等）。然后，我们找来一些关键的客户代表，请他们对这些质量特性打分。这样，我们就可以掌握哪些质量特性是最主要的，哪些是次要的，从而就可以有的放矢，为这些质量特性而优化设计。
我听说的更有意思的一种软件质量定义是“客户回来了，但不是为了退货”（the customer comes back, but the product does not）。和你的下属以及客户一起定义合适的质量目标，一旦定义了，则要不遗余力的为达成这些目标而努力。你也要以身作则，以高标准要求自己。记住这句话：“非完美不争取，非卓越不满足”（Strive for perfection; settle for excellence）。

表彰进步

表扬和奖励项目成员的成绩是很重要的激励方式。

奖励计划或许需要你投入一小笔钱，但更需要你多动动脑，想想以何种方式奖励。和你的下属多交流，了解他们在乎什么样的奖励。要把奖励活动变成团队文化的一部分。另外，尝试“非正式”的奖励，在“不经意”中让你的下属明白你是真的知晓他们所做的贡献，并且对此心存感激。

前车之鉴，后事之师

你负责的项目很可能是半途接手的，而且你的前任做的并不怎么好；或者，虽然是新项目，但从前有类似的项目完成，当然有成功的，也有失败的。不管是哪种情形，你作为项目的负责人，应该花些时间分析以往的成功经验和失败教训。你要了解这些项目曾经出现过什么问题，以此避免自己重蹈覆辙。失败是成功之母，但你没有太多的机会失败，所以你要多从别人的失败中学习。
不要戴着有色眼镜去看以往的项目，或许某个你不喜欢的家伙出色的完成了他的项目，你当然可以把这归结为运气或者侥幸，但如果你客观的分析，或许更有助于你的成功。

你也需要客观的去评价自己完成的一些项目（如果有的话），了解自己的团队究竟强在哪里，弱在何处。除此之外，你需要了解被软件业界普遍认可的最佳实践（Best practice）。在 Steve McConnell 的《Rapid Development》（Microsoft Press，1996）中介绍了 27 个最佳实践和36 个软件开发的“经典”问题。此书曾获 Jolt Award，是一个很好的学习起点。当你想把一些好的方法、工具和流程引入到你的项目中时，其他人可能会排斥、反对，甚至抵制，而这恰恰是你的职责所在，你要让项目成员明白为什么要这样做，并且确保他们不折不扣的执行。在你的团队内部，也会产生一些最佳实践，所以你要采取一些措施，促使在项目成员之间交流和采纳这些实践。

设立改进目标

当你回顾了以往的项目，并且确定了“质量”的含义，你需要设立一些短期的和长期的改进目标。只要可能，这些目标应该是可以量化的，这样你可以通过一些简单的指标来衡量自己是否在朝着这些目标前进。

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

尽管流程改进常被人指责为“官僚作风”的体现，但事实上，每个团队都能找到一些可以改进的地方。如果你停留在一贯以来的做事方法上，你最好不要指望能获得比以前更好的结果。

设立可度量的、可争取的目标将集中你为改进流程而付出的努力。你要和你的队员们一起定期检视改进的结果。记住流程改进的目的是为了项目和公司的成功，而不是为了满足书本上的条条框框。把流程改进当成项目来操作，有自己的进度、投入和产出。否则，流程改进总是得不到应有的重视，最终被琐碎的日常工作而淹没。

不要急于求成

你不可能一下子把想做的事都做到，你可以根据自己的处境有所选择，从容上路。