问题：对管理不熟悉，团队现在40人，活多却效率低，怎么办？
在日常接触研发团队的管理人员过程中，有一次我被问到这样的问题：
某技术团队负责问到："我本身不懂什么是管理，之前都是直接完成任务就行，现在团队大到40人、活多却研发效能不高，该怎么办？"
根据这个问题以及提供的团队上下文信息，结合新场景下的研发团队对于项目管理的诉求，我来做个总结和分享。
观点：业务优先，以价值驱动研发提升
在前面我也有发表过文章来介绍：如何打造价值交付驱动型的软件研发团队，以及研发指标体系的设计。继续保持我的观点，对于业务型的技术研发团队，不能过于仅仅专注于技术本身，还要在企业的维度和层面关注技术给业务所带来的价值。
应该急业务所急，及时响应和满足产品用户所提出的需求和问题，优先开发实现和交付对业务销售、订单、用户新增和职能部门效率提升有帮助的需求功能，而不是做出很多功能但几乎没人使用的软件。
以业务优先，以价值驱动研发效率的提升。 先思考如何满足和提升业务价值的交付速率、交付质量、部署频率，再以此来驱动思考研发团队内部的效率提升。研发效率的提升是起脚点、而业务价值的快速响应和有效交付则是落脚点。
立项：起个项目名称就叫： "火箭"加速计划
我喜欢在工作的节奏是有条理性、目的性和明确性的，为了让老板、团队和负责人知道指定目标的工作计划、进度情况和最终取得的成果，我都推荐和践行在YesDev项目管理中给每一个项目创建一个项目，并起一个内部贴切的名称。例如，针对研发团队的转型和效率提升，我喜欢使用诸如"火箭"加速计划的项目名称，再配上一个小火箭 ，贴切又有活力。
然后，在项目文档中列明此项目的目标和背景，例如：提升研发效能和交付质量。再拆解成具体的执行计划和需要各部门、各小组分别负责的事项和完成日期。
这里有一个小小的工作技巧和心得，为了更好推进项目的实施和开展，尤其是这类由虚拟小组或委员会组成推进的虚线项目，项目负责人应当先和决策层做好前期沟通，再和各小组负责人进行会前的同步和私下一对一了解各个小组的现状和难点，再制定好可行成熟的项目计划，随后再预订好会议时间进行宣导，最后才是创建项目和分工执行。
创建项目不难，但执行落地不容易。做好充分沟通和授权，是项目成功的必要条件之一，也是减少阻力的有效途径。
关键路径及效率提升路线图
在了解团队背景、项目上下文和明确提升的目标后，就可以进入更具体、更有执行层面的思考、设计和工作安排了。对于已经有丰富团队管理和项目管理经验的负责人来说，再次制定一份效率提升计划并不难，但对于一位从来没有正式管理过小型团队的负责人来说，提前获取必要的知识、方法论和干货，则是"临危受命"、"连夜充电"、"现学现卖"的一个很好补充。
找到项目实施的推进的关键路径，可以让你和你的团队少走弯路，有序达成既定的目标。
关于研发团队效率提升的路径图，整体流程分为7个阶段。下面结合的是YesDev项目管理进行介绍，如果你使用的是其他项目管理工具，也可以对号入座。工具本身无分好坏，关键还是在于如何使用好你的项目管理工具。
第1阶段：团队导入
团队的导入，又分为三个具体可以实施的步骤。
首先，1阶段的第一步，如果是第一次使用YesDev，可以由管理员分配好员工账号和权限；如果是使用其他项目工具，可跳过。这部分是常规的成员管理，包括组织部门、外部人员可以设置账号有效期等，不展开细说。
1阶段的第二步，就是在你的项目管理工具中完成基础性的后台配置，包括但不限于：
工作组的划分： 根据产品、技术、测试、运维、客服等职能岗位，结合内部日常工作的需求，创建对应的工作组，并设置各个小组的小组管理员（方便后续自我组织自我管理）。在YesDev中的工作组，是可以用来限制项目的访问查看和操作权限，除了控制必要的项目权限，更多的作用在于让繁忙的一线员工只须关注关心和他自己有关的项目即可，不需要了解全公司那么多项目。工作组权限又分为：私有/保护/公开，方便不同范围的项目协作。如上，前面的 "火箭"加速计划就适合放在 公开的工作组，以便后续的新人和全员进行学习和培训。
项目的分类和模板设定： 根据公司的业务情况，预设好需要的项目管理能力、模块和分类，方便后面每个项目能快速对号入座，形成标准化、统一化、工程化的项目管理体系；譬如有：研发类项目、维护类项目、项目集、公司一级专项、外部合作项目等。最好种类不宜超过6个。YesDev是可以支持不同的团队配置和预设各自的项目模板，做到快速贴合研发场景的需求。
这里多说一下，在YesDev里，以及我推荐的，
Project IS 项目是指:
-
✅ a sprint 一次迭代冲刺 (faster)
-
✅ a software version upgrade 一次软件版本升级 (smaller)
-
✅ same as a IM group 类似一个聊天群 (don't call us, we'll call you)
-
✅ dynamic 动态的 (more frequent)
Project IS NOT 项目不是指:
-
❌ NOT The complete life cycle of the product 非软件产品从出生以来的全部内容 (Longer)
-
❌ NOT a full software product 不是完整的一个软件产品 (Larger)
-
❌ NOT static 静态的 (far far away)
研发流程的配置和全局别名配置： 不同的企业、不同的团队，对于一些需求状态、问题类型、术语称呼、流转的顺序和要求也各不相同。因此，在正式开始你的项目管理之前，请一位熟悉原来内部开发流程的同事或项目经理，对项目管理工具中的研发流程进行必要的配置和全局别名配置。如果这一块，暂时没有什么概念，也不用担心，也可以在后续熟悉后再回头来进行设置。
YesDev自带提供了丰富的后台配置，除常规的系统配置外，还有特色的：任务SOP流程配置、放假调休配置、任务工时个性化的高级配置、文档模板的配置、默认列表筛选器的配置等。
剩下1阶段的第三步，也就是最后一步，就是需要在团队内部简单介绍项目管理工具的使用。一般来讲，项目管理工具的使用不难，但要按流程协作使用，和按管理要求及达到团队高效协作的效果，就需要大家每位成员通力配合才行。
如果团队内有一位成员不同频，或掉队，或反作用力，整体团队就会很痛苦，至少在同一个项目组内的沟通和协作成本就很大，交付质量也很差。
还有全局的别名配置，让系统工具更符合你的团队文化和习惯。
从简单到复杂，完成了团队的导入。讲完了人的导入，再来说说事的导入。
第2阶段：产品线和需求导入
人员的导入有一定的复杂性，花了一些篇章，接下来介绍事的导入，主要是关于产品线和需求池。
首先，是产品业务线的配置，是具有全局性的，可以根据公司的业务的产品进行设置。如果产品线过多，则成员可以选择是否需要展示，以便后续快速统计每个产品线的项目、需求、Bug缺陷等。
其次，就是录入或导入你的需求池，可以单个创建，或批量Excel导入，方便把历史的需求快速导入，例如把禅道的需求导入。
关于YesDev本身的需求流转，也顺便分享这张PPT，让你和你的团队，尤其是研发和测试人员，明白和搞懂如何把需求和任务、Bug缺陷、代码、交付物、实时通知反馈进行关联。
第3阶段：提高项目并行和工作并行效率
对于团队而言，当前活跃和并行的项目，是体现团队效率和工作量的一个很好指标。如果一个项目沉下去了，或者每天进行的项目只有数个，或项目"长期睡眠"没动静，那么既不能体现最新的真实项目动态，侧面也反映了团队的状态士气是低下的。
为此，结合最近使用算法规则，YesDev在项目主界面是以最近更新的时间来对项目进行列表排序，就和日常聊天一样，哪个项目最活跃，哪个项目就在最前面，提升大家对项目的关注度。
对于个人而言，同时在进行的需求和任务数，包括待办的工作项，则是一个很好的参考指标。例如：新的需求有哪些、正在进行的任务在哪些、哪些需求任务是延期的、还有多少个Bug要等待修复。最终拆解到最小颗粒度，则是每周、每天的任务工时，即工作度的饱和情况。因此对于成员个人而言，提升工作的方法是，既要做好工作计划、也要明确当下的工作重心、还要清楚未来一个月的方向和已经遗留延期任务的及时提醒。做到多而不乱。
第4阶段：建立快速稳定持续的交付和部署能力
前面完成了团队、人员、产品需求的基础导入和熟悉，对于落脚点，对于如何提升研发团队的服务能力和交付能力，则需要从几方面进行入手。
一方面，要尽快搭建CI/CD自动化、持续集成、持续部署的能力；
另一方面，还要结合工具和流程，制定每周版本迭代、每月计划、SOP标准化作业流程、团队规范和开发流程等一系列的前置配套工作。
才能"软硬兼施"，技术硬实力，加上软能力。把DevOps、敏捷开发、一键发布等，融合整合在一起，为业务交付打造强有力的研发支持。
第5阶段：有针对性提升项目质量
基础设施搭建完毕，自动化或半自动化发布流程也落实了，那么就会发现，项目交付质量还是会存在很多缺陷，除了测试慢、耗时长、问题多、故障频发，还有很多漏洞要补、很多性能扩容、系统卡的优化要做。怎么办？
近期，我在周会上和我团队负责测试的负责人讲，你要持续做好以下几个链条的持续跟踪，我觉得也是大家可以应用的方法。为了有效提升项目质量，要有四个抓手：开发质量和Bug缺陷跟踪、抓发布上线标准化流程、线上故障的响应和处理、以及售后工单的处理。
抓：开发质量和Bug缺陷跟踪：
通过提前介入到需求评审，让测试人员在正式测试之前，创建好测试用例，并且制定测试计划关联到项目一起联动。对于复杂和涉及核心主流程的需求，进行有必要的测试用例评审。
抓：发布上线标准化流程；
在发布上线前必要先发出测试报告，即测试通过后才能进行发布。并且规定每周的常规发布窗口，一般选择在周二、周四进行发布，周五不发布。同时提前收集好发布计划，充分和业务部门保持联动，测试通过后随时等待发布。
在发布之前，做好上线发布的准备，包括代码合并、线上配置、运营内容的通知、相关资源有准备。在发布时，在YesDev根据既往的发布流程，制定好上线发布的SOP流程。
把每一次发布，都当作一个需求来看待。每一次发布，需要哪些人员进行哪些标准化的操作，都一一列明，包括：代码合并、code review、预发布验收、线上回归、版本更新公告通知。发布后如果发现有漏测的Bug也可以统一记录，以便复盘，这也是对于测试考核的重要指标之一。
下图中，是我们团队每周一次发布的标准化流程。不管是做SaaS服务、还是做互联网产品；不管是做外包项目的验收交付部署，还是做标准化产品私服更新交付的，都就尽早建立一套属于自己团队标准化的发布交付流程，避免重复的事项、频繁出差错，避免让客户觉得不靠谱，或不专业。
抓：线上故障的响应和处理；
不管前面做得再好，"常在河边走，哪有不湿鞋"，就算是某大型的文档协作平台也有宕机的情况。一旦线上发生故障，对于客户和用户和业务，那就是相当于毁灭式的损失。
尤其是，团队现在已经面临或正遭遇天天救火的团队来讲，更是需要建立一套快速响应线上故障的机制和流程。上班时段还好，如果是下班后，或晚上，或周末，或节假日，出现故障怎么办？客户很着急，但又没有来处理，怎么办？
首先，我们可以使用SLA服务水平，这个指标来作为系统全年稳定性的一个核心重要考量指标。
一般来讲，能做到两个九是普通的水平；如果能做到三个九，即99.9x%的SLA服务水平，则是相当不容易的了。相当于每年系统只崩溃8.77 小时、分解下来每天只崩溃1.44 分钟。
为了达到更高的服务水平，一方面需要对线上故障建立一个评级体系，如P0表示致命最高故障，P1重大故障、P2一般故障，依此类推；再者，可以对每个系统、各个产品，进行观测，统计和记录连续xxx天线上无故障，也是作为每个团队内部对比的一个指标，看谁做的系统更稳定、更可靠。在这背后，还要在运维层面建立配套的、完善的实时监控报警体系和日记体系，这里就不展开了。
凡是有故障，都要记录，处理后进行复盘，以及提出改进的措施，落实到人，避免再犯。
抓：以及售后工单的处理：
开发质量要高、需求交付要快、线上故障要少、还有一点就是不同用户要使用产品软件过程中，总会遇到一些这样那样的小问题，这些问题呢，不一定是bug，也不一定是故障，有可能是系统功能暂时无法满足，需要技术人工处理的，也有可能是用户在使用过程中遇到卡壳的反馈和投诉。对于这一类异常情况，可以建立工单，统一收集、处理和反馈，还要考核技术工单处理的负责人员指标和奖励。
关于工单处理的指标，可以关注响应速度、客户满意度、工单处理完成率、工单自动化占比；关于工单的奖励，可以根据工单处理的难度、数量进行一定的现金奖励，合并到工资一起进行发放，让工单处理者多劳多得，同时提升服务质量。
第6阶段：配套研发考核指标，形成流程闭环
在工具落实和流程跑通后，再来补充配套建立研发团队的考核指标，形成流程闭环。只有公司制度加持，研发指标的执行才更加有章可依。
例如，曾经有管理人员问我，在YesDev登记工时后，后面会以工时进行考核吗？
关于这个问题，以及公司的工资、绩效、年终奖、项目奖，具体和哪些项目指标挂钩，则是需要公司决策层来决定，以及结合人事行政，再同步考虑其他部门的考核方式进行裁定。
对于绩效评估，也有人和我探讨过，是否需要互评、上级评分、怎么进行绩效考核和目标设定，这一些，也可以根据团队人员和管理方式，进行设计。
例如，下面是我参考了老东家的绩效考核模板：
第7阶段：每月复盘总结，不断改善度量方式
我认为，研发效率的提升只是一个起点，每年的业务不同、每年的团队规模不同、每年的侧点和发展周期不同、每年技术革新不同，需要持续动态在月度会、半年会议和年终总结会议以及专题会议上，持续跟踪研发团队过往的历史指标和度量方式。
我一再在现场会议强调，度量指标无分好坏，但要真实，让负责人和团队清楚自己目前的状况，从而有意识进行针对性的提升。我觉得，这一周比上周有进步、下个月比这个月更优秀、下一次项目交付更有成效，我觉得就是进步。但从优先到卓越，是一个过程，需要持之以恒，不能只有开头，没有结尾。
例如我们YesDev产品粗略的全年迭代回顾，
分解到研发团队的指标回顾，
还有一些更细粒度的统计，例如项目甘特图、排期表、每个月团队的任务工时统计、脑图等，也可以进入到YesDev自行查看，系统会生成生成和帮你汇总。
以上，专题分享完毕。
关于作者
黄禅宗 dogstar，果创科技创始人，YesApi果创云亿级流量PaaS平台创始人、YesDev研发协同SaaS创始人，累计服务3万+开发者； 前唯品会高级开发工程师，千万级架构经验； 前MobVista高级工程师、前租租车技术经理； 10年以上互联网经验，对软件领域有独特见解；PhalApi开源框架作者，著有《良质!》等电子书；退役士兵，华南师范大学软件工程专业，喜欢交流分享。