最新公告
  • 欢迎您光临欧资源网,本站秉承服务宗旨 履行“站长”责任,销售只是起点 服务永无止境!立即加入我们
  • 不安静的书桌(1):高效的产品文档写作指南

    本文作者 Gaurav Oberoi 是 SurveyMonkey 的前联合创始人。他曾在亚马逊和 Xmarks 工作过。他在硅谷有十多年的工作经验,负责过几款拥有数百万用户的产品。

    全文由刘涵玉翻译。翻译是FellowPlus的产品经理。他个人关注产品设计、效率工具和投融资行业。微信公众号“No Quiet Desk”,欢迎关注交流。

    温馨提示:本文为4D文字,通读大约需要15分钟。

    前面的话:

    产品经理往往负责互联网公司的所有需求,需要沟通的对象还包括设计、开发、测试、运营等角色。因此,产品经理需要处理和面对的信息量往往是巨大的,因此也经常面临沟通效率低下、产品开发进度和质量不可控等问题。

    这个时候,最好的解决方案其实就是清晰高效的产品文档。不幸的是,大多数产品经理对“文档”的价值和意义认识不足。

    在本文中,作者 Gaurav Oberoi 分享了他对产品文档和编写产品文档的通用流程的看法。此外,本文还包含一个真正完整的产品文档示例,以及详细的产品文档编写指南(包括格式+思路),希望对您有所帮助。

    以下是正文

    很多人听到“产品文档”这个词就像吞下一只苍蝇一样,人们通常认为这意味着还要再写几个星期的文档,而根本没有人阅读。如果一个团队总是被产品文档之类的东西拖累,它怎么可能“敏捷”,怎么可能高效地生成代码?

    在过去十年创建了数百万人使用的多个软件产品之后,我越来越认为这种观点是完全错误的。根据我的经验:

    有效的产品文档是创造伟大产品的过程中不可或缺的一部分。编写产品文档迫使每个人从项目一开始就进行理性思考,经常沟通,定义职责——所有这些都会带来更好的软件质量、更少的进度风险和更少的时间浪费。

    在本文中,我将通过一个案例来分享一些对产品经理,尤其是大中型(200人以上)公司的产品经理非常有帮助的一般性建议。

    首先,我们来看一个例子

    假设你需要解决这样一个问题:

    一家经营在线旅行预订服务的公司(如酒店或 Airbnb,但规模较小)。目前这家公司的支付转化率比较低,所以本季度大家打算尝试通过在支付环节增加在线客服来增加转化。

    你的计划是:

    尝试通过在支付环节增加在线客服来提高支付转化率。

    目前支付转化率仅为18%,而行业平均转化率为30%。我们将测试在结帐时显示实时聊天窗口是否可以提高此转化率。用户运营团队已同意提供1人月的客服人力支持。

    如果您没有产品文档,请执行以下操作:

    假设您觉得行动始终是最重要的事情,那么就开始吧:

    1. 在迭代计划会议上,你和团队讨论了这个需求;

    2. 那你就选择靠谱的第三方客服(比如SnapEngage);

    3. 提交工单让工程师添加一些Java代码;

    4. 与支持团队开会,确保他们准备就绪。

    搞定了!这么简单的事情怎么会要求我们写产品文档呢?

    那么现在问题来了:

    如果你在一个小型的创业团队,你可能真的不需要产品文档——因为产品变化相对较小,涉及的人也相对较少。

    但是,如果您在一个更大的组织中,或者如果产品更成熟/复杂,则以下问题开始出现,并且比编写文档需要更多的时间来处理。例如:

    如果这是一个相对简单的项目,如果没有产品文档,它可能不会是一场灾难。但是在简单的项目中,如果没有文档,您仍然会浪费大量时间和机会成本。

    如果你写一个文件:

    为了便于说明,我准备了两个示例文档:一个想法笔记,一个完整的产品文档——可以完整描述产品文档的编写过程。

    请花几分钟时间阅读这两个示例文档,然后再继续。

    1. 思想笔记示例(阅读 2 分钟)

    这是一个基于您已经知道的内容和您想要回答的问题的列表。这将是您需要做的第一件事,完成此文档大约需要一个小时。本文档将成为您与团队其他成员之间沟通的基础。

    ↓↓↓以下是idea笔记的示例部分↓↓↓

    1. 问题

    2. 目标

    3. 聊天服务提供者

    4. 如何衡量成功

    5. 高级测试

    6. 需要什么样的数据报告?

    7. 还有什么?

    ↑↑↑以上是idea笔记的示例部分↑↑↑

    2. 示例产品文档(6 分钟阅读)

    只有在与团队一起审查了您的假设和想法之后(无论是在特别召开的会议上、喝咖啡时还是在桌上足球休息期间),您才真正开始编写产品文档。如果沟通和审查已经完成,整个文档应该需要您 1-3 个小时的时间。

    ↓↓↓ 这是产品文档的示例部分 ↓↓↓

    灰色的参考是评论。

    第一次阅读本文档时,建议忽略评论部分阅读整篇文章,然后回到文章开头重新阅读所有内容。

    文中提到的所有超链接都没有链接到任何地方。本文中的反向链接只是表明有一些待办事项和相关文档。

    支付时添加在线客服

    作者:高拉夫·奥贝罗伊

    最后更新日期:2016 年 9 月 28 日

    该项目的目标是通过向支付页面添加实时聊天客户服务来提高支付转化率。这是一个为期 30 天的测试,测试完成后,我们可能会上线或关闭此功能(薛定谔的客户服务?蛤蜊)。

    用不超过两行的文字描述这个项目。“行”是指您的客户端的默认阅读宽度(例如 Google 文档、wiki、文本文件等)。坚持字数限制是可读性的关键。

    一、概述

    A. 问​​题

    1. 支付转化率过低:点击“预订”按钮的用户中只有18%完成了支付。竞争预订网站可以实现 30% 左右的转化率(数据源)。我们正在失去收入!

    2. 没有明确的流失原因:之前的票务和用户调查给出了非常广泛的可能原因(易用性、支付费用、支付时间问题),并且没有明确的分类。

    3. 添加帮助文档内容没有帮助:上个季度,我们对帮助文档和预订信息的内容和界面设计进行了 A/B 测试。这导致转化率仅略微增加 1.5%。

    我强烈建议使用列表来增强文档的可读性。

    使用粗体文本快速指出每行文本的要点,并将列表限制为两三行。

    我更喜欢有序列表,因为它们在口头交流时很容易指示。

    B. 目标

    1. 测试客服聊天是否能显着提高转化率:一天增加90多单可以平掉线上客服的运营成本,能否做到还不清楚。这是一个测验!

    2. 降低测试成本:避免一切过度优化,如果测试成功,我们可以优化Q1的在线聊天体验。

    3. 12 月 1 日的最终结果:我们有 8 周的时间开始规划第一季度。

    确保文档可以提出一个清晰的目标,应该很容易判断“你实现了吗?”。

    在文档中做出明确的承诺。

    C. 不应考虑的问题

    1. 重要的 UI 更改:仅添加可见的聊天按钮,没有其他设计更改。

    2. 确定聊天服务商:暂时使用SnapEngage,如果测试成功,考虑长期服务商。

    3. 国际和非英语用户:为简单起见,此测试仅适用于美国和其他英语用户。

    这部分用于消除各种不利的假设,建立正确的项目预期。

    D. 团队成员和角色划分

    1. Heather(用户运营经理):批准客户服务资源要求。

    2. Randy(用户运营专员):每周负责处理用户反馈,整理反馈总结。

    3. Colin(工程师):开发和测试。还负责配置 SnapEngage 并向我们展示如何设置它。

    4. Kalpana(财务):负责审查我在测试阶段及以后的盈利预算。

    5. Joha(设计师):花点时间看看我们对设计所做的改动,没有大的设计要求。

    6. Vikram(数据分析师):确保我们按时获得本次测试的数据报告。

    帮助每个人确定项目成员和对他们每个人的期望。

    只包括那些会做这件事的人,以及对这件事有通过/否决权的人。

    二、背景

    这应该包含理解当前问题及其解决方案所需的所有背景信息。

    添加您认为应该出现在此处的任何内容,例如:用例、用户模型、指标、竞争解决方案、研究结果等。

    A. 用例

    1. 用户要求:

    在 2 分钟内获得帮助:不确定是否可以实现,但让我们先去做。

    适应移动端和桌面端:28%的支付是在手机上完成的,所以移动端的适应很重要。

    2. 用户运营团队要求:

    带反馈队列的客服后台:桌面/网页均可,无需支持移动端

    添加或删除客服人员:可自行完成,无需开发者支持

    设置在线时间:您可以控制网站上的实时聊天按钮是否可见。

    查看用户信息:需要将用户ID的参数传递给后台,以便客服人员可以找到当前用户信息。

    标记对话:聊天结束后,可以在评论区记录一些非结构化的文本信息。

    B. 假设

    1. 每天增加 90 个付费订单可以使客服人员的运营成本相等:基于每个客服人员的成本和付费用户的 LTV(生命周期价值)。详见表格。

    2. 单个代理可以支持 20% 的支付流量:基于一组关于等待时间、聊天持续时间和并发聊天数量的假设。我们没有数据来支持做出可靠的假设,所以我们决定做一个数字并且需要我们的系统来支持测试流量的快速增加/减少。

    3. 支付转化率应该从 18% 提高到 20%:总转化率不需要提高太多就已经说明测试成功了。在此处查看我们的分析报告。

    三、解决方案

    用最自然的方式描述你的计划。

    它需要清晰、连贯和合理分割。

    根据不同项目的特点,您还可以添加:线框图、用户流程图、表单输入/验证逻辑、数据模型…等执行计划所需的所有细节。

    A. 在线客户服务提供商

    我选择了 SnapEngage,它符合我们规定的用例,而且价格便宜(每月 60 美元)。注:如果测试成功,我们将再次选择合适的供应商。我已经注册了一个付费账户,账户密码在我们的密码管理工具中。

    B. 用户体验

    浏览 SnapEngage 的文档,找出他们的这个聊天窗口的弹出逻辑。有以下几点:

    1.按钮:设置为“立即聊天”的文字,放在详情页“预订”主按钮旁边;

    2. 交互:点击时,客服名称和“您需要什么帮助?”的副本 显示;

    3. 所有支付页面:应该显示在所有三个支付步骤页面上;

    4. 不自动弹出:我们以后可以试试这个效果,现在低调上线。

    C. 会话参数

    1. 它是什么:当我们嵌入服务提供者的Java时,我们可以传入某些参数。这些参数可以被客服看到,也会记录在日志和数据报告中。

    2. 传输这些参数:用户 ID、用户电子邮件、浏览器信息、预订 ID、预订订单价格。

    D. 测试流量开关

    只有部分支付流量会看到在线客服功能。这是我们需要做的:

    1. 只显示给 X% 的用户:我们必须能够在不重新部署的情况下修改 X 的值,但是每次我们修改它时,用户运营团队都会向工程师提交工单进行手动修改(例如存储这个我们的数据库/Redis 中的值)。

    2. 对显示的用户始终可见:只要用户已经看过一次聊天窗口,用户就应该在测试期间始终看到此功能。这个状态可以保存在一个cookie中,也可以和该批用户的用户ID一起记录(例如:如果用户ID模100小于X,可以看到这个特性)。

    3. 流量增加计划:第一天,我们只开放5%的流量进行测试。如果用户运营团队反馈正常,第二天会开通10%的流量,第三天开通20%的流量。.

    E. 数据指标和报告

    1. 日志记录:添加到现有指标:“live_checkout=true/false”。

    2. 新数据报告:

    比较有在线客服的用户(测试组)和没有在线客服的用户(对照组)的支付转化率。

    在线客服产生的订单总数和收入。

    有多少测试用户点击了实时聊天窗口。

    3. SnapEngage 的数据报告:它可以告诉我们平均会话时间、并发会话数等数据

    我上面给出的示例可能晦涩难懂,但我们团队的工程师和数据分析师将能够轻松理解它 – 因为他们是文档这一部分的受众。

    记住:写下人脑需要做的所有必要的事情。

    F. 未来计划

    1. 如果我们发现在线聊天的使用率低:我们需要尝试一些优化方案c语言开发群发软件哪个好,例如:自动弹出聊天窗口,b.修改聊天按钮的样式,c。在聊天按钮旁边添加代理的照片。

    2.如果测试成功:我们将争取更多的客服人力,并在Q1进行大规模的迭代改进,包括选择合适的供应商,更深入的数据分析,以及正式的客服技能培训。

    指出一个项目的未来方向总是好的,因为它引导人们进行更长远的思考。

    四。任务和时间表

    考虑到《未来计划》中提到的问题,这个时间表可能会延长一到两周。只要我们能在12月1日拿到测试结果,我们就会在Q1 HR规划中获得更多的人手。

    1. 10 月 4 日:文档审查。

    2. 10 月 8 日:与支持团队一起测试如何在开发环境中设置代理及其工作时间。

    3. 10 月 11 日:直播。我们将在未来几天逐步增加测试流量。

    4. 10 月 17 日:上线 1 周后同步信息。在这一点上,我们可能还有一些额外的工作要做。

    5. 11 月 12 日:最后一次沟通,审查当前状态以决定是推进还是关闭项目。

    6. 12 月 1 日:这是完成这个项目并收到测试结果的最后期限。

    一开始,时间表只能有一个粗略的估计,通过更多的分析,可以逐步细化时间点(例如需要技术文档)。

    但还是要尽量早点拆解确定时间,粗略勾勒出每件作品的范围和规模。

    持续时间估计应来自执行方(开发、设计等)。

    ↑↑↑以上是产品文档的示例部分↑↑↑

    啊哈!拿到文件后是不是感觉更安心了?编写文档似乎是一项额外的工作成本,但事实并非如此。有效的文档可以帮助您和您的团队节省时间投资,并在交付上线时让您更有信心。

    等等 – 你读过示例文档了吗?在继续下面的文章之前,请务必先阅读它。

    产品文档编写指南

    我用一个示例文档来解释本文中描述的思想,请确保您在继续之前阅读了上述文档演示。

    为什么要编写产品文档?

    一言以蔽之:交付具有更高质量、更快和更好可预测性的正确产品。

    对,就是那样。那么产品文档将如何帮助您完成这一切呢?Ben Horowitz 在上图中分享了这个观点,我的示例文档就是一个很好的例子。只是要清楚:

    1. 从一开始就理性思考

    在团队开始为设计软件架构、实施代码开发、改进界面设计和测试软件质量之前,编写文档可以迫使您提前考虑每一个细节。这将提高您决策的质量并减少意外的机会。

    2. 有效沟通

    您经常需要将您的提案传达给不同的利益相关者(支持团队、工程团队、设计团队、财务团队、管理层等)。产品文档可以帮助您以更少的努力进行更多的沟通,避免口头沟通中的歧义,并让团队中的每个人都能更好地理解您的意图并更有效地做出响应。

    3. 明确职责

    明确项目目标的评价标准,公开承诺奖惩激励:利益相关者可以在最后一刻知道改变需求意味着什么,工程师在估算工期时会仔细检查。

    产品文档应该包含什么?

    产品文档应该清楚地传达要制造产品的“什么”,以及“为什么”要这样做。一个产品的表达方式有很多种,但最重要的是要明确这五点:

    1. 问题

    描述你这次打算解决的问题。更重要的是,解释你为什么要解决这个问题。描述应尽可能具体,并提供相关的数据指标。

    2. 可衡量的目标

    对可交付成果和成果做出明确承诺,并确定超出该项目范围的内容。对于每个目标,应该可以清楚地衡量“目标是否实现”。

    3. 需求背景

    提供您的受众了解当前问题并接受您的提议所需的所有背景信息。包括但不限于假设、用例、数据指标和其他信息。

    4. 解决方案详情

    您的提案应该足够详细,以便团队成员消化和执行——将其视为对人脑的编程和执行。

    5. 时间线

    列出您的团队同意的最后期限和其他重要时间点。此部分起初可能含糊不清,但应在最终文档审查之前完全定稿。

    您可以使用我的示例文档作为您的文档模板并添加/删除/修改您想要的任何章节。只要你能清楚、连贯地表达上述五点信息,文件的形式无所谓。

    产品文档编写流程:

    接下来,我将描述我编写和审查文档的一般过程。根据项目的规模、利益相关者的数量等,过程的细节可能会发生变化,但大体的过程是固定的。

    1. 快速完成一份草稿(1-2 小时)

    关闭电子邮件和聊天工具。泡一杯茶,坐在椅子上开始思考,然后列出你所知道的,上面的思考笔记的例子。

    2. 安排几次 30 分钟的一对一会议(1-4 小时)

    此步骤的目的是仔细阅读文档中的详细信息,完善您的解决方案并获得更多支持。尽可能控制这些会议的规模,尽可能少的人(理想情况下都是一对一的会议)。例如,在本文的示例中,我将安排与客户服务部门负责人、财务人员和工程师的会议。

    3. 编写和编辑文档(0.5-3 天)

    此时,你应该对自己能做什么和应该做什么有一个清晰的认识,但你的大脑却塞满了等待理清的细节。所以下一步就是把所有这些细节都梳理一遍,一一梳理出来。

    完成文档的第一个版本后,您需要继续对其进行编辑和修改。通常,最终文档可以在您的第一个版本草稿的基础上压缩 30%-50%。简洁明了的文档意味着更容易阅读。.

    大多数文件半天到一天就可以完成,但实际上也有一些文件需要两三天才能完成。

    4. 批量文档并安排一个 1 小时的审查会议(15 分钟)

    将文档发送给项目的所有利益相关者,并抄送可能对文档感兴趣的其他团队(例如您的产品团队、整个支持团队等)。

    跟进这些关键人物是否接受了会议邀请:将执行这件事的人,以及所有对这件事有通过/否决权的人。

    5. 审查文件(1 小时)

    在开始会议之前,询问是否有任何与会者没有详细阅读您的文档。一般会拍一两个人,这种情况下你可以说:“没问题,我们看文档10分钟,已经看过文档的可以利用这段时间先放松一下。”

    在这次会议上,您需要获得利益相关者的同意,并获得高管(工程师、支持团队等)的专业知识、支持和人力支持。

    您可能需要召开多次审查会议,并根据审查会议上传达的信息不断修改文件。

    6.审核通过后,及时同步信息,创建工单(1-2小时)

    会后同步电子邮件需要包含更新产品文档的链接、与该项目相关的工单的链接(例如向页面添加 Java 代码、完成数据分析报告、测试登台环境和支持团队排练流程等)。

    通常工程师接下来会完成技术文档,但并非总是如此(本文中的示例项目不需要此步骤)。

    产品文档高级提示:

    1. 保持简短

    没有比这更重要的文档写作建议了。简洁意味着清晰的想法和沟通,这意味着您的文档更易于阅读和理解——这至关重要。

    2. 使用简单的语言和简单的格式

    使用简短而不是花哨的句子,使用列表和粗体强调使文章更一目了然,以轻松有趣的方式而不是僵硬的方式写作,如果你有体面的幽默感会更好。

    3. 为开发团队预留时间

    完整的文档是经过审查并达成共识的文档。如果你想在未来的 Sprint 中开发项目,你应该提前两到三周开始产品文档的编写过程。

    4. 像工程师一样思考

    当一个项目进入开发阶段时,通常会发现很多意想不到的边缘情况——但它们是可以避免的。如果您已经仔细考虑了项目进入开发的所有必要条件,您可以提前发现这些问题(例如,移动设备中是否可以使用实时聊天?)。

    5. 确保每个人都跟随你的节奏

    当我进行产品评论时,房间里的大多数人已经对我要谈论的内容有了一个大致的了解——因为我已经提前在讨论和日常聊天中传达了这一点。既然大家对“做什么”和“为什么做”有了清晰的认识,我们只需要在文件审查会上关注实施细节即可。

    6. 处理图表

    流程图、线框图等图表可以以通俗易懂的方式提供大量信息,但制作这些图表也需要大量时间。

    7. 花 0. 5-3 天时间思考和编写文档

    具体时间取决于项目的大小。花在编写文档上的时间越长,边际收益就越小。特别是,没有人可以阅读超过 5-6 页的文档。

    8. 指明方向,清晰视野

    你不只是定义一个特性,你在解释“我们为什么这样做”和“我们的目标是什么”,在文档中指出项目将如何影响更高级别的规划,以及接下来会发生什么。

    9. 确保您的听众阅读文档

    如果您的文档很臭,很长,或者从未与合适的人共享,那么您最好不要编写文档。确保你的文档被合适的人阅读c语言开发群发软件哪个好,我上面关于在审查开始时让每个人都有时间阅读文档的建议值得考虑。

    站内大部分资源收集于网络,若侵犯了您的合法权益,请联系我们删除!
    欧资源网 » 不安静的书桌(1):高效的产品文档写作指南

    常见问题FAQ

    免费下载或者VIP会员专享资源能否直接商用?
    本站所有资源版权均属于原作者所有,这里所提供资源均只能用于参考学习用,请勿直接商用。若由于商用引起版权纠纷,一切责任均由使用者承担。更多说明请参考 VIP介绍。
    提示下载完但解压或打开不了?
    最常见的情况是下载不完整: 可对比下载完压缩包的与网盘上的容量,若小于网盘提示的容量则是这个原因。这是浏览器下载的bug,建议用百度网盘软件或迅雷下载。若排除这种情况,可在对应资源底部留言,或 联络我们.。
    找不到素材资源介绍文章里的示例图片?
    对于PPT,KEY,Mockups,APP,网页模版等类型的素材,文章内用于介绍的图片通常并不包含在对应可供下载素材包内。这些相关商业图片需另外购买,且本站不负责(也没有办法)找到出处。 同样地一些字体文件也是这种情况,但部分素材会在素材包内有一份字体下载链接清单。
    欧资源网
    一个高级程序员模板开发平台

    发表评论