读书笔记:技术管理实战笔记

Written by with ♥ on in 学习

01 | 多年前的那些工程师都去哪了?

技术人员可能的职业发展路径:

  • 技术
    • 广度:架构师:提供行业内业务的技术解决方案,例如金融架构、电商架构,与行业强相关;
    • 深度:科学家、机器学习、推荐算法、图像技术等…达到一定深度,个人认为走这条路首先要有科研背景,否则不太适合;
  • 管理
    • 技术管理者(CTO):负责产品相关技术事务,需要的技能:业务理解、技术判断、目标规划、团队建设、任务执行、沟通…
    • 职业经理人(VP):负责完整的业务,类似于内部创业,不局限在技术上,需要的技能:行业洞察、商业判断、资本运作、目标规划、公司经营、沟通…
  • 创业
    • 创业者(CEO):公司创始人,基本与技术关系不大,需要的技能:行业洞察、商业判断、资本运作、目标规划、公司经营、沟通…
    • 技术合伙人:与技术管理的区别是,从公司早期就共同创业做到高管的,属于共同创业者,承担创业的压力和风险,不像成熟公司的技术管理,侧重点不一样
  • 顾问
    • 投资人:必须有丰富的企业经营管理经验、宽广的视野和敏锐的洞察力;
    • 管理顾问:提供培训,咨询服务,偏人力发展和团队建设

根据样本统计,10 年后继续做技术的比例不超过 20%。大多数技术人员都需要学习更多的跨领域知识才会有更大的发展,很多的能力是相通的:项目管理、带团队、沟通、执行能力…

刚开始工作时作为工程师,提升自己的技术实操能力,随着能做的事情越来越多、越来越大,提升整体架构能力,成为架构师或者对每个领域越来越精通,成为技术专家,这个方向基本上 5 年就达到收入的瓶颈。后续需要不断拓展项目管理能力和带团队的能力,成为技术管理者、合伙人、创业者。当你越来越关注行业发展、商业逻辑、公司经营,就慢慢拥有了职业经理人和公司创始人的视角;当越来越关注资本运作和资本产生的价值,就会从投资人的角度去看待各行各业和整个社会。

因此,职业发展需要围绕技术和管理两条腿走路,一条腿是走不远的。

02 | 我要不要做管理呢?内心好纠结!

管理的价值:招聘面试、辅导员工、向上汇报、开会沟通、流程梳理、资源协调、进度推动、绩效评估等

关注团队:

  • 工作目标
  • 新人培训
  • 项目协调
  • 流程优化(避免同样的错误)

管理需要学习的认知和能力:

  1. 更大的责任
  2. 更立体的视角:考虑上级、下级、平级的期待和诉求,系统性看问题,关注过去和未来
  3. 灵活的思维方式:很多事情是没有对错的

03 | 哪些人比较容易走上管理岗位?

向上级明确表示自己的意愿。

如何走上管理岗位:

  • 天时:选择的行业(是否快速发展)和公司(是否固化),去能积累的公司,也要看机缘
  • 地利:个人优势、能力,负责的工作内容:
    • 负责最全局的模块(核心是广),容易得到全局视野、积极的沟通和协调能力,和很多人建立起合作关系
    • 负责最核心的模块(核心是深):掌握着团队最核心、最重要、最有技术含量、最能体现团队价值的模块的工程师,是团队里的骨干,不可或缺的技术核心,容易得到上级重视去承担重任。他们往往影响力比较大,所以容易走上管理岗位,不过常常是被动的
    • 没有负责这样的模块,是不是就没有机会了呢?主动去了解技术和业务的全局,并主动争取做一些大型项目的负责人
  • 人和:得到他人的支持:
    • 上级
    • 平级(管理伙伴、同学、朋友):交流经验
    • 导师(指导人、管理教练…):多交流,多听取看法和意见
    • 家人:情感支持

例子:

即使没有机会,在编码工作之余,关心项目流程如何改进,团队合作的机制该怎么建立,新员工入职如何培训,团队的氛围该怎么建设……虽然我之前并没做过这些工作,上级也不会因此就给我多发薪水。

但是我还是用心去做了,而且越做越拿手,团队里的同事和上级经理也慢慢认可了我的贡献和价值,部门经理也扭转了对我的看法,于是他把我的直接经理调去负责更大更有挑战的业务,提拔我来负责我们团队。从此,开启了我的十年管理之路。

所以你看,想被提拔为一个管理者最好的方式,就是你首先成为一个实际上的管理者,我们常常把这样的晋升理念叫“既定事实”,而这种理念在互联网行业里被广泛认同。

04 | 我要不要转回去做技术呢?

不要。

把技术作为工具看待。

05 | 作为技术管理者,我如何保持技术判断力?

不要被技术所限制,转换对技术的态度,看成一些能解决问题的工具。

作为工具的调配者,有三个维度进行评估:

  1. 结果评估:做一件事情,解决什么问题,希望拿到什么结果,你要从哪几个维度去衡量结果,从哪几个技术指标去验收成果。在项目开始之前就要考虑结果验收,关系到每个人工作的效果和业绩,至关重要!!!
    • 例如:提升服务稳定性,去完善服务架构
    • 提升数据准确性,去改写数据采集程序
    • 提升性能指标,去重构数据读写模块
    • 等等,无论如何,你心里都需要很清楚,用什么技术指标来衡量团队的某项技术工作,而不只是完成一个个项目
  2. 可行性评估:
    • 能不能做?其实一般都是能做的,除非太离谱的需求
    • 值不值得?收益 - 成本 判断是否值得,几个人用的系统改造个屁,主要看成本:
    • 人财物时等资源成本
    • 机会成本(放弃做其他项目的机会)
    • 协作成本(根据参与人数增长)
    • 维护成本:
      • 技术选型成本:新技术、旧技术
      • 技术升级成本:架构扩展的成本,有些东西不能写死
      • 问题排查成本:debug 的时间
      • 代码维护成本:可读性,其他人维护的时间
  3. 风险评估:在技术上是否有风险

06 | 管理风格

每个人都有自己的风格。也不可能有一样的风格,每个人的价值观都是不一样的。

  1. 指令式管理:重事不重人,关注目标和结果,喜欢发号施令但不亲力亲为。
  2. 支持式管理:重人不重事,希望带头冲锋亲力亲为,特别在意团队成员的感受,并替他们分担工作。
  3. 教练式管理:重人也重事,关注全局和方向,并在做事上给予教练式辅导和启发。
  4. 授权式管理:不重人也不重事,关注目标和结果,不关心过程和人员发展。

根据不同的情况使用不同的管理方式。

不过,不同的风格,在不同的场景下,的确会有不同的适用程度,我就简单列出几个场景做一些说明:

当一项工作不容有闪失,而你又是唯一熟悉、且最有掌控力的人时,一个命令式的你可能更能降低风险、达成目标。所以,命令式管理最适用于需要强执行的场景。

当一个团队特别需要凝聚力和斗志,需要攻坚的时候,一个支持式的你会促成很好的效果。所以,支持式管理特别能带团队士气和凝聚力,在带动大家热情和积极性方面很有优势。

当有一些核心人才需要重点培养,团队需要发展梯队的时候,一个教练式的你会带来明显的效果。他们不但能把事情做好,个人能力还能成长。虽然执行速度通常不会太快,但是不会偏离方向。

当团队梯队很成熟,团队成员需要发挥空间的时候,一个授权式的你能提供最恰当的管理方式。

当然,如果你能驾驭多种风格,那是非常厉害的。大部分管理者都还是以自己最拿手的风格来带团队,其他方式仅在必要时使用。

08 | 管理到底都做哪些事儿?

技术有技术图谱(环境是固定的),管理没有管理图谱,在不同的时代背景,不同的行业,不同的公司,不同的业务下有不同的选择。

管理制造业工厂讲究胡萝卜加大棒,追求严格管控。而互联网行业,更多是靠激发内驱,弹性工作制也好,发挥员工优势也好,都是希望员工更主动、自主,从而有更多的创造力(提升员工福利,体验…)。

因此管理没有一个通用的定义。但不妨看看管理界大佬下的定义:

  • 古典管理理论的代表人物亨利·法约尔认为,“管理是由五项要素组成的一种普遍的人类活动,这五个要素是:计划、组织、指挥、协调和控制。”由此可以看出他特别关注管理的过程性,强调“做事”,不愧为“管理过程学派”的创始人。
  • 科学管理之父弗雷德里克·泰勒认为,“管理就是确切地知道你要别人干什么,并使他用最好的方法去干。”他关注的焦点在于干什么,以及怎么干,有明显的目标性和方法性,强调“目标”和“做事”。
  • “现代管理学之父”彼得·德鲁克认为,“管理是一种实践,其本质不在于‘知’,而在于‘行’;其验证不在于逻辑,而在于成果,其唯一权威就是成就。”他这个说法的焦点在于实践性和结果性。众所周知,德鲁克是“目标管理理论”的创始人,尤其强调“目标”。
  • 当代管理大师斯蒂芬·罗宾斯给管理的定义是:“所谓管理,是指同别人一起,或通过别人使活动完成得更有效的过程。”这个说法的背后蕴含着管理的三个要素:人、过程和有效,用正式一点的词汇叫组织性、过程性和目标性,强调了“带人”“做事”和“目标”。

大家都很强调目标,也就是结果。能达成结果的方法就是好方法。

带人、做事,简单说就是人和事。

一个粗略的流程(驾驶马车):

  1. 认识到自己的角色所处的位置,带哪些人,做哪些事
  2. 出发前明确目的地,到目标的途中有很多细分的任务,目标管理
  3. 控制很多马齐心协力把车拉倒目的地,团队建设,人员管理
  4. 到达目的地完成任务,中途可能会调整目的地,会延期,任务管理
  5. 与团队外的环境沟通,上级,平级,其他团队,客户等等,管理沟通

角色认知、管理规划、团队建设、任务管理和管理沟通

img
img

09 | 从工程师到管理者,角色都发生了哪些变化?

对自己角色的认知不同,会产生不同的底层行为,当你以管理者的角色要求自己时,就会对怎么做产生不同的见解,就像这个问题:我是老板会怎么做?

直接从身份层,影响价值观层,进而影响能力,行为。俗话说的看一个人的屁股坐在哪里

img
img

从工程师角色到管理者角色,有多个方面的不同:

  • 工作职责:不只是做好技术
  • 负责对象:不只是对自己负责,还要对上级给的资源,下级的发展和成长负责
  • 关注焦点:工程师只需关注自己手上工作的进度,管理者需要关注整体的进度,时刻关注目标和结构,当前的进度
  • 工作内容:工程师只需要发挥专业能力,管理者要做成一项工作,除了技术判断力,还需要目标管理能力、团队规划能力、项目管理能力、沟通协调能力、团队建设能力等等
  • 任务来源:工程师的工作任务来源,主要是上级安排,听上级指挥;而管理者的工作内容,虽然也有上级工作的拆解和安排,但更多是靠自己筹划,然后和上级去沟通确认,从被动“等活儿”变为主动规划
  • 实施手段:大部分工程师的工作还是要亲力亲为的,因为工程师角色是个人贡献者角色,所以主要靠自己完成。而管理者的工作清单涵盖了整体团队的工作,靠自己一个人是无论如何都做不完的,因此主要是依靠团队来完成。
  • 合作维度来看。工程师主要的合作内容就是和平级的伙伴共同做好执行,因此主要以平级合作为主。而作为管理者,合作的内容非常丰富,比如,需要和上级合作规划好整个团队的目标,和下级合作做好落地执行,和平级管理者合作完成联合项目,有时候还需要和平级的上、下级去一起协调资源和进度。所以合作的维度变得非常立体。
  • 从和团队成员的合作关系来看。之前做工程师的时候,和大家都是平等竞合关系,以合作为主,也有“竞”的成分。
  • 执行思维和规划思维
  • 技术视角,工具和陷入细节

img
img

10 | 新经理常踩的坑儿有哪些?

六大误区:

1. 过程导向,被动执行

  • 不主动找活儿干,总是等待上级派活儿,如果上级没有明确安排,就“放羊”。
  • 即使上级有了安排,还总是指望上级替他做决定该怎么做,选哪个方案。
  • 在和上、下级沟通中,他主要充当“传话筒”的角色,常用句式是“老板说……”“某员工说……”,并没有反思每次沟通要达到的目的和效果是什么。
  • 过于关注苦劳和付出,常见说法是“某某还是不错的,没有功劳也有苦劳。”

工作被动,还是认为自己是执行者的角色,而不是管理者的角色,不能做决定。没有站在管理者的角度想问题,定方向,定目标,定方向。

2. 大包大揽,唯我最强

  • “某某做得太慢了,还是我来做吧,他半天的工作,我两个小时就搞定了。”
  • “团队离了我就不转了,里里外外都靠我操心,他们都担不起这个责任。”
  • “某某的工作主要靠我……”“在我的指导下,某某才……”“这件事主要是我做的……”

不能放权,过于关注每件事的细节,所有事情都自己做了,不能培养下属。

3. 带头大哥,当家保姆

两个极端,做下级的大哥,给能力强的员工做保姆都是不可取的。

4. 单一视角,固话思维

不要因为某一个条件不具备而否定所有的可能性,思维模式非常单一,很多问题都可以创造性地解决,绕过去。

  • “人手不够,没人,这真做不了,要做就得招人。”
  • “让团队加班的话,得给大家发加班费,不然没法提升积极性。”
  • “像某某那样的人才适合做管理,我跟他太不一样了,所以不适合做管理。”
  • “还有个 Bug 没修复,不能发布,我们一直都是这么规定的。”

5. 自扫门前雪、固守边界

应该以全局目标为己任,尤其是职责边界的地方,只做自己的事情导致:

  • “这个是测试的问题,这个是产品的问题,这个是别的部门的问题。”
  • “产品经理一点逻辑都没有,没法沟通。”
  • “这事不赖我们团队,是某某团队没有按时完成。”
  • “我查过了,不是我们的问题,惩罚不到我们。”
  • 项目推进不畅,从而影响全局的结果
  • 自我设限,因此个人成长受限
  • 个人影响力无法扩展,因为目光和手脚都局限在团队内,所以无法在更大的范围产生影响力,也就无法成为更高级的管理者

6. 患得患失

不写代码感觉吃饭的家伙没有了,执着于技术,不能投入管理,造成犹豫反复,成长缓慢。这是对技术的看法太狭隘,管理和技术不是对立的。

11 | 我刚开始带团队,从哪里着手呢?

这就从管理的上层理论进入到实践层面了,对于做技术,是胸有成竹,对于带团队做事情则茫然无措:

  • 季度交替、年度交替之际,如何汇报阶段性工作,如何抓住核心
  • 工作中各种问题,手忙脚乱,各种不靠谱
  • 新接手团队,不知道如何去带

上面这些问题都是不可避免的,在正常的管理工作范围之内,对于管理问题的困惑和技术问题不一样,这些问题导致管理者一下子陷在问题里,期待解决掉这些问题之后,一切事情都好了,是典型的问题驱动型思维

例如大禹治水的故事,刚开始采取堵漏的方式解决问题,效果并不好。在从之前的失败中吸取教训,采取疏导的方式来治理,引导洪水流向某个一方向,才产生效果。

在工作上也是如此,当你忙得焦头烂额的时候,如果只关注眼前的堵漏工作,没有一个全盘规划的指引,不清楚把团队往哪个方向待,早晚会失败。

能否有一个清晰的规划也是领导力的差距所在,即规划驱动型思维

回答:把团队带往何方?,理清未来的发展,从而理顺当前带团队的思路。

第一个问题:团队的职能和使命是什么?

说白了还是结果导向,以结果反推过程。

弄清楚团队需要完成什么样的职责和使命,决定了团队的工作目标是什么,通过哪些指标来衡量目标,决定需要什么样的人加入你的团队,投入哪些资源到团队中。

这是管理工作的起点,而此时我最关心的是,你是否可以毫不迟疑、非常简练地说出你团队的职责和使命呢?

一般来说,职责是必须要完成的,完不成就会被批;而使命是你想要的最好的状态。

第二个问题:团队的目标是什么?

设定目标后才能决定哪些事情是重要的,实现资源的配置。

第三个问题:盘点团队有哪些资源?

核心是团队内部的建设,如何完善内部的资源配置。

第四个问题:选择走哪条路?

有了职责、目标、团队,接下来就应该执行了,但是在此之前,需要看看有哪些路可以走,不同的路需要不同的资源:

选择完成目标的路径,是稳扎稳打,还是烧钱抢占市场都会有不同的计划。

不要混淆路径选择和计划制定,这两者最大的区别在于:路径选择主要是为了预算资源,制定计划主要是为了执行过程可控。

规划四要素:

  1. 职能:你是干什么的,基础架构,商业化,内容…
  2. 目标:你想要什么,带团队去哪里
  3. 团队:你靠谁,依靠谁达成目标
  4. 路径:你要投入什么,走哪条路,投入哪些资源

管理规划就是要说明白一个问题,你想要什么目标,需要投入什么资源。目标取决于团队职能,例如你的团队是做商业化的,目标与商业化相关,而团队是管理者的核心资源。一份合格的规划报告,至少需要体现职能、目标、团队、路径这四个要素。

12 | 如何界定我团队是干什么的呢?

明确职能

  1. 公司为什么要给我这批资源(团队)?希望我产出什么?
  2. 团队存在的独特价值是什么?增长、收入、赚钱还是对内服务?
  3. 用什么维度来衡量团队的价值高低?钱?服务稳定性?效率?客服接待数量?满意度?

例如 HR 是招人,研发是业务,商务是赚钱。

基本的职责和升华的使命

职责是团队职能的下限,即,至少要完成的工作,如果这些职责都搞不定,意味着团队的基本价值都不能体现。拿前端团队举例,基本职能是保证每个项目高质量开发和顺利发布,如果项目常常不能按时保质完成,就说明前端团队连基本的职责都不能胜任。基本职责是一般都是上级定下的。

使命是团队职能的上限,做一些边界之外的事情,如果做得好,能承担更大的职责,体现出更大的价值。拿前端举例,在保证项目的高质量发布之外,还能做出一些通用组件、服务平台、行业标准,在整个前端领域有更大的影响力,就是领导为团队规划的使命和愿景。

一般使命和愿景不是上级指定的,而是团队管理者自己的规划和设想。如果做到了,就是非常亮眼的成绩,团队也会受到很大的激励和鼓舞。如果没有使命,可能团队很快就会失去激情,只满足于完成基本职责!

设定团队职责和使命的方法和步骤:

  1. 收集信息
    1. 向上沟通:听听上级对你团队的期待和要求,以及希望用什么维度衡量做得好还是不好
    2. 向下沟通:和大家探讨对团队业务的看法和理解,以及对未来发展的期待,为以后沟通做好铺垫
    3. 左看右看:职能定位的边界,最好和兄弟团队的职能无缝对接
    4. 你的理解:对业务的理解,对领域的理解,对团队的期待,对自己的期待。团队的更高指着,往往来自于你的设想
  2. 提炼和升华:团队的职责和使命必须要传达下去,为了方便记忆和传播,必须进行提炼和升华:
    1. 职责的提炼:简短华提炼,保证长时间稳定
    2. 使命的升华:结合现实情况,公司状态,行业发展趋势,基于结果描述使命
    3. 确定衡量维度:指标维度,例如服务端的性能、稳定性、扩展性等维度
  3. 确认和主张:上级沟通确认,内部确认,最好是在合适的场合,比如季度会、合作沟通会等,有计划、有步骤地把团队的职责和使命宣贯给大家。团队职能的设定和宣贯是一个长期工程,不要期待一蹴而就。当然,如果做得好的话,效果也很快就能显现出来。

13 | 如何为团队设定合理的目标呢?

职能、目标、团队和路径

明确了职能和使用,下一个问题就是,未来的一段时间里,三个月、六个月也好,一年也好,你希望带着你的团队抵达一个什么样的目的地呢?

目标并不意味着让团队有事干那么简单。更多情况下意味着:

  1. 你和上级的诉求,希望收获的东西
  2. 资源的有效配置(资源围绕目标获取)
  3. 执行力,清晰的目标是高效执行的必要条件
  4. 团队凝聚力
  5. 激励,自驱力

踮起脚尖能够到的目标最合适。

SMART 原则:

  • Specific 明确性
  • Measurable 可衡量性
  • Attainable 可达性
  • Relevant 相关性(与上下游相关)
  • Time-bound 时限性(完成时间)

目标描述形式:

第一种,可量化指标,通常是指 KPI(Key Performance Indicator,关键绩效指标),到某个时间点,什么指标达到什么数字

第二种,不可量化,以关键结果衡量,例如 KRA(Key Result Areas)或 OKR(Objectives & Key Results),到某时间点,完成什么工作,该工作实现了哪些功能或达到了哪些效果。

几个常见问题:

  1. 基于现有资源做目标,而不是基于远方的目标往前推,应该做到以终为始的出发点
  2. 目标不明确,主要强调“我做了什么”,而没有交代做完这些工作后,取得了什么效果,没做到结果导向的描述
  3. 向下同步
  4. 目标总是变来变去,解决方法:设定专业目标

团队和人一样,如果没有核心的目标,总是被外在需求牵着走,内心必然会充满焦虑,还是需要弄清楚自己的内在追求。专业目标就是为团队树立明确的内在追求,由你和团队自己设定,属于自我要求,新的管理者往往忽略不做,内在目标的设定,最能体现管理价值,也最能展现自主性。与专业目标相对的是业务目标,也公司上级压下来的 KPI 和 OKR。

专业目标设定的核心步骤分为两步:

  1. 选择你要提升的关键维度,从团队的职责出发,确定关键维度,比如服务端团队的稳定性和性能,数据团队的准确性和安全性,功能迭代团队的高效和质量等,可以把半年内提升 40% 的并发性能作为团队的专业目标来不断修炼团队的内功。
  2. 设定目标,根据情况时有 KPI 和 OKR

14 | 如何来规划团队的组织结构呢?

团队规划三个视角:

  • 团队目标
  • 资源
  • 人才培养

简单总结就是团队职能是做啥,团队需要多少人及哪些人,团队的规划和人才培养。归根结底就一个字“人”。

目标

  • 完成目标需要的团队规模
  • 团队的分工,分为多少个业务块,每个块多少人
  • 梯度,不会因为某个人离职而产生巨大的影响

资源

从资源角度看,每个团队每个人都是人力资源。资源都有其固定的价值和成本,在互联网公司,技术团队往往是最昂贵的资源和成本。预算人力实际上就是预算资源。作为管理者要有成本意识,要考虑投入这么多资源和成本是否值得,要说服上级给你这些资源,如何推算要多少资源:

  1. 取决于对业务的理解和希望达成的目标,以及选择的手段(烧钱模式和稳扎稳打模式),因为投入的人力和目标息息相关
  2. 参考行业资源配置,其他公司有多少人

人才培养

重点培养的都是团队最核心的人,包括最有潜质的人,一般只涉及直接下级。做规划时,涵盖重点人才的培养目标。(现在互联网都不招 35 岁以上和应届毕业生,人才培养上堪忧,都想招来就能用。)

15 | 我都要申请哪些资源呢?

弄清楚完成目标需要多少资源,用哪些资源解决问题。

所谓的资源,账面就是你手里有那些牌;所谓的手段,就是你要如何出牌;所谓的人才,就是怎样抓到想要的牌。手里的那些牌上是你的账面资源,潜藏的资源其实还包括已经出去的牌、你对于对手的研究、你出牌的策略、你的资本底线、你的运气等等;想要真正的赢,达到最终的目的,方法可能千万种,如何取舍及选择,以最小的代价达到最大的价值就是你的目标;人才难得,就跟你想要抓到你想要的牌面一样,也许一张好牌被你随手丢掉了,也许你根本都不需要一张好牌,也许不太好的牌同样能赢。打牌如是,管理亦是如此。把资源理清楚、把目标定明白、把视角望远方,相信一定能有成就。

资源丰富性

资源不仅仅是人、财、物。

  • 财(团建费用、培训费用、差旅费用、办公设备等等都是基于人数)
  • 时间(允许花多少时间完成,根据目标特殊性,可能超过某个时间就不要做这件事了,或者可以直接购买)
  • 信息(某些特殊的数据?)
  • 权限(是否能定绩效,是否能发奖金,作为激励手段,是否能参加某个会议)

当你评估一个平台是否有发挥空间时,可不只是看职位高低,人员多寡。你能否得到全方位的支持,也是很重要的因素。当然,前提是你知道自己需要什么。

手段多样性

工程师出身的管理者,喜欢炫技,自己开发的产品才是最好的,一有机会就重构,“前人写的东西太烂了,不能忍受”。崇尚亲力亲为,凡事自己开发。

站在工程师视角上,追求工作的极致品质,恰恰是一种良好的工匠精神。但是站在管理者视角上,就需要评估一段时间内的产出效率了。衡量一项工作“到底需要花 5 天做到 70 分,还是 10 天做到 90 分”,是管理者的日常工作。90 分方案未必比 70 分方案好。

比如你想做一个新功能,诸如“人脸识别”“自动推荐”“反作弊”等。以下的做法是不同的管理者所采用过的:

  1. 自学自研:时间成本高;
  2. 招聘专业级人才:时间成本高,不确定性强;
  3. 借调工程师;
  4. 跨部门合作:沟通成本,合作成本高;
  5. 请外包或者外部专业人士兼职做:维护性差;
  6. 采购云服务:适合初创公司;
  7. 购买现成的解决方案:资金成本高,适合非核心业务。

人力资源的持续性

不少中小型公司的技术负责人或创始人,动辄想招聘某技术领域的资深专家。他们常常会这样说:

  1. 对于我们这个业务来说,数据很重要,我需要搭个数据团队,能帮我介绍一位数据大牛吗?”可实际情况是,自己连数据需求都描述不清楚,只是直觉上认为这能给公司带来价值,其实每天的数据量,拉个表格都能看清楚了
  2. 我们接下来要做智能推荐系统,得招两个专门做推荐算法的。但实际情况是,大部分数据都是格式化数据,却连最基本的推荐策略都还没做,还远远达不到专业瓶颈
  3. 我们需要招两个做专业图像处理和模式识别的。但实际情况是,公司业务的核心竞争力在于 O2O 业务,而不在于图像处理技术。

显然,他们太高估招聘能解决的问题了,而且太低估人才选用育留的成本了。事实上,牛人一般会嫌业务量小、平台小招聘不来,即便来了,成天形单影只的,也未必留得住。所以,招聘作为一种迟缓的解决问题的手段,更多地是看长线是否需要

对于工程师思维特别重的管理者来说,他们尤其倚重技术;对于不懂技术的管理者来说,他们又特别迷信技术。而职业的技术管理者,就需要在这之间找到一个平衡,提供一个既能够解决问题,成本又合理的可操作的执行方案,而不是一个“走一步算一步”的对策。

以上的三个意识如果你都具备,能够从资源丰富性、手段多样性和人才持续性来预算你的资源,说明你已经是一位老道的管理者了。我们通常会说,管理者要做战略,所谓战略是什么呢?其实就是筹划把资源投在什么方向,以达成什么目标。所以,资源视角就是战略视角。

至此,我们探讨完了管理规划的全部四个要素:职能、目标、团队和路径。细心的你也许会发现,探讨路径以及预算资源的时候,离不开目标和团队;而盘点团队的时候,又脱不开目标和路径;而设定目标的时候,也需要基于当前团队的情况和可用资源。

也就是说,尽管我们是把目标、团队、路径分开来探讨的,但是这几个要素之间并不是割裂的,而是相互联系的。所以,只有你把这三个要素统筹起来,梳理明白,才能“产出”一份完整的管理规划。

16 | 团队建设该从哪里入手?

个体:能力培养、员工激励

个体之间:团队分工、协作水平

整体:梯度建设、团队文化

17 | 如何提升员工的个人能力?

– 做事–

25 | 多任务并行该如何应对?(做什么)

  • 研究管理规划是为了做对的事情;
  • 研究团队建设是为了理顺做事的主体(人);
  • 研究任务管理是为了把事做出来,产出实实在在的业绩和成果;

作为有效性为导向的管理者,任务才是管理工作的落脚点,也是验证管理规划是否合理、团队建设是否有效的最重要的标准和依据。

大部分执行问题的主要症结都不在执行本身,而在角色认知、管理沟通、管理规划和团队建设上。

分为:

  1. 做事之前:要做哪些事,先做哪些事,后做哪些
  2. 做事过程中:有效地推进执行
  3. 做事之后:复盘整个过程,并从过去的经验之中抽取一些流程机制,以便以后在类似的场景下也可以做得更好、更顺畅

任务管理三要素:事前的轻重缓急、事中的有效执行和事后的流程机制

实际上,对于每个团队来说,当下能做的工作是有限的,增加并发并不会让大家的产出更高效,所以,多任务并行问题归根结底还是优先级问题,即,你要优先保证哪项工作的顺利进行。

如何判断重要紧急程度:

  1. 老板刚刚口头交代的临时任务,这到底是紧急重要的、紧急不重要的,还是重要不紧急的呢?这个场景常常被倾向于认为是紧急重要的情况,必须如此吗?
  2. 锻炼身体、学习培训常常被倾向于认为是重要不紧急的事情,情况真的如此吗?

对于上面的这两个场景,不同的人、不同的上级、不同的任务和不同的情况下,可能会被归入不同的象限,这并没有一个可供遵循的一定之规:

  1. 如果做,收益是否很大?收益越大,这个事情就越重要。
  2. 如果不做,损失是否很大?损失越大,这个事情就越紧急。

在实际的工作中,我们经常做的并不是梳理轻重缓急四象限,更常见的情形是,我们要把日常的工作分为两种情况:一种是计划内的,也就是按照我们的规划进行的;另外一种是计划外的,即突发的情况和任务。

  1. 对于计划内的任务,我们更关注在一个规划周期内的价值和收益有多大,把价值足够大的任务安排进来,并持续往前推进
  2. 对于计划外的工作,由于是一种突发情况,是否要中断既有安排来高优先级跟进呢?中断既有安排一定是会影响正常推进的收益的,所以我们要做的决定是,是否要立刻跟进?如果不立刻跟进,带来的损失有多大?我们是否愿意并能够承担?如果不能,那就立即跟进。如果可以不立即跟进,那就转化为一个可以安排到计划内的工作,并参考第 1 条的策略就可以了

总结起来,对于任何工作任务,决策的步骤就两步:

  1. 对于“计划内工作”,看收益是否足够大。收益越大就越重要,也就越需要给予相匹配的优先级、资源和关注度;收益相对不大,就放入“To do list”,作为待办任务处理。
  2. 对于“计划外的工作”,看损失是否足够大。损失够大,就按照紧急任务安排,以止损为核心目的;如果损失可控,就放入“计划内工作”列表。

关于任务优先级的安排,除了决策的步骤和方法,还有几个重要的原则:

  1. 目标是需要一以贯之的
  2. 任务安排是弹性的
  3. 沟通是不可或缺的

26 | 如何确保项目的有效执行?(怎么做)

  • 充分条件视角:列出所有任务,一个一个实现,不可能实现,一定是会变的
  • 必要条件视角:必须要做的任务(可行)

目标清晰

有哪几件事做不好,就必然会引发项目执行过程的不可控呢?

  1. 目标不清晰,导致在紧急程度、质量水平、效果上的偏差:
    • 目标不够明确具体,至少没有具体到执行人员可以执行的程度
    • 上、下级对目标的理解看似一致,实则有偏差,尤其是对进度、质量和效果的拿捏上
    • 目标发生变化了,没有及时同步给相关的人员
    • 例如:
    • 虽然你很清楚做某项目的初衷,但是并没有去设定可以衡量的目标。比如某次技术重构、某个模块性能优化等。也就是说,虽然你知道自己想要什么,但是不知道出于什么原因,你没有设定一个清晰可衡量的目标,而目标不够清晰的话,必然会引发时间预算、人力预算,以及优先级决策的模糊
    • 虽然在你眼中目标很清晰,比如“到年底某模块单机性能达到 500qps”,但是负责项目实施的员工并不知道该从哪里下手去执行
    • 在你看起来,两周能搞定的事情,员工却花了 3 周时间。诚然,完成质量的确很高,可是和质量比起来,你更希望在 2 周内发布
    • 项目交付时间提前到这个周末了,员工没有完成,可他为什么还一副很无辜的样子呢
    • 项目是如期发布了,可是这不是你想要的效果啊

责任明确

项目总负责人缺位(确认负责人)

机制健全

过于依赖人的主动性,缺乏基本的流程和机制,虽然有机制,但是没有人监督执行。虽然机制有人监督执行,但是大家依然不愿意执行

  • 如果 A 也像 B 那么积极主动,这个项目就不会出问题了,所以 A,你能不能更主动一些呢?
  • 我们明明约好了有问题及时通报,为啥总有些人不通报呢!
  • 我们各种各样的流程都有,很完整也很系统,但是大家就是不按照流程办事……

这些问题的原因是,我们见识过某些优秀人员的优秀表现,产生过于迷信人的主动性和职业水平。出现问题的时候总感觉是”人不行“。事实上,团队成员的能力水平都是正态分布的。如果真的是“人不行”,那么人从“不行”到“行”也会是一个缓慢的过程,而此时此刻你就得做事,那你打算怎么办呢?这就要靠流程和机制了。

于是很多管理者就制定了全套的流程让团队遵循,但由于学习和执行成本很高,员工遵循起来非常痛苦,因此就干脆让流程机制去“睡大觉”。这也是很多团队的真实情况,他们有很多流程机制、规章制度的页面,但是还是做不好项目。

开发 -> 测试 -> 上线 流程。

沟通到位

信息不对称。

  • “我通知了啊,为啥他们就是不听呢?”
  • “对方有问题不主动找我沟通,关我什么事!”
  • “我不知道啊!什么时候变更的?”
  • “不是说好了周五交付的吗,他们没有如期交付啊!”

大家在一些事情上没有达成共识,由此产生了协作上的偏差和误会。原因可能是对信息本身的理解就不一致,也可能是没有有效传递和同步,总之在沟通这个问题上有诸多的不顺畅,归结起来就是:

  1. 主动意识不足,沟通不够主动。
  2. 通报意识不足,没有知会到所有相关人员。
  3. 闭环意识不足,广播出去了,就默认对方收到了。

当然,关于项目得不到有效执行,也许还有许许多多的其他问题,就好像“不幸的生活各有各的不幸”一样,项目执行不好也各有各的原因。上面我们阐述的,只是最常见的四类问题。如果你的项目没有这四类问题,不见得一定执行良好,但是如果出现了这四类问题中的某一类,执行上一定会有问题。

所以,我把避免这四类问题的钥匙归结为“有效执行四要素”,即目标清晰、责任明确、机制健全和沟通到位,以方便我们梳理和诊断执行问题。

27 | 如何让流程机制得到有效的执行?

一个问题:自己开发质量很好,做管理没有时间,授权给别人,各种问题,怎么办?

关注结果,关注培养人,能够兼顾做事和培养人,那自然是很美好的。但如果两者不能兼顾的时候,就需要非常清楚我们优先保证的是什么了。

要想让员工分担我们手头上的工作,要么靠梯队,要么靠机制。

靠梯度就是团队里有胜任度非常好的人。

靠机制就是设计一套方案,专门应对某个场景出现的问题,这套方案可以指导和搀扶着员工做好这类工作。带着员工一起做,不是会产生更好的效果吗?你说的有道理,但是这样做的最核心的目的达不到,即,要减轻管理者的负担和精力开销。

如何建立机制

找到流程中的关键点,进行检查(做某个任务的单元测试,检测一些关键点)。

  1. 首先要明确该机制要解决什么场景下的什么问题,即明确目标
  2. 提炼应对该场景的关键点
  3. 明确由谁来确保机制的执行,即谁在什么时候检查什么关键点
  4. 确认操作成本
  5. 沟通,并和其他执行人取得共识

几个原则:

  1. 可操作,即简单原则
  2. 只打关键节点,即关键原则
  3. 明确到人,即问责原则(谁负责监督机制运行,小惩罚)
  4. 从 case 中来,到 case 中去,即实用原则

观点:

  1. 机制不是越多越好,而是越少越好。这个观点和前面提到的关于机制的简单原则、实用原则一脉相承。你要明白一个道理:机制的建立并不会解决问题,对机制的执行才能解决问题,而机制的建立、执行和后期维护都是需要成本的,所以,千万不要贪多,在风险可控的前提下,机制能不建就不建,能少则少。
  2. 关于到底是人靠谱还是机制靠谱。很多管理者都认为,事情都是人做的,人如果足够靠谱,机制就没什么用了。对此,我的看法是,人的靠谱度的方差比机制大,即,人靠谱的时候比机制靠谱,人不靠谱的时候会比机制更加不靠谱。即便是最靠谱的员工,也会由于身体状态、精神状态、情绪状态以及外部干扰变得偶尔不靠谱,而机制的意义就在于,当人不靠谱时,事情也不至于变得很差。所以,机制是为了保证做事的“下限”的。同时,机制有很好的迁移性和传承性,不会随着某个人的缺位而产生大的影响。因此,必要的机制是不可或缺的。

28 | 管理沟通那些事儿