六张表格让你快速搞定新技术团队

标签: 架构和远方 团队管理 空降落地 管理新手 | 发表时间:2022-02-26 20:03 | 作者:admin
出处:http://www.phppan.com

前言

如果你是一新手管理者,或者你是一个刚升职,从带一个几人的小团队到带几十人的团队,或者你空降到一个新公司做技术管理,都可以看一下这六张表格。

要搞定一个新技术团队,主要是四步:

  1. 弄清楚有哪些人;
  2. 搞清楚有哪些事;
  3. 把人和事关联起来;
  4. 确定好目标并执行

前三步中我总结了六个表格来梳理这些结构,在这些结构的基础上我们明确团队的目标,并执行下去,将会有一个不错的结果。

1. 弄清楚有哪些人

弄清楚有哪些人的关键点是人才梯队和人才发展计划的表格,确认哪些会有下一步晋升,哪些可能会走,哪些是有问题的,做好 1v1 沟通,先熟悉起来,了解每个人的工作状态,特别是核心骨干。

1.1 成员信息表

成员信息表能帮助你了解你的团队成员的背景,在职时间等,这些信息可以找 HR 或者之前团队的负责人去了解,或者当面沟通的时候了解等。

序号 部门 职位 职场 职级 姓名 性别 工号 家乡 工作年限 年龄 在职状态 在职时长 出生年份 毕业时间 入职时间 备注
1 研发中心 前端 深圳 T10 张三 00134 湖南 8 30 已转正 3 1993 2013 2019-10-01 核心,部门老员工

可以通过透视表的方式使用成员信息表,其可能的用法:

  1. 看人才职级占比,是否梯队不合理;
  2. 看职场分布,是否多地,沟通成本有多大;
  3. 看在职时长,是新人多,还是老人多;
  4. 看工作年限,看年轻人多,还是资深的人多;
  5. 看职位,各技术工种占比,配比是否合适;
  6. 看老家分布,下次出去吃饭点菜心里会有点谱。

1.2 人才梯队表

人才梯队表主要是帮助你理清当前团队的梯队情况,哪些是能带项目的,哪些是只能执行的,以及当有人才流失的时候,哪些同学是可以补位的。

- 前端 后端 移动端 QA
负责人 张三 李四 王五 赵六
第一梯队 - - - -
第二梯队 - - - -

一般人才梯队表如上,也可以有更多级,具体看团队规模,几十人的团队大概三级左右就可以了。 如果是一个研发中心,其人才梯队表组成如下:

  • 负责人主要是某一块技术的负责人,是这块的掌控者,不仅要求技术,还要求有较强的管理经验;
  • 第一梯队主要是骨干同学,是负责某一块业务的模块负责人,不仅要求技术,还需要有一些项目管理的经验;
  • 第二梯队主要是偏执行的同学,负责某一块具体的事务。

1.3 人才发展计划表

人才发展计划表主要是识别出团队中成员的当前状态,以及下一步的发展计划。

姓名 当前状态 下一步计划 风险 备注
张三 骨干 职级晋升 后备 leader -
李四 执行 后备培养 轻微离职倾向 -
王五 待考察 待观察 - -
赵六 绩效不佳 淘汰 - -

人才发展计划表主要是了解团队的成员的具体情况,多和老员工去聊聊,工作接触中多观察,并且可以通过下一级的 Leader 了解一线同学的状态,这个过程中可能会有一些信息的过滤,需要批判的接收信息。

1.4 做好沟通

做事之前先做人,做人之前先熟悉。

对于新同学,先认识一下,让对方知道你是怎样的人,以及了解一下对方是怎样的人,背景如何。可以从 HR 或其它渠道拿到简历等信息。

在破冰后可以多聊一下现在手头的工作内容以及将来团队的情况,目标等。 沟通过程可以适当的记录一些信息,整理到上面的成员信息表和人才发展计划表中。 至少都做一次 1v1 沟通,以及一次全员沟通,全员沟通可以和周例会合到一起。

2. 弄清楚有哪些事

在理清人的同时,也要同时开始了解有哪些事情。

作为技术管理者,多看文档,多看代码,多看表结构。多和原来负责的产品沟通,聊聊天,和原来负责的开发也多勾兑勾兑,在这个过程中把一些信息落成表格。

2.1 业务模块重点问题表

重点问题表主要是提取当前业务的重点问题,并从中找出能早点出成果的破局点。

模块 重点问题 当前状态 当前负责人 解决方案 后续计划 相关文档
核心链路 稳定性问题 梳理中 张三 可用性治理 - -

从以上的表格中找到能快速解决大家工作中的痛点或者业务痛点的问题,尽量以 ROI 较高的方式处理,打破局面,获得一定的信任,当这种小的成功累积多了,你在团队中的口碑也就建立起来了,后续要做一些大的改变也顺理成章。

2.2 RASCI 矩阵表

RASCI 矩阵表主要是澄清项目组成员权利与责任,明确事项,作为项目管理中必要的沟通工具存在。

项目名称 执行(R) 决策(A) 顾问(C) 通知(I) 支持(S)
订单系统 研发二组 产品组王五 李四 商业化部门 中台/ SRE

有了 RASCI 矩阵的表,我们就可以知道业务边界在哪里,出了问题应该找谁,找谁去决策问题,做好了找谁去汇报或通知。

3. 把人和事关联起来

人和事关联,主要是找到事情的是什么,是团队的什么人在负责什么内容,这里重点要关注模块负责人。

3.1 模块负责人及成员表

业务线 前端 后端 移动端 QA 备注
订单系统 张三 李四 王五(模块负责人)、赵六 - -

模块负责人及成员表主要是理清具体某个事项是谁在负责,谁在执行。而模块负责人是一块业务的技术负责人,是一个小的技术 Leader ,负责掌控该业务模块,包括人和技术,是各端 Owner 的后备人才池,这个制度是人才梯队的核心制度之一。

模块负责人的主要职责包括:

  1. 参与需求规划并评估模块需求所需人力;
  2. 与模块成员对齐迭代需求,分配并拆解需求;
  3. 识别和管理模块内的需求,及时暴露风险;
  4. 对模块负责,推进并协调模块成员解决问题;
  5. 迭代完成后回顾模块内的需求;
  6. 关注并引导模块成员成长。

4. 明确团队的目标

这里更多是的向上沟通,和产品,老板多做沟通,了解公司整体目标,业务目标,技术目标等,在这些目标的基础上结合当前团队的现状,和团队成员做一定范围内的讨论,一起制定出团队的目标。

在初步确定目标后,和上级沟通团队目标,并达成一致。

5. 清晰目标和持续跟进

达成共识的目标后,将目标分解向下同步,确保大家对于目标能有清晰的认识。

这里我们会用到 OKR 、KPI 等技术,通过周报将 OKR/KPI 和具体的产品需求,技术需求关联起来,将目标,过程需求,过程进展,业务价值通过周报的逻辑持续的跟进起来,反思一周之中我们所做的内容是否向着我们的目标前进。

同时,建立沟通机制,周报机制,周会逻辑等等。

结语

接手新团队不是一个一蹴而就的过程,需要时间,把工作做实,该聊的天要聊到位,该开会的会要开,该喝的酒不能少。 就像一个又大又重的飞轮,开始的时候很艰难,努力转动一厘米,两厘米,一段时间后,发现转完了一整圈。飞轮开始转动,不停的努力,飞轮又会转完第二圈。继续沿向一个方向努力,3 圈 …… 4 圈 …… 5 圈 …… 6 圈,轮子开始加速,7 圈 …… 8 圈 …… 9 圈 …… 10 圈 …… 轮子有了动量,已经可以开始自己转动了,再坚持就能很快的飞转了。

最后引用冯唐的九字真言「不着急,不害怕,不要脸」,2022,加油吧!

模板在这:

飞书 Docs Link: https://fgr6cngqqy.feishu.cn/space/sheet/shtcnywzAOBxaeiU5ofJTYNXrGb Password: x1w8

你好,我是潘锦,超过 10 年的研发管理和技术架构经历,出过书,创过业,带过百人团队,也在腾讯,A 股上市公司呆过一些年头,现在在一家 C 轮的公司负责一些技术方面的管理工作。早年做过 NOI 和 ACM,对前端架构、跨端、后端架构、云原生、DevOps 等技术始终保持着浓厚的兴趣,平时喜欢读书、思考,终身学习实践者,欢迎一起交流学习。微信公众号:架构和远方,博客: www.phppan.com

相关 [表格 技术 团队] 推荐:

六张表格让你快速搞定新技术团队

- - 胖胖的空间
如果你是一新手管理者,或者你是一个刚升职,从带一个几人的小团队到带几十人的团队,或者你空降到一个新公司做技术管理,都可以看一下这六张表格. 要搞定一个新技术团队,主要是四步:. 前三步中我总结了六个表格来梳理这些结构,在这些结构的基础上我们明确团队的目标,并执行下去,将会有一个不错的结果. 弄清楚有哪些人的关键点是人才梯队和人才发展计划的表格,确认哪些会有下一步晋升,哪些可能会走,哪些是有问题的,做好 1v1 沟通,先熟悉起来,了解每个人的工作状态,特别是核心骨干.

谈技术团队目标

- - Tim[后端技术]
技术主管新年想得最多的一件事必定是如何比上一年做得更好. 宏大的目标设定每个团队都会做,谈几个不引人注意的小问题. 见过一些技术团队将计划定义为“按时完成需求”,需求驱动并没有什么不对,但是研发工作仅考虑被动需求的话是很难做好. 之前完成的许多需求有什么共性. 经常出问题/bug/故障的项目/功能/模块是哪些.

了解豆瓣技术团队必看

- - 张沈鹏
文 挑灯看剑@ douban.com. 以下内容按照时间倒叙排列,方便各位阅读,以后不定期更新:. (之前发布的内容,不保证符合现状). 豆瓣首席科学家、算法组leader在程序员杂志上发文《下一代个性化推荐系统》. 豆瓣高级工程总监段念在letagilefly会议上讲豆瓣的技术团队敏捷实践. 豆瓣设计师在极客公园讲豆瓣FM的设计.

说说技术型创业团队的技术选型

- rhyttr - DBA Notes
看到微博上《程序员杂志》在征集"一分钟先生"的话题:如何做好公司/团队的技术选型. 其实大公司或者大一点的团队选型几乎不需要太多讨论的 -- 最后会不可避免的绕到技术官僚的话题上去. 这里我想简单说说技术型创业团队技术上的选型问题. 如果只能选择微软的技术路线,比如团队几个人只会用微软的技术做开发,甚至也不想学别的,那么似乎没有别的办法,将就一下吧.

续——冯大辉谈技术性创业团队的技术选型[原创]

- huyun - 运维进行时
       原文冯大辉谈技术性创业团队的技术选型提到了天涯,好吧. 站在一个天涯从事6年运维工作的角度,我就多说几句,天涯属于破釜沉舟要摆脱这种束缚的这一类. 原因不用多说,文中提到的问题天涯多少都有碰到或存在. 目前已全面拥抱开源技术,这不是一时头脑发热所做出的决定. 根据现状、未来的发展策略理性来选择的.

工程师在创业团队的技术挑战

- cong - DBA Notes
曾经有不少人对我问过类似的问题:作为技术人员在创业团队(或是小公司)工作,技术上没什么挑战,觉得自己得不到锻炼,我该怎么办. 的确,就说互联网这个领域吧,创业团队或是小公司的网站规模往往并不大,或者至少要从小做起,用户访问量和那些大型网站在当下自然没法比,从这个角度上看,很多中小网站的确暂时面临不到这些高并发、大流量、高可用的这些"严峻挑战",另外,团队的职能岗位甚至也没有大型公司那么齐全,人家连做配置管理的团队规模甚至都比你整个公司人多,似乎在小团队作技术的出门都低人家一头,见面不好意思打招呼,真的有必要妄自菲薄么.

如何做好企业/团队的技术选型?

- 【虎.无名】 - 《程序员》杂志官网
好的技术选型,能最大程度地提高企业和团队的效率,从而开发出满足用户需求的产品. 作为一线的技术管理者,他们都是怎样做的呢. 大公司或者大一点的团队的技术选型几乎不需要太多讨论,因为最后会不可避免地绕到技术官僚的话题上去. 这里我简单说说技术型创业团队的技术选型问题. 如果只能选择微软的技术路线,比如团队只会用微软技术,也不想学别的,那么似乎没有别的办法,将就一下吧.

技术团队看板方法实践的难点分析

- - csdnNews
CTO俱乐部看板研修班开课. 北京、上海、深圳三站火热报名中. 感兴趣的朋友可扫描左侧二维码加入看板公开课与路宁、何勉两位讲师直接沟通. 成功加入 CTO俱乐部会员并. 获赠6个月《程序员》iPad/Android版电子刊. 会员权益:个人主页、定期餐叙、最新周刊、折扣优惠、《程序员》杂志、大会门票、人才招聘、每月赠书等,.

关于技术团队管理的胡言乱语

- - 博客园_知识库
  临近年底,接到《程序员》杂志的邀请,希望我能写一篇与团队管理有关的年终盘点文章,盘点2013年业界与团队管理相关的大事. 试想,揪出各个公司在2013年的各种“大事”,指点江山,激扬文字,那种众人皆醉我独醒的感觉是相当的妙不可言. 可细细一想,2013年可以归纳为团队管理大事的事件倒是不少,例如Yahoo!美女CEO宣布取消在家办公制度,最近又按照绩效评估结果排名开始裁员;最近知乎上好事者提出的“你问什么离开xx公司”系列,各种回答纷至沓来,为2013的团队管理大事记提供了不少素材.

安全无小事--技术团队防守一二三

- - 五四陈科学院
以下内容由 [五四陈科学院]提供. 那天在使用某创业团队的APP时,输入完了微博账号还需要他自己的账号,于是就发了条微博,. 然后就有人@我是不是在说小米被脱库的事. 这里要讨论的是,如何让数千计的开发人员在安全防守安全编程上,得到有效的效果. 有人说,我干了xx年,手上从来没有一个项目出过安全漏洞; 还有人说,我一个人做的x项目,也从来没有出现过安全漏洞; 呵呵,集体的智慧不由个人意志来控制,木桶漏水取决于最短的一块.