新闻中心 
如何理解软件开发过程中客户需求的问题-领汇认证中心
2021-06-04
浏览次数：次
返回列表从有软件产品开始，几十年来软件需求一直困扰着我们。而且我们总有做不好的借口：市场和产品部做的不好；客户不配合；需求总在变化等。敏捷引入了跨职能团队，并一再强调要倾听客户的声音，以为这样就能解决需求问题，可结果还是令人失望。
许多人的软件工程假设中有这么一条：通过努力和客户沟通他们的真正需求，我们可以在项目前期开发出合理的软件需求。这个假设主导了许多组织的软件需求过程，导致了不少软件项目没能实现其经济目标。
客户说要个不重易带的箱子，我们以为理解了他们的要求，并据此设计出引以为豪的式样，可客户却既不买账也不买单，从竞争对手那买了个很重的箱子，因为那个箱子下面带着轮子。
搞错了，没理解我要箱子的目的
这个解决了我的问题
这个假设的硬伤有三：客户在一段时间内不一定知道他们要什么；即使知道，也不能描述清楚；即使貌似能描述，他们往往给出的是一个解决方案，而非真正的需求。稍微复杂的软件项目都会有多个客户的声音，软件需求需要平衡众多干系人的需要，还要考虑用户讲不明白的非功能需求。在开始设计前，我们大概很难梳理出准确的软件需求，所以再好的软件需求规格说明书也会存在严重问题，这些问题的后果随着时间的推移会成倍加重。
客户声音有噪音
是时候改变我们的软件需求思维了，不要再假设从客户听到的都是靠谱准确的信息了，而是把它们看作是充满噪音，需要不断验证调整的信息。这样看来，在项目前期投入大量资源开发出“完美”的需求就不那么明智了。新的假设需要一个匹配的过程和支持体系，团队可以快速识别、纠正解决方案和不断进化的客户需求的不一致之处。
也许这就是你敏捷转型的目的。
本文转载自公众号：老丛讲桌
京公网安备 11011502006429号 领汇认证中心，让认证成为一件简单的事！
