有效沟通：需求说清楚，IT不跑偏（轻科技）

作为甲方，我们经常遇到的一个问题是，如何把需求与乙方讲清楚，那种“五彩斑斓的黑”式描述显然不行，我们需要结构化的描述。什么结构？作者给出了一个需求三棱镜，问题层：你要解决的问题是什么，结果层：成功是什么样子，验收层：怎么知道做到了。 整本书读下来，我感觉这套工具绝不仅仅可以用在软件系统开发，任何我们想与对方沟通需求的场合都可以套用，只不过有时候可以适当简化，比如领导在布置工作，要讲清楚自己到底想要啥，怎么才叫做好了，比如需要告诉朋友如何帮忙办事。需求讲的清楚，后面执行才不会跑偏。马斯克说过，根本没有所谓的执行问题，只是需求没有讲精准。描述的颗粒度越细，执行效果越好。 具体来说，要先从问题描述出发，没有痛点就没有需求，这是明确我从哪里出发，然后要想明白要做成的最终模样是什么，最好能够场景化描述出来，也就是要有画面感，这是明确要到哪里去，最后要明确验收标准，给出相应量化指标，以数据来判断这个项目是成功还是失败。 作者也给出了需求三棱镜相应的工具。问题层，要讲清楚三个问题：一是现状是什么，要具体详细做事实描述，而不是一些类似“出餐慢、效率低”等主观判断，二是要明确问题的代价是什么，代价决定项目的价值，三是要找到问题的根因。 结果层，要进行场景化的描述，格式是：早上/下午/项目结束后的某天，[这个人]做了[一件具体的事]，和之前不同的是[具体的区别]。” 比如： “早上10:00，店长老张打开手机，屏幕上显示今天的午市预测：预计12:00-12:30会比平时多30%订单，因为附近有展会。系统给出了备菜建议。老张确认了建议，花了30秒。以前，他等到12:15发现订单涌进来才知道今天忙，然后临时加人，后厨还是堵了。” 验收层，要明确出具体的验收指标，可以从效率、成本、风险、机会四个维度给出指标，比如试运行3个月，真实离职案例中有60%以上在系统里提前出现了预警。 作者最后还很贴心的给出了模版，可以直接复制使用： 《［项目名称］》需求三棱镜 填写人：___________日期：___________ __________________________________________ 【问题层：我要解决什么问题】 现象：_________________________________ （谁、在什么时候、遇到了什么问题，出现多少次） 影响：_________________________________ （这个问题让谁付出了什么代价） 根因（假设）：__________________________ （你认为是什么机制导致了这个问题） __________________________________________ 【结果层：成功是什么样的】 成功场景：_____________________________ （某个具体的人，在成功后的某一天，做了什么） （不一样的事，具体到时间、地点、动作） __________________________________________ 【验收层：怎么知道做到了】 验收条件：_____________________________ （可量化的指标 + 时间范围 + 判断阈值） 价值估算（量级即可）：__________________ （现在的成本 vs 数字化后的改善量级） 不在本次范围内的事：___________________ （明确边界，防止范围蔓延） __________________________________________ 总结来说，核心就是三句话：为什么要做这件事（问题入手，why，使命）？做成什么样子（目标，愿景），不做什么（确定做事边界，聚焦资源）？如何判断做的好坏（价值观，量化指标）？至于谁来做（who），做什么（what），怎么做（how），在哪里做（where），这是对方需要考虑的问题，甲方要不断追问自己的问题，把别人的问题留给别人去思考。

数字化项目大多折戟，从来不是技术难题，而是需求沟通的错位。本书用“需求三棱镜”，把模糊想法拆解成可落地的精准表达，打通业务与IT协作壁垒，高效对齐共识、规避项目跑偏，职场协作必读干货。

其实我也认为，很多时候不是技术问题，是沟通问题。我们总是以为我们了解了对方的需求，对方也总是认为自己把他的需求讲清楚了。其实两者之间有一个天地之差，而作者用了需求三棱镜的模型很好，我要解决什么问题？成功了会怎么样？结，成功之后的结果又是怎么样的？怎么验收的？可量化。 这想法都很好，在IT行业特定的情景下也能做得更好。但是在不特定的情况下，我们如何利用需求三棱镜把它做得更好呢？又是一个新的课题。

三棱镜需求： 【问题层：我要解决什么问题】 ①现象（需求）：：谁、在什么时候、遇到了什么问题，出现多少次 ②影响：这个问题让谁付出了什么代价） ③根因（假设）：你认为是什么机制导致了这个问题 完整的用用户故事和场景描述法，描述整个事情的全貌（做出动作者和被影响者），并给出你的结论！ 【结果层：成功是什么样的】成功场景：某个具体的人，在成功后的某一天，做了什么）（不一样的事，具体到时间、地点、动作） 你期望的结果样子（谁，地点，动作 【验收层：怎么知道做到了】 ①验收条件：可量化的指标 + 时间范围 + 判断阈值） ②价值估算（量级即可）：现在的成本 vs 数字化后的改善量级 ③不在本次范围内的事：明确边界，防止范围蔓延 具体可量化的条件，价值估计，说清楚范围

好书好书，短小精悍！这本书不仅讲透了如何提出/理解软件需求，更可贵的是，它的思维框架完全可以迁移到各类任务场景中。 无论你是甲方提出需求，还是乙方承接需求，只需厘清三个核心问题： 1. 问题层：当前用户的核心痛点是什么？它带来了怎样的影响？背后的根本原因又是什么？ 2. 结果层：软件上线前后，某个具体角色的工作场景发生了怎样的实质变化？ 3. 验收层：有哪些可量化的指标来评判软件是否成功？最好还能设定阶段性节点，避免一路走到最后才惊觉方向错了。 三问之下，需求自明。值得一读！

AI时代，这个能力尤为重要。 问题、结果、验证，以终为始！

数字化转型中，各类技术仅为落地工具，核心落脚点在于业务模式重构。本书从三大维度拆解数字化项目业务需求的梳理逻辑： 问题层：梳理现存业务痛点，明确痛点带来的实际影响，并深挖问题根源； 结果层：描绘问题解决后的理想业务图景，清晰界定各岗位、业务对象的工作变革； 验收层：设定可落地、可量化的项目验收指标，例：连续三个月业务预测准确率≥90%。

清晰的表达是高效协作的基石，精准的共识是成事的根本。多数协作的偏差与项目的落空，并非能力与技术的局限，而是认知与需求的错位。模糊的主观感受无法落地执行，零散的想法难以形成统一标准。建立系统化的梳理逻辑，拆解问题根源、明确预期结果、锁定验收标准，让抽象构想转化为可落地的清晰需求。统一沟通认知与执行口径，消解协作中的信息偏差，让每一次对接都精准对齐，规避无效内耗，让所有推进都稳步有序。

目的是把问题结构化地描述出来，让 it 团队能理解清楚，不跑偏，保证项目成功。 为了实现这个目的 分 3 步来做： 1.定义清楚问题（有数字支持） 2.定义清楚目的（有数字支持） 3.定义清楚验收标准（有数字支持） 其实沟通的背后也是这些东西，难点是数字怎么来？ 纸上得来终觉浅，绝知此事要躬行。

需求三棱镜: 1，问题:通过现象发现问题本质，本质也需要用具体的数据去体现出来（谁在什么时间发生了什么事，问题的数据是什么样）。 2，结果:成功的案例是什么样，去解决问题得根因。 3，验收:贯穿整个流程，是一个目标和框架，要从一开始就有一个具体确定的验收标准，这样往这个方向努力才能不跑偏。