- == 系统问题，暂停聊天功能。==
- 【征集】西西河的经济学，及清流措施，需要主动参与者，『稷下学宫』新认证方式，24年网站打算和努力目标
主题：【原创】软件开发项目中的需求开发问题 -- 闲云野熊
家园 也不是什么仙境 我在美国做软件。项目里也有让人头痛的地方。
因为客户一开始就可以和负责技术的人交流，所以没有遇到要和其他开发设计人员直接谈的情况。在我们这，项目经理和需求分析的人是和客户交流最多的。设计人员不会单独和客户见面，我觉得一般情况下是不允许的。
我觉得一开始就要和用户说明，这是我们的系统设计师，如果您在技术上有疑问可以和他交流。我们一般是要给客户提交设计文档的，特别是系统构架文档。其他的开发人员，很多情况下客户的面都不见的。
- 复 与您商榷
家园 接着侃 熊兄客气了，和兄台对侃其实挺有趣的。
既然是订制新系统，即或是改造旧系统，几乎可以肯定功能有变化，不太可能全面照搬旧的流程。事实上，很多问题都出在旧的流程不适应新技术。特别是由手工流程改为自动化流程时，如果要求新系统适应旧的思想观念，将导致系统建设事倍功半。当然，改造用户思想很难，但必须有这个意识。确实如此，一般来说，区别在于大改还是小改。
妥协不是软件开发者的责任，但是开发者需要提供解决矛盾的方案，如果总把问题推给用户，最后结果是承建商出局。其次我所说的矛盾是指用户很多部门试图通过新系统的引入改变部门在组织中的地位，或是改变分工方式，这种矛盾是很难调和的，对于承建商的需求开发部门而言，这是陷阱，很容易导致项目死亡，必须识别出陷阱，提出技术解决意见，依靠用户的上级最终解决。很微妙，但必须会做。
这话对极。良好的开发商就是要提供解决方案，而且不止一个，向用户阐释各个方案的利弊，最终的决定权还是在用户手里。不了解国内的软件开发状况，我个人的经验是尽可能对事不对人。倒不是很担心项目死亡，关键在于合同的条款，看看谁为项目死亡负责。
开发者，不止是程序员，还包括系统分析师、设计师，都并不关心系统是否真正贴近用户需要，这话实在不敢苟同。愚以为这样实在不是一个好的开发团队。小弟认为这大概就是与熊兄最大的分歧了。
熊兄或许认为软件开发能够象生产线的流程一样，但我认为，软件开发目前还属于初级阶段，太多东西没有办法标准化，流水线式的软件开发，还言之尚早。
- 复 接着侃
家园 我发现与您的共识还是有的 我基本同意您的关于软件开发管理作为一门科学还不很成熟的看法。
不过我还是不同意您所提到的开发人员会真正考虑用户的实际需要的看法。从主观上，开发人员对软件企业负责，而不是对用户负责，如果开发人员使开发成本超过所得，企业将面临困境，所以开发人员只能建立一个符合合同规定的系统。这也是我认为尽管瀑布模型被认为是一个缺陷的模型，但在大多数系统开发时还是被使用的原因。
当然合同不是全部，国内一般注重行业开发经验。进入一个领域非常难，因此，在打入一个新领域时几乎肯定是要赔本的。如果只考虑合同规定的维护，肯定不能满足用户需要，企业付出的代价是今后很难涉足这一行业了。
因此上述两个方面是矛盾的。这也是我建议将需求开发与系统设计分开的理由。
家园 呵呵，君子和而不同 从某种角度来看，开发团队交出一份让用户满意的产品，也是对软件企业负责，当然，所作所为必须在成本之内。
- 复 侃几句
家园 叫个好！
家园 给个好。谈一点看法 就象老熊所说，这个用户要求的征集，也会很繁琐。粗略地分，可以分成对已有系统的维护和新系统的创建。
对已有系统的维护相对比较简单。用户已经对于系统有一定的印象和经验，所以对于自己想要什么不想要什么，会有一个大概其的印象，而不至于满口跑火车。即使他想要加一些新功能，也会依照已有的系统来类比。对于作软件的也比较省事儿，估算时间成本时可以比照已有系统，八九不离十。这就象一辆跑车，车主要求车厂给追加个CD天窗ABS之类...
对于从无到有的新系统，这个方法就不适用了。因为用户没有印象，所以不能，也不应该指望用户在一开始就把所有要求全部提光，后来就一声不吭。就像阔佬托车厂给他造汽车，车厂当然不会上来就把车造出来再给用户，“看，这就是你要的汽车！”“什么？我没有要五个方轱辘呀？”得，又得重新造。
车厂（好像现在还不存在这种车厂，咱打比方哈）这种情况下应该排个设计师，跟客人边谈边画，画完给他看，“喏，这就是你要的车子”“嗯，屁股能不能小点，轮胎能不能再宽点儿... ” 就这样边谈边改，最终差不离的时候才算定稿，然后才交付车厂进行生产。这个Rapid Prototype(RP)方式在软件开发上即可用所谓快速开发，先把用户能看得见的东西给他拿出来，大家看着实物，边谈边改；不看着实物，光是空对空地讲，回头他经常会给你来个彻底不承认。RP可能会增加用户需求征集时间，但是在这里多花一个钟头后头能省好几个钟头。
对于老熊说的(2),非常有同感。这个要求从直接用户那里上来，一路上经过BA/BSA/TSD几道手，往往就面目全非。最好的是能找到最终用户，由最终用户来敲定而不是由他们的领导来提要求。领导们只关心这个“18摸”计算机挖地雷快不快啊？
对于系统接口的问题，咳，这个其实更多的是个政治问题了，公司政治，已经不是简单的技术问题了。有人能做不原意做，有人不能做却硬撑着要做... 这些都已经是软件工程之外的问题，属于“人际工程”...
家园 说得不错，看花！
家园 就这个问题，我觉得美国的路子很对。他们这里的模式是 Business drives IT,而不是像国内那样反过来。
资本家惜财如命，每上马一个项目都有它的目的。他的要求他很清楚。这是开发任何系统的基础。虽然在具体的开发过程中会有很多反复，很多修改，或者由于外界情况变化了导致整个项目停滞或是下马。但就根本而言，资本家花钱是前后斟酌过的，是有目的的。
有的项目很大，一是不可能把要求搞得很清楚，通常的做法就是分阶段实施。先交付一部分，然后根据用户反馈和当时的具体情况，决定下一步如何。
比较好的一个例子是Bank of America(美国银行?)的Online Banking系统。这个系统我从一开始就使用上了，这么多年看着它一步步的完善，一步步的改进。到现在，无论是功能，还是性能都非常得不错。不仅极大的便利的他的用户，提高了服务质量，并且极大提高了他们的工作效率，降低了用户支持成本。一个真正双赢的例子。