研发团队如何从容应对突发性的开发需求？

「这个需求是重要客户新提的，非常着急，赶快解决。」 「有用户新发现了一个 Bug，比较严重，优先修复这个。」 「老板说这个功能这周必须要上，你先把目前手头的事情放一放。」

诸如以上的情况我们在开发工作中时常发生，研发团队里各个都是「救火队员」，然而这些救火队员尽心尽力的完成了任务，也未必能取得客户满意，未必能实现客户和市场的价值。那么出现此类问题的原因是什么呢？

问题分析

1.支撑工作与开发工作混合，没有明显的优先级 2.团队正常进行开发工作的时候，客户经常会提出一些干扰团队的冲发性工作。

那么在管理研发团队过程中，如何应对突发性需求，以提高团队工作效率，保证团队成员完成冲刺目标呢？

解决措施

在 VUCA 时代下，敏捷开发方式是时代的选择，被越来越多的研发团队开始实践和采用。以下解决方案的内容均以敏捷方式叙述，包括但不限于 Scrum 框架。

对于混合模式

支撑工作与开发工作混合，出现突发性工作是常态，这里简称「混合模式」，可以从人员分工角度思考，建议团队人员最好有工作侧重点的划分。一部分人员精力用于开发，另一部分人员侧重于应对突发工作。应对突发工作的人员时刻准备着问题风险的对应（比如开发工作尽量领取简单、松耦合的）。应对开发工作的人员专心完成开发内容。在这里也建议可以使用一些工具作为辅助，在敏捷项目管理产品中，多数都有管理工作项的功能。

对于开发为主模式

开发工作为主，伴随着出现突发性应急工作，也就是正常的需求变更。这里简称“开发为主模式”，开发为主模式下，伴随着突发性应急工作的类型二，是我们很多研发团队中的常态，也是本解决方案着重描述术的情况。从根本解决工作项优先级的问题，系统地学习怎么样应对需求变更才是根本。

明确需求责任人，做到需求来源唯一

在研发团队中一般产品经理或者需求分析师（Business Analyst）充当这个角色。我们来明确下需求责任人到底负责什么。需求责任人至少同时要面对两个方向。

一方面，需求责任人必须很好地理解项目中的利益干系人、客户和用户的需要（包括前面提到的突发工作项）及其优先级，以便能充当他们的代言人。从这个角度理解，一般是产品经理充当需求责任人。

另一方面，需求责任人必须与开发团队交流要构建的特性及其构建顺序。需求责任人还必须保证特性的接收标准已有明确说明，让团队可以确定在什么情况下需求责任人可以认为特性完成了。在这个角度理解，一般是业务分析人员和测试人员的角色。

同时，需求责任人还要在版本、迭代和 Backlog 层面都能够持续做出良好的经济决策，管理经济效益。为了统一叫法、便于理解，后面需求责任人都由产品经理充当（类似 Scrum 框架中的产品负责人）。

综上所述，产品经理的主要职责如下图所示：

梳理产品待办列表

高优先级的工作项放到迭代待办列表（更多关于迭代待办列表的内容请参考下面的“了解更多”）中先做。

产品待办列表是一个按优先顺序排列的、预期产品功能的列表。工作项是 Backlog 中的待办事项。对用户和客户来说，大多数的工作项都是有实际价值的特性和功能，当然也包括一些需要缺陷修复、技术改进、知识获取等工作以及产品负责人认为有价值的任何工作（当然有价值的突发性工作也属于工作项）。如使用 Gitee 中的 「里程碑」 梳理产品待办列表。

梳理 PBI

梳理是指三大重要活动：

1.确立并细化工作项； 2.对工作项进行估算； 3.为工作项排列优先顺序。

关于梳理活动想必大家有所了解，但好像具体又无从下手。如何能有效地将条目梳理的活动管理起来呢，这时候工具的作用就体现出来了。（以 Gitee 企业版为例）

重新定计划

确保团队容量适合，合理更新迭代目标。我们的目标是快速地重新制定计划并根据开发过程中不断出现的、具有重要经济价值的信息进行调整。因此，通过梳理以后原计划准备做的工作项可能被移入到下一个迭代中实现，这里体现的是「等价交换原则」，这样虽然在迭代中增加了新的工作任务，但是同时我们也移除了迭代待办列表中一个等工作量的任务，所以保证了工作量不变，进而保证迭代的速率。

迭代回顾，识别改善点

迭代回顾是一个会议，目标是持续改进流程，根据团队的需要改进和制定流程，以提高士气，提高效率，提高工作产出速率。几个迭代下来，需要对这类突发工作进行度量分析，识别改善点，持续改善。

这里利用 Gitee 企业版给出一个很好的小实践，可以提供客观数据帮助回顾。新纳入迭代待办列表的突发性工作项可以在 Gitee 的「功能设置-任务类型与状态管理」下进行任务类型新建管理。如下新建「突发性工作」任务类型如图所示：

有了「突发性工作」任务类型后，我们在接收到突发性的类似培训客户的需求而建任务时，就可以相应的选择「突发性工作」。如下图所示：  最后，在迭代回顾时需要对这类的突发性工作进行分析。比如走过几个迭代后发现平均每个迭代大概都会有4个左右类似的任务（工作量在16小时左右），那么在新的迭代时就要预留相应的16小时，以便更好的应对这类突发性的工作。如下图所示，可以使用类型看板进行快捷的查看突发性工作的数量。 

同步进行人才培养

同步需要进行的是人才的培养，向跨职能型团队努力。不仅仅是应对处理突发性工作，而是让团队更高效。

每个任务应该由谁来做，或者说突发性工作应该由谁来做？答案很明显，应该是能够最快且正确完成这个工作的人来做。如果这个人不在了怎么办？或者他正在做其他工作，抽不出时间，但这个任务需要马上完成。团队成员都有责任考虑各种不确定因素，做出最好的选择。如果团队成员都是 T 型技能的时候，每个任务都有好几个人可以做，那么团队就能够在迭代执行期间几个人全力完成制约工作项流程的任务，更灵活地平衡资源，使团队更高效。

总结

本文是基于敏捷开发方式给大家详细阐述避免突发性需求导致迭代周期过长的解决方案，选择一款趁手的工具能帮助更好的管理实践，达到事半功倍的效果。推荐 Gitee 企业版 ，一款基于敏捷思维设计的研发管理软件，想开始小范围测试的企业可以现在也可以免费注册使用。

Gitee 企业版 不仅能为需求管理、迭代规划、进度跟踪等经典 Scrum 环节提供工具支撑，而且能很好的帮助企业有序管理研发全流程而且还是国内首屈一指的代码托管平台，云端/本地均可灵活部署，已为 18 万家企业提供服务。

点击链接：Gitee.com，或拨打专属客服电话：400-606-0201，免费试用 Gitee 私有化部署账号，助力企业有序规划和管理软件研发，高效实现一站式DevOps。