风险规避

项目开发过程中，由于客户的需求变更或客户对系统分析存在不同解释的时候，不同的方案便会从客户方或者项目组内部涌现出来，作为系统分析师或者架构师又或项目经理（决策者），如何谨慎取舍，规避风险，以保障项目能平稳进行、并在期限内完成呢？

首先的一点还是，决策者的技术功底，当然如果技术功底不够深厚的话那么成为一名决策者的可能性也不大了。其次，是沟通能力，甚至说一个人的气质（很难表达，但暂且用这个词吧）。能把自己的思路淋漓尽致的表达出来，理直气壮的表达出来，这一点很重要，事实上不是好的设计方案没有想到，而是提出者或许根本就对自己的方案没有足够的勇气和信心去推销，而被埋没，如果是这样的话岂不是很无奈很可叹!

知道该怎么做而不去做，其他就都是扯蛋。

LZ是唯技术决定论。不过很多时候，技术是不起决定作用的。再说设计方案本身是个权衡的问题，不存在最好的设计方案，只能说合适不合适。当环境发生变化的时候，设计方案可能就不一定合适了。
至于自己的设计方案，是不是要说得理直气壮，都不重要。能把设计方案的优点和缺点都说清楚才最重要。
对于这个问题，我认为属于变更管理的范围，rup上是说成立一个什么ccb(变更控制管理委员会），协调各方利益，设计方案应该解决协调好的问题就OK了。
总之，风险的问题，常常是管理应该解决的问题，技术一般是不会起决定作用的。

[quote="tigers"]项目开发过程中，由于客户的需求变更或客户对系统分析存在不同解释的时候，不同的方案便会从客户方或者项目组内部涌现出来，作为系统分析师或者架构师又或项目经理（决策者），如何谨慎取舍，规避风险，以保障项目能平稳进行、并在期限内完成呢？ 首先的一点还是，决策者的技术功底，当然如果技术功底不够深厚的话那么成为一名决策者的可能性也不大了。其次，是沟通能力，甚至说一个人的气质（很难表达，但暂且用这个词吧）。能把自己的思路淋漓尽致的表达出来，理直气壮的表达出来，这一点很重要，事实上不是好的设计方案没有想到，而是提出者或许根本就对自己的方案没有足够的勇气和信心去推销，而被埋没，如果是这样的话岂不是很无奈很可叹![/quote]


项目已经开始开发，则需求已经确定，此时就不该有什么 系统存在不同解释的说法。客户有异议，和合同需求不同，就应视为需求变更，做可以，要另算钱的。当然如果你们的需求做的很烂，SRS含糊其辞，或者客户很强势，比如电信移动，那就靠双方扯皮了。最好的情况是将这个需求纳入到二期开发。扯皮决定好是作为新需求算钱算时间开发，或者是旧瓶新酒，其他照旧。pm不需要多强的技术，又不是架构师。沟通很重要，和客户方的pm搞好关系更重要，和客户方的领导搞好关系最重要--有时候你们两个pm怕担责任扯皮到天昏地按，他这个什么都不懂的领导一句话就把你们解放了。