什么是业产技分层协作？
「业产技」是业务团队、产品团队、技术团队的缩写，代表研发流程中的三个典型的职能团队。
在经典的研发协作流程定义中，更偏向于技术相关职能角色的分工定义，例如需求管理、迭代排期、缺陷跟踪等协作流程，即使这些流程中有产品团队和业务团队的参与，协作流程的核心仍然是研发交付过程。
在企业的创业初期，业务人员、产品经理、技术人员可能都在一个部门，以项目的形式进行产品的研发，这个阶段的协作效率较高，经典的研发协作流程一般可以满足团队的诉求。随着企业产品线的演进和业务线的不断发展，很多企业都会形成独立的业务部门、产品管理部门、技术研发部门，由不同的主管分别管理。这三个部门的部分人员可能会形成虚拟团队进行项目协作，完成产品研发和业务交付。
业产技分层协作方案就是描述这三个职能团队的协作过程，实现从业务到技术的完整的价值单元交付过程。
业产技分层协作模式与SCRUM有什么关系？
SCRUM是一种被广泛采用的敏捷研发协作模式。当技术团队面对源源不断的产品需求时，SCRUM可以帮助技术团队找到一个科学的工作节奏，通过一个接一个的迭代，持续交付需求，并且可以对研发过程中的问题进行快速的改进，在下一个迭代就能马上得到验证，这样不断的探索整个技术团队的极致工作效率。
而业产技分层协作模式，不仅仅关注研发交付过程，而是对业务、产品、技术三个团队的工作流程分别定义，再通过分层的方式，让三个团队的协作有机的融合在一起。在业产技的“技”这个领域，SCRUM其实是业产技方案中的一环，是技术团队的一种选择。
建议：技术团队我们推荐采用SCRUM敏捷研发的模式进行交付过程管理，云效也提供了成熟的项目模板技术团队快速落地SCRUM；
我的团队是否适合采用业产技协作模式？
SCRUM模式更注重的是研发团队的交付效率，所以经常看到的关键词是：“敏捷”、“高效”、“持续交付”，在SCRUM实施成功的研发团队，我们能看到需求的交付时间较短，需求的吞吐率很高，但是仍然有两个问题比较难回答：
技术团队所做的需求，是否很好的支撑了公司的业务发展？
产品演进的中长期规划是什么，现在所做的需求对于产品的发展是否具有价值？
第一个问题如果回答的不好，就会出现技术团队很忙，效率也很高，但是仍然无法满足公司的业务发展，或者无法让业务团队感到满意。第二个问题如果回答的不好，就会出现产品技术团队每天在不断的接需求、做需求，功能在不断增加和堆叠，但是产品的竞争力却没有提高，时间长了对产品的演进危害很大。
如果您的公司已经发展出独立的业务、产品、技术的独立部门，技术部门一般按照产品线进行划分，而产品经理可能独立出来，归口在一个部门。业务部门通常按照业务领域或者地域进行划分，由不同的业务经理分管。业务部门的原始诉求会首先经过产品部的确认和规划，才转到技术部门进行开发。
这三个部门的分工会让工作流程更加专业，但是也会逐渐形成“部门墙”，并且您的企业已经形成上面的组织架构，并且被上述两个问题所困扰，那么我们建议您选择业产技分层协作模式来改善跨团队的协作模式。
分层协作的“分层”是指的什么？
业产技分层协作模式覆盖三个职能团队，每个职能团队关注的工作重点不同，因此需要为他们设计不同的工作流程，这些工作流程中的一些关键步骤又可以互相衔接在一起。在云效的产品方案中，不同团队的工作流程需要用工作空间和工作项来承载。这里的分层指工作空间的分层和工作项的分层。
在以前没有分层的协作模式下，多个团队一般是在一个工作空间中进行协作，工作事项的类型也是比较单一的类型，一个需求从提出到完成，只有一条记录，很像多人维护的excel表格。而在分层协作模式下，工作事项的类型出现多元化，不同的职能团队有自己所负责的工作事项类型，这些事项通过关联形成“拓扑状”的需求结构关系，并且不同职能团队的事项都在自己的工作空间中进行管理，避免了多个团队在一个空间里的管理混乱。既做到了工作管理的独立性，又实现了协作关系的连通。
医院就诊场景与分层协作非常类似，病人到医院首先是“挂号”，医生会根据这个号填写病历，相当于病人的原始诉求（主诉），然后检查单、检验单、处方这些“事项”，并不会直接在病历上操作，而是另外创建，并且和病历建立关联。每个事项的负责人只需关注自己的事项，而病人可以通过病历（原始诉求）查看所有事项的进展。
分层协作可以解决哪些问题？
对于业务团队：
·不确定核心业务目标是否得到产品研发团队的有力支持；
·难以掌握研发进度和风险；
·不清楚产品下一步的规划，是否能满足业务的发展战略；
以前仅scrum的交付方式，研发交付空间里面的需求颗粒度非常细，需求数量非常多，业务团队在交付空间很难获得更多有价值的信息，业务团队的工作和技术团队的工作基本是脱节的，需要进行大量的线下沟通，才会掌握最新信息，并且经常会出现信息滞后和延误。
对于产品团队：
·产品缺乏规划，只是传递业务团队的需求，产品竞争力难以提升；
·产品规划停留在PPT，难以连接业务团队的目标规划和研发团队的交付过程；
如果只是传递业务团队的诉求到技术团队，那么产品团队会很容易迷失，会忽略对产品最有价值的一些特性建设，其实产品团队经常需要做取舍，既要满足业务的发展，又要为产品规划一些中长期的产品专项主题，缺乏规划的产品，可能会在一段时间后，出现产品竞争力下降，难以支撑业务发展的问题。
以前产品团队都是把这些产品规划/产品主题落在文档/PPT中，这解决了需求按照产品主题归类的问题，但是这些产品长期规划和业务目标的关联关系以及需求的进度（在交付空间中）到底如何，又是看不到的。
对于技术团队：
·搞不清需求的源头是什么，也就很难确定需求的价值；
·担心技术资源没有投入最重要的核心业务，没有为业务创造价值
在“需求价值”的话题上，技术团队和业务团队其实有着同样的共识。业务团队希望最有业务价值的需求能够得到技术团队的大力支持，同样，技术团队也希望自己的优势兵力投入到公司的核心业务里面。单纯使用SCRUM研发交付模式，开发的工作内容跟业务团队、产品团队的工作是分离的，技术团队希望能够参与到业务规划和产品规划的工作中来。
接下来让我们开始体验一下业产技分层协作在云效产品中是如何实现的。
根据组织架构创建工作空间并设置工作项类型
分层协作最先需要确定的是工作空间和工作项的分层设置，这里要参考各个职能团队的组织架构关系，下表给出了云效推荐的三层协作的模式，并且在云效的项目模板中也预制了业务空间、产品规划空间、SCRUM研发交付空间的三类模板，供用户选择。
建议：业产技协作模式默认分为三层，用户也可以根据团队的实际情况进行调整，比如产品主导的企业，可以分为产技两层，业务主导的企业可以分为业技两层；
工作空间 | 工作事项 | 参与团队及职责 | 关键词 |
业务空间 | 客户诉求 用户反馈 | 业务团队：
产品团队：
| 原始诉求收集 建立需求依赖关系 跟踪交付进度 验收 |
产品空间 | 产品主题 产品类需求 | 产品团队：
| 产品主题 需求价值评估 产品规划路线图 |
研发交付空间 | 产品类需求 技术类需求 研发任务 缺陷 测试用例 | 产品团队：
技术研发团队：
| 需求池 迭代规划交付 应用变更 测试计划 缺陷跟踪 |
预制模板里已经设置好了工作项的类型和工作流程，用户可以直接使用云效的预制模板，也可以在云效·Projex的企业设置里，根据实际的要求重新设置工作空间模板和工作项模板。
云效的工作项分为以下几个大类，每个大类下可以根据用户的要求创建工作项小类：
工作项大类 | 工作项小类（可自定义） | 填写内容 | 创建人/负责人 |
原始诉求 | 客户诉求 用户反馈 |
| 由业务团队创建，产品团队负责 |
主题 | 产品主题 |
| 由产品团队创建，也是产品团队负责 |
需求 | 产品类需求 技术类需求 |
| 产品团队创建，技术团队负责 |
任务 | 设计任务 开发任务 测试任务 |
| 根据实际情况确定 |
缺陷 | 缺陷 故障 |
| 测试团队创建，开发团队负责 |
通过需求结构化掌握原始诉求的依赖关系和交付进度
业务空间创建好以后，业务团队可以直接录入来自客户/用户的原始诉求，指派给产品团队，共同决策是否接受这个诉求，并确定实现的优先级。
建议：通过产品评审会的方式，业务团队/产品团队一起对原始诉求进行评审和澄清，再做决定；
建议：原始诉求的字段里可以增加「业务域」「产品线」这些字段，便于以后的分类跟踪和汇总统计；
一旦决定接受原始诉求，产品经理需要尽快创建/关联产品类需求，这样把原始诉求和产品需求之间建立“依赖”关系。看到原始诉求的状态更新为“已接受”，并且诉求有依赖的产品需求，业务团队便可以知道自己的诉求有了着落，接下来只需要跟进依赖的产品需求的进度即可。另一方面，产品团队也可以在产品需求中看到原始诉求的来源，更容易理解需求的价值。有时很多客户会提出相同的诉求，这时就可以看到一个产品需求有多个原始诉求的依赖，这些信息会帮助产品团队决定产品需求的优先级。
业务团队可以直接在原始诉求的列表查看交付进度，也可以在诉求的详情页查看更具体的进度信息。在列表页云效会展示原始诉求所依赖的产品需求的状态进度，在详情页可以查看需求结构的完整拓扑图，包括了产品需求下的技术任务都会在一张图完全展示出来，如果有哪个节点的进度出现逾期，或者状态长时间处于不合理状态。
（需求全景图在开发进行中）
建议：如果产品需求如果改动范围较小，方案比较确定，可以将产品需求直接转移到“研发交付空间”，如果产品需求规模和方案不太确定，不合适直接转交给开发团队，建议先转到产品规划空间，经过规划和排期再转交给开发团队。
工作项详情页提供了详细的分阶段进度展示，业务团队可以清楚的掌握工作项当前的所处阶段和之前经历阶段的停留时间，帮助用户从整体上了解原始诉求的进度，对完成的时间也有一个大概的预测。
规划产品主题来选择最有价值的产品需求
产品团队是衔接业务团队和技术团队的一个重要职能团队，产品规划空间就是产品团队进行产品发展路线图规划的工作空间。当产品需求数量急剧膨胀，需求的价值难以评估，研发团队整日忙于交付需求，却对产品中长期发展规划不明确的时候，我们建议启用产品规划空间来规划产品最有价值的需求，并进行合理的规划排期。
产品规划空间的核心工作项是产品主题和产品需求，产品需求描述一个具体的功能点，比较细碎，单个功能点之间是比较难进行价值对比的；而产品主题是描述一个完整的用户使用场景，能够较好的评估这个场景的用户价值，在多个主题并行的时候，也比较容易横向进行对比。
建议：当产品需求急剧膨胀的时候，梳理用户核心使用场景，并创建对应的产品主题，每个产品主题的个数在10～20个左右为宜。
产品主题有两个重要属性：影响和成本。影响是对于产品目标/业务目标的价值，成本是粗略估算的开发成本，这两个属性都采用了“十分制”，然后通过影响和成本的比值，可以横向对比多个主题之间的ROI。
建议：这几个属性值都可以用于排序，但仅仅是给产品团队的参考，云效提供了手工排序的功能，用户可以根据自己的要求进行排序；
产品主题下可以拆分出产品需求，也可以将已经存在的产品需求关联到产品主题。通过产品主题的梳理和价值评估，可以从繁多的产品需求中找到一个产品演进的主线，在满足业务团队的原始诉求的基础上，选择更高价值的产品需求进行交付，不断提升产品竞争力；
建议：产品主题的规划和业务团队的原始诉求之间要保持一个有机的联系，原始诉求所依赖的产品需求，可能只有一部分会关联到产品主题，没有关联上的，不代表不重要，如果完全以产品主题的优先级规划产品需求，可能造成客户的原始诉求的交付效率下降，因此需要寻找合理的平衡点；
通过研发任务/应用变更完成需求的交付
对于技术团队的工作模式，本文不做过多的介绍，您可以参考云效SCRUM敏捷研发的最佳实践说明。
建议：将产品需求拆分为多个技术任务，分配给不同的技术人员，共同完成产品需求的开发交付
由于技术团队的分工不断细化，很多技术团队都会出现设计师、前端开发、后端开发、测试等多个职能小组，共同协作完成一个需求，这时如果在一个需求“工作项”上进行操作，会出现很多问题，比如前端开发完成，后端还在开发中，这时需求的状态难以表达这种区别。如果将需求拆分为两个技术任务，分给前端和后端，就比较容易区分。
小结：
业产技分层协作方案希望解决的是让业务、产品、技术团队清晰地看到产品交付的价值，用价值将团队聚合成一个整体。
业务团队建立业务空间，管理原始业务诉求。这些诉求可以来自业务目标的规划拆解，可以来自客户的反馈，再通过原始诉求与产品主题和产品需求的连接，清楚的掌握产品团队的规划和技术团队的交付进度，还可以进行阶段性的总结分析，与产品团队、技术团队一起review产品技术是否很好的支持了核心的业务目标。
产品团队在产品规划空间，对产品主题和产品需求进行价值评估和排期规划，成为了衔接业务和技术的关键枢纽，共同决策出最优的产品发展路线。
技术团队一方面在研发交付空间不断优化提升研发效率和质量，另一方面通过与业务空间和产品规划空间的连接，清楚的掌握需求的源头和价值，并且积极参与到需求规划决策过程中来，将研发资源投入最重要的业务目标或者产品目标。
- 本页导读 （0）