为什么客户总说“这不是我想要的”？

文章主旨：

作者认为，软件项目中出现“这不是我想要的”并非主要是技术能力问题，而是开发关注技术实现、客户关注业务结果之间的认知错位；因此应先对齐需求、固化流程，再动手开发，以减少返工并精准匹配业务预期。

关键要点：

• 客户与开发思维不同：执行者盯着技术实现，付费方盯着业务结果，双方从开局就不在同一认知维度。
• 客户需求像冰山：客户明确说出的功能诉求是表层需求，未说出口但仍需满足的业务规则、流程、通知、对账等是底层需求。
• “订单退款”案例说明：开发只做退款按钮和记录，客户实际需要状态区分、自动校验、违规拦截、财务同步、短信通知、部分/全额退款、操作日志等完整业务闭环。
• 真正的项目管理逻辑是“慢开局、快执行”：前期花时间梳理和对齐需求，后期才能高效开发、一次交付。
• 需求管理应形成闭环：拆解模糊需求入池、分层拆解并关联任务与测试、基线锁定范围与变更流程、迭代过程实时监控与标准化管控。

内容结构：

1. 引子与问题：

   需求前期已评审，但做到一半客户仍说“这不是我想要的”；追问时客户又给出“五彩斑斓的黑”等模糊描述。作者强调，首先不要怀疑自己的技术能力。

2. 核心矛盾分析：

   产品经理、项目经理直接对接客户，一线开发较少直面终端用户。客户侧重业务落地、使用体验；产品与开发团队聚焦功能落地、技术实现。客户不关心架构、代码量、自测次数，只关心功能能否解决业务痛点、适配工作流程、实现预期业务效果。

3. 案例分析：用户订单退款功能：

   开发理解为“做一个退款按钮，可提交退款申请，后台可查看记录，功能正常无报错”。客户实际需求包括：区分“未发货、已发货、已签收”三种状态及不同退款流程；自动校验用户余额、拦截违规退款；同步财务台账、推送短信通知；支持部分退款与全额退款；保留操作日志用于对账。开发只完成表层功能，未匹配底层业务诉求。

4. 需求认知模型：

   软件需求如冰山，表层是客户明确提出的功能诉求，底层是客户没有说出口但仍需满足的需求。很多客户自己也无法一次性说清全部需求。真正的软件项目管理逻辑是“慢开局、快执行”。

5. 需求管理与流程管控方法：
   1. 01 拆解模糊需求，录入需求池：

      “流程优化、体验升级、逻辑调整、更贴合业务”等模糊表述不能直接作为开发依据，需拆解后统一录入需求池，保证版本可追溯，从源头避免理解偏差。

   2. 02 分层拆解需求，打通需求—任务：

      将大需求拆解为多个可执行的小需求，并支持需求、任务、测试用例、Bug 全关联，避免只做功能实现却不理解业务目的。

   3. 03 锁定需求范围，固化变更流程：

      需求梳理完成后打基线，明确本次迭代的交付内容、验收标准、交付时间等，可由客户、产品、开发三方确认锁定。迭代周期内所有需求变更都要走变更流程，记录清晰可查。

   4. 04 迭代过程闭环，管控研发全流程：

      覆盖软件研发全流程，项目经理实时监控开发进度、工时消耗等，实现标准化闭环，让研发过程透明化，减少人为失误导致的返工。

6. 结尾建议：

   软件开发行业已经变化，代码写得好、技术够硬不是全部，流程同样重要。过硬技术只能保证“做得出来”，标准化需求管理和流程管控才能保证“做得对”。因此应先对齐需求，再固化流程，最后动手开发。

文章总结：

全文强调以需求对齐和流程管控降低无效返工，让每一次交付都更精准地匹配业务预期。