对软件项目开发的一点思考

今天看到同事写的一些思考，感觉还不错，真的是通过这个项目让他成长起来了。

目录 I

1 引言 1

2 概念 1

3 国内软件项目角色分析 1

4 国内项目的一般性问题 2

5 客户与项目组对需求的认知情况 2

5.1 第一种情况 3

5.2 第二种情况 3

6 湖工项目实施过程中碰到的问题 4

6.1 项目边界问题 4

6.2 项目需求问题 4

6.3 项目计划、里程碑问题 4

7 结语 5

对软件项目开发的一点思考

湖工项目阶段总结

1 引言

湖工项目磕磕碰碰也进行了很长时间，其中的酸甜苦辣，其中的艰辛，不是一言两语能够说清楚。

湖工项目是为高校开发一套教务系统，是一个完整解决方案型项目，业务涵盖学生从入校到出校四年中的所有教学活动，用户包括：学生、授课教师，教务处各相关办公窒，校领导，离退休教师等。

在整个项目的诸多问题中，项目前期风险评估不足，过于乐观是最主要的问题，在项目实施过程中，项目边界不确定，项目需求不清，计划控制不好是现在所表现出来的问题的根源。这些问题常常引发我思考两个问题：

什么是软件工程？

什么是项目管理？

2 概念

“软件工程”的概念书上和网上都有，之所以有软件工程这个概念，是当时人们为了解决软件危机，而照搬其他领域已经很成熟的工程方法论到软件开中来，再慢慢发展和总结才形成今天我我们所看到的所谓的软件工程理论。软件工程并不能保证一个项目成功，但却能最大限度地保证项目不会失败，这也是软件工程的价值所在。

“项目管理”也是从其他领域来的，不是软件开发独创的。按照PMBOK红宝书理论，项目管理是将知识、技能、工具与技术应用于项目活动，以满足项目的要求（这个说得有点泛）。项目是为了创造独特的产品、服务或成果而进行的临时性工作。项目的“临时性”是指项目具有明确的起点和终点。当项目目标达成时，或当项目因不会达到或者不能达到目标而终止时，或者项目需求不复存在时，项目就结束了。

3 国内软件项目角色分析

软件开发是因人的需求而开始，又因人的需求被满足而结束。软件开发的根本是人，与技术无关，技术只是为了满足人的需求，不能满足人的需求的技术是毫无价值的。下面就来分析一下软件开发过程中所涉及到的各人各角色的特点。

表 31 软件项目中各角色分析

哪方

角色

特点

客户

高层领导

十分清楚项目目标，期望在指定的预算内达成目标。基本核心需求一定会坚持，对于不太影响目标实现的需求可以作让步

中层领导

基本清楚项目目标，按照高层的意思办事，为保证满足高层的要求，可能会对需求从严把握，但部分情况下可能迷失项目目标

基层用户

不太清楚项目的目标，只关心能不能解决他具体的本职工作问题，往往会提出一些匪夷所思的需求

公司

高层领导

很清楚客户的目标，想办法以尽量低的成本来满足。从本公司战略发展的角度来处理客户的要求

销售人员

为让客户签单，容易做出项目组无法满足的承诺，给客户过高的期望值

项目经理

背负超大的进度压力，期望需求尽量少，容易背离项目目标。遇到需求变化时，难以静下心来仔细思考

架构师

基本能理解项目需求，容易设计出过于超前的软件架构，也容易设计出粗糙的设计甚至无设计，以致某些需求无法满足，或者需要巨大的开发工作量

程序员

不太清楚项目的目标，对需求没有全局观，对于自己负责部分的需求了解得不深

测试员

不能得到“一手”的需求，需求往往是开发人员告知的，对软件需求可能有很多疑问，但没有时间或者没有机会去求证。

实施员

很清楚客户基层用户的需求，但向项目组反馈意见时往往得不到重视。部分情况下，容易陷于需求细节，而迷失了项目目标

总的来说：

客户一方总是倾向于：自己花最少的钱，让软件公司做最多的事；

软件公司一方总是倾向于：多拿客户的钱，尽量少做事。

4 国内项目的一般性问题

国内的项目，不管是开发过程还是开发完成，如果上线了，一般会遇到以下三种情况：

Ø 情况一、客户一直没有提出任何问题。

Ø 情况二、客户一开始提了一些问题，但很快就没有其他问题了。

Ø 情况三、客户一直在提问题，项目组解决这些问题后，新的问题又来了，如此不断重复。

分析：

情况一：估计客户没有怎么使用过这套系统，所以没提出什么问题。对于项目组来说，似乎不用再被麻烦的需求变更所纠缠，可以爽快地脱离此项目了。但对于客户来说，此系统白白花费了他们的钱，对他们没有任何实际价值，对于公司来说，花费了那么多的人力做出系统，客户却没用上，很可能收不到项目验收款。这种结果是“双输”。

情况二：可能是客户试用了一段时间后，觉得系统不能满足他们的需求，不再使用这个系统了。这种情况，项目估计很难验收通过，公司收不到项目款，客户不使用该系统，又是“双输”。

情况三：这可能是比较理想的情况，说明客户在不断地使用该系统。这些问题最开始会比较多，最开始项目组解决问题的速度会低于产生问题的速度，但后来问题逐步减少，直至基本消失，软件和用户的“磨合”过程终于完成，系统最终成为客户日常工作中的一部分。

5 客户与项目组对需求的认知情况

需求开发和需求管理会贯穿于整个项目周期，在整个软件项目开发周期中，随着时间的推移，项目组和客户对需求的理解程度会存在下面两种情况中的一种。

5.1 第一种情况

 

对于第一种情况，在项目刚开始的时候，项目组对需求的理解是为零的，客户在项目刚开始的时候，对需求是有一定认识的。随着时间的发展，客户对需求的理解越来越强，尽管项目组对需求的理解也同样在变强，但项目组对需求的理解总是落后与客户，这样需求分析工作肯定陷于被动，总是会被客户“牵着鼻子走”，很容易出现互相责怪的局面：客户责怪项目组水平太差，而项目组责怪客户需求变来边去！如果出现这种情况，项目进展往往不会顺利，甚至有失败的风险。

 

5.2  第二种情况

 

对于第二种情况，在项目刚开始时，客户对需求的理解确实比项目组强，但在很短的时间内对需求的认识迅速超过了客户，进而能引导客户对需求的理解。从图中的“交点”以后，项目组对需求的理解总是领先与客户。项目组应具备超强的业务学习能力，迅速理解客户的真正需求，抓住需求的本质，这样才能做出符合客户需要的软件系统。

6 湖工项目实施过程中碰到的问题

6.1 项目边界问题

在项目实施过程中，出于某些原因，项目边界一直得不到确定，这样造成一个很大的问题是：项目经理无法确定哪些需求该接受，哪些需求该拒绝，标书上又写得很泛，很可能客户一句话，可能要开发两三个月。项目边界不清晰时，项目经理就没有拒绝客户的依据，在博弈过程中很容易处于下风。客户的想法很跳跃，什么都想做，在客户现场发现别的公司常常以不在合同范围为由委婉拒绝客户的灵光想法，防止需求泛滥。

最理想的情况是，在项目正式编码前能确定好：哪些需求能做，做到什么程度？有限的预算只能做有限的事情，不能盲目乐观承诺。

6.2 项目需求问题

6.2.1 没有专业的需求管理

项目前期和项目实施过程中，没有进行专业的开发和需求管理工作，基本上是客户说了几句后就回来埋头开发，没有从整体上去把握和控制需求。经常开发一段时间后，出现无可用的需求来支撑编码开发，因为需求开发工作还在进行中。

最好的做法是，在正式编码前，一定要完成需求开发工作，然后在开发过程中逐渐的清晰需求。

6.2.2 对需求的认知滞后

项目经理和项目组对需求的认知一直滞后于客户，就像前文说的第一种情况，没有做到第二种情况，总是被客户牵着鼻子走，还被客户认为不专业，然后项目组再跟着抱怨客户的需求总是变来变去。

其实，湖工项目的精髓就在于业务，如果业务认知清楚以后，项目已经成功了80%。强智高校教务系统在教育行业立足十余载，靠的就是业务为王，他们的系统连IE以外的浏览器都不支持，但这并不妨碍他们卖出一套又一套的产品。

所以为了解决这个问题，最简单直接的方法是请一个业务专家，如果不能这样的话，只能是项目组慢慢陪着客户学习业务，这样就变成一场持久战，如果最后产品化战略能成功，再用产品的收益去填补项目研发过程的超支费用。

6.2.3 没有获取到真正的需求

项目需求的提供者为客户领导，客户领导对需求的理解不深入，项目经理过分依赖客户领导，没有向真正的用户挖掘需求。项目初期，项目需求基本上来自于客户领导，但客户领导又不是最终用户，这样就会造成开发出来的功能和真正用户的需求偏差很大，用户抱怨很大，最终会造成大量返工。

比较好的做法是，向基层用户收集需求，整理清楚后，请客户领导一来拍板确认。

6.2.4 没有专职的接口人

湖工项目都是由客户领导作为接口人，但领导比较忙，基本上没有时间，有时候去客户那里等了一天都无法确认一件事情。与客户交流时最好以开会的形式进行，相关干系人都要到场，会议结论以文档形式在会后发送相关人员，这样可以提高交流的效率，减少沟通成本。

6.3 项目计划、里程碑问题

由于项目边界和项目需求无法明确，项目的计划及里程碑也就很难确定，这样就造成项目进行到一半时，还是没有一份完整的开发计划，无法跟踪项目进度，很难估算出还需要多少人力，还需要多少时间，无限增大了项目风险。

7 结语

本文基本上从人的角度和需求的角度结合实际项目去分析软件开发，没有全面展开讨论，主要缘由时间和篇幅的限制，希望透过这两点能达到一叶知秋的目的，这两点就是人和需求，就像前文所说，软件开发起于人的需求被发现，而止于人的需求被满足。