背景
新晋管理者总是手忙脚乱的。领导管你要技术规划;一堆业务需求提过来了，如何判断做不做，任务应该分配给谁;原来和组里同事都是平级，现在我是领导了，好像有几个人不太服，我该怎么处理呢。千头万绪，第一件该干的事就是设定团队目标。
Why
为什么优先是设定团队目标呢？因为晋升为管理者之后，你就不再是大头兵了，你不再是一个人冲锋陷阵了，你是带着一组人去冲锋了，没有目标，技术人就是工具人，被动接受他人输入。找不到工作价值。没有意义和使命感，工作都是浑浑噩噩的。
没有目标，你不知道你团队需要多少人，应该申请多少hc？团队重心在哪？怎么排兵布阵？
没有目标，就是一堆人拼凑在一起，劲使不到一起。说散就散。没有任何凝聚力。
How
目标设定，业界比较通用的就是OKR,从我的实践经历来看，非常好用。
目标定义
O就是Object，目标。目标的输入来源一部分是技术团队自上而下的拆解，一部分是关联业务方的支撑。如果两个都没有输入，纯自己设定，即无中生有（阿里P8的能力模型）作为新晋管理者，如果你接手的是这样一团队，建议有合适机会就跑路，这绝对是个烂摊子，持续不久。最近互联网公司大裁员，这种情况绝对是第一梯队的。因为技术团队是支撑团队，解决问题的。现在连问题空间都没有，怎么定义问题，解决问题。
目标的输入来自他人，但是定义却是你自己，你设定的目标首先应该是你想去的地方，你想带领团队完成的。
目标调整
作为技术，经常头疼的一个问题是业务经常调整来，调整去。刚设定好的目标，过了2月就变了。之前的设定都白费了，所以有些人就想干脆别设定了。这样就是因噎废食了。业务经常变，那我们就在其中找不变。找底层逻辑。比如业务开发团队可以设定 代码质量、性能指标、系统稳定性等技术指标。也可以设定提升研发效能、优化系统架构、解决历史债等架构指标。同样作为业务技术团队，还可以设定提升项目管理能力、提高业务sense等指标。把这些作为团队的内核。
但是公司不是白养技术的，技术目标是要围绕业务目标，要不然你述职、晋升时也会被挑战。此外业务不问题，有些员工焦虑感很强，觉得是白忙，瞎忙。觉得代码质量是提升了，但是业务不做了，代码都要下线了。这些工作都白费了。这是很常见的问题，那么如何解决呢？
这个需要从3个方面解决
- 设定技术目标时要贴合业务，这要求管理者必须深入到业务，知道哪块业务有长期价值，是公司重点投入对象，那么你的专业目标也是围绕着这块优先落地。
- 抽象，剥离业务属性，比如我在微服务如何划分一文中介绍的，你的技术目标应该设定在基础能力、核心领域层，而不是在应用系统上
- 和组员多沟通，统一思想，业务的成功不代表技术的成功，技术要有自己的价值，同样业务失败并不代表技术要走人。通常公司某块业务不做了，程序员不会被裁掉，而是调到其他部门。这就是技术人的可迁移能力，不能换了业务就不会做了。学习的技能在新的业务就找不到落脚点了。退一步讲，即使业务不做了，公司裁员了，设定的技术目标也是有利于组员能力成长，能帮助组员去找到一份更好的工作。
目标衡量
目标衡量就是KR，Key Result。限定时间内，完成哪些工作。这些工作怎么被衡量。
KR有什么特点呢
时效性
KR是对O的拆解，是检查和监控我们如何达到目标的标准。所以必须是相关的。KR完成了理论上讲O能完成，但是实际不一定。因为通常O是指引，是个长远目标，指导行动的。但是KR是半年/一年，一个考核周期内要完成的事。
比如你的目标是提升研发效率，当前影响研发效率的可能是应用启动优化。你们组负责的应用有10个，在一个考核周期你可以只能完成部分应用启动优化。你的KR就是完成5个核心应用，启动时长<3分钟，提效50人日。
明确可衡量
所以KR必须要非常明确，不能笼统。比如提高单测覆盖率就不对，必须是提升某某模块单测覆盖率从XX到YY
目标传达
目标设定好了，一定要拉组员一起通晒，而不是直接拆解，让组员负责具体工作。因为团队里每个人都需要非常清楚团队的目标，知道团队要往哪里去。此外这也是一个收集信息的好机会，看看大家有什么困惑，建议，想法，都在一起聊聊。同时向团队成员传达你对团队的期望，统一阵型，打造开放的文化。团队成员了解了整体方向后，在不影响你的排兵布阵情况下，可以让他们适当选择自己感兴趣的方向承接，达到双赢。
