像CTO一样思考：如何高效管理30人的研发团队？

前言

今天是2022年国庆长期的最后一天，国庆回来后即将进入Q4第四季度。转眼间，又快到了元旦和春节的时候。正所谓，“员工过节，老板过关”。今天继续来分享一下，30人的研发团队，如何管理更轻松、更高效、更成功。

管理原则

先来分享一下，我从事研发管理近十年的管理原则和心得总结，包括我自己总结的、或学习到的或别人提炼的。

原则1：管理，就是要越管越轻松。

原则2：我相信，但我要确认。

原则3：人可以犯错，但流程制度不能。

原则4：尽早实现闭环管理，形成正反馈。

作为一名研发管理者，或者作为一名需要管理团队的技术负责人，你需要掌握很多技能和多方位专业能力，譬如：技术能力、管理能力、统筹、沟通、产品业务能力、系统架构、人员招聘、甚至服务器运维能力。但这些都只是管理者基本的能力，而不应该成为你日常事务的核心和重点工作。

简单来说，作为研发管理，要懂得分配、安排和统筹。要有自己的想法、规划和整体的把控节奏。不管是以前管理10个人的团队，还是现在带领30人的队伍，抑或是未来上百人规模的企业研发团队，你都应该能轻松应对，要越管越轻松。好的研发团队，应该拨高来用，即下级对上级进行向上管理；而不是反向而行，始终都是向下管理，甚至CTO干经理的活，经理做工程师的事，工程师最终还要被当作实习生来对待。如果是这样，就会越管越累，不仅团队得不到成长，而且团队整天都很忙还效率不高、问题一堆。

有这么一个小故事，有位高级经理人上班后帮忙清倒了垃圾，却被老板训斥。这就好比如CTO做了实习生本身要做的事。事情本身不分对错，只是站在不同的角度，有不同的解读。

古人有云，“用人不疑，疑人不用”。在对待自己的研发团队时，应该相信他们能把事情做好，并授权给一线的开发人员，让他们得到充分的专业发挥，而不应该限制他们的工作。但在相信他们的同时，也要进行二次确认，始终秉持“我相信，但我要确认”的原则和严谨精神。因为每个人都会犯错和疏忽，通过发挥团队的智慧，团队犯错的机会将会大大减少。比如进行回归测试、代码review、开发演示、变更审批等。

前面有提到，每个人难免都会犯错。但作为管理者，你所设计和同意的流程制度不能有纰漏。管理者所作的每一个决定、每一次沟通都应该深思熟虑。正如红绿灯的交通设计一样，某辆车可能会不小心闯了红灯而扣分，但红绿灯的设计一定要正确、人性化和统一化。好比如，某个开发人员可能会因为忽略大意而写了一个Bug，但在研发流程和发布上线的流程设计上就不能有纰漏。因此，对于流程制度的设计，一方面要结合当前团队的人员规模、业务特点和需要重点解决的问题来设计，另一方面也要在人员出错的防范、效率提升、发挥团队集体智慧等维度综合考量。你应该站在一个更高更抽象的角度来思考，不断思考一个倍受大家欢迎的公园应该是怎么设计的，思考一栋有活力、经典和永恒的建筑要遵循哪些模式，思考一个成功、优秀、卓越的研发团队应该需要怎样的流程和制度。

最后，反馈很重要。向上汇报很重要，向下反馈也很重要。能保持顺畅的双向反馈和闭环管理，对于研发团队的协作和沟通都是非常明显的积极作用。在向上汇报方面，要培养团队在正式汇报、会议汇报、私下沟通、书面总结、非正式场合的沟通，提醒下属既要报喜也要报忧。凡事，先记录、后跟进、最后要反馈。反馈很重要，主动汇报更难得。

另一方面，同时也别忽略了要向下反馈。好的爱情，都是双向的。团队也一样，没有严格的上下等级，只是分工和角色不同。作为管理者，不一定要始终保持“神秘感”，让人“捉摸不透”就是牛。当团队做得好或者某人表现优秀时，记得在公开或私下场合，给予认可和赞同。当有业务增长和业绩时，也别忘了给团队一些鼓励或安排一次下午茶或小饭局。在例会或正式会议上，也可以把一些重要的信息和高层指示同步给大家。“要想走得快，就一个人走；要想走得远，就大家一起走。”

当向上汇报、向下反馈的沟通闭环形成后，同时结合前面研发流程的管理闭环，就能双管齐下，形成正向循环。如此反复，持之以恒，优秀和卓越的研发团队，将会得以呈现。

产能、产出和产效

接下来，继续重复聊一下产能、产出和产效这几个话题。

站在不同的角色角度，以及一家企业经营、生存和发展所需要的基础，我把研发生产力分为三层，分别是：一线人员的研发产能、管理层的软件产出和经营者关注的企业产效。简单总结就是：既要把活干好，又要能出成绩，还要能帮公司赚钱。

一线视角：研发产能可视化

作为基层的研发人员、工程师、技术人员和程序员，他们在工作上，关心的是具体能完成的事务、具体的工作项、以及在自己能力和专业领域内能完成的任务。

在IT互联网行业，普遍有“内卷”、加班、996等文化。对于怎么让研发团队加班这个敏感话题，我的建议是不必太在乎和在意所谓的加班，更不要进行没有意义的加班。软件研发是一个需要高智力的工作，不同以往工业时间使用科学管理的方式就能提升程序员的工作效率和进度。很明显，你不能按代码行数的多少来衡量程序员的工作量。

但是，我们需要知道研发团队每天都在做什么，以及他们本周和下周的工作计划是什么。我们要共同看见研发人员的每天工作计划。虽然登记每日工时是很常规的工作，但对于团队管理和个人高效工作，都是有很重要的意义。对于工程师个人，他会清楚，自己接下来这周每天的工作计划；对于项目经理，可以提前了解项目的排期计划表和项目进度和延期风险；对于研发管理，可以实时掌握研发团队的工作量饱和度和工作情况。坚持让一线员工亲自、如实地登记工时，实现研发产能的可视化，是我们后续研发效率提升的基础和关键。

在进行工时登记前，需要先完成两件重要的事情：第一件事是人才盘点；第二件事是梳理划分核心域、支撑域和通用域。第一件人才盘点，是了解现有研发团队的人员情况，例如前端、后端、产品、测试分别有多少人，每个人工作年限、入职时间和角色分别是什么，包括每个人的简历、过往晋升调薪情况等，这有助于管理者（特别是空降的管理层）快速掌握人员情况。这对于后续的人员分工、培养基层管理者、安排新人导师、挖掘KOL意见领袖以及人才培育方面都会有重要的信息参考价值。

第二件事是关于主营业务的识别和划分。这点在DDD领域驱动设计一书中有专业的介绍。对于管理者，除了掌握团队人员的情况，还要了解公司产品业务的特点和核心业务的划分。从而进一步梳理和划分支撑域和通用域。然后在这基础上充分利用自研、外包开发、采购等模式，选择合适的解决方案，发挥和使用外部力量的资源优势，让自主团队更加专注于核心业务的研发和投入。此时，可以参考721原则，即70%以上的时间精力和研发资源投入到核心主营业务和主流程团队；20%左右的资源配置到支撑域，剩下的10%则划分给通用域。

结合YesDev研发协同工具的使用，我们可以更清楚地看到。任务登记在人员工时登记和项目进度两方面发挥了很大的作用。

首先，对于个人、行政部门和虚拟的项目组，可以分别看到自己的、自己所在部门的、以及参与涉及的工作组的每周任务计划和工时登记，可以分别满足个人、技术TL管理者、项目经理等多种角色。

为此，结合团队人员和核心域的划分，可以在YesDev后台配置好需要的工作组和产品线。

其次，对于项目侧和交付侧，任务和工时，可以关联到需求，也可以归集关联到项目。在项目维度，我们可以看到项目汇总好的实时开发排期计划表、项目每日燃尽图、多个项目的宏观七彩甘特图，甚至还有研发的成本核算。

项目的开发排期计划表，也可以分为两个维度，为项目经理、技术管理者和老板提供不同视角的统计数据。如果你是项目经理或老板，更关心结果，那么可以查看项目开发计划表，因为它会从项目到需求再到任务这样的层级进行下钻透析，还可以对比上一次发送和统计的结果变化。

如果你是实线管理的技术管理者，更加关心人员的任务完成情况和目前的工作计划，则可以查看人员排期表。它会从人员出发，统计每个项目成员所需要的工作量，以及计划开始时间和计划完成时间，还有当前的实时完成进度。比如什么时候开发联调，什么时候可以提测，什么时候可以上线等里程碑节点。

这就是研发产能可视化的作用和价值。

在此基础上，我们可以引申和得到我们需要进行研发效率提升和工作计划安排的基础工时数据。再进一步，我们还可以围绕任务和工时，完善闭环的协作和闭环反馈。例如，针对任务的延期设置任务延期提醒，同时进行钉钉群、邮件等同步和提醒，除了提醒开发者本人，还可让团队保持信息同步。

又如，当任务完成时，所关联的需求，由YesDev系统自动发出和更新需求进度给到需求方和产品经理以及抄送给测试人员。形成需求进度的向上智能反馈。

除此之外，任务还有很多重要的实用的参数配置，可以结合自己团队的管理和协作需要，进行配置。

前面所提及的项目燃尽图、七彩甘特图、项目脑图等，也可以在YesDev的项目中即时获得。不管是要用邮件汇报，还是要导出Excel附件，还是查看在线的图表，都能随时查看和下载。

最后，小结一下研发产能可视化的实施要点：

1）了解团队人员情况，划分业务的核心域；

2）建立工作组，由小组长或意见领袖人员负责督促和协调小组成员的任务工时；

3）每周或每双周定时检查和验收任务的完成情况；

4）协作过程中，如有必要，可以结合每日站会进行当面沟通；

5）使用YesDev的每周工时登记或其他工具进行任务工时登记、统计和任务协作。

管理视角：软件产出最大化

曾经我作为一名PHP开发工程师，在我看来，根据产品功能需求完成开发和上线是最基本的岗位职责；而以更高效率和更高质量地完成需求开发和上线交付，则是属于良好的工作表现。那怎么才算是优秀的级别呢？

优秀员工的表现是，你不仅出色完成了代码的编写、功能的开发和上线，同时你还保证了100%通过的单元测试、遵循了合适的设计模式、在静态代码质量方面维持了较低的技术债务、在数据库慢查询和接口响应时间等性能方面有合适的解决方案和提前考虑、在文档编写和UML图表设计有清晰的思路……也就是说，你不仅直接产出了代码和软件，还配套产出单元测试、文档、代码分析报告、UML架构设计、安全检测报告等间接的产出，这些产出是可以量化的，是行业内的标准，是通过第三方来评定和认可的。

那么，何谓卓越的员工呢？卓越的员工不仅能出色把事情完成，而且这件事情本身也是很有价值的。例如，卓越的员工会主动发现问题、提出他的解决方案并在完成需求开发的同时主导或独立落地实现，最后他还会给出优化后的效果对比和分析记录对比总结和分享等。又如，卓越的员工都会超越自己去思考、负责和实现在他能力范围外或在他职责以外的目标，帮助团队或公司不断解决别人解决不了的历史难题，或是创造新的价值。

一开始，优秀或卓越的员工会快速学习，独立完成任务；逐渐地，他会成为团队内的意见领袖（虽然他还只是一名普通的开发人员），并持续给团队带来正能量和积极的促进；到后面，他会乐意接受不同的挑战，带领团队完成一个又一个看似抽象、不可能完成或者别人不愿意接手的疑难杂症。

所以，回到团队管理者的视角。你觉得作为一名技术管理者，什么更重要？

作为一名管理者，有不同的管理风格和方式。有些以权威的方式进行推进，有的则以教练的身份和团队共成长，有些会以“无为而治”得让人看不透的方式进行团队管理。不管何种管理风格，要想有出色的团队，首先，你需要有出色的成员。结合20-80定律，在团队员最为优秀的卓越的成员，一般情况下来源于三种途径：第一个是从新人成长到独挡一面的老员工，作为老员工，熟悉业务、熟悉团队、熟悉历史、熟悉各种坑；第二个是来自空降的技术人才或职业经理人，这些人有良好的背景或权威的专业知识和经验，但要确保人才和当前团队的匹配程度；第三个则是作为管理者，之前的老部下。

加班，只是在工时方面，粗糙地填补，即使你让研发团队每天都多干了几个小时的活，但不一定就能提升团队的软件产出。软件产出就是最终可正常工作的软件，以及配套的中间输出物、制品和统称。即我们平时所提到的：源代码、数据库设计、上线的软件系统/产品/App、文档、单元测试用例、功能测试用例、测试报告、静态代码分析报告、构建的版本、PRD、设计稿等。

在软件的课程里有一门课叫：算法。算法里面关于排序的算法有很多种，归纳为用时间换空间或用空间换时间。不同的场景，不同的排序算法有不同复杂度。但目的都是为了找到最短路径或最优算法。既然明白了在软件研发团队，其效率和产出，可以通过量化最终能正常工作的软件和中间的输出物这一观点，那么作为技术管理者，就可以围绕这些流程，结合DevOps和需求业务的上下游进行联动、整体性的规划和统筹。

你要思考，当前你的研发团队，最缺什么、更需要的是什么、亟待解决的问题又是什么。如何才能让你的团队持续、稳定、高效地交付有价值的软件产品？

先来观测一下，在DevOps流程过程中，行业内推荐的需要用到的工具有：