现存问题
管理者
- 由于管理者(特别非开发部门的,需要对开发进行成本、效益考核的管理者)的工作方向及重点的不同,难以时刻对日益更新的新技术以及技术实现过程保持深入的跟进。造成对团队或项目进行管理的时候无法清晰的把握绩效。
- 盲目制定或照搬的KPI管理办法(代码量、bug数、加班时长、营收、服务等级协议、NPS等等),难以公平、全面的涵盖复杂的业务逻辑或流程,造成评价结果准确度低且容易打击成员积极性,导致开发人员、管理人员怨声载道。
开发人员
- 不清晰或不合理的绩效办法容易造成员工的猜忌或怨气,难以全面发挥成员能力,导致项目结果不尽如人意,最终形成项目成果差及员工态度差、成长缓慢的恶性循环。
- 开发人员盲目遵从各项指标,专研指标的完成而不尊重用户体验或满意度,只为完成指标而脱离用户需求,最终只会得到用户不满意或凑合的产品。导致整个项目“忘本”。
团队之间
- 不合理/不合适的绩效管理只会让研发团队的指标往往与业务团队的指标大相径庭甚至形成冲突。最终造成团队内耗、沟通低效、生产低效、成本增加等结果。
目的
- 合理考核成员
- 用户满意度优
- 团队执行力强
- 团队凝聚力高
- 团队使命必达
- 团队自驱动
- 团队自学习
- 团队有活力
- 团队开放透明
前辈经验
- 软件开发是智力工作甚至是艺术创造活,团队内更追求合作而不是竞争,对于创造性的工作盲目强加绩效指标只会打击员工的积极性,从而抑制优秀人员的发挥。追求竞争/有标准流程和模式/例如传统手工制造的劳动密集型工作更适合讲求KPI,相反的,创造性的工作更应该关注和重视的是每一个人,一味追求KPI只会适得其反。
- 不完全理解各类评估方式或指标的前提下切勿胡乱应用,这种时候贴近技术团队的管理者直接人为决策往往更靠谱。
管理方法
OKR
OKR起源于英特尔公司,后来经谷歌、Zynga、领英、GeneralAssembly(硅谷知名的创业教育公司)等公司使用后,它实现了持续高速的增长。在这里,O表示目标(Objective),KR表示关键结果(KeyResults)。目标就是你想做什么事情(比如,上线一款游戏),关键结果就是如何确认你做到了这件事(比如,一天2.5万下载量或一天5万美元收入)。
OKR主要解决目标聚焦问题,我们在工作中往往面临容易分心的场景,无论开发人员、管理人员个人还是团队、部门乃至企业,都会有各种各样让人分心的场景,这就容易造成工作的“跑偏”或者“走弯路”,导致成果大打折扣。
“KPI的实施本身并不反映管理⽔平的⾼下,但是低劣的管理⽔平有⼀个共同点,那就是管理者试图把KPI和薪酬直接挂钩,美其名⽈:结果导向的管理。他们认为只要制定出⼀个KPI,根据KPI决定薪资和奖⾦就⾼枕⽆忧了。美国⼈在批评绩效主义的时候⽤了⼀句玩笑话:“You get what you measure",他们就信以为真了。如果真的You get what you measure,你⼲吗不直接measure税后利润呢? You get what you