规模化敏捷转型中，哪些问题会被经常问到？
1月16日，Agilean 咨询团队在 Adapt 规模化敏捷框架第七期直播中，邀请了多位群友观众来到直播间进行连麦互动，通过大量实例问题的分析解答，对 Adapt 框架第一个系列直播活动进行了收尾总结。限于直播时长，我们无法对这些问题一一解答，特撰此 Q&A 并与大家分享。
直播回放
文末有本次直播关于敏捷导入、业务协同、项目&产品管理、大规模敏捷交付等话题的回放，可点击原文链接查看。
1月31日，我们将组织一场 Adapt 规模化敏捷框架的线上培训课程，感兴趣的同学，可识别下图二维码报名。
识别二维码报名周日 Adapt 培训课程
1
敏捷转型四问
Q1：在向业务人员宣导敏捷实践的时候，应该宣导哪些方面，才能更好的让业务人员参与和支持敏捷实践？
A1：促进业务侧更多参与敏捷实践确实是很多组织面临的难题。在宣导时，建议结合业务自身的痛点以及业务与研发协作的痛点出发，有针对性的进行宣导。（By 雷晶晶）
首先是协作上的痛点：
交付时效痛点：可以通过小批量交付，缩短交付时效。
交付内容「货不对板」痛点：该问题来源往往是交付时效太长，导致需求澄清重要细节的损耗，或因为交付过程太长，期间出现需求变更。采用敏捷实践后，基于频繁的沟通与持续的交付，让业务有机会不断校准需求细节，促进交付内容更符合业务目标
交付质量痛点：采用敏捷方式后，由于测试左移、开发 Showcase 等实践，每次交付的内容能得到更充分的测试与验证，质量将有改善。同时由于每次交付的「容量」降低，问题定位与修复将更快
过程黑盒痛点：持续沟通、双层看板都将向业务透明进展与实际情况。
其次是业务痛点：
创新痛点：业务的产品创设与创新，本身有业务敏捷的实践。落地时都需要研发具备持续交付与快速实验能力，这都是研发敏捷实践可以辅助的内容
降本提效：研发交付的内容不是业务和市场需要的，就是最大的成本浪费，敏捷对于交付内容的准确性的提升有助于帮助业务节省成本；研发和业务更好协作，可以让研发从系统角度给业务更好的实现建议。
跨部门协作：研发敏捷划分部落以后，能够对齐业务条线，一定程度上降低跨部门协作难度
案例分析
金融机构前端业务的常见痛点是上线慢，如果涉及与合作方对接，经常需要三个月甚至半年时间。宣导时可以着重表述，通过需求的梳理、优先级的排序，高质量快速交付合作项目的核心内容，帮助业务快速抓住市场热点与趋势，辅助业务快速落地。
但是，在宣导过程中，应该注意避免以下几个坑：
单纯将敏捷描述为研发能够快速交付；
将敏捷描述为研发的实践，没有事先与业务对齐参与敏捷的「投入」与「产出」。
如何理解敏捷的投入与产出
常见的投入包括：频繁的需求澄清、定期与研发集中办公（尤其针对业务研发不在一个职场的情况）、小批量验收测试等。更进一步的实践中，需要将业务目标与产品规划、需求管理进行关联和挂钩。
常见的产出包括：支持快速实验、交付内容更符合业务诉求，交付质量提升等
Q2：项目制中，项目经理的管理能力较弱，同时疲于应对向上汇报，虽然有团队内敏捷教练，但是本身不关注也不了解敏捷，对敏捷转型中形成阻力，如何优化？
A2：不过分纠结「某一小部分」的问题，将大部分精力投入规模化。（By 周麟）
在面向组织做转型的过程中，天然的存在人员能力的差异与不同态度问题。首先，本着转型的长期目标与短期要解决的问题为主，不要过于纠结为某一小部分人员的执行程度。
从个人经验，分享几个导入的小 Tips:
找到着力点：多观察，总能抓到几个对转型有支持态度的人，以及有一定影响力的人，这些人的引导非常重要，要多花些心思；
树立标杆：组织的转型道路长远，困难重重，先挑选与辅导出一两个标杆团队，说明我们真的是可以做得到的；
扩大影响力：有了标杆团队后可以到领导面前拉拉票，借取更大的力量，逐渐规模化；
个别边缘化：在一定规模化后，仍然会有一些反对的声音。要注意，不管理无理由的反对，还是个别能力问题执行不到位，对于我们导入来说，大部分精力应投入在规模化。个别的人可以先放一放，因为很多人不一定想得第一，但非常害怕到掉队到最后，形成边缘化。当然，若反对的声音是客观存在的问题，我们应该认真沟通与引导，持续优化改进。
Q3：传统到敏捷的转型阶段问题
A3：这个问题很大，这里推荐敏捷流畅度模型，在 Adapt 中，也有转型路径可参考。（By 程萃）
Q4：一个现有的研发小队，让他们做敏捷转型，在宣导敏捷思维时，应该着重宣导哪些方面，才能让他们感觉到敏捷转型会给他们带来收益？
A4：先问题驱动，让研发小队成员知道敏捷是什么，能给他们带来什么帮助，目前管理方式的痛点又是什么。（By 徐哲&李黄容）
从具体问题出发，去了解研发小队真正的痛点是什么。比如敏捷转型后，觉得工作节奏更快。或者交付质量没有带来质变，业务满意度还是不高。我们可通过先透明团队工作来帮助团队发现问题和痛点。
敏捷更强调的是小批量交付业务价值，尽快获取市场用户的反馈，及时调整、持续改进，形成自我优化的闭环。
敏捷转型是一个长期积累的过程，是一种工作模式的优化。对研发小队成员本身来说，持续交付高价值的需求，也是提升成就感、获得感和实现自我价值的过程。
同样，我们敏捷导入可从「多快好赞」的角度出发，量化交付成果，比如需求产能的提升，需求交付时效的提升，缺陷率的降低，业务满意度的提升。通过提升，来逐步提升研发小队成员的士气和业务方的参与程度及信心，来促进更大范围、更大深度的改进。
2
外部资源的协作与管理
Q1：合作方人员分布资源匹配，是匹配到每个项目里面的人数么？如果不是的话，告知下是匹配到哪个维度里面？
A1：资源管理不应割裂，几个维度推荐（By 李黄容&徐哲）
基于组织自身运作需求，有些组织会整合外部专业化资源，此时即会涉及内部自有人力和外部合作人力。
人员管理是整体的，从组织层级来看，内外部人力资源的整合分布信息对管理层来说一样重要。
观察：内部人力情况的黑盒
我们观察到，很多组织不仅外部合作人力情况是黑盒的，甚至内部自有人力情况也是不透明的，或对领导管理层非实时可见。基于本问题来说，不同组织对人力资源分布的统计信息，期望看到的维度可能会有所差异，建议先从最关注和最易获得的维度入手，再持续迭代。
此时，我们可以在人员上有一些岗位标签，比如角色、小队、部落、职能线、公司、专业领域、产品、项目等等。科技类工作需要更细化、灵活可变的岗位标签体系，以支持实时人力盘点和人才画像。
同时，结合 Adapt 三层需求分解体系（下图），个人任务落到单个人，可关联到更细的颗粒度，通过工时向上汇集到个人任务关联的需求/系统任务，展现不同需求和任务的人力投入。
有了如上基础原始信息之后，可以单维度或多维度的进行统计，获取全组织关注维度的人力分布地图，建立人员效能评估的数字化管理体系，帮助管理层更好地进行资源分配和整合管理，并有针对性地提升各团队的交付能力。
补充一个例子，根据人员的公司归属信息，可单维度统计出各公司人员分布；根据人员的公司归属和项目信息，可多维度统计出各公司在各项目的人员分布，或各项目中各公司的人员分布：
Q2：对于合作方的资源和项目串联进行管理，衡量合作方人员的交付速率，可以建议些方法么？
A2：先聚焦关注业务/用户认同并有感知的维度，多个交付指标推荐（By 李黄容&徐哲）
本问题基于项目团队且含合作方人员，分两种情况：
研发团队由自有人员和合作方人员共同组成
完全是合作方人员
无论是哪种情况，我们建议应首先从团队整体出发，聚焦关注业务/用户认同并有感知的度量维度，当团队超过一定规模，团队自身亦需分层级精细化管理和度量，持续过程改进。
就团队交付速率的核心指标，可计算团队单位周期的需求交付量或单位周期人均的需求交付量，如月度人均需求吞吐量，经过一段时间观察趋势，建立基线数据后，可设定阶段性改进的目标值。
这里的目标值，更多为相对值，而非绝对值，更多为纵向比较，而非横向比较，即更多关注该团队本身或项目整体的交付速率在单位周期内的改进情况和变化趋势。具体可参考上图 Adapt 「多快好赞」度量体系。
Q3：在敏捷大规模交付中，多家厂商如何管理？
A3：理解该问题最主要的点，是传统向敏捷转型时，对合作供应商管理的变化点。（By 李黄容&徐哲）
多家厂商管理，传统或敏捷交付中都会有涉及，以下从采购和外部合作人员管理两点进行说明：
1. 采购转向人力外包，时间投入和工作项关联
传统采购更多的是以项目外包的形式，与供应商进行谈判合作，固定范围、成本、时间。
在不确定性的环境背景下，项目外包的采购方式难以满足目标的实现，因此采取敏捷的方式来应对，建议转向人力外包的形式，通过对外包人员的工时管理，将人员时间投入与工作项进行关联，促进整体资源更合理的分配，最终实现目标驱动，甲乙双方合作共赢，采购按目标达成进行滚动验收的工料合同。
2. 尽量避免差异对待
我们观察到，团队中外部合作人员的管理方式，一方面，在很多组织依然存在说「我是内部人员，你是外包」的现象，十分不利于团队合作。
正如敏捷宣言所说「客户合作高于合同谈判」，因此团队管理者应避免造成诸如此类的差异对待，无论来自哪家公司，都应强调我们是一个团队，让团队成员有归属感，共同朝着统一的目标，促进甲乙方共创的敏捷交付。
另一方面，通常外部合作人员会涉及结算，此时的确需一定的约束，如遵守内部的行政管理要求，对供应商服务人员有面试选择权利，人员的考勤和工时管理，团队管理者对内外部团队成员的绩效考核等。
3
跨系统跨小队协同
Q1：受到后台系统进度影响，速度快不起来怎么办 ？
A1：分两种情况来分析找答案（By 郭阳）
这个问题分几种情况：
第一种，经常性的被后台进度慢影响。看看这几个方面是不是出现了问题：
事先排期的时候没有做足准备，没有提前把需要后台做的部分讲清楚，约定好联调和上线时间。注意，此处需要后台去明确优先级，确定这个任务被放到了他们的高优先级去做。
事中没有定期（根据重要程度和情况调整频率）与后台做进度跟踪。
第二种，不是经常性的。任务已经在研发中，计划做的没问题，沟通也没问题，那应该是有未预测到的技术难题。此时应该及时升级给大领导协调资源攻克难题，把失去的时间抢回来。
Q2：规模级，如信贷、核心、国结、票据、支付等，几十个同时交付中，如何评估项目交付时间，制定版本计划，应对需求变更，做到按预定时间上线。
A2：三种风险管理方式推荐（By 熊小龙）
约定交付时间：应该先有时间窗，明确交付日期。这类似 Adapt 中的版本日历（下图）。
制定最小可交付范围：根据项目的交付目标，各团队评估能完成多少功能，寻找到最小可交付的平衡点。
依赖管理：迭代中，有依赖关系的尽早约定好接口，明确联调时间点，保障交付可控。
同步机制：项目周例会机制，同步进展和风险，需求变更等。
通过以上方式，一般能尽早暴露风险，使风险得到有效管理。
Q3：跨部落对齐，或者同一部落内各小队间的具体优秀实践是哪些？
A3：该问题的实践分享（By 郭阳）
制定定期的沟通对齐会议计划。会前准备会上需要讨论的问题，发给所有参会人员并注明需要谁重点关注。会上产生行动项，记录下来并持续跟踪。
跨部落对齐部分，可以参考即将发布的Adapt3.0跨部落协作部分
小队间的沟通要运用好公司内部的即时信息软件、邮件，做频繁的对齐。必要的时候升级给部落级角色进行协调。
心法：不要怕麻烦，不要觉得这个事会有别人处理。
Q4：各个系统的关联性、耦合度太高，可以是说是错综复杂，该如何做到版本节奏的统一？
A4：先统一小队迭代周期，版本与迭代解耦（By 周麟）
在 Adapt 中，版本与迭代是解耦的。版本节奏是各系统的投产节奏，迭代是各小队各系统的研发与测试计划。
版本节奏统一，可以根据实际情况来看遇到的问题来对症下药，是担心执行不到位，还是有某些系统的客观因素，等等。
题干上提到系统的关联性与耦合度高，更多是要解决版本节奏不一致的情况下，多系统协同问题。建议先统一小队的迭代周期（例如两周），这样哪怕各小队的迭代起始时间不同，也不会存在过长的时间差。根据需求的期望上线时间，定期的提前与关联小队做迭代计划便可。
4
关于人的问题
Q1：团队测试人员每个版本都有不同怎么办？
A1：三个固定（By 熊小龙）
优先固定：首先思考为什么会不同，如何增加固定。无论开发还是测试，是需要领域知识的，人员高度复用并不能提高效率，仅是看上去提高了利用率。
相对固定：如果推动力不足，可以考虑核心人员固定，核心人员保障知识传承、案例设计，变动人员主要做测试执行相关工作。
领域固定：在某个小领域内的人员复用，让测试人员渐渐掌握2-3个小队的业务知识。
Q2：如何培养团队骨干？
A2：内驱力辅助，激发和引导工作分配。（By 周麟）
团队的骨干培养可以通过内驱力来辅助，管理 3.0 里将内驱力分为 10 种类型（好奇、荣誉、认可、能力、权力、自由、关系、有序、目的、地位）。
通过人员的内驱力不断的去激发和引导工作的分配。同时，根据各人员的角色与岗位不同，应制定不同的培养路线。有对人员本身的培训赋能输入，也给予实践的机会和空间，不断的引导与反馈，激发其学习成长动力。
Q3：团队规模太大怎么办？
A3：化繁为简，降维管理。（By 熊小龙）
可以尝试把大团队用虚拟部落制的方式，细化到小队。部落与业务对齐，小队与产品经理对齐，本质上管理复杂度就限定在一个细分的业务领域了。使组织从千人级的管理，降维到一百人左右的管理维度。
5
关于需求拆分
Q1：市场变化快，业务压力大，要求 IT 要更快响应，例如两三天上线，但是需求一句话，交付质量差，可是业务和 IT 不敢停，如何化解？
A1：关键词：价值优选、优先级置换、产品经理辅导（By 徐哲&李黄容）
首先，需要将一些当前优先级较低的，正在研发阶段前期中的需求挑选出来，置换为高优先级的业务需求，尽快启动需求澄清、排期、研发、验收、上线。
其次，辅导产品经理的能力提升，将业务负责人的一句话需求明确验收条件和完成标准，同时分析关联系统的影响，避免关联方未及时配合修改，导致需求最终无法上线。从源头开始，也就是需求本身开始，加强需求质量。
再次，业务和产品加强价值优选环节，保证输出给研发团队的迭代需求列表，是当前时点业务最高价值的；同时，团队规划时建议纳入迭代系统任务的总估算不超过团队容量的 80% （具体数值也可根据团队实际情况而定），保留 20% 作为 buffer 或排优先级较低的，以及时响应变更。
Q2：需求颗粒度和系统任务的拆分，如何在实践过程中做好衡量和规范？
A2：尽量拆小，颗粒度相对统一即可。（By 徐哲&李黄容）
需求颗粒度一般拆分到产品经理和小队长可以沟通对齐，让小队长理解的程度，满足INVEST原则（独立的、可沟通的、有价值的、可估算的、足够小的、可测试的）。
需求颗粒度没有绝对，尽量拆小，保持颗粒度的相对统一即可。然后再根据需求分析的结果，去完成系统任务拆分，系统任务的工作量要求小于10人天，否则就很难在一个迭代内完成系统任务的交付。
6
度量与绩效
Q1：实行敏捷之后，怎么样配套的去做绩效管理？
A1：不建议直接将度量体系搭建刚开始，即用作绩效考核。（By 李黄容）
指标的选定也需要试点和正式推广，度量的主要目的是帮助团队用于过程改进。稳定后如需利用研发效能数据可参考上图的建议。
7
关于知微的问题
Q1：知微是否可实现项目WBS管理，看项目进度燃尽？
A1：藉由灵活的卡片类型和关联配置能力，知微可实现项目的拆分（项目群-项目，项目-任务等）管理和进度燃尽监视。（By 知微产品团队）
一方面，列表甘特图实现对项目/任务进展与风险的监控，绿色线代表进度正常，红色线代表进度异常/有延期风险；
另一方面，通过统计视图，可监视一/多个项目进度燃尽情况。下图为按照项目分解后的任务事项，监视两个项目的燃尽图，时间刻度可以指定按天/周/月等。
类似进度燃尽功能，不止是项目管理，同样适用于版本、迭代、缺陷修复等场景。
8
Adapt 的应用
Q1：在 Adapt 框架运行中，如何自组织管理？
A1：先进行「5+3」角色与迭代节奏&版本设定。（By 都云霞）
在进行了部落长、小队长、小队人员开发、测试等角色配置之后，对迭代节奏、版本也有了设定，则可以让团队基于迭代节奏、版本进行自组织管理，去进行 Adapt 里面定义的活动。
或者说，如何开展、什么角色都在 Adapt 里面进行详细说明后，团队可以在小队长主持下召开站会、也可以根据团队情况安排版本排期、需求澄清等，这些都是自组织管理的。
Q2：Adapt 框架目前主要针对的企业开通服务及其应用，有没有考虑针对某企业下小 team，比如一个项目组使用这种模式来管理，其他 team 仍遵循原有的管理模式。
A2：Adapt是规模化敏捷框架，其中也包含部落内单小队的运作规范。（By 郭阳）
如果目前企业内无法支持部落化，那么单个小 team 是可以参照 Adapt 中小队运行方式及产品经理和小队长的职责来进行改进的。
补充说明1：在 Agilean 公众号内回复「直播」，可查看Adapt 本系列直播全部回放，以及直播 PPT 下载；
补充说明2：点击「阅读原文」，查看第七期直播回放。