AI 年度盘点与2025发展趋势展望,50+案例解析亮相AICon 了解详情
写点什么

为什么你的核心骨干团队总是建立不起来?

  • 2018-12-24
  • 本文字数:4395 字

    阅读完需:约 14 分钟

为什么你的核心骨干团队总是建立不起来?
  • 项目经理、开发经理和产品经理没有有效配合。

  • 遇到问题,开发人员不知道找谁协调。


这些是很多技术团队都曾遇到过的问题,那么你找到正确的解决方案了吗?12 月 9 日,在 TGO 鲲鹏会南京分会「技术难、管理烦,技术领导者如何破局?」的活动上,江苏盖闻 CTO & TGO 鲲鹏会会员朱彬为大家带来主题为「如何打造核心骨干团队」的演讲。


以下根据当天演讲整理,有部分不改变原意的删减。



朱彬现场分享图


先做一个简单自我介绍,我目前在江苏盖闻互联网公司,之前有过接近 2 年的创业经历。


对于很多人来说,技术管理是一件非常头疼、痛苦的事情。技术团队从开始搭建时,往往会发生自己想留的人留不住,不想的留的人一直在的情况。有一句话叫“铁打的营盘流水的兵”,如果说自己能有一个骨干团队,那么它就是我们铁打的营盘。而非骨干边缘正常流动,实际上对于企业和团队来说,是一件好事情,因为它能给团队补充新鲜的血液。


今天我将结合自身的实战经验,以及在 TGO 鲲鹏会所学到的内容做一个成果性的分享。


目前,我的技术团队大概有 100 人左右。由于公司业务流程比较长,我们按照语言分为多个团队,有 Java、APP、PHP 等,包括还有单独的测试部、项目管理部。还有一些支撑部门,如技术委员会、DBA、配置经理、质量经理、运维部。同时,我们选择了矩阵式管理作为公司的组织架构形式。


这个架构看上去比较理想,但实际上有一个最大的问题是,这一套东西完全不落地,最终导致发生了以下几个情况:


1.项目经理、开发经理和产品经理没有有效配合。在与员工沟通时,大家通常会有很多抱怨,如需求变化太频繁,上线失败率很高,人员流失严重等;


2.遇到问题,开发人员不知道找谁协调。矩阵式的管理会导致多头管理,如果出现问题,应该找主管领导或项目经理?还是找产品经理?大家都非常迷茫。


那么该如何解决这些问题呢?当时我想到的第一个解决办法是,做大量一对一的沟通,包括走动式管理,详细了解跨部门之间情况。通过这样的方式,我得到了一些反馈:


1.由于需求变化很频繁,东西刚做出来,需求就变了,导致技术人员不能明确阶段性目标是什么;


2.不够了解技术团队的痛点和诉求。


如果我想要满足团队的需求,我们一定要建立核心的骨干团队。让核心骨干团队成为中坚力量,带动整个团队。

如何建立核心的骨干团队?

1、营造以技术为本,平等尊重的氛围

首先,我们需要给团队信心,告诉大家,我们在技术团队里做什么样的事情是正确的,能得到大家的认可。


1.技术为本


我们既然是一个技术团队,那么一定要技术实力过硬,无论是一线团队,还是管理者。


2.沟通能力


作为一个技术负责人,我们需要与业务部门沟通,与市场执行讲”人话“。讲“人话”指的是,把技术性的数据转变为非技术人能听懂的话。


3.人品


我们需要有一个理念,无论是在任何场合,我们都需要明白平等、尊重、沟通、互动的重要性。

2、招聘中发现人才

招聘无非有三个渠道,对外招聘、内部提拔和淘汰,那么我们该如何让招聘变得更高效呢?


1.会问问题,具有打破砂锅问到底的精神


通过学会问更好、更多的问题,挖掘面试者的潜力,考察他的技术深度。


2.考察三观


在团队里肯定要面对自己的同事、下属和领导。即使招聘的是一位普通开发人员,我们都应该问他三个问题:


1.你喜欢什么样的领导?

2.如果你是领导,你喜欢什么样的下属?

3.你喜欢什么样的同事?


这三个问题能让我们大致了解他是如何理解团队协作,和我们所提倡的理念是不是一致的,三观一致更有利于大家之间的合作。


3.人员优化要果断


我认为,人员的优化一定要非常果断,尤其是你刚接触一个新的团队。


因为从优化的角度来说,特别是针对管理层而言,我们肯定要看结果的,职场稍微残酷一点,对于团队来说是一件好事情。


4.提拔和培养


除了组织架构里面的经理层管岗位,我觉得小组作战也是非常重要的。我们在公司里会成立多个 4-5 人的小团队,其中会指派一位小组负责人,他可能技术能力比较强,同时也比较负责任。通过这样的形式,相当于把比较大的部门逐渐拆分成各个小组作战,我们遇到的问题时,也会比较机动灵活。


另外,我们无论是作为经理,还是小组负责人,不管负责的人数是多少,都要善于问下属问题。比如在分配任务时,问某位开发同学是否清楚自己所做的内容是什么,技术方案该如何落地,什么时候能完成等,这些都是很关键的问题。

3、如何解决技术团队的抱怨

1.需求变化过于频繁


我们曾经发生过这样一件事情,某个规则在一个月内变化了 5 次,APP 里的页面改了 7 版,这完全是一个失控的状态。由于当时的项目经理比较弱势,在面对强势的业务部门频繁提出需求变更时,没有做到控制。我们要快速响应合理的需求,对不合理的需求应该加以管控。


很多时候,我们都希望软件工程师不仅有阶段性成果,而且能够快速响应业务部门需求时,那么该如何处理呢?我们设置了一套解决办法:


1、常规需求:每两周做一次上线;

2、紧急需求:立即响应;

3、线上 BUG:第一时间解决。


通过这 3 种不同的处理方式,既能缓解需求,又能把需求进行了分类。除此之外,我们需要告诉项目经理,在对外时一定要做好沟通,如果沟通中出现问题,那么会导致项目很难落地实施。


技术对业务部门一定要讲“人话”,这是一个很实际的关键点。


2.开发流程不落地,流于形式


我们公司开发流程好像没问题,部门也比较健全,为什么还会出现这么多问题呢?那是因为开发流程不落地。


开发流程上,无论是做敏捷,还是做迭代,我认为最关键的是分工一定要清晰。


其次,大家在合作的过程中,不能出现甩锅的情况。比如,PMO 需要及时管理和接受需求;技术总工需要确保整个技术方案;开发人员的功能性 BUG 一定为 0,保证代码一定要通过。


在解决了技术团队常抱怨的两个问题后,我们团队从原来的上线成笑话,到现在我们每次上线,基本 2 小时内都可以完成。

4、绩效考核是把双刃剑

很多技术工程师都不太明白,绩效考核到底是什么。对于我来说,绩效考核可能是一把双刃剑,如果做得不好,它将会扼杀很多技术工程师的创造性。那么我们该如何做绩效考核呢?


我觉得,关键是需要有一些理念进行支撑,让大家明确绩效考核的目的。我们不是为了把做得好的骨干团队绩效打低,而是甄别出其中还需要改进的同学,让他们知道自身有哪些方面做的不足。具体我们可以通过两方面让他们了解:


1.数据说话


我们现在每周都会做一个次数据统计,通过具体数据给大家一个相对公平的绩效考核,比如:


计算实际工时,假设这个任务要求 8 小时完成,可你只花了 6 个小时就完成,那么你的绩效肯定高。


任务数,做了多少任务,出现了多少 BUG,在测试阶段出现的 BUG 数量。


2.OWNER


我们曾经发生过一件事情,某个应用需要搭预上线环境时,由于搭建环境过程相对比较复杂,中间出现了很多问题,导致测试和运维吵得不可开交。


其实这件事很容易解决,运维负责预算环境,测试作为使用者,在搭建预算性环境中,你可能需要研发,那么就自己去找人。如果在找各个部门协调的过程中,得不到配合,你可以找相应的负责人,让他去进行协调。如果负责人把整件事情捋顺了,那么就不能再找任何借口说,这个事情因为某个原因导致最后没有做成。

5、建立持续改进的研发文化

在团队落地的过程中,我会要求大家持续改进研发文化,希望能帮助大家每天进步一点点,那么具体该如何做呢?


1.经常做复盘


每次项目做完后,我们通常会花一个小时左右的时间做复盘。把项目过程中所遇到的问题列出来,并说明为什么不该出现问题的原因,最后指定到相应的人进行整改。


2.述职


在试用期结束后,需要写一份转正报告,那么报告中具体需要体现哪些内容呢?


1.总结试用期期间你做了哪些事情,形成了什么样的成果;

2.分析自己做得不足的地方;

3.下一个阶段的计划。


述职会参与人可能是同事,以及相关的领导。你可以在述职过程中做一些自我否定,因为一个人只有在自我否定后,别人才敢给你提意见。我们希望通过这样的方式,让大家在工作中沟通不再有隔阂。



南京分会活动大合照

Q&A

不少程序员可能对新技术、新工具会比较感兴趣,但时间长后,由于业务逻辑十分乏味,不少人失去了原本工作的激情,这时候该如何处理呢?


朱彬:通常大家都喜欢做一些有挑战性的事情。所以面对这个问题时,应该给开发人员一些正向的引导,让这个事情变得更有趣一些。


举个例子,最近我们正在做组织架构调整。首先,我们取消了配置经理的职务,把原本无聊的工作通过工具去完成。其次,事情完成后需要进行跟踪,这是关键的一步。在过程中我们如果发现代码不提交,其中肯定是有原因的。我们需要发现原因、跟踪原因,并及时改正。这个事情做起来会相对比较有意思。


当下我们也会出现类似的情况,很多程序员写了大量的业务代码,导致工作热情极度下降。因此,我们采取了相应的措施,如定期组织培训。我们要求所有的技术经理,每个月至少要做一次有深度的技术培训,主要围绕 3 点:


1、引导大家让事情做得更有趣,简单的事情深入去做,这个过程会让它变得更有意思;


2、让工程师选择自身的技术栈;


3、组织一些技术分享活动,让大家觉得在这里还能有一定程度的成长。


目前,我所在的公司想通过日报、周报的形式加强与员工的互动。想请问一下,盖闻是否也有日报、周报制度?日报、周报制度对于技术性公司是否合适?有没有存在的必要呢?


朱彬:我觉得日报、周报制度得从不同层面上来看。


对于一线开发员工来说,开发人员的精力不是去做日报和周报,而是集中做技术,从项目中就可以体现出他们所做的事情。而日报、周报制度更适合于管理岗,尤其是项目经理。


我的管理方式更倾向于走动式管理,可以更直接的处理员工的工作问题,及时了解员工的工作状态。


我想最重要的应该是计划,特别是月度计划和周计划。因为它们,你自然而然就有了周报,周报的最终目的是为了帮助你做总结。


如果遇到一些比较听话的员工,但他的个人能力不足的话,有没有其他更有效的方式,能够帮助提高他们对项目的贡献?


朱彬:态度不错,能力较差,我们称之为小白兔员工,我认为他们并不是企业所需要的,但是一个企业不可能说没有这样的员工,这时候该怎么办呢?


我觉得,首先理念是很重要的,我们需要告诉大家做什么样的人是正确的。技术和能力是每个公司都需要的,如果你的技术能力不强,态度再好,都不能解决问题,你在整个部门里,排名一定是靠后的。所以需要帮助他们意识到,想要往上走,就要想尽一切办法提高自己。


那么该如何提高呢?


1、主动,要求组长安排任务时,多关注他们;

2、给予一定的空间和压力,一定要有压力,如果没有压力就没有动力;

3、通过培训给予机会,这种机会可能不是很多,因为企业想要生存,肯定是需要有能力的人。




TGO 鲲鹏会是极客邦科技旗下高端技术人聚集和交流组织,目前已在北京、上海、杭州、广州、深圳、成都、硅谷、台湾、南京、苏州、武汉全球十一个城市设立分会。现在全球累计 700 多名会员,60% 为 CTO、技术 VP、技术合伙人。


如果你想和这些优秀的科技领导者们一起前行,目前 TGO 鲲鹏会厦门分会已成立,欢迎点击「报名表单,申请加入」


2018-12-24 10:513966

评论 1 条评论

发布
暂无评论
发现更多内容

架构师训练营第八周作业

xs-geek

极客大学架构师训练营

第八周总结

睁眼看世界

极客大学架构师训练营

架构师训练营第四周系统架构总结

Sandman

极客大学架构师训练营

它是世界上最好的语言,吊打PHP那种

MySQL从删库到跑路

php 少儿编程 scratch

Netty源码解析 -- PoolChunk实现原理(jemalloc 3的算法)

binecy

源码 Netty 内存管理

架構師訓練營 week8 作業

ilake

架构师训练营第八周总结

xs-geek

极客大学架构师训练营

第四周-作业一

ray-arch

极客大学架构师训练营

网络模型及性能优化

天天向上

极客大学架构师训练营

第八周作业

Geek_ce484f

极客大学架构师训练营

架构师训练营第 1 期第八周总结

Leo乐

极客大学架构师训练营

架構師訓練營 week8 總結

ilake

第四周作业

Griffenliu

性能优化学习笔记

Yangjing

极客大学架构师训练营

架构师训练营第 1 期 week8

张建亮

极客大学架构师训练营

架构师训练营第一期第八周作业

Leo乐

极客大学架构师训练营

典型互联网应用系统使用的技术方案和手段

jorden wang

第八周作业

Geek_ce484f

极客大学架构师训练营

在GitHub中如何进行PR(Pull Request)

jiangling500

GitHub PR

匠心、携手、深耕:5G Capital展现出的无线产业新范式

脑极体

架构训练营第四周课后作业

Sandman

极客大学架构师训练营

三步实现SSH免密登录Linux服务器

jiangling500

SSH 免密登录 Linux服务器

并发压力&响应时间&系统吞吐量

Yangjing

极客大学架构师训练营

架构师训练营第 1 期 - 第八周作业

Todd-Lee

极客大学架构师训练营

第四周学习总结

Griffenliu

第八周作业总结

Geek_ce484f

极客大学架构师训练营

架构师训练营第八周学习总结

Gosling

极客大学架构师训练营

架构师训练营 - 第八周 - 作业一

行者

第四周学习总结

晴空万里

极客大学架构师训练营

第八周作业

极客大学架构师训练营

架构一期第八周作业

Airs

为什么你的核心骨干团队总是建立不起来?_技术管理_朱彬_InfoQ精选文章