小米科技|深度 | 从DevOps到BizDevOps, 研发效能提升的系统方法( 三 )



与业务需求一样 , 产品需求也需要被收集、管理、规划和交付 , 研发管理工具 , 同样要为产品人员提供专属的产品交付空间 , 并定义产品交付的工作流 。 技术开发者也需要对他们友好的工作台 。 在这里 , 他们接受、管理、计划和完成技术工作 。
更重要的是 , 我们需要让这三个层次三者变成有机的整体 , 让大家真正的协同起来 , 顺畅的交付业务需求 。 这三个层次的工作流是相互关联 , 业务需求规划后被拆分为产品需求 , 产品需求会被进一步拆分为任务 , 这些是自上而下的 。
再看自下而上的 , 下层的工作完成后 , 它的状态要能够被自动卷积上去 , 比如产品需求下所有的任务完成后 , 对应的产品需求进入待测试状态 。 业务需求所有产品需求完成后 , 业务需求的状态也需要自动变更 。
这三个层次的联动和透明 , 让问题和阻碍更容易被识别 , 比如业务需求交付延期或者出现问题时 , 能清晰的看到是哪一个产品造成的 , 应该在哪里采取动作 。
我们把这称为业务驱动的协作模式 。 组织中不同的职能和团队 , 必须相互协同完成业务交付 , 达成用户或者业务的目标 , 业务驱动的协作模式 , 让这一过程更加透明和高效 。
产品导向的交付模式
前面讲的是协作模式 , 企业的业务需求最终还是要到落实到产品交付团队中交付的 。 以前我们更多把IT交付团队看成成本中心 , 先确定需求范围 , 再确定时间 , 然后分配资源、成立项目、完成交付这也被称为项目导向的交付模式 。

项目导向的交付本质是把人作为资源分配到事情上 。 其背后的假设是未来是确定的 , 在确定的时间内交付确定的内容 。 它强调计划和执行 , 追求交付的确定性 。
确定性今天已经越来越不现实 , 组织必须学会与变化共舞 。 另外 , 项目导向的交付导致短期思维 , 缺乏工程、技术长期改进意识 。 同时 , 因为团队的临时性 , 也无法持续团队的交付效能 。
数字化时代 , 我们需要从项目导向的交付模式向产品导向的交付模式迁移 。 产品导向的交付模式本质是把事情交给跨功能的特性团队 , 由相对稳定的特性团队持续的接受并完成需求的交付 。
特性团队对产品的迭代负责 , 他们拥抱业务的不确定性 , 并为此不断演进产品 。 特性团队要维护产品 , 必须建立长期思维 , 注重代码资产和工程资产 , 并持续改进团队交付能力和交付流程 , 提升交付效能 。
但这还不够 , 因为如果各个产品各自为政 , 任何特性团队的需求过载都会让它成为整个业务瓶颈 , 解决办法是 , 同一业务领域的多个特性团队 , 共享同一需求列表 。 这就让一个团队出现资源瓶颈时 , 需求可以分配到另一个团队 , 这与今天很多服务行业中实行的 , “一个队列多个服务窗”的本质是一致的 。
以终为始的需求分析和设计
前面 , 我们讲了 , 企业的协同模式应该是业务驱动的 , 团队的交付模式应该是产品导向的 , 它们解决协同流程的问题 , 但光有流程是不够的 , 我们还必须保证输入的质量 。
IT行业有一句著名的话:“输入的是垃圾 , 输出的也会是垃圾“。 需求的输入 , 是交付过程是源头 , 也是最关键的部分 。 如果输入的有问题 , 交付的中间过程也不可能顺畅 。 那我们应该怎么做呢?
“输入垃圾 , 输出垃圾”的反面是以终为始 , ——也就是在需求输入的时候 , 团队要知道最终要做成什么样子 , 并在业务、产品和技术之间达成一致 。
那么 , 怎样才叫以终为始呢?以终为始分为3个方面:

相关经验推荐