微软的项目经理

除了项目管理相关工作外，强调了最重要的一点是训练项目成员，而微软项目经理一般由资深的程序设计人员担任。所以微软项目管理应该是更偏技术型的，同时也驳斥了项目经理不需要懂技术的一些说法。训练项目成员除了提升项目成员的开发技能外，更重要的还是整个团队精神的塑造。微软项目经理偶尔也会写些程序，但那是次要的工作。

专注再专注

软件开发的真理是任何不能改善产品的工作，都是在浪费时间和偏离方向。团队出问题的一个原因往往是项目成员花太多时间做他们不该做的事情，如参加毫无价值的会议，回复邮件，准备冗余的文档。

项目经理的任务是消除项目成员工作中的一切障碍。让项目成员全力专注在真正重要的工作上－改善产品。

如果把太多杂事分配出去的目的仅仅是为了减轻项目经理个人负担，实际上你做的是伤害团队生产力的事情。别人能够做这件事情，并不代表必须做。

有太多的项目经理在不该授权的时候授权，让项目成员为了与产品无关的事情疲于奔命，让外界的杂事干扰项目正常的进度，以致于项目进度不断延误。

Email的目的就是要让程序设计师的思维不被打断，所以不必要有事情没事情就去瞧瞧它。我只能告诫新进人员回复Email要分批去做，而不是实时去做。

清晰详细的项目目标

不要把设定目标这件事情理解的太玄，设定目标只不过是把你要完成的事用清晰的语言描述出来，让每个人都有明确的概念。明确目标之所以带来效率，是让你可以格外的专注与目标相关的事情，做好时间管理，分清轻重缓急。

开发阶段的进度，特别像敏捷团队工作目标会细化到每天，通过每日构建来检查每天完成的工作情况，及时的纠正偏离。长期加班和饱受压力的小组，多半是工作漫无目标的后果。

程序设计上对性能，质量，安全，可维护性等的优先级考虑顺序必须要和项目的目标保持一致。因此项目质量目标往往和项目进度目标一样重要。

缺陷和BUG
缺陷解决的晚或说缺陷泄漏会导致成倍的清除工作量。所以一发现BUG就需要立即去清除，不能有任何的拖延。

自己的BUG自己负责清楚，不应该是小心翼翼的人去帮助散漫随便的人收拾残局。

如果你要求开发人员出现BUG后要立刻清除，那么程序设计师的功力高下便可立见分晓，如果有人进度一直落后，可能是警示他该加强训练了。

如何避免这个错误？我如何以更简单的方式发现这个错误？当你能对每个BUG都去总结这两个问题的时候，就可以很好的学到避免BUG的策略。

小小的改变可能产生惊人的效果，面对问题和解决问题的时候，简单有效才是王道。

保持进度

如果没有未雨绸缪，那只有坐以待毙。在你期望保持进度之前，能否总结出影响进度的各方面因素并制定相应的应对措施。只有切实的做好了项目的风险管理，进度才能够有效的保障。

能否每天都问自己，有什么事情我今天能做，而且会帮助项目在未来几个月内进行顺利的。项目在进度紧张情况下不会给你任何的知识和技能的学习时间，所以这种预见性就显得额外重要。

以我的经验，最有效的除错方式是对程序进行Debug，通过设定断点来检查变量的值的正确性。这往往比我们凭空猜测要有效的多。因此一个优秀的程序员也应该是一个Debug高手。高手就在于你花一天找不出问题的，高手可能只需要1个小时甚至更短的时间。

解决问题前请先确定真正的问题在哪里？问题的根源是什么，然后再考虑如何用简单有效的方法去改正它。人口开头想要的东西往往并不是他们真正需要的，所以处理这种要求时候先挖掘出用户的潜在想法和需求。

项目主管要勇于说不，不要为了讨好别人而伤害双方的工作进程，你永远要根据自己的目标，作适当的决策。

项目进度的有效控制方法是进行挣值法分析成本和进度的偏差。增量迭代和多个检查点和里程碑的设置可以有效的做到这点。

项目主管可以排到以周为单位的项目进度计划，模块的负责人应该细排出以天为单位的工作计划，通过采用每日构建，每天需要完成的功能清单及时的发现到进度的偏差。对于突发事件，疑难问题解决引起的偏差往往通过赶工可以很好解决外；对于进度估算不准，如生产率数据太乐观引起的偏差则需要及时对整个项目计划进行调整，重新分配资源。

通过实用和易用极大的满足用户需求是软件产品终极目标，与次不相关的有趣，花哨的功能，或开发人员把自己个性强加到系统中，都将是系统的败笔。

不要把时间浪费在无法改善产品的工作上，即使这么做在将来会有潜在的利益，也要与现在投入的时间成本做个衡量。

通过控制图来监控项目偏差情况，当项目进度偏差超过上下限时候，都有必要分析原因，并及时的对进度计划调整。

利用项目检查报告来改进软件开发的工作程序。为了使报告发生作用，报告中必须确实描述我们这次解决问题的每一个详细步骤，以及将来应该如何运用这项新发现。

请注意定期会议的价值，确定它值得每个人放下手上的工作。为了尽量减少工作的中断，会议最好安排在一天的最前面或最后面。有事先对问题的分析准备，有明确的目的，有主持人，有记录人，没有漫无目的的讨论和争辩才能够让会议达到最好的效果。

项目成员每天的有效工作时间为6小时左右，中间还有突发的会议讨论或其它事件。进度计划必要要适当考虑这些因素，同时也不要完全的依赖于进度表来驱动项目的进程，这对小组的士气伤害太大了。

让日程表维持适度的紧迫，但又是可以做到的，好让组员振奋、不松懈，专心致力于项目的推进。

绝对不要草率定出不可能的期限，导致组员为了赶进度而损害产品的质量。导致后续成倍的返工和维护成本。

为了保持创意的活力和团队士气，必须让每一个小项目或小功能的完成都有令人兴奋的结果。

身为主管的您，一定要时常提醒组员：产品的质量远比遵守期限重要。最会误导项目发展、伤害产品质量的事情就是过份重视进度，这不仅打击人员士气，还会逼迫组员做愚昧的决定。

学无止境

如果程序设计师只是完成份内的程序设计工作，那还不够好，一位讲求效率的管理者应该不断提高对属下的要求标准，就像花样滑冰选手的教练一样，当您提高了对组员程序设计功力的要求，也会带动整个公司的程序设计功力水平向上提升。

不要让程序设计师的学习停滞不前，要让程序设计师有机会磨练不同领域的技术，培养十八般武艺样样精通的组员。持续性的训练、培养是必要的投资，以后会带来不可限量的回馈。
训练新进程序设计师时，先培养他对整个公司所有项目都有价值的技术，然后才培养本项目独有的技术。

不要舍不得放您最优秀的程序设计师到别的项目去。如果他在您的项目已经没有新的东西可学，为了公司和他个人的前途，您应该把他推荐到别的项目，让他的成长永不间断。

确定每位组员、每两个月都有一项技术上进步。空闲时候阅读相关的技术书籍是巩固和完善自己知识体系的重要手段。学习的结果最好是一个可以量化和评估的目标，这样才能够更好的检验学习的效果。

绝对不要让组员一直做同样的工作，这样是限制了他的学习，使他停滞在原来的领域。一旦程序设计师精通了某一个领域，就让他换别的领域做做看，永远让他们学习新的技术。

态度问题

是的，撰写“零错误”程序的确需要下功夫，而程序设计师大都不愿下这些功夫，除非程序设计师有正确的态度：没有任何理由，有错虫就是不行。

纠正程序设计师以为增加异常处理和错误提示花太多时间的观念，应该训练程序设计师第一个反应是考虑加上这些是否有道理，第二是考虑加异常处理是否符合项目的目标与工作的优先级。

项目主管应该乐于让项目成员提出相关的问题，而不在乎它们自己是否能够很好的解决。当主管指责项目成员不要提出你解决不了的问题，简直在浪费我的时间的时候。估计即使后面项目成员发现项目严重问题，也不敢提出了。

不要给使用者次品，宁愿延期交货，务必追求质量的完美。

程序设计师必须经常以使用者的观点来看自己写的程序，程序设计师必须能体会使用者的感受。

将程序的可共享性当作优先考虑的目标之一，否则程序设计师将经常做重复的工作。

没有尝试就不要轻易的说不，承担有挑战性的工作才会保证自己技能的快速增长。失败不要紧，关键是是否学会了分析和总结。

如果进度发生落后，那表示有个地方出错了。您应该找出问题，并加以解决，不要一味要求组员加班，在问题没有解决之前，加班是没有用的。

别误信加班等于增加生产能力，长期的加班只会伤害生产能力，对项目没有帮助。

工作时间的长短和程序的好坏是无关的。应该强调系统思考的能力的提高，而不是长时间的工作。

给项目主管的话－结尾

项目经理和其他人一样是团队的一员，不同的是他肩负着与其他组员不同的责任。

主管应该把自己视为团队中的一分子，与其他人平等，而不是高高在上。