在软件开发的项目管理中，当遇到进度获取困难时，可以参考我的建议：

1. “90的完成度”是不真实，因为这个进度出自程序员的汇报，尽管这是每日会议或者周期会议，更糟糕的是来自超过两周以上的一次汇报。

2.  真实的完成度来自Product Owner(产品负责人)的判断。判断标准是符合需求/已修改/可集成。

3.  实施阶段进度中状态包括7步，后续简称--7步状态汇总图(7-3S)：

    1.开发中

    2.开发完待提交

    3.提交后待测试

    4.已测试待返修

    5.已修复待 测试

    6.合要求待集成

    7.已集成；

4.  开发人员本能对汇报反感，其不汇报进度为项目创造的是风险。我们没有办法让开发人员喜欢上进度汇报，充其量能让其接受命令。

5.  汇报目的是了解项目进度，而非针对开发人员考核业绩。我们希望的是团队和睦中自强不息。只要团队的核心共性存在，团队接受存在更多 的个性。

6.  让开发人员积极地做自己的事而非直接面对项目管理，把进度全部量化，大家一起看数据。把数据的录入工作交给把关的产品经理的下属QA 或测试人员。事实上，录入工作并没有带来工作量的增加，本来录入工作是存在的。

7.  产品经理得到的是7-3S，7-3S反映了统计对象的生命周期的度量结果。

8.  进度工作改变了沟通方式，过程流畅了，目的达到了。

 

9.  过程尽量避免有对责任追究到人的考核上，避免鼓励成员丧失积极性，我们为的是获取项目进度并非针对你我他。

 

10. 责任不到不得不追究时，要明察秋毫，奖惩有度，激励为上。鼓励团队把剩下的问题解决，会获得一顿美味的庆功宴。

 

请读者接龙，考虑奖惩机制...