我们这些在2013年生活在美国的人可能还记得医疗保健.政府, 一个新的(在当时), 有争议的健康保险在线市场, 是由美国政府发起并坠毁的 两小时内. 随后的一项研究 政府问责局 发现该网站的开发“没有有效的规划”，“关键技术要求未知”.“用户需求也被严重低估了. 从本质上讲，站点的许多失败都是由于糟糕的产品需求计划.
需求收集是产品开发的关键部分，也是产品负责人经常出错的阶段. 许多研究指出，无效的需求收集是开发人员生产力主要问题的来源. 在一个 2022年广泛调查 CodinGame和Coderpad, 例如, 软件开发人员面临的主要挑战是“返工”, 变化, 计划外的工作, 计划外的问题”和“方向不明确”.这些挑战可以通过实现一个健壮的需求收集过程来缓解.
作为一个资深的项目，项目和 产品经理, 我目睹了公司和团队对需求收集的广泛态度, 其中一些最终导致了资源的浪费, 范围蠕变, 失望的客户, 以及表现不佳的产品. 在本文中, 我将分析其中的一些错误，并指出关键的教训，以便您可以避免犯同样的错误.
在开发过程的任何阶段，一个关键的挑战是不要让固有的偏见影响我们的工作. 这就是健壮的、客观的需求收集过程至关重要的原因.
著名项目管理专家Bent Flyvbjerg的研究表明 几种常见的偏见 这在项目管理中经常出现. 根据我的经验，这些偏见也会影响 产品开发的早期阶段. 这些是你应该注意的:
偏见 | 表现 |
|---|---|
战略误传 | 为了战略目的而故意和系统地歪曲或错误陈述信息的倾向(也称为政治偏见), 战略偏差, 或权力偏见) |
乐观偏见 | 对计划好的行动的结果过于乐观的倾向, 包括高估积极事件的频率和规模, 以及低估负面事件发生的频率和规模 |
独特性的偏见 | 倾向于认为你的项目比实际情况更单一 |
计划谬误 | 倾向于 低估了成本，进度和风险，高估收益和机会 |
过度自信的偏见 | 对自己对问题的回答过于自信 |
后见之明偏见 | 认为过去的事件在事件发生的时候是可以预测的 |
可获得性偏差 | 倾向于高估在内存中更容易检索(可用性)的事件的可能性 |
基础概率谬误 | 倾向于忽略一般的基本率信息，而把重点放在与某个案例或小样本有关的特定信息上 |
锚定 | 在做决定时过于依赖某一特征或信息的倾向, 通常是在相关主题上获得的第一条信息 |
承诺升级 | 为一项决策增加投资辩护的倾向, 基于累积的前期投资, despite new evidence suggesting the decision may be wrong; also known as the sunk-cost fallacy |
每个公司和产品的需求收集过程看起来都不一样, 你可以采取几种方法来取得成功. 而不是谈论什么 to 描述常见的错误是否更有效 负 对产品结果的影响. 以下是在需求收集过程中需要避免的五大错误:
几年前，我在一个处理公司内部网门户升级的团队中. 客户的目标很简单:设计一个新的门户 不 类似于之前失败的产品. (该公司最近尝试更新门户，但最终解决方案被最终用户拒绝.)乍一看，“不像X”似乎是一个很好的要求. 但该团队的反应是专注于视觉效果, 保留相同的功能，并以新的颜色和品牌重新发布产品. 当然, 这个产品遇到了与上一个产品相同的问题，因为它的特性和功能基本上没有改变. 问题不在于颜色或品牌，而在于产品要求没有重新定义.
一家中型公司看到竞争对手利用了市场上的一个机会, 它也想参与进来. 进入市场的速度至关重要，因此没有时间来收集需求. 相反，团队只是简单地复制竞争对手的产品功能. 客户的回答是:“我们在你们的其他产品中看重的支持特性在这个产品中哪里??以及“这个产品如何与我们已经从你们那里购买的其他产品相结合??对这些问题缺乏连贯的答案会导致产品团队受挫，客户不满意.
我曾经在一家新公司的一个团队中工作，他们开发了一款具有惊人功能的产品，在竞争中脱颖而出. 不幸的是，团队忘记了需求收集过程中的一个重要元素:客户. 事实上, 他们害怕与他们接触, 对负面反馈保持警惕, 并且担心产品市场不适合被暴露出来. 因此，他们开发的产品需求集缺乏重要的客户输入.
作为产品经理，我们必须是我们的专家 客户需求. 如果你的公司提供的服务是B2B的，你甚至必须了解你的客户的客户. 成功就是顾客想要他们得到的东西. 为了知道你的客户想要什么, 你可以分析报告, 读文章, 参加会议——但要获得最清晰的见解, 你得问问他们想要什么.
我自己也经历了惨痛的教训. 在一个项目上, 我们与客户和其他利益相关者进行了接触，并制定了产品需求清单. 然而，当我需要创建用户故事时，我并没有与客户确认每一个用户故事. 我认为他们不会关心后端日志功能或Kubernetes基础设施节点配置的小变化, 任何不是基于UI或ux的东西. 但我错了. 有一个客户对我们产品的所有功能都很着迷，他想了解产品的每一层功能, 甚至对有用的功能有了新的想法.
最近，我在一家大型IT服务公司的一个团队中交付一个客户参与产品. 产品范围是一个顾问小组将访问客户的站点, 部署我们的专有软件分析产品, 并分析客户网络的云连接问题和机会. 服务交付后，将向客户发送一份报告. 这是一个简单的瀑布式产品交付，有固定的交付物， 时机，以及成本. 现场交货几小时后, 客户发现了其他不涉及我们同意扫描的技术的网络问题. “让我们成为 敏捷,他们说, 并要求我们更换产品来分析打印机, 防火墙, 客户端连接问题. 然而，产品需求已经达成一致，我们需要防止范围蔓延. 我们选择交付当前的产品, 然后接受新的客户请求，并将其用作未来版本的需求.
需求收集是项目开发的一个重要阶段 任何产品的开发 不应该被忽视. 一个产品的基础不可能是你不希望它成为的, 它也不应该仅仅是市场上已有产品的复制. 与您的创新者和早期采用者的客户群接触，以获得他们有价值的见解, 不要害怕问问题，以确保你没有浪费时间构建不必要的功能. 知道何时确定需求并继续前进，或者使用 瀑布式方法 交付. 在项目开始时为富有成效的团队实现这些经验教训, 快乐的客户, 以及成功的结果.
产品需求收集是识别和记录产品需求和规格的过程, 包括所需的功能, 特性, 和约束. 它包括研究、整理信息和确定需求的优先级.
产品需求收集是为成功的产品设计和实现奠定基础的关键阶段. 目标是确保全面理解产品应该实现什么. 这有助于减少误解, 防止范围蠕变, 并确保产品满足客户需求.
需求收集的最佳实践包括定义产品应该是什么(而不是不应该是什么), 原创而不是抄袭竞争对手, 与客户互动, 确保所有功能都是必要的, 并且知道何时确定需求并继续交付.
世界级的文章，每周发一次.
世界级的文章，每周发一次.
作者都是各自领域经过审查的专家，并撰写他们有经验的主题. 我们所有的内容都经过同行评审，并由同一领域的Toptal专家验证.