- 发帖可能变空内容，邪门暂不知所以然
- 『稷下学宫』新认证方式，24年网站打算和努力目标
主题：【原创】软件开发项目中的需求开发问题 -- 闲云野熊
链接出处终于看到有人在河内讨论软件工程问题了，兴奋ing,但在下还是决定另开一题，因为在下关注的问题是属于项目管理范畴，而不是软件工程范畴。
本文所讨论的软件开发项目，是特指为某客户订制开发软件应用系统，而不是根据市场需求开发一个软件产品。因为本熊没有这方面工作经验，所以没有发言权。
在本文中，本熊只是提出了自己遇到的问题和自己的看法，并没有多少理论支持，希望河内高人指教。
在软件开发项目中，本熊最感到困难的就是需求的确定，事实上，在本熊参与开发的所有项目中，从没有需求真正确定的例子。有的只是开发人员与用户的妥协产物：
成功的项目：
开发人员：我只能做到这样了，以后咱们再搞一个二期工程？
用户：我先凑合用吧，不过按合同我们还有个适应性维护期，到时候你可得随叫随到给我改！
。。。。。。。
不成功的项目：
开发人员：我只能做到这样了，这已经比当初的需求多多了！
用户：你们这样不行呀！这个系统现在跑不起来！要么换人，要么加人给我做，什么？没人了？！扣钱！
。。。。。。。。
几乎所有的开发人员都有一个梦想：让我经历一回真正的瀑布开发流程吧！所有的需求都在最初的阶段得到确定，我们获得了一个完美的系统定义。。。。。但是梦想肯定是梦想。
为什么总是这样呢？
本熊认为原因可能有以下几点：
（1）开发一个新系统，尽管是用户订制的，但这是一个以前从未存在过的系统。任何人无法凭空想象该系统如何运作，如何实现以前从未实现的功能。因此没有人能够告诉开发人员这个系统的功能如何匹配系统建设目标。只有获得了一个实际的系统才能检验实际运行能否满意。而在实施过程中，用户的灵感总会被不断激发，产生新的愿望。
（2）一个系统的使用肯定牵扯到用户群体中的很多人，每个人，每个部门都对系统有着自己的幻想，都希望维护自己的利益。而这些利益不一定重合为系统建设目标。因此需求调研有如盲人摸象，只能获得很多片面、破碎的信息。这些信息之间有矛盾，不可调和，只能妥协，但妥协只能带来各方面都不满意。
（3）对项目建设有决定权的领导有自己的看法，但这些看法只能通过下级人员反映给开发者。下级人员会塞入自己的意见。其次，系统的使用者不关心投入，只关心系统是否减轻自己的负担。因此最初的需求调研肯定获得了很多锦上添花的需求，而不是系统建设目标所必需的需要。
（4）开发者并不实际关心系统是否贴近用户需要。只是关心是否不被抓住把柄。承建商只关心预计开发成本是否压缩利润。
针对以上问题，本熊认为
（1）必须把需求开发视为一个过程，包括原始需要调研、整理出面向用户需要说明、面向用户的功能设计、面向开发者的需求分析、面向用户的操作运行设计、面向开发者的设计任务书。分清需要、功能需求、操作需求、性能需求、系统集成需求之间的关系。
无论用户代表多么有经验，需求开发必然是一个递进的、迭代过程。因此在需求开发过程中不要急于确定系统边界（这是无法确定的），应该首先关注当前尚未实现的最主要的功能。
（2）认真分析用户群体，找到真正的组织结构图，找到用户在系统中的位置和相互关系。并在用户中建立系统建设代言人链，在这一链条中的成员必须真正是系统建设的责任和利益相关者。并且直达决策层。如果该链条中的成员不能达到决策层，必须纠正，否则项目无法成功。
（3）建立项目需求开发组，成员一定不能是系统设计者。强迫用户、需求、设计开发者之间的交流通过文档进行。并隔离用户和设计开发人员。避免用户对系统设计、开发组织的干扰，避免设计开发者之间不能充分理解用户需求。同时审定需求追踪和需求变更管理。
（3）建立需求字典，使双方讨论问题概念一致。
（4）建立用户能够接受的成本估算方法，与用户共同估算开发成本，核算需求变更成本。
（5）必须记住，与其他系统的接口是客观存在的，并不因为用户没有想到就不存在，并不因为可以推迟考虑就减轻，反而可能更严重。在处理接口时的原则是没有接口谁的承受能力低谁的工作量大，谁越早做出行动和形成文档谁越主动。
本帖一共被 1 帖 引用 (帖内工具实现)
Business drives IT,而不是像国内那样反过来。
资本家惜财如命，每上马一个项目都有它的目的。他的要求他很清楚。这是开发任何系统的基础。虽然在具体的开发过程中会有很多反复，很多修改，或者由于外界情况变化了导致整个项目停滞或是下马。但就根本而言，资本家花钱是前后斟酌过的，是有目的的。
有的项目很大，一是不可能把要求搞得很清楚，通常的做法就是分阶段实施。先交付一部分，然后根据用户反馈和当时的具体情况，决定下一步如何。
比较好的一个例子是Bank of America(美国银行?)的Online Banking系统。这个系统我从一开始就使用上了，这么多年看着它一步步的完善，一步步的改进。到现在，无论是功能，还是性能都非常得不错。不仅极大的便利的他的用户，提高了服务质量，并且极大提高了他们的工作效率，降低了用户支持成本。一个真正双赢的例子。
就象老熊所说，这个用户要求的征集，也会很繁琐。粗略地分，可以分成对已有系统的维护和新系统的创建。
对已有系统的维护相对比较简单。用户已经对于系统有一定的印象和经验，所以对于自己想要什么不想要什么，会有一个大概其的印象，而不至于满口跑火车。即使他想要加一些新功能，也会依照已有的系统来类比。对于作软件的也比较省事儿，估算时间成本时可以比照已有系统，八九不离十。这就象一辆跑车，车主要求车厂给追加个CD天窗ABS之类...
对于从无到有的新系统，这个方法就不适用了。因为用户没有印象，所以不能，也不应该指望用户在一开始就把所有要求全部提光，后来就一声不吭。就像阔佬托车厂给他造汽车，车厂当然不会上来就把车造出来再给用户，“看，这就是你要的汽车！”“什么？我没有要五个方轱辘呀？”得，又得重新造。
车厂（好像现在还不存在这种车厂，咱打比方哈）这种情况下应该排个设计师，跟客人边谈边画，画完给他看，“喏，这就是你要的车子”“嗯，屁股能不能小点，轮胎能不能再宽点儿... ” 就这样边谈边改，最终差不离的时候才算定稿，然后才交付车厂进行生产。这个Rapid Prototype(RP)方式在软件开发上即可用所谓快速开发，先把用户能看得见的东西给他拿出来，大家看着实物，边谈边改；不看着实物，光是空对空地讲，回头他经常会给你来个彻底不承认。RP可能会增加用户需求征集时间，但是在这里多花一个钟头后头能省好几个钟头。
对于老熊说的(2),非常有同感。这个要求从直接用户那里上来，一路上经过BA/BSA/TSD几道手，往往就面目全非。最好的是能找到最终用户，由最终用户来敲定而不是由他们的领导来提要求。领导们只关心这个“18摸”计算机挖地雷快不快啊？ 
对于系统接口的问题，咳，这个其实更多的是个政治问题了，公司政治，已经不是简单的技术问题了。有人能做不原意做，有人不能做却硬撑着要做... 这些都已经是软件工程之外的问题，属于“人际工程”...
有两种情形，其一是用户已经有一套行之有效的Process（业务流程？），虽然没有一个软件系统，但依样画葫芦，只不过是把手动的流程变成自动的流程，这种情形好办。其二是用户现有的流程很乱，更糟糕的是用户有不现实的期待，以为新的系统可以自动解决他们所有的问题。这种情况下，首先要教育用户，买更多的时间。其次要依赖对该行业的理解，设法先把业务流程定义好。当然，还可以买象SAP这样的软件包，直接把同行的业务流程抄过来。
妥协不是软件开发者的责任，软件开发的责任是尽可能早点发现矛盾所在，让用户老板自己决定。我个人的经验，在同一家公司内部，极少有不可调和的矛盾的，动动脑筋，很多时候都能双赢。
这要看哪一级别的领导了，负责拍板的，最关心的是投入多少，收获多少。比较强势的领导，会事先收集使用的意见，制定一系列的指标，计划，算清楚成本利益之后，才开始软件开发，而且在开发的过程中，会确保不偏离原有的目标。
这要看开发者是否特指程序员，在较大型的项目中确实可能这样，只是对着Spec（功能定义？）编码，在较小的项目里，Spec往往较为含糊不清，在这种情形下，程序员应该更频繁的和用户交流。无论如何，我总是鼓励程序员尽可能多点和用户交流，这样有助于提早发现问题所在。
至于开发商，把项目做好，有助于拿到下一个项目，用户总是有新的要求的。至于开发成本和利润，就要看合同是怎么签的了。
既然是订制新系统，即或是改造旧系统，几乎可以肯定功能有变化，不太可能全面照搬旧的流程。事实上，很多问题都出在旧的流程不适应新技术。特别是由手工流程改为自动化流程时，如果要求新系统适应旧的思想观念，将导致系统建设事倍功半。当然，改造用户思想很难，但必须有这个意识。
妥协不是软件开发者的责任，但是开发者需要提供解决矛盾的方案，如果总把问题推给用户，最后结果是承建商出局。
其次我所说的矛盾是指用户很多部门试图通过新系统的引入改变部门在组织中的地位，或是改变分工方式，这种矛盾是很难调和的，对于承建商的需求开发部门而言，这是陷阱，很容易导致项目死亡，必须识别出陷阱，提出技术解决意见，依靠用户的上级最终解决。很微妙，但必须会做。
[ｃｃhｅre.com 西西河 懒厨]
这要看开发者是否特指程序员，在较大型的项目中确实可能这样，只是对着Spec（功能定义？）编码，在较小的项目里，Spec往往较为含糊不清，在这种情形下，程序员应该更频繁的和用户交流。无论如何，我总是鼓励程序员尽可能多点和用户交流，这样有助于提早发现问题所在。
至于开发商，把项目做好，有助于拿到下一个项目，用户总是有新的要求的。至于开发成本和利润，就要看合同是怎么签的了。
开发者，不止是程序员，还包括系统分析师、设计师，都并不关心系统是否真正贴近用户需要，关心的是系统设计是否符合提交给用户的需求文档（这当然是乙方按乙方的需求作的，骗甲方签字而已），在此基础上，希望系统尽可能简单，尽可能可以照抄以前的设计。这是客观现实。
我主张将设计开发者与用户隔离开，通过需求开发人员进行交流，而不是让开发者直接与用户见面。理由如下：
（1）开发者会尽量选择简单的方案说服某个不懂行的用户，然后说这是用户同意的，但这不一定符合用户组织的利益。
（2）让开发者在绞尽脑汁设计、编写系统的同时费很多心思捉摸用户的政治意图和组织结构是不人道的。尽管在很多人看来开发者已接近牲畜。
（3）系统设计开发者与需求开发者虽然同属乙方，但由于在组织上分离，需求开发者会在一定程度上代表用户利益，监督系统设计开发者。同时需求开发的有特殊的业务知识和技术知识、人生经验要求，从人力资源使用上也应该单独分出来。
（4）分离还可以保护系统开发者，当用户不满意系统建设情况，我们可以调离需求开发者而不影响系统进度，满足用户的面子要求。而不使系统建设实际受损。有谁愿意接手一个用户不满意、没有利润的半截工程？
我也是看着BOFA成长的. 刚开始那个臭. 动不动就秀给你看JAVA的STACKTRACE. 而且各个州的系统好象也没集成.
现在确实好多了, 界面也比以前强太多了
另一方面，我不知道国外的情况，但想来即使老板有明确的意图，但开发方总不能拉着老板谈上一个月甚至几个月的需求吧。最终还得与正在努力领会老板意图的员工谈需求，我不知道这些人会不会塞点私货进来。
熊兄客气了，和兄台对侃其实挺有趣的。
确实如此，一般来说，区别在于大改还是小改。
其次我所说的矛盾是指用户很多部门试图通过新系统的引入改变部门在组织中的地位，或是改变分工方式，这种矛盾是很难调和的，对于承建商的需求开发部门而言，这是陷阱，很容易导致项目死亡，必须识别出陷阱，提出技术解决意见，依靠用户的上级最终解决。很微妙，但必须会做。
这话对极。良好的开发商就是要提供解决方案，而且不止一个，向用户阐释各个方案的利弊，最终的决定权还是在用户手里。不了解国内的软件开发状况，我个人的经验是尽可能对事不对人。倒不是很担心项目死亡，关键在于合同的条款，看看谁为项目死亡负责。
这话实在不敢苟同。愚以为这样实在不是一个好的开发团队。小弟认为这大概就是与熊兄最大的分歧了。
熊兄或许认为软件开发能够象生产线的流程一样，但我认为，软件开发目前还属于初级阶段，太多东西没有办法标准化，流水线式的软件开发，还言之尚早。
我基本同意您的关于软件开发管理作为一门科学还不很成熟的看法。
不过我还是不同意您所提到的开发人员会真正考虑用户的实际需要的看法。从主观上，开发人员对软件企业负责，而不是对用户负责，如果开发人员使开发成本超过所得，企业将面临困境，所以开发人员只能建立一个符合合同规定的系统。这也是我认为尽管瀑布模型被认为是一个缺陷的模型，但在大多数系统开发时还是被使用的原因。
当然合同不是全部，国内一般注重行业开发经验。进入一个领域非常难，因此，在打入一个新领域时几乎肯定是要赔本的。如果只考虑合同规定的维护，肯定不能满足用户需要，企业付出的代价是今后很难涉足这一行业了。
因此上述两个方面是矛盾的。这也是我建议将需求开发与系统设计分开的理由。
从某种角度来看，开发团队交出一份让用户满意的产品，也是对软件企业负责，当然，所作所为必须在成本之内。
我并不怀疑大多数软件开发人员的职业道德，但如果面对一个简单并不违背合同的方案与一个更适合用户今后需要但复杂、可能存在超支风险的方案，作为设计人员您认为会选哪个？
作为一名甲方项目管理人员，我虽然比较倾向于善待开发人员，但现实告诉我，并不能无条件的信任他们。
可以考虑用use case地分析方法。
关于use case，有很多书介绍，比如Karl E. Wiegers德Sofetware Requirement.
我参与过得比较大的软件项目有两个是使用了这个方法，我觉得很有效率。对于一个时间上要求比较紧，业务流程还算比较清晰的项目来说，效果很好。但是如果想要启动快，条件是要有一队头脑清晰业务分析员（business analyts)，这样软件开发人员根据use case的基本描述就可以开工了，而且不会跑弯路。
如果时间紧，没有大量的时间去做需求调研，JAD Session(Joint Application Development Session)可以比较有效率的在短时间内搭起一个需求的架子。简单来说，就是将所有可这个项目有关系的人员（业务，终端用户代表，软件设计，软件开发，项目管理）召集起来做一个1-2天的workshop(业务会议），在会上集思广益，争取在最短的时间内把流程搭出来。
跟你说的这个JAD Session差不多...