本文探讨了项目实施过程中遇到的问题，特别是用户需求与实际操作之间的矛盾。作者指出，项目需求文档明确了系统的预期行为，但用户未能遵循这些规定，导致了一系列误解。文章呼吁重视需求规格的重要性，并强调了需求变更管理和用户培训的必要性。
前段时间刚结束了一个项目，结果提交给用户后，用户在实际应用中遇到了许多所谓的“问题”，反馈回来给我们后，原来不是程序的Bug，而是用户没有根本没有根据当初他们给我们的需求规格操作，所以在用户交互的接口处就被涮了下来，为此他们总天抱怨说程序如何如何不好用……
我真的不明白，这样的项目实施下去有没有什么意义？有人指责说我们项目组如何如何开发出一个不符合用户需求的系统，我心里真的觉得冤啊，项目需求文档，白纸黑字把需求规格写得清清楚楚，现在用户不按照当初给我们的需求规格来操作，还想要求系统能够做出正确的回应？我想这样的项目很难做下去的……需求规格应该就像是一份合同、一份契约一样，是供应方和消费方共同遵守的约定，一方遵守，一方却不遵守，却要求系统按照双方都遵守的情景去运行，我想现在的程序还没有这样的逻辑能力吧？
用户需求、需求文档、需求规格，如何更好地为项目服务？项目需求会不断地变化，因此需求规格也有可能随之变化，但是需求变化了，一般都要求有需求变更，如果没有做需求变更，则要求系统能按新的需求规格运行，那还真不如叫公鸡下蛋呢……
这样的项目要怎样做下去呢？
扫一扫
1万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
