减少需求的含混性（上）

最近负责的几款硬件陆陆续续进展到中后期了，但我发现不确定性没有减少反而有增多的迹象，经常会出现以下这些问题。

1、进度越来越慢，最终要么是延期，要么是功能完成得不完整；

2、随着开发的进程，最原始的需求发生了多次变更，但最终版的需求如果你去问团队内的人，每个人理解都不一致；

3、产品是在快速迭代，但每个版本都是对上个版本的否定或调整幅度很大；

4、引入新的设计方案，团队成员为了配合新方法或新的符号系统，带来了新的困难；

5、一款硬件产品，涉及的环节较多，如果手机的光学成像元件更改了，则硬件电路、嵌入式软件算法、客户端都需要跟着更新，不同职能间的沟通、接口文件以及通信协议便面临着出错的风险；

6、因为这些反复的调整（或大或细微），团队成员头绪混乱，有时候会因为反复调整而情绪暴躁。

如果你是从事软、硬件开发或相关管理工作，你所在的团队是否也有类似的问题呢？欢迎继续补充。

为什么类似的问题会反复出现呢？《探索需求—设计前的质量》这本书或许能给你一些答案或启发。

开发的过程可以简单描述为：将人的期望转换为产品的过程。而在这个转换的过程中，「人们试图发现其期望的东西」也即需求，是转换为产品的第一步，也是含混性最多的那一步。这和我们的文化、日常做事的风格也有一些关联，比如我们从小接受的教育很多是：别把话说死，留三分余地；文学作品中，一语双关、文字的细微差异反而耐人寻味。

但产品实现的过程正好相反，假设解决需求阶段的成本是1美元，则设计阶段的成本是需求阶段的3-6倍，而如果问题留到实际运行阶段再解决，其成本可能已经是需求阶段的40-1000倍。

这些浪费绝大多数的原因都是因为对需求的含混理解造成。导致需求含混性的原因很多，作者在书里的第一部分给我们列举了一些。比如：

• 缺少的需求（建一座房子，其材料是什么？）

• 含混的词语（房子的大小是相对的，如何度量？）

• 无意中引入的假设（最开始的需求是“设计一个解决方案”并不是“设计一个建筑物”）

• 观察和回忆错误（观察图纸或回忆最初需求导致的错误）

• 解释错误（用户和设计的理解不一致导致的解释错误）

针对上面这些问题，也许你能想到一些方法，比如：学习书面需求，然后和客户一起坐下来询问他们一些敏锐的问题。但作者把这个过程称为“可靠但不真实的直接问题的用法”。因为我们经常认为好用、管用的“客户面对面调研”一方面对面谈技巧有要求，另外一方面很多问题都是隐藏着的，如果我们不掌握一些探索需求的工具，其结果也会与初始需求相差很大。

作者以决策树模型为例（这是一种用于弥补直接问题的工具），我们向沿着一颗“树”的可能分枝逐步探索一样来绘制设计，这一模型有助于你通过提问所得的回答到达目的地。

决策树有一颗树根、若干树叶，除了客户恰好想要的那片叶子之外，任何叶子都是设计错误。或者说树上的每一片叶子都是一个正确的解决方案，但是它们中的绝大多数都是对错误问题的正确解决方案。

举一个例子：如果客户想要一辆绿色自行车，那么一辆紫色自行车可能就比一个绿色滑雪板更容易接受。在那种情况下，“它是什么颜色的？”可能是一个较靠后的设计问题，而“它是自行车还是滑雪板呢？”的问题则应该相对较早。

所以，问题的次序在实践中和问题本身一样重要。一个有判断力的次序将会产出一个接近于“完美”的解决方案，还能够把为了矫正错误假设所需的工作量降到最低。你不仅需要直接问题，你还需要一些技巧来帮助你用正确的次序问这些问题。

我们通常遇到的问题，决策的错误假设更有可能接近树的根节点附件发生，却更容易在接近叶子附近发现。这就是我们为什么需要在设计过程刚开始的时候，发挥更多的机灵和努力来针对解决含混性，或者用开发人员的行话说，就是需要更多的前期努力，而不仅仅是更多的努力。

回到文章最开始，在项目和产品的后期之所以问题频出，你会发现是因为前期的工作做得远远不够。市场调研不充分、客户沟通不完整、需求落地不严谨、需求变更跟进不及时，所有的这些综合到一起，就导致了后期的步履维艰。

那应该怎么做呢？《探索需求—设计前的质量》中的第二部分有详细的介绍，我们下篇文章再说。

2018年第14篇原创文章2018014《减少需求的含混性（上）》

每周最少两篇文章之2018年第26周（2018.6.25-2018.7.1）记录之一：需求