也谈谈影响项目成败的因素

    个人负责和经历的项目不多，自92年毕业工作以来持续在IT业偏软方向努力，第一个独立负责的项目是1993年3月开始给一个宾馆写一个宾馆管理系统，包括并不内行的硬件系统，历时半年。个人觉得最难的是写电话程控交换机的数据接口，为此我还在苏州有线电一厂待了近一个月。从此走上了不归路，写到这里心里还有点......呵呵。

    那么经历的最大项目是和台湾（好像还有日本股份）一个资讯企业合作，给某个地方银行写银行管理系统，包括硬件项目大概120万美金，具体软件开发占多少比例不是很清楚，估计不低于50%。个人负责其中会计部分。

    2000年以后个人主要给一个学院讲课，比如C语言、数据结构、软件工程、MIS等偏软的课程，业余时间打理自己的2个小企业（一个软件、一个外贸）。前2年听说“阿狗阿猫”们都去开发游戏软件或网络游戏市场了，游戏是我第三生命，当然不甘落后，去年底开了一个SF，现在注册人数4500+，每天在线人数在60--120左右，人气还在不断上升中。今后随着对游戏软件技术的摸索和经验的积累，想开发自主产权的游戏、想在游戏市场分点汤羹。

    啰里啰唆这么多，主要在整理自己对影响项目成败因素的思考。所以请各位放心，我下面说谈的影响因素可能不是最经典或合理的，但一定是个人最精粹的经验整理，毫无保留地奉献给这里--我的第一个博客。

一、态度

    委托方和开发方，对于最后开发完成的软件而言，是谁的成果？我的答案是委托方的成果，开发方只是用某种技术（当然主要是软件技术）完成了委托方布置的“作业”，或者说开发方用软件技术实现了委托方的管理和经营的思路。

二、需求

    需求阶段最容易造成矛盾和隐患，而且往往是致命的因素。原因只有一个：开发方重技术、委托方重管理。所以培养一个合格的需求收集、分析人员很难啊，既要听得懂委托方的管理思路、又要用计算机技术去做分析和还原。

    关于“隐性需求”有这样三种情况：

1、委托方清楚自己的需要，并且表达出来，但开发方未能理解（或听不懂）；

2、委托方清楚自己的需求，但表达不出来，需要开发方去体会或理解；

3、委托方知道存在问题，但不知道原因和解决办法，需要开发方提供参考意见，希望通过软件系统来解决或规范。

    从上可以看出解决了1、2点后，可以极大地保证委托方的认同感了，估计这项目十拿九稳；保证了第三点后，开发方想不赚钱都难了。所以初步的接洽和初步的需求交流很重要，需要派经验丰富的、亲和力高的工作人员去。

三、委托方的参与性、参与度

    参照第一点：态度。不仅开发方要明确我是去做服务的，而且要让委托方（主要高层或决策领导）时时刻刻知道：你才是真正的开发者，我只是用软件来实现你的思想。俗话说：老婆是别人的好，小孩是自己的好。你要让他深深地参与到开发过程中来，让他把这个项目当作自己的小孩来养。这时候你要钱、要物都好说。个人这一点比较有体会，我没有碰到恶意欠费的，通常委托方都会提前问我要不要先打点经费过来，包括和政府和学校等老爷单位。这点比较自豪（没办法人品好......赫赫）。

四、客户培养

    客户培养很重要，培养的基础和目标都是诚实、以诚相待。培养过程贯穿整个过程，比如我们做一个需求分析或系统规划，通常有2个版本，一个给他们（委托方）的技术员看，一个是给他们的领导看。这两个版本绝对不能相同、不能偷懒。

五、其他

    其实开发过程中，还有很多很多关系成败的关键因素。比如说技术、人员、计划进度、成本核算等，当然还有风险控制（风险不可回避，主要关键是要明确风险责任）。个人觉得关系项目成败的很多关键因素集中在初步接洽和初步需求交流上，就像找对象，第一印象很重要，好的开始是成功的一半。

    以后再整理下思路，把个人接项目的大概经过、大体思考和处理过程介绍一下，欢迎各位发表意见和看法。

疑.....为什么后面那么多的内容没有了呢？难道版面有长度限制？
郁闷了。

好像lz 講的更多的是如何和客戶談判?

看來lz很重視是否能拿到項目,估計拿到項目基本也算成功了

不過期待后文

lz可以说是经验丰富的专家了，希望能看到你的佳作。
项目的成败我觉得最主要的是要把握好用户需求，用户的支持配合。

楼上抓住了重点，我有几个项目的确不是很成功，主要是技术解决手段薄弱。但由于把握了用户的核心需求（部分），以及用户的积极配合，都得以顺利结束。比如我的第一个项目：宾馆管理系统。03年我去那家宾馆，发现其老总办公室还放着那台10年前的386，DOS环境里面每天只运行一支当年我用FoxBase写的一支日记账程序，当时感动的恨不得把当年的项目收入还给她。

看来楼上谈的项目成败因素和先前的那个帖子 有很大的出路

继续-我接项目的一般过程
    这里说的项目不是上面领导指派的，不是纵向而是横向课题。如果有项目，一般我会亲自去做第一次接洽。了解以下内容：
1、项目名称、目的、作用（意思），委托方有无更深层次的开发用意；
2、首先思考项目或未来系统的边界，为将来需求交流明确：哪些是系统内、哪些是系统外？
3、以现有的、现掌握的技术来估算该项目软件开发实施（详细设计与编程）阶段的工作量，并依据人工来估算开发成本，然后按软件实施阶段占30-40%比例来反推整个项目的开发成本。项目成本测算很敏感，高了吓跑用户、低了怕有去无回，我也参考了很多资料，但发现真正能拿来用的还是经验。其实30-40%也不是一定的，主要依据你团队或公司对类似项目开发成功的技术把握度。因为这个阶段依赖外界因素较少，通常我依此来测算开发成本。
4、安排需求调查与分析
    一般来说需求调查手段有2种：会谈和问卷。注意各自特点，个人总结，会谈调查结果--比较诚实、真实；问卷调查--可以调查一些比较敏感的内容。
PS:给刚入道男孩女孩一点建议，如果安排你去收集需求，并且和对方不熟悉，你脸皮又比较薄。你可以这样做，到对方企业收集他们工作时需要填写各种空白单据，如果你看不懂就请教他们怎么填写，在他们教你的同时注意收集他们工作的业务处理流程。
    另外，请问一下各位：你们有没有碰到过空着双手去做调查工作的人员？现在有些大学生连上课也不带任何东西，带本教材给足教师的面子了。
5、安排委托方共同参与系统规划、设计未来系统的“美好蓝图”，呵呵。
6、相对独立的软件实施过程，注意时刻和委托方沟通系统实施进度、完成度。
7、整合测试和用户培训，用户操作培训不可少，再小的系统也要安排工作人员到现场培训，其实这也客户培养的一个内容。俗话说：阎王好见、小鬼难缠。
8、整理开发文档、备案、部分移交用户，考虑需不需要为客户制定相应的规章制度。
9、最后不要忘记收回尾款，如果因为种种原因，打算放弃尾款，那么意味着你将打算放弃这个客户。
10、开发方总结，总结回绕着这2个重点：用户对该系统的工作使用依赖程度和满意程度。因为依赖程度决定了软件的价值性、满意程度决定了软件的质量认可程度。比如用户的满意程度，那么具体他满意在哪个方面：功能、性能、操作界面、开发技术、抑或是其它因素？及时总结经验教训，分析整理其中具有普遍性的管理思想或业务处理流程，为下一次开发积累成功的经验。

“看来楼上谈的项目成败因素和先前的那个帖子有很大的出路”
    是的，原因有2个：第一是视角不同；第二是个人真正独立主持（自己说了算的）的大部分项目较小。宁波是个发展中的城市，其产业的99%是个私企业，那些老板很精的，尽管舍得花钱，但钱得花在刀口上，不会动不动就搞个“形象工程”。我举个例子：
    我一个死党同学介绍的一个汽车销售商与我接洽，希望建设一个汽车销售网站，提出了一堆设想，当然也需要“与众不同”。当时我提出一个“汽车档案”的构思，跟踪到每一辆销售汽车，那么可以得到很多有用的信息：比如季节的车型销售情况、车型的维修率、各车型的货源组织情况分析等等。当时他问我开发这样一个网站要多少钱？由于是死党介绍，我跟他说保守估算5万人民币以上。他听后说2万元你做不做？一时无语，只好尴尬地握手言别。后来他对我的死党这么说：靠！你给我介绍的是什么人呢？给他2万了他都不做，外面到处都是1800元一个网站。

楼上的例子真精典
所以大的公司作了系统没人用
小公司出不起钱作系统。。
这是普遍的社会现像

根本就不是出不起钱，2万的钱还是能出的起的，只是有更便宜，更烂的，但他觉得勉强够用。