05-技术领导力全方位实践

参考资料：

1. 书籍：《技术领导力》.

1. 技术管理工作

1.1 技术管理

为什么技术管理难做？

1. 刚通过校招进人团队的A
   A:我有一个函数不会写， 我使用Spring框架时老是报错，能不能帮帮我?
2. 团队内工作3~4年的B
   B:我们对外的协议层性能不好，不知道怎么优化，能不能指点我?
3. 团队内工作5~ 6年的小组长C
   C:系统架构能不能给我点意见?技术选型怎么做?
4. 产品团队管理者D
   D:技术要符合产品需求，别谈什么技术追求，让你们做什么产品就先做什么。
5. 5)直属领导E、F
   E、F:你的编码能力怎么样，系统架构能力怎么样，项目管理能力怎么样，项目不要有任务延期，未来技术方向定出来，设计文档怎么写得这么差，对外沟通工作怎么做得不及时…..
6. 部门最高领导G*
   G:我们和同行、业界的技术差异点有哪些?为什么你们不用那个流行的某某框架?
7. 兄弟部门领导H
   H:你要站得更高-一些， 能不能讲讲未来几年云计算的发展趋势?
8. 文档评委I
   I:你们这个协议定得不够好啊。
9. HR接口人J
   J:团队氛围很重要，公司价值观要注入。记得要给新员工进行技术培训。
10. 专利部门接口人K
    K:专利也很重要。有没有开始专利布局?

作为技术管理者，无论具体管几个人，最好能拥有以下能力，才能满足各方面提出的需求：

• 深入理解一门或多门编程语言
• 深入理解多种流行的框架
• 系统架构能力强，拥有复杂系统的设计经验
• 积极跟随开源社区
• 积极了解业界技术发展
• 沟通能力强、情商高
• 有产品意识，不是技术迷
• 会带人，服从领导，责任心强
• 会写专利
• 再会点别的更好
• 随叫随到、工资不高

1.2 技术团队领导者

1.2.1 工作职责定位

一家企业能够生存，一定是业务开展得不错，作为技术团队管理者我们需要做到技术与业务的融合，需要保证我们的付出可以为企业带来长久的利润。只有成为“技术的业务派，业务的技术派”，才能让技术引领业务，并创造价值。这其实也是技术管理者成熟的标志。

技术管理，要有成就他人的心胸，同时还要有超出一般人的眼界，能够给予团队正确的方向。同时，要保持对技术的兴趣，多关注新技术的发展，否则你很难在重大的技术决策上做出正确的决定。

“你要维持一种正义和公平，这是非常重要的，不要欺负弱者。当你是强者的时候你欺负了他，他强了他一定会欺负你。有一种感恩的心理很重要，会把事情做得很好，否则没法维持”。

1.2.2 工作品质定位

18条品质：

• 成熟：重视诺言、不夸夸其谈、有学识而含蓄内敛、心胸宽广、不以自我为中心、勇于承认错误、意志坚定。凭自身的品格、实力与信誉在人群中从容地来去。
• 勇敢：硬汉本色，不惧怕外在威胁。团队成员都在看着你，你决不能懦弱，要勇敢。
• 热爱技术：我对团队的技术要求一直都是:“我们输出或者呈现给别人的技术能力，需要且必须是公司内部的技术权威之一，说是之一，是因为不能否定公司内部其他部门的技术能力。我们必须让别人知道我们是专家，我们团队很牛。如果被别人列举出我们团队技术不尽人意之处，我会认为这是对我人格的侮辱，只要我是这个团队的领导，我决不允许这种情况发生”。但有一点需要注意，只有做好当前的事情，才有资格谈技术理想。
• 勤奋：在不断更新的软件开发行业中，这并不意味着你不需要使用大学里学习的知识，而是除此外还需要不断地增加对新的技术、工具、方法、框架的深度认识和理解。
• 脚踏实地：在做技术选型决策之前，有没有做足充分的技术调研、产品调研工作，能不能尽量详细地说清楚已有框架、产品的实现原理、优缺点、是否适用于你的产品场景等，这些都是前期技术调研的工作，也是体现我们脚踏实地做事的一 个个环节。
• 逻辑能力：逻辑贯穿设计、建模、编码、调试、重构、沟通、学习、思考。
• 公平透明：无论是绩效考核，还是职位升迁，亦或是问题处理，都不应该由少数几个领导通过闭门会议的形式完成，而应该是通过制定逻辑严谨的规章制度，通过类似任职资格考核(团队建设部分会深人介绍)的方式完成初步考察，然后通过事情责任制方式明确个人的成绩、责任，最后通过有员工代表、相应部门代表参与的会议讨论决定，这样可以让整个团队朝着健康的方向发展，而不会让一部分人感觉被边缘化，从而滋生小团体。
• 一线作战精神：以身作则，关键时刻顶上去，而不是让团队处于流浪状态。
• 决策能力：开放的提炼能力、准确的预测能力、准确的决断能力；克服从众心理、增强自信心、不求十全十美但要把握大局。
• 开放姿态：开放、共享、追求极致。
• 为人处世：言行一致，知行合一。
• 真诚：真诚待人，谦虚内敛。
• 宽容：管理者要包容下属的缺点。
• 仔细：善于观察、思考，进而仔细。
• 终身学习：日拱一卒，保持持续学习的心态和行动。
• 时间管理：学会集中精力，善用碎片时间。按照时间管理四象限，做好待办与日程提醒的维护管理。
• 以人为本：绝对不能忽视团队里的任何人。
• 保持身体健康：身体是革命的本钱。

1.3 带领技术团队心得

1.3.1 传统型教育&创新型教育

传统外包、传统行业的IT部门：采用传统型教育能更好的完成目标。

游戏型：全部靠自己，最短时间内找到自己方向的管理者才能胜任目标。

1.3.2 自主循环

分组讨论、自主工作。

1.3.3 技术人员心态的四个阶段

• 感知：刚工作，知识需要学习，经验需要积累。有追求，就能学会付出。
• 深入：有一定的技术能力和学习能力，清楚自己的方向。从实际着手，也给他们独立思考的机会。
• 突破：这类技术人员遇到了技术发展瓶颈，渴望突破。适度授权、让他们一边自我实现，一边听到你的看法。
• 创新：能够按照自己的思路创新。此时你需要给予掌声、认真倾听、给予意见、一同参与。

1.3.4 找到属于自己的圈子

交流工作内、工作外的眼界、发展方向等。

1.3.5 何时成为技术管理者

没有恒定的标准，先打好基础。

在有50%时间做技术的同时，还能紧跟技术、细节的时候，你就可以给自己加上技术管理的工作量了。

1.4 个人职业发展

• 职业选择
  技术是罗辑思维，是智商；管理是非逻辑思维，是情商。系统问题需要智商，而人需要情商。
• 工程师等级
  吴军《硅谷之谜》中对工程师的理解：
  1. 第五等级工程师：能够独立设计和实现一项功能。基本要求。
  2. 第四等级工程师：有点产品头脑，考虑易用性、易维护性、稳定性、产品生命周期等。高级工程师。
  3. 第三等级工程师：可以做出行业里最好的产品，技术水平↑ 市场了解↑ 用户了解↑ 组织能力↑
  4. 第二等级工程师：可以给世界带来惊喜的人，如扎克伯格。
  5. 第一等级工程师：可以开创一个全新行业的人，如冯·诺依曼。
• 不计较当下职位
  要么聪明，会交际，懂政治，被人认可；要么做出成绩，贡献巨大，被人认可。后者更合适。
• 坚持做正确的技术管理
  最好的领导，思路敏捷而清晰，做事务实而高效，永远没有废话，永远雷厉风行。
  和他共事，绝对不会轻松。他不会讲段子哄你干活，他也不会笑眯眯地安抚你的情绪。只会关注成绩并对结果负责。
• 抛弃通道思维、建立雷达视角
  抛弃通道思维，建立起自己学习新知识的雷达视角，建立起自己的朋友圈，扩大雷达视角范围，对你一定会有用的。
• 收入浮动曲线
  根据经济形势，顺势而为。
• CTO角色
  CTO是公司第一号技术大师，他对于技术非常敏感，需要具备对于技术发展的深远见解，保持公司在技术上的竞争力。CTO需要保持自己对于专业领域内前沿技术的不断搜寻，也要对可能影响公司的技术方向的旁系领域进行调研。
  技术VP的职责是交付软件解决方案，确保业务健康。

2. 团队建设&人员管理

2.1 管理基础

2.1.1 什么是管理

管理人员是与人打交道，其任务是使员工能够协同工作、扬长避短。

2.1.2 开发岗位

• 应用程序员
• 系统程序员
• 系统架构师
• 开发团队管理者

2.1.3 团队成员品质

• 职业素养
• 做事专注
• 乐于挑战
• 永不气馁
• 承认错误

2.2 组建团队

一流人才招聘一流人才，二流人才招聘三流人才。——史蒂夫·乔布斯

2.2.1 招聘策略

1. 了解岗位需求

是需要：
  一个可以领导整个团队开展各种实际工作的程序员?
  一个可以找出产品里隐蔽难寻的设计缺陷的程序员?
  一个具备大局意识、能预想到需求可以如何分解为模块和组件的设计师?
  一个能主动行动、能很好地配合管理层的工程师?
还是需要:
  在短时间内可以编写数千行代码?
  能够快速开发出对客户非常重要的原型系统?
  能快速领会业务流程，围绕根本需求设计产品。

2. 编写职位描述

基本信息，包括岗位、部门、直接领导、状态、工作地点;
职位概述，包括工作职责和预期表现;
岗位最低要求。

具体案例可以参考同职位招聘平台上的职位描述，可以快速获取与需求匹配的职位信息描述。

3. STAR面试法
   STAR是SITUATION (背景)、TASK (任务)、ACTION (行动) 和 RESULT(结果) 四个英文单词的首字母组合。

   • 背景：工作业绩背景。可以了解获得优秀业绩的前提因素，多少是个人相关的，多少是市场/行业特点相关的。
   • 任务：任务具体内容。可以了解经验和经历是否与当前职位相匹配。
   • 行动：如何完成工作。可以了解工作方式、思维方式、行为方式。
   • 结果：任务最终结果。可以了解成果高低，好是为何，不好是为何。

4. 招聘文化
   快速响应、测试驱动、积极沟通。技术人员无法完全依靠HR，招聘和培养都是成本的考量。

2.2.2 面试技巧

1. 学历
   中小型公司，不要太在意学历。应届生和大公司就要留意了。
2. 面试题
   适当的笔试题可以过滤掉招聘和面试的成本，当然中小型公司除外。
3. 罗辑思维观察
   排除拖泥带水、啰嗦的人，鉴别做事干练、果断的人。
4. 心理状态观察
   排除心理上的一些问题，如上家公司发生过冲突？或心理素质太差玻璃心？——我的亲身经历是招聘到过一个心理素质差的，因为家庭矛盾入职一个多月就跳楼自杀的后端程序员。
5. 面试官形象
   注重自身形象，代表了公司。

2.2.3 性格分析

• DISC个性特征理论：支配型D、影响型I、稳定型S、遵从型C。
• 九型人格：完美型、助人型、成就型、自我型、理智型、忠诚型、活跃型、领袖型、平和型。

2.2.4 人员分类

• 独狼 和 农民：关注独狼、安排农民
• 英雄：重点任务、薪资和福利多倾斜，多沟通，指明发展方向，放入关键项目
• 内向的人：沉默内敛，多支持多鼓励
• 带有明显负能量的人：尽量避免团队里有这样的人
• 离奇之人与离奇之事：办公室政治、压制同事、对同事粗鲁、到处借钱等等，早日让其远离团队，不论技术水平高低。

2.2.5 新员工入职

带新员工逐一认识团队成员，自己带他去吃午饭，并指定新员工导师（技术上的），和他聊聊最近一个月准备给他安排的工作。

等他和团队成员熟悉后，组织全组人一起吃饭，欢迎新员工。

新员工容易流失的三大原因：

• 没有对新员工进行明确区分
• 忽略新员工直属主管的重要作用
• 培训方式缺失

2.3 管理团队

管理的最终目标：不要让你的下属陷入困境，不要让你的同事陷入困境，尤其是在任何情况下，不要让你的上级陷入困境。

• 向下管理：

  • 技术尊重：理解计算机程序设计的艺术，拥有良好的过往履历，做出过技术贡献，追逐技术潮流，成为一个技术或者职业组织的活跃成员，展现出强大的个人价值。
  • 强化现有团队：要有1~2位杰出的程序员来强化现有的团队。
  • 团队组成：杰出的程序员需要一群称职的程序员来配合。
  • 薪酬组成：薪酬=i*工资+j*股票期权+k*福利+1*与谁共事+m*工作地点+n*做了什么+…
  • 进度管理：每日晨会，对齐进度、问题和风险。
  • 效率管理：做正确的事，提高资源性能，提高工具性能，每个人都主动优化流程。
  • 引导工作：引导的最终目的是让事情完成，指出大方向，做好充分的检查。
  • 保护成员：学会拒绝其他团队给自己团队带来的问题、干扰和时间成本的浪费。
  • 评估和改进绩效：信任但要核实，为每一个人设定工作目标并规定完成的时间，定期审查目标进度和实现方式。
  • 任务责任制：每一项任务都需要有一位负责人，没有担任责任人的员工，最多只能给与合格评价。
  • 裁员：表现差的员工会影响整个团队，因为定期与这种员工谈话，审查绩效并讨论胜任力的结果。
  • 主动沟通：Leader应每两周与小组成员的一对一沟通，每个月月底时组织全员例会，内容可以是：欢迎新入职的同学、总结本月重要进展和存在的问题、介绍下个月的重点工作等。
  • 被动沟通：如果团队成员在你不太方便的时候找你来聊天，一定要先把手上的工作放下，专心跟他交流问题。
  • 文化冲突：会哭的孩子有奶吃 与 突出来的钉子要先挨敲 是有文化认知上的不同的。
  • 负面效应：根据员工的侧重能力，安排合适的工作，再在工作内容上指出他的问题，努力让他提高。
  • 会议记录：参与人员、讨论议题、讨论过程、最终结论、遗留问题、下一次会议时间和议题等。
  • 人才评测机制：评测才能为岗位定级，才能推动企业对员工薪资变化的可能性，良性发展。
  • 下放权利：抓大放小，注重结果。
  • 激励员工：没有激励，无法让员工作出更好的成绩。当然不限于金钱、成就、认可、责任、发展等

• 向上管理：

  • 了解老板：理解你的老板，高效与老板沟通，精简报告、注重大局、细节更少、局面更大、文字更少、项目符号更多。
  • 准备讨论内容：带着方案找领导，最好不止一个方案。
  • 主动承担：主动自荐，帮助上级解决更多的问题。

• 对外管理：

  • 与部门内的人保持良好的合作
  • 了解其他部门的人和情况
  • 平级的同事相处困难时，及时向上反馈，先自我检查，再简单高效的沟通。

• 自我管理：

  • 过度管理：你覆盖的团队成员不要超过10人，如果超过，则需要进行分组管理。
  • 沟通管理：别人的信息你不必一定及时答复或回应，你的时间也很宝贵，学会规划时间。
  • 面对面交流：只有面对面，才有说真话的可能。
  • 形象管理：人靠衣装。

2.4 影响团队因素

【不懂技术的技术领导】

• 基础知识和理论很重要，多使用已有的成熟的方案。
• 对技术严谨且敬畏，想清楚了再干，很多事情急不来。

【薪资管理】

• 按照能力和付出衡量，不掺杂个人情感。
• 指定标准考核，输出让人信服的流程和细则。
• 薪资组成结构能够多元化，让员工感受到自己的付出和回报。
• 薪资是第一要务，一定要公平、公正。

【上升通道】

• 多与团队成员沟通，了解他们对未来的期望。
• 帮助他们逐渐设计符合他们期望的上升通道。

【大规模变革】

• 一定要慎重，无论是组织架构还是人事任命，都会引起权利的欲望和恐惧。
• 人是有感情的，被尊重胜过加薪。

【一言堂】

• 一言堂会让团队核心人物流失，剩下的成员战斗力指数级变弱。
• 作为一名团队管理者，紧急四个字：不要作恶！

【频繁开会】

• 找出沟通节点有效的减少沟通，是管理者需要经常思考的问题。
• 高效会议。
• 尽可能减少会议。

【各种无端限制】

• 分工，不能作为只干一件事的借口。
• 一个合格的程序员，绝不仅限于一种编程语言，而是能够通过编程语言解决问题。

【老员工的管理】

• 避免生锈，多用。
• 兑现承诺，老员工的付出值的之前所给的承诺。

【工作时间】

• 针对程序员，更建议弹性的工作时间，他们总在夜晚的时候才更能专注。
• 每天保证必须有4个小时的聚在一起，完成需求、涉及的评审流程 和 架构、代码的问题讨论。

【缺乏愿景】

• 个人要有个人的愿景，团队要有团队的愿景，就好比大公司和小公司都会有各自的愿景。

2.5 OKR与KPI

OKR全称是Objectives and Key Results,而KPI的全称是Key Performance Indicators。

OKR 关注的是目标。KPI 关注的是指标。

• 以程序员为例：
  如果我们关注目标，我们会想接下来我应该做什么事情，是要解决产品的卡顿问题，还是引入大数据来做精准推荐;
  如果关注指标，因为我们的工作是编程，那我们就会想哪些指标可以衡量编程工作呢?我们想到的是代码行数、Bug 数、单元测试覆盖率等。
• 以足球运动员为例：
  如果关注目标，我们会想到夺冠、四强、保级;
  如果关注指标，那我们就会想到进球数、助攻数、跑动距离、比赛场次等。
• 以滴滴和快的为例：
  如果关注目标，快的的目标应该是超越滴滴;
  如果关注指标，快的的指标应该是司机数量、订单数、乘客数等。

使用OKR的时候，我们关注的是 我们的【目标】是什么？

使用KPI的时候，我们关注的是 我们的【指标】是什么？

使用OKR来进行绩效考核没有什么问题，将KPI平滑的过渡到OKR，最终考察的还是OKR中的KR是否达成。

3. 产品开发过程管理

3.1 开发经理及研发体系介绍

软件开发生命周期的关键：确定业务需求 >> 编码 >> 测试 >> 上线。

3.1.1 什么是软件

• 软件发展历史：从冯·诺依曼开始，程序逻辑开始脱离硬件，采用二进制编码，进而发展出汇编语言，C/C++/Java/Python等，使人类可以把知识传递给计算机，并训练计算机掌握某种技能。
• 软件的作用：软件的主要目的就是把人类生活的非核心生命周期软件化、虚拟化，以提供更低的成本和更高效率的新生活，让核心生命周期的运行能够更加容易，让非核心生命周期的处理更少地占用人类的时间，变相地延长人类生命。
• 软件生命周期：软件开发生命周期 与 软件运行生命周期。

3.1.2 什么是开发经理

• 职责

  • 对产品开发全过程进行组织和管理，按预期交付产品开发的成果
  • 管理产品开发团队，为成员提供技术和业务上的支撑，使之高效而愉快地工作，并获得最满意的工作体验
  • 管理对外关系，以取得外部对交付成果及过程的最满意评价

• 任务

  • 与产品经理交流，确认需求、资源、时间；
  • 负责产品开发交付，推进计划执行、协调资源使用；
  • 完成产品开发收尾；
  • 管理干系人的关系；
  • 管理项目团队。

3.1.3 开发经理素质

• 领导力：口号应该是 跟我冲，而不是 给我上。
• 责任心：主动细节，发现问题，应对意外。
• 积极主动：不会抱怨，不会慌乱，信心满满镇定自若。
• 抗压能力：冷静思考、稳定军心、解决问题。

3.1.4 软件开发模式

• 瀑布式开发模式

  • 需求 - 设计 - 实施 - 交付 四个阶段
  • 只有当确认一个阶段的开发成果正确，才进入下一个阶段。

  

  此软件行业采用瀑布式模型时，会存在大量的浪费，最终的结果也往往不尽如人意，这也是为什么其他开发模式兴起的原因。

• 敏捷式开发模式

  • 快速迭代，迅速反馈。
  • 四条基本价值原则：
    人员交流重于过程与工具(Individuals and Interactions over Process and Tools );
    软件产品重于长篇大论(Working Software over Comprehensive Documentation);
    客户协作重于合同谈判(Customer Collaboration Over Contract Negotiation);
    随机应变重于循规蹈矩(Responding to Change over Following a Plan)。

  

  敏捷的核心在于犯的错误越多，纠正的越快，就越能够减少线上的问题。要想快速发现和纠正错误，就要做好迭代，而做好迭代就必须确保迭代的生命周期足够短。这就是所谓的“敏捷”，核心就在于快速迭代并迅速反馈。

3.2 产品开发过程管理

里程碑4要素：时间点、标志性事件、交付物、关闭条件。

3.2.1 项目启动会

• 目标：明确该产品开发的目标，明确用户需求。

• 准备工作：明确目标、阶段、人员结构划分和任命、管理流程、项目干系人等

• 过程和议题：开发经理主持，议程如下：

  1. 介绍议程和来宾;
  2. 介绍项目目标、阶段计划、管理方法;
  3. 发布项目的组织结构图;
  4. 确认关键角色及其职责，并作出承诺;
  5. 参会人员针对介绍内容进行提问交流;
  6. 高层领导做项目动员发言，激励和鼓舞士气;
  7. 各个相关部门领导表态支持项目工作。

  并输出《项目启动会议纪要》，意见统一是项目成功的关键。项目启动会和项目例会有助于统一和巩固团队思路。

• 经验和教训：

  1. 如果可以，请一个有经验的专家一起参与。
  2. 项目启动会其意义不在于启动，而在于确认人员到位的关键时间节点。
  3. 高层领导的出席和表态，让项目后续推进得以广泛的支持。

3.2.2 用户需求

关键问题：需求理解不一致。

建议需求评审会议的三个步骤：会签提供材料、会中讲解讨论、会后解决疑问缺陷。

原则：任何会议一上来都应该先讲背景、或场景，而不是上来就说产品方案，只有背景和场景分析透彻了，方案才有其讨论和落地的实际意义。并且项目团队成员达成一致，而且需要根据实际情况适当的反讲（讲述理解是否与需求一致）。

3.2.3 产品需求

• 产品需求编写：简介、产品描述、技术约束和局限、需求详细描述、接口需求、质量需求、用户文档需求等
• 产品需求评审：3W1H，为什么做？做什么？截止日期？需求是否完整？

3.2.4 总体设计

设计阶段的目标是对开发系统进行架构的分析和设计。

一个好的系统架构设计可以帮助人们梳理业务逻辑并抓住核心需求，设计稳定可扩展的业务系统，评估业务开发周期和开发成本，有效地规避风险。

总体设计说明书一般包含：

• 产品描述
• 涉及约束
• 总体设计介绍：架构及模块划分、模块描述、接口设计、备选方案和方案对比、集成要点。

【设计方针】：

• 先实现，再优化。
• 前期评估软件结构，并且精细化。
• 结构简单、优雅、高效。
• 模块划分合理性。
• 优化格言：先能使它跑起来，再让它快一些。

3.2.5 概要设计

概要设计主要做架构选型使用。

3.2.6 详细设计

包括但不限于流程图、时序图、伪代码等。

参考：详细设计文档

未完待续….