做到客户满意为止（项目成本控制相关主题）

客户满意是所有项目开发的最终目的。
但是客户的主管意见很容易改变，随着客户对项目的深入了解，如看到原型、例子、其他系统、开发中间产品等等，都有可能导致客户改变初衷，还有就是客户接口人员变化（人数增删），客户的领导的意见都会导致客户改变初衷最终导致超出了预定的项目要求，导致项目开发不断在修改中度过，项目进度延时，导致项目成本不断攀升，最终可能导致客户不满意，项目开发人员怨声载天，甚至项目流产。

那我们要怎样才能保证项目能令客户满意，又能保证项目成本。我总结以下几点：
1、需求分析阶段
   这个非常重要，这个阶段必须划分清楚那些是项目应该做的，那些是不应该做的，这个阶段必须出系统原型。
   首先需求分析人员要熟悉客户的业务，如果不熟悉业务则必须到现场办公，深入了解业务，然后想成需求分析详细说明文档。
   这个时候最怕的是你有问题，但客户没空理你，这就要求需求分析人员和客户搞好关系，同时必须有牛皮膏精神，无论用什么手段都要搞到清楚，哪怕和客户有些小摩擦都可以，事后再和客户解析清楚、请请客倒下谦修复关系就好。
   将所有主要业务界面都用原型展现出来，这样能更好的限定范围，同时也能更好的让客户知道他即将要求的系统是什么样的。
   对应B/S系统，原型可以是HTML，简单点的直接有VISIO话也行，尽量避免用图片，不便修改，对以后的设计用途也远没前面两个大。
    所有的客户确认最好以email方式确认，当然文档更好，保留“罪证”。

2、系统设计阶段
   这个阶段必须出概要设计说明书，编写是可以充分利用需求分析阶段的系统原型，而且也是限定开发范围的最有效手段。

3、开发阶段
   要向成员充分贯彻业务，对于分组开发的项目要分好大模块，再有组长具体分配。
   必须有“高手”每天review代码，保证质量，尤其要避免低级错误，尤其是开发初期和新加入成员，这个“高手”可以是组长。
    开发初期，需要“高手”共同制定开发规范包括开发格式，工具，编码格式等，对数据库设计要求定好表名规范，表名最后统一全部大写或小写，开发基类，公共库，基础框架等，这个很重要。对JAVA来说基类一把分别DAO,SERVICE,BEAN,ACTION的，对应eclipse开发工具，可以制定eclipse格式配置文件，大家导入即可保证格式统一。

4、开发中
   开发中定期将开发结果和客户沟通，保证项目符合客户要求

5、测试
   单元测试、功能测试、集成测试、UAT等，应该有奖惩机制，对应犯低级错误的次数多的必须提出警告甚至惩罚。

6、交付
   
   
   

好像没有看到什么和成本相关的，都是需求质量客户满意度这些间接影响成本的东西

seeckt 写道
好像没有看到什么和成本相关的，都是需求质量客户满意度这些间接影响成本的东西

结合个人以前的一些经验，发表一下愚见。lz所说的需求分析阶段，是我们大多数项目中产生成本的关键阶段。
在项目中不是每个功能，每个需求都能做。特别在项目资金有限的情况下。在需求分析到系统功能分解的时候，哪些能做，哪些不能做，哪些更难做，哪些工作量比较大，需要投入更大的人力。比如说人家客户就给公司100w,要求做很多功能，这本来就不现实。所以我反倒认为这个阶段产生成本估算，可以有效的控制项目成本。

关键要弄清楚，UAT用例是谁提供，谁评审，谁验收，谁签字
原来出现过找签字的咨询用例设计，结果验收的人不买账，而且更可能发生的是你最终交付的目标用户和验收的不定是一拨人，所以想好你应该花最大精力让谁满意
review代码在大项目里面很难做到，能做到评审接口和数据库设计已经是极限了

引用
seeckt 写道
好像没有看到什么和成本相关的，都是需求质量客户满意度这些间接影响成本的东西

结合个人以前的一些经验，发表一下愚见。lz所说的需求分析阶段，是我们大多数项目中产生成本的关键阶段。
在项目中不是每个功能，每个需求都能做。特别在项目资金有限的情况下。在需求分析到系统功能分解的时候，哪些能做，哪些不能做，哪些更难做，哪些工作量比较大，需要投入更大的人力。比如说人家客户就给公司100w,要求做很多功能，这本来就不现实。所以我反倒认为这个阶段产生成本估算，可以有效的控制项目成本


这个思路很不错，其实不同职位的人，每个人都有每个人的解决方案
诸如现场开发、配备更好的需求分析师、更好的代码设计等待，这个是软件开发的思维
如果从项目管理的思维上说，解决方案就可能是按工程收入分析哪些该不该做，以及对变更的严格控制
当然完全跳出软件项目的思想圈子，从营销角度说，在需求不明确时，根本就不应该签总价合同，
而是用工作量单价或者基础价格+工作量的方式签合同

一点自己的项目经验
在项目管理不正规的时候，客户会使劲变更需求，使劲加内容，因为往往我们自己都搞不明白哪些是在合同范围内哪些是在合同范围外，哪些要收费，哪些要打折，哪些免费。这潜意识告诉用户加的改的内容都是应该免费或者优惠的，如果不免费优惠就不满意。

在项目管理正规的时候，任何变更都被记录，哪些是收费范围都很清楚，比如上门检查客户申报的一个BUG算缺陷验证还是算上门服务。做到这个程度客户方项目经理自然会做好成本控制，否则一不小心成本超支他自己都没法向领导交代，这样项目成功就不仅仅靠乙方单方面的努力，而是借用了甲方的力量。如果做过非软件行业的项目，可能会更好地理解一下这点，乙方做的好不仅仅是为自己公司省钱，更要能提建议给甲方省钱。让大家知道一个项目的事情做好了，而且保证的乙方的利益，又帮甲方省了钱，这样才能使各方满意。
事情事先谈清楚，包括收费范围，事故责任等等，后面扯皮就少了，客户就会尊重项目团队和软件企业的正规程度，满意是必然的。

如果说一个项目要做到客户满意为止。那么可以说这个项目从一定层面已经失败了。没有一个项目能够是完全让客户满意的。

其实我们要做的就是当客户提出需求或者变更时，及时反馈给用户这个我们能不能做。能做时间是多长。成本是多少。如果是变更要及时反馈给客户这个变更对现有系统中的其它部分的影响程度有多大。会导致什么样的后果等等。

总之要有勇于对客户说NO的勇气。最忌讳的就是，客户不管说什么就只知道点YES。如果只会这样的话。那这样项目就已经到了失败的边缘了。团队也到了分崩离析的边缘了。

woaiwofengkuang 写道
如果说一个项目要做到客户满意为止。那么可以说这个项目从一定层面已经失败了。没有一个项目能够是完全让客户满意的。

其实我们要做的就是当客户提出需求或者变更时，及时反馈给用户这个我们能不能做。能做时间是多长。成本是多少。如果是变更要及时反馈给客户这个变更对现有系统中的其它部分的影响程度有多大。会导致什么样的后果等等。

总之要有勇于对客户说NO的勇气。最忌讳的就是，客户不管说什么就只知道点YES。如果只会这样的话。那这样项目就已经到了失败的边缘了。团队也到了分崩离析的边缘了。

我们公司是不管能不能做，都说YES。做的来，就可以合作，做不来，你说YES或者NO都是合作不了的。。YES意味你有赚钱的机会，NO意味着你连赚钱的计划都没有。 哈哈！！

还是根据实际情况出发，把需求排个优先级，在有限的时间内，哪些一定要完成的，哪些可以延后。还要根据现有的开发能力，能不能争取多点人来资源，充分利用现有的人力资源。如果客户说做什么什么时候要，都说YES，这样会到期了也拿不出个像样的东西来，还BUG一大推，客户的抱怨会更大，会直接导致项目失败。

..........