|
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. 如果我们发现在线聊天的使用率很低：我们需要尝试一些优化方案，例如：a. 自动弹出聊天窗口，b. 修改聊天按钮样式，c. 在聊天按钮旁边增加客服人员照片。 2. 如果测试验证成功：我们会争取更多的客服人力，并且在 Q1 进行大规模迭代改进，包括选择合适的供应商，更深入的数据分析，以及正式的客服话术培训。 指明项目的未来发展方向永远都是好事，因为这样可以引导人们更长远地去思考。 IV. 任务和排期表 考虑到在「未来计划」中提到的问题，这个排期表可能会有一到两周的延期。只要我们能够在 12 月 1 日得到测试结果，我们就在 Q1 人力资源规划时争取到更多的人力。 1. 10 月 4 日：文档评审。 2. 10 月 8 日：和客服团队一起在开发环境中测试如何设置客服人员以及客服时间。 3. 10 月 11 日：上线。我们会在接下来的数天中逐步增加测试流量。 4. 10 月 17 日：在上线1周后同步信息。在此时我们可能会有一些额外的工作要做。 5. 11 月 12 日：最后一次沟通，评审当下状态以决定继续推进还是结束此项目。 6. 12 月 1 日：这是完成此项目并且得到测试结果的最终截止日。 开始的时候排期表可以只有一个大致的估期，通过更多的分析来逐步精确时间点（例如需要技术文档）。 但是尽早尝试拆解和确定时间点，大致框定每项工作的范围和规模仍然是非常重要的。 工期估算应当来自于执行方（开发，设计等）。 ↑↑↑以上是产品文档示例部分↑↑↑ 啊哈！有了文档之后是不是就感觉踏实多了？写文档看起来是额外的工作成本，但是其实并不是，高效的文档可以帮助你和你的团队节约时间投入，并且在交付上线时会更有信心。 等等——你已经读完示例文档了么？请务必先读完它，再继续阅读下面的文章。 产品文档写作指南 我通过示例文档诠释了这篇文章中所讲述的思考，在继续阅读下文之前，请务必确认你已经阅读了上面的文档示范。 为什么要写产品文档？ 一言以蔽之：为了以更高的质量、更快的速度和更佳的预判来交付正确的产品。
|
