当我在做技术管理时我在做什么互联网科技程序员

当我在做技术管理时我在做什么 - 3. 人 - 团队管理

2017-02-10  本文已影响527人  hirainchen
上一节 2. 序言

人 - 团队管理

核心思想: 以人为本

团队是由一群追求一个或多个共同目标的人组成，通过一些规则约束在一起工作。人多不一定是力量大，也可能是人多手脚乱。要让一个团队高效协作，核心原则必然是以人为本，让每个成员在自己的位置得到最有效发挥，让个体与整体相互触进成长。

我把团队管理分为6个方面：

  1. 定组织架构 - 要招什么人
  2. 招聘 - 怎么招人
  3. 培养 - 招到的人怎么培养
  4. 考核 - 要不要继续培养
  5. 效率管理 - 要培养成高效人材
  6. 情绪管理 - 是人就有情绪

1. 定组织架构

所谓“成大事须合乎天时地利人和”，其中天时不如地利，地利不如人和。所有事情归根都是由人来推动执行，因此一个团队首先要有适合的人。

那是不是马上要讲讲怎么招人吗？不急，首先看公司的业务方向，根据公司发展的需要来选则所需要的人材组建团队。
所以成熟团队的管理方案中第一件事应该先定好组织架构，定下企业需要的岗位、职责、需要的人数。

这点其实跟做产品开发流程很像，得先有原型、设计图，然后才做实际的开发实现，实施成本才可控。

组织架构的科普：

企业组织结构是进行企业流程运转、部门设置及职能规划等最基本的结构依据，常见组织结构形式包括中央集权、分权、直线以及矩阵式等。
企业的组织架构就是一种决策权的划分体系以及各部门的分工协作体系。组织架构需要根据企业总目标，把企业管理要素配置在一定的方位上，确定其活动条件，规定其活动范围，形成相对稳定的科学的管理体系。

组织架构的作用简单来说就是公司的骨架，自上而下明确各个岗位的职责、管理范围、责任链，因此不宜经常大动大改。

Beansmile成立了3年多，目前做了2次调整，「图3-1」是Beansmile 2016年底定下的组织架构中CTO负责管理的开发部分

∆「图3-1」组织架构

2. 招聘 - 招人其实也是个技术活

有了组织架构（设计图纸）后可以招人了，然而招人这件事本身就是个技术活！

从哪里招？同行那么多要发什么样的招聘文案才吸引人？面试时要问什么？怎么知道对方是不是有料？什么样的人适合留下来？要给多少钱？

一大波的问题迎面而来！

有效过的招聘渠道大概有3种：内部推荐，专业招聘网站，社区论坛。

从实践结果来看，其中内推的结果最为靠谱。为了鼓励更多的内推，我在公司内提出推行了内推奖励机制：通过内部推荐应聘成功的，在试用期转正后，推荐人可获取一定现金奖励，奖励力度跟被推荐人被评定的职位等级挂钩，也就意味着引荐越有实力的人，引荐人则有高的回报，企业也能收获更有实力的人材，对企业而言是小投入高回报的策略。

另外为了让招聘文案“新鲜刺激有内涵”，在众多的招聘帖子中能吸引到小伙伴的眼球，我曾煞费苦心收集了大堆团队的日常照片，从中挑选一些有代表性，给每一张配上适合的解说词，合并成了一张457x8419 像素的巨长图（「图3-2」），得到一波好评的同时也给公司了一次PR。

「图3-2」 Beansmile的日常（@2015.4）

不同的技术岗位需要掌握的技术技能自然不同，因此刷选时也需要面试官对面试岗位技能都有所掌握，然而每一门技术的技能树各不相同，如「图3-3」。

∆「图3-3」前端工程师技能树

技术岗位都需要定一些面试题目来提高候选人筛选效率和标准化结果评估，因此我根据需要的引进的岗位制定一些面试题文档：

内容涉及对应岗位的编程知识、项目开发的流程及协作方式、解决问题的方法等，考察候选人当前的编程水平、项目经验、学习能力和工作态度，用以判断加入公司后的培养成本和周期。当然大家都知道，只是通过交谈是无法百分比准确的判定一个候选人是否完全符合预期，只有真正在一起工作时才能了解彼此。

目前所有进入公司的技术人员都是由我亲自面试过，因此引进的人员在技能方面是比较有把握的。

面试的过程其实很占用人的时间、精力的，对于每位上门的应聘者，我都会耐心的引导，避免由于面试的紧张导致应聘者没有发挥好从而给出错误的结论。因此即使没有面试通过的，也得到比较正向的反馈，见「图3-4」

∆ [图3-4] 面试反馈

最后面试的人多起来了，我们需要安排一面、二面流程提高面试效率，这时也需要制定一些流程规范来标准化从而提高招聘效率，因此我也将这个流程指定成规范文档，见「图3-5」：

∆ 「图3-5」Beansmile招聘流程

除了专业技能，我认为优秀员工的重要的品质有2点：

但这些是从短短一个小时的面试过程中是看不出来的，因此还要涉及到对新入职员工的考察，后面一节会讲到我是怎么做。

面试通过后、谈妥了offer后，就是入职安排。
入职过程不是到公司报个道就完事了，有相应的入职的流程、需要不同的人协作，如要安排Mentor、分配帐号、满试用期后考核等等，因此我提出并制定了一个[Beansmile新员工入职流程]，如「图3-6」

∆ 「图3-6」[Beansmile新员工入职流程]

企业都想找到适合的员工，所谓适合，其实就是有能力、企业能给得起钱。企业主不应总是对应聘者挑剔，懂得要马跑就要喂马吃饱的道理，这点是每个企业主自身要做好的准备，双方各取所需、共同成长，企业赚钱、员工涨薪才是最大的共赢。

3. 培养

经过了面试双方谈妥，人员入职到岗了，不能丢在一边“放养”。要想让新人尽快通过磨合，熟悉开发流程，掌握专业技能，尽早能独立完成开发任务，我采用以下几种方案：

引入Mentor制度

Mentor制，是指定了一名同类岗位、高一级别的同事作为“导师”，来带领入职的同事熟悉开发环境、开发流程、代码规范等，让新人尽快通过磨合，熟悉团队、有归宿感。我不认可那种一来就直接指派个任务卡片，丢下一句“自己看代码学习，这周内搞掂”的放养式管理风格。将心比心，人到一个陌生的环境，都是期待能得到一些简单的指引，有时只有简单几句话，也会有种安全感。

[Beansmile 新人提点注意事项]

这是我整理给Mentor的指导文档，一般的开发人员平时都只是做日常开发，一开始也不懂得如何指导新人，为了解决这种窘况，我整理了这么一份文档（「图3-7」），内容实际就是公司知识库WIKI中的一些内容的链接索引，另外特别强调了注意不要分享整个文档给新人，要锻炼他们自己的学习能力。

∆ 「图3-7」Beansmile 新人提点注意事项

code review：[Code Review Tips]

我们在日常开发中鼓励并推行code review（代码审查）。

在每个项目立项进入开发阶段时，我会根据开发组成员的级别设定审查链，按照 “中级审初级，高级审中级，高级互审”，没有合适的人时我来审查，开发任务完成后，任务开发者需要发Pull/Merge Request给指定好的审查者进行审查和合并，确保每次代码合并前都有2个人能看到过，一般只有在做演示出现exception，需要紧急合并做部署时才会跳过code reivew流程。

推行code reivew需要有2个人以上的协作，自然是有代价的，那有什么好处？
见「图3-8」中我在公司WIKI [code review tips]中给的回答：

∆ 「图3-8」code review tips

相当于另一种pair programing，大家的编程水平都能提高（无论是提出问题的，还是被指出问题的）

让一个新人融入团队没有比在一起讨论代码更快的方式了，特别是对于新人而言，对代码规范不熟悉，通过code reivew能有效减少低质量代码的check in，对个人、对团队、对项目都是很有益的一项安排。

至于要怎么做好code reivew这件事，需要另开新篇来阐述，「图10」中有review代码的要点摘要，在这里就不展开了。

「图3-9」是我日常进行code reivew 发现问题的一些总结，在团队内也做过一次专题的培训

∆ 「图3-9」 code review examples

∆「图3-10」code reuse - DRY your codes

特别提一下，设定固定的审查链的好处是减少审查者的负担，每个人只需负责1~2个的代码审查；阶级式的安排，可以让高级的不用反复的去提点低级人的一些低级错误，反复指出一些低级问题对高级人员是负担也是干扰，容易累积高级人员缺乏成就感的情绪（程序员的一个特质是喜欢有挑战性的任务）。

pair programming

结对编程的好处不用多说，我鼓励结对编程，但不会强制安排，不会要求像教科书般要求在某个时间规规矩矩的一个看一个写，实际上一般的情景是某个同事有问题时，需要找我或作指导的其他同事，拿上电脑大家坐在一起讨论、直接敲代码（「图3-11」）：

∆ 「图3-11」pair programming

内部培训、分享

团队的强大不能依赖个体，新知识只有一个人掌握时，不等于团队掌握了，分享出来团队技术才能成长。
在每周五下午，我会不定期的安排一些内部的培训，技术的、设计的、产品的，不限制领域，既是对个人的一次锻炼，又同时是给大家一个休息、坐在一起讨论的时间（「图3-12」）

∆ 「图3-12」内部培训

官方blog

知识的累积和巩固途径由浅到深可分为“听读写说”，但听别人说不如自己读书，读书不如动手练习写写，写不如说出来给别人听。能亲口说出来的知识掌握得最牢固，不过不是人人都有勇气在别人面前开口，因此我们设立了团队Blog，把掌握到知识“写”出来。

我会不定期给技术人员安排“功课”，给定一个主题和大纲，将一些开发的心得总结整理成博客文章，经我审查修订后发布到公司的博客上，这样即可以让当事人的知识更加巩固，又可以给其他同事作参考指引，另外还可以对外展示公司的技术能力和形象，可谓一举多得。

外部技术交流会

只是内部交流是不足够的，还要看看别人是怎么做的，做法很简单要么走出去要么请人来。
我们会不定期安排一些优秀的员工，参加的一些技术沙龙活动开拓眼界和学习。

我们会邀请其他企业的、行业的技术专家过来，给团队分享技术上的、产品上的、团队管理上的经验。

交流应该是双向的，我个人也会被邀请到其他技术团队、交流活动分享我的技术经验、心得，让外界了解公司技术实力。

我自己曾作为2015年的Rubyconf China活动讲师，跟现场300多ruby开发者们交流（「图3-13」）

∆ 「图3-13」Rubyconf China 2015

4. 考核

前面提到，除了专业技能，我认为优秀员工的重要的品质有2点：

但这些是从短短一个小时的面试过程中是看不出来的，因此还要涉及到对新入职员工的考察和审核，试用期就是很好的一个让双方了解磨合的阶段。

在前面提到的[Beansmile新员工入职流程]中，我要求Mentor在试用期结束后，需要对新人进行评价审查，而评价审查的大纲很简单：

  1. 基础
  2. 学习能力
  3. 态度
  4. 交流

1是考察当前能力水平，这点在面试时已经大概了解，相当于验证一下是否有水分，短短的试用期内也不大可能突飞猛进；

2考察个人潜质，对个人发展很重要；

3是看责任心和态度，遇到问题会不会主动找人反馈或协助？交代的任务超出预期时间不能完成有没有主动反馈给项目组长？

4是考察团队协作，对团队重要，有些程序员动手能力强但比较内向，沟通能力略有欠缺的，那就可以安排不需要很多沟通需要的任务。

一般初级安排1到2个月的实习，但基本上1、2周都能看出一些问题了，这时我是愿意给机会调整，看重后续的成长，但如果到了实习结束期都还是不行的，那就只能劝退了。

审查内容只有4点，因为写评价报告这件事对Mentor是开发工作之外的一种负担，我尽量简化文档/报告的复杂度，减少干扰，接下来效率管理就会提到具体怎么做。

5. 效率管理

核心思想：减少干扰

程序员最烦什么？最烦的不是任务有多难多重，而是在写代码时被干扰打断。为此我需要从沟通方式、工作流程、协作方式各种方面来解决干扰的问题，我大概归纳为“四化”：

沟通明朗化 - 限定沟通工具、使用好工具

为了减少对开发人员的打断，可以把需要沟通讨论的内容根据“轻重缓急”，粗略分为“紧急且重要”，“紧急不重要”，“重要不紧急”。

∆ 「图3-14」Slack example

另外还有一点要提的是，作为管理者应该有意识的界定IM工具的使用场景，我们工作时间使用Slack，这样只要是通过Slack发过来的消息，我们能第一时间意识到是有工作相关的问题需要讨论了，以便能及时作出反馈。Slack中按项目建立分组，所以往往只是看到消息是来自哪个分组，不用看消息内容，就以及知道大概是要讨论什么内容，自然在脑中切换上下文，提高沟通效率。

不建议使用微信/QQ作为企业内部的沟通工具，由于微信/QQ混合了非工作消息的通知，开发人员不能很好的区分开这是有工作消息、还是普通社交聊天消息，很容易错过重要的工作信息。但有人会说跟外部的人沟通时是避免不了使用微信/QQ，注意，这里说的是“企业内部的沟通工具的选择”，对外该使用什么的还是用什么，两者并不冲突。

工作流程化 - 不要每次都让我告诉你什么时候该做什么

在团队中，特别是进行软件开发项目时，需要有一定的流程指引，那么大家在一起进行工作时可以分工、分步协作，清楚知道自己、别人下一步会做什么，自己会不会被干扰，从而提高协作的效率。
为此我根据我们公司实际的需要，制定了一些规范文档，从接到项目需求，到项目评估、立项、开发、具体到代码提交、部署、验收都做了流程规范，例如：

∆ 「图3-15」Beansmile开发流程规范

定好工作流程，大家都能从中找到自己的位置和角色，知道在什么阶段要做什么、下一步做什么、要跟谁协作，不能有“一头雾水”的感觉。

开发自动化 - 把重复丢给机器

我提倡善用工具最大程度做到自动化，这种思维是贯穿整个开发流程各个环节的。

如最普通的Terminal（终端shell），推荐使用带交互的shell（如zsh/Fishshell）来辅助cli的操作，鼓励善用alias来简化重复的使用命令；

代码开发时鼓励使用支持自动完成的IDE、编辑器（如Sublime Text），鼓励善用代码snippet来减少重复编码的操作；

代码测试使用自动化测试（可配合guard或者livereload达到保存时自动跑相关测试）；

代码提交使用自动化命令（gitlab-send-merge-request of git-cmd-helpers），一步完成代码提交并发Merge request；

项目部署使用自动化部署工具（如Chef、Capistrano），做到一键部署；

使用CI（GitlabCI）进行自动化测试、自动构建、构建结果通知、自动部署、自动打包上传app package，达到DevOps的自动化；

服务使用健康监控（如Monit，God），自动监测服务健康并自动重启服务；

一句话就是尽量把重复的工作丢给机器去做，人力应该专注在机器解决不了的地方。

协作清晰化 - 让你知道什么时候要去找谁做什么

为了解决协作清晰问题，我们使用3种管理方法：

一个项目开发时必定会定下一些关键的时间节点，如什么时候开会讨论、什么时候开发结束、什么时候做演示、什么时候正式上线；公司内必会有人员活动的变化，如公共节假日怎么安排、团建、什么时候有面试安排、团队成员中必然会有事生病请个假什么的等等。
为了让这些跟时间节点、会影响到人员在线情况的事件在团队中清晰透明、避免冲突，我在公司里发起推行了“团队日历共享计划 - [Beansmile Agenda]”（见「图3-16」），这样大家都能有个清晰的预期，知道最近有什么短期目标、有什么事需要准备、什么时候有会议要开、哪个小伙伴会没有空。具体做法很简单，使用Google Calendar服务进行日历共享，客户端使用Mac Calendar查看，约定好事件的标题格式“[公司名-项目名] 事件类别: 事件标题”。
另外注意一点，在推行新制度时，使用流行的服务和系统自带的工具，可以降低推行阻力。

∆ 「图3-16」Beansmile agenda

但日历只能也只应该记录事件标题和日期时间，更具体的内容，我们在Trello上建了一个board来进行管理，如我们的团队分享安排、团建安排、假期的安排等。

至于更具体的项目开发任务，我们是使用独立的项目管理工具，在后面的项目管理章节中会提及。

6. 情绪管理

是人就会有情绪，了解员工的情绪问题也是管理工作的日常之一。在公司还没有强大到有专职的“程序员鼓励师”时，也只有亲身上阵，我推行了3种方式：

我自认为在这方面做得还不够好，InfoQ上有篇文章《技术团队的情绪与效率》 值得参考借鉴。

下一节：4. 事 - 项目管理
上一篇 下一篇

猜你喜欢

热点阅读