回复 jacob1

1、案例1 中的计件员，应该对自己采取保护性行为，中国的现实就是这样，她把她所掌握的东西全给你了，她肯定会下岗，一将功成万骨枯就是这个道理。 在这个问题上，建议采用国外的方法： 应该和计件员 好好合作，可以采用 入股的方式 拉她入伙， 在这个软件的 股权 获利 问题上 可以与之 分享，让这个 计件员也当家做主，她的10多年的经验也是一种财富，应该说这是一种真正的合作方法。人和人是平等的，只有站在巨人的肩膀上才能成功， 而不应该是立即吃掉这个巨人，将自己迅速成长为一个巨人，这样会撑死的。

2、案例2 很简单， 他们说这个系统是上头要弄的， 那你们就应该去找他们的上级部门谈谈，

我本人就是在一个所谓的政府部门，而且是监督政府部门的 一个部门，“ 拖 ”就意味着他们不想掺和 此事 ，确实应该去找做出这个决策的 决策部门 ，他们既然做了这个决策，肯定舍得在这个方面 投资， 投入各种人力、物力、财力，

目前 我的上级部门找我做的东西， 其实我也早就想做了， 但在我们自己单位就是推行不了， 为什么？ 外面的和尚 会念经 嘛~~~

失败的原因就是有些客户极其变态，特别是那些有后台或垄断行业的客户。其实就是狗仗人势，有点权利不知道怎么使了，只好去变态了。

项目开发方面，商业运作优先于技术工作。
项目经理，首先应该是一个商人。学会推销和融合。会将自己的需要用对方可以接受的方式推销出去。不然怎样去从对方口袋里拿钱呢？
搞项目开发的目的就是赚钱嘛。明白了这个根本，什么事情多可以找到解决办法。
搞技术的人们，应该多学习一些经商的本事和手段。紧紧地把自己限制在技术圈子里，当不成好的项目经理。

不mark不行

论坛功能有点...，收藏应该提供的。

我做过主持过的项目也不少了，在第一线做项目管理四年多了。
大部分项目都是成功的，唯一失败的项目的经过是这样的:

这是为某企业的一个部门开发的项目，跟该部门的负责人经过
长时间的了解需求，写文档，分析的过程，最终该负责人在几百
页的详细需求说明上签了字，经过历时两年的开发，系统最终
开始运行，而此时该负责人调往其他部门。从美国总部调来的
新负责人在一段时间以后，完全否定了系统。因为认为不符合
他的管理思路。
虽然金钱上我们没有受任何损失，当时仍然相当的痛心，
一个项目的成功有很多情况下与服务对象有很大关系，特别是
对方的高层领导。

还有一个项目虽然没有失败，但是也是让对方颇多微词，情况
与楼主差不多，对方习惯于原有的系统，虽然那个系统根本无
可取之处，但仍然要求我们模仿那个系统的一些东西，我们做了
一定妥协，照搬了一些东西。用户才基本满意。

我觉得一个项目的失败往往有这样的因素：

1.服务对象最高层领导的重视和权威性。

没有一个权威的领导的支持，很多工作无法开展。

2.上系统态度的坚定程度。

如果本来就不坚定，很可能遇到困难就退缩。

3.是否已经或曾经使用过类似系统。

用过其他系统就有习惯问题，此时尽量照顾用户的习惯，

尽管有时候原有的东西很烂。

4.用户对相关业务的了解程度。

如果用户自己还不了解业务，他就无法表述给你，项目

也会困难重重。

还有一点经验就是，做好项目必须保持与用户的良好沟通，频繁

的交流能少走很多弯路。对于对方的需求，必须要求对方只有一个

声音。就是先让对方统一思想。

我认为在跟客户了解需求的时候，千万不要把客户供为上帝。一定要把握主动权，让客户跟着你走，让客户接受你的思路和方法，而不是客户说了怎么做，你就怎么做。你应该让客户明白，你是专家。这一点太重要了。

项目基本成功的最低标准如下：
1、客户使用你提供的软件产品达到了他的业务目标。浅显的说，就是他们把“这个系统”用起来了。
2、整个开发费用及免费服务期内的总成本之和，小于目前客户的已支付款额。浅显的说，就是这个项目粗略算下来是不会亏的了。
3、开发团队还没有出现1/3以上的人辞职的情况。

目前来看，国内的软件公司能在每个项目中做到这一点的为数不多。如果一家公司一直保持有2个以上的这类项目在并行运行，那么这家公司不仅营销能力过关，而且在是找到了软件开发公司的经营感觉了。不出意外，它起码能平稳发展上去。

事实上，我看到的大多数情况是：
1、软件勉强能跑起来，但客户几乎没法拿它去使用。
2、软件公司用各种手段想让客户通过“签字”把验收的标准（或需求）定下来。但即便签下来，客户也不敢按原定合同支付下一期的款项。
3、开发时间越来越长，成本越来越高，客户越来越不满意，产品经理越来越烦燥，开发人员士气越来越低落。验收越来越遥遥无期。
4、亏损了。工程烂尾了。
5、6个开发人员中的4个分别跑到其他的软件公司区去重复1-4。
6、剩下的2个开发人员连同新招聘的4个开发人员继续在Sales新签的项目中重复1-4。

学习，收藏！

叫用户有东西可选择，才能成功率高。

刚刚从一个项目组撤下来，这个项目本来是公司产品化实施的一个范例，预计12个人月完成的，但在产品差异化分析的阶段就碰到了问题，由于客户对需求的理解与公司产品差别太多，导致需求说明几乎重新写了一遍，代码开始也在产品基础上进行修补，最后发现BUG太多，无法正常运行，全部推倒重来。结果，所谓的产品化实施变成了一个比重头开始还麻烦的解决方案，前后周折，耗费了36个人月还没完工，更糟糕的是项目成员的士气已经明细收到打击，项目质量一塌糊涂！
回来总结经验，一点感受最深的就是需求一定要在项目启动前就把握好，实施目标定位失误真的很要！

高度赞同r3000 的观点！！！！

如果采取组件化编程，即使项目失败，还会留下一些组件包能够在重新启动再次利用，如果我们采取基于组件的设计编程方法，项目失败可能只是我们组合组件积木的方法出错，只要根据新的需求，重新进行组件的组合即可能达到目标。