V engineering managementu je mou vizí vytvořit produktivní software delivery prostředí, na které jsou vývojáři hrdí, s důrazem na hmatatelné výstupy napříč firmou.

Je to systém se správnými guidelines a správnou úrovní automatizace, aby standardní vývojová práce běžela plynule. Proto jsme v engineering oddělení implementovali real-time team health boards. Vrátilo nám to drahocenný čas na fokus na systematické zlepšování procesů.

Ke splnění takových ambicí standardní sada předdefinovaných metodologií (například Scrum) a ticketing systém out-of-the-box nestačí.

Měřte to, na čem nejvíc záleží: Focus na roadmapu

Problém, se kterým zápasím nejvíc, je mezera mezi software development ticketing nástroji a product management řešeními.

Přes engineering ticketing aplikace nám tvrdí, že top efektivnostními faktory jsou lead time, throughput a jejich deriváty. Zdá se mi, že tento typ defaultních indikátorů odklání software firmy od měření toho, na čem záleží nejvíc: focusu na výsledek, reprezentovaného roadmapou. Ostatní metriky jsou sekundární. V praxi nízký lead time a vysoký throughput nebudují důvěru, když se roadmapa zpožďuje.

Indikátory Health Boardu

K vizualizaci engineering výstupů a udržení focusu jsme se rozhodli implementovat plně transparentní health board s následujícími insighty:

Mews Software Development Health board, aplikovatelný na celé oddělení nebo filtrovaný na konkrétní týmy

1. Jaký je náš roadmap contribution % za posledních 30 dní? Plánujeme dobře? Naše očekávané guardrails jsou v rozmezí 50 %–70 %, v závislosti na fázi životního cyklu produktu. Typicky startupové produkty mají vyšší roadmap focus kvůli nízkému objemu supportu a maintenance práce.
2. Jakou distribuci typů práce týmy mají — bugy, cleanup, support, investigace? Jaká práce brání týmu přispívat do roadmapy? Kolik investujeme do tech dluhu / konsolidace? K mitigaci tech dluhu a potenciálních bugů investujeme do features a konsolidace v poměru 2:1.

Rovnováha Features a Tech Roadmap

3. Jaký je status roadmapy? Na kolika různých iniciativách (epics) tým paralelně pracuje? Aby se výrazně snížily náklady context-switchingu, držíme počet paralelních hlavních iniciativ na 1 nebo 2, v závislosti na velikosti týmu.

Roadmap Epics — Execution status

4. Kolik investujeme do kterých produktů? Takové insighty nám umožňují správně řídit naši pracovní sílu.

Timeline investic do produktů

Po tom, co byly správně zodpovězeny výše uvedené otázky, jsme rozšířili naše health boardy o standardní indikátory jako throughput, lead a cycle time, výskyt ad-hocs a long-lasting outlierů, frekvence pull-requestů a délka code review.

Nad rámec metrik jsme na cestě k implementaci notifikací, když se situace vymyká (long-lasting ticket stages, blížící se deadliny, návrhy vhodné pro sprint planning, eliminace waste). V podstatě je naším cílem mitigovat firefighting situace, které jsou typicky obtížné a časově náročné na řešení.

Vybudujte Real-Time Health Boardy za 3 měsíce

Data flow architektura

Ve zkratce: jednoduchá node.js služba extrahuje všechna ticketing data a příslušné changelogy z YouTrack přes REST API volání. Výstup je pak nahrán ve formě csv souboru do Azure Storage. Dále data factory obohacuje atributy (ticket fields) o odpovídající datové typy a vytváří datový tabulkový model na základě naší ticketing hierarchie. V Power BI Desktop jsme schopni designovat požadované reporty a publikovat je do Power BI Cloud. Ve výsledku jsou všechny dashboardy automaticky obnovovány a dostupné na webu nebo přes mobilní aplikaci.

Boardy jsme implementovali end-to-end v následujících krocích:

Krok 1: Vytvořte ticketing strukturu

Hierarchie tiketů

Interně jsme se rozhodli reprezentovat produktové roadmap iniciativy v hierarchické formě topics, epics, tasks a subtasks — přímo v ticketing systému. Pro tento účel jsme díky rychlému change managementu upravili ticketing strukturu v YouTrack během měsíce. Alternativou je mít existující integraci s některým z product management řešení.

Krok 2: Extrahujte data

Další fází bylo strávit měsíc implementací malé node.js služby zodpovědné za extrakci real-time ticketing informací a následné krmení analytics data pipelines. Dobrou zprávou je, že většina ticketing řešení nabízí spolehlivý přístup k datům přes REST API, včetně historie změn.

Krok 3: Použijte správný reporting nástroj

Dnes jsou analytics nástroje (jako Power BI nebo Tableau ) celkem uživatelsky přátelské a snadno použitelné, jakmile člověk pochopí jejich principy a jak strávit a vizualizovat data, která poskytují, v nejlepší možné formě. Bylo mimořádně užitečné začít sbírat znalosti hned na Power BI Desktop video kanále a PowerBI.tips. Takže jsme měli dashboardy funkční za měsíc, díky lidem se software development background.

Praktické výstupy

Přiznávám, že jsme stále na začátku naší mise, i když je výstup hmatatelný. Inženýři a produkt manažeři si vyžádali vylepšení reportů různými způsoby, spolu s dalšími úpravami struktury tiketů. Učíme se používat reporty denně a důvěřovat datům. Pevně věřím, že čisté datové insighty výrazně zvyšují pravděpodobnost investování do správných zlepšení a dělání správných rozhodnutí.

V praxi nám engineering health boardy a reporty pomohly mnoha způsoby:

• Ujistili jsme se, že plánujeme sprinty podle očekávání, s hlavním fokusem na roadmap contribution a eliminujeme ostatní typy práce.
• Nasadili jsme strop na počet high-level iniciativ, na kterých může tým paralelně pracovat.
• Snížili jsme neplánované ad-hocs, které narušovaly vývojový proces.

Nejdůležitější je, že software engineering je vnímán jako vysoce transparentní. Každý ve firmě má přístup k health boardu vývojového týmu, progresu roadmapy a produktovým investicím — což vytváří důvěru.

Naučené lekce

Stakeholdeři říkali, na základě zpoždění features, že „Inženýři neumí odhadovat“. Jako software manažer jste žádán, ať „dělejte lepší odhady”. V praxi jsem se naučil, že odhady nejsou jádrem problému.

https://cdn.embedly.com/widgets/media.html?src=https%3A%2F%2Fgiphy.com%2Fembed%2FR7m04yMaGWVeE%2Ftwitter%2Fiframe&display\_name=Giphy&url=https%3A%2F%2Fmedia.giphy.com%2Fmedia%2FR7m04yMaGWVeE%2Fgiphy.gif&image=https%3A%2F%2Fi.giphy.com%2Fmedia%2FR7m04yMaGWVeE%2Fgiphy.gif&key=a19fcc184b9711e1b4764040d3dc5c07&type=text%2Fhtml&schema=giphy

1. Soustřeďte se na roadmap contribution, aby týmy uspěly. Defaultní metriky ticketing nástrojů jsou sekundární.
2. Vyčistěte systém. Měřte různé typy práce, na kterých týmy pracují. Vyčistěte masivní backlogy. Snižte context-switching a výskyt ad-hocs. Zajistěte, aby si inženýři udrželi fokus.
3. Jako agent změny — pokud se rozhodnete posunout strukturu firemního ticketing systému, požádejte o mandát, abyste se vyhnuli potenciálním push-backům.
4. Aby byly reporty spolehlivé, počítejte s tím, že investujete další měsíc do data cleanupu.
5. Když budujete transparentní dashboardy, připravte se vysvětlovat proč a kde to pomůže. Transparentnost není k tomu, aby někoho šikanovala — je tu, aby dělala správná zlepšení a předcházela firefighting situacím.
6. Vyhněte se reportům porovnávajícím jednotlivce.
7. Neusilujte o vybudování dokonalého vývojového procesu. Místo toho vytvořte systém, který zvládne 80 % problémů plynule ve flow. Veďte příkladem a učte ostatní, jak řešit zbytek on demand.

Dlouho jsem hledal správný styl managementu, který by seděl většině inženýrů. Prošel jsem hromadu knih nabízejících různé strategie.

Jednoduše řečeno, závěr, ke kterému jsem došel, je, že datový insight kombinovaný s empatií je neporazitelný způsob, jak nejlépe řídit jak vývojáře, tak dodávku features.