移动应用团队怎样分配 Bot 工作
Ryan Perry 用移动游戏案例，介绍分析、开发和运营之间的交接。
开发之外还有运营
原文关注获客、素材、发布与故障处理。长期 Bot 通过工具连接和交接承担职责。
先写清各自负责什么
六个角色覆盖管理、数据、创意、工程、部署和修复，分析角色先给出发现。
把一个角色配完整
以分析 Bot 为例，原文逐项说明职责、连接、云电脑、日程、技能和交接；花钱前要确认。
从交接看成效
团队可互相传递工作。作者报告了安装成本和留存的改善，数字属于这一游戏案例。
随新问题增加职责
后续计划补充收入分析等角色，继续扩充团队。
本站练习，把移动端问题交成一份任务包
本栏目另行设计的虚构练习 · 可用自己的工具完成 · 未作产品实测
这是一款名为行囊的虚构离线清单应用。练习只使用下面的模拟数据，目标是写出可交给设计和开发人员的任务书。现有材料没有源码或原型，因此本轮交付文档，原型检查留待后续执行。这里不对应真实用户。
先准备这些材料
版本均为 0.3。Android 有一百二十次去重的新建页会话，其中七十二次保存成功；iOS 有八十次，其中五十六次保存成功。保存统计只计算同一会话内的首次完成。 反馈 T1 为 Android 小屏输入时，键盘挡住保存按钮。T2 为 iOS 切到后台再回来，输入内容还在。T3 为 Android 收起键盘后，保存按钮可以看到。 本轮没有页面截图、源码或可运行原型。任务书需列明后续所需材料；原型到位后，建议安排三天、最多两轮本地检查，预算为零。此处仅制定计划。
01先把算得出的结果写清楚
请分析角色分别计算两个平台的保存比例，结果应为百分之六十和百分之七十。把 T1 与 T3 放在一起，提出键盘遮挡值得检查的假设。两组比例差异不能直接证明原因，反馈里也没有提供受影响会话数量。
02给设计和开发不同的交付物
写给设计的任务要求在取得页面资料后，画出键盘展开与收起的两种状态。写给开发的任务先要求取得源码和复现环境，再核对保存区域。两份任务都引用 T1、T3，并列明尚缺的材料，不把 T2 的内容保留行为误当作故障。
03把后续验收写成可执行的清单
在待执行清单中写好动作，原型可运行后，输入三项行李，在最后一项展开键盘，检查按钮可见、可点击且保存后内容保留，再收起键盘重复。为设备型号、系统版本和实际结果各留一栏。当前每项都标待执行，不填写模拟通过结果。
04检查任务书是否足够交接
让两位接收者只读任务书，分别指出第一步需要谁提供什么。设计任务应能找到页面资料的缺口，开发任务应能找到源码与运行环境的缺口。把这些前置条件补进交接表，写明材料到齐后才安排三天内的两轮检查。交接内容核对后，本轮文档练习即结束。
交付后这样核对
应交付比例计算、带反馈编号的假设、两份任务书和待执行验收表。页面资料、源码与运行环境列为前置条件，所有原型检查仍未执行，不附虚构截图或测试结果，也不报告用户效果改善。
把这段提示词带走
配合上面的虚构材料使用，也可以换成你自己的任务资料
为虚构离线清单应用行囊准备任务书。0.3 版 Android 新建页会话120次、首次保存72次，iOS 为80次与56次。T1 Android 小屏键盘挡住保存按钮；T2 iOS 后台返回内容仍在；T3 Android 收起键盘后按钮可见。材料没有源码、页面或原型。计算比例，提出待验证假设，分别写给设计和开发的任务，列出所需材料及后续验收清单。原型检查全部标待执行，只交文档，不声称已检查布局或改善用户效果。
- 比例差异没有被当成因果
- T1 与 T3 支撑待验证假设
- 缺少原型的检查全部标待执行
先让一项发现能交给下一位执行者。