當開發與軟件維護相結合時，DevOps 的理念對任何人來說都不足為奇。 一種新趨勢正在蓄勢待發——DevOps 2.0 或 BizDevOps。 它已經將三個組件合併為一個整體：業務、開發和支持。 就像在 DevOps 中一樣，工程實踐構成了開發與支持之間聯繫的基礎，因此在業務 DevOps 中，分析扮演著將開發與業務結合在一起的“粘合劑”角色。
我想馬上承認：我們得到了一個真正的 bizdevops，我們現在才知道，在閱讀智能書籍之後。 由於員工的主動性和不可抑制的改進熱情，它以某種方式發展起來。 今天，分析是開發生產過程的一部分，大大減少了反饋循環並定期提供見解。 我會詳細告訴你我們是如何安排一切的。
經典 DevOps 的缺點
當構思新的客戶產品時，企業會創建一個理想的客戶行為模型並期望良好的轉換，在此基礎上建立其業務目標和結果。 就開發團隊而言，它努力編寫非常好的、高質量的代碼。 另一方面，支持希望流程完全自動化，以方便維護新產品。
現實通常以這樣一種方式發展：客戶收到相當複雜的流程，業務依賴於低轉化率，開發團隊在修復後發布修復，並且支持淹沒在客戶的請求流中。 熟悉的？
這裡的罪惡根源在於流程中嵌入的漫長而質量差的反饋循環。 業務和開發人員在衝刺期間收集需求和接收反饋的同時，與有限數量的客戶進行溝通，這極大地影響了產品的命運。 通常對一個人來說重要的東西根本不是整個目標受眾的特徵。
了解產品的開發是否在正確的方向上是在發布幾個月後的財務報告和市場研究結果。 而且，由於樣本量有限，它們沒有提供在大量客戶身上檢驗假設的機會。 總的來說，結果是冗長、不准確且效率低下。
戰利品工具
我們找到了擺脫這種情況的好方法。 一個過去只幫助營銷人員的工具，我們進入了企業和開發人員的手中。 我們開始積極使用網絡分析，以便實時查看流程，了解此時此地發生的事情。 基於此，規劃產品本身，將其推廣給大量客戶。
如果計劃進行某種產品改進，您可以立即看到它與哪些指標相關聯，以及這些指標如何影響銷售以及對業務很重要的特徵。 所以你可以立即剔除效果不佳的假設。 或者，例如，向統計上顯著數量的用戶推出一項新功能並實時監控指標，以了解一切是否按預期進行。 不要等待請求或報告形式的反饋，而是立即監控並及時糾正創建產品的過程。 我們可以推出一項新功能，在三天內收集統計上正確的數據，再在三天內做出更改——現在一個很棒的新產品在一周內就準備好了。
你可以跟踪整個漏斗，所有接觸過新產品的客戶，找出漏斗急劇變窄的點，了解原因。 開發人員和企業現在都在關注這一點，這是日常工作的一部分。 他們看到相同的客戶旅程，他們可以一起產生改進的想法和假設。
這種業務和開發的集成，加上分析，使得持續創建產品、不斷優化、尋找和查看瓶頸、整個過程成為可能。
一切都與復雜性有關
當我們創建新產品時，我們不會從頭開始，而是將其構建到已經存在的複雜服務中。 試用新產品時，客戶通常會接觸多個部門。 他可以與聯絡中心的員工溝通，與辦公室的經理溝通，他可以聯繫支持人員，使用在線聊天。 在指標的幫助下，我們可以看到，例如，聯絡中心的負載是多少，如何最好地處理傳入的請求。 我們可以了解有多少人來辦公室，並建議如何進一步建議客戶。
信息系統也是如此。 我們的銀行已經存在了 20 多年，在此期間創建了大量的異構系統並且仍在運行。 後端系統之間的交互有時是不可預測的。 例如，在某些古老的系統中，對某個字段的字符數有限制，有時這會使新服務崩潰。 使用標準方法跟踪錯誤非常困難，但使用網絡分析是基本的。
我們已經到了開始收集和分析來自所有相關係統並顯示給客戶的錯誤文本的地步。 事實證明，他們中的許多人已經過時了，我們甚至無法想像他們以某種方式參與了我們的過程。
使用分析
我們在同一個房間裡有網絡分析和 SCRUM 開發團隊。 他們不斷地相互交流。 必要時，專家會幫助設置指標或上傳數據，但基本上團隊成員自己使用分析服務，沒有什麼複雜的。
例如，如果需要某些依賴項、針對有限類型的客戶端或源的額外過濾器，則需要幫助。 但是在目前的架構中，我們很少遇到這種情況。
有趣的是，引入分析並不需要安裝新的 IT 系統。 我們使用營銷人員以前使用過的相同軟件。 只需要在業務和開發中協調使用並實施即可。 當然，我們不能只拿營銷有的東西，我們必須重新配置一切，讓營銷進入一個新的環境，讓他們和我們在同一個信息領域。
將來，我們計劃購買改進版的網絡分析軟件，以應對不斷增加的已處理會話量。
我們還積極整合來自 CRM 和會計系統的網絡分析和內部數據庫。 通過合併數據，我們可以在所有必要的部分中全面了解客戶：按來源、客戶類型、產品分類。 幫助可視化數據的 BI 服務將很快提供給所有部門。
我們最終得到了什麼？ 事實上，我們將對其進行分析和決策制定作為生產過程的一部分，這產生了明顯的效果。
分析：不要踩耙子
最後，我想分享一些技巧，幫助您避免在構建 bizdevops 的過程中遇到障礙。
- 如果分析不能快速完成，那麼你就做錯了分析。 您需要從一種產品開始遵循簡單的路徑，然後進行擴展。
- 您必須擁有一個非常了解未來分析架構的團隊或人員。 您仍然需要在岸上決定如何擴展分析、將其集成到其他系統以及重用數據。
- 不要生成額外的數據。 Web 統計數據除了提供有用的信息外，還是一個包含低質量和冗餘數據的巨大垃圾場。 而這些垃圾如果沒有明確的目標，就會干擾決策和評估。
- 不要為了分析而分析。 首先，目標，工具的選擇，然後才是 - 僅在會產生影響的地方進行分析。
該材料與 Olga Chebotar ().
來源： www.habr.com