做了 8 个月的技术经理，我总结了这些管理方法论……

说说我的困惑。

个人经历

老粉朋友都了解我的情况，2014 年未毕业就加入目前的公司，待到现在，快 7 年。

做过 4 年的前端开发，2 年的前端主管，接近 1 年的技术经理，现在团队接近 40 人。

两三年前，带的是前端组。6、7 个人一起干活，人员稳定，执行力强，组内气氛一片和谐融洽，跨组沟通协作顺畅，可谓顺风顺水。

其他部门的人夸前端组的小伙伴很不错，基本每个成员都被表扬过，作为前端组 Leader，脸上都有光。

那时候我认为不就是管理嘛，感觉比做技术更简单，只要我说一声，整个团队就一起干，团队战斗力也强，大家合作得也开心 。

压根不需要什么管理体系啊，方法论啊啥的，没有这些理论知识我一样可以把团队管理得很好。

难题

现在坐在研发部 Leader 这个位置，我遇到新一轮的管理难题：

团队由 6，7 人变成了 40 人，我还有没有足够的精力关注到能每个人？显然没有。

前端 vue，后端 python，安卓 Java，iOS swift，我无法擅长所有技术栈，我靠什么给他们指导工作？

除了前端组的人，其他人都不是我招进来的，他们认可我吗，是否愿意配合开展工作？

再退一步讲，如果去到一个新的公司，抛开我在这家公司过往的积累（成绩，威望），也没有老员工的称号，我还能不能带动一个全新的、已经成型的团队？

……我给自己提了好多问题。

我这人危机意识有点过强，总是喜欢思考一些还没发生的问题，扯远了。

我相信不管谁坐到这个位置上，都会遇到这些问题，没有谁能擅长所有的技术栈，也总会有人对你不感冒。

没有谁是天生就会做领导， 坐到这个位置上的人， 都是摸着石头过河。

摸索、打击与思考

近 1 年来，我在团队推行过很多管理上的流程制度，包括项目「研发项目管理」流程，「产研跨部门对接」流程，「月度奖励评选」机制，「主管复盘」制度等等。

还调整过组织人员架构，做了不少管理上的工作，大大小小的已经记不清了。

目前来看，这些调整收到的效果还是不错的，至少比调整之前运作得更顺畅。

上个月去了一趟公司集团总部南京述职，总部的评委对我的评价是： 你没有自己的管理体系和方法论 。

这个对我的评价确实到位，一语中的。

技术出身，摸索着做管理，没有接受过系统的管理学培训和学习。

但我依然没有深刻到，这些所谓的方法论，所谓的管理体系，有多必要。

所谓无知者无畏！

直到这个月对部门工作的不断思考和总结，我越发得觉得这玩意还是有必要的。

感谢公司安排的述职，简直是面对面地给我上了生动的一课，否则我不会去思考这问题。

这周，我在网上收集一些曾经「不屑一顾」的管理体系，结合近年来我在的团队管理上的实践、思考、学习，做了一次总结梳理和输出。

所以这篇文章会有很多管理干货，还有点长，但它很接地气，而且一点都不枯燥。

我希望能建立出一套属于自己的，相对完整的 且逻辑自洽的管理体系和方法论。

照搬网上的管理理论没用，不管是鹅厂的还是猫厂的，看似高大上的管理八股文，不符合自己团队，只会搞得大家不适应，水土不服，最终都是无法落地执行。

搞不好把团队带散了，这罪过就大了，把自己口碑都做坏掉了。

为什么定了这么多流程制度还不够，非得要搞个体系或者框架呢？

因为有完整的管理体系，我才能以 更高的视角来看待团队的管理事务。

出了问题我能定位到是哪个模块，然后有针对性地加以改善。

下面是我梳理的管理体系，一共有 2 个维度，4 项工作，16 个模块。

我会讲一下每个模块存在的原因是什么，它对应着团队管理的哪些日常工作。

让你们知道我绝对不是扯什么高大上的名词，也不是在隔空吹牛逼。

每一项都是实实在在发生过在我的管理工作当中，这样你们听起来才会接地气一点，才没那么抽象枯燥。

这图谱有点像个坐标系，分了横轴 2 个维度，我来拆解一下：

横轴是从“ 定制度-拿结果 ”的维度，纵轴是从“ 管人-管事 ”的维度。

乍一看是有点迷糊！

可以用一句话概括这 2 个维度的关系：

带团队就是管人和管事，这两者都是通过设计流程制度，依靠流程制度运作起来，最终拿到想要的结果。

下面说说 4 项工作：人员管理，文化建设，技术管理，项目管理。

人员管理

我把人员管理工作划分为 4 个模块， 如下图：

1.1 人才标准

你的招聘标准是什么，你需要什么技能的人，每个岗位的技能要达到什么标准，这些你要制定好。

没有标准，hr 姐姐都不知道按照什么标准去招人。

每个岗位的不同的职级的能力标准是什么？初级、中级、高级，专家分别要具备哪些能力。

很多公司都有 P4-P10 的职级，每个级别都设立了对应的薪资区间。 所以同岗、同职级、 不同酬，也很正常，HR 会控制在区间合理范围内。

公司小的时候也许没有精力去做这些，干活才是第一位。不同阶段有不同的管理需求，等公司人数到达一定的规模了，你就发现这个很有必要了。

举个最实在的例子：

当团队三天两头有人找你要求升职加薪的时候，你给不给加，不给他可能辞职，换人的成本高不高，你的团队能不能承受？

给加薪的话，给多少合适？给他加了，其他人也来要加怎么办？

有了这个职级能力标准，就可以作为一个参考。

按照标准来走，达标了才可以升职加薪，大家心服口服。你也节省了很多讨价还价的时间和精力。

1.2 绩效考核

标准岗制定绩效很容易，比如客服，销售岗等。

程序员，产品经理，测试工程师，UI 设计师都是非标岗位，制定绩效需要花点时间和功夫了。

我们团队会用提测时间，提测质量，线上 bug 率等指标来要求程序员。

同样，线上 bug 率也是测试的核心考核指标。

对产品经理，我们会考核需求评审的通过率，要求他们尽可能地思考周全，才来找技术开评审会。而不是把业务逻辑兜底的任务甩给研发的同学。

绩效考核的内容，要有侧重点，往往是你团队目前存在的不足，急需提升的部分。

这些都是绩效考核的一小部分，具体的细节就不展开了。

绩效的各项分值一定要合理，这就决定了内行才能做，外行最好看看热闹，别插手进来。

很多小公司由不懂技术的外行来做管理，定程序员的绩效标准，真乃坑爹，迟早会把人搞走。

没有考核，就没人会对结果负责 。不要高估人的自觉性，人都是惰性的。

团队里有 2-3 个能自我驱动的人就偷笑了，指望所有人都能自我驱动不现实。

适当的考核约束，其实更有助于员工的成长。

1.3 人才培养

能招进来的都是薪资 offer 谈妥了，钱到位了。短期内的诉求不是钱，是能力上的提升。

结合你团队中日常的工作安排，看看有什么机会，能让他们承担一些有挑战、有难度的任务，提升他们的专业能力。

能力的提升会带来一定的满足感和成就感。

工作上学不到东西，无法结合工作实践来提升能力，自然就会担心将来收入提不上去，离职的念头就产生了。

好不容易招到合适的人又走了，白培养了。

所以 Leader 要关注下属的学习提升诉求有没有得到满足。

想做咸鱼的不在讨论范围内。

1.4 晋升加薪

人进来了，能力得到锻炼和提升了，有没有晋升和加薪的通道？

前面的「人才标准」定义了不同职级的能力标准，能力达标是条件之一，对，只是之一。

有的公司还要结合你工作内容对公司产生的价值，意思就是你技术牛逼，你也得为公司创收啊，最好是产生可衡量的效益。

参与到公司核心项目去，是一个最有效的办法。

晋升的标准是否明确？明确了，大家才能有针对性的提高自己，才有努力的方向和目标。

标准不明确，等于没有晋升通道，大家只会觉得你公司忽悠人罢了。

在这里看不到晋升的希望，自然就想跑出去看看外面的机会。 出去面一下，发现有 30 %的 涨幅，回来你再想留他就留不住了 。

总结一下，现在再回看上图就很容易理解了。

通过左边的「定制度」，也就是定义好人才标准、定好绩效考核。

来 实现 右边的「拿结果」 ， 人才得到培养、在公司实现晋升和加薪。

文化建设

我把文化建设工作划分为 4 个模块，如下图：

人员管理做好了，人是留下来了，组织稳定还不够。

个人好，不能代表整个团队就能好，所以还要花时间去做团队的文化建设。

说到团队文化，都会觉得有点抽象、模糊。

2.1 文化信仰

一个中小团队的文化氛围，大概率就是这个团队的 leader 的性格和做事方式。

因为他是 Team Leader，他在团队有足够的影响力，久而久之大家就会被他影响。

但不是每个 Leader 都是完美的人，身上总有一些不可取的部分。所以做管理者，就要花时间考虑，如何塑造自己技术团队的文化。

你的团队相信什么，推崇什么，什么样的信念能给予你们力量，作为 Leader，这些是你的带队理念，值得花时间去思考。

2.2 落地执行

团伙文化不是口号，是落实在团队每个人日常工作中的点点滴滴。

比如，团队推崇技术攻坚，结果稍遇到一点技术难题，就跟业务方说实现不了，显然跟文化信仰相违背。

比如，团队推崇拥抱业务，但是研发的人都不知道自己在做的功能，最终给谁用，也不关心也用户对产品的使用情况。

比如，团队推崇有担当，但大家遇事就互相甩锅，解不解决问题不是重点，只关注自己怎样才能免责，把锅甩出去才是最重要的。

有担当，责任心驱动，主人翁意识，对结果负责， 是我目前阶段想重点打造的团队文化。

怎么落地？

Team Leader 首先要以身作则，这也是最基本的领导力要求了。

再搭配一些奖惩制度上，对符合团队文化做出积极贡献的成员，要给奖励，给以正向的反馈。

相当于变相告诉其他员工，团队重视什么，鼓励什么样的行为，会奖励什么样的人。

2.3 组织凝聚

好的组织文化、团队氛围，大家互相尊重，互相帮助，员工工作得开心，自然愿意留下来，团结组织才能稳定，才有凝聚力。

小伙伴们之间是开心见诚，团结一致；还是勾心斗角，互捅刀子，直接决定这个团队是否健康运作。

下属之间合作有不愉快的，Leader 要尽快介入调解，不能任由事态恶化下去，最终都干得憋屈，肯定是有人要离职。

人员都不稳定，三天两头换人，还谈啥干活。

2.4 团队作战

绝大部分人都会受到周边环境所影响。

当队友都很积极，很有担当的到时候，他也会努力干好，因为跟着一群正能量的人在一起，他也正能量起来了。

前面的文化信仰铺垫，落地执行，为的都是打造一致有战斗力的团队。遇事不退缩，集体迎难而上。

每个人都能成为团队文化建设的践行者和受益者。

再扯两句团队文化建设。

团队建设要有好的文化土壤作为根基，人员的凝聚力才会强，团队的整体战斗力才会硬。

团队文化建设不是靠说，不是空口号，不是靠在墙上拉横幅，靠团队成员以身作则，Leader 首当其冲。

如果 Leader 都是个没有担当，有锅就往下属身上甩的人，找背锅的，也就别指望他能带出一个有担当的团队，没有人愿意追随这样的 Leader。

唯一的解决办法就是，换 Leader。

总结一下，关于文化建设，看上图。

通过左边的「定制度」，Leader 思考团队的文化信仰，制定好落地方案。

来 实现 右边的「拿结果」 ，团队有良好的凝聚力，足够硬朗的战斗力 。

技术管理

我把技术管理工作划分为 4 个模块，如下图：

有了人，有了凝聚力还不够。

考核一个管理者是否成功，一定是看团队是否成功。看的是团队的战斗力，而不是 Leader 个人的战斗力。

我们都希望自己的团队整齐划一，能够做到一声令下，指哪儿打哪儿。

实际情况是，每遇到一些状况，大家都是你一言我一语，说的乱七八糟，最后发现团队里面怨声载道，说什么的都有。

要高效协作，就要降低协作上的成本，必须让每个人有标准可遵守，团队整体动作整齐划一。

做技术的，一定要定团队的技术规范，没有的话，就是一盘散沙。

3.1 技术规范

代码风格规范、代码管理规范、 Code Review 规范、技术债务管理等等。

干过程序员的都清楚，多人合作，要是没有人站出来统一标准，最终项目代码就是一坨屎，久而久之，系统就变成了一座危房，没人敢维护，没人愿意接手。

唯一的出路就是重构，费时费力还不一定就稳。

3.2 方案评审

技术这把刀磨锋利了，还得用得合理。

所有的项目技术实现方案都要拿出来评审，在跨技术组合作的情况，经常因为沟通不到位，信息差，造成开发过程中的返工。

磨刀不误砍柴功，动手写代码之前，必须拿出来放在桌面讨论得清清楚楚，确认无误之后再开发。

提前防火，远胜于紧急”救火“。

3.3 赋能业务

技术就是为了给公司的业务做好支撑，脱离业务去谈技术，纯粹是耍流氓。

研发要以业务支撑作为工作的首要目标。

公司业务都得不到支撑，商业模式得不到验证，扯再多的技术都是白搭。

虽说赋能业务，但研发人员不是机器，对于运营的需求，如何控制研发的节奏，需要产品经理做好把控，根据重要程度和紧急程度定好优先级。

产研在确保满足运营需要的前提下，要对做不做，做什么，怎么做，提出自己的意见和建议。

不是每个运营都专业，也会有瞎提需求，为了冲自己的运营 KPI，疯狂提研发需求。

一个运营活动不行，就想着赶紧再搞一个，只注重数量，不注重质量。

我们允许 产研有一定的否定和拒绝的话语权 ，要不然就会把研发人员当机器人了，活生生地带成了一支乙方外包团队了。

什么时候全力支持业务侧，什么时候行使产研的话语权，这里需要一个管理级别高于运营和研发的人，才能做决策并推动。

否则运营会觉得研发的技术菜鸡，不配合。研发又觉得运营傻逼，没有整体规划，想一出是一出。

公司的内耗就出现了！

3.4 创新提效

干技术的，团队总得要有点工程师文化。

技术团队除了赋能业务部门，还可以对内做一些技术上的实践的创新。

目的是为了提高团队的效率，可以降低公司的人力成本，和试错的时间成本。

比如做一些技术上的常用封装、难题攻坚、提高代码的复用率等等。

比如搭建自动化测试，提高测试的效率和质量。

定好技术规范，做好方案评审，才能更好的赋能业务，才能有精力去创新提效。

没有好的规范和评审环节，就是一边挖坑，一边填坑，技术天天都在救火。

老员工扛不住拍拍屁股就可以走人，屁事也没有，新员工也接不住这些天坑，扛不住也会离职。

运营也会吐槽埋怨系统不稳定。 更别提什么技术创新了，根本没这个时间和精力。

总结一下，关于技术管理，看上图。

通过左边的「定制度」，定好统计的技术规范，做好实现方案的评审。

来 实现 右边的「拿结果」 ，技术为业务赋能，也有时间和精力去做创新 。

项目管理

我把项目管理工作划分为 4 个模块，如下图：

团队搭建好了，技术规范制定好了，最终还是要在项目研发上试验一下。

是骡子是马，拉出来溜溜。

4.1 项目目标

我强调研发人员，一定要去了解项目的需求背景和目标，为什么要做，做到什么程度，能为用户带来什么好处，能为公司带来多少创收？

这些是程序员要去了解的，了解后你的视野和格局会更高，你会更清楚你的工作的意义在哪里。

程序员最大的通病，就是只关心技术。把自己定义为一个码农，只是在敲代码。

4.2 研发流程

每个研发团队都有自己的研发流程，都大同小异，可以互相借鉴一下。

这个是我基于我们团队目前的情况，定下来的一套流程，目前执行得还不错。

4.3 交付标准

这里的交付是指研发完成后，对业务部门的交付。

这个环节产品经理会跟业务部门紧密沟通，做好上线前的准备。

比如一些预热和系统的基础配置，确保上线后用户能正常使用。避免交付环节沟通不到位，导致的上线事故。

产品上线，运营配置还没准备好，这种事情也偶有会发生。

跨部门沟通，依靠人去推动，总是有阻力的。

项目的各项工作都要列在流程制度里面，到了什么环节，由谁负责做什么，一目了然。谁也不用求着谁去做什么。

4.4 项目复盘

项目上线后，我们会对这次研发过程做一次回顾复盘，做得好的人和事，给于表扬奖励，继续保留。

做的不好的，找出根本问题，从流程制度上进行优化调整，避免再次犯同样的错误。

举个例子，上线后发现一些 bug 没测出来。要追踪是测试用例没覆盖到，还是测试人员没严格执行；又或者是关联模块的改动导致的 bug。

针对不同的原因，管理上会做不同的调整。

测试人员执行不严格，绩效考核就要着重考核这部分的工作。

测试用例覆盖不全，就要加大测试用例评审的力度。

关联模块改动导致的 bug，就要求相关联的模块负责人都参加评审，在实现方案环节加大评审力度。

这么看的话，我们制定的制度也不是一成不变的，制度流程会一步步规范完善起来，团队的战斗力也会随着提高。

总结一下，关于项目管理，看上图。

通过左边的「定制度」，项目目标同步给整个项目组成员，明确工作的意义，严格执行项目流程。

来 实现 右边的「拿结果」 ，高质量地交付，针对结果复盘，沉淀经验，完善团队 。

最后再回来看一次这个完成的管理体系，思路是不是就清晰很多了。

2 个维度：管人管事 ，定制度拿结果。

4 项工作：人员管理，文化建设，技术管理，项目管理。

16 个模块：人才标准，绩效考核.........交付标准，项目复盘。

是目前基于我的管理实践、学习、总结梳理出来的一套逻辑自洽的管理体系和方法论。

对我来说，学技术和做管理都一样，都是先实践，后反思，结合学习，总结出自己的经验和方法，就是提升。

分享给所有想从「技术走管理」的读者朋友，将来你一定会用得上。