神马文学网也谈谈影响项目成败的因素
来源：百度文库 编辑：神马文学网 时间：2024/04/28 03:34:14
个人负责和经历的项目不多，自92年毕业工作以来持续在IT业偏软方向努力，第一个独立负责的项目是1993年3月开始给一个宾馆写一个宾馆管理系统，包括并不内行的硬件系统，历时半年。个人觉得最难的是写电话程控交换机的数据接口，为此我还在苏州有线电一厂待了近一个月。从此走上了不归路，写到这里心里还有点......呵呵。
那么经历的最大项目是和台湾（好像还有日本股份）一个资讯企业合作，给某个地方银行写银行管理系统，包括硬件项目大概120万美金，具体软件开发占多少比例不是很清楚，估计不低于50%。个人负责其中会计部分。
2000年以后个人主要给一个学院讲课，比如C语言、数据结构、软件工程、MIS等偏软的课程，业余时间打理自己的2个小企业（一个软件、一个外贸）。前2年听说“阿狗阿猫”们都去开发游戏软件或网络游戏市场了，游戏是我第三生命，当然不甘落后，去年底开了一个SF，现在注册人数4500+，每天在线人数在60--120左右，人气还在不断上升中。今后随着对游戏软件技术的摸索和经验的积累，想开发自主产权的游戏、想在游戏市场分点汤羹。
啰里啰唆这么多，主要在整理自己对影响项目成败因素的思考。所以请各位放心，我下面说谈的影响因素可能不是最经典或合理的，但一定是个人最精粹的经验整理，毫无保留地奉献给这里--我的第一个博客。
一、态度
委托方和开发方，对于最后开发完成的软件而言，是谁的成果？我的答案是委托方的成果，开发方只是用某种技术（当然主要是软件技术）完成了委托方布置的“作业”，或者说开发方用软件技术实现了委托方的管理和经营的思路。
二、需求
需求阶段最容易造成矛盾和隐患，而且往往是致命的因素。原因只有一个：开发方重技术、委托方重管理。所以培养一个合格的需求收集、分析人员很难啊，既要听得懂委托方的管理思路、又要用计算机技术去做分析和还原。
关于“隐性需求”有这样三种情况：
1、委托方清楚自己的需要，并且表达出来，但开发方未能理解（或听不懂）；
2、委托方清楚自己的需求，但表达不出来，需要开发方去体会或理解；
3、委托方知道存在问题，但不知道原因和解决办法，需要开发方提供参考意见，希望通过软件系统来解决或规范。
从上可以看出解决了1、2点后，可以极大地保证委托方的认同感了，估计这项目十拿九稳；保证了第三点后，开发方想不赚钱都难了。所以初步的接洽和初步的需求交流很重要，需要派经验丰富的、亲和力高的工作人员去。
三、委托方的参与性、参与度
参照第一点：态度。不仅开发方要明确我是去做服务的，而且要让委托方（主要高层或决策领导）时时刻刻知道：你才是真正的开发者，我只是用软件来实现你的思想。俗话说：老婆是别人的好，小孩是自己的好。你要让他深深地参与到开发过程中来，让他把这个项目当作自己的小孩来养。这时候你要钱、要物都好说。个人这一点比较有体会，我没有碰到恶意欠费的，通常委托方都会提前问我要不要先打点经费过来，包括和政府和学校等老爷单位。这点比较自豪（没办法人品好......赫赫）。
四、客户培养
客户培养很重要，培养的基础和目标都是诚实、以诚相待。培养过程贯穿整个过程，比如我们做一个需求分析或系统规划，通常有2个版本，一个给他们（委托方）的技术员看，一个是给他们的领导看。这两个版本绝对不能相同、不能偷懒。
五、其他
其实开发过程中，还有很多很多关系成败的关键因素。比如说技术、人员、计划进度、成本核算等，当然还有风险控制（风险不可回避，主要关键是要明确风险责任）。个人觉得关系项目成败的很多关键因素集中在初步接洽和初步需求交流上，就像找对象，第一印象很重要，好的开始是成功的一半。
六、我接项目的一般过程
这里说的项目不是上面领导指派的，不是纵向而是横向课题。如果有项目，一般我会亲自去做第一次接洽。了解以下内容：
1、项目名称、目的、作用（意思），委托方有无更深层次的开发用意；
2、首先思考项目或未来系统的边界，为将来需求交流明确：哪些是系统内、哪些是系统外？
3、以现有的、现掌握的技术来估算该项目软件开发实施（详细设计与编程）阶段的工作量，并依据人工来估算开发成本，然后按软件实施阶段占30-40%比例来反推整个项目的开发成本。项目成本测算很敏感，高了吓跑用户、低了怕有去无回，我也参考了很多资料，但发现真正能拿来用的还是经验。其实30-40%也不是一定的，主要依据你团队或公司对类似项目开发成功的技术把握度。因为这个阶段依赖外界因素较少，通常我依此来测算开发成本。
4、安排需求调查与分析
一般来说需求调查手段有2种：会谈和问卷。注意各自特点，个人总结，会谈调查结果--比较诚实、真实；问卷调查--可以调查一些比较敏感的内容。
PS:给刚入道男孩女孩一点建议，如果安排你去收集需求，并且和对方不熟悉，你脸皮又比较薄。你可以这样做，到对方企业收集他们工作时需要填写各种空白单据，如果你看不懂就请教他们怎么填写，在他们教你的同时注意收集他们工作的业务处理流程。
另外，请问一下各位：你们有没有碰到过空着双手去做调查工作的人员？现在有些大学生连上课也不带任何东西，带本教材给足教师的面子了。
5、安排委托方共同参与系统规划、设计未来系统的“美好蓝图”，呵呵。
6、相对独立的软件实施过程，注意时刻和委托方沟通系统实施进度、完成度。
7、整合测试和用户培训，用户操作培训不可少，再小的系统也要安排工作人员到现场培训，其实这也客户培养的一个内容。俗话说：阎王好见、小鬼难缠。
8、整理开发文档、备案、部分移交用户，考虑需不需要为客户制定相应的规章制度。
9、最后不要忘记收回尾款，如果因为种种原因，打算放弃尾款，那么意味着你将打算放弃这个客户。
10、开发方总结，总结回绕着这2个重点：用户对该系统的工作使用依赖程度和满意程度。因为依赖程度决定了软件的价值性、满意程度决定了软件的质量认可程度。比如用户的满意程度，那么具体他满意在哪个方面：功能、性能、操作界面、开发技术、抑或是其它因素？及时总结经验教训，分析整理其中具有普遍性的管理思想或业务处理流程，为下一次开发积累成功的经验。
那么经历的最大项目是和台湾（好像还有日本股份）一个资讯企业合作，给某个地方银行写银行管理系统，包括硬件项目大概120万美金，具体软件开发占多少比例不是很清楚，估计不低于50%。个人负责其中会计部分。
2000年以后个人主要给一个学院讲课，比如C语言、数据结构、软件工程、MIS等偏软的课程，业余时间打理自己的2个小企业（一个软件、一个外贸）。前2年听说“阿狗阿猫”们都去开发游戏软件或网络游戏市场了，游戏是我第三生命，当然不甘落后，去年底开了一个SF，现在注册人数4500+，每天在线人数在60--120左右，人气还在不断上升中。今后随着对游戏软件技术的摸索和经验的积累，想开发自主产权的游戏、想在游戏市场分点汤羹。
啰里啰唆这么多，主要在整理自己对影响项目成败因素的思考。所以请各位放心，我下面说谈的影响因素可能不是最经典或合理的，但一定是个人最精粹的经验整理，毫无保留地奉献给这里--我的第一个博客。
一、态度
委托方和开发方，对于最后开发完成的软件而言，是谁的成果？我的答案是委托方的成果，开发方只是用某种技术（当然主要是软件技术）完成了委托方布置的“作业”，或者说开发方用软件技术实现了委托方的管理和经营的思路。
二、需求
需求阶段最容易造成矛盾和隐患，而且往往是致命的因素。原因只有一个：开发方重技术、委托方重管理。所以培养一个合格的需求收集、分析人员很难啊，既要听得懂委托方的管理思路、又要用计算机技术去做分析和还原。
关于“隐性需求”有这样三种情况：
1、委托方清楚自己的需要，并且表达出来，但开发方未能理解（或听不懂）；
2、委托方清楚自己的需求，但表达不出来，需要开发方去体会或理解；
3、委托方知道存在问题，但不知道原因和解决办法，需要开发方提供参考意见，希望通过软件系统来解决或规范。
从上可以看出解决了1、2点后，可以极大地保证委托方的认同感了，估计这项目十拿九稳；保证了第三点后，开发方想不赚钱都难了。所以初步的接洽和初步的需求交流很重要，需要派经验丰富的、亲和力高的工作人员去。
三、委托方的参与性、参与度
参照第一点：态度。不仅开发方要明确我是去做服务的，而且要让委托方（主要高层或决策领导）时时刻刻知道：你才是真正的开发者，我只是用软件来实现你的思想。俗话说：老婆是别人的好，小孩是自己的好。你要让他深深地参与到开发过程中来，让他把这个项目当作自己的小孩来养。这时候你要钱、要物都好说。个人这一点比较有体会，我没有碰到恶意欠费的，通常委托方都会提前问我要不要先打点经费过来，包括和政府和学校等老爷单位。这点比较自豪（没办法人品好......赫赫）。
四、客户培养
客户培养很重要，培养的基础和目标都是诚实、以诚相待。培养过程贯穿整个过程，比如我们做一个需求分析或系统规划，通常有2个版本，一个给他们（委托方）的技术员看，一个是给他们的领导看。这两个版本绝对不能相同、不能偷懒。
五、其他
其实开发过程中，还有很多很多关系成败的关键因素。比如说技术、人员、计划进度、成本核算等，当然还有风险控制（风险不可回避，主要关键是要明确风险责任）。个人觉得关系项目成败的很多关键因素集中在初步接洽和初步需求交流上，就像找对象，第一印象很重要，好的开始是成功的一半。
六、我接项目的一般过程
这里说的项目不是上面领导指派的，不是纵向而是横向课题。如果有项目，一般我会亲自去做第一次接洽。了解以下内容：
1、项目名称、目的、作用（意思），委托方有无更深层次的开发用意；
2、首先思考项目或未来系统的边界，为将来需求交流明确：哪些是系统内、哪些是系统外？
3、以现有的、现掌握的技术来估算该项目软件开发实施（详细设计与编程）阶段的工作量，并依据人工来估算开发成本，然后按软件实施阶段占30-40%比例来反推整个项目的开发成本。项目成本测算很敏感，高了吓跑用户、低了怕有去无回，我也参考了很多资料，但发现真正能拿来用的还是经验。其实30-40%也不是一定的，主要依据你团队或公司对类似项目开发成功的技术把握度。因为这个阶段依赖外界因素较少，通常我依此来测算开发成本。
4、安排需求调查与分析
一般来说需求调查手段有2种：会谈和问卷。注意各自特点，个人总结，会谈调查结果--比较诚实、真实；问卷调查--可以调查一些比较敏感的内容。
PS:给刚入道男孩女孩一点建议，如果安排你去收集需求，并且和对方不熟悉，你脸皮又比较薄。你可以这样做，到对方企业收集他们工作时需要填写各种空白单据，如果你看不懂就请教他们怎么填写，在他们教你的同时注意收集他们工作的业务处理流程。
另外，请问一下各位：你们有没有碰到过空着双手去做调查工作的人员？现在有些大学生连上课也不带任何东西，带本教材给足教师的面子了。
5、安排委托方共同参与系统规划、设计未来系统的“美好蓝图”，呵呵。
6、相对独立的软件实施过程，注意时刻和委托方沟通系统实施进度、完成度。
7、整合测试和用户培训，用户操作培训不可少，再小的系统也要安排工作人员到现场培训，其实这也客户培养的一个内容。俗话说：阎王好见、小鬼难缠。
8、整理开发文档、备案、部分移交用户，考虑需不需要为客户制定相应的规章制度。
9、最后不要忘记收回尾款，如果因为种种原因，打算放弃尾款，那么意味着你将打算放弃这个客户。
10、开发方总结，总结回绕着这2个重点：用户对该系统的工作使用依赖程度和满意程度。因为依赖程度决定了软件的价值性、满意程度决定了软件的质量认可程度。比如用户的满意程度，那么具体他满意在哪个方面：功能、性能、操作界面、开发技术、抑或是其它因素？及时总结经验教训，分析整理其中具有普遍性的管理思想或业务处理流程，为下一次开发积累成功的经验。