2.13. Goal

目标的意义:

  • 可以将模糊的授意或导向具体成可执行、可拆解甚至是可衡量的目标;

  • 评估项目的可行性,标识出关键环节和风险环节;

  • 统一项目所有成员对工作方向或价值的认知,保证全体成员同时朝一个方向努力;

  • 将项目成员之间的工作进行串联,形成协同效应。

2.13.1. OKR目标管理法 6

目前,国内外常用的目标管理方法是由英特尔发明,在Uber、谷歌、LinkedIn等公司成功推广的OKR,即目标与关键成果法。

OKR是一套严密的思考框架和持续的纪律要求,旨在确保员工紧密协作,把精力聚焦在能促进组织成长的、可衡量的贡献上。

使用OKR做目标管理主要分为三个阶段:目标制定、落地执行、结果评估。

  • 目标(O)回答的是“我们想做什么”的问题,是定性的;

  • 关键结果(KR)回答的是“我们如何知道自己是否达成了目标要求”,是定量的。

2.13.1.1. 目标制定

企业可参考长远目标,将整体经营过程,按照工作性质的不同、时间安排的先后次序,分解成若干相互关联的阶段,分阶段逐步实现长期目标。

目标先行,然后将目标自上而下拆解,将项目与目标对应,不同级别的目标对应不同的项目(一个目标可对应多个项目),最后确保每个项目都有明确的目标。

2.13.1.1.1. 满足SMART原则

Specific(明确性):目标必须是明确的,不能是模棱两可或含糊不清的,比如“优化客户服务意识”就不是一个明确的目标。 Measurable(可衡量):关键结果必须是可衡量的,可用于衡量的方法有:基线法、里程碑法、正向度量法、负向度量法等,如“用户留存时间从60分钟提升为80分钟”就是一个可衡量的关键结果。 Attainable(可实现):OKR鼓励在设定目标时具有一定的野心,但也要考虑可实现的,不能天马行空设定一个无法实现的无意义目标。 Relevant(相关性):公司级目标要跟公司的战略对齐,部门级目标要跟公司目标对齐,个人目标要跟部门目标对齐,这样才能确保全员目标聚焦。 Time-bound(时限性):没有时间限制,目标的制定就失去了意义,在OKR实施中,时限性体现在周期的设定上。

2.13.1.1.2. DUMB

  • 切实可行 (Doable)

  • 易于理解 (Understandable)

  • 可干预可管理 (Manageable)

  • 正向的有益的 (Beneficial)

2.13.1.1.3. More

可优化性,并能迅速解决现有的问题,并且无论是短期需求还是长期发展,此方案都可应对。

2.13.1.2. 落地执行

目标的具体执行需要落地为一个个具体的项目,每个项目都会包含若干任务,因此,目标的最后执行是在任务上,只是我们将具有相同目标的任务聚合在一起,放在同一个项目中进行管理。

2.13.1.3. 结果评估

每个周期末,全员需要对本周期的目标完成情况总结、评估并打分。

  • 周例会:每周例会评估本周目标的进展情况,以及关键结果的风险状态。

  • 季度中期审视:要确保目标在季度结束时完成,建议在季度中期对目标进度进行审视与评估,以便今早的找到可能存在的风险及解决方案。

  • 季度末评估:在季度末的评估会议上,需要回顾这一季度目标的完成情况及最终的评分情况,最佳的得分应该在0.7分上下。在这个评估会议上需要回答好两个问题“做到什么程度”和“如何做到这个程度的”。

负责人对目标完成情况打分可能只需要几分钟,但是更多的工作应该是在员工大会上:

  • 集体讨论以及回顾本周期目标的执行情况;

  • 激励有野心的,优秀的成员;

  • 对执行过程中的问题进行汇总;

  • 为新一周期的目标制定提供参考。

2.13.2. 产品经理的工作目标 3

产品经理的工作目标是帮助用户创造价值,帮助公司创造商业价值,而不是把工作定位成编写产品文档,画产品交互设计图。

2.13.2.1. 太关注产出

把产品带来的产出排在第一位,比如做这个产品功能能带来多少新用户,做那个产品功能能带来多少消费用户的转化等。

2.13.2.2. 感知用户能力弱

如果一个产品经理只是在工作的时候讨论需求,在回到家后只是在产品有故障时才关注一下,那么肯定没有大的发展,即便已经做了组长。因为他缺少对用户的感知,缺少对产品做到极致的追求,缺少发现产品亮点的眼睛,把太多时间放到了生活、娱乐,但是又没有从中锻炼出用户同理心、对用户需求的敏感度,只能谈一些似是而非的产品理念,不能够深究。

2.13.2.3. 沟通能力差

如果一个产品组是用表格写产品需求的,那么说明这个产品组的层次非常低,这并不是文档格式的问题,而是一个团队的产品文化有问题。产品经理的工作绝对不只是把粗糙的交互设计图放在表格的左边,随便写几个产品流程的判断条件就可以交给开发同事了。

很多语句读起来不通顺,只有在产品需求评审会上逐一讲解,其他人才能理解,大大增加了沟通成本。产品经理要能够讲清楚技术方面的前置条件和后置条件,还要能够讲清楚这个页面的主要功能诉求、最希望用户怎么操作、是怎样通过交互设计和文案设计引导用户的(包括如何引导用户的下一步动作,比如图1-9显示在用户获得奖品后,只有一个“确认”按钮,并且让用户去分享)。在产品文档中还需要加入更多的异常流设计。

2.13.3. 清晰的学习的目标

  • 可行性:这个级别的产品经理要能对一个需求或问题给出高可行性的解决方案,大约是市场上的P6级,小领域的熟练执行者

  • 创造:要能为一个需求或问题找到最优解。这需要不断洞察环境、用户的持续变化和趋势

  • 权衡:能跳出单个需求,从全局角度考虑权衡取舍。即使一个需求为真、可行、有最优解,最重要的还是决定当下要不要做,分配多少资源做

  • 变迁:能跳出当下,对世事变迁敏感,对需求或问题做决策时,形成习惯性地预判(并反思自己的判断是否正确)能力

  • 方法论:这个级别要求有成体系的优质方法论输出。这个层级主要是追求“影响力”和“确定性”

2.13.4. AI 产品的目标

目标不应该是与领先的互联网公司竞争,而是为你的垂直行业部门赋能人工智能。 5

2.13.5. no code1

So as long we need to code, we failed that because 99.8% of the world can’t code. The main goal would be to get to a point where it’s not a library but a piece of software that doesn’t required code. It certainly shouldn’t require a lenghty hardworking course like this one. I want to get rid of the course, get rid of the code. I want to make it so you can do usual stuff quickly and easily. That’s may be 5 years, may be longer.