[综合教程经验分享] 《从点子到产品》笔记（八）——第7章 文档管理

第7章 文档管理

Brainy is the new sexy. (智慧也是一种性感)
--Irene Adler

1、了解技术是为了更好地设计功能和协作，并不是帮技术的同事完成工作。

2、不管文档是什么形式、篇幅如何，能让开发人员们看得懂的就是好文档。

3、文档的完整性、逻辑性比文档的可读性、美观程度都重要。

产品经理要不要懂技术？

1、不同公司产品经理负责的事务各不相同，分为技术型、设计型、运营导向型和项目管理型等。

拓展思考一点，在工业控制领域，实际已衍生出业务型的PM，他们以客户为中心开展五环（涉及到机密，此处略过细节）产品开发。

2、产品经理一定要懂技术，具体懂到什么程度看 “需要”。

例：比较让人头疼的是，很多人问 “产品经理是不是需要懂技术” 的问题时，脑海里想的是 “下星期要不要报个Java学习班或者买本 《七天学会安卓开发》”，这样的想法是很荒谬的。

好的文档到底是怎么样的？

1、为什么要有PRD（产品需求文档）？

严格来说，文档不是必须的，完全可以不写，只需产品经理不断跟技术的同事沟通、时刻跟进研发的每个步骤，产品做出来自然是没有问题的，但这个过程效率太低了。

2、“好的” 文档应当满足的几个条件，

没有逻辑硬伤、没有疏漏、逻辑清晰、可读性强，只要满足以上四点，具体的展现形式就不是最重要的了。

3、很多产品经理自认为的位置：

用户 ⇋ 产品经理 → 需求文档

作者认为的表述：

用户 ⇋ 产品经理 ⇋ 技术研发

对于产品经理，输入是不断跟用户发生互动，而输出就是不断跟技术研发人员产生互动。在互动中完成需求分析、产品功能设计及协助产品实现的工作，前后两端同样重要。

文档逻辑

1、怎么才算有清晰的框架和结构呢？

a.拆分

把产品功能（或预期有的功能）枚举拆分成相对独立的模块。

b.组合

简单讲 “合并同类项” ，把相关功能进行模块组合，我们就对消费者端的产品结构一目了然了。

2、怎么分析业务流程的逻辑？

a.面向事件

使用流程图（泳道图）来描述面向时序事件的流程步骤。

b.面向对象

使用状态转换图来表现一次完整的功能使用。

3、描述产品功能时需要注意什么？

a.完整

尽量枚举所有的情况，正常的流程一般是单一流向的，完整的流程往往伴随有异常处理分支。

b.考虑到所有影响点

产品越大、功能越多，就越有可能存在牵一发而动全身的改动。对任何改动，即使再小都可能牵扯到其他的地方。

c.条件判断清晰

条件判断要足够清洗，是在什么条件下有什么功能，或者在怎样的条件下触发怎样的特殊功能都要罗列清晰。
这里可以参考编程语言很常见的if/else、while、switch等几种逻辑描述。

d.含义明确

让大家沟通更加高效。
借用SpaceX的老板马斯克的一句话：“除非得到我的批准，其他的缩写词不能列入SpaceX的词汇库。例如：测试架不应该有 ‘HTS’ 或 ‘VTS’ 这样的称呼，这讨厌的缩写版本实际上比原词更费解......”。

e.叙述背景

逻辑完整 = 叙述背景 + 目的
可参考第4章提到的基于场景需求挖掘。

成长建议 VII

1、产品方面的文档并没有统一的标准，大公司有模板，创业团队可用简陋的形式一页纸说清楚功能也是可以的。

2、文档要讲求逻辑、内容清晰。