企业为什么想要进行绩效管理？
为什么企业需要做绩效管理？绩效管理背后的目的是什么？企业家们一般都会这样回答：我们希望充分挖掘每一位员工的潜力，发挥他们最大的能力，助力企业获得发展，同时，他们也能不断成长进步。
开发团队又是怎样一群人？
在互联网、高科技行业的发展中，这些大佬起到了至关重要的作用，他们是一个团队的团魂！
现实中他们一言不发，在代码的世界重拳出击，用魔王的语言让我们见证一个又一个奇妙的产品。
在这样一个需要创新需要无限多想法的团队中，每个人主动为自己的目标负责，不断为实现目标而努力才是最重要的，才能体现绩效管理的本质。
但是事实上，很多企业对于开发团队成员，依然用KPI绩效考核代替绩效管理，不切实际的生搬硬套式的管理，严重限制大佬们的发挥，非常不利于企业的发展。
提一句：绩效管理是一个整体的过程，而绩效考核只是其中的一个环节，下面这张图可以充分体现二者的关系。
在讲如何做之前，我们先要弄明白当前开发团队进行绩效管理的问题出在哪儿，方便对症下药。其实也不外乎以下这几种：
一、团队缺乏好的激励机制驱动他们去了解客户的需求，做出市场需要的优质产品。程序员每天都在自己的世界埋头搬砖，不抬头看路，不知道甚至不愿意知道用户真正想要的是什么。
二、部门间难以协同，工作效率和工作质量低下。
我们会发现，开发团队单个部门的工作效率很高，一旦配合起来就会很别扭，没有人关心产品最终的呈现是什么样，只关注自己的工作有没有完成。其实这是团队工作不透明导致的，大家各忙各的，没有人关心最终结果。
我们要知道开发团队需要前端开发，后台开发、ios开发、安卓开发、UI设计、测试工程师、产品经理等多个部门之间密切协助，才能做出一款响应多方需求的好产品。
三、当前的KPI绩效管理难以量化他们的工作，无法真实反映他们的贡献。
在这个管理模式下管理层过分纠结于如何把他们的工作强制量化以方便考核，比如说：bug数多少？功能数多少？代码写了多少行？有无加班到深夜？
这些指标对于一个开发人员来说是非常不合理的，毕竟谁不写几个bug呢？对于他们来说，真正研发一个好的产品出来才是正理，这种强制指标的管理实在有些本末倒置了。
开发团队的大佬们既然是团队的核心，那么选择好的管理办法也非常重要
我们是如何用OKR来解决这些问题的呢？
一、共同参与、上下对齐，全员聚焦主要目标
OKR强调共同参与，从制定OKR到执行到复盘、全员参与，每一个成员都清楚团队的目标是什么，管理层明确该倾斜什么资源和人力给哪个重点项目，成员明确自己需要做什么来支撑团队目标的实现。
制定OKR目标时，自上而下和自下而上相结合，共创共识，上下对齐。源目标OKR通过目标地图可以非常清晰的表现成员的对齐关系。
每个人的OKR都能被查看，公开透明的工作模式，让开发团队的大佬们实现完美的对接，程序员通过用户运营的数据可以更清晰的知道用户需要什么，做出更贴合市场的产品。
二、打破部门壁垒，实现高效协作
上面提到了，开发团队的部门部门多，协作困难，大家各想各的。但是在OKR的目标管理中，大家的目标一致，都是奔着产品最终上线去的，其中任何一个环节的影响导致产品完成上线，那么大家的目标就不算完成。大家是一个共荣辱的整体，必会齐心协力。
在源目标OKR的项目任务中，如果需要其他部门的人协作，只需要简单@他，他就与你们这个项目共存亡，不断贡献他的价值。
三、合理的绩效评价，真实反映每一个员工的价值贡献
开发团队是需要灵感、创新、不断探索新思路的团队，固化的绩效指标不仅限制了他们的发挥，也不能真正反映他们的价值贡献，从而让他们的的工作失去动力。
在源目标，主张OKR与绩效弱挂钩。
在绩效考核时，分为OKR完成部分和评价部分。二者在绩效考核中所占的比重是灵活多变的，根据每个部门的的工作性质灵活设定，在周期伊始就由团队确定好，周期结束之后具体执行。
对于评价环节，我们可以具体说一下：
360度的评价包括自评、互评、上级评，上上级评，评价的对象管理员可灵活选择。评价的综合得分就是这个周期评价部分的总分。
在评价的环节，管理员可以根据不同需要设置每个单位评分的权重，就也避免了仅上级评价分数过高或者过低的现象。多维度的评价，能更公平、客观的衡量成员的价值贡献。
从上图可以看到，我们能灵活调节每一个评分单位的比重，如果团队的团队协作能力不是很强，可以适当调高同事评分的比重。
即使一开始是出于个人利益的驱动才积极配合团队其他成员的工作，后期也会因为尝到了团队协作的甜头而变得更加积极。
个人评价主要是针对这个周期的工作进行一个反思和总结。
互评、上级评和上上级评，就是看这个人在周期内工作的完成情况以及对公司所创造的价值是多少。
最后，想要照顾好开发团队的大佬们，让他们可以安心搞产品搞研发，选择一款简单实用的工具也很重要，坚决不给大佬们添麻烦。