根据题主这个问题和描述，整理下来可以分两个部分进行回答：

        一、如何做好一个管理者

        二、如何管理好一个小的研发团队

1、如何做好一个管理者

以下内容整理自知友王世民文章：聪明的领导，会用这4招来管理下属（侵删）

• 背景故事：

我是工作第2年开始带团队的，那是2005年，我担任开发组长，手下有两名比我大两岁的同事。刚开始，因为完全没有带团队的经验，而且他们又比自己年龄大，心里还挺忐忑的，怕他俩不服自己。因此，我工作起来比升职前更加拼命了。

这么战战兢兢地一个月下来，我变得一点都不忐忑了，但这两位同事在我心里的形象也一落千丈。我甚至偷偷在心里给他们分别打了一个标签，一个是“笨蛋”，一个是“懒货”。“笨蛋“的来源是因为这位同事写代码的能力实在不敢恭维，50行代码能搞定的功能他能写上几百行，而且Bug还很多。他编完的代码，我基本都要重做一遍。“懒货”的来源是因为另一位同事工作期间，一会儿要出去抽支烟，一会儿要去便利店买瓶水，我1天就能写完的代码，他至少要干上3天。因此，那段时间我特别累，几乎一个人将一个组的工作都给干了。

于是，只要跟人聊到工作累的话题，我都会“怨妇式”地抱怨这两个人的能力实在太差了。后来随着自己带团队的水平日渐提高，我觉得这种“怨妇式”的抱怨应该彻底远离我了。没想到，13年后的今天，我一位转任子公司老大不久的朋友开始跟我抱怨，手下的那些副总和总监们能力不行，一点儿都不让他省心。每次见面都唠叨这个，让我恍惚间有一种往昔再现的感觉。

其实，下属绝对会有缺陷的。之所以需要团队管理，就是因为每个人都存在缺陷。凡是抱怨下属能力不足的领导者，99%都是自己在人才的选择、配置、管理或培养上出现了问题。

• 做好“选人”

一切团队问题都源于自己的管理无能，无关下属的能力。

对这句话，你可能会有这样的质疑：假如公司配给我的人确实能力很不行，难道这也是我的管理无能吗？是的，因为选人本就是领导最重要的职责之一。

微软的观点就是，选对人比培养人更重要。对的人进入团队后，会快速产生价值，而且你需要在他们身上花费的精力会很少。但如果选择的人能力不足，你就要投入更多的时间和资源来培养他们，还要把本该他们干的活给干了。这意味着作为领导的你，一段时间内基本上把自己填进去了，实际上耽误了更重要的工作。如果选择的人在人品上有问题，那对团队而言更是一场灾难。

有个著名的“酒与污水定律”，说的是：一匙酒倒进一桶污水，得到的是一桶污水；把一匙污水倒进一桶酒里，得到的还是一桶污水。因此，与其花费很多不必要的精力来培养不合适的人，不如花更多的精力在选择合适的人上。

• 做好“搭配”

选好人后，不代表你就可以高枕无忧、放手不管了。

同样的一批人，在不同的搭配组合之下，团队表现可能有天壤之别。这就是为何同一支足球队，在不同教练手上，战绩会有巨大不同的原因。

团队管理的本质就是优化人员配置，配置水平的高低体现了团队管理水平的高低。人力资源管理中有一个“不值得定律”，这个定律说，一个人认为不值得做的事情，就不会做好。你要相信，没有能力不行的下属，只有放错位置的人才。

位置放错了，他就会认为你分配的事情不值得做，自然就不会做好，在你眼中就成了“能力不行”了。因此，一个优秀的管理者，必须深刻了解下属的意愿、能力、性格特征，合理分配他们的工作。

• 做好“管理”

选好人，做好搭配，一个优秀团队的架子就有了，这就像一辆“车”被制造出来了，但要让这辆“车”动起来，行驶到目的地，还需要有人来“驾驶”，也就是管理。一个人的管理水平不高，主要就是受到这六大因素的影响：目标、计划、沟通、检查调整、领导力，当然每个方面整理出来都是一片大文章，这里就不展开。

• 做好“培养”

前面我们说过，选对人比培养人更重要，但这并不代表你就不需要培养下属了。之所以需要培养，无非是下属现时的工作输出与工作需要之间产生差距了。一个人的工作输出是同时受到态度与个人能力影响的。

第一、态度：下属的态度，通过你的领导力、激励手段，是可以快速改变，并做短期保持的。因此对于周期短的工作，下属的态度并非是关键点。但如果你想培养的是“基石型”的下属，那么态度就是一个最关键的考量点了。所谓“德才兼备，以德为先”，对于态度不端正的下属，如果每次都要靠短期激励来纠正的话，就千万不能当做团队核心来培养了。

第二、能力：关于团队成员的能力，自然要安排培训、创造实践机会帮下属提升。但千万不能陷入到这个误区中：所有人的能力都是可以通过培训提升的。这个观点在原则上没错，但忽略了提升速度的要求。在实际管理中，你会发现，下属提升的速度往往是赶不上工作推进的速度的。因此，作为管理者首要应注意选才，人选对了，培训才能事半功倍。

有没有确实是下属能力有问题，而不是你管理无能的情况？

有！如果组织分配给你的人确实不适合你的团队，而你又没有换人权力的话，这种情况下导致的问题确实不是你管理无能。但将管理成果不如意归因到这样的客观情况下，对你毫无意义。一是根本无法改变现状，二是无助于你管理水平的提升。

因此，接受下面这个观点——“一切团队问题都源于自己的管理无能，无关下属的能力”——对你有百利而无一害。若能克服这些客观制约，你就可以将工作完成得更好，也不再需要像我曾经那样做对管理水平提升毫无益处的“怨妇式”的抱怨。若最终无法突破客观环境的制约，你也能得到更多的管理锻炼，选人、人员搭配、团队管理、培养下属的水平会得到更大的提升。

2、如何管理好一个小的研发团队

以下文章来源公众号，作者PingCode研发VP孙敬云（公众号同）

一、都问研发管理如何管，我想谈一谈研发管理如何理

我们先从一个需求变更说起，如果客户想改一个字，那么你的应对方法是怎样的呢？

1、直接走到开发的面前让他改了，因为这是“顺手”的事。

2、告知需求方需求变更的成本（改需求文档、配置文件、测试用例、用户手册等）和风险（因为工作量的变化影响交付时间），让需求方知难而退或者转化为自己的谈判筹码。

3、放入需求池，设置优先级，尽量安排到下个迭代。

第一种方法的破坏性极大，看似我们在个例上非常“敏捷”，也貌似可以省去很多“不必要”的工作，但是它破坏了流程，破坏了团队的工作流。研发的流程不是为了限制创造力，而是为了保护创造力。

如果缺少流程的保护，那么产研体系的员工就会在各类突发性工作中东奔西走，导致团队无法制定有效的工作计划，也无法准确的预估结果，更没有一种稳定的交付能力。

第二种方法因为有严格的风险把控和时间节点要求，因此往往能够履行交付承诺。但是它对于变化的响应能力太差，往往变更都要经历复杂的流程，而且经常性的牵一发而动全身。对于需要根据市场反应及时调整策略的互联网产品来说，这样的开发方式实在是跟不上节奏。

第三种方法有较强的节奏感，周期性的完成一个产品增量，它比第二种方式灵活，也不会像第一种那么冒进。不过这样就够了吗？

二、工作流管道

设想我们有这样一个管道，当新的需求来的时候，可以将它们引入管道中，它们像水一样流动到生产环境，在这个过程中流动是快速的、单向的、稳定的、持续的、高质量的，最终它们在用户无感知的情况下生效。我们可以扩大管道的直径从而实现量化，也可以分割产品建立多条相似的工作流管道。

有了这样的工作流管道，我们的产品它要么是正在部署，要么就是准备部署。那么我们的产品对外提供的服务是什么样的呢？

用一句话形容就是：用户每一次体验到的都是更好的服务。这句话有点太夸张了，不过这样的工作流是存在的，并且早已应用于领先的互联网公司中。

三、研发管理如何理

搭建和优化工作流的过程其实就是“理”的过程，这里我总结有五点核心原则：

• 让无形的工作显现出来

经常接触开发工程师的人都知道，如果不借助外部工具，真实的进度只有写代码的那个人才知道。对于管理者来说，通过流程和工具将无形的工作显示出来非常重要，因为工作流的可视化是基础，当一切暴露在阳光下，管理者才知道如何“管”。

我的研发团队使用的管理工具是PingCode，我会要求所有的工作必须有一个工作项卡片进行跟踪，而所有人都需要及时的领取任务、拖拽卡片、更改状态、拆分子任务、关联代码、关联构建、提供验收说明等等，通过这些“习惯性动作”让工作进度显现出来。

附上链接：

• 定义完成的定义，配合拉动策略，让工作“流动”起来

根据DevOps的第一工作法，我们要建立一个从左到右的工作流，这个工作流的每个阶段都要有清晰的输入和输出，然后通过标准化的输入和输出，将它们组装成一个顺畅的工作流管道。工作流梳理完成后，我们通过拉动策略让工作进行“流动”。

例如：当我完成一件工作时（一定要符合我和下游约定的完成的定义），我的下游可以将这个工作拉过去继续做，而我则可以在我的上游拉另一件工作继续做。对于“我”个人而言，只要“我”现在空闲，同时看到上游有一件工作标记为完成，那么“我”就拉过来继续做，然后将它标记为完成，每个阶段的“我”使用同样的工作策略，这些“我”让工作持续的流动。

• 引入自动化，让速度和质量并存，摸索适合自己的持续交付方案

当我们开始运转工作流的时候就会发现，有些高度重复化的工作非常的占用人力资源，比如工程师修改了代码之后有可能影响任何一个功能，那么回归测试就有其必要性，但是每次变更都需要人工来回归吗？

要知道回归一次的时间是非常长的，但是不测试又无法保障质量（积累多次变更后统一回归，并不符合我们建立上述工作流的初衷）。这时引入自动化是最好的选择，我相信朋友们对于CI/CD、流水线这些词汇并不陌生，但是很多人并没有创建和维护好自己的自动化脚本，这个我打算下一期专门讲一讲如何让研发和测试这两个角色合二为一，有效的落地一套面向研发过程的测试方案。

• Being agile，适应变化，不断优化工作流

敏捷开发最重要的还是价值观，是内功。而无论是Scrum还是Kanban，归根到底是通过行为约束让使用者在不知道法门的情况下也能成为高手。我认为无论是团队级别实施敏捷，开始企业级转型敏捷，更关注的应该是发展，一种面对变化能够从心态和行动都及时进行调整的能力。

真正落实到日常工作中，就是让所有人主动领取和负责工作，当目标没有完成时是全部人的责任，而不是部分人的责任。让所有人参与到工作流的改进中，在一个周期内加入20%的非功能性需求，尽情的去优化自动化，去调整系统结构，去创造去发展。

• 建立包容的文化，让问题暴露出来，促进企业进化

很多人一看到文化，第一反应是这个有点虚，但是职位越高，越能真切的体会到文化的重要性，人少的时候很多事当面说就好了，但是人多的时候，我们需要通过文化作为载体传达我们的行事原则。

因为篇幅的问题，今天我不想分享的太大，我只说两个在团队级别就能落实并且十分有效的方法：周期性全员回顾和月度1v1。

周期性回顾其实就是Scrum里的Sprint Retrorespective，所有人在一起提出我们流程上的问题，我们一起制定改进计划，并在未来的回顾中验证计划是否奏效。回顾是团队自我改进最有效的方式，也是让团队成员把“怨念”释放出来的机会，一个能够自我优化的团队一定少不了类似的会议。

月度1v1是我在外企学来的经验，那时候我通过1v1向我的老板表达我的想法，后来我也一直通过它管理我的团队。我在1v1上讨论近期的工作、讨论工作流程、讨论成长方向，我有时扮演导师、有时扮演倾听者、有时扮演鼓励师，我通过1v1了解我的团队，也将他们真切的想法反馈给我的老板。

写到最后

掌握了这五点核心原则，基本上就能把研发团队“打理”的清清楚楚。这些年我养成了一个习惯，一旦出现问题我的第一反应是看一看是不是流程的问题。

我会更加关注如何避免未来出现类似的问题，关注团队的成长。

虽然人与人有能力的差距，但是故意破坏规矩的人我还是很少见到的，为所有人建立一个正确的轨道，这便是我说的“理”，也是我今天想分享的最核心的东西。

链接：https://www.zhihu.com/question/28180845/answer/1806309904
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。