- 发帖可能变空内容，邪门暂不知所以然
- 『稷下学宫』新认证方式，24年网站打算和努力目标
主题：【原创】软件开发项目中的需求开发问题 -- 闲云野熊
家园 【原创】软件开发项目中的需求开发问题 链接出处终于看到有人在河内讨论软件工程问题了，兴奋ing,但在下还是决定另开一题，因为在下关注的问题是属于项目管理范畴，而不是软件工程范畴。
本文所讨论的软件开发项目，是特指为某客户订制开发软件应用系统，而不是根据市场需求开发一个软件产品。因为本熊没有这方面工作经验，所以没有发言权。
在本文中，本熊只是提出了自己遇到的问题和自己的看法，并没有多少理论支持，希望河内高人指教。
在软件开发项目中，本熊最感到困难的就是需求的确定，事实上，在本熊参与开发的所有项目中，从没有需求真正确定的例子。有的只是开发人员与用户的妥协产物：
成功的项目：
开发人员：我只能做到这样了，以后咱们再搞一个二期工程？
用户：我先凑合用吧，不过按合同我们还有个适应性维护期，到时候你可得随叫随到给我改！
。。。。。。。
不成功的项目：
开发人员：我只能做到这样了，这已经比当初的需求多多了！
用户：你们这样不行呀！这个系统现在跑不起来！要么换人，要么加人给我做，什么？没人了？！扣钱！
。。。。。。。。
几乎所有的开发人员都有一个梦想：让我经历一回真正的瀑布开发流程吧！所有的需求都在最初的阶段得到确定，我们获得了一个完美的系统定义。。。。。但是梦想肯定是梦想。
为什么总是这样呢？
本熊认为原因可能有以下几点：
（1）开发一个新系统，尽管是用户订制的，但这是一个以前从未存在过的系统。任何人无法凭空想象该系统如何运作，如何实现以前从未实现的功能。因此没有人能够告诉开发人员这个系统的功能如何匹配系统建设目标。只有获得了一个实际的系统才能检验实际运行能否满意。而在实施过程中，用户的灵感总会被不断激发，产生新的愿望。
（2）一个系统的使用肯定牵扯到用户群体中的很多人，每个人，每个部门都对系统有着自己的幻想，都希望维护自己的利益。而这些利益不一定重合为系统建设目标。因此需求调研有如盲人摸象，只能获得很多片面、破碎的信息。这些信息之间有矛盾，不可调和，只能妥协，但妥协只能带来各方面都不满意。
（3）对项目建设有决定权的领导有自己的看法，但这些看法只能通过下级人员反映给开发者。下级人员会塞入自己的意见。其次，系统的使用者不关心投入，只关心系统是否减轻自己的负担。因此最初的需求调研肯定获得了很多锦上添花的需求，而不是系统建设目标所必需的需要。
（4）开发者并不实际关心系统是否贴近用户需要。只是关心是否不被抓住把柄。承建商只关心预计开发成本是否压缩利润。
针对以上问题，本熊认为
（1）必须把需求开发视为一个过程，包括原始需要调研、整理出面向用户需要说明、面向用户的功能设计、面向开发者的需求分析、面向用户的操作运行设计、面向开发者的设计任务书。分清需要、功能需求、操作需求、性能需求、系统集成需求之间的关系。
无论用户代表多么有经验，需求开发必然是一个递进的、迭代过程。因此在需求开发过程中不要急于确定系统边界（这是无法确定的），应该首先关注当前尚未实现的最主要的功能。
（2）认真分析用户群体，找到真正的组织结构图，找到用户在系统中的位置和相互关系。并在用户中建立系统建设代言人链，在这一链条中的成员必须真正是系统建设的责任和利益相关者。并且直达决策层。如果该链条中的成员不能达到决策层，必须纠正，否则项目无法成功。
（3）建立项目需求开发组，成员一定不能是系统设计者。强迫用户、需求、设计开发者之间的交流通过文档进行。并隔离用户和设计开发人员。避免用户对系统设计、开发组织的干扰，避免设计开发者之间不能充分理解用户需求。同时审定需求追踪和需求变更管理。
（3）建立需求字典，使双方讨论问题概念一致。
（4）建立用户能够接受的成本估算方法，与用户共同估算开发成本，核算需求变更成本。
（5）必须记住，与其他系统的接口是客观存在的，并不因为用户没有想到就不存在，并不因为可以推迟考虑就减轻，反而可能更严重。在处理接口时的原则是没有接口谁的承受能力低谁的工作量大，谁越早做出行动和形成文档谁越主动。
本帖一共被 1 帖 引用 (帖内工具实现)家园 如果是面向对象的软件项目 可以考虑用use case地分析方法。
关于use case，有很多书介绍，比如Karl E. Wiegers德Sofetware Requirement.
我参与过得比较大的软件项目有两个是使用了这个方法，我觉得很有效率。对于一个时间上要求比较紧，业务流程还算比较清晰的项目来说，效果很好。但是如果想要启动快，条件是要有一队头脑清晰业务分析员（business analyts)，这样软件开发人员根据use case的基本描述就可以开工了，而且不会跑弯路。
如果时间紧，没有大量的时间去做需求调研，JAD Session(Joint Application Development Session)可以比较有效率的在短时间内搭起一个需求的架子。简单来说，就是将所有可这个项目有关系的人员（业务，终端用户代表，软件设计，软件开发，项目管理）召集起来做一个1-2天的workshop(业务会议），在会上集思广益，争取在最短的时间内把流程搭出来。
家园 我还听过另外一个名字, Agile Development 跟你说的这个JAD Session差不多...
家园 agile methodologies 应该是一种软件工程的方法论，涵盖各个阶段的（个人理解，不太肯定）。 JAD Session一般只应用于需求分析阶段，从JAD得出的结果就可以用来准备use case。
家园 那么可以说JAD是Agile的头一部分了 回去翻翻Agile手册去，也没准偶们就是从JAD开始做的，只是不知道名字哈
家园 【原创】兄台，可不能拿着锤子到处找钉子亚 Agile Development 叫敏捷编程，也叫极限编程，相对最早的瀑布开发方式以及最近的RUP开发过程，是一种轻量级的软件开发方法论，从实践中来，充分发挥开发人员的主动性，主要针对需求不明确、不稳定的中小项目，听说大的项目也有用的。它的精神宗旨是：沟通、简单、反馈和勇气，对原来的开发方式进行了大胆的改进和颠覆，比如：结对编程（一个编一个看）、先写测试代码、计划游戏、小版本、隐喻（团队内部开发术语）、简单设计、代码重构、代码集体所有、每日集成、每周工作40小时（提高工作效率）、现场客户、编码标准，要求每个项目成员都编码、测试、倾听和设计，还有很多的策略和解决方案，每一项都非常值得深究，同样相对于每一项衍生出很多open source的framework和开发工具，最有名的就是：ant和junit，特别是junit听说是kent bake（极限编程的发明者）和Erich Gamma（《设计模式：可复用面向对象软件的基础》的作者，eclipse的总设计师）在飞机上完成的雏形，刚开始主要用java实现，最后被.net等吸收，现在升级为Xunit，在它之上有衍生出了dbtest等等很多的测试工具，扯远了。敏捷编程总之一句话：拥抱变化！
关于野熊的需求变化问题，我觉得分两种情况：
一、 公司是行业专家，这个时候，对用户需求的捕捉就会更准确，以后的变化就小，
我做北京公积金的时候，他们个贷处的人态度很不好，我们公司有一个从地方公积金系统出来的信息处长，介入项目后，个贷处没一个乱说了，要技术你不行，要业务你也不行，我们又把你们老大搞定，你们还敢说什莫！
用正规的开发方式rup等，需求分析师和系统设计很多时候是一个人（充分使用资源），但要注意需求阶段和设计阶段的角色转换，你想睡觉时老发愁着明天吃什莫，能睡的着吗？
二、 公司是行业新生力量，这个时候就要用极限编程的方式，建议抛弃每周40小时工作原则，用自己的努力和热情去打动客户，积累行业经验，你也只有这个。
我见过很多国内小公司做电子政务，都是先做项目，在签合同，难呀！试想只要甲方有良知，看着做好的项目和“饥饿“的乙方，能不签合同吗？
总之，客户花了钱看“病“，找个“生手“，他能给你好脸吗？他能不抓狂吗？换位思考很重要，不光销售，各个工种都要这样。
另外，斗胆建议熊兄，看看《麦肯希法则》，你哪些问题这本书说得很详细，其实咨询顾问的工作和需求分析师的差别不大，当然如果你把需求分析师定位于联络员，我就无话可说了。对工程师发火的时候，多考虑考虑自己都作了哪些？有哪些过失？舞龙——龙头一动累死龙尾，如果一个团队出现了对立，什莫方法也救不了这个项目了！
家园 感谢兄台的建议 我这就找这本书去,不过对兄台所说的敏捷编程或是极限开发的思想,我还是不太明白:主要通过开发人员的快速构建形成模型反复与用户交流?这主要依赖快速开发工具,主要适用于业务模型相对成型,架构成熟的系统。不知我理解得对否。
又：我把需求开发工程师的工作定义为两种：（1）捕捉用户需要，帮助用户形成系统设计人员所需的需求；（2）帮助用户管理需求变更和进行需求追踪，在需求上确保软件质量。
我是作甲方项目管理工作的，我的经历告诉我，与承建商工程师的关系基本上是要又斗争又团结。不过我们当然要注意采取措施保持对方开发队伍的稳定。不过我承认，这一点国内很多用户作得不好，特别是政府部门。
- 复 感谢兄台的建议
家园 客气，大家讨论讨论 那本书的名字写错了，应该是《麦肯锡方法》，主要说的是如何捕捉需求，在此过程中如何应对各种不利的情况，并给用户提供相应的解决方案等，我可以给你email一个。
如果业务模型相对成熟，客户需求变化肯定局限在一个小的范围，更多的应该是微调，不适合使用极限编程，极限编程不是利用快速开发工具，而是在软件生产整个过程中以沟通、简单、反馈和勇气为基础，象junit就是让用户针对具体的方法和类编写测试类并保留下来，需求变化修改程序后，马上运行测试类检验所做修改是否伤及到了其他无关类（软件系统很多都是相互关联），如果没有，说明你的程序现在是安全的，如果有错误，说明你所做的需求修改影响到了系统的其他部分，努努力找到错误，改过来，说明需求修改在系统上是可行的，可以大胆的进行下面工作了，改不过来，说明由于系统原因这个需求变更不能实现，什麽需求变化可不可行，与其从业务上空论，不如试试，就这麽简单。极限编程所有的原则、宗旨都是为了保证尽快的、直接的试一试，以不变应万变---拥抱需求。
当然好的方法和架构也被很多开发方法吸收，不仅是极限编程的专利。
另外，我觉得你对自己现在的角色可能不太明白，反而和承建商掐上了
，单位上一个大的信息系统，首先就是对业务流程的重组（ERP中常用，其实大的信息系统比ERP差多少呢？），可是这样做对内部的影响最大，会触及到各方的利益，太钢猛会得罪人，可是老确定不了需求，项目不能推进，老大对你就有看法，机遇和挑战并存，没有一定的政治手腕和权利，老弟日子不好过，我有一个朋友考察一个大型企业的信息系统，说人家做的真好，真是见到实用了，该企业CIO的权利很大，如遇到在信息化过程中不合作的人员，部长以下有就地免职的权利，部长有降职降薪的权利。我们原来做一个物流企业的信息化，要求工人用扫描仪对货物扫描，然后装箱打包，原来工人都是只打包，速度快，现在让大老粗照这样做，粗活不仅变成了细活，而且工作速度明显的降了下来，结果仓库的主管就找了很多理由，什麽工人不会，工人工资低，这样增加了工作量等，别的需求都定了，就这点事了一两个月也没搞定，最后我们的老板（大老板的父亲）组织大老板参加的一个会，会上那个仓库主管又那样说，大老板一句话：我养的不是傻子工人，就这麽定了。那个仓库主管也不吭气了，结果最后实施的不错。每次变革都会触及到一部分人的利益，只要对全局会产生更大的推动作用，就要坚持自己的主张并积极的想尽各种办法、调用各种资源去推进。我不知道你和开发商怎麽对立起来的，我觉得你们才是一条船上的蚂蚱。商人是利益的动物，即使在中国，再有关系，项目做不好，钱也不是那麽好拿的（我原来的公司就很有背景，项目做不好会给你机会，但是机会是有限的哦），项目做好了，你有了政绩，然后升官发财，同时承建商有了利润，多好的一个双盈。最大敌人是信息化过程中单位内的利益集团（如果你的项目不触及利益集团，你就偷着乐吧）
。你控制不了需求，你这个项目负责人当的不合格呀，把皮球踢给承建商（工程费用就那麽多，无休止的修改），没有明确的需求界限，项目到做最后会失控的，害人害己呀！如果承建商有实力有眼光的话，甚至于能够要求你们的老大把你给先换了。说到你定义的两类需求工程师，不是传令兵是什麽，一个是先头兵，一个是维护兵，在需求的确定中有什麽决断力，我常把用户的问题需求当做洪水猛兽，从需求、设计、实现、测试等是一系列的大坝，第一个需求一点水都不阻拦，要这个大坝何用（当然没有功劳有苦劳）。
含雄奇于淡远之中，有价值的需求就是必须解决的问题总是藏在大量的、无序的、平实的业务中间，你一下就能看见，你单位各部门的人就傻到家了，但是他们不傻，而且他们还会制造烟幕弹，可是在真正的行业专家面前这些伎俩无处可藏，千里马常有二伯乐不常有，同样，十几年经验的行业专家也不多，找行业专家多咨询咨询，其实好的承建商就不错，当然怎麽沟通就师你的事了，另外，用Rose做好各种需求，和用户沟通的结果记录下来（各种图表或文字），多确认多分析，找其中的逻辑关系，还是毛主席说的好：世上就怕认真二字。计算机出现之前，人们就在和需求打交道，没有什麽大不了的。
有些地方说的有点重了，包涵包涵
家园 再次感谢您的帮助 我的邮箱通过短信发给您。但我觉得您对我的意见理解有误。我并没有和承建商对立，也不建议这样做。但我认为用户的需求是不确定的，必须通过用户与承建商共同努力在一定时间内达成妥协，而承建商的工程师在获取用户需求时有趋于将系统设计简单化的偏好，用户有将系统设计趋于复杂的偏好，通过需求开发工程可以较有效的解决矛盾。
家园 侃几句 （1）开发一个新系统，尽管是用户订制的，但这是一个以前从未存在过的系统。任何人无法凭空想象该系统如何运作，如何实现以前从未实现的功能。因此没有人能够告诉开发人员这个系统的功能如何匹配系统建设目标。只有获得了一个实际的系统才能检验实际运行能否满意。而在实施过程中，用户的灵感总会被不断激发，产生新的愿望。有两种情形，其一是用户已经有一套行之有效的Process（业务流程？），虽然没有一个软件系统，但依样画葫芦，只不过是把手动的流程变成自动的流程，这种情形好办。其二是用户现有的流程很乱，更糟糕的是用户有不现实的期待，以为新的系统可以自动解决他们所有的问题。这种情况下，首先要教育用户，买更多的时间。其次要依赖对该行业的理解，设法先把业务流程定义好。当然，还可以买象SAP这样的软件包，直接把同行的业务流程抄过来。
（2）一个系统的使用肯定牵扯到用户群体中的很多人，每个人，每个部门都对系统有着自己的幻想，都希望维护自己的利益。而这些利益不一定重合为系统建设目标。因此需求调研有如盲人摸象，只能获得很多片面、破碎的信息。这些信息之间有矛盾，不可调和，只能妥协，但妥协只能带来各方面都不满意。妥协不是软件开发者的责任，软件开发的责任是尽可能早点发现矛盾所在，让用户老板自己决定。我个人的经验，在同一家公司内部，极少有不可调和的矛盾的，动动脑筋，很多时候都能双赢。
（3）对项目建设有决定权的领导有自己的看法，但这些看法只能通过下级人员反映给开发者。下级人员会塞入自己的意见。其次，系统的使用者不关心投入，只关心系统是否减轻自己的负担。因此最初的需求调研肯定获得了很多锦上添花的需求，而不是系统建设目标所必需的需要。这要看哪一级别的领导了，负责拍板的，最关心的是投入多少，收获多少。比较强势的领导，会事先收集使用的意见，制定一系列的指标，计划，算清楚成本利益之后，才开始软件开发，而且在开发的过程中，会确保不偏离原有的目标。
（4）开发者并不实际关心系统是否贴近用户需要。只是关心是否不被抓住把柄。承建商只关心预计开发成本是否压缩利润。这要看开发者是否特指程序员，在较大型的项目中确实可能这样，只是对着Spec（功能定义？）编码，在较小的项目里，Spec往往较为含糊不清，在这种情形下，程序员应该更频繁的和用户交流。无论如何，我总是鼓励程序员尽可能多点和用户交流，这样有助于提早发现问题所在。
至于开发商，把项目做好，有助于拿到下一个项目，用户总是有新的要求的。至于开发成本和利润，就要看合同是怎么签的了。
- 复 侃几句
家园 与您商榷 有两种情形，其一是用户已经有一套行之有效的Process（业务流程？），虽然没有一个软件系统，但依样画葫芦，只不过是把手动的流程变成自动的流程，这种情形好办。其二是用户现有的流程很乱，更糟糕的是用户有不现实的期待，以为新的系统可以自动解决他们所有的问题。这种情况下，首先要教育用户，买更多的时间。其次要依赖对该行业的理解，设法先把业务流程定义好。当然，还可以买象SAP这样的软件包，直接把同行的业务流程抄过来。既然是订制新系统，即或是改造旧系统，几乎可以肯定功能有变化，不太可能全面照搬旧的流程。事实上，很多问题都出在旧的流程不适应新技术。特别是由手工流程改为自动化流程时，如果要求新系统适应旧的思想观念，将导致系统建设事倍功半。当然，改造用户思想很难，但必须有这个意识。
妥协不是软件开发者的责任，软件开发的责任是尽可能早点发现矛盾所在，让用户老板自己决定。我个人的经验，在同一家公司内部，极少有不可调和的矛盾的，动动脑筋，很多时候都能双赢妥协不是软件开发者的责任，但是开发者需要提供解决矛盾的方案，如果总把问题推给用户，最后结果是承建商出局。
其次我所说的矛盾是指用户很多部门试图通过新系统的引入改变部门在组织中的地位，或是改变分工方式，这种矛盾是很难调和的，对于承建商的需求开发部门而言，这是陷阱，很容易导致项目死亡，必须识别出陷阱，提出技术解决意见，依靠用户的上级最终解决。很微妙，但必须会做。
（4）开发者并不实际关心系统是否贴近用户需要。只是关心是否不被抓住把柄。承建商只关心预计开发成本是否压缩利润。[ｃｃhｅre.com 西西河 懒厨]
这要看开发者是否特指程序员，在较大型的项目中确实可能这样，只是对着Spec（功能定义？）编码，在较小的项目里，Spec往往较为含糊不清，在这种情形下，程序员应该更频繁的和用户交流。无论如何，我总是鼓励程序员尽可能多点和用户交流，这样有助于提早发现问题所在。
至于开发商，把项目做好，有助于拿到下一个项目，用户总是有新的要求的。至于开发成本和利润，就要看合同是怎么签的了。
开发者，不止是程序员，还包括系统分析师、设计师，都并不关心系统是否真正贴近用户需要，关心的是系统设计是否符合提交给用户的需求文档（这当然是乙方按乙方的需求作的，骗甲方签字而已），在此基础上，希望系统尽可能简单，尽可能可以照抄以前的设计。这是客观现实。
我主张将设计开发者与用户隔离开，通过需求开发人员进行交流，而不是让开发者直接与用户见面。理由如下：
（1）开发者会尽量选择简单的方案说服某个不懂行的用户，然后说这是用户同意的，但这不一定符合用户组织的利益。
（2）让开发者在绞尽脑汁设计、编写系统的同时费很多心思捉摸用户的政治意图和组织结构是不人道的。尽管在很多人看来开发者已接近牲畜。
（3）系统设计开发者与需求开发者虽然同属乙方，但由于在组织上分离，需求开发者会在一定程度上代表用户利益，监督系统设计开发者。同时需求开发的有特殊的业务知识和技术知识、人生经验要求，从人力资源使用上也应该单独分出来。
（4）分离还可以保护系统开发者，当用户不满意系统建设情况，我们可以调离需求开发者而不影响系统进度，满足用户的面子要求。而不使系统建设实际受损。有谁愿意接手一个用户不满意、没有利润的半截工程？
- 复 与您商榷
家园 关于是否让设计人员参与需求，说说我的体会 我的体会是，让负责整体设计的人（一般中、小项目就一个人）参与需求有很大帮助。
原因有几方面。一个就是交流。多转一道总会少些东西。而且不同职责的人对不同信息的理解和敏感度都不一样。总负责的人如果能了解原始需求，能使设计尽可能合理。
还有一点就是时延。负责设计的人不用等做需求的人写好文档才开始工作，在比较早的时候就可以做出系统结构的设计。这对于在项目早期有一个比较合理、自己心里有底的估计和计划是非常有必要的。
家园 您说得是通行的做法 但我认为正是由于负责系统设计的人作需求，当需求变更时，特别是反复变更时容易挫伤积极性，容易发生与用户的争执，如果导致设计人员被迫调离，系统建设肯定受到重大延误。
其次，由于设计人员直接面对用户，很多交流直接面对面进行，经常出现文档不及时，而用户在谈需求时经常是片断的、支离破碎的，甚至相互矛盾。久而久之，很多需求可能被淹没，需求的本意被忘却。
我建议将需求开发与系统设计实现分开，实际上是企图强制建立通过文档交流的机制，确保文档的有效性。其次是系统设计人员的知识构成主要偏技术类的。只有少数人具有足够的耐心和沟通技巧胜任与用户周旋，而需求开发人员更侧重于从技术角度理解用户业务，经过他们的翻译，设计人员更容易理解用户的需求。我个人以为这样未必降低效率，甚至可能提高效率。再次，通过组建专门的需求开发组，在组织上可以监督系统设计贴近用户最终需求，也可以控制用户需求变更的规模和频度。最后还可以保护系统设计人员，在需求开发人员和用户吵翻之后，我们可以调走需求开发人员，让系统设计人员再顶上来。
由于我目前主要是作甲方的项目管理工作，所以对于以上建议我确实没有实践经验，希望兄台和河里诸高人多指教
