技术管理探索

经过几年的工作，也担任过几个团队的的负责人，想总结下技术管理探索的思考。

技术管理的主要工作

0. 取得上级信任

无信任，不成行

看到过很多有想法的管理，最终的成果都不太好。也见过很多管理水平低的技术管理，下面人老有不满，却小有成绩。究其原因，我觉得就是一点，有能力的人大多容易一意孤行。而没能力的人，却更懂得借力。

举个例子，你认为当前团队的中心是构建出一套开发体系，进而后续开发工作进展更快。而领导认为当前的开发重点是赶紧实现某些功能。这个时候就会出现一些分歧，一意孤行的后果就是，而在关键时候得不到领导的支持，进而什么事情都没做好。

所以，我的技术管理很重要的一件工作就是取得上级的信任。在一个组织内，公司资源一般由上级掌握。在这个时候，做出成果的一个前提条件就是争取到足够多的资源。而要争取资源，首先得取得上级的信任。达成信任可以粗略认为有一下几个目标：

• 团队当前首要目标一致
• 对于产品战略的思路一致
• 对于团队人员配备的想法一致
• 对于团队发展阶段的理解一致
• 对于技术栈和工具链的重视度一致

总结起来就是，需要让上级对你管理的团队能做成事情有信心，与这个整体目标一致的相关事情都是工作的主要内容。

那么怎么做到呢，我觉得就是多沟通+做扎实。工作中多沟通，事情做扎实。不知道怎么做就可以采用一个原则：事前做计划、传到到意图、沟通后执行、进度多汇报、出事商策略、原则要坚持、事后需总结。

很多年轻的技术人员，第一次做技术管理时都不知道怎么取得领导的信任，往往各行其是。其实，对于上级领导来说，他需要思考的是大的方向，考虑的是全局。他并不关心你的细节问题，但是对于你们团队当前的状态他需要明确知道。对于出现了情况，他比你还需要知道事情的影响范围。而他最担心的也就是你容易各行其是，往往这种情况就会被限制，反倒无法施展手脚。

1. 产品战略

对于任何一个技术团队，都需要对产品进行长期规划。这里的产品不是狭义的软件产品的意思，它代表着技术的可持续性和团队在某一特定应用领域的积累。就需要技术管理根据不同团队情况，通过行为去支撑公司在商业行为上的收益，用好的规划去降低在开发投入上的成本。

技术管理就需要注意的是不断的思考和积累技术的可持续性，在特定应用领域进行积累，让技术团队在应对可能面对的软件类型（如：项目开发、产品研发、合作研发、DevOps开发）有足够的技术积累，让团队擅长某个应用方向（如：电商、ERP、管理系统、云计算等）。这样，在持续面对这些方面的问题的时候，我们就会越来越得心应手。

我在两个团队中做过这方面的工作。

第一个团队中，我和老板沟通后认为产品发展的方向必然是：交互简单化、功能场景化、数据可视化，就像瑞士军刀一样多样功能，每个功能都能应对不同的场景。以产品为核，项目作为主的收益模式。所以这时的技术管理需要的就是怎么样去调整团队工作中心有效减少项目周期（不是通过大量加班哈，这个毫无能力），并且积累产品能力。所以，我从几个角度去改变现有团队：

• 在工作中通过职责明确界定人员分工：产品经理、研发人员、项目开发。由产品经理和前端研发负责交互的简化设计，技术管理和产品经理一起规划主要的应用场景并映射其对应的功能，改变思维从应用场景上思考功能。
• 剥离项目需求为产品需求和定制化需求。有产品人员开发共性功能，项目开发人员基于产品基础之上编写客户的定制化需求。
• 带领研发人员构建一个小但是满足需求的产品框架，通过行业业务理解来设计框架功能，多份需求只干一份事，减少重复开发工作量
• 组织研发攻关客户关注的功能的优化，如：提升数据可视化的帧率、分辨率，降低程序性能、优化稳定性，更新新的图形控件
• 改变瀑布式的开发模式为敏捷迭代，用于快速响应客户的意见，提供可用的版本，进而通过反馈快速调整
• 构建开发工具集，制定简化的使用规范，减少开发人员的一些流程制度化操作对于状态的干扰
• 制定测试的的流程和最简原则，减少开发与测试人员扯皮的时间，让测试回到帮助提升开发质量发现问题的轨道上

第二个团队中，我以设计人员的身份入职，负责一个项目，实际干着软件开发技术管理的职责。面对CTO的技术管理体系和行政管理体系。两个顶头上司不懂技术，所以我和CTO沟通后认为，我们当前的战略方向是，从无到有构建产品团队，形成一定的能力，结合硬件打造一个系统级别产品。所以这时的技术管理的工作重点就是，如何在没有软件开发经验的组织中构建起一个团建团队，并制定规则，构建技术生态，并开发完成棘手的项目。所以，我从几个事情上去入手：

• 进行系统架构设计，明确出软件未来的工作内容
• 分析团队所需工种，提交招聘名额申请，并自己参与招聘
• 分析项目的需求，剥离共性和定制化需求，对于共性需求进行模块化设计，定制化需求进行框架上的兼容设计
• 构建开发环境，并结合环境制定开发流程
• 制定开发的规章制度，用以规范开发人员行为
• 构建迭代开发模式，用以在初期阶段快速产出功能
• 和客户沟通开发节点（其实就是讨价还价），并在有一定小成果后向客户演示，让他们对我们这个新团队放心

通过以上内容其实可以看出，我们整个团队的工作，其实都是围绕我们的产品战略来的，服务于当前阶段我们要奔向的目标。所以，作为技术管理，产品战略的工作很重要。

2. 人才管理

做任何事情，人是根本。依靠人才能做好事情。

有很多管理者认为人才管理都是HR的事情，实则是一种误解。对于任何团队的管理者，团队内的人才管理永远都是他的主要工作内容。HR是帮助我们进行这项管理的专业人才，不是招人和开人的白手套。

对于一个团队来说，人员的活力和氛围是前进的引擎，发展空间和人才梯队是团队的保鲜剂。所以，依靠人才梯队找人，根据团队氛围选人，通过老带新留人，通过规章制度取信于人，通过发展空间凝聚人，好聚好散留情于人。应该足够总结起来了。

3. 提升团队开发效率

很多管理者认为团发进度过慢，进而责怪具体的开发人员。固然有可能存在有人会懈怠的问题，但在大家都是职场人的环境中，做出这种事情是不合理的。所以，不管怎么样，当你意识到出现问题了，其实都是你自己的问题。

我认为团队的开发效率紧关联着大家的幸福指数，呈正相关。而开发效率中，个人只占比一半不到。而通过团队互信、开发设施的构建、知识的积累、合理的流程、明确的目标等等都会成为另一半提升效率的武器。作为技术管理者，需要处处为团队的方便做考虑，与人方便，与己方便。这样效率自然就会提升，不用你强制大家加班。

我认为大部分导致效率底下的原因反而是管理者人为制造的，比如：

• 将整块时间中插入事件，让团队成员碎片化
• 目标在执行过程中轻易改变
• 开发过程中需要使用很多上古系统才能完成一件工作
• 根据自己喜好将需要频繁沟通的工种位置分开
• 遇到任务延迟，不解决问题，反而进行讽刺
• 性格反复无常
• 不能以身作则，言行不一
• etc.

其实很多看似只是个人修养的小问题，却容易因为你是管理者在团队中放大它的影响，进而影响到团队的效率。我认为坚持一个事情就可以做到不因为自己的原因降低效率：

君子行事以直，人必信之

上句翻译过来就是，就事论事，言行一致，就能得到团队成员的信任。

解决了因为管理者自身带来的问题，接下来就要考虑的是，如何通过一些基础的开发设施来提升效率，我觉得可以做以下尝试：

• 构建简便的代码管理和版本管理，方便合作开发，避免开发中的大量问题
• 构建BUG管理系统，降低测试与开发的沟通成本，必须辅助适合当前团队的最简使用规范
• 持续集成系统，减少集成，打包等无技术含量的工作时间
• 构建开发环境，测试环境，模拟生产环境，用于开发工作的实际验证
• 开放的WIKI系统，用于积累专业知识，提升技术受，培养贡献的习惯
• 包管理系统，用于一些组件、框架、模块的版本发布和开发集成
• 思考如何丰富面对面沟通模式，增加沟通场所，减少聊天工具的使用
• 思考如何减少工作流中的割裂，尽量少的使用不同工具

4. 保证产品质量

作为技术管理者，产品质量是我们很应该重视的点，这里的产品与产品战略的产品含义相同，并不是指的狭义的软件产品。其实，有时候一个好的技术团队也是一件产品，需要长时间耐心的打磨。

那么产品质量中我认为有几点是作为技术管理必须要保证的：

• 代码质量（简洁性、鲁棒性、耦合性、可读性、一致性）
• 架构的工程质量（架构落地是否符合预期）
• 功能实现的过程节点质量（把控过程中关键节点的质量自然产出质量就高）
• 项目计划的质量（合理的周期划分、技术实现的时间、存在风险和难点的技术）
• 开发自测和测试验证的质量（回归测试、性能测试、稳定性测试、功能性测试）
• 产品打包发布质量（安装包测试、完善的版本管理、配套文档测试、开发过程文档归档）
• 售后客户服务质量（如何便捷获取客户的问题反馈、解决问题的计划反馈）

能保证以上几点，基本上就覆盖了技术团队整个开发周期中的各点质量，更优秀的人就是在这些的基础之上进行细化、提炼得到一套符合自己团队的最简实践原则。我觉得可以通过以下方式来做到这些点的保证：

• 选择合适节点组织代码评审（一定注意别弄成批斗大会，追究责任）
• 与架构师定期一起评估架构工程质量，将改进工作放入后续工作计划中
• 细化开发流程，必要的环节需要输出简单文档（保证一致性），在功能完成后需要自测并输出报告、迭代完成进行内部演示（很容易发现问题）
• 每次计划开始前，需要经过关键角色的整体评估，它的合理性和风险应该是评估的主要内容
• 注重如何减少开发与测试人员在测试中的无意义工作，如何增加他们的沟通效率是保证质量的标准，且需要保证他们的理解一致性，需要在功能开发前管理好他们的预期。
• 制定产品发布流程规范，有专职人员负责执行和检查，需要反复强调其遵守规范的重要性
• 向客户提供多种便捷售后反馈渠道，并制定售后处理流程，开发流程保留导入售后需求的入口

5. 制定规则&监督执行

任何人都有凭个人想法做出决断的情况，而按照规则执行能够避免大部分问题。

在开发团队中，存在一个很重要的点：保证一致性。保证不同成员的理解一致性，目标一致性，期望一致性是很重要的点。

在与时俱进的现代思潮下，管理思维必须与时俱进，适应当下的新生代人群的主流三观。所以，自觉高人一等，管理就是管制人的落后想法一定要摒弃。建议将技术管理理解为团队领头人，你需要把握方向帮助团队向前向前。作为人的角度大家是平等的，只是拥有不同的分工而已，这样才能避免官僚主义的滋生。

那么排除人治的情况下以什么为准呢？——规则。

在制定规则前就需要明确的一点是，规则天然的非人性，存在明显的缺点，就是不近人情。所以作为技术管理，制定规则是用来解决大部分一致性问题，保证大家遵循同一标准，不会出现不公正的情况。另外一部分人情，就需要通过人为协调来实现，兼顾团队目标和个人价值。这也就是很多公司价值观中，以人为本的体现之处。

可以见的，规则在这其中扮演者重要的角色，那么制定出覆盖常见问题和关键问题的规则就显得很重要。我认为，需要制定规则的方面有以下几点：

• 设计规范（代码设计、UI设计、文档设计）
• 项目流程规范（需求导入、需求变更、迭代模式、协作方式等）
• 编码规范
• 版本管理规范
• 测试基本原则
• 开发工具最简使用规范
• 产品发布规范
• 团队资源管理规范
• 会议制度
• 考核制度（非硬性考核比扣绩效工资更有效，采取不同维度投票制决定考核结果，考核结果不合格但下次合格补发绩效）

在逐步制定出各项适合当下情况的规则后，监督执行就是一项重要的规则。说是监督执行，我认为最重要的就是以身作则，从技术管理者本身做起，在实际日常工作中以现有规则作为统一的评判标准，自然大家就会效仿。

技术管理的核心原则

0. 明确目标

团队开发周期大量延长，成员效率低下。大部分情况都还没优化管理，增加配套设施等操作的时候。基本都是因为目标不明确，或者目标不一致。导致这种情况的原因有几种，需要结合当前的情况进行分析：

• 负责人自己都不知道具体要做什么效果
• 负责人搞不清楚当前阶段事情的优先级
• 事前没有反复向成员传达目标
• 每天没有回顾和检验成员的工作是否偏离目标
• 缺少对成果的检验机制

一般来说，按照PDCA来执行就能行，但是要解决问题还看技术管理者在过程中所做的工作。

1. 通畅信息&保证沟通

团队存在不同的角色分工，每个分工又有不止一个人，所以在组内与组与组见的沟通交流就显得极为重要。毕竟，千人千面，每个人都有自己的想法。特别是，你的团队成员都普遍优秀的情况下，管理优秀的人更加需要保证沟通，不然他们各行其是带来的后果可能会更加严重。

首先，需要注意的几个沟通陷阱：

• 使用聊天工具，聊天工具即时性强，但是溯源能力差，且没有确定感，确定一致的东西容易随着时间改变
• 产生约定后不发送邮件存档公示，久而久之出现矛盾契约精神就会荡然无存，习惯性甩锅
• 不愿意面对面沟通，会增加团队成员间的隔阂，也会导致倾向于不沟通
• 沟通过于正式化，容易演化成责任、职权边界的划分讨论，无益于工作
• 沟通只通过嘴巴，没有纸面、文档、白板等的书面化、形象化、图形化表达，效率低下，限制大家想象力
• 私下做决定结果不透明，滋生办公室政治

作为技术管理者要让沟通变得更加的通畅可以通过一些办法来实现：

• 限制聊天工具的使用内容，原则上不允许讨论重要事情
• 厘清不同场景下的沟通情形，思考能够通过具体开发设施解决
• 在办公室中设置沟通场所（小块空地、公共桌子、小会议室、阳台茶几等）
• 在办公室中设置公共白板
• 在办公室中添置公共投屏
• 构建公共共享文件、文档协作、WIKI等文档共享工具
• 在办公室中部署公共打印机
• 让你的办公场所不明显区别于团队成员，使它便于随时接待沟通并做好随时工作中断的准备
• 重要决定需要透明过程，并公示结果

2. 承担决策责任

团队成员出现问题，都是管理者的问题。你有这个责任去纠正问题，而不是马上追究责任。

作为技术管理者，必须要面对的一点就是当无人能够做出决策时，你就是那个要做出决策的人。当出现问题需要承担责任并解决问题时，你就是那个承担责任和解决问题的人。

有很多人会纳闷，有的时候又不是我的工作、责任和我的问题，为什么要我来做出决策和承担责任。其实这里涉及一个能力层级和压力模型的问题，技术管理者的能力层级高于团队成员，必然需要承担更大的压力。如果当团队成员无法做到某些事情时，就需要从下至上冒泡传导到合适的人的那里。而出现责任需要承担时，一般是从上向下传导，压力会越传导越大，但是具体到某个人身上时他并不能够承担起这个责任。所以，作为技术管理者，必然需要以代表整个团队的身份承担起这个责任。然后以团队的角度，来解决掉问题，让团队能够继续正常运转，而不至于大家各自担惊受怕。

3. 服务成就他人

技术管理者其实就是个服务员，团队重要的工作都是由具体的分工来完成，而让整个团队良好运转的工作由你来完成。所以，要加快运转效率，成就每个成员，让他们成长为能力更强效率更高的人之后，团队的运转自然高了起来。技术管理的最高境界，就是在成员个人成就和团队成就间求同存异，实现双赢。

4. 做好团队成员工作

技术管理实际上还是进行着人的管理，所以人的特性就需要考虑进来。人不像机器，是有着情绪，状态有着起伏，心态也会收到外界的影响。所以，团队过程中会存在激动时刻、乏味时刻、厌恶时刻、难过时刻等等。那么在每个成员遇到难事，遇到状态低迷的时候，如何去帮助他们渡过，如何鼓励他们是每个技术管理者需要思考的。可以通过一些方式来帮助团队成员：

• 鼓励同事间互相谈心帮助
• 和具体的同事单独朋友间谈一谈
• 建议同事心情不好时可以出去走走
• 听取工作中的意见并做出改进
• 状态不好时组织一些游玩、散心、发泄活动
• 组织办公室小活动（观影、评比、演讲、吃东西、八卦会等）活动活跃气氛

5. 明确评价体系

在现代社会下，作为职场人，自我实现的渠道单一。很多人还是需要通过工作成就来证明自己的，所以，明确的评价体系对于团队的成长和公正客观的评价很重要。这方面网络上很多资源可以参考。

6. 处理好上下级矛盾

作为技术管理需要执行上级的战略要求，还需要平衡下级的工作体验。这两方面都是决定事情可不可为的重要部分，建议对上管理预期，对下明确目标标注核心内容。在其中平衡好不同的立场双方，需要在具体的工作中保持敏锐的洞察力和执行力，结合具体的情况做出决定。

7. 不加班的态度

不加班不是说真的不加班，而是一种愿景一种态度。实现不加班，是为了实现团队成员的福祉，平衡个人价值于团队价值。要注意的地方就是，加班其实是对精力的一种低效运用。如果过于透支每个人的精力后，长此以往后的每天团队都会被弱执行力所笼罩。只在需要时加班，合理拒绝过量的工作，产出优质产品是优秀技术管理者的检验标准。

8. 好的成果是结果，不是目的

扎实做好生产的过程，好的成果自然会产生。面朝着好的结果走过去，肯定会走入看似捷径的羊肠小道。