主题：【原创】软件开发项目中的需求开发问题 -- 闲云野熊

既然是订制新系统，即或是改造旧系统，几乎可以肯定功能有变化，不太可能全面照搬旧的流程。事实上，很多问题都出在旧的流程不适应新技术。特别是由手工流程改为自动化流程时，如果要求新系统适应旧的思想观念，将导致系统建设事倍功半。当然，改造用户思想很难，但必须有这个意识。

妥协不是软件开发者的责任，但是开发者需要提供解决矛盾的方案，如果总把问题推给用户，最后结果是承建商出局。

其次我所说的矛盾是指用户很多部门试图通过新系统的引入改变部门在组织中的地位，或是改变分工方式，这种矛盾是很难调和的，对于承建商的需求开发部门而言，这是陷阱，很容易导致项目死亡，必须识别出陷阱，提出技术解决意见，依靠用户的上级最终解决。很微妙，但必须会做。

开发者，不止是程序员，还包括系统分析师、设计师，都并不关心系统是否真正贴近用户需要，关心的是系统设计是否符合提交给用户的需求文档（这当然是乙方按乙方的需求作的，骗甲方签字而已），在此基础上，希望系统尽可能简单，尽可能可以照抄以前的设计。这是客观现实。

我主张将设计开发者与用户隔离开，通过需求开发人员进行交流，而不是让开发者直接与用户见面。理由如下：

（1）开发者会尽量选择简单的方案说服某个不懂行的用户，然后说这是用户同意的，但这不一定符合用户组织的利益。

（2）让开发者在绞尽脑汁设计、编写系统的同时费很多心思捉摸用户的政治意图和组织结构是不人道的。尽管在很多人看来开发者已接近牲畜。

（3）系统设计开发者与需求开发者虽然同属乙方，但由于在组织上分离，需求开发者会在一定程度上代表用户利益，监督系统设计开发者。同时需求开发的有特殊的业务知识和技术知识、人生经验要求，从人力资源使用上也应该单独分出来。

（4）分离还可以保护系统开发者，当用户不满意系统建设情况，我们可以调离需求开发者而不影响系统进度，满足用户的面子要求。而不使系统建设实际受损。有谁愿意接手一个用户不满意、没有利润的半截工程？