《网易一千零一夜：互联网产品项目管理实战》总结 五

数据

ps：终于说到本行了。。。

• 没有数据支持的决策基本上都是凭感觉和拍脑袋。
  正所谓，无量化，不管理。

• 每个产品的数据指标：
  确认产品明确的核心业务指标，再定义各功能的核心数据考核指标

• 提高成员对数据的敏感度：提高大家对数据的重视程度；提供大家可见的数据。

• 解决埋点数据透明性的问题：每个需求负责人都要查看本次改动的部分之前的埋点数据是怎么样的情况。

• 开一次数据收集埋点的培训动员会。建立埋点的流程。

• 当前版本需求确认会 -> 发出埋点需求稿@需求负责人 -> 意见反馈阶段
  -> 埋点统计稿确认后上传指定工具 -> 进入开发阶段 -> 当前版本提测 -> 提供调试版
  -> 策划埋点验收完成 -> 运营& DA 验收完成 -> 版本发布

• 计划阶段：需求负责人确定需求的同时需要提数据需求，根据要收集的数据，确定需要通过何种方式收集。根据数据埋点标准模板提交给数据组同事进行审核，用于确认数据收集埋点的合理性及格式。确认无误后提交开发进行确认和埋点。具体表格见附件。

• 执行阶段：各端开发根据埋点需求文档进行埋点。

• 验收阶段：测试阶段：需求负责人进行验证；上线前，通过平台查看数据收集埋点的情况，做二次确认；上线后，需求负责人观察线上数据是否有异常。

• 对所有的运营活动、推广合作、新产品上线指定出上线后一个月内的线上数据表现情况、客服反馈情况的闭环反馈和评价机制。

• 项目上线一个月后的数据分析会上邀请全体项目组同事进行线上数据分析（销售额、PV/UV、新用户数、复购率等）

---

需求

• 判断需求优先级的重要标准：产品当前的重心是什么
• 排需求优先级：如果这两个功能只能完成一个，我会选择什么。用这种方法来区分需求之间的优先级。
• 我们通常缺乏从用户的视角来检验产品。
• 负责项目时：强化整体视野/责任；培养用户视角
• 设计产品时，第一个问题首当其冲，我们的目标是什么？
  eg：当前最缺的是用户规模。于是将目标收敛在产品用户总数和用户活跃度这两个关键指标上。
• 进一步规划：
  • 列出所有相关的工作；
  • 针对每项工作，按转化逻辑，计算出可能带来的注册用户数逻辑；
  • 按预期，对工作进行排序，指定具体责任人负责推进。
• 有些新事务，我们一开始无法预估他的价值，会选择快速去尝试，快速看结果。如果值得做，就再来一轮优化；如果不值得，立马终止。
• 每项事务，都必须有完整的目标。
• 产品，或许，因一个创意而产生，但是，它却需要至少5000个创意去发展和成长。
• 从做事本身的过程中找到内在的愉悦，恰恰是优秀与卓越最大的分水岭。
• 立项过程中，靠的是知识和思维，加之敢于开拓的魅力。

---

敏捷&团队

• 敏捷背后的关键：目标，人和过程
  目标导向
  始终关注人
  过程应该是透明而灵活的
• 里程碑规划+迭代的管理思路，期间穿插进行三次评审：策划需求评审，交互/视觉评审和上线评审
• 1个人两天完成的工作量往往大于两个人一天完成的工作量
• 一般项目都有关键约束因素和浮动约束因素
• 团队真正的凝聚，来自团队一起工作。
• 加班并不是可持续的常态，关联的是时间的投入，并不是真实效率的提高
• 相比于固定迭代周期，应该更看重需求在迭代内的完整实现。
• 开发阶段，通过燃尽图，持续跟踪开发当前剩余的工作量。燃尽图，用来呈现实际情况与理想情况的偏差，可以提示我们风险的存在。
• 提交测试时，可以采用分批提交，也可以按功能提交。为了控制剩余bug的数量，一致采取了分批提测的方式；令bug得以在更早的时间被挖掘出来，也更早的被解决。
• 多项目并行，不仅会导致多任务切换的额外成本高，还导致团队在任何一个项目上都没有归属感，也会增加计划之间的牵绊，导致计划很难制订，并引起一些连锁反应。
  • 解决方法：按团队进行划分。项目团队主要承接项目需求，支持团队主要承接每日来自线上和用户反馈的开发任务。
  • 减少成员的并行项目。每个人都有一个投入超过60%的主要项目。
  • 进行固定长度的迭代方式。
  • 审视项目的优先级。
  • 强化计划过程。

没有结果的过程是无效的，没有过程的结果是垃圾。