技术团队与OKR

标题是在我思绪乱飞，文不及意的时候改的，原标题是命题作文“CTO的最后一课 第一季毕业设计”的一部分，《技术团队绩效考核机制》，思绪飞完，发现这都是自己的意淫，作为一个基层员工，除了自我管理就是被管理，谈技术团队的管理，未免太不切实际，但是恰是因为自己是被管理的对象，所以在听完CTO训练营整整一季的课后，我想说，老师，我有话要说~

在思考如何激励时，自然想到了CTO讲师于斌平《技术团队如何做绩效管理》中的论述，于斌平老师有着10年以上500人以上的团队管理经验的，观点也是经过了实践的淘洗，有几点很适合我们当前的团队。此处并非拿来主义，更不敢谈英雄所见略同，但是作为基层管理人员，有些point还是可以get到的~

1.     考核预设

统一的价值观，引导，“方向比努力更重要”——CTO讲师于斌平

预设是为了将企业对技术团队，乃至具体到员工的价值期望传达到位，而不是在最后评分的阶段流于形式，对员工评价高，打分低或者打分评价都高，却没有实质的奖励，再次验证了方向比努力更重要的正确性。

2.     采用OKR而非API

    KPI有毒，此言不假，如果设置不当，对团队和个人不能指导就会变成误导了。

    OKR全称是Objectives and Key Results即目标与关键结果，何为关键结果？

 做了几个项目，搭建了几个系统，测试除了多少bug这个是关键结果吗？是，但是核心还不够清晰，有产出是必要的，但是我们忽视了其背后的两个重要的目的，一，对业务带来的收益（此处综合考量成本），二，对技术人员带来的成长 。细化一下：是否纯粹为了bug数量这一指标，在IE6兼容问题上技术争得火热？是不是用合适的技术，高效优美的完成的项目？搭建的系统有没有后续推广指导投入到作业中？等等。

3.     激励策略

那，重点来了，作为技术管理层，这种格局下怎么才能通过管理手段，来打造一支有活力，有战斗力，热血又不轻浮的技术团队呢？以下我从周期，内容，奖罚及关键因素四个方面，来论述OKR的落实：

具体的目标及奖惩机制根据具体人员及项目来设置调整，原则是要能充分调动起技术人员的积极主动性，成果明显，气氛欢快轻松，员工幸福指数高。

另外， 既然是团队激励，那团队的组织结构将密切影响激励方案及方案效果。以下是某司的技术部组织结构草图：

    这种小组划分，优势明显：分工明确，责任到位，各司其职，术业专攻；

    劣势也很明显：工作形式长期单一，组间各自为站，不利于技术交流及发挥整体团队协作的power。

    公司作为较早崛起的互联网公司，积累了丰富的互联网经验，资源及用户；传统业务项目历久弥长，业务形态成熟稳定，技术方面以支持为主；随着互联网的迅速发展，网络的普及，智能手机的大众化，办公移动化等时代的进步，如何突破创新，走出安逸，跟随甚至引领互联网大潮，对企业及技术团队提出了较高的要求；业务先行，技术需提供强有力后盾。

    这种业务形态下的这种组织，貌似是很合理的，但是，员工职责单一，在团队规模不大的情况下，组员成员少，人才梯度小，不能帮扶，不利于员工成长； 时间久了，呈现出两类员工，一类是对业务轻车熟路，对技术熟视无睹（或者感觉当前的工作都在把控之内，无意识也无能力超于自己）；另一类是有追求，也是不能自己完成突破，通常寄希望于环境来改变自己，比如离职跳槽；

    第一类的员工貌似会给公司带来稳定，实则是不求上进的态度（企业和员工都是），试想技术迅猛发展，用户需求复杂多变，这种保守会让企业慢慢的掉队；第二类的员工通常都是有想法，和对自己的投资负责的员工（员工选择企业并为其工作也是一种投资”），能留住此类能自驱的员工，并为其提供成长的环境，形成互利关系，才是健康茁壮的团队面貌。

    组织结构是稳定的产物，这里并不是要打乱当前结构，把团队揉成一团，而是可以结合OKR的形势，在关键事件中，引入“技术指导”之类的概念，担当技术指导角色的通常是来自其他组，有能力的人贡献想法，能力稍差的人在指导下落实实践方案。实践结果都纳入二者的考核范围。（貌似和大公司的师傅带徒弟制度类似，不过导向更明确）。

    至此，好像说了很多，又好像什么都没说清楚，理论是美好的，现实是多变的，但是相信努力不会白费，经过摸索和实践一定能找到适合自己团队的风格。

    本文旨在抛砖引玉，技术成就梦想，让团队更美好！