我们这些在2013年生活在美国的人可能还记得医疗保健.政府, 一个新的(在当时), 有争议的健康保险在线市场, 是由美国政府发起并坠毁的 两小时内. 随后的一项研究 政府问责局 found that the website had been developed “without effective planning” and that “key technical requirements were unknown.“用户需求也被严重低估了. 从本质上讲，站点的许多失败都是由于糟糕的产品需求计划.
Requirements gathering is a crucial part of product development—and it’s also the stage at which product leaders often go wrong. Numerous studies point to ineffective requirements gathering as a source of major issues for developer productivity. 在一个 2022年广泛调查 CodinGame和Coderpad, 例如, 软件开发人员面临的主要挑战是“返工”, 变化, 计划外的工作, 计划外的问题”和“方向不明确”.” These challenges can be mitigated by implementing a robust requirements gathering process.
作为一个资深的项目，项目和 产品经理, I’ve witnessed a broad range of attitudes toward requirements gathering by companies and teams, 其中一些最终导致了资源的浪费, 范围蠕变, 失望的客户, 以及表现不佳的产品. 在本文中, I’ll unpack a few of these mistakes and identify key learnings so that you can avoid making these same errors.
One of the key challenges at any stage of the development process is 不 letting inherent biases influence our work. 这就是健壮的、客观的需求收集过程至关重要的原因.
著名项目管理专家Bent Flyvbjerg的研究表明 几种常见的偏见 这在项目管理中经常出现. 根据我的经验，这些偏见也会影响 产品开发的早期阶段. 这些是你应该注意的:
偏见 | 表现 |
|---|---|
战略误传 | 倾向于 deliberately and systematically distort or misstate information for strategic purposes (also known as political bias, 战略偏差, 或权力偏见) |
乐观偏见 | 对计划好的行动的结果过于乐观的倾向, 包括高估积极事件的频率和规模, 以及低估负面事件发生的频率和规模 |
独特性的偏见 | 倾向于认为你的项目比实际情况更单一 |
计划谬误 | 倾向于 低估了成本，进度和风险，高估收益和机会 |
过度自信的偏见 | 对自己对问题的回答过于自信 |
后见之明偏见 | 认为过去的事件在事件发生的时候是可以预测的 |
可获得性偏差 | 倾向于 overestimate the likelihood of events with greater ease of retrieval (availability) in memory |
基础概率谬误 | 倾向于 ignore generic base-rate information and focus on specific information pertaining to a certain case or small sample |
锚定 | 倾向于 rely too heavily on one trait or piece of information when making decisions, 通常是在相关主题上获得的第一条信息 |
承诺升级 | 为一项决策增加投资辩护的倾向, 基于累积的前期投资, despite new evidence suggesting the decision may be wrong; also known as the sunk-cost fallacy |
每个公司和产品的需求收集过程看起来都不一样, 你可以采取几种方法来取得成功. 而不是谈论什么 to 描述常见的错误是否更有效 负 对产品结果的影响. 以下是在需求收集过程中需要避免的五大错误:
几年前，我在一个处理公司内部网门户升级的团队中. 客户的目标很简单:设计一个新的门户 不 类似于之前失败的产品. (The company had recently tried to update the portal but the final solution had been rejected by the end users.)乍一看，“不像X”似乎是一个很好的要求. 但该团队的反应是专注于视觉效果, 保留相同的功能，并以新的颜色和品牌重新发布产品. 当然, this product encountered the same issues as the previous one because its 特性 and functionality remained largely unchanged. The problem wasn’t the color or branding—it was that the product requirements had 不 been redefined.
一家中型公司看到竞争对手利用了市场上的一个机会, 它也想参与进来. 进入市场的速度至关重要，因此没有时间来收集需求. 相反，团队只是简单地复制竞争对手的产品功能. The customer’s response is: “Where are the support 特性 in this product that we value in your other products?” and “How does this product integrate with the other products we have already purchased from you?” The lack of a coherent answer to these questions results in a frustrated product team and unsatisfied customers.
I was once on a team at a new company that had built a product with amazing 特性 that outperformed the competition. Unfortunately, the team forgot one vital element in the requirements gathering process: the customer. 事实上, 他们害怕与他们接触, 对负面反馈保持警惕, 并且担心产品市场不适合被暴露出来. 因此，他们开发的产品需求集缺乏重要的客户输入.
作为产品经理，我们必须是我们的专家 客户需求. If the services your company provides are B2B, you must even understand your customers’ customers. 成功就是顾客想要他们得到的东西. 为了知道你的客户想要什么, 你可以分析报告, 读文章, 参加会议——但要获得最清晰的见解, 你得问问他们想要什么.
我自己也经历了惨痛的教训. 在一个项目上, we had engaged with customers and other stakeholders and developed a list of product requirements. However, when it was time for me to create user stories, I didn’t confirm each one with the customer. I thought they wouldn’t care about a back-end logging feature or a minor Kubernetes infrastructure node configuration change—basically, 任何不是基于UI或ux的东西. 但我错了. One specific customer was obsessed with all the 特性 in our product and wanted to know about every layer of its functionality, 甚至对有用的功能有了新的想法.
Recently, I was on a team at a large IT services company delivering a customer engagement product. 产品范围是一个顾问小组将访问客户的站点, 部署我们的专有软件分析产品, 并分析客户网络的云连接问题和机会. 服务交付后，将向客户发送一份报告. 这是一个简单的瀑布式产品交付，有固定的交付物， 时机，以及成本. 现场交货几小时后, the customer found other network issues that did 不 involve the technology we had agreed to scan. “让我们成为 敏捷,他们说, 并要求我们更换产品来分析打印机, 防火墙, 客户端连接问题. The product requirements had already been agreed upon, however, and we needed to 防止范围蠕变. 我们选择交付当前的产品, 然后接受新的客户请求，并将其用作未来版本的需求.
需求收集是项目开发的一个重要阶段 任何产品的开发 不应该被忽视. 一个产品的基础不可能是你不希望它成为的, 它也不应该仅仅是市场上已有产品的复制. 与您的创新者和早期采用者的客户群接触，以获得他们有价值的见解, and don’t be afraid of asking questions to ensure you’re 不 wasting time building unnecessary 特性. 知道何时确定需求并继续前进，或者使用 瀑布式方法 交付. Implement these lessons for requirements gathering at the outset of your 项目s for productive teams, 快乐的客户, 以及成功的结果.
产品 requirements gathering is the process of identifying and documenting the needs and specifications of a product, 包括所需的功能, 特性, 和约束. 它包括研究、整理信息和确定需求的优先级.
产品 requirements gathering is a crucial phase that sets the foundation for successful product design and implementation. 目标是确保全面理解产品应该实现什么. 这有助于减少误解, 防止范围蠕变, 并确保产品满足客户需求.
Best practices for requirements gathering include defining a product by what it should be (不 what it shouldn’t), 原创而不是抄袭竞争对手, 与客户互动, 确保所有功能都是必要的, 并且知道何时确定需求并继续交付.
İ世界、土耳其
自2021年4月29日起成为会员
迈克尔是一个经验丰富的节目主持人, 项目, 并对大型产品经理有深入的了解, 全球IT解决方案. 他曾在微软担任多个职位, 包括高级构建产品经理和高级项目经理. Michael拥有网络安全硕士学位, and also has a professional degree from the General Management Program at Harvard Business School.
以前在
世界级的文章，每周发一次.
世界级的文章，每周发一次.
