互联网公司的产品运营等工作，如何最快速的交接呢？
相信，这是每一个到新公司的产品运营人员都会遇到的问题
即使新的工作内容与老东家一样，由于工作环境的改变，往往也会一地鸡毛
能够全盘的快速承接新工作，对于产品迭代，项目计划，乃至转正都非常重要
建议从如下方面入手，可以最快速的交接工作
1：态度
有玩笑说，多数程序员都认为前人写的代码垃圾，无时无刻不想推倒重做
笔者接触过的产品人员，有一些也一样：认为前人的需求莫名其妙
即使你上份也是同样的工作，但现在环境不同，产品策略也不尽相同。也许每一个在你眼中“很傻的需求”，背后都跟着一个又一个坑
因此，请先安静的读相关的资料，不要轻易的指指点点。即使发现了问题，也不要上来就一锤定音，免得砸了自己的脚
2：熟知相关人员
拿到邮件，IM工具后，最快速的了解项目相关人员。不要加完好友就完事大吉，建议用如下表格，整理归档
- 原产品人员：获取相关的文档。由于过一段时间他就要离职，所以把握好时间，尽可能多的获取相关资料，需求背景
- 市场人员：最近提出的需求 及 完成情况
- 交互人员：拿到所有的交互文档
- 视觉人员：拿到所有的视觉文档
- 客户端/服务端研发：最熟悉各种坑的人。一定要多聊
- 运营人员：近期需求，运营报表
- 外部资源：如果涉及到了与外部的合作，可以获得合作资料
项目人员
3：在研版本的项目管理
接手新的产品，多处于在研状态了。那么请立即按正常的项目管理流程管理起来。如果新公司有相应的管理工具，除非你非常熟悉这套流程，否则，建议先用表格，成本最小。
如下表所示，注意如下几点
- 交付日期：根据交付日期，倒推各里程碑的时间点
- 明确需求方：这是最容易忽略的一点。当需求有问题时，最靠谱的讨论人选
- 研发功能的拆分：要细致拆分研发任务，以便跟踪进度
- 注意验收：良好的验收，才能确保需求的完成
- 上线发布的闭环：上线发布后，一定要通知到需求方，才能完成需求的闭环
以上三点，就是最重要最紧急的，需要你立即可以接手的工作
下面讨论其它重要交接工作
4：产品及版本信息
除了产品的应用名称，包名，渠道号等基本信息，还要了解
- 历史版本的版本号：都有哪些历史版本。版本号的命名规则是怎样的
- 发版日期：具体的发版时间
- 修改点：每个版本实现了什么功能，修复了哪些BUG等等
- 耦合/依赖情况：与其它模块，OS，系统版本是否有依赖
- 该版本的测试用例：相应的测试用例可以让你更加熟悉该产品。比试用产品更直接有效
产品版本表格示例
5：打点
一般都会有打点的文档。特别要注意的是
- 所属页面/逻辑：打点是属于哪个页面的 或者 哪个业务逻辑
- 触发时机：什么时候上报打点
- 应用版本：在哪个版本上，实现的该打点
每一个打点，都要考虑以上三个问题，可以对打点有更加深刻的认识
打点表格示例
6：漏斗转化
漏斗转化，是分析产品行为，优化商业表现最有力的工具
- 上步转化：当前步骤/上一步骤*100%
- 首步转化：当前步骤/第一步骤*100%
当然，产品不同，用户场景不同，数据指标不同，漏斗也会不会。欢迎各位和我探讨具体的漏斗
漏斗转化
7：渠道信息
很多的互联网应用，都会上传到各大商店 或者 与 广告平台有合作。可以按如下表格记录相关的信息，主要目的是当有问题时，可以快速的找到责任人
渠道信息
广告平台信息
8：产品运营数据
常规的产品运营数据即可，如每版本的日活，留存等，如果是互联网应用，建议重点关注版本分布：明确哪个是主力版本，升级情况
更精细化的数据，可能与产品形态有关。如LBS类的数据报表与文件管理器可能就不同
9：商业化数据
商业化数据要单独拿出来说，毕竟，一旦涉及到商业化，往往都是重要的指标之一。每一个广告位，必须明确如下信息
- 对应用的应用版本：属于哪个版本的应用
- 所属界面：在应用的哪个界面展示广告
- 展示逻辑：什么时候展示广告
以上信息，一旦忽略，往往造成初期数据特别明晰，后期越来越乱的情况
10：我是跑路的那个，怎么最快交接？
请在日常工作中，整理好如上的数据。当交给你的下任时，相信我，他会感谢你的
最后，祝大家都有一个好的前景
PS：欢迎大家关注我公众号，获取最新的产品运营的相关文档与资料
转播
