技术管理三板斧之第一板斧拿结果-定目标

一、现状：

去年年底今年年初，帮助一家公司做了一次大的系统重构，30多小伙伴，经历一次洗礼，对产品定位，技术选型，目标制定，任务分配，协同开发，测试上线，数据迁移等有一个清楚的认识，同时很多小伙伴因综合素质的提升，升为管理岗，但是被各种产品需求会、技术方案会、汇报会搞得焦头烂额，然后还要安排团队成员的工作，协调跨部门协作的事务，失去了 Coding 的“硬核时间”，忙得晕头转向，能力不但没得到提升，最终交付的项目也没有得到老板的肯定。

在没有介入管理职能之前，每个人管理好自己就可以了，需要考虑的都是围绕自己的事情，方向和维度都比较垂直。角色转变后，从解决自己的问题变为要解决团队的问题，要解决的问题也由单点变成多点，在这个过程中，你很容易抓不住核心点，最终取得的结果自然会跟预期产生偏差

这个过程中，每小伙伴的目标都是团队leader帮大家定的，放手给他们做的时候，就失去方向，那怎么才能确定目标呢？为了回答这个问题，你要知道“定目标”的三个关键步骤：怎么解读目标、制定目标、传递目标。自上而下确定目标，自下而上完成目标。

二、怎么解读目标？

解读目标就是要确保自己做的事儿和公司的方向一致，顺势而为，没有走偏（这里的“势”就是公司的战略和目标），正因为有了目标才有根据目标制定的 KPI，才会有围绕目标的执行动作和最终取得的结果。

1.公司业财一体化：目标是把账算清楚

2.智能化：目标：提高效率，降低成本

解读目标有一个具体的流程，会将使命、愿景、价值观作为内核驱动，结合目前的公司状况形成战略，各 BU、部门根据战略拆解自己的组织目标，然后目标逐级拆解并下发，最终形成各部门可衡量的 KPI；接下来进行执行环节，最终以结果交付进行考核验收。

不过，这对于研发 TDL 很有挑战，因为要解读业务并且做好技术与业务之间的平衡。而且“业财一体化”又比较虚，当研发 TDL 看到类似的战略时，不知道怎么和自己负责的系统、日常代码建立起联系。不要急，目标不是一句口号，它是一个个层层拆解、递进的过程。说白了，解读目标是把公司的方向变成你的方向，把上一层的问题转变成你可以改变的问题。

你一定要在业务、运营、产品技术团队上进一步拆解，通过一系列的分析、数据、讨论、决策后，这个目标会被拆解为几个可以理解、执行的目标：

1.业务流程标准化，非标准化地处理方案是怎样的

2.运营数据精细化，及时化，日清日毕，特别每天可变成本，不确定成本找到找到解决方案

3.产品针对每一个场景，及时找出解决方案。

接下来就是围绕这些目标进一步拆分，一直到你的团队可以执行发力的程度

根据目标逐层分解的特性，可以考虑四个方面。
你的主管，确定你老板的目标是什么；
你自身所在的团队、团队的成员们，根据团队情况确定现状；
与你紧密合作的上下游（研发），比如你是做订单系统的，那么支持属性很重，商户、导购、用户很多研发团队都是你的上下游关联方；
直接对口的业务与产品，这是业务目标拆解、业务痛点、客户诉求的直接来源方。

在我看来，这四点中主管层是相对比较重要的，主管（代表的是公司层面）作为你以及你团队结果交付的重要裁判，你要完全确定自己和他的目标一致，而且你的信息来源是从上往下得来的，由上而下的信息更加接近公司战略核心。通过反复对焦，将所有模糊、分歧的点都讲明白，讲到你清楚地知道为什么有这样的目标为止。

除此之外，好的对焦一定是有互动的，你要充分去拿到信息，给后面的所有决策作为依据，所以我建议你多了解团队情况、客户需求、上下游合作方的意见，这样一来，在你理解目标、跟主管对齐目标时会有的放矢。

三、怎么制定目标

当你充分解读了公司和上级团队的目标后，就要制定你自己、团队和团队成员的目标了。在这个阶段，核心点就在于把你的方向变成团队、成员的目标。

很多同学会把解读目标当作了解目标的过程，设定目标时继续按照自己的想法或者被其他外在因素影响。而且现实总比理论要复杂一些，因为你考虑问题时会带有主观性，比如趋利避害地按照“去年怎么定，今年就在这个基础上预估一个可以实现的目标来制定目标”这样做虽然不会出彩，但肯定不会出错。

可这就犯了一个很明显的错误，因为制定目标并不是制定自己的 KPI ，而是团队整体的目标，要从整体出发，而且，主管既然赋予了你角色肯定是期望你能做出更好的结果。如果以目前制定的目标为导向，对组织发展贡献的力量就很有限了。

那么怎么设定目标更好呢？ 我认为可以结合 4 个关键点来考虑。

“短长”结合：事情分轻重缓急，你一直盯着“急”和“重”，“轻”和“缓”的事情就会转变成“重”和“急”，进入死循环。所以长短期目标是有关联的，达成短期目标是为了长期规划做铺垫，逐步达成一个大目标，但往往很多同学会注重短期目标，忽略长期目标。
要足够聚焦：一些同学在定目标的时候往往会列出十几个关键问题，觉得把问题都解决掉，团队就“干净了”。可这样做反而会因为资源、精力、时间不够聚焦，导致每一个点都没有解决到位。我建议关键目标不要超过 3 个，最多控制在 5 个以内，要找最有客户价值、对公司战略最有帮助的点，目标越少、方向越清晰，当问题发生或者需要判断时越容易做决策，在有限的时间内做出更好的结果。
要有足够的挑战：系统可用性假如去年是 3 个 9，今年考虑业务会发展保守起见还是力保 3 个 9，这样的目标挑战性就不足，也无法体现技术的价值。这个度量是很考验你的，一旦极端就会出现过犹不及的情况。就好比考试前，你用希望考 80 分的努力可能实际只能考 60 分，但如果告诉你 99 分以下都是不及格，可能你就干脆放弃了。
要让组织有沉淀、个人有成长：很多同学在目标制定特别容易忽略这一点，但其实制定目标的过程，也是一个让成员不断打磨自己的过程。通过一个个目标的完成，让参与的同学得到个人能力的提升，未来可以承担更大的职责，组织也在这个过程做能力的积累与沉淀。

也许你会觉得这四个点比较简单，但是往往越简单的道理，在做起来的时候就比较难。你可以结合这四点，围绕目标和团队一起讨论策略与打法，将目标拆解成几个关键任务，明确到责任人，总结一下就是：定策略、拆任务、细到人。然后结合 KPI 或者 OKR 等考核方式，进一步落到每个成员的结果考核上，目标的达成也就是成果的交付，一定要有考核。不过，需要提醒你的是，KPI 不完全等于目标，它是目标的拆解与落地可执行的指标。

四、怎么传递目标？

在制定完目标之后，就要传递目标了，因为你要让大家力出一孔，有劲儿往一块使。这个阶段的核心是让员工把你的方向和目标变成自己的目标，最终走到同一个终点。

可往往期望和现实会存在冲突，因为大部分的开发者是不关注公司战略和目标的。你不妨问一下团队伙伴看看有多少人能正确且清晰地回答出下面这些问题：

公司今年的战略是什么？
你所在的大部门重点项目是什么？
你们小团队的 KPI 是什么？
你老板的 KPI 是什么？

很多人都回答不上来，或者回答得不准确。原因有两点，一个是很多Leader 根本没有意识到要传递目标，默认确定目标之后，大家都知道了；第二个原因是很多同学只是单纯地复述目标是什么，但是却没有强调目标是怎么来的，没有把目标和团队成员的获益点关联起来，让团队成员了解自己的 KPI 为什么要这么设计。

大部分情况下，你会发现信息不对等、传递过程中的损失、个人理解的差异，直接导致不是所有人都清楚“我们要往哪去”。
我以前也犯过类似的错误，当我察觉到很多同学对部门目标不清楚时，发全员邮件、组织全员大会、Review 大家的 KPI 设定这些事儿我也都干过，但是收效甚微，原因在于姿势不对。

首先这些沟通方式有距离感，不利于我与大家的情感传递，也没有营造出一个轻松接收大家反馈的场子；

再者我只是告诉大家有这样的目标，而没有讲清楚这些目标是怎么来的，这些结论背后的思考、 Why 我没有很好地讲出来。因此大家光看一个结论自然难以理解。

那合适的传递目标的方式是什么样的呢？我建议硬传递和软传递相结合，注意场合和时机。
刚刚我提到，我会用邮件和全员大会的形式进行目标的传递，但是效果并不好。不过这也要结合你自己团队现状，在一些必要的情况下，你其实是需要这两种硬传递的方式来传递目标的，因为你需要有一个公开的场合让全员先知道有这么一回事。
除了硬传递，你还可以在合适的时机组织小的场子去聊这件事儿，聊一聊现在我们团队的目标是什么样的？这个目标是怎么来的，即将面临的困难又是什么，比如在团建里策划这个环节，当然聊得可以自由一些。
最重要的是，我们不要把管理动作神化、复杂化，你可以参照图中这几点来传递目标。