接下來讓我們把目光再移向另一個(gè)熱點(diǎn)平臺(tái)---DevOps工具鏈哟忍，它之所以成為熱點(diǎn)，就是因?yàn)樵絹碓蕉嗑邆洳凰籽邪l(fā)力量或資源的企業(yè)其馏，希望通過平臺(tái)建設(shè)爆安，具備工程化承接數(shù)字化需求的能力扔仓。
企業(yè)打算投資建設(shè)DevOps工具鏈之前，需要先明確哪些能力可以采購撬码，哪些需要自己建設(shè)版保；核心的原則當(dāng)然是彻犁，確定性強(qiáng)、標(biāo)準(zhǔn)化程度高的部分盡量采購驼鹅，企業(yè)自身特點(diǎn)與行業(yè)差異化大森篷、或有機(jī)會(huì)成為核心競(jìng)爭(zhēng)力的部分疾宏。
首先根據(jù)前文“數(shù)字化營(yíng)銷&運(yùn)營(yíng)平臺(tái)”的案例里，平臺(tái)化的過程識(shí)別到了三類工具：
用戶畫像为牍、漏斗分析等效率/能力提升工具岩馍，用于該領(lǐng)域內(nèi)一線人員提升執(zhí)行效率和能力蛀恩；
可視化看板類結(jié)果管理工具双谆，用于對(duì)該領(lǐng)域內(nèi)的產(chǎn)出結(jié)果進(jìn)行管理（表現(xiàn)為結(jié)構(gòu)化、半結(jié)構(gòu)化幌羞、非結(jié)構(gòu)化數(shù)據(jù)）属桦；
運(yùn)營(yíng)計(jì)劃看板類過程管理工具盏混，從該領(lǐng)域內(nèi)核心角色視角出發(fā)许赃，結(jié)合管理方法實(shí)踐乾巧，對(duì)執(zhí)行過程，尤其是需要協(xié)作的部分進(jìn)行管理和賦能咳胃；
這三類工具建設(shè)次序和過程也有一定的依賴旷太，也決定著企業(yè)的投資策略供璧。
“效率/能力提升工具”優(yōu)先建設(shè)，可以采購或自研来惧；“結(jié)果管理工具”最好基于前者的數(shù)據(jù)產(chǎn)出邏輯演顾，結(jié)合數(shù)據(jù)洞察能力形成一定的管理辦法后，再選擇自研或三方承接需求军浆；“過程管理工具”則有著更高的定制化需求挡闰，即便采購產(chǎn)品也需要進(jìn)行二次開發(fā)，因?yàn)閳?zhí)行過程中如果涉及到跟其他團(tuán)隊(duì)協(xié)作的統(tǒng)籌方法（如項(xiàng)目管理方式）赞季，每個(gè)公司都千差萬別申钩，但可以將一些成熟外部產(chǎn)品做底座（如看板工具瘪阁、視頻會(huì)議工具）進(jìn)行二次開發(fā)管跺。
但同時(shí)，“DevOps工具鏈”相比“數(shù)字化營(yíng)銷&運(yùn)營(yíng)平臺(tái)”來說更復(fù)雜的在于廉涕，其包含了多個(gè)領(lǐng)域之間的合作艇拍，如“需求管理”卸夕、“代碼管理”、“測(cè)試管理”贡羔、“投產(chǎn)管理”等等；這就導(dǎo)致在做整體平臺(tái)規(guī)劃時(shí)碍讨，需要考慮不同維度下的設(shè)計(jì)治力、落地和運(yùn)營(yíng)方法。
從協(xié)作復(fù)雜度上看勃黍，需要關(guān)注不同崗位宵统、環(huán)節(jié)，從核心用戶視角出發(fā)，理清不同角色需要關(guān)注的任務(wù)马澈，以及這些任務(wù)在不同領(lǐng)域下平臺(tái)/工具里的流轉(zhuǎn)；
從平臺(tái)架構(gòu)上看痊班，要讓業(yè)務(wù)架構(gòu)勤婚、技術(shù)架構(gòu)與組織架構(gòu)相配合，數(shù)據(jù)的管理權(quán)限涤伐、平臺(tái)的邊界在實(shí)際落地中都會(huì)極大地影響使用情況馒胆；
從功能設(shè)計(jì)上看，不同角色執(zhí)行專業(yè)任務(wù)時(shí)凝果，實(shí)際的工作方法與理想規(guī)范一定有差距祝迂，在企業(yè)當(dāng)前環(huán)境下，哪些角色應(yīng)該配合工具學(xué)習(xí)方法論器净？哪些場(chǎng)景下工具型雳、方法論要根據(jù)實(shí)際情況進(jìn)行適應(yīng)性設(shè)計(jì)和改造？
這些問題都需要結(jié)合企業(yè)實(shí)際情況進(jìn)行調(diào)研山害，而不像前文反復(fù)提到的“三類工具”具備一定的共性和普適性纠俭，可以從行業(yè)經(jīng)驗(yàn)上給出參考答案。
工具/平臺(tái)邊界劃分輔助領(lǐng)域劃分
平臺(tái)和工具的規(guī)劃方案浪慌，不僅影響著投資決策和成本結(jié)構(gòu)冤荆，更影響著技術(shù)架構(gòu)設(shè)計(jì)時(shí)，對(duì)核心域眷射、通用域匙赞、支撐域等領(lǐng)域劃分的結(jié)果。
那么假設(shè)經(jīng)過對(duì)企業(yè)情況的初步調(diào)研和走查后妖碉，結(jié)合行業(yè)經(jīng)驗(yàn)，得到如下的平臺(tái)&工具關(guān)系圖芥被，并對(duì)平臺(tái)和工具做了如下幾種區(qū)分：
效率/賦能工具欧宜，該類工具又根據(jù)行業(yè)共識(shí)和企業(yè)能力分為兩種：
對(duì)于執(zhí)行人員需要的效率提升工具，行業(yè)內(nèi)如果有非常標(biāo)準(zhǔn)的實(shí)踐和工具（如代碼管理拴魄、自動(dòng)化測(cè)試冗茸、原型設(shè)計(jì)等），就可以直接采購現(xiàn)成產(chǎn)品匹中；
對(duì)于沒有現(xiàn)成的工具夏漱，但又確實(shí)需要工具輔助的部分，要么是業(yè)內(nèi)沒有通用的方法顶捷，要么是該工具沒有足夠的使用場(chǎng)景或經(jīng)濟(jì)效益挂绰。如若必要，企業(yè)可以選擇自建服赎，或者用靈活多樣的方式（如專業(yè)角色負(fù)責(zé)）代替工具葵蒂；
設(shè)計(jì)支撐平臺(tái)：對(duì)同一領(lǐng)域內(nèi)產(chǎn)出（結(jié)構(gòu)化交播、半結(jié)構(gòu)化、非結(jié)構(gòu)化數(shù)據(jù)）進(jìn)行整合管理的平臺(tái)（如應(yīng)用設(shè)計(jì)平臺(tái)践付、架構(gòu)平臺(tái)秦士、分層配置平臺(tái)等）。 對(duì)于組織結(jié)構(gòu)并不復(fù)雜的企業(yè)來說永高，可能并不需要這層平臺(tái)隧土，直接由工具或許就足以支撐；而對(duì)于體量較大命爬、組織架構(gòu)復(fù)雜的大型企業(yè)曹傀，該層平臺(tái)要與組織架構(gòu)緊密綁定，并從平臺(tái)屬性和特點(diǎn)上審視是否有平臺(tái)化的需要遇骑；比如分層配置平臺(tái)的建立與設(shè)計(jì)卖毁，是因?yàn)橛袑ｉT的部門對(duì)研發(fā)團(tuán)隊(duì)進(jìn)行基線設(shè)置、資源管理落萎、環(huán)境支撐等工作亥啦，且對(duì)工作方式和資源分配進(jìn)行管理。
職能協(xié)作平臺(tái)：從領(lǐng)域出發(fā)（如需求管理练链、任務(wù)管理翔脱、測(cè)試管理、投產(chǎn)管理）媒鼓，以對(duì)應(yīng)領(lǐng)域內(nèi)關(guān)鍵角色（如產(chǎn)品經(jīng)理届吁、開發(fā)、測(cè)試绿鸣、運(yùn)維）視角出發(fā)建立的協(xié)作平臺(tái)（如需求管理平臺(tái)疚沐、代碼管理平臺(tái)、測(cè)試平臺(tái)潮模、流水線平臺(tái)等）亮蛔。 該層的幾個(gè)平臺(tái)相互間的數(shù)據(jù)調(diào)用會(huì)極其緊密，每個(gè)平臺(tái)為對(duì)應(yīng)環(huán)節(jié)負(fù)責(zé)擎厢，并制造關(guān)鍵數(shù)據(jù)究流；比如“需求管理平臺(tái)”在需求階段產(chǎn)出，并流轉(zhuǎn)入開發(fā)迭代的“故事卡（編寫需求的一種形式）”动遭，在“開發(fā)任務(wù)管理平臺(tái)”上會(huì)據(jù)此拆分“開發(fā)任務(wù)”芬探；研發(fā)團(tuán)隊(duì)則是根據(jù)“開發(fā)任務(wù)”為單位執(zhí)行具體分工，而非“故事卡”厘惦；但需要每個(gè)“故事卡”的開發(fā)完成偷仿，才能以“故事卡”為單位流轉(zhuǎn)到測(cè)試階段，而不能單獨(dú)將完成的“開發(fā)任務(wù)”進(jìn)行流轉(zhuǎn)；但當(dāng)一個(gè)迭代的所有“故事卡”都完成測(cè)試炎疆，理想情況下卡骂，該迭代所有“故事卡”對(duì)應(yīng)的代碼會(huì)進(jìn)入發(fā)布環(huán)節(jié)，以迭代為單位形入，而不是“故事卡”全跨。
端到端協(xié)作平臺(tái)：基于項(xiàng)目或產(chǎn)品管理的需要，從組織投資決策管理和項(xiàng)目驗(yàn)收的立場(chǎng)出發(fā)亿遂，對(duì)所有進(jìn)入研發(fā)階段浓若，即“DevOps工具鏈”納管范圍內(nèi)的開發(fā)需求，進(jìn)行驗(yàn)收蛇数、結(jié)項(xiàng)等工作挪钓，輔助企業(yè)經(jīng)營(yíng)管理的端到端信息整合平臺(tái)。 該層平臺(tái)所取用的數(shù)據(jù)完全來源于“職能協(xié)作層”的各平臺(tái)進(jìn)行整合和產(chǎn)出耳舅，可以根據(jù)整體數(shù)據(jù)表現(xiàn)迭代企業(yè)經(jīng)營(yíng)方法碌上，并統(tǒng)一地進(jìn)行數(shù)據(jù)治理。
如果將“DevOps工具鏈”平臺(tái)的目標(biāo)定義為幫企業(yè)建設(shè)工程化承接數(shù)字化需求的能力浦徊，那么可以將不同角色執(zhí)行具體工作的協(xié)作方式和能力類比為業(yè)務(wù)架構(gòu)馏予，由于不同部門設(shè)置和管理方式而對(duì)平臺(tái)進(jìn)行的劃分看作是組織架構(gòu)的影響；那么在設(shè)計(jì)技術(shù)架構(gòu)時(shí)盔性，匹配“業(yè)務(wù)架構(gòu)”與“組織架構(gòu)”的領(lǐng)域劃分方法霞丧，就可以將上述結(jié)果作為輸入進(jìn)行設(shè)計(jì)。
基于真實(shí)工作情況的調(diào)研結(jié)果設(shè)計(jì)方案
需要注意冕香，這也并不是最終的結(jié)果蛹尝，僅僅可以作為參考，降低設(shè)計(jì)時(shí)的復(fù)雜度悉尾，是提供確定性的一種信息輸入方式突那。
企業(yè)可以根據(jù)這樣的確定性、結(jié)合自身的投資策略和戰(zhàn)略規(guī)劃构眯，去排兵布陣推進(jìn)不同的工具/平臺(tái)的建設(shè)陨收，以及對(duì)應(yīng)一線人員的能力培養(yǎng)。
從用戶視角出發(fā)鸵赖，改造能力
比如需求管理平臺(tái)的建設(shè)，首先要調(diào)研評(píng)估當(dāng)前BA或產(chǎn)品經(jīng)理產(chǎn)出需求的方式和習(xí)慣拄衰；
如果企業(yè)沒有投入改變工作方式的規(guī)劃它褪，那么平臺(tái)設(shè)計(jì)時(shí)就需要匹配當(dāng)前的用戶習(xí)慣；而如果認(rèn)為BA的需求實(shí)踐不標(biāo)準(zhǔn)對(duì)工程效能造成了比較嚴(yán)重的影響翘悉，那么可能就需要外部力量介入進(jìn)行輔導(dǎo)茫打，或者在平臺(tái)建設(shè)過程里，通過試點(diǎn)等方式用數(shù)字工具改造團(tuán)隊(duì)實(shí)踐。
進(jìn)而老赤，基于需求實(shí)踐的進(jìn)步轮洋，管理實(shí)踐才能落地；比如團(tuán)隊(duì)要采取“每日站會(huì)”這樣的實(shí)踐抬旺，以及有具體的實(shí)踐要求（比如多地區(qū)團(tuán)隊(duì)遠(yuǎn)程站會(huì)）弊予，“需求管理平臺(tái)”在建設(shè)時(shí)才需要考慮具體的需求。
所以汉柒，隨著對(duì)用戶場(chǎng)景的分析和豐富，不僅是對(duì)平臺(tái)建設(shè)需求的澄清责鳍，更是一個(gè)總結(jié)碾褂、改造工作方式的最佳時(shí)間窗口。
比如如果需求階段產(chǎn)出的“故事卡”經(jīng)常在已經(jīng)進(jìn)入迭代之后历葛，還要進(jìn)行調(diào)整正塌，并因此極大地影響了開發(fā)進(jìn)度；那么在平臺(tái)功能設(shè)計(jì)時(shí)恤溶，就要對(duì)“需求變更”這個(gè)場(chǎng)景更為重視乓诽，如配合變更流程和需求優(yōu)先級(jí)看板將歷史變概率更高（如需求提出團(tuán)隊(duì)/BA的需求變更率）的“故事卡”優(yōu)先級(jí)調(diào)低；這就也會(huì)影響相關(guān)的管理實(shí)踐宏娄，尤其是“回顧會(huì)”及“度量管理”場(chǎng)景问裕，需要將對(duì)應(yīng)的度量權(quán)重提高。
如果需求階段產(chǎn)出的“故事卡”顆粒度太大粮宛，開發(fā)、測(cè)試完成一個(gè)故事卡的周期都太久卖宠，甚至需要跨迭代完成巍杈，導(dǎo)致流轉(zhuǎn)速率過慢，甚至打破許多敏捷迭代實(shí)踐需要的條件，給迭代運(yùn)作提高阻力；那么在平臺(tái)功能設(shè)計(jì)時(shí)周偎，就需要強(qiáng)化類似“估點(diǎn)”這樣功能的顯性化蓉坎，并更重視“故事卡”在需求全周期場(chǎng)景進(jìn)行流轉(zhuǎn)時(shí)的追蹤伺通，以及通過度量牽引“故事卡”的數(shù)量和交付速度逢享。
所以雖然從功能開發(fā)和使用層面說，度量的能力需要在許多功能完成并被使用起來后才建設(shè)；但在團(tuán)隊(duì)能力改造上侧但，尤其是試點(diǎn)團(tuán)隊(duì)禀横，卻是需要實(shí)踐改造與度量管理同步實(shí)施的酿箭，只不過早期度量可以通過人力手動(dòng)進(jìn)行計(jì)算和過來，平臺(tái)迭代的MVP也可以做一些可快速實(shí)現(xiàn)的簡(jiǎn)單功能（如Excel導(dǎo)出）輔助這個(gè)過程。
“從用戶視角出發(fā)”，對(duì)不同場(chǎng)景（管理場(chǎng)景、度量場(chǎng)景等）使用到的能力抽象總結(jié)挣磨，整理出需求全景圖节仿，再根據(jù)試點(diǎn)團(tuán)隊(duì)需要進(jìn)行優(yōu)先級(jí)排序。
這個(gè)過程完成的就是在“需求管理”這個(gè)領(lǐng)域里壕翩，工程化解決問題的能力荐操；而最大的難點(diǎn)或許就在于，如何配合工作方式的調(diào)整節(jié)奏同步迭代產(chǎn)品唠亚，市面上成本較低割卖、確定性強(qiáng)的方案都很難滿足要求淹仑。
如何利用外部力量
傳統(tǒng)管理咨詢的做法是引入一套標(biāo)準(zhǔn)的方法論和培訓(xùn)颜阐，方法論和實(shí)踐的背后就是一套與工作方法配合的數(shù)據(jù)采集和分析框架平窘，通過規(guī)范業(yè)務(wù)執(zhí)行動(dòng)作，讓方法論體系下的指標(biāo)發(fā)揮衡量業(yè)務(wù)成效的作用凳怨。
但每個(gè)企業(yè)有自己的企業(yè)文化和各種或淺或顯的行為及管理方式瑰艘，管理咨詢公司試圖在培訓(xùn)的過程中一個(gè)個(gè)團(tuán)隊(duì)地完成配適企業(yè)業(yè)務(wù)特征的調(diào)整，受限于方法論和實(shí)踐的約束條件肤舞，想產(chǎn)生規(guī)淖闲拢化效果往往需要持續(xù)的投入（然而企業(yè)這種組織形式天生不待見這種ROI充滿不確定性的投資）。
數(shù)字解決方案提供商的做法是將方法論固化到產(chǎn)品上李剖，配合方法論銷售產(chǎn)品（如飛書與OKR）芒率；通過產(chǎn)品配合方法論讓用戶對(duì)產(chǎn)品的使用方式更符合設(shè)計(jì)者對(duì)企業(yè)管理的抽象和構(gòu)想；
所以理想情況下杖爽，自然是企業(yè)自己的平臺(tái)研發(fā)團(tuán)隊(duì)同時(shí)負(fù)責(zé)平臺(tái)運(yùn)營(yíng)敲董，在功能設(shè)計(jì)之初就開始影響用戶；但現(xiàn)實(shí)情況下慰安，無論是從人員能力上還是從管理難度上腋寨，這些條件都不具備，因此還是需要借助上述兩種外部力量化焕，不過企業(yè)經(jīng)營(yíng)者只有在理解了供應(yīng)商的工作方式后萄窜，才能更好地、最大化的利用外部資源撒桨。
比如如果采購互聯(lián)網(wǎng)產(chǎn)品查刻，企業(yè)除了要求私有化部署外，那么或許還應(yīng)該要求對(duì)方提供咨詢服務(wù)凤类，培訓(xùn)穗泵、教輔企業(yè)員工如何更好得使用產(chǎn)品，甚至配合企業(yè)的流程和人員能力改造或者定制化一些功能谜疤；這是讓企業(yè)一線員工配合成熟產(chǎn)品和學(xué)習(xí)方法論進(jìn)步的思路佃延，更適合本就缺乏標(biāo)準(zhǔn)化流程管理的中小企業(yè)。
而如若選擇讓工具配合企業(yè)經(jīng)營(yíng)管理流程夷磕，即讓產(chǎn)品和方法論為企業(yè)進(jìn)行定制化配適履肃；那么就更需要專業(yè)的數(shù)字化咨詢公司來對(duì)團(tuán)隊(duì)進(jìn)行教輔，并根據(jù)教輔節(jié)奏和持續(xù)反饋提供平臺(tái)建設(shè)方案坐桩；而企業(yè)為了保證效果尺棋，除了合同驗(yàn)收需要與成效綁定（比如達(dá)到xxx用戶使用付款xx%）外，更需要理解上述邏輯绵跷，才能形成有效地配合和項(xiàng)目管理膘螟。
跨領(lǐng)域的平臺(tái)對(duì)接
前文中成福，案例演示了在“需求管理”階段，針對(duì)“故事卡”產(chǎn)出可能會(huì)出現(xiàn)的各類問題萍鲸，而當(dāng)“故事卡”流轉(zhuǎn)起來后闷叉，不同角色都需要對(duì)“故事卡”有所操作，但目標(biāo)和交互習(xí)慣截然不同脊阴，比如：
業(yè)務(wù)方、Tech Lead等角色共同決定“故事卡”優(yōu)先級(jí)并移入迭代準(zhǔn)備開發(fā)蚯瞧；研發(fā)團(tuán)隊(duì)小組長(zhǎng)/Tech Lead負(fù)責(zé)將“故事卡”拆解為開發(fā)任務(wù)（Task）嘿期，并分發(fā)給對(duì)應(yīng)的研發(fā)人員進(jìn)行執(zhí)行；這部分工作依然都是針對(duì)“故事卡”進(jìn)行的埋合，業(yè)務(wù)方备徐、項(xiàng)目經(jīng)理和BA主要基于“需求管理平臺(tái)”進(jìn)行協(xié)作和日常項(xiàng)目溝通；但同時(shí)甚颂，Tech Lead更多的工作是進(jìn)行開發(fā)任務(wù)開發(fā)蜜猾、管理團(tuán)隊(duì)開發(fā)進(jìn)度，主要是在“任務(wù)管理平臺(tái)”上完成的振诬；那么幾類角色共同協(xié)作的需求優(yōu)先級(jí)蹭睡、迭代管理等功能，又應(yīng)該在由哪個(gè)平臺(tái)負(fù)責(zé)完成呢赶么？
同樣的問題也會(huì)發(fā)生在測(cè)試平臺(tái)與測(cè)試團(tuán)隊(duì)身上肩豁，測(cè)試人員在與BA結(jié)對(duì)一起寫測(cè)試用例時(shí)、與開發(fā)辫呻、BA一起開卡清钥、結(jié)卡時(shí)，也是基于“故事卡”進(jìn)行放闺；但進(jìn)行更消耗時(shí)間的主要測(cè)試工作時(shí)祟昭，又是在“測(cè)試平臺(tái)”進(jìn)行。測(cè)試怖侦、開發(fā)在進(jìn)行需要專注的本職工作時(shí)也需要頻繁參考“故事卡”的內(nèi)容篡悟，那么自然也都會(huì)希望在自己專注的平臺(tái)上，可以直接對(duì)“故事卡”進(jìn)行交互而不是跳到“需求管理平臺(tái)”上進(jìn)行础钠。
所以恰力，“職能協(xié)作層”這些平臺(tái)無論在交互體驗(yàn)上、還是數(shù)據(jù)表結(jié)構(gòu)上旗吁，都最好經(jīng)過統(tǒng)一規(guī)劃和拉通設(shè)計(jì)踩萎，并通過“設(shè)計(jì)系統(tǒng)”、“API”等方式保證后續(xù)建設(shè)或接入的平臺(tái)不會(huì)走樣很钓。
這樣既有多樣的技術(shù)方案可供選擇香府，又能保證不同平臺(tái)在對(duì)同樣的內(nèi)容（如“故事卡”）進(jìn)行操作時(shí)體驗(yàn)一致董栽，并允許各平臺(tái)專注于自身“關(guān)鍵用戶”的視角，提供對(duì)應(yīng)的能力企孩。
“需求管理平臺(tái)”只需設(shè)計(jì)好“故事卡”相關(guān)的交互锭碳，并以服務(wù)的形式（封裝好的前端代碼、API等）提供出去勿璃，那么無論是在哪個(gè)平臺(tái)擒抛，都可以通過調(diào)用服務(wù)保證“關(guān)鍵用戶”的注意力專注于該平臺(tái)上。
同理补疑，“測(cè)試平臺(tái)”做好“測(cè)試用例”相關(guān)服務(wù)歧沪，BA在“需求管理平臺(tái)”上也一樣能查看用例的編寫進(jìn)度和內(nèi)容。
除了保證“職能協(xié)作層”各平臺(tái)共性需求的體驗(yàn)一致性莲组，還需要數(shù)據(jù)能力允許各平臺(tái)具備獨(dú)立的度量機(jī)制诊胞，以實(shí)現(xiàn)各職能部門（假設(shè)企業(yè)需要分只能進(jìn)行度量管理）對(duì)崗位角色專業(yè)性的考核；同時(shí)又保證“端到端協(xié)作層”對(duì)研發(fā)全生命周期的數(shù)據(jù)洞察锹杈，用于發(fā)現(xiàn)工程協(xié)作的阻礙環(huán)節(jié)和根因問題撵孤。比如：
業(yè)務(wù)部門對(duì)BA/產(chǎn)品經(jīng)理進(jìn)行考核時(shí)，在“需求管理平臺(tái)”的數(shù)據(jù)看板模塊竭望，可能看的更多的是故事卡的“產(chǎn)出速率”邪码、“及時(shí)性”等等，并需要對(duì)相似業(yè)務(wù)的BA/產(chǎn)品經(jīng)理們進(jìn)行橫向比較市框；而在“端到端可視化平臺(tái)”上霞扬，項(xiàng)目經(jīng)理主要看的或許則是故事卡的“需求變更率”，以避免干擾交付進(jìn)度枫振；
同理喻圃，測(cè)試部門對(duì)測(cè)試專員進(jìn)行考核時(shí)，在“測(cè)試平臺(tái)”上更關(guān)注測(cè)試用例的編寫情況粪滤、自動(dòng)化測(cè)試用例數(shù)等等斧拍；而在“端到端可視化平臺(tái)”上，項(xiàng)目經(jīng)理更關(guān)注“缺陷數(shù)量”杖小、“嚴(yán)重等級(jí)”等數(shù)據(jù)肆汹，以識(shí)別交付風(fēng)險(xiǎn)；
“端到端協(xié)作層”關(guān)注企業(yè)技術(shù)部門的整體研發(fā)效能予权，以及交付過程的進(jìn)度和風(fēng)險(xiǎn)昂勉；而“職能協(xié)作層”則更關(guān)注各自平臺(tái)“關(guān)鍵用戶”的用戶體驗(yàn)扫腺、執(zhí)行效率岗照，以及從專業(yè)崗位要求上對(duì)職能角色的能力評(píng)估。
理想狀況下厚者，或者說“DevOps工具鏈”的完整形態(tài)下，各平臺(tái)迫吐、各角色都可以相對(duì)獨(dú)立運(yùn)作库菲，專注完成自身專業(yè)的工作就可以保證企業(yè)具備穩(wěn)定的志膀、持續(xù)交付的工程能力；
但如果團(tuán)隊(duì)進(jìn)行的工程實(shí)踐與預(yù)期差距過大溉浙，工具和平臺(tái)有很大機(jī)會(huì)不能有效地反映真實(shí)問題奇颠，又或者問題根源太多找不到解決的主要方向，比如：
如果企業(yè)軟件更新或上線時(shí)放航，同時(shí)有統(tǒng)一按版本發(fā)布和自發(fā)布兩種需要圆裕，那么在發(fā)布部署階段，運(yùn)維人員就需要與不同團(tuán)隊(duì)用不同方法對(duì)接吓妆； 比如在眾多團(tuán)隊(duì)共版本進(jìn)行上線的場(chǎng)景里，運(yùn)維人員就需要頻繁地與所有團(tuán)隊(duì)對(duì)接上線版本祖秒，尤其是對(duì)需求變更過的舟奠、流水線管理混亂的團(tuán)隊(duì)竭缝，就更需要借助“需求管理平臺(tái)”沼瘫、“代碼管理平臺(tái)”、“流水線平臺(tái)”等等的數(shù)據(jù)和結(jié)果來厘清湿故，到底上線哪個(gè)制品膜蛔、包含了哪些“故事卡”、是否都已經(jīng)完成測(cè)試皂股？ 但對(duì)實(shí)現(xiàn)了自發(fā)布的團(tuán)隊(duì)來說，是可以直接匹配迭代規(guī)劃里的“故事卡”躁锁，和交付流水線上對(duì)應(yīng)的制品，實(shí)現(xiàn)快速對(duì)接完成上線計(jì)劃的搜立；單純以這個(gè)場(chǎng)景本身來說槐秧，或許并不需要一個(gè)平臺(tái)來承載上線需求啄踊；不過自發(fā)布團(tuán)隊(duì)也需要被統(tǒng)一納管颠通，但如版本發(fā)布那樣復(fù)雜的流程膀懈，反而會(huì)極大地降低團(tuán)隊(duì)效率。
需求階段如果“故事卡”顆粒度太大启搂，很可能導(dǎo)致開發(fā)人員無法在一個(gè)迭代內(nèi)完成，進(jìn)而影響節(jié)奏胳赌；更嚴(yán)重的是，當(dāng)發(fā)生需求變更時(shí)熏版，過大的“故事卡”更容易發(fā)生連鎖的需求變化捍掺，且開發(fā)人員也有更大幾率正處于該“故事卡”的開發(fā)過程中，將已經(jīng)寫的代碼摘出去或者重寫乡小，必然對(duì)工作量造成巨大的浪費(fèi)（甚至還不如完成開發(fā)更省時(shí)）。
所以胜榔，DevOps作為一個(gè)工具鏈平臺(tái)湃番，可以看作是對(duì)企業(yè)研發(fā)工程能力的體現(xiàn)；任何一個(gè)環(huán)節(jié)的薄弱尊惰，都會(huì)帶來其它各環(huán)節(jié)的問題，并形成更為復(fù)雜弄屡、漫無頭緒的大線團(tuán)；這也更加證明了前幾步建設(shè)階段的重要性膀捷，缺乏實(shí)踐支撐全庸，專業(yè)性輔助產(chǎn)品設(shè)計(jì)得再好，也無法阻止團(tuán)隊(duì)走向惡性循環(huán)壶笼。
正是因?yàn)?b>協(xié)作過程充滿著各種的不確定性，才更需要每個(gè)環(huán)節(jié)本身提供確定性的能力和產(chǎn)出保礼。
