Spotify如何驅動「數據驅動」決策

  • 流覽次數:: 54
  • 分類: 產業區
  • 分享次數:
  • 作者: 音樂地圖
  • Spotify如何驅動「數據驅動」決策

      202102/0906:55

    ◎Spotify的基礎架構團隊分享如何透過對數據進行優先級排序,以構建自動數據收集平台,該平台可在(DevOps)中進行數據驅動的決策,並提高開發人員的生產力和產品價值。
    ◎Spotify基礎架構團隊將Gradle(Gradle Enterprise Edition)用作其Android應用程式的構建系統。它根據本地開發經驗來生成,收集和儲存理解軟體所需的數據。由於沒有針對iOS的數據生成,收集和儲存的既定解決方案,因此該團隊自己構建了這些工具。
    ◎Spotify已經對數據進行了一段時間的投資。Spotify技術學習團隊已經啟動了數據大學,這是一系列培訓課程,涵蓋了數據科學和工程學的各個方面,旨在幫助工程師解決與產品相關的問題。
    ◎Spotify團隊使用這種新的數據基礎結構來闡明技術和產品團隊應在哪些方面進行投資,以減少構建時間。當他們查看構建時間趨勢以及Swift和ObjC中使用的組件總數時,有必要對Swift優化進行投資。
    ◎這項針對數據驅動型決策的技術投資,與哈佛商業評論分析服務公司的最新研究相比非常出色。該研究表明,只有7%的組織為他們的團隊提供驅動基於數據的決策,和自治所需的分析工具和資源。產品團隊中以數據為依據的決策有助於評估解決方案的有效性和採用滿意度。產品經理經常從很早期就使用用戶研究來評估產品。相比之下,數據驅動的流程將這種評估帶入了產品概念化。

    詳細全文:

    Spotify's infrastructure team has shared how by prioritising data, they've built an automated data collection platform that enables data-driven decision-making in DevOps and has improved their developer productivity and product value.
    The Spotify infrastructure teams use Gradle (Gradle Enterprise Edition) as a build system for their Android apps. It generates, collects and stores the data needed to understand their software in the context of the local development experience. It requires joint focus on data pipelines and visualisation on dashboards. There wasn't an established solution for data generation, collection and storage for iOS, so the team built the tools themselves.
    Spotify has been investing in data for some time. The Spotify Tech Learning team has launched Data University, a series of training sessions that covered different aspects of data science and engineering, designed to help engineers solve product-related problems.
    The Android infrastructure team brought those lessons to bear on their build times and their local development experience, but discovered that they lacked the data to drive decision-making.
    Spotify has tackled this data demand by dedicating certain groups it calls tribes to providing the data infrastructure, and equipping the engineers with the building blocks to collect the data and feed it into visualisations. They indicate that plenty of challenges remain, for example to bring this data-driven approach to their architectural decisions.
    The team used this new data infrastructure to shed light on where the technical and product teams should invest in to reduce build time. When they looked at the build-time trend, and the overall numbers of components in use across Swift and ObjC, it made sense to invest in Swift optimisation.
    This technical investment into data-driven decision-making stands out against recent research by Harvard Business Review Analytic Services, which shows that only 7% of organisations give their teams the analytics tooling and resources needed to drive data-based decision-making and autonomy.
    In essence, Spotify's approach is simple: the team produces questions they don't have the answer to, and then prioritises the work to answer them in the backlog. After the data is available and the question answered, the team collects feedback in an evaluation phase to understand if the work had an impact on the local development process. To prevent deterioration of the data quality, the teams have to build in quality checks on data consistency and data pipelines per component.
    In the planning phase, the team uses historic data to identify scenarios for improvement. The data may not describe the current scenario, but it offers a baseline to identify improvements. If they already understand the build time for the system in a specific scenario, they expect to either keep the same numbers or improve them regardless of the growth of the codebase. This is critical because as systems become more complex, DevOps workflows generally become complex and opaque.
    Agile naturally leans towards prioritising product, so the challenge in DevOps is to throw light onto the compromise between investing in features to increase product effectiveness or increasing development efficiency or improving service reliability.
    During planning, the team introduces tasks that collect and display the data needed to validate their changes. The questions raised in this phase are one of the key outputs, e.g.: "Are we collecting enough information to check whether developers have the remote cache on?" or "How many components do they change on average in a single PR?"
    As the infrastructure team's data initiative was recognised more widely internally, other teams began prioritising work related to the platform. Product teams started to value the data visualisations for validating the product discussions that drive the decision-making process for mobile DevOps teams.
    Data-driven decision-making in product teams has helped to evaluate the effectiveness of solutions, and adoption satisfaction. Product managers often use user research from the very early stages to evaluate products. By contrast, the data-driven process brings this evaluation to product conceptualisation.
    InfoQ's Data-Driven Decision-Making Series provides an overview of how the three main activities in the software delivery - product management, development and operations - can be supported by data-driven decision-making.

     

    Infoq
    https://bit.ly/3obrjHY