|
针对这个项目中需求变更频繁，客户传达的需求常常模糊不清，或者变化不断。这有两方面的原因，一来客户是真正没有想清楚自己要什么，二来是我们没有引导好客户，帮助客户想清楚他们真正想要的是什么。由于我们团队都没有法务的背景和经验，所以，在这方面确实比较吃亏。但我们可以做的是更好地对需求变更进行管理，把风险降低到最小。
对一个项目开发来说，release拥抱变化。对于一个iteration，要拒绝变化。iteration计划前，产品的 backlog都可以变化。 所以在后来，我们要求A地产品经理根据客户的需要，定义好release计划，然后我们制定iteration计划，并提交给产品经理以及客户，在进行充分的沟通澄清的情况下，作为需求的开发基线进行开发。当一个iteration开始了，我们不再接受需求变更，把已经通过审核并确认要变更的内容登记到我们的需求变更表上，由产品经理决定何时加入到哪一个release计划中。同时我们根据release的变化也相应的对后面的iteration计划进行调整，但整体的time-box是固定的，而且尽可能地避免了返工，团队士气后来就好多了。当然，我们的计划也及时反馈给了客户，让客户知道我们不是不做这个需求变更，而是把我们的专业分析以及后面的计划安排反馈给了客户，让他们更明白他们这次的需求变更所要付出的代价以及何时能得到他们想要的东西，这样做了后，他们的满意度至少没有很差，最后还验收接受了我们的软件系统。项目管理者联盟
这个项目后来成功按时上线并得到了客户的验收，但因为前期工作的混乱不足，后来的改进还是效果有限的，后来这个项目还做了二期三期来进一步完善和提高。但不管怎样，所有的经历都是一笔财富，都是自我成长的一部分，这样的经验和教训多么的难能可贵。希望对大家能所有借鉴和启发。谢谢!项目管理者联盟 项目经理博客
本文为项目管理者联盟联盟会员原创文章，授权发布，非经同意不得转载！
|
