如何解决百人研发团队的管理问题?

发表于:2019-7-12 11:12  作者:Worktile CEO anytao   来源:Worktile官方博客

字体: | 上一篇 | 下一篇 |我要投稿 | 推荐标签: 团队管理

  分享一个公司规模近200,研发占一半的创业公司 Worktile 在研发管理方面的玩法,仅供百人左右研发团队参考~
  什么是研发团队,简单的说,就是由你熟悉的那帮穿格子衬衫程序员为核心组成的团队,就是研发团队。本来,你以为格子男们是很乖很闷骚的那种,管理和协作起来比销售和业务简单很多,而实际情况是,格子男们并不那么容易管理,面向代码世界的复杂度,可能远比面向财物世界的复杂度还要高。作为致力于团队协作的公司,我们研究了很多国内和海外牛逼公司的研发模式和研发管理,例如OKr在谷歌Facebook的应用,Uber的高效会议制度,阿里的绩效体系,腾讯的产品流程。除了在自身团队做了N次不同的试验和反思,我们也将很多不错的经验分享到客户和用户,所以本文试图将Worktile的研发管理全景图做一个概括性的阐述。要谈清楚方法,就先了解清楚问题,研发管理之所以令人头疼,核心的问题无外乎以下一些方面。
  研发管理的典型问题
 
  难以KPI化和考核
  任正非有句名言:钱分好了,管理的大部分问题就解决了。我对此深表同意,可问题是,怎么能分好钱确实非常考验能力、经验和智力的。研发之难,恰恰难在无法KPI化工作本身,所有那些试图KPI化工程师和码农的做法,最终结果都啼笑皆非、面目可憎、吃力不讨好。在我过去经历,还有客户实际的研发管理里,试图KPI化研发工作一直是不同团队努力的尝试,包括和不限于以下方式:
  解决Bug
  SLA
  功能完成度
  加班,007就比996牛逼,996就比955更值得奖励
  营收捆绑
  NPS
  这些看起来可以数字化的指标,除了证明研发管理者通过偷懒的方式做绩效考核外,可以说毫无价值,也无法给公司和组织带来正向的激励。
  离代码很近,离用户很远
  另外一个现实且无奈的问题是,工程师和产品经理好像是在象牙塔里做产品和研发,和用户往往离得太远太远。这种问题带来的伤害可能远比其他事情来得更加彻底,但本质上这是研发规则上没有解决好的问题,导致工程师本身并没有任何的目标和动力去贴近用户和客户场景。
  我们常常说要做用户喜欢的产品,但那些反人类智商的产品,往往是产品经理和工程师合谋的结果。如果说研发管理的目标是提高效能,那么首先同步研发团队朝着统一的目标,就是效能管理最重要的第一步。
  因此,以什么样的制度去驱动研发抬起头来看客户场景,是一切研发管理的核心工作之一。
  跨部门战争频发
  因为低头干活,所以往往研发团队的目标和业务团队的目标并不是一致的,研发体系和业务体系的跨部门战争,简直罄竹难书:
  业务认为,怎么这么多bug,一个小问题需要花这么久的时间才能修复
  而研发认为业务的智商不够用,这么好的产品就是无法准确传达给客户
  业务面对客户点头哈腰;而研发觉得客户是业务的客户,不是研发的客户
  业务对需求排期是12345;而研发对需求排期往往是54321
  业务给客户承诺就像谈恋爱,把星星摘下来也敢接着;
  研发认为你承诺的,你去写代码实现吧
  业务认为研发高工资吹着冷气,自己天天跑在外面晒太阳;研发认为,业务提成那么高,这产品是我做的,我咋没提成呢
  这种剪不断、理还乱的关系,是很多公司的普遍现象。因为跨部门的不理解,必然带来团队之间的内耗,信息的折扣和效率低下自然产生。而更重要的影响是跨部门战争造成对客户服务与理解的偏差与推诿,没有任何公司或者团队能在一个不流畅的环境下成就对客户的100%满意度。
  那么如何解决以上问题呢?
  从研发管理全景图说起
  下面的研发全景图,是我们团队过去几年逐步形成的研发管理经验,其中主要包括以下内容:
  研发管理的的核心是构建一个开放、自学习、自驱动的组织文化和仪式感,这是打造高效研发团队最内核的基础。
  左边是工具和方法,主要包括:以OKR驱动的目标管理,基于Scrum的敏捷,和逐步完善的DevOps。
  右边是制度和规则,核心包含:研发团队的绩效和考核、跨部门合作、其他仪式感驱动的各种规则,尤其是构建自学习的环境与分享机制。
  
  打造开放与竞合的组织架构和文化
  一个组织要焕发活力、自驱动、使命必达的信念,开放而透明的文化是绩效管理的核武器。总体来说,不管你的方法和制度多么丰富和完善,无论如何也不可能驱动僵化、死板、没有活力的团队产生极其高效的价值。所以,我们在谈研发效能的时候,注意力总集中在别人家的团队是符合管理的,而忽略了团队激活的核心首先是塑造超强自由度、透明度和使命感的团队文化。
  从效率这个角度去看,没有透明度的提效都是打折扣的,在一个组织里效率低下的首要原因并不是执行力,而是透明度。需要层层审批和报备的组织,设定层层关卡和信息围墙的团队,效率一定是非常低下的,单点的执行力提升并不改变整个团队的低效基因。
  所以,打造开放与竞合的组织架构和文化,至关重要。
  特种部队
  如何设计研发团队的组织架构,是个大大的思考题。我们团队经历过好几次不同的组织形态,也经常性的将研发团队,简单说,一个研发团队的角色主要是以下几类:
  产品经理
  设计师
  服务端工程师
  前端工程师
  测试
  其他
  以什么样的组织方式调配以上资源,是个非常考验团队管理的事情,例如很多公司会将设计团队作为完全独立的部门,其他团队和项目按需调配设计资源,设计团队就像公司的乙方角色,通过资源调配来匹配执行。而另一种形态则是广泛存在于Facebook等互联网公司的方式,设计、产品经理、开发、测试组成短小精悍的特种部队,在研发团队中以小组形态组合,就像一个研发业务的接口一样,有清晰的输入和清晰的输出,有清晰的目标和清晰的边界。显然,打起仗来,特种部队方式的小组,从执行到目标都是超级强悍的,也同时能方便研发组织绩效考核的落地与激励。
  特种部队的另一个好处是,每个小组的职能和目标是固定的,在产品研发大架构下执行一个精确的目标和单元。但小组成员可以转岗或者调配到其他小组,从而避免了研发人员的枯燥和无挑战的问题。
  仪式感
  仪式感是团队管理的调味品,也是必需品,就像你吃饭离不开盐一样。研发团队管理者,例如CTO角色的人,需要有意识的在团队中设计有价值的仪式感,来增加团队磨合、默契与调味。好的仪式感,就像宗教仪式一样,能不断加强团队目标的执行、文化的塑造以及阶段的激励。
  例如,我们自己团队就有很大仪式性的东西在执行:
  OKR的阶段同步
  把重大版本发布变成研发团队的阶段激励
  管理层的固定One One访谈
  研发人员的每月访谈,同步到公司月报
  花心思的团建
  每月的产品考核
  师徒制
  走出去,参加各种外部的技术大会
  还有很多其他的仪式和规则,并且以上几乎每个规则都值得拿出来说道说道。
  用户体验委员会
  在Worktile团队,我们建立了组织架构之外的一些虚拟组织,虚拟组织的设计可以很好解决跨部门沟通与信息同步的问题,以用户体验委员会为例,将公司里研发、设计、产品、销售、客户成功的同事组成一个虚拟委员会。委员会主席本质上就是这个组织的秘书,通过定期的会议或者讨论,将解决用户体验上的问题作为核心目标来解决。委员会的茶话会,每次都能高效推进很多方面的事情:
  就用户体验的重大问题充分讨论,产品和研发从不同视角收听意见,销售和客户成功更多代表了来自一线用户的建议。
  促进跨部门的彼此理解,很多时候跨部门的战争,来自于互相的不理解和看不起。例如,我们在某次茶会中,就一个很久以来的核心需求做了讨论,销售端原本以为是一个简单的需求,结果讨论下来发现,这个简单需求其实在客户方也有非常不同的理解,完全推翻了产品已经草创的设计方案。反过来,销售同事也完全理解了为何产品方案是如此之难的原因。
  指定行动方案,快速驱动产品研发落实改进方案。用户体验委员会不是只讨论,更重要的是驱动行动方案,快速解决用户关心的体验问题。
  技术委员会
  同样在研发团队,我们通过技术委员会来实现跨研发团队的技术沟通、分享和技术选型。技术委员会保证了公司始终以科技驱动商业的基础不被稀释,汇聚团队中技术能力最强的圈子更加自驱动的投入技术贡献,主要的工作目标包括:
  公司级的技术方案
  前沿技术研发小组研发岗的职级评审,技术委员会承担对技术能力的职级评估
  驱动公司技术进步和学习,例如组织黑客马拉松、技术分享、对外技术输出
  向市场和销售输出技术内容研发下乡
  研发下乡
  就是让研发走向客户,贴近客户需求,了解客户状况,然后回来完善产品以满足客户需求。Worktile本身是企业服务产品,客户需求在B端是及其复杂而多样的,憋在办公室是无法做出好产品的,所以需要从制度上驱动研发、产品和设计走向客户,而不是待在象牙塔。
  研发下乡给了每个研发人员固定的指标,需要下乡到客户现场,所以销售和客户成功有了正当的理由要求研发同事完成指标,从另一个方面也加强了研发和业务部门的配合与协作,因为双方有了共同KPI的时候,大家绑在一起去做好一件事的动力就变得很强。
  Polish Week
  Polish Week是来自硅谷的流行文化,让研发团队在一个紧张迭代之后,有足够的时间可以休息一下,然后集中火力解决来自客户的需求或者问题,这种制度设计是非常高效的方法,可以短时间集中兵力解决遗留问题。
  技术分享和走出去
  5年下来,我们技术团队每周分享已经正常进行了几百次,研发团队中的每个人都或多或少完成过对于所在部门的技术分享。新人来到团队,可以从过去数百次分享留下来的知识收获非常多的遗留知识。
 
  (在研发体系共享的技术分享池)
  另外一方面,Worktile 的核心客户本来就是研发团队和工程师,市场维度需要研发人员能够不断共享有价值的技术内容,而技术分享机制恰恰提供了驱动工程师内容创作的土壤。每次内部分享的内容,其实完全可以继续优化成外部可以传播的内容,通过市场手段实现二次传播,同时也能够将团队中有活力和分享精神的小伙伴,推到前台去技术大会或者公司组织的技术分享大会分享。
 
      上文内容不用于商业目的,如涉及知识产权问题,请权利人联系博为峰小编(021-64471599-8017),我们将立即处理

【干货】Linux命令行工具之处理JSON的神器-JQ全面讲解

评 论

论坛新帖

顶部 底部


建议使用IE 6.0以上浏览器,800×600以上分辨率,法律顾问:上海瀛东律师事务所 张楠律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2019, 沪ICP备05003035号
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪公网安备 31010102002173号

51Testing官方微信

51Testing官方微博

扫一扫 测试知识全知道