基于ShapeUp的团队管理实践反思
本文从ShapeUp的理念和实践出发，反思了当前的团队管理实践，并探讨了如何通过改进团队工作方式来提升研发效能。
团队管理的挑战
主流的研发方法模型
上图是软件开发生命周期（SDLC）的全流程框架。它涵盖了从需求提出到系统运维的整个过程，不仅包括传统的瀑布式开发模型，还引入了敏捷开发、快速应用开发（RAD）、极限编程（XP）等多种方法，这些方法有助于在不同阶段推动团队效率和协作。尽管这些方法模型各具特色，但它们往往在强调流程的规范性和可控性时，忽略了个体的灵活性和创新性。
经典的研发方法论，例如瀑布模型、迭代模型和螺旋模型，是早期软件开发的主要指导框架，其核心理念是将软件开发过程进行分解和串联，强调严格的计划、清晰的文档和规范化的流程，以确保整个开发过程的可控性和可预测性。瀑布模型是一种线性开发方法，将开发过程分为需求分析、设计、开发、测试和运维等多个阶段，每个阶段必须完成并通过评审后才能进入下一个阶段，适合需求稳定、变更较少的项目。迭代模型在瀑布模型的基础上引入了分阶段的迭代开发，将整个项目拆分为多个小型的、可控的阶段，通过逐步完善和扩展满足需求的变化。螺旋模型则结合了瀑布模型的分阶段特点与迭代模型的灵活性，强调风险评估和控制，以增量式的方式逐步完成软件开发。
当下，主流的敏捷研发方法模型有：
- Scrum：主要解决需求与开发脱节以及小团队协作的问题，适用于团队规模在5-10人的项目开发中。Scrum强调通过敏捷迭代的方式推动开发进程，核心活动包括每日站会、迭代计划、迭代评审和回顾等环节。这些活动帮助团队成员保持实时沟通，明确当下目标和任务进度，并通过持续反馈优化开发流程；
- XP（极限编程）：关注编程质量的开发模型，旨在通过严格的技术实践提升代码的可靠性和开发效率。XP提倡一系列核心实践，如测试驱动开发（TDD）、持续集成、结对编程和重构等，以确保开发团队能够快速响应需求变化并保持高质量的代码输出；
- Kanban（看板）：旨在提高协作透明度和任务可视化的管理方法。Kanban通过可视化的看板（如任务板），将开发流程中的每个任务清晰地标注在“待办”“进行中”“完成”等状态中，从而使团队成员能够一目了然地掌握任务优先级和进展情况；
- DevOps：强调开发、产品和运维高效协作的文化和实践方法，旨在打破传统团队间的沟通壁垒。通过工具链的自动化支持，DevOps实现了开发、测试、部署和运维的无缝衔接，加速了软件交付周期。
这些现代化的研发方法论，针对快速变化的市场需求和技术发展，更加强调团队协作、快速迭代和持续交付，以更高的灵活性适应复杂的开发环境。
存在的问题
尽管现代开发方法如Scrum、XP、Kanban和DevOps等在提升团队协作和工作效率方面取得了一定成效，实际操作中仍然存在一些问题。比如：
- 为什么初创公司的效率多高于成熟公司？
- 为什么产品、技术、测试、运维间会相互扯皮？
- 为什么有这么多的“我不清楚，我不知道”？
- 为什么有很多团队管理不好，不服管，“他凭什么管我”？
我们可以简要分析如下：
- 为什么初创公司的效率多高于成熟公司？
因为越是成熟的公司越重规范的视组织能力建设、均衡的激励制度，而初创公司则更关注个人效率、使用更灵活的激励制度，更重视交付的价值；
- 为什么产品、技术、测试、运维间会相互扯皮？
因为每个角色只对专业领域负责，缺乏为一个目标而行动的意识；
- 为什么有这么多的我不清楚，我不知道？
因为每个人只关注任务的“点”，不关心产品的“面”，缺乏对整体的认知；
- 为什么有很多团队管理不好，不服管，“他凭什么管我”？
因为技术能力与工作职责错位，缺乏对团队的认同感。
综上，这些模型方法都是试图通过提升研发组织效率进而提升企业研发效能，但却忽略了人效的提升。而研发效能的提升，不仅仅是流程的优化，更是人效的提升。因此，我们需要一种方法，能够在保证研发效率的同时，提升人效，让每个人都能够更好地发挥自己的价值。
怎么解决？
人效的提升最直接做法是完善考核激励制度，这很重要，但也很复杂，真正能做好的公司并不多，并且制度方面在很多公司中研发团队无法控制。因此，我们还需要从研发管理可控的范围内寻找解决方案。
实际上，人员效率低的一个核心在于：团队成员缺乏责任感，而责任感的缺失又导致了没有成就感，近一步减低了责任感。
做为管理者，我们要相信每个人都是想进步的，是想有所成就。但是软件工程的流水作业让每个人都成了“螺丝钉”，流程越细化越是如此。软件工程、敏捷框架本质上提升协作效率、团队稳定性，而往往忽略了每个人渴望被重视、渴望独立的需求。
比如Scrum为代表的每日站会(Daily Scrum)机制能有效的减少因需求任务执行偏差的修正周期，让迭代始终走在正确的道路上。但是这一机制也降低了执行人独立思考、计划的能力——“先这样做吧，如果错了明天就会知道，修改还来得及”。
视人为人，而不是视人为工具。这是解决人效问题的第一步。
什么是ShapeUp
ShapeUp是Basecamp提出的一种独特的产品开发方法，它强调团队的自主性和创造性，让团队成员在清晰的时间框架内自由发挥，避免过度的规划和无休止的迭代。
特别说明的是ShapeUp：
- 不是阿米巴/划小经营，ShapeUp关注的是研发交付的效能提升，不是一种经营管理体系，与经营核算无关，并且细胞团队很小且不固定；
- 不是项目外包，ShapeUp的架构线与研发线分工不同但彼此都为一个大团队（部门），共担风险共享收益；
- 不是要搞996、末尾淘汰这些负面制度；
- 不是绩效考核的工具，ShapeUp是重组研发流程以实现人效提升，好的绩效考核手段也可以提升人效，两者应相辅相成。
详见：ShapeUp
ShapeUp的实践
目标与思路
以人效提升为核心，组织流程适配为支撑的研发方法。
理念：让更多的人从参与者转变为主导者，强化责任意识，进而提升工作的成就感。
落地：以细胞团队+需求交付为研发线，以设计团队+产品规划为架构线，重执行轻管控。
团队及协作
基于ShapeUp的团队管理实践，我们将团队划分为两个核心团队：
以需求交付导向的细胞团队
负责需求的分析、设计、研发、测试和上线交付。每次迭代都会重组细胞团队，通常由2-4人组成。团队成员需要从需求分析到开发、测试、交付全过程中都有参与，确保每个成员对交付的结果负责。原则上每次迭代都会重组细胞团队，新的细胞团队中至少有1人参与过类似的任务。
以产品规划导向的设计团队
负责产品的规划、设计和整体架构把控。设计团队的任务是确保产品的设计方案统一、可实现，并且与产品的整体目标保持一致。一般由产品经理、技术负责人、测试人员组成。
设计左移，测试右移的协同作业
设计团队中产品关注需求整体性、描述完整、可验收；技术负责人关注架构的统一、可靠、可扩展等顶层要求；测试关注冒烟用例、边界用例及非功能性用例。细胞团队中每个成员共同参与从需求分析到开发测试交付的完整过程。
怎么理解这些变化？本质上是为了发挥细胞团队每个人的主观能动性。设计左移，要让每个人都思考需求的背景、设计实现的方案，而不是简单的按照需求文档来实现；测试右移，要让每个人都思考需求的边界、功能性需求，编写测试用例，并在团队内完成自测，每个团队对自己交付的内容负责。专业测试团队只负责边界、非功能性用例的编写和自动化测试。
迭代周期
适度的迭代周期
每个项目按迭代分期交付，每个迭代以1.5到2个月为宜。
明确的休整时间
每个迭代明确地划分成交付阶段与休整阶段，交付阶段聚焦任务的设计、研发、测试及上线，休整阶段聚焦于遗留bug的修正、文档的补充、经验交流总结及下一迭代的准备。休整时间以1到2周为宜。
在迭代周期上，与主流的敏捷方法模型相比，ShapeUp的迭代周期更长，这是因为ShapeUp更加注重团队成员的自主性和创造性，希望团队成员能够在有限的时间内完成产品的开发，而不是过度的规划和无休止的迭代。并且通过休整时间的设置，让团队成员有更多的时间进行思考和总结，提升工作的质量和效率。
关键流程
ShapeUp注重流程的简化和高效执行。其关键流程包括需求定义、细胞团队的组建、交付、测试和上线，以及休整阶段的总结和调整。通过这些流程的优化，ShapeUp力图提高团队的协作效率和成员的责任感。关键的流程如下图所示：
设计规约
由于细胞团队的成员都是技术人员，因此在设计规约上，我们需要明确的规范，以确保每个人都能够按照统一的标准进行设计和开发。这方面每家公司都有自己的规范，几个示例如下：
试点反馈
上面描述的是我们的目标，但在试点过程中做了不同程度的降级。几次试点反馈如下：
第一次试点反馈的问题如下：
- 前期准备比较仓促，导致细胞团队设计阶段时间被压缩，设计完成度不高；
- 此版本部分任务需多个细胞团队协同，破坏了细胞团队的内聚与隔离要求，导致这些任务推进遇到比较大障碍；
- 中途临时插入较多需求，导致未能按原定计划执行，细胞团队人员划分被打乱；
- 试点期间过程管理不够精细，导致未能及时纠偏发现的问题。
对应的，做了如下优化：
- 更合理的时间周期：由1到2周的设计，3到4周的开发及测试，1周验收，1周休整组成；
- 分阶段交付：所有任务分成三个阶段分批次交付；
- 更明确的任务边界：避免存在需要跨多个团队的任务，尽量不插入临时任务；
- 更快速的问题处理：试点管控的问题发现及处理会更敏捷高效。
第二次试点比上一次有提升，但仍然存在以下问题：
- 分阶段交付未能严格落地：批次内没能完成的任务都允许顺延，导致最后一批次的任务承压；
- 任务分配按能力而非按岗级：长期以来我们都是按能力分配任务，这导致了“高岗低产”的问题尤为严重。对团队而言一方面严重影响了团队的公平公正，另一方面也影响了我们的交付效率；对个人而言这种“纵容”只会让部分同事失去竞争力，也是对团队个体的不负责。
对应的，又做了如下优化：
- 更严格的分阶段交付验收：合理安排时间，对验收不通过的任务以细胞团队为单位组织加班，每周最多只算一次加班，即周六补验不通过，周日加班不算工时。我们设定的工作量不需要过多的加班，这一措施仅为提升大家平时的工作效率；
- 按岗级分配任务：按细胞团队成员的岗级分配任务，希望部分同事走出“舒适区”，能有更多地承担。如果某个细胞团队觉得自己工作量大，需先反思下是不是给自己设定的岗级过低了。
再之后，我们还做了多轮试点，不断优化流程，提升团队效率。
ShapeUp的反思
几轮试行，我们挖掘了一些自律的、能对自己交付负责的同事，并适时调整了其定位。这是试点下来较为明显的收获。总结下我们认为ShapeUp的两个特色：
产品左移、测试右移
一方面大部分团队的产品经理、测试人员与研发人员的比例极不匹配，这一做法可以平衡前两个角色的资源不足；另一方面也是最主要的目的是为挖掘各角色的潜能：
- 让产品经理从PRD的撰写中解脱出来面向用户面向市场，形式产品大局观。产品经理能写点对点的需求，也能有大规划大战略；
- 让测试人员从只关注测试点走向关注项目整体质量。从功能、性能、兼容、稳定等传统的测试走向流程、效率的把关，承担成QC+QA的工作；
- 让研发人员从单纯的Coding转向了要主导需求分析、设计架构、编码实现、测试交付的全周期实施上。向产品经理学习需求背后的动机是什么，为什么是这样的，进而能更好的设计与编码；向测试人员学习测试的关注面，编写高质量的代码，成为交付质量的第一责任人。
本质上这一措施是把大家从现代化研发流水作业中解放出来，让产品有精力站得高看得远，让测试有机会把控研发全流程，让研发从需求参与者成为需求的主导者。提升大家工作的成就感。
细胞团队任务接力
要求每次迭代细胞团队都要重组，由至少一个熟悉业务及代码的同事+至少一个不熟悉业务及代码的同事组成。动机有三层：
- 第一层，也是最基础的。“铁打的营盘流水的兵”，是为稳定我们需求、代码的基本盘，减少因人员流动导致的问题；
- 第二层，提升代码质量，要的就是有“前人埋坑后人踩坑”的效果，短期内一定会出现效率的下降，但不换人可能永远找不到坑，这才最可怕；退一步说当知道自己的代码要被他人审查时研发人员也会更注重质量；
- 第三层，提升自我能力，通过学习他人好的代码或是修正他人的问题代码提升自己的能力水平。
当然，我们也发现了ShapeUp的一些问题。比如理想情况下，每个迭代会有明确的休整时间，明确地划分成交付阶段与休整阶段，交付阶段聚焦任务的设计、研发、测试及上线，休整阶段聚焦于遗留bug的修正、文档的补充、经验交流总结及下一迭代的准备。但实际情况下，我们不是在赶功能路上，就在修复缺陷路上。由于迭代周期任务多，时间紧，部分需求省略了用例评审、技术评审等，缩短了需求分析和开发时间，没有独立的测试时间段……类似的问题有不少，总结而言，我们认为ShapeUp推广的几个核心难点在于：
- 研发人员的观念转变：ShapeUp强调给研发人员更大的自主权，但这也要求他们有更强的独立思考能力和决策能力。为了帮助研发人员更好地适应这一变化，需要通过定期的培训和分享会，让他们理解并体会自主设计和主导任务的价值；
- 流程节点的规范化：尽管ShapeUp提倡简化流程，但在实际操作中，省略需求、技术、测试用例评审环节会导致一些关键问题的遗漏。为了平衡敏捷与质量控制，需要将评审时间合理嵌入迭代计划中，确保每个重要节点得到有效评审；
- 任务安排节奏的合理性：很多项目迭代都是任务多、时间紧，往往导致缺乏充分的思考和设计时间。在推进上上要尽可能对任务进行优先级排序，并将任务切分成更小的单元，避免“急功近利”。重要的功能需求应留有足够的设计和开发空间，而非单纯依赖快速交付；
- 细胞团队工作边界的划分：在多团队协作的情况下，往往会出现团队边界重合、依赖冲突等问题。为了避免这些问题，需要明确团队边界和协作关系，对于复杂任务，尤其是需要多个团队协作的需求，应在项目初期就明确依赖关系和优先级，确保各团队可以同步推进；
- 测试规划的合理性：在ShapeUp实践中，测试的全面性常常被忽视。为此，应该确保在设计阶段即开始考虑全面的测试覆盖，包括功能、性能、边界条件等方面。即使在快速交付的环境下，也应当考虑构建自动化测试套件，以保证质量。
结语
以上我们实践ShapeUp的阶段性反思。我们相信，通过不断的实践和总结，能够更好地应用ShapeUp的理念和实践，提升团队的效率和成员的成就感，实现研发效能的提升。也欢迎更多的团队一起探索ShapeUp的实践，共同提升团队的效率和成员的成就感。
