推荐策略：

　　尽量使用自下向上+专家指导的方法进行估算，如果有人员到位或者估算周期的有限制，至少要保证关键人员的参与，而慎用自上向下的估算方法.

3、善用加班文化

　　IT公司加班是件很自然的事情，如果哪家公司没有加班情况，反而会让人感觉不正常。做为项目经理应该首先理解，加班虽然是IT公司的普遍现象，但是确实是组员为了项目做出了额外的奉献，他们牺牲与家人团聚的时间，牺牲了休息时间，甚至影响了健康。这种行为值得我们尊重，我们要小心使用这项权力。

1）不要动不动抛出一句“这个搞不定，打地铺解决”等，这种言论是对员工额外奉献的一个严重的漠视，而且带着很强的个人意愿

2）时时保证项目的进展的透明性，可以通过周会，日报的形式在团队中发布。当遇到赶工时，跟当事人讲解当前团队面临的困难，总之，加班是个艰难的决定，是为了整个团队的绩效，不是项目经理的个人意愿

3）任何加班时项目经理都应该尽量身先士卒带队

4）在一些公共场合，尤其有上级领导在时，公开表扬那些为团队做出很多额外贡献的人

5）绩效考核肯定以结果为导向，不能以加班多少论英雄，但要有其他措施安慰辛苦的人

　　推荐策略：加班是一种奉献精神，我们要小心使用，认真对待。不能简单的当做管理者的权力，轻言肆用，否则久之必招其离心

4、开放沟通的团队氛围

　　人都希望自己能够有发言权，能够对关心的事情产生影响。上至的选举，下至日常的工作生活。如果发言权被长期压制，会产生压抑和叛逆的心理。因此构建一个具有开放沟通的团队氛围则显得很重要。而往往言路开明后，项目经理总是能在一些讨论中，得到很多比预期更好的解决问题的方案。一个强权的管理者，容易获得一定程度上的执行力，但是容易被自己的盲点击败。而一个开明的管理者，往往能使用集体智慧，获得跟随者，更容易产生威望。

推荐策略：

1）项目沙盘等关键策略制定时，要全体项目参与讨论

2）项目经理鼓励大家发现问题，提问问题，对于好的措施，能够采纳执行

5、责任到户 VS 大锅饭

　　从头到尾的责任到户制应该是理想的工作分配方式了，在这种分配方式下，团队成员有一块自己土地，通常愿意花更多的时间与精力去耕耘（例如：某个全新的模块），如果这个模块又是他一直想尝试的方面，那将会更加完美，我们有理由相信他将会在这里充满了激情。

　　然而世界上总没有十全十美的事情及百分百通用的方案，尽管责任到户制如此之好，但是在某些项目上我们达成不了这样的期望。

　　我所亲身经历过的两个版本遇到了这样的状况。两个版本的共性是：在一个很大的系统上做覆盖面很大的，很多小点的修改（例如：更换所有UI系统），但是基于老系统的复杂性及历史问题，项目在中会遇到很多bug，各种各样，在bug没有查到原因之前并不好确定这个问题谁改动引发或是谁的责任，这种情况下责任到户制会出现失效。在面对系统这么多的bug时，项目经理很容易想到一种方法：“那是给大家分配bug数，下指标，每天每人要解决3-4bug等”。两次项目经历中，项目经理确实都想到了这种方法，区别是前者实施了，后者被我阻止了。原因如下：

1）团队组员容易产生不被尊重感，被当成解决问题的机器

2）团队之间的协作会发生困难，而且过度强调这项指标，例如谁每天不修改完这个bug数，要加班到10:00之类的，会导致部分组员开始取巧，每天争抢容易处理的bug

3）没法发挥人的主动性，将团队目标和个人目标相背离

　　这种情况下大锅饭的机制似乎更合适一些，如果团队没有达成目标则需要一起想办法或加班解决，而不是将这人归咎个某个人。

　　推荐策略：在正常项目中尽量使用责任到户制，而对于一些特殊项目，则选用大锅饭制，没有一成不变的方案，具体情况具体变通。

项目实战笔记之五：里程碑管理

一、背景

　　由于公司及部门的发展，项目经理已经开始面对人数众多，时间跨度较长的版本管理挑战。

　　如张湘辉（1994年加盟微软，现任微软大中华区CTO）所说：

　　以Windows 7为例，包含七八千万条甚至上亿条代码，五六千人同时开发，还有很多合作伙伴确保周边产品兼容。对这样一个超大的项目而言，不能一眼盯到结果，不能像跑百米一样，始终盯着终点。我们的经验是盯终点肯定乱，因为要经历非常漫长的过程。

　　从心理上说，当发现离终点还很遥远时，人会泄气，不能以那么快的速度玩命跑下去。好的方式，是将事情分成很多步骤来做。Windows7从开始到完成可能要耗时两年，以两年时间为一个周期，那么前六个月团队会被弄垮，所以你必须以也许每两个月为一个终点。像跑一千五百米，我们要考虑第一圈跑多快，第二圈跑多快。

　　这需要把每个终点区分得很好，设定有效的里程碑，在逻辑上要很，是不是到了这个里程碑，同样要非常清楚。这样每个里程碑达到时，大家可以庆祝一下，重又奔向下个目标。如同爬珠穆朗玛峰，没有说不断爬上去，而是先到大本营，再到第几个营地，后才能登顶。

　　从过去的3.0，BM2.0等较长时间的版本管理中，能够看出我们的里程碑管理做得并不好。以前的里程碑是一些项目关键时间点的划分，例如：转测试，转联调等，项目组在里程碑处的行为基本是核实是否满足进入下个阶段的标准，满足则进入。总体来说项目还是以终发布时间点为目标，这样非常容易导致团队的疲惫。因此结合部门历史经验和其他公司的做法，产出里程碑管理的概念。

二、目的

　　里程碑管理目的是解决时间跨度较长或任务比较艰巨的版本管理问题。里程碑管理期望可以达到以下4个效果：

1、 使团队将长期目标划分为不同的短期目标，像跑长跑一样，不是以5W米为目标，而是把目标分解到每一圈

2、 在里程碑处，团队进行有效的休整。像队伍打仗时，一定要有休整，才能持续保证旺盛的战斗力

3、 促使组员进行上个阶段的总结，找出自己的不足，并吸取其他人的优点，从而让组员进行成长

4、 整理下个阶段的工作思路，促进大家进行整体思考，并对模块进行全面分析。

三、具体内容

1、给予项目组时间，进行全员总结，包括上个阶段的总结，下个阶段的工作思路，做成PPT

2、由每个人在会议上将自己的总结PPT进行分享 （做成ppt并在项目会议上进行分析，会引起大家的重视，自然效果会好）

3、进行表彰，表彰做得好的人员，由主管亲自颁发奖品（结合奖励措施）

4、用本小组经费进行欢庆，吃饭+KTV之类