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

应该是一种软件工程的方法论，涵盖各个阶段的（个人理解，不太肯定）。 JAD Session一般只应用于需求分析阶段，从JAD得出的结果就可以用来准备use case。

回去翻翻Agile手册去，也没准偶们就是从JAD开始做的，只是不知道名字哈

我的体会是，让负责整体设计的人（一般中、小项目就一个人）参与需求有很大帮助。

原因有几方面。一个就是交流。多转一道总会少些东西。而且不同职责的人对不同信息的理解和敏感度都不一样。总负责的人如果能了解原始需求，能使设计尽可能合理。

还有一点就是时延。负责设计的人不用等做需求的人写好文档才开始工作，在比较早的时候就可以做出系统结构的设计。这对于在项目早期有一个比较合理、自己心里有底的估计和计划是非常有必要的。

但我认为正是由于负责系统设计的人作需求，当需求变更时，特别是反复变更时容易挫伤积极性，容易发生与用户的争执，如果导致设计人员被迫调离，系统建设肯定受到重大延误。

其次，由于设计人员直接面对用户，很多交流直接面对面进行，经常出现文档不及时，而用户在谈需求时经常是片断的、支离破碎的，甚至相互矛盾。久而久之，很多需求可能被淹没，需求的本意被忘却。

我建议将需求开发与系统设计实现分开，实际上是企图强制建立通过文档交流的机制，确保文档的有效性。其次是系统设计人员的知识构成主要偏技术类的。只有少数人具有足够的耐心和沟通技巧胜任与用户周旋，而需求开发人员更侧重于从技术角度理解用户业务，经过他们的翻译，设计人员更容易理解用户的需求。我个人以为这样未必降低效率，甚至可能提高效率。再次，通过组建专门的需求开发组，在组织上可以监督系统设计贴近用户最终需求，也可以控制用户需求变更的规模和频度。最后还可以保护系统设计人员，在需求开发人员和用户吵翻之后，我们可以调走需求开发人员，让系统设计人员再顶上来。

由于我目前主要是作甲方的项目管理工作，所以对于以上建议我确实没有实践经验，希望兄台和河里诸高人多指教

那是得考虑保护干活的人。我们这情况不太一样，相对安全些。

再解释两句。我说让设计人员（主要负责人，一般是一个）参加需求，并不是要让他承担主要的需求工作，更不是替代需求分析的人。做需求的还是做需求。设计人员的角色更多的是旁听和观察（observer），也不要求参与所有的客户会议。

可能还有个好处就，多一个人，吵架就会少一些。不知道有没有这个作用

您的意见很好，不过我仍有疑问，如果用户要求直接与设计人员谈怎么办？不管与谁谈？谁负责记录、整理会谈文档？

我在美国做软件。项目里也有让人头痛的地方。

因为客户一开始就可以和负责技术的人交流，所以没有遇到要和其他开发设计人员直接谈的情况。在我们这，项目经理和需求分析的人是和客户交流最多的。设计人员不会单独和客户见面，我觉得一般情况下是不允许的。

我觉得一开始就要和用户说明，这是我们的系统设计师，如果您在技术上有疑问可以和他交流。我们一般是要给客户提交设计文档的，特别是系统构架文档。其他的开发人员，很多情况下客户的面都不见的。

我这就找这本书去,不过对兄台所说的敏捷编程或是极限开发的思想,我还是不太明白:主要通过开发人员的快速构建形成模型反复与用户交流?这主要依赖快速开发工具,主要适用于业务模型相对成型,架构成熟的系统。不知我理解得对否。

又：我把需求开发工程师的工作定义为两种：（1）捕捉用户需要，帮助用户形成系统设计人员所需的需求；（2）帮助用户管理需求变更和进行需求追踪，在需求上确保软件质量。

我是作甲方项目管理工作的，我的经历告诉我，与承建商工程师的关系基本上是要又斗争又团结。不过我们当然要注意采取措施保持对方开发队伍的稳定。不过我承认，这一点国内很多用户作得不好，特别是政府部门。

甲乙双方的互信不是一朝一夕可以建立起来的，但也不是完全没有办法，话题太大，改日再细谈。

我也是倾向于善待开发人员，因为这样他们的工作效率最高，您说的条件，我猜是如何让他们不偏移开发目标吧。

那本书的名字写错了，应该是《麦肯锡方法》，主要说的是如何捕捉需求，在此过程中如何应对各种不利的情况，并给用户提供相应的解决方案等，我可以给你email一个。

如果业务模型相对成熟，客户需求变化肯定局限在一个小的范围，更多的应该是微调，不适合使用极限编程，极限编程不是利用快速开发工具，而是在软件生产整个过程中以沟通、简单、反馈和勇气为基础，象junit就是让用户针对具体的方法和类编写测试类并保留下来，需求变化修改程序后，马上运行测试类检验所做修改是否伤及到了其他无关类（软件系统很多都是相互关联），如果没有，说明你的程序现在是安全的，如果有错误，说明你所做的需求修改影响到了系统的其他部分，努努力找到错误，改过来，说明需求修改在系统上是可行的，可以大胆的进行下面工作了，改不过来，说明由于系统原因这个需求变更不能实现，什麽需求变化可不可行，与其从业务上空论，不如试试，就这麽简单。极限编程所有的原则、宗旨都是为了保证尽快的、直接的试一试，以不变应万变---拥抱需求。

当然好的方法和架构也被很多开发方法吸收，不仅是极限编程的专利。

另外，我觉得你对自己现在的角色可能不太明白，反而和承建商掐上了，单位上一个大的信息系统，首先就是对业务流程的重组（ERP中常用，其实大的信息系统比ERP差多少呢？），可是这样做对内部的影响最大，会触及到各方的利益，太钢猛会得罪人，可是老确定不了需求，项目不能推进，老大对你就有看法，机遇和挑战并存，没有一定的政治手腕和权利，老弟日子不好过，我有一个朋友考察一个大型企业的信息系统，说人家做的真好，真是见到实用了，该企业CIO的权利很大，如遇到在信息化过程中不合作的人员，部长以下有就地免职的权利，部长有降职降薪的权利。我们原来做一个物流企业的信息化，要求工人用扫描仪对货物扫描，然后装箱打包，原来工人都是只打包，速度快，现在让大老粗照这样做，粗活不仅变成了细活，而且工作速度明显的降了下来，结果仓库的主管就找了很多理由，什麽工人不会，工人工资低，这样增加了工作量等，别的需求都定了，就这点事了一两个月也没搞定，最后我们的老板（大老板的父亲）组织大老板参加的一个会，会上那个仓库主管又那样说，大老板一句话：我养的不是傻子工人，就这麽定了。那个仓库主管也不吭气了，结果最后实施的不错。每次变革都会触及到一部分人的利益，只要对全局会产生更大的推动作用，就要坚持自己的主张并积极的想尽各种办法、调用各种资源去推进。

我不知道你和开发商怎麽对立起来的，我觉得你们才是一条船上的蚂蚱。商人是利益的动物，即使在中国，再有关系，项目做不好，钱也不是那麽好拿的（我原来的公司就很有背景，项目做不好会给你机会，但是机会是有限的哦），项目做好了，你有了政绩，然后升官发财，同时承建商有了利润，多好的一个双盈。最大敌人是信息化过程中单位内的利益集团（如果你的项目不触及利益集团，你就偷着乐吧）。你控制不了需求，你这个项目负责人当的不合格呀，把皮球踢给承建商（工程费用就那麽多，无休止的修改），没有明确的需求界限，项目到做最后会失控的，害人害己呀！如果承建商有实力有眼光的话，甚至于能够要求你们的老大把你给先换了。

说到你定义的两类需求工程师，不是传令兵是什麽，一个是先头兵，一个是维护兵，在需求的确定中有什麽决断力，我常把用户的问题需求当做洪水猛兽，从需求、设计、实现、测试等是一系列的大坝，第一个需求一点水都不阻拦，要这个大坝何用（当然没有功劳有苦劳）。

含雄奇于淡远之中，有价值的需求就是必须解决的问题总是藏在大量的、无序的、平实的业务中间，你一下就能看见，你单位各部门的人就傻到家了，但是他们不傻，而且他们还会制造烟幕弹，可是在真正的行业专家面前这些伎俩无处可藏，千里马常有二伯乐不常有，同样，十几年经验的行业专家也不多，找行业专家多咨询咨询，其实好的承建商就不错，当然怎麽沟通就师你的事了，另外，用Rose做好各种需求，和用户沟通的结果记录下来（各种图表或文字），多确认多分析，找其中的逻辑关系，还是毛主席说的好：世上就怕认真二字。计算机出现之前，人们就在和需求打交道，没有什麽大不了的。

有些地方说的有点重了，包涵包涵

我的邮箱通过短信发给您。但我觉得您对我的意见理解有误。我并没有和承建商对立，也不建议这样做。但我认为用户的需求是不确定的，必须通过用户与承建商共同努力在一定时间内达成妥协，而承建商的工程师在获取用户需求时有趋于将系统设计简单化的偏好，用户有将系统设计趋于复杂的偏好，通过需求开发工程可以较有效的解决矛盾。