在创业公司该如何解决技术开发团队的考核问题

时间：2024-10-18 15:58:24 赛赛如何创业我要投稿

相关推荐

　　团队考核即团队绩效考核，就是对团队完成其职责和对工作结果的考评，是对其工作贡献程度的衡量和评价，直接体现出各个层次团队在企业中的价值大小，是绩效考核的核心内容。以下是小编整理的在创业公司该如何解决技术开发团队的考核问题，希望对大家有所帮助。

在创业公司该如何解决技术开发团队的考核问题

　　团队考核存在的问题

　　现在创业公司的技术开发部门其实很难进行考核，无论是KPI还是OKR，我觉得在实际操作过程中都有不少问题，这不是说考核的方法不对，而是我觉得在落地操作的时候并不那么的接地气，那么问题或者阻碍有哪些呢？

　　1、目标不明确

　　这是创业公司都会存在的问题，因为创业公司的首要任务是活下去，所以朝令夕改，边做边调整的情况是司空见惯的，而习惯于瀑布式开发的团队，对于这样的做法做着做着就不行了，关键是开发人员非常反感需求的频繁调整，这对于开发团队的士气也会造成较大的影响。

　　那么有人会说，敏捷开发不就解决这些问题了？是的，在一定的条件下，的确可以解决问题，但是这对于开发人员、项目经理、产品经理，甚至于部门负责人的要求都是非常高的，真正用好敏捷开发的我自己看来屈指可数。

　　2、考核的依据过于主观

　　一般来说，无论哪种考核方式，都是要评估工作量的，但是开发与卖产品不一样，开发人员在接到任务的时候，其实是不知道要做多久的，很可能都是做着做着发现其实需求并不合理，一问业务部分，然后又改了需求，但是修改之后工作量可能就变化了（这个关于工作量的问题，我也是在读《人月传说》时特别有感受），所以大部分的项目都是由项目经理来评定的，万一项目经理的经验不准，或者老板极其强硬的缩短开发周期，那么团队就会死的很难看了。

　　尤其是拼命干了之后，开发人员并没有得到充分的认同，对老板来说可能老板更加相信是自己的眼光和远见，团队越是这样完成任务，接下来任务会更紧，而且变得更加的理所当然，这也是程序员特别苦闷的地方，谁让我们IT人当老板的不多呢？

　　3、考核最终的呈现不透明

　　一般我们IT人员搞开发，大部分还是拿稳定薪水的，毕竟不压榨开发人员，公司哪里来的收益，资本主义的概念在现代开发项目中最有体现，尤其是老板是业务出生的，你跟他说工作量，这个用了什么技术，那个通过什么算法，老板基本都是云里雾里，那是为什么？因为不懂啊，不懂技术啊，因为不懂所以天然就会怀疑，因为怀疑所以并不理解技术人员在完成项目过程中的辛苦与汗水，完成之后，好一点的给个项目奖，但是因为整个过程没有得到最希望认可的人来理解，那么就算完成了还是成就感缺缺。

　　归根结底，对于技术人员开发的考核不透明，对开发人员自己不透明，做的只有自己知道，对外就更不透明，大部分开发人员做出来的功能，其实是没人去用的，处理自己和测试人员，没人知道这个功能有多棒！

　　那么，是不是有什么方法解决呢？

　　有啊，比如：招个特别牛的IT总监就可以，因为人家经验丰富，对于这些问题应该比较了解，通过他再跟老板沟通应该就会好，当然这也是很多企业解决的方法，但问题是，我看到更多的还是CTO是个大坑这样的言论（各位CTO先不要喷，并不针对人，只是存在这种存在情况）。

　　对此，有何方案

　　那么这三个问题，有没有办法解决？目标该怎么定？工作量怎么评估？如何通过考核透明向老板正名？

　　看了《阿米巴模式》之后，我就有了下面的一个实施方案，拿出来大家讨论讨论：

　　由全体人员对工作量进行评估，而不是仅仅由项目经理负责；

　　评估之后取全体人员评估的平均值；

　　选3个开发人员，按照其对于团队的了解，基于平均值进行调整，最后选用最合适的方案，方案使得每个人的工作量最终应该差不多时间完成，而团队以完成最长的那个人评估的工作量作为整体项目完成时间，而方案的拟定人作为这个项目任务的负责人；

　　项目实际开发时，计算个人实际完成和团队实际完成天数，比照原来估计的分别产生个人完成效率和团队完成效率；

　　个人完成效率可以迭代到下一次任务中作为平均值调整的参数，团队完成效率之外可以再提供一个项目完成时的表现打分，仅仅是大家对于开发人表现的打分，其实也可以理解为，大家对于个人在整个项目完成过程中这个人对于团队的共享价值。

　　依次反复之后，会有一些结果，我自己按照上述方法在我自己的开发团队执行了4次，第一次误差比较大，毕竟没有什么借鉴，但是随着一次一次的尝试，一方面团队的人员会比较熟悉这套方法，除了每个人具体评价的值不透明，所有过程都是透明的，公开的，自己都可以计算；另一方面的确有激励的作用，毕竟原先一个人评价20天完成的任务，12天完成了，成就感就非常高（无论是团队内部，还是上升到老板层面），所以解决了上述的一些问题。

　　但是，这个方法本身还存在问题需要继续完善，比如：除了开发其他岗位的执行并不理想、人员太少的情况下不太适合、临时或者突发增加的任务依然还需要靠项目负责人来分配等等，这也没办法。但是，我希望通过团队和大家的努力共同打造一个合适我们IT技术人员的考核方法。

　　高效研发的5个关键步骤

　　第一步：立项——定方向

　　在豌豆荚的整个研发过程中，立项称为ProductBrief或者Project Brief。团队的产品经理会撰写一个1－2页的文档，然后和执行团队进行评审，如果评审通过，立项就成功了。文档一般包含会包含以下内容：

　　1. 愿景：一句话表达清楚要做什么；

　　2.分析市场机会和趋势，决定当前策略；

　　3. 确定目标用户的特征和核心需求；

　　4. 现存的解决方案和各自的优劣势；

　　5. 该项目对豌豆荚的利益点；如果不做该项目，哪些竞争对手会做，对竞争对手的利益点；

　　6. 需要哪些技术的支持和驱动，哪些技术是豌豆荚的弱项；

　　7. 人力需求；

　　8. 项目的紧急程度，是否需要快速推进；

　　9. 发布策略；

　　10.核心衡量指标，用来衡量成功的指标。

　　第二步，OKR 体系——定目标

　　对一个项目来说，设定目标是非常重要的，因为这决定了如何去做，以及能做到何种程度。豌豆荚采纳的目标管理是从 Google 引进的 OKR 体系（Objectives& Key Results，目标与关键成果），这跟传统的 KPI（Key Performance Indicator，关键绩效考核）稍微有些区别：

　　1. OKR 首先是沟通工具：豌豆荚共有 300 多人，每个人都要写 OKR。为了便于沟通，所有这些OKR都会放在一个文档里。任何员工都可以看到 CEO 的这个季度最重要的目标是什么，HR 团队这个季度的目标是什么。

　　2. OKR是努力的方向和目标：OKR代表你到底要去哪里，而不是你要去的地方具体在哪里。

　　3. OKR必须可量化。比如健身时设定锻炼目标，如果只是定义成「我们要努力提高身体素质」，肯定不是一个好的 OKR，因为无法衡量，好的OKR是「今年的跑步时间较去年增加一倍」。

　　4. 目标必须一致：制定者和执行者目标一致、团队和个人的目标一致。首先，制定公司的OKR；其次，每个团队定自己的 OKR；第三，每个工程师或设计师写各自的OKR。这三步各自独立完成，然后对照协调这三者的OKR。在豌豆荚，OKR跟个人绩效没有关系，因为OKR 系统的结果和每个人并不直接挂钩。

　　5. 通过月度会议Review ，时时跟进OKR：在月度会议上需要确定如何去达到目标，是一个帮助达到目标的过程。

　　6. 通过季度会议 Review ，及时调整OKR：互联网的变化非常快，所以豌豆荚每季度有一个OKR 的 review，调整的原则是目标（Objectives）不变，只允许调整关键成果（Key Results）。

　　第三二步，项目管理——控进度：

　　目标设定以后，非常重要的就是执行，一般的项目管理实际上就是控制进度。

　　1. 任务/进度勤同步。整个公司所有人的 calender，包括会议、要做的事情、项目的时间节点都需要及时同步。在整个战略布局上，如果某个项目工期非常紧，就必须进行更多的沟通，确保每一个环节都没有问题。

　　2. 站立会议 (Daily Sync)：每天进行站立会议，一般控制在十分钟之内，每个人说明自己今天要做的工作，需要什么帮助，有谁可以帮忙，可以更有效的调节资源和公关。

　　3. 多方位沟通（Google Docs / Gmail / Hangouts）：对非紧急的事情，两个团队或者是两个人一起讨论所有的设计。Hangouts用于做快速响应。

　　4. 周会（Weekly Report）：每周总结。豌豆荚的团队产品经理要做周报，汇报这周的工作、发布、取得效果以及数据。

　　5. 数据系统：MUCE 是豌豆荚的数据系统，上面有全公司所有的产品数据和运营数据。MUCE 的数据能够用来验证产品的假设、方向等。

　　第四步，人员管理——带团队：

　　项目是由一个个具体的人来执行的，所以带团队非常重要，在人员管理上，豌豆荚有三个基本原则：

　　1、 Re-Organization& 换组：公司鼓励员工换组，每个人都有机会到喜爱的团队做更有趣的事情。只要在原团队的绩效合格，每季度都可申请换团队或换工作内容。员工的绩效不与 OKR 挂钩，公司鼓励员工挑战难度、超越优秀，低 Level 的事情做不到优秀会被惩罚，做事不及格也会被惩罚。

　　2、One on One：在带人方面， One on One 非常重要。One on One 指的是每个团队的 manager 需要定期（最佳间隔是每周一次）与自己团队中的每个成员进行一对一讨论或者对话。在豌豆荚，manager 首先是一个教练，应该帮助自己团队的成员成长。通过 One on One，manager 需要了解每个团队成员现阶段的状态和遭遇的困扰，分享职业规划，帮助他们正确地处理问题，更好地实现个人成长。

　　3、个人 OKR 和 Performance 体系：每个员工在每个季度初需要确定自己本季度的 OKR，在一个季度结束后需要根据自己这个季度的工作完成情况给 OKR 打分。每半年公司会进行一次 Performance Review，主要是 review 员工过去半年的绩效，并根据 Performance Review 的结果变更 Job Ladder（业务职级）和薪酬。值得一提的是，在豌豆荚，所有的个人Performance Review 的成就内容及级别都是全公司共享公开的，如下图所示。这个对于很多公司来说是不可想象的，豌豆荚为什么要这么做？因为一方面对于豌豆荚来说可以做到更为公平和透明，另一方面也给每位豌豆提供了更好学习和成长自己的样本，激励大家在产品研发中更高质量的挑战和要求自己。

　　第五步，兴趣管理——排干扰：

　　1、激发兴趣：HackDay，是豌豆荚一个特殊的节日，开始于2010年，类似黑客马拉松。通常在春节假期回来的那一周，产品设计师和工程师们 3-5 人组成一队，在连续48小时的时间里，充分展现工程团队的创意和想像力，完成一些比日常开发更 geek、更有趣的东西。

　　豌豆荚为了鼓励大家更好的完成挑战，也会设计一些特别有特色的奖品，历史上2012 年提供的是苹果刚出 Macbook Retina，2013年是 Google Glass，2014 年则是程序员最爱的 Herman Miller 顶级座椅。

　　在历史的 Hackday 中，有不少作品最终都成了重要产品对外发布，比如 MUCE、豌豆洗白白和 IAS（应用内搜索），都成为了豌豆荚极具特色的产品。

　　2、控制兴趣：PolishWeek，让公司慢下来，对已有产品的细节进行精细化的过程。在大量开发和新产品上线的过程中，我们会担心因为走得太快而对产品的细节关注不够。在连续3个工作周后，第4周通常是 PolishWeek。在 Polish Week 的这一周，豌豆荚内部不会进行新产品或新功能的开发，而主要是对现有的产品和服务进行打磨，解决一些细节问题和小 bug，譬如产品内一些字体的统一等等。平均每个 Polish Week 会解决产品中各种 Bug 大约 200 个。

【在创业公司该如何解决技术开发团队的考核问题】相关文章：