思步网

标题: 90的完成度的汇报结果来自谁为准？ [打印本页]

作者: yichamps 时间: 2010-7-22 11:17
标题: 90的完成度的汇报结果来自谁为准？
在软件开发的项目管理中，当遇到进度获取困难时，可以参考我的建议

：

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

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

作者: yichamps 时间: 2010-7-25 15:23
奖惩机制？我同意！同时我也反对!
我记得几年前在XPG公司工作时的一次户外拓展的经历，我们参与了技术型拓展项目，地点天鹿湖，过程用了3天，拓展项目十余项。原来那时候我们已经开始敏捷了。此次拓展的总结论之为：

1. 你们必须互相尊重。
2. 你必须读懂需求。
3. 你的信息必须共享于你的团队。
4. 你必须懂得有效地从团队内外获取与需求相关的信息。
5. 你需要知道如何与团队建立沟通渠道。

是的，以上总结是对户外拓展的收益总结。敏捷要的就是拓展的效果：

1. 注重团队；
2. 注重实效沟通；
3. 注重个体积极性带动团队积极性；
4. 频密地建立信任关系也即频密地交付成果；
5. 对团队内部褒贬不在乎，只要有建树；
6. 对项目(活动)结果最重要，这点对管理层来说是最重要的。

返回主题，奖惩，在那次拓展中的十余个项目，输家是这样受罚的，由领队受罚，成员围圈看。为什么这样，成员不需要受罚吗？对，成员不需要受到良知以外的受罚，例如，底薪/福利/无偿加班等，成员付出了当然应该不能被剥掉。成员受的是良知的惩罚。在敏捷项目过程中，领队投资的是信任/鼓励/协调，把自身的这种能量转化到团队中，能量守恒，团队接受到这种鼓励的力量后实施项目各种活动。如果赢了，领队得到了投资回报，团队会更加信任/增添默契而更加协调，如果输了，领队投资失败，领队承担风险接受惩罚，团队需要目睹此过程而测量个体与团体的短板而达致反思改进。失败与成功都不是偶然也并非必然的，但成功需要失败的沉淀，领导受罚是再次追加投资成本其目的是获得团队的成长与项目的成功，而项目的成功是团队成长的重要衡量标准。

请读者接龙，奖惩机制的数据分析比例

作者: 漂在生活 时间: 2010-7-29 11:46
写的不错，学习了，谢谢分享。

作者: 舞俪姑娘 时间: 2010-8-10 09:58
回复 yichamps 的帖子

很喜欢你们的这次拓展活动！即使是进度汇报也需要团队的互相信任。

欢迎光临思步网 (http://www.step365.com/)