欢迎加入QQ讨论群258996829
苹果6袋
麦子学院
产品经理实习生怎样提高文档书写能力？
发布时间：2018-06-11 17:49 回复:0 查看:4384 最后回复：2018-06-11 17:49
万事万物皆产品，一个好的
产品经理
不一定要有成为乔布斯那样改变世界的抱负，但一定要有写好产品需求文档的能力。对于刚入行的产品经理特别重要，那么怎样提高文档书写能力呢？
在分享具体的文档结构之前，有两个撰写的前提：
第一，产品文档的终极目标是指导设计和开发，建立对于项目的共同理解。所以在书写的时候，要对阅读对象的理解能力和知识水平以及对这个项目的了解程度都要有个大致的判断，确保每个人都可以看得懂。在Lean startup的背景下，我们既不倡导事无巨细地记录，也不倡导凡事只讲个要点。这个平衡的把握，基于对团队中每个人的了解。
第二，产品文档是一个不断更新的过程。在产品概念设计阶段，根本没有办法写设计的具体需求和测试计划。早起产品文档扮演的角色就是记录那些已经确定的概念和目标，到产品中后期，大家都明白做什么了，也确定了一些用户流程和屏幕细节，文档的整个骨架才会慢慢支撑起来。这意味着，我们一定要做好版本控制。
公司的产品文档包含十个部分。
1. 产品概览(overview）大概用三四句话左右高度描述一下我们会做一个什么样的产品以及为什么要做这样一个产品。
2. 问题与机会（problem and overview)描述我们通过这个产品需要解决的问题，或者是我们正在寻求的机遇。一般来说，这段话的作用在于让人阅读后明白我们为什么要花时间做这件事，以及明白了这件事的意义所在。
3. 产品目标与范围
基于SMART原则来制定的一系列产品目标。其中最重要的是要定义什么是产品的成功。这一点在产品开发时越早提出来越有优势，慢慢会发现是一切决策的依据。
产品范围不仅定义我们决定花时间去做的事，也包括了决定放弃的功能。明确把这些out of scope的东西也列出来，有利于在未来讨论时不用反复出现“那我们做不做这个？做不做那个”的讨论。
4. 产品需求产品需求指的是一小列通过用户的视角撰写的声明。例如“我希望通过这个产品我可以实现……”它不需要包含具体的实施细节，也不需要写具体的界面元素。它们只是对于产品成功的一些具体表现。
5. 产品原则这里面会提到一些设计和技术的原则，例如facebook的设计原则就是：universal, clean, consistent, useful等等。不同的产品会需要不同的原则。例如对于2B的一些企业级软件，安全和易用是非常高的原则。然而对于一些消费者产品，趣味性和创新可能更为重要。
6. 用户故事
之前已经有人提到了用户故事，里面讲到了用户故事的三大元素：谁，是什么，为什么。这是一个比较直接的表述。一般在设计师眼里，会考虑更多的场景，动机，用户行为以及最终的价值实现。所以一般一个产品，会支持若干个优先级的用户故事。每个用户故事是描述了一段独立的end-to-end的使用体验。它包括：用户画像（persona），使用场景（context), 使用意图（intent), 步骤（flow), 产品价值（value, 产品如何帮助用户实现价值），以及优先级（priority）
一般优先级最高的进入MVP（minimal viable product), 然后依次类推，优先级最低的进入backlog，大家有空有资源再考虑实现。
7. 设计细则这里包含的是设计的细节。产品经理有时候可以提供一些wireframe，也可以让设计师来提供更加专业的设计稿。
8. 衡量指标这一块讲的是具体如何衡量一个产品的成功。指标性的东西来帮我们判断自己的努力是否有了预期的回报。
9. 依赖物（dependencies)这一点比较容易被人忽略，但是往往很重要。因为产品经理是对一个产品最有全局观的人，所以一定要说清楚，哪些交付物得走在哪些交付物的前头，交付物和交付物之前是什么样的关系，这样对应的负责人才有一个清晰的认识，不致于误了开发时间。
10. 测试计划
测试计划是一系列需要在产品发布之前做的测试，确保在各种使用情境下，产品都不会有意外发生。测试计划包含了可用性测试，performance，regression testing，以及一些基于特定使用场景下的行为测试。
有好几点其实要摊来开讲，还可以讲得更深，不过暂且分享到这里。做产品尤其是在产品初期，其实是不断地和不同的人碰撞想法的过程。然后我们把一些确定下来的点子放到产品文档里面封存起来。首先要考虑的是产品是否有价值，这种价值是否可以在交流中让别人感受到，一般这两点满足之后再写产品文档会思路清晰很多。
公众号：maibanzhang
（素材来源于网络，并非原创，如有雷同，请联系删除）
在分享具体的文档结构之前，有两个撰写的前提：
第一，产品文档的终极目标是指导设计和开发，建立对于项目的共同理解。所以在书写的时候，要对阅读对象的理解能力和知识水平以及对这个项目的了解程度都要有个大致的判断，确保每个人都可以看得懂。在Lean startup的背景下，我们既不倡导事无巨细地记录，也不倡导凡事只讲个要点。这个平衡的把握，基于对团队中每个人的了解。
第二，产品文档是一个不断更新的过程。在产品概念设计阶段，根本没有办法写设计的具体需求和测试计划。早起产品文档扮演的角色就是记录那些已经确定的概念和目标，到产品中后期，大家都明白做什么了，也确定了一些用户流程和屏幕细节，文档的整个骨架才会慢慢支撑起来。这意味着，我们一定要做好版本控制。
公司的产品文档包含十个部分。
1. 产品概览(overview）大概用三四句话左右高度描述一下我们会做一个什么样的产品以及为什么要做这样一个产品。
2. 问题与机会（problem and overview)描述我们通过这个产品需要解决的问题，或者是我们正在寻求的机遇。一般来说，这段话的作用在于让人阅读后明白我们为什么要花时间做这件事，以及明白了这件事的意义所在。
3. 产品目标与范围
基于SMART原则来制定的一系列产品目标。其中最重要的是要定义什么是产品的成功。这一点在产品开发时越早提出来越有优势，慢慢会发现是一切决策的依据。
产品范围不仅定义我们决定花时间去做的事，也包括了决定放弃的功能。明确把这些out of scope的东西也列出来，有利于在未来讨论时不用反复出现“那我们做不做这个？做不做那个”的讨论。
4. 产品需求产品需求指的是一小列通过用户的视角撰写的声明。例如“我希望通过这个产品我可以实现……”它不需要包含具体的实施细节，也不需要写具体的界面元素。它们只是对于产品成功的一些具体表现。
5. 产品原则这里面会提到一些设计和技术的原则，例如facebook的设计原则就是：universal, clean, consistent, useful等等。不同的产品会需要不同的原则。例如对于2B的一些企业级软件，安全和易用是非常高的原则。然而对于一些消费者产品，趣味性和创新可能更为重要。
6. 用户故事
之前已经有人提到了用户故事，里面讲到了用户故事的三大元素：谁，是什么，为什么。这是一个比较直接的表述。一般在设计师眼里，会考虑更多的场景，动机，用户行为以及最终的价值实现。所以一般一个产品，会支持若干个优先级的用户故事。每个用户故事是描述了一段独立的end-to-end的使用体验。它包括：用户画像（persona），使用场景（context), 使用意图（intent), 步骤（flow), 产品价值（value, 产品如何帮助用户实现价值），以及优先级（priority）
一般优先级最高的进入MVP（minimal viable product), 然后依次类推，优先级最低的进入backlog，大家有空有资源再考虑实现。
7. 设计细则这里包含的是设计的细节。产品经理有时候可以提供一些wireframe，也可以让设计师来提供更加专业的设计稿。
8. 衡量指标这一块讲的是具体如何衡量一个产品的成功。指标性的东西来帮我们判断自己的努力是否有了预期的回报。
9. 依赖物（dependencies)这一点比较容易被人忽略，但是往往很重要。因为产品经理是对一个产品最有全局观的人，所以一定要说清楚，哪些交付物得走在哪些交付物的前头，交付物和交付物之前是什么样的关系，这样对应的负责人才有一个清晰的认识，不致于误了开发时间。
10. 测试计划
测试计划是一系列需要在产品发布之前做的测试，确保在各种使用情境下，产品都不会有意外发生。测试计划包含了可用性测试，performance，regression testing，以及一些基于特定使用场景下的行为测试。
有好几点其实要摊来开讲，还可以讲得更深，不过暂且分享到这里。做产品尤其是在产品初期，其实是不断地和不同的人碰撞想法的过程。然后我们把一些确定下来的点子放到产品文档里面封存起来。首先要考虑的是产品是否有价值，这种价值是否可以在交流中让别人感受到，一般这两点满足之后再写产品文档会思路清晰很多。
公众号：maibanzhang
（素材来源于网络，并非原创，如有雷同，请联系删除）