熟悉linux开发环境
The Data, Solutions & Analytics (DSnA) team supports business teams within T-Mobile’s Procurement & Network Supply Chain (P&NSC) and Regional Network Engineering & Operations (RNE&O) organizations. These teams are responsible for billions of dollars in spend, thousands of units of material flow through the supply chain and thousands of successful network development projects executed every year. Organizations of such impact need critical, timely and reliable analytic insights to support business decisions. DSnA has transformed itself into a hybrid technology team with full stack development capabilities; from data engineering to software development to data science and analytics development. Centralized data across hundreds of sources is the foundation of our value proposition.
数据，解决方案和分析(DSnA)团队为T-Mobile的采购和网络供应链(P＆NSC)和区域网络工程与运营(RNE＆O)组织中的业务团队提供支持。 这些团队负责数十亿美元的开支，数千个单位的物料流经供应链以及每年执行的数千个成功的网络开发项目。 具有这种影响的组织需要关键，及时和可靠的分析见解，以支持业务决策。 DSnA已将自己转变为具有完整堆栈开发功能的混合技术团队 。 从数据工程到软件开发再到数据科学和分析开发。 跨数百个来源的集中数据是我们价值主张的基础。
‘Analytics Development’ is the process used to create and refine business intelligence (BI) and advance analytics (machine learning & AI) products and solutions that support our functional teams. These activities are inherently business context specific. Unlike typical software development, analytics development requires engineers to have deep business process and logic understanding. DSnA has created a familiar but ‘new’ way of organizing our teams for effective and impactful analytics delivery.
“分析开发”是用于创建和完善支持公司职能团队的商业智能(BI)和高级分析(机器学习和AI)产品和解决方案的过程。 这些活动本质上是特定于业务环境的。 与典型的软件开发不同，分析开发要求工程师对业务流程和逻辑有深入的了解。 DSnA创建了一种熟悉的“新”方式来组织我们的团队，以进行有效而有影响力的分析交付。
Before we get into more details, let’s look at some reasons for this shift first.
在开始更多细节之前，让我们先来看一下这种转变的一些原因。
Vertically aligned (to business teams) analytics teams often find it difficult to eliminate redundancy and overlap, with similar products and functionality being developed across multiple teams.
与业务团队垂直对齐的分析团队经常发现很难消除冗余和重叠，因为跨多个团队开发相似的产品和功能。
Engineering managers end up wearing more hats than should be acceptable for efficient delivery — for example, she has to manage the external stakeholders, hash out requirements, manage engineers and development activities, manage internal and external communications, enhance technical capabilities of her team, sustain existing products and manage delivery.
工程经理最终戴的帽子多于有效交付所需的帽子 ，例如，她必须管理外部利益相关者，制定要求，管理工程师和开发活动，管理内部和外部沟通，增强团队的技术能力，维持现有产品并管理交付。
Frequent external facing activities like meetings, brainstorming sessions, stakeholder walk-by and ad-hoc requests provide disruptive distraction to our engineers
频繁的外部面对活动，例如会议，集思广益会议，利益相关者旁听和临时请求，给我们的工程师带来破坏性的干扰
Technical competencies and best practices are hard to maintain across engineering teams that reside within the business unit.
在业务部门中的各个工程团队之间很难保持技术能力和最佳实践 。
技术团队的结构 (Structure of Our Technology Team)
There are multiple ways to organize a technology team and DSnA choose to adapt a ‘Federated or Hybrid’ model. In this model, DSnA has different engineering teams organized by competencies with a product team providing focus and alignment. Business units retain a team of analysts responsible for operational analytics. DSnA focuses on foundational high impact things like centralizing data, harvesting business logic to the core data model and building advanced analytics and solutions. The team’s goal centers around analytic enablement, knowing that insights will be most efficiently developed within the business unit
组织技术团队的方式有多种，DSnA选择采用“联合或混合”模型。 在此模型中，DSnA具有按胜任力组织的不同工程团队，而产品团队则提供重点和一致性。 业务部门拥有一支负责运营分析的分析师团队。 DSnA专注于基础的高影响力事物，例如集中数据，将业务逻辑收集到核心数据模型以及构建高级分析和解决方案。 团队的目标围绕分析支持 ，知道在业务部门内将最有效地开发见解。
Traditionally, product management is highly efficient in the software solutions space. We applied this model to any development work happening in DSnA, be it software, analytics & BI, data science or data engineering — product team provides the vision and focus of investments; engineering teams execute on the strategy to provide our BUs the solutions they need for data driven business decisions.
传统上，产品管理在软件解决方案领域非常高效。 我们将此模型应用于DSnA中发生的任何开发工作，无论是软件，分析和BI，数据科学还是数据工程。产品团队提供了投资的愿景和重点； 工程团队执行该策略，以向我们的业务部门提供他们所需的解决方案，以进行数据驱动的业务决策。
分析开发执行框架 (Execution Framework for Analytics Development)
There are two key components of our execution framework:
我们的执行框架有两个关键组成部分：
Analytics Delivery Team Supported by the Product Team
产品团队支持的Google Analytics(分析)交付团队
- The product team provides the product vision and road-map to the Engineering (or delivery) team. Technical Product Managers (TPM) maintain close relationships with BU stakeholders (analysts and others), understand their pain points, have an eye on BU’s maturity for data driven decision making. These insights, coupled with the strategy provided by senior leadership, determine the right investment areas for DSnA’s resources. Each TPM supports a BU and maintains a rolling 12 months road-map including new and existing products (these could be web Apps, reports, dashboards, data products etc.). 产品团队向工程(或交付)团队提供产品愿景和路线图。 技术产品经理(TPM)与BU利益相关者(分析师和其他人员)保持密切关系，了解他们的痛点，关注BU在数据驱动决策方面的成熟度。 这些见解与高级领导层提供的策略一起，为DSnA资源确定了正确的投资领域。 每个TPM支持一个业务部门，并保持12个月的滚动路线图，包括新产品和现有产品(这些产品可能是Web Apps，报告，仪表板，数据产品等)。
- TPMs are supported by Functional Analysts (FA) who are also aligned to a BU. FAs understand the business process, including the systems used for day to day operations. They are critical in translating business requirements into meaningful work for our engineering teams. TPM得到功能分析师(FA)的支持，他们也与BU保持一致。 财务经理了解业务流程，包括用于日常运营的系统。 对于将业务需求转化为对我们的工程团队有意义的工作而言，它们至关重要。
- Engineers, with support from the Engineering Manager, execute against the road-map. They are critical to the quality and sustainability of the products we create. Engineering Managers ensure high technical standards and best practices within their teams. 工程师在工程经理的支持下，按照路线图执行。 它们对于我们创造的产品的质量和可持续性至关重要。 工程经理确保团队中的高技术标准和最佳实践。
2. Analytics Delivery Accelerated by Agile
2.通过敏捷加速分析交付
- The development of the analytics products is done via agile. 2-week sprints with typical agile events like grooming and planning sessions (led by TPMs), daily stand ups (led by engineers) and retrospective (led by the Engineering team) help facilitate execution on the road-map. 分析产品的开发是通过敏捷完成的。 为期两周的冲刺包括典型的敏捷事件，例如修饰和计划会议(由TPM领导)，每日站起来(由工程师领导)和回顾(由工程团队领导)，有助于促进路线图的执行。
- This framework is not atypical in the software development world but developing analytics (for example, Power BI dashboards, Analytics Web Apps and ML models) in this framework is unique. Analytics work is iterative by nature, and this agile framework really helps organize the delivery and provide focus to Analytics Engineers. 该框架在软件开发领域不是典型的，但是在此框架中开发分析(例如Power BI仪表板，Analytics Web Apps和ML模型)是独一无二的。 Analytics(分析)的工作本质上是迭代的，并且这种敏捷的框架确实有助于组织交付并为Analytics(分析)工程师提供重点。
Here’s how the relationships play out across different roles in this framework:
在此框架中，不同角色之间的关系如何发挥作用：
The size of the edge between nodes shows the magnitude of engagement and edges are bi-directional. It could be viewed as relationship magnitude of 1 (thin edge) — stay connected & keep informed, 5 (medium width edge) — periodic touch points, and 10 (thick edge) — frequent touch points and work closely together. The following matrix further expands on this map.
节点之间的边缘大小显示了接合的大小，并且边缘是双向的。 可以将其视为1(薄边缘)(保持连接并保持了解状态)，5(中宽度边缘)(周期性接触点)和10(厚边缘)(频繁接触点)之间的关系强度并密切合作。 以下矩阵在此地图上进一步扩展。
主要好处 (Key Benefits)
Everything Thing Goes Through the Product Lens
一切都通过产品镜头
Product Manager is the primary point of contact for stakeholder engagements creating a simple customer experience that supports the long-term growth of the team. They drive prioritization for development activities through a high-level road-map translated into tactical user stories. This ensures minimal redundancy within the technical team and analytic work that follows a coherent narrative for each vertical. Every request doesn’t end up as a new dashboard and the team understands why this work is important before development commences. This product focus ensures that we go after the right problems, create meaningful solutions and keep those solutions relevant as business process changes.
产品经理是利益相关者参与的主要联系点，可创建简单的客户体验以支持团队的长期发展。 它们通过翻译成战术用户故事的高级路线图，为开发活动确定了优先级。 这样可以确保技术团队和分析工作的冗余度最小，这些工作遵循每个垂直领域的一致叙述。 并不是每个请求都以新的仪表板结束，并且团队在开发开始之前就理解了这项工作为什么很重要的原因。 以产品为中心的重点是确保我们追寻正确的问题，创建有意义的解决方案，并随着业务流程的变化使这些解决方案保持相关性。
Alignment with Other Products
与其他产品的对接
Another key benefit of a Product Manager is the visibility they have across all existing and in-development products within the team. She can collaborate with other product managers to ensure the right home for a business problem (whichever product it resides in; not necessarily in her own products). For example, if a BI Development team is aligned with a vertical, every request will end up in a report or dashboard. A product team facilitating the engagement ensures that the right solution is considered, regardless of past technical work. BU stakeholders, at the end of the day, do not care how their problems are solved, they care for results.
产品经理的另一个主要好处是，他们可以看到团队中所有现有和开发中的产品。 她可以与其他产品经理合作，以确保业务问题的正确归宿(无论驻留在哪个产品中；不一定在她自己的产品中)。 例如，如果BI开发团队与垂直团队保持一致，则每个请求都将最终出现在报告或仪表板中。 不管过去的技术工作如何，促进参与的产品团队都可以确保考虑正确的解决方案。 BU的利益相关者最终不会在乎问题如何解决，而是在乎结果。
Engineering Manager’s Responsibilities
工程经理的职责
This framework frees the Engineering Manager from a range of external facing responsibilities and allows her to focus on the development process and quality of delivery. Managing requirements gathering, external and internal communications, development process, product quality and people management responsibilities is daunting and not scalable as the team grows.
该框架使工程经理摆脱了一系列外部责任，使她能够专注于开发过程和交付质量。 随着团队的成长，管理需求收集，外部和内部沟通，开发过程，产品质量以及人员管理职责是艰巨的，并且无法扩展。
Engineer’s Enhanced Focus
工程师的重点关注
Anyone who has been an engineer or has worked with one knows that development activities require undistracted focus. In a vertically aligned Engineering team, being part of the full cycle of activities takes up a lot of an engineer’s time. Our model puts the ‘problem definition’ responsibility on the product & analysis team and when the tasks come to the engineer, they are refined, and allowing her to focus on innovative ways to solve the problem at hand.
任何曾经担任过工程师或与之一起工作过的人都知道，开发活动需要专心致志。 在垂直排列的工程团队中，参与整个活动周期需要占用大量工程师的时间。 我们的模型将“问题定义”责任推给了产品和分析团队，并且当任务交给工程师时，它们就得到了完善，并使她能够专注于创新方法来解决眼前的问题。
示例—采购分析多维数据集 (Example — Procurement Analytics Cube)
The best way to explain this model of analytics development is with an example. Spend, as with any Procurement organization, is foundational for sourcing, negotiation & category strategy work. In early 2019, state of our solution for spend analytics was bound within the confines of the eSourcing & Procurement-to-Pay (P2P) tool. Accessing spend reports (no visualizations, only raw data), was not intuitive. Once found in the tool, building the needed report was ‘mission impossible’. Data was loaded into this tool on a monthly basis manually using files downloaded from our ERP system (you heard that right — manual, file based and monthly refresh). For an organization managing billions of dollars in spend, this was not a workable solution.
解释此分析开发模型的最佳方法是一个示例。 与任何采购组织一样，支出是采购，谈判和类别策略工作的基础。 在2019年初，我们的支出分析解决方案现状受到eSourcing和采购到付款(P2P)工具的限制。 访问支出报告(没有可视化，只有原始数据)并不直观。 一旦在工具中找到，构建所需的报告就“不可能完成”。 使用从我们的ERP系统下载的文件，每月手动将数据加载到此工具中(您没听错-手动，基于文件和每月刷新)。 对于管理数十亿美元支出的组织而言，这不是可行的解决方案。
An immediate response to this solution might have been to build a few pipelines that land this spend data in the data warehouse, throw a pretty Power BI dashboard on top and call it done! We did not limit ourselves in that way. The Product Manager was able to peel the layers of the problem and understand that dashboards will only answer first few layers of business questions even though Sourcing Managers had frequent need to build their own analysis and access transactional data. Furthermore, the raw spend data was missing some key attributes like spend categorization and supplier master normalization (multiple legit records for same supplier). Without these enrichments, the impact of making this data available would not be complete.
对该解决方案的直接响应可能是建立了一些管道，以将这些花费数据存储在数据仓库中，在其上方放置漂亮的Power BI仪表板，然后将其完成！ 我们并没有以此方式限制自己。 即使采购经理经常需要建立自己的分析和访问交易数据，产品经理仍能够解决问题的各个方面，并了解仪表板只会回答业务问题的前几层。 此外，原始支出数据缺少一些关键属性，例如支出分类和供应商主数据规范化(同一供应商的多个合法记录)。 没有这些丰富的内容，提供这些数据的影响将是不完整的。
- After a year of product management and innovative development, our current spend solution looks much different: We have automated daily data extracts. A huge improvement from the manual monthly extracts of the past. 经过一年的产品管理和创新开发，我们当前的支出解决方案看起来大不相同：我们具有自动化的每日数据提取。 与过去的每月手动摘要相比有了很大的改进。
- The data engineers have leveraged a full domain model built a tabular format in Azure Analysis Service with all enrichments and key metrics baked in. This serves as the backbone of the self-service solution we offer our end users. 数据工程师利用了Azure分析服务中构建的表格格式的完整域模型，并纳入了所有扩展功能和关键指标。这是我们为最终用户提供的自助服务解决方案的基础。
- A couple of Power BI dashboards provide answers to key business questions in under 5 clicks. 只需不到5次点击，几个Power BI仪表板就可以回答关键业务问题。
- Our data science team built models to classify spend transactions and normalize supplier names. This aligns our output with long-term procurement category strategy. And we’re actively building an automated way of collecting feedback on our models to better train them over time. 我们的数据科学团队构建了模型来对支出交易进行分类并规范供应商名称。 这使我们的产出与长期采购类别策略保持一致。 我们正在积极构建一种自动收集模型反馈的方式，以便随着时间的推移更好地训练它们。
- A 3rd party self-service solution is currently being implemented to leverage Natural Language Query and let users ask any question from the spend data while at the same time, extract any transactional data they need. 当前正在实施第三方自助服务解决方案，以利用自然语言查询，并让用户从支出数据中提出任何问题，同时提取所需的任何交易数据。
- To bring it all together, the Power BI dashboards, Web Apps and Self-Service Solution will all be embedded within an existing Procurement Web App that already provides a lot of procurement insights in a single place. 为了将所有功能整合在一起，Power BI仪表板，Web应用程序和自助服务解决方案都将被嵌入到现有的Procurement Web App中，该Web应用程序已经在一个地方提供了很多采购见解。
This solution is miles away from what a single Analytics Team aligned directly to the BU might have been able to achieve. It exemplifies the strengths of all technical teams in DSnA (data engineering, data science and BI) and a product vision that not only solves the immediate business problems but takes it to the next level.
该解决方案与直接与业务部门结盟的单个Google Analytics(分析)团队可能实现的目标相距甚远。 它体现了DSnA中所有技术团队(数据工程，数据科学和BI)的实力，以及可以不仅解决眼前的业务问题而且将其提升到更高水平的产品愿景。
翻译自: https://medium.com/tmobile-dsna/a-familiar-but-new-way-of-analytics-development-e0594d4109e9
熟悉linux开发环境