一 项目中的各种文档、评审
关于文档
在原型工具越来越完善的今天，文档的形式更加多样化，FSD可以和设计一起产出高保真原型。这也是《启示录》里建议的，《有的放矢》和《四步创业法》里的最小功能集合、几位老师提到的MVP等概念都值得重视。
另外关于PRD，7月份刚开始入门的时候找到一篇文章：董弈的回答
关于UML（《人人》，page130）
以及之前记录过的用例文档的UC模板：读书笔记2——《人人都是产品经理》（持续更新）
UC一般只用来描述功能需求，不便于描述诸如产品拓展性、系统容量、人员培训等非功能需求。UC里对语言要求比较高：无歧义、完整、一致、可测试等。
关于Demo
1.最重要的不是工具，心中有剑，拿根树枝都能杀人。
2.让专业的人做专业的事。
关于评审
项目中的需求阶段，通常围绕“写作→评审→修改→评审”循环展开。
评审是流程中的关键节点，节点设置的顺序正确、数量合适，才能保证流程的通畅。
需求的生老病死
《人人》page143。
二 开发测试到发布
对于每个特定的项目，应该在开始之前就约定好各种管理方法，比如文档怎么管理、测试过程怎么管理、使用哪些技术工具等。
关于发布：灰度测试、回滚方案。
以始为终，项目小结
通过项目的日报或周报随时记录每天的情况。
三 聊聊文档与流程
建立自己的文档规范
主要内容在《人人》page155。
模板的作用
1.让经常看同类文档的人提高效率；2.让写文档的新人可以尽快上手；3.让写作者不会遗漏内容。
关于流程
设计流程的目的，在于保证“无论谁来做这个产品的设计，都能达到80分”。
三 一些特色项目
1.老板项目
2.封闭开发
3.开发外包，项目外包
《人人》page173.
早一步是先驱，再早一步是先烈。
四 文档与用户体验
《启示录》page113~121
安息吧，纸质说明文档
作者推崇使用高保真模型，他认为产品经理的核心责任是确保向开发团队交付具有成功潜力的产品说明文档。理想文档应该满足：
1.完整的描述用户体验，不只用户需求，还有交互设计、视觉设计‘’
2.必须准确说明软件的行为，文字和图片的表达能力有限；
3.受众要广，开发人员、测试人员、客服人员、市场营销人员、运维人员、销售人员、管理层等；
4.可以修改；
5.避免衍生物混淆不清。（原文见《启示录》page114~115）
作者要求原型尽可能体现产品细节，包括所有页面和主要用例。辅助用例文档补充描述重要的产品行为。展示说明文档最理想的方法是在原型上增加注释。
高保真原型最突出的优势是可以用于测试。
作者推荐的高保真原型和产品说明文档范例参考：Examples
先定义用户体验再动手开发
作者认为需求调研和产品设计应该同步展开，但用户体验设计和软件开发不不能一起进行。
最后：
“让用户放弃不可用的软件很容易，要他们放弃使用习惯却很难。”
2016.11.05，18：20
