背景
在滴滴工作的时候很多老板强调owner意识，同学们在晋升时也会重点讲自己owner的项目。那么如何做一个合格的owner？
什么是owner？
在不同的层次下，owner具备不同的含义，但都是承担总体职责的人。这里以一个研发的视角来划分。
团队owner
一个实体组织的负责人，负责整个团队的人力安排、方向规划以及绩效考核。核心指标是团队KPI，因为是管理者的范畴，所以这里不班门弄斧了。
方向owner
一个工作方向的负责人，例如应急响应团队的自愈，在这个方向上
- 具备足够的技术设计能力以及优雅的代码编写能力（这是基础，一定是先能干漂亮的活）
- owner需要制定方向发展路径（什么该做什么不该做以及什么时候做）
- 要对小team中同学的成长负责
- 要具备在横向团队中一定的影响力和推动能力
项目owner
一个项目的负责人。在职场生态中，后端的RD在项目组中也一般会承担项目负责人的角色。即使PMO也不可能介入研发测试的具体工作。本次将重点讲述此部分内容。
合格项目owner的工作流程
如果一个研发，尤其是应急响应团队的研发，是项目owner，那么需要具备哪些能力，做那些事情呢？
可以从项目的全生命周期来具体说明。
1 发现问题并定义问题
所有的项目都是为了解决问题的，这些问题可能来自业务的需求，也可能来自用户反馈和自身痛点。在该阶段需要做的事情可以拆解为几步
- 问题和需求搜集
- 思考本质，用户的需求是不是一个真实需求，是不是有其他更好的方式解决？
- 聚类，将零散的需求点分为不同类别，力求解决面的问题，而不是单点问题，并能形成清晰的产品模块雏形。
- 定优先级，哪些是雪中送炭，哪些是锦上添花。
- 需求的可行性分析，包括大致的技术依赖，上下游能力以及研发资源等。
- 产出BRD（需求文档）并得到业务方、老板以及研发人员认可。
2 产品设计
在BRD的基础上，进行PRD（产品文档）设计，将BRD需求转化为产品语言，步骤如下
- 需求分析，并定义产品框架和主要流程。
- 产出原型图：包括操作场景描述、操作行为描述、操作交互等
- 沟通UI同学产出设计稿。
- 产出PRD并通过评审。
3 技术方案设计
技术设计者在前置需求评审和产品评审阶段就需要提出自己对于产品的见解并考虑大致实现，对于不合理需求、难实现需求应及时提出异议并告知风险。
设计阶段要做的事情简单来说就是将产品语言转换为技术语言。具体步骤如下
- 充分理解需求，力求不遗漏任何一个点
- 技术选型，包括框架、存储、核心算法等。
- 文档编写
- 团队内部评审、TC评审
个人觉得一个好的技术方案不在于使用了多个艰深和高大上的技术，而是以严谨的构思、丰富的细节、朴实的语言最大化的避免后续开发和维护过程中的不确定性。
最直观的判断标准：研发人员能否根据你的技术文档流畅的实现？最终代码呈现和方案有多大的偏差？
需要着重关注的几个不确定性因素
- 各种下游依赖的当前能力和需要支持的内容、排期
- 各种异常情况的出口和处理方式
- 存储数据量的预估
- 项目的风险点（排期、稳定性等）
4 研发联调阶段
一般而言，此阶段的时间通常是最不够用的。。需要比较强大的项目把控能力。
主要工作
- 按时完成代码开发以及各方联调
- 定期追踪研发进度、反馈风险（周会或日会形式）
- 沟通决策解决前置产品技术设计中的不确定性问题
主要标准
- 符合编码规范
- 通过组内CR
5 测试阶段
进入该阶段后，主要是QA介入，研发修复bug。标准是QA同意准出。
最常见的问题是初期bug太多，修复起来没有头绪。这时项目owner可以采取非常手段，包括但不限于
- 问题分级
- 封闭开发测试
- 强追踪到责任人（例如半天review一次bug列表）
同时，在测试阶段，需要提前梳理上线工作的checklist
- 前后端机器资源
- 基础产品资源，包括但不限于数据库、MQ等
- 下游各环境地址
- 接入相关工作
- 上线顺序以及检查标准
此工作非常重要，否则很有可能延误上线时间。
6 上线&验收
在QA发出准出后，需要对照上线手册进行逐步操作，并及时处理上线过程中的问题。上线完毕后check服务和数据状态。
内部核验后发起用户、产品和业务方验收，并针对相关反馈快速迭代。
7 产品通报和用户推广
产品通报
1）同步需求方，重点推介
2）标准：发送产品通报邮件；重点用户沟通
用户推广
1）新产业重点用户推介
2）存量用户导流、迁移
8 搜集反馈&迭代
通过不断的用户意见搜集整理后形成一个个单独的迭代版本，不断循环往复。到此一个项目的周期结束了，但是一个产品的周期才刚刚开始～ 接下来的owner就需要考虑一个方向负责人该做的事情了。
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
