本文是系列文章的第一篇，笔者从建立一个文档管理系统的第一步讲起：如何追根溯源，抓住用户的原生需求。

从任务说起

近期从老板处接到一项非产品工作，每天收集汇总公司多个运营小组编写的针对病种的专业性文档（涉及到公司核心业务，此处以文章指代）。

并至少满足老板如下需要：

• 为每个文档分配唯一编码；
• 统一出口，使用者只能在我这获取文档；
• 统计汇报每日完成的文档数量；
• 制作文档清单，并定期更新。

收集统计这么简单的事，撸起袖子就干吧，结果往往一顿操作猛如虎，回头一看不靠谱。

职场老炮说：会不会工作取决于能不能猜中老板心思。产品经理会翻译成：产品好不好取决于能不能抓住用户的原生需求。

原生需求

Want 和 Need 是老生常谈，今天只想补充一个Original Need。道生一，一生二，二生三，三生万物。大大小小的真实需求取之不尽，挖之不竭（其实能挖到真实需求已并非易事）。而一定存在一个原生需求来不断产生这些真实需求，有果必有因，原生需求就像一条主干，围绕着它生长出来的才是各种真实需求。找到了主干，想跑偏都很难。

要透过现象看本质，先抽象再具体，先归纳再演绎，才能万变不离其宗。本质的、抽象的、归纳的宗就是原生需求。——马大爷

抽象也好，归纳也罢。还是要基于大量的信息，信息从何而来是要解决的第一个问题。直接从老板或相关第三方获取信息是最直接的办法。但即便如此，这些也只是信息源，少不了接下来自己的分析和加工。

今天，就拿上述老板提过的具体要求为例，聊一聊：怎么衍生出更多的信息？

先把书读厚

先把书读厚，再把书读薄 ——华罗庚

分析出大量的信息就是把书读厚，而归纳总结出原生需求就是把书读薄。“十万个为什么”是最容易把书读厚的方法之一。

我们先来简单分析一下：

为什么要为文章分配唯一编码？

——就像每个人都有身份证，并且号码肯定是唯一的。当然是为了便于管理了，而且这串神秘的数字隐藏着不少关键信息呢，这个不用解释了吧！（尤其是110开头的土著们）

为什么要统一出口？

——统一出口的前提是集中管理，目的是为了让使用者明确该找谁获取，同时又能起到传播控制的作用，防止传播泛滥；

为什么统计汇报每日完成的文档数量？

——工作进度既体现了当前的状态和瓶颈，也为未来规划和发展提供了依据，因此需要时刻跟进。

文档清单干什么用？

——文档的价值不是存起来，而是用起来，建立清单就是为了更好的使用。书要有目录才会结构清晰，便于索引。

再把书读薄

通过上面的简单分析，总结成一句话就是：文档很重要，要集中管理、实时监控、便于使用。这就是粗略的原生需求了！

很多朋友会说，这么简单的事，有什么好分析的，干就完了。而且分析完了也是一句正确的废话，你可能不知道是：总结这句废话的两个极其重要的好处：

1. 在分析具体要求时，会发现多个问题的答案存有潜在的矛盾冲突。不要慌，这是好事，这会增强你对具体问题的准确理解。比如：上面有两个问题看起来是稍稍有一些冲突的，统一出口势必会降低使用效率，而文件清单是为了提高使用效率。重新思考一下，统一出口本质上保护文档内容信息尽量少外泄，目录清单在没有外泄内容的前提下辅助了传播，两者并无矛盾。
2. 找到原生需求以后，就可以轻易的辨别之后的每一个需求是不是伪需求，优先级有多高，是否具有扩展性，就像各种立法的根基一定是不能违背宪法的准绳。

迭代原生需求

哈哈，终于定义出了原生需求，大功告成！

不要高兴的太早，原生需求是需要迭代的，上面的问题只是个例子。你还可以通过继续追问，获取更多新的信息，来不断的完善对原生需求的定义，比如：

• 为什么要编写文档？
• 文档包含什么内容？
• 文档有什么用途？
• 文档和业务怎么结合？
• ……

原生需求的定义不是一成不变的，随着业务的开展，随时需要进行微调甚至颠覆。但至少在一个中短期的时间窗口，还是能稳定的指引方向的。

最后

无招胜有招，才是真正的高手。–《笑傲江湖》

不要盲目的扎入具体需求的实现，拿出一些时间总结出原生需求，当手握根基时你会发现：

1. 接到需求后瞬间就能判断是否合理，优先级高低；
2. 不再被动接受需求，而去主动发现需求；
3. 功能可用性增强，返工和废弃的概率大大降低；
4. 易于扩展，新功能与旧功能兼容性更高；
5. ……

不知不觉写了这么多，只写了个开头。不过也好，即保证了阅读体验，又能体现文章重点。

本文由@产品非经理 原创发布于人人都是产品经理，未经许可，禁止转载。

题图来自Unsplash, 基于CC0协议。