如何理解“管理”

引用堂主老师的分享： 管理，就是靠别人拿结果

无论是实线Leader，还是虚线的小组长，或者是项目PM的具体Owner，其工作的内容都不是一个人能搞定的，都要靠其他人的产出来集体落地成果。

管理是靠别人拿结果。在不确定性中寻找确定性，通过成就他人来成就自己，基于数据阐明一切改变。

管理者是带来改变的人，管理者就是靠影响他人，带来正向的改变。

宏观看“管理”

按优先级分：人 -> 事 -> 文化 -> 影响力，具体的管理围绕这四个维度，此外需要有与之匹配的制度、流程和管理工具。

关于制度流程：团队成员平均意识和能力偏向于一般般和强执行的，越需要强化，既需要明确清晰的制度和流程。
反之团队成员偏专家和自驱的，越需要弱化规则和制度，尽可能降低强硬的制度对个人的约束，强化价值观和文化驱动。

关于管理工具：绩效、晋升是管理工具，调薪、股权、奖项也是管理工具。积极的管理工具，需要向团队倡导的方向倾斜。

人 - 人对了事就成了一半

人 - 筛选

选人是第一步，也是最重要的一步。
领导力定义是选对人，不是培养人，选拔比培养重要N倍。选对人的标准：他有没有做到你要的结果或标准。

内部选拔

能力够、要性强、潜力大。

外部招聘

外部招聘的策略，就是本土短期内成长不起来的“物种”，尽量避免招进来的人是一类人，要形成互补的概念。

外部招聘尽量避免缺人时，心浮气躁降低标准，能干活就行。前面提到管理是靠别人拿结果，你团队同学的能力水平，决定了你的管理结果。

招聘优先能为团队带来积极改变的候选人

人 - 育人

用人长，避人短。重视团队成员的输入和输出。

人 - 汰换

人员汰换是必经之路，无论是被动接受优秀同学的流失还是主动淘汰不合格人员。

主动淘汰

心要慈，刀要快。不能有老好人心态，一个人如果长期在一个不匹配的团队和业务当中，他也会感到不舒服，同时也会导致他的职业信心受损。

被动流失

团队核心离职、流失，是大家都不希望看到的事情，但是人和企业的合作，本质也是双向匹配的过程，这种情况也在所难免，有几个注意点：

关键岗位必须有 Backup，团队 TL，业务接口人，技术建设 Owner，都是关键岗位。如我团队的 TL 、组长们，自这个团队的组建、分线、分梯队开始，就第一时间和大家明确过他们都有自己的 Backup，且会要求各组内同步建立下面的 Backup 机制。

系统性坍塌： 是指一个人的离职会导致一批人的离职，比较常见的是某 Leader 离职后带走大批核心，导致对应业务支撑能力系统性受损。能力性坍塌，是指离开了某个人，某项能力就玩不转了，如团队某关键建设基于 A 技术，结果负责的同学离职后，团队剩下的人谁也不会 A，导致这块变成无人能维护，出了问题也无人能解决。每年的人才盘点中，除了要盘点团队梯队、核心的阶段性潜力，更要考虑在岗的可替代成本和流失成本。

人 - 结果

绩效和晋升都要对结果负责。

绩效

尽量做 “绩效管理” 而非仅仅 “绩效考评”。绩效的工作，90% 在日常中的过程跟进，不要本末倒置放在最后的结果沟通时。

• D（不满足期望）：代表的是无年终、无加薪、无晋升。有些公司还会针对这部分员工纳入 Pro 改进流程，改进不到位就淘汰；有些公司是连续两次 3.25 解除合同。针对业绩不满足期望，一定是其工作有重大人为过失（如因个人疏忽直接导致线上 P0/P1/P2 等重大故障），或是明确不满足团队现阶段的用人标准。
• C（部分不满足）：这部分我的标准是，有 80 分的能力，却只拿到了 70 分的结果。可能是因为合作态度问题，可能是因为自己跟进不力，总之未能发挥该有的水平，浪费了天赋。
• B（满足期望）：良好完成自己分内工作，属于得努力踮踮脚甚至跳一跳才 OK 的结果，但也没明确的亮点，只是做到了分内事。
• A（部分超出）：有亮点，除了完成分内事，还带来积极正向的改变，有明确的对外的影响和推动结果。
• A+（超出期望）：不止是亮点，更有惊喜。通过个人努力和推动，带来了突破性的变化。

晋升

晋升的前提，是能像下一个层级那样思考问题，并在做下一个层级做的事并拿到结果。

绩效好不等于能晋升，前者是拿到了突破性结果，但不代表一定能胜任下一层级的综合要求。管理者也不应该将晋升等同于排队，晋升需要对结果及直接显著的贡献负责。
对于晋升提名通过者，管理者需要进行必要的晋升辅导，如演示稿、陈述内容结构优化的辅导等，必要时还可以组织几场模拟面试，帮助参加晋升面试的同学找找感觉。程序员很多人都是会做不会说，必要的辅导还是需要的。

这里特别强调一下晋升后新的目标的设定。部分流失是出现在晋升后，晋升成功就提离职不是玩笑，是确实存在的局部现象。晋升后，前期的持续努力得到了阶段性满足，新的目标感缺失（有些是晋升后待遇变化低于预期），会加大诱发离职的风险。

层级&要求

对于人，核心重点是明确层级标准和产出结构，结合不同的策略提升组织的整体能力。
这其中要求组织上下都能明确不同层级的定位，明确考评标准，面向梯队的分层，制定对应的阶梯式成长计划，提供足够的输入和输出空间，对结果的评定也当是站得住的（有业务落地并带来明确变化）。

考评维度的单一，是管理者的大忌。考评什么，就会得到什么。维度单一会导致团队能力单一，核心人员的输入、输出空间不足，诱发流失。考评维度单一，也会客观上造成面向 “履约率” 的“计件式”结果核定，面向层级分配工作量（层级高的多分配几个业务模块），造成团队寒心、失心，严重的会导致团队核心离散。

人的方面，管理者需要基于以上的标准，区分出团队的梯队构成，并对梯队现状有一个了解。

事 - 提前布局

事：建设

无论业务支撑、技术基建，都是建设。

业务支撑

优质高效的支撑业务，是活在当下。做完既定的业务工作，帮助业务达成既定的业绩目标，是拿工资该做到的最基本的事。但做完绝不意味着结果 OK。好的业务支撑，在做完的基础上，还要能做好。

深入业务，对业务预期的把握和影响，面向业务支撑的流程、协作等优化，驱动业务乃至正向的影响到业务的产品架构，技术的方式优化支撑业务的基础模式，用更具效率、更优体验的方式为业务带来更多可能性，都是需要考量和衡量的点。

技术建设

必要的技术建设，是为了帮助业务和团队活好未来。尤其是对于前端职能来说，太多的前端团队仅面向最上层的 “用户界面层” 进行开发，基建也仅是一套三方的开源组件库 + 一套本地脚手架环境，技术范畴很薄，业务影响不深。这也导致普遍的在研发体系的对话中，前端的话语权偏低，处于堆人力的资源型工种，经常被 “资源瓶颈” 的问题怼。
出蛮力的堆人、加班，顶多能带来 40% 的人效提升（看你是 996 还是 997）。希望于数倍的人效提升，需要在业务支撑结构，和面向业务的技术基础建设上找答案。

体系结构

管理者需要带动团队，推动业务方、协作方，优化队伍支撑业务的基本结构，变出蛮力的做事方式，为更聪明高效的方式。

相比较一线大厂已经在 Serverless、FaaS、微前端、AI 机器学习 UI 自动转 Code 的方向上发力，一般的中小型企业的前端团队很难具备这样的基础。面向一般中小企业的前端团队，在大厂新一代解决方案还未成熟产品化之前的现阶段，因地制宜的优化团队的支撑结构，是更接地气的。

• 系统支撑：系统搭建、质量监控、自动化测试、数据大盘。
• 基建支撑：通用组件库、业务组件库、业务模版、工程化CLI工具链。
• 业务支撑：营销搭建化、交易中心化、后台模板化、流程配置化。
• 架构支撑：领域分层、流程解耦、功能聚合。

事：视角

前端在研发体系中话语权偏低的现状，从前端这个职能出现那一刻就存在了。不排除个别研发团队，因其业务模式的原因，对前端的依赖较深，前端的话语权相对偏高。绝大部分的研发团队中，前端的工作，在其他研发眼中，往往是 “技术含量低”、“很薄的一层” 等情况。

对于有了较完善体系的前端团队而言，其技术体系也更多是局限于前端自身的职能范畴，没能较好的互动渗透到业务侧，更多是在自嗨，业务的感知力是很弱的。将技术带来的工程收益，转变为业务收益；将部门内的技术影响，转变为业务影响；将技术场景，升级到业务场景；将团队的基础能力，变为业务能力。跳出前端，围绕并深入业务，这是每一个正在推动团队体系建设的 Leader 要更多想想的事。

文化 - 所谓文化、价值观，就是日常的言行

团队共识

团队共识，有助于帮助团队找到做事的态度和节奏。我的个人经验是，先从团队不希望拥抱的那些问题出发。我们团队的核心成员，曾经聚在一起用了很多时间，罗列出日常中那些反感的行为，并归类总结，反推出团队集体认同的方向、观点，和希望拥抱的行为，落实为我们的团队共识。

问题汇总：

• 态度问题
  • 形式主义，敷衍了事、虚报进度
  • 态度傲慢、交流有距离感或让人不舒服，影响组内氛围
  • 做事不认真、评审不关心、开发不按需求文档
  • 没有责任心、找借口、不担当，碰到问题就甩锅
  • 不遵守公司团队规章制度，个人觉得无所谓
• 能力问题
  • 业务理解不深入，无研发投入产出比考量
  • 思考单一、埋头苦干不沟通
  • 不考虑代码质量，不主动寻找最优解
  • 不总结经验教训，相同的错误连续犯
  • 安于现状，缺乏目标，不主动学习，没有技术追求
• 沟通问题
  • 主动沟通意识差，遇到问题不反馈
  • 沟通方式单一、只会等消息
  • 情商低，沟通容易产生对抗情绪
  • 沟通抓不住重点，沟通没有结果

数据指标

管理者推动改变，数据说明改变。

数据指标的设计，需要在某专项建设的前期即设计好并进行采集，并在整个推动周期和落地后持续收集，这样可以得到一个相对完整的变化曲线，用以佐证工作的成效。数据不见得一定是精准的，但数据一定要能说明趋势，直观化结构，准确反馈。

最后 - 管理者的建议

管理者是推动改变的人，从最初的执行，到开始承担对改变负责，到逐渐适应，一路上的心路历程和风景各不相同。管理者是火车头，肩上负担着业务、团队方向，及身后一群人未来一个阶段的得失。套用一篇讲企业发展文章的话，“朝哪个方向走，判断的核心是深刻理解市场、业务的趋势。这其中，要对技术的未来做判断，对产品的未来做判断，相对而言，大部分人都能看到技术的发展趋势，困难的是判断未来的产品形态”。运作一个团队，和运营一家企业，异曲同工。管理者，其自身也是创业者。

管理者同时也要面对结构性挑战与周期性挑战，只有活得久才能迎接更大的空间挑战。结构性挑战，是在不同的业务及团队阶段，团队需要发展和落实的结构性能力、体系化能力。人才体系、文化体系、组织架构、技术体系、业务体系，管理者首先要尽量成长为体系性选手，具备搭建体系的能力，否则会压低团队的天花板。周期性挑战，亦是在不同的业务及团队阶段，管理者需要侧重面对的核心问题也是在变化中。草莽期解决无到有，资源压力；快速发展期要快速搭建技术体系和优化梯队；技术体系相对完备时要跳出前端的事业，横向推动和打通，和业务产生更多互动；平台期需要帮助业务和团队在新的曲线破局… 每个管理者必须要务实、要花足够的精力提高自己推动改变的能力。