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

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

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

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

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

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

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

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

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