互联网公司产品和技术团队怎么样实施OKR( 二 )
但是，这个问题在产品技术部门可能是个例外。尤其是产品型公司的产品技术团队。一方面是因为产品型公司的聚焦重点经常会发生在产品本身上；另一方面是因为很多互联网公司在产品技术方面遇到的问题和机会都非常接近，以至于我看到不少科技公司在企业层面的OKR设定都非常近似。
先决条件
即便如此，也并非所有的产品技术团队都适合独立引入OKR方法。如果要让这个方法在企业中发挥出成效，不产生部门本位主义，那么这个团队要符合以下这些特征：
1）产品技术团队能够对产品的设计、开发和交付整体负责；团队具备主控性，而不是受制于多个部门的配合；
2）非项目服务业务模式，产品技术团队服务的是本企业的产品，而不是客户的产品，否则这个团队的核心管理体制很难超越项目管理本身。而且外包项目的生命周期也不足以来激励OKR的实施。
3）公司的业务成效很大程度上取决于产品本身的定位、特性与市场需求的适配度和产品质量；销售和营销职能起的是放大器作用。消费者应用领域的公司大多符合这个条件。如果是2B的产品则要视情形来看。
同时，这三个基础条件也决定了产品技术主管一般都是公司的核心管理人员，对公司的资源分配，协调其他部门的工作能够起到关键影响。
如果以上提到的先决条件不存在，那么这样的团队独立实施OKR的成效是不乐观的。实际上，如果缺乏自治度和管理关注度的产品技术团队本身也很难有动力来自行发起目标管理。即使做，一般也只是为了响应公司从上至下的管理要求而已。
常见的产品技术部门OKR类型
当我辅导了十家科技企业的OKR制定沟通会议以后，我发现这类企业的OKR选择有非常明显的规律。团队相对容易达成一致的目标意图（Objective）大体会分成这么几类：
1、产品特性交付里程碑
这可能是最常见的目标之一。产品技术团队因为担负交付产品和特性的责任，所以容易有这样习惯性的思维——本季度发布xxx特性，交付2.0版本产品等。
在这个动因下，产品技术部门设定目标要有更清醒的头脑和更整体的认知。为什么要交付2.0版本？2.0版本主要解决的问题是什么？除了形式上的交付，用什么KR能够更好地定义交付成功？一个好的产品交付目标应该揭示背后的商业意图。比如：“通过2.0解决客户自助部署问题”，“通过3.0解决合作伙伴增加销售选项”就是更加完整的目标描述。
正是因为如此，这类目标所配套的关键结果（Key Results）也要能够反映出意图达成的KPI（请中性理解这里的KPI含义）。发布时间本身不应该成为KR，发布后能够形成的一个关键数据指标才是。比如上面“通过2.0解决客户自助部署问题”的Objective可能需要配套一个KR：自助部署页面的UV数量，它反映了这个特性交付带来的客户价值，每有1000个UV，说明可能有1000个用户得到了自助部署系统的帮助。在第二个例子中，合作伙伴销售中新产品的占比可能是一个有价值的KR。
在产品特性交付目标方面，我还经常发现一个常见困难，就是每个季度的OKR周期很难保证一个大宗的产品特性交付彻底完成，更加不要说获得使用相关的数据。这时候，我们就需要定义更加细分的里程碑，而不是一个版本的交付，比如“完成单元测试”、“完成数据架构设计”等。
2、提升开发和运维质量
在产品型公司的早期，因为经验和能力的原因，在产品开发和运维过程（devops）中存在大量缺陷。有一些质量问题也可能是因为“MVP”理念导致的。这些可能都是创业公司不可避免的阶段。
但当公司开启了商业化进程，建立了专门的销售团队，低质量的产品会消耗巨大的营销投入，不仅无法转化满意的客户，而且会让整个团队士气低落。
但站在公司的角度看，刚刚建立了销售团队，管理层的注意力通常被牵制在销售团队的形成和管理上，有时候是难以顾暇，有时候是没有意识到产品质量对于提高销售效率的重要性。与其等到部门之间相互指责和推诿，有全局观的CTO应该尽快聚焦在提升质量的目标上。在达成这类目标时，产品技术团队的自治能力至关重要。
推荐阅读
- 长春评选“网络奋斗者”：互联网成更多普通人创业工具
- 旅行社@旅行社推出“高铁+旅游”新产品 高铁旅行说走就走！连淮扬镇高铁全线通车
- 广西鹿寨贫困户玩直播带货变身创业新星以电商帮老乡卖滞销农产品
- 黄金时间■黄金时间丨哪种产品最节水？购买产品请注意这个标识！
- 货币等各类金融产品彻底电子化会到来么
- 互联网怎样解决“家政服务上门速度慢”的问题
- 银行it人怎样转型
- 银行的数据中心可以跳槽去互联网公司吗
- 汽车知识|押宝全新造型，东风雪铁龙新C5能否成为神龙公司“救世主”
- 互联网在线音乐行业有哪些可能的盈利模式