接下来让我们把目光再移向另一个热点平台---DevOps工具链，它之所以成为热点，就是因为越来越多具备不俗研发力量或资源的企业，希望通过平台建设，具备工程化承接数字化需求的能力。
企业打算投资建设DevOps工具链之前，需要先明确哪些能力可以采购，哪些需要自己建设；核心的原则当然是，确定性强、标准化程度高的部分尽量采购，企业自身特点与行业差异化大、或有机会成为核心竞争力的部分。
首先根据前文“数字化营销&运营平台”的案例里，平台化的过程识别到了三类工具：
用户画像、漏斗分析等效率/能力提升工具，用于该领域内一线人员提升执行效率和能力；
可视化看板类结果管理工具，用于对该领域内的产出结果进行管理（表现为结构化、半结构化、非结构化数据）；
运营计划看板类过程管理工具，从该领域内核心角色视角出发，结合管理方法实践，对执行过程，尤其是需要协作的部分进行管理和赋能；
这三类工具建设次序和过程也有一定的依赖，也决定着企业的投资策略。
“效率/能力提升工具”优先建设，可以采购或自研；“结果管理工具”最好基于前者的数据产出逻辑，结合数据洞察能力形成一定的管理办法后，再选择自研或三方承接需求；“过程管理工具”则有着更高的定制化需求，即便采购产品也需要进行二次开发，因为执行过程中如果涉及到跟其他团队协作的统筹方法（如项目管理方式），每个公司都千差万别，但可以将一些成熟外部产品做底座（如看板工具、视频会议工具）进行二次开发。
但同时，“DevOps工具链”相比“数字化营销&运营平台”来说更复杂的在于，其包含了多个领域之间的合作，如“需求管理”、“代码管理”、“测试管理”、“投产管理”等等；这就导致在做整体平台规划时，需要考虑不同维度下的设计、落地和运营方法。
从协作复杂度上看，需要关注不同岗位、环节，从核心用户视角出发，理清不同角色需要关注的任务，以及这些任务在不同领域下平台/工具里的流转；
从平台架构上看，要让业务架构、技术架构与组织架构相配合，数据的管理权限、平台的边界在实际落地中都会极大地影响使用情况；
从功能设计上看，不同角色执行专业任务时，实际的工作方法与理想规范一定有差距，在企业当前环境下，哪些角色应该配合工具学习方法论？哪些场景下工具、方法论要根据实际情况进行适应性设计和改造？
这些问题都需要结合企业实际情况进行调研，而不像前文反复提到的“三类工具”具备一定的共性和普适性，可以从行业经验上给出参考答案。
工具/平台边界划分辅助领域划分
平台和工具的规划方案，不仅影响着投资决策和成本结构，更影响着技术架构设计时，对核心域、通用域、支撑域等领域划分的结果。
那么假设经过对企业情况的初步调研和走查后，结合行业经验，得到如下的平台&工具关系图，并对平台和工具做了如下几种区分：
效率/赋能工具，该类工具又根据行业共识和企业能力分为两种：
对于执行人员需要的效率提升工具，行业内如果有非常标准的实践和工具（如代码管理、自动化测试、原型设计等），就可以直接采购现成产品；
对于没有现成的工具，但又确实需要工具辅助的部分，要么是业内没有通用的方法，要么是该工具没有足够的使用场景或经济效益。如若必要，企业可以选择自建，或者用灵活多样的方式（如专业角色负责）代替工具；
设计支撑平台：对同一领域内产出（结构化、半结构化、非结构化数据）进行整合管理的平台（如应用设计平台、架构平台、分层配置平台等）。 对于组织结构并不复杂的企业来说，可能并不需要这层平台，直接由工具或许就足以支撑；而对于体量较大、组织架构复杂的大型企业，该层平台要与组织架构紧密绑定，并从平台属性和特点上审视是否有平台化的需要；比如分层配置平台的建立与设计，是因为有专门的部门对研发团队进行基线设置、资源管理、环境支撑等工作，且对工作方式和资源分配进行管理。
职能协作平台：从领域出发（如需求管理、任务管理、测试管理、投产管理），以对应领域内关键角色（如产品经理、开发、测试、运维）视角出发建立的协作平台（如需求管理平台、代码管理平台、测试平台、流水线平台等）。 该层的几个平台相互间的数据调用会极其紧密，每个平台为对应环节负责，并制造关键数据；比如“需求管理平台”在需求阶段产出，并流转入开发迭代的“故事卡（编写需求的一种形式）”，在“开发任务管理平台”上会据此拆分“开发任务”；研发团队则是根据“开发任务”为单位执行具体分工，而非“故事卡”；但需要每个“故事卡”的开发完成，才能以“故事卡”为单位流转到测试阶段，而不能单独将完成的“开发任务”进行流转；但当一个迭代的所有“故事卡”都完成测试，理想情况下，该迭代所有“故事卡”对应的代码会进入发布环节，以迭代为单位，而不是“故事卡”。
端到端协作平台：基于项目或产品管理的需要，从组织投资决策管理和项目验收的立场出发，对所有进入研发阶段，即“DevOps工具链”纳管范围内的开发需求，进行验收、结项等工作，辅助企业经营管理的端到端信息整合平台。 该层平台所取用的数据完全来源于“职能协作层”的各平台进行整合和产出，可以根据整体数据表现迭代企业经营方法，并统一地进行数据治理。
如果将“DevOps工具链”平台的目标定义为帮企业建设工程化承接数字化需求的能力，那么可以将不同角色执行具体工作的协作方式和能力类比为业务架构，由于不同部门设置和管理方式而对平台进行的划分看作是组织架构的影响；那么在设计技术架构时，匹配“业务架构”与“组织架构”的领域划分方法，就可以将上述结果作为输入进行设计。
基于真实工作情况的调研结果设计方案
需要注意，这也并不是最终的结果，仅仅可以作为参考，降低设计时的复杂度，是提供确定性的一种信息输入方式。
企业可以根据这样的确定性、结合自身的投资策略和战略规划，去排兵布阵推进不同的工具/平台的建设，以及对应一线人员的能力培养。
从用户视角出发，改造能力
比如需求管理平台的建设，首先要调研评估当前BA或产品经理产出需求的方式和习惯；
如果企业没有投入改变工作方式的规划，那么平台设计时就需要匹配当前的用户习惯；而如果认为BA的需求实践不标准对工程效能造成了比较严重的影响，那么可能就需要外部力量介入进行辅导，或者在平台建设过程里，通过试点等方式用数字工具改造团队实践。
进而，基于需求实践的进步，管理实践才能落地；比如团队要采取“每日站会”这样的实践，以及有具体的实践要求（比如多地区团队远程站会），“需求管理平台”在建设时才需要考虑具体的需求。
所以，随着对用户场景的分析和丰富，不仅是对平台建设需求的澄清，更是一个总结、改造工作方式的最佳时间窗口。
比如如果需求阶段产出的“故事卡”经常在已经进入迭代之后，还要进行调整，并因此极大地影响了开发进度；那么在平台功能设计时，就要对“需求变更”这个场景更为重视，如配合变更流程和需求优先级看板将历史变概率更高（如需求提出团队/BA的需求变更率）的“故事卡”优先级调低；这就也会影响相关的管理实践，尤其是“回顾会”及“度量管理”场景，需要将对应的度量权重提高。
如果需求阶段产出的“故事卡”颗粒度太大，开发、测试完成一个故事卡的周期都太久，甚至需要跨迭代完成，导致流转速率过慢，甚至打破许多敏捷迭代实践需要的条件，给迭代运作提高阻力；那么在平台功能设计时，就需要强化类似“估点”这样功能的显性化，并更重视“故事卡”在需求全周期场景进行流转时的追踪，以及通过度量牵引“故事卡”的数量和交付速度。
所以虽然从功能开发和使用层面说，度量的能力需要在许多功能完成并被使用起来后才建设；但在团队能力改造上，尤其是试点团队，却是需要实践改造与度量管理同步实施的，只不过早期度量可以通过人力手动进行计算和过来，平台迭代的MVP也可以做一些可快速实现的简单功能（如Excel导出）辅助这个过程。
“从用户视角出发”，对不同场景（管理场景、度量场景等）使用到的能力抽象总结，整理出需求全景图，再根据试点团队需要进行优先级排序。
这个过程完成的就是在“需求管理”这个领域里，工程化解决问题的能力；而最大的难点或许就在于，如何配合工作方式的调整节奏同步迭代产品，市面上成本较低、确定性强的方案都很难满足要求。
如何利用外部力量
传统管理咨询的做法是引入一套标准的方法论和培训，方法论和实践的背后就是一套与工作方法配合的数据采集和分析框架，通过规范业务执行动作，让方法论体系下的指标发挥衡量业务成效的作用。
但每个企业有自己的企业文化和各种或浅或显的行为及管理方式，管理咨询公司试图在培训的过程中一个个团队地完成配适企业业务特征的调整，受限于方法论和实践的约束条件，想产生规模化效果往往需要持续的投入（然而企业这种组织形式天生不待见这种ROI充满不确定性的投资）。
数字解决方案提供商的做法是将方法论固化到产品上，配合方法论销售产品（如飞书与OKR）；通过产品配合方法论让用户对产品的使用方式更符合设计者对企业管理的抽象和构想；
所以理想情况下，自然是企业自己的平台研发团队同时负责平台运营，在功能设计之初就开始影响用户；但现实情况下，无论是从人员能力上还是从管理难度上，这些条件都不具备，因此还是需要借助上述两种外部力量，不过企业经营者只有在理解了供应商的工作方式后，才能更好地、最大化的利用外部资源。
比如如果采购互联网产品，企业除了要求私有化部署外，那么或许还应该要求对方提供咨询服务，培训、教辅企业员工如何更好得使用产品，甚至配合企业的流程和人员能力改造或者定制化一些功能；这是让企业一线员工配合成熟产品和学习方法论进步的思路，更适合本就缺乏标准化流程管理的中小企业。
而如若选择让工具配合企业经营管理流程，即让产品和方法论为企业进行定制化配适；那么就更需要专业的数字化咨询公司来对团队进行教辅，并根据教辅节奏和持续反馈提供平台建设方案；而企业为了保证效果，除了合同验收需要与成效绑定（比如达到xxx用户使用付款xx%）外，更需要理解上述逻辑，才能形成有效地配合和项目管理。
跨领域的平台对接
前文中，案例演示了在“需求管理”阶段，针对“故事卡”产出可能会出现的各类问题，而当“故事卡”流转起来后，不同角色都需要对“故事卡”有所操作，但目标和交互习惯截然不同，比如：
业务方、Tech Lead等角色共同决定“故事卡”优先级并移入迭代准备开发；研发团队小组长/Tech Lead负责将“故事卡”拆解为开发任务（Task），并分发给对应的研发人员进行执行；这部分工作依然都是针对“故事卡”进行的，业务方、项目经理和BA主要基于“需求管理平台”进行协作和日常项目沟通；但同时，Tech Lead更多的工作是进行开发任务开发、管理团队开发进度，主要是在“任务管理平台”上完成的；那么几类角色共同协作的需求优先级、迭代管理等功能，又应该在由哪个平台负责完成呢？
同样的问题也会发生在测试平台与测试团队身上，测试人员在与BA结对一起写测试用例时、与开发、BA一起开卡、结卡时，也是基于“故事卡”进行；但进行更消耗时间的主要测试工作时，又是在“测试平台”进行。测试、开发在进行需要专注的本职工作时也需要频繁参考“故事卡”的内容，那么自然也都会希望在自己专注的平台上，可以直接对“故事卡”进行交互而不是跳到“需求管理平台”上进行。
所以，“职能协作层”这些平台无论在交互体验上、还是数据表结构上，都最好经过统一规划和拉通设计，并通过“设计系统”、“API”等方式保证后续建设或接入的平台不会走样。
这样既有多样的技术方案可供选择，又能保证不同平台在对同样的内容（如“故事卡”）进行操作时体验一致，并允许各平台专注于自身“关键用户”的视角，提供对应的能力。
“需求管理平台”只需设计好“故事卡”相关的交互，并以服务的形式（封装好的前端代码、API等）提供出去，那么无论是在哪个平台，都可以通过调用服务保证“关键用户”的注意力专注于该平台上。
同理，“测试平台”做好“测试用例”相关服务，BA在“需求管理平台”上也一样能查看用例的编写进度和内容。
除了保证“职能协作层”各平台共性需求的体验一致性，还需要数据能力允许各平台具备独立的度量机制，以实现各职能部门（假设企业需要分只能进行度量管理）对岗位角色专业性的考核；同时又保证“端到端协作层”对研发全生命周期的数据洞察，用于发现工程协作的阻碍环节和根因问题。比如：
业务部门对BA/产品经理进行考核时，在“需求管理平台”的数据看板模块，可能看的更多的是故事卡的“产出速率”、“及时性”等等，并需要对相似业务的BA/产品经理们进行横向比较；而在“端到端可视化平台”上，项目经理主要看的或许则是故事卡的“需求变更率”，以避免干扰交付进度；
同理，测试部门对测试专员进行考核时，在“测试平台”上更关注测试用例的编写情况、自动化测试用例数等等；而在“端到端可视化平台”上，项目经理更关注“缺陷数量”、“严重等级”等数据，以识别交付风险；
“端到端协作层”关注企业技术部门的整体研发效能，以及交付过程的进度和风险；而“职能协作层”则更关注各自平台“关键用户”的用户体验、执行效率，以及从专业岗位要求上对职能角色的能力评估。
理想状况下，或者说“DevOps工具链”的完整形态下，各平台、各角色都可以相对独立运作，专注完成自身专业的工作就可以保证企业具备稳定的、持续交付的工程能力；
但如果团队进行的工程实践与预期差距过大，工具和平台有很大机会不能有效地反映真实问题，又或者问题根源太多找不到解决的主要方向，比如：
如果企业软件更新或上线时，同时有统一按版本发布和自发布两种需要，那么在发布部署阶段，运维人员就需要与不同团队用不同方法对接； 比如在众多团队共版本进行上线的场景里，运维人员就需要频繁地与所有团队对接上线版本，尤其是对需求变更过的、流水线管理混乱的团队，就更需要借助“需求管理平台”、“代码管理平台”、“流水线平台”等等的数据和结果来厘清，到底上线哪个制品、包含了哪些“故事卡”、是否都已经完成测试？ 但对实现了自发布的团队来说，是可以直接匹配迭代规划里的“故事卡”，和交付流水线上对应的制品，实现快速对接完成上线计划的；单纯以这个场景本身来说，或许并不需要一个平台来承载上线需求；不过自发布团队也需要被统一纳管，但如版本发布那样复杂的流程，反而会极大地降低团队效率。
需求阶段如果“故事卡”颗粒度太大，很可能导致开发人员无法在一个迭代内完成，进而影响节奏；更严重的是，当发生需求变更时，过大的“故事卡”更容易发生连锁的需求变化，且开发人员也有更大几率正处于该“故事卡”的开发过程中，将已经写的代码摘出去或者重写，必然对工作量造成巨大的浪费（甚至还不如完成开发更省时）。
所以，DevOps作为一个工具链平台，可以看作是对企业研发工程能力的体现；任何一个环节的薄弱，都会带来其它各环节的问题，并形成更为复杂、漫无头绪的大线团；这也更加证明了前几步建设阶段的重要性，缺乏实践支撑，专业性辅助产品设计得再好，也无法阻止团队走向恶性循环。
正是因为协作过程充满着各种的不确定性，才更需要每个环节本身提供确定性的能力和产出。
