项目的出发点－－人力资源？项目本身？

项目的出发点－－人力资源？项目本身？
daoger

昨天和项目经理说了一下最近的工作，无意中也说了一下项目今后的改造问题，
结合我们现在的项目，遂产生了一个疑问：一个项目的出发点应该是什么？

一个项目的启动受到方方面面因素的影响，用户需求的可行性、软件开发人员的
限制、技术储备是否充足、时间是否够用这些都是主要因素，同时免不了还有项目收
益的问题。自己综合各方面的因素认为项目的出发点应该是项目本身，在很大程度上
也就是用户需求，抛出除需求以外的因素，综合全面的分析用户需求，力求使系统完
备的满足用户需求；用户在使用中是否方便灵活、是否具有较强的健壮性，这些都是
在项目分析设计之初要充分考虑的问题；从软件开发人员方面讲，在充分满足用户需
求的同时，考虑如何使项目开发工作量尽量少，开发迅速，架构清晰明了，节约成本，
增加项目收益，易于以后的维护，也是不可缺少的。

但是在现实中又是怎么样的呢？许多项目的出发点不是项目本身。由于软件开发
的本源还是人，项目的另一个出发点就成了开发人员本身。开发人员的设计水平、技
术水平，人员的配备，开发人员的热情成了决定项目的绝对因素。只要能拉到项目，
不管自身条件是否具备，项目都可以随时开工！

一块肥肉就在嘴边，你不想吃？没有条件，创造条件也要吃！

项目时间紧，可是人手不够怎么办？先启动项目再说！

前期分析设计还没做好，好多问题还没考虑怎么办？抛弃详细设计，从概要设计
开始自己理解着干，有的概要设计不也很“概要”吗？

开发人员技术水平不够，业务还没理解怎么办？加加班，贤能完成业务功能再说！

在这种情况下，项目是根据现有的分析和开发人员的自身水平进行项目的设计和
编码，同时因为前期准备不足，更别说文档和测试了。项目开发基础好的公司应该还
好一些，而对于项目基础薄弱，项目用到的开发语言有“真空”现象的公司，真的难以
想象，那这个项目做完了也是一个噩梦的开始！由于项目前期的准备、分析设计等都
没有做好，以后的后续开发也是这一情况的延续，更不用说缩减项目维护成本，增加
收益了。

而现实就是现实，项目最终还是用户说了算，用户认可了，一切都OK！只要和用户
搞好关系，项目差些，能用就行；功能死板、使用不方便灵活，也说的过去；维护费用
增加了，和用户签个新合同，再增加点功能和模块，也就挣回来了。有了这样的先例，
那以后的情形也就可想而知了，也更别谈为了长远利益而积累经验、做技术储备、培养
新人、提高员工素质了。

说到这里，我不得不怀疑自己最初的观点了。项目果真是从开发人员自身出发而不
是从项目本身出发？缺少分析设计人员；软件行业有水平高经验丰富的系统分析师啊！
开发人员技术水平不高；行业里的牛人多得是啊，再说有时间可以给现有开发人员组织
短期培训，设立激励制度，增加技术业务评定一项，于待遇奖金结合提高学习热情，提
高开发水平啊！机器不好，影响开发效率；淘汰旧设备增添新硬件啊！这些问题不是没
有解决办法，可是事情没有那么简单，费用是关键因素！市场开拓人员为了拉一个项目
可以请用户吃饭等等等等，费用很容易报销，因为结果是立杆见影的；而以上的费用谁
来出？你说过会有什么什么好处，会有什么什么的效果，可是再说也没用，就是没钱！

由于这种种原因，难道项目本来就是以人力而不是以项目、做更好的产品作为出发点
的吗？我现在有点迷茫了！我工作时间不长，项目经验也不多，正儿八经参与的项目现在
就两个，现在的项目已经近一年了，以上都是我自己对开发工作的思考与理解，肯定有不
对和不足的地方，希望各位老大、同仁能给我一个答案！

我很奇怪为什么会从开发人员出发。作为一个开发人员，没项目做我每天上网看看新闻泡泡妹妹，有项目我要天天忙碌加班，为什么我会上赶着主动要求开始一个项目？

我得意思不是说开发人员要天天盼着有项目，我是说在一个项目启动时的出发点问题！
可能是我没说清楚！

then what's your point?

我想说的是在项目中是应该完全抛弃用户需求以外的因素进行分析设计还是仅仅从现有人力资源（技术水平、人员配备等）出发搞一个豆腐渣工程！

看不懂啊看不懂

市场人员拉到一个项目，比方说是一个适合于B/S的系统，而公司里懂网页开发的人又很少，懂java的也很少！

在这种情况下，如果从项目本身出发，我认为系统分析设计人员（假设水平很高）应该完全抛弃开发人员的技术水平因素和人员配备，在充分考虑用户需求的基础上对系统进行分析设计；分析设计人员只管系统的分析和设计，他不管开发人员在技术上怎样实现，他关心的只是自己的设计能否充分满足用户的需求、能否尽量减少开发的工作量、能否具有适应用户需求变更的灵活性、是否具有系统以后维护的简易性和系统的健壮性。作为项目组长，他应该了解实现这种系统设计的常用技术（最起码是要听说过），搜集技术资料，综合权衡各种技术的利弊，最后确定所使用的技术，投入开发；他也不要考虑自己的开发人员对自己要采用的这种技术是不是掌握熟练，他的出发点就应该是项目本身。作为开发人员，需要有较强的学习能力，并不能因为你自己没用过这种实现起来更简单的技术就排斥它，而选择你自己比较熟悉但是工作量可能大许多的技术。
当然这样的项目开发流程也许只是我得理想状态，其中免不了有分析设计人员和项目组长的交流、项目组长和开发人员的交流、开发人员内部的交流！

如果从开发人员本身出发，你的开发人员什么技术比较熟，项目就采用什么技术！用java的人有很多只是做过桌面应用程序，那么我们就有几个模块按照应用程序的模式来进行设计和开发实现；用过jsp的水平也不高，那我们就用设计的尽量功能生硬点，因为好实现嘛！没人用过spring、webwork、jstl、ajax等等，那就不用，用原始的在jsp文件中嵌入java代码的形式；有人没用过java，那就一个页面对应一个类！

我承认上面说的“豆腐渣工程“夸张了许多！我也承认在现实开发中从开发人员出发有时也能做出比较好的项目，可我觉得这应该也只是少数情况，想做好项目、做出好的产品还得从项目自身出发！当然，实际中要根据实际情况自己把握灵活性，这不是教条主义！

可是，现实中有很多项目都是以开发人员作为出发点，根据项目组的开发水平来进行项目设计，那我大学的时候为什么还要学习《软件工程》啊？难道软件工程只是一种理论上的研究？

所谓人员系统分析分析设计人员需不需要对项目最终结果负责?
<软件工程>告诉你应该完全抛弃开发人员的技术水平因素和人员配备?
<软件工程>没告诉你要做风险管理吗?

倾巢之下岂有完卵.

因为对'上进'人人都有不同的看法.

我在7楼的时候也说了，完全抛弃其他因素从项目本身出发，按照步骤一步一步的进行的开发流程也许只是理想状态，系统分析人员当然要为项目负责，但不是为项目的最终结果负责，只要自己的系统设计方案的到项目组长的认可，项目组长签字，那么设计人员就不需要再对项目负任何责任了，对吧！

我的理想状态下是可以完全抛弃开发人员的技术水平因素和人员配备，但现实中这是必须考虑的，但是一个项目风险很大而收益也很大的项目你会怎么对待？因为巨大的风险，要么从自己现在的能力出发不接这个项目，要么为了巨大的收益接手，之后还是因为风险你只能从现有开发人员出发来进行项目的设计和开发，那你的项目各方面如何保证呢！

如果人手不够，项目紧急，可以招聘高手参与开发，但是这种想法不属于从现有开发人员为出发点，正是认识到项目风险才以项目本身为出发点尽量减少风险。那些搞外派的公司不就是靠着个挣钱嘛！但是招聘高手也有风险，他是不是能尽快融入团队、技术水平到底怎么样、业务知识储备怎么样、对项目设计的理解等等都是要考虑的。

我只是想知道，在项目开发中以项目本身作为作为出发点和完全以开发人员作为出发点这两种情况在现实中的差距到底有多大？到底是应该以项目本身为出发点还是以开发人员为出发点？