一个文档管理系统的诞生一追根溯源

　　本文是系列文章的第一篇，笔者从建立一个文档管理系统的第一步讲起：如何追根溯源，抓住用户的原生需求。
　　从任务说起
　　近期从老板处接到一项非产品工作，每天收集汇总公司多个运营小组编写的针对病种的专业性文档（涉及到公司核心业务，此处以文章指代）。
　　并至少满足老板如下需要：
　　为每个文档分配唯一编码；
　　统一出口，使用者只能在我这获取文档；
　　统计汇报每日完成的文档数量；
　　制作文档清单，并定期更新。
　　收集统计这么简单的事，撸起袖子就干吧，结果往往一顿操作猛如虎，回头一看不靠谱。
　　职场老炮说：会不会工作取决于能不能猜中老板心思。产品经理会翻译成：产品好不好取决于能不能抓住用户的原生需求。
　　原生需求
　　Want和Need是老生常谈，今天只想补充一个OriginalNeed。道生一，一生二，二生三，三生万物。大大小小的真实需求取之不尽，挖之不竭（其实能挖到真实需求已并非易事）。而一定存在一个原生需求来不断产生这些真实需求，有果必有因，原生需求就像一条主干，围绕着它生长出来的才是各种真实需求。找到了主干，想跑偏都很难。
　　要透过现象看本质，先抽象再具体，先归纳再演绎，才能万变不离其宗。本质的、抽象的、归纳的宗就是原生需求。马大爷
　　抽象也好，归纳也罢。还是要基于大量的信息，信息从何而来是要解决的第一个问题。直接从老板或相关第三方获取信息是最直接的办法。但即便如此，这些也只是信息源，少不了接下来自己的分析和加工。
　　今天，就拿上述老板提过的具体要求为例，聊一聊：怎么衍生出更多的信息？
　　先把书读厚
　　先把书读厚，再把书读薄华罗庚
　　分析出大量的信息就是把书读厚，而归纳总结出原生需求就是把书读薄。十万个为什么是最容易把书读厚的方法之一。
　　我们先来简单分析一下：
　　为什么要为文章分配唯一编码？
　　就像每个人都有身份证，并且号码肯定是唯一的。当然是为了便于管理了，而且这串神秘的数字隐藏着不少关键信息呢，这个不用解释了吧！（尤其是110开头的土著们）
　　为什么要统一出口？
　　统一出口的前提是集中管理，目的是为了让使用者明确该找谁获取，同时又能起到传播控制的作用，防止传播泛滥；
　　为什么统计汇报每日完成的文档数量？
　　工作进度既体现了当前的状态和瓶颈，也为未来规划和发展提供了依据，因此需要时刻跟进。
　　文档清单干什么用？
　　文档的价值不是存起来，而是用起来，建立清单就是为了更好的使用。书要有目录才会结构清晰，便于索引。
　　再把书读薄
　　通过上面的简单分析，总结成一句话就是：文档很重要，要集中管理、实时监控、便于使用。这就是粗略的原生需求了！
　　很多朋友会说，这么简单的事，有什么好分析的，干就完了。而且分析完了也是一句正确的废话，你可能不知道是：总结这句废话的两个极其重要的好处：
　　在分析具体要求时，会发现多个问题的答案存有潜在的矛盾冲突。不要慌，这是好事，这会增强你对具体问题的准确理解。比如：上面有两个问题看起来是稍稍有一些冲突的，统一出口势必会降低使用效率，而文件清单是为了提高使用效率。重新思考一下，统一出口本质上保护文档内容信息尽量少外泄，目录清单在没有外泄内容的前提下辅助了传播，两者并无矛盾。
　　找到原生需求以后，就可以轻易的辨别之后的每一个需求是不是伪需求，优先级有多高，是否具有扩展性，就像各种立法的根基一定是不能违背宪法的准绳。
　　迭代原生需求
　　哈哈，终于定义出了原生需求，大功告成！
　　不要高兴的太早，原生需求是需要迭代的，上面的问题只是个例子。你还可以通过继续追问，获取更多新的信息，来不断的完善对原生需求的定义，比如：
　　为什么要编写文档？
　　文档包含什么内容？
　　文档有什么用途？
　　文档和业务怎么结合？
　　原生需求的定义不是一成不变的，随着业务的开展，随时需要进行微调甚至颠覆。但至少在一个中短期的时间窗口，还是能稳定的指引方向的。
　　最后
　　无招胜有招，才是真正的高手。《笑傲江湖》
　　不要盲目的扎入具体需求的实现，拿出一些时间总结出原生需求，当手握根基时你会发现：
　　接到需求后瞬间就能判断是否合理，优先级高低；
　　不再被动接受需求，而去主动发现需求；
　　功能可用性增强，返工和废弃的概率大大降低；
　　易于扩展，新功能与旧功能兼容性更高；
　　不知不觉写了这么多，只写了个开头。不过也好，即保证了阅读体验，又能体现文章重点。