Jak v HP zkrotili šelmu vývoje software

Vývoj software v HP

Citace z knihy.

Jestliže existuje nějaká oblast, která může být považována za odolnou vůči jakékoli disciplíně, pak je to vývoj počítačového softwaru. Ve srovnání s tím, jak se na trh dostává většina softwaru, vypadají i ty nejvolněji nastavené vývojové postupy v jiných odvětvích jako přísně organizované.

Tvůrci softwarového vybavení jsou obecně považováni za kovboje a nespoutané živly (především se tak vidí oni sami). Možná oplývají skutečně velkým nadáním, ale pojmy jako disciplína či pravidla jim to­ho moc neříkají. Odjakživa vnímali svou práci spíše jako tvůrčí činnost a formu uměleckého vyjádření než jako něco podobného inženýrství.

Pojem chaos je ještě velmi mírným označením způsobu, jakým dříve vznikal nový software v příslušné divizi společnosti Hewlett-Packard. Spousta technických odborníků pracovala v naprosté izolaci a každý sle­do­val svou vlast­ní inspiraci. Často začínali s vytvářením nového programu ještě dříve, než byly přesně určeny potřebné specifikace. Jednotlivé vlastnosti byly přidávány nebo odebírány hlava nehlava. Životně důleži­té kroky, jako je například analýza potřeb zákazníků, se někdy udělaly a někdy ne, to záleželo na něčí náladě. I v případě, kdy se udělaly, to by­lo třeba až poté, co byl software víceméně hotov. Testování produktu po­chopitelně probíhalo na poslední chvíli a ve značném spěchu, jak se pro­gramátoři snažili dostat své výtvory co nejrychleji ven. Jen málokdy se spojí tolik nadaných lidí, aby dohromady vytvořili tak neschopnou sku­pinu.

Není divu, že nové softwarové produkty Hewlett-Packard přicházely pravidelně se zpožděním, překračovaly rozpočet a byly plné chyb. V po­lovině devadesátých let tehdejší generální ředitel Lewis Platt smutně od­hadoval, že 70 % všech závažných problémů, které se dostanou na jeho stůl, se týká softwaru.

Manažeři zjistili, že snažit se o řešení těchto problémů je jako snažit se dát dohromady stádo koček. Po nějaký čas se ředitelé divizí smiřovali s tímto zmatkem a  soudili, že prostě patří k povaze práce se softwarem. Ale pak se jednou, před několika lety vzbouřili. Rozhodli se, že vývoj softwaru nutně nemusí probíhat takto chaoticky. Takže vytvořili disciplinovaný proces a představili jej svým programátorům. Proces zahrnoval a propojoval všechny prvky vývoje softwaru, od jeho návrhu přes testování po standardizaci. Vyžadoval včasné určení požadavků zákazníků, vytváření časových plánů na základě analýzy a ne od oka, uskutečňování potřebných testů a ověřování ve správnou dobu, pečlivé sledování postupu práce a odhalování a  řešení nedostatků raději dříve než později. Nový proces byl řízen pevně daným systémem měření a zaručoval předvídatelnost a  opakovatelnost.

Aby prokázali své odhodlání prosadit disciplínu, vedoucí představitelé HP se dopustili softwarového kacířství. Ve světě softwaru vždy platilo, že na prvním místě stojí vlastnosti produktu - ty jej definují. v důsledku toho časové plány zásadně ustupovaly do pozadí - vlastnosti produktu byly prostě důležitější. a pokud jde o proces, žádný neexistoval. S tím byl náhle konec. Ve firmě Hewlett-Packard začala vláda procesů. Manažeři vysvětlili svým lidem, že proces má přednost před časovým plánem a časový plán má přednost před vlastnostmi produktu, které ostatně vyplynou z průběhu procesu samého. Dodržování nově nastavených procesů nebylo otázkou volby. Jak řekl svým lidem vedoucí soft­wa­ro­vé di­vi­ze: „Do­dr­žo­vá­ní pro­ce­su je pod­stat­nou po­lož­kou roz­ho­du­jí­cí o u­drže­ní va­še­ho pla­tu.“

Řád práci usnadňuje

Podle očekáváni byla taková opatření některými volnomyšlenkáři ze softwarové divize považována za návrat k montážním linkám z dob Henryho Forda, ne-li k pekelným podmínkám továren z dob průmyslové revoluce. Tvrdili, že je nový systém úplně zotročí, že na tom nebudou o nic lépe než dělníci ve dvacátých letech devatenáctého století. Tvůrci změn jim říkali pravý opak - že cílem není jejich kreativitu potlačovat, ale posílit. Díky dodržování strukturovaného procesu mohou svou kreativitu uplatit účinněji a v důležitějších oblastech. Jejich posláním je zaměřit kreativitu na produkt, ne na proces.

Protesty těchto volnomyšlenkářů vyjadřovaly obvyklé mylné představy. Možnost improvizovat a  vytvářet jedinečné pracovní postupy může vypadat jako svoboda, ale ve skutečnosti je to zátěž. Odsuzuje to lidi k neustálým zmatkům ohledně určování toho, kdo má vlastně co dělat a kdy. Nepřítomnost procesních struktur v podstatě kreativní práci podrývá. Oproti tomu disciplína a struktura kreativní energii usměrňují a uvolňují. Umožňují lidem, aby se soustředili na práci, kterou dělají nejlépe, místo aby se zabývali tím, jak by činnosti měly být organizovány.

Máte dost procesů?

Manažeři firmy HP mají hezkou metodu posuzování, jaká míra procesů je pro podnik nezbytná. Říkají, že procesů máte málo, pokud musí výjimeční lidé dělat obyčejné věci - pokud je třeba "hrdinských výkonů" k vykonání práce, která by měla být rutinou. Na druhé straně procesů máte příliš mnoho, pokud vaši výjimeční lidé nemohou občas udělat něco výjimečného - když se procesy stanou svěrací kazajkou, která lidi omezuje a svazuje. Je faktem, že mnohem více podniků trpí nedostatkem procesů spíše než jejich nadbytkem. Většina podniků pracuje spíše v podmínkách připomínajících chaos než pevný řád.

Firma HP byla za svou ochotu zkrotit divokou šelmu vývoje softwaru bohatě odměněna. Průměrná doba potřebná k uvedení nového softwarového produktu na trh poklesla o více než 50 %. Objem produkovaného softwaru (měřeno z hlediska objemu programátorské práce) poklesl o více než 10 %, protože se do něj už nezapracovávaly nepotřebné prvky. To jeho výrobu zlevňovalo a  zároveň snižovalo nároky na jeho údržbu. Software dnes vzniká za dodržování plánovaných rozpočtů a časových harmonogramů, což bylo dříve nemyslitelné a zároveň došlo k obrovskému zlepšení kvality ‑ počet závažných chyb softwaru HP spadl na nulu a toho všeho bylo dosaženo bez omezení autonomie a inovačního potenciálu pracovníků softwarové divize HP.

Je rozumné to zkusit

Pokud máte pocit, že máte podobný problém a domníváte se, že je možné s tím něco dělat nebo k tomu něco říci, ozvěte se! Resp. chtěli byste s tím něco dělat, máme zkušenosti z několika takovýchto firem a nutno říci, že to, co píše M. Hammer, není nijak přehnané.

Aktuálně za sebou mám diskusi o tom, jestli je nebo není účelné dávat úkoly ve vývoji software (výkonným/řadovým vývojářům) na několik týdnů… nebo jestli je lepší dát si tu práci a domluvit se na tom, co je doopravdy potřeba udělat. Nejenom u agilního přístupu se vyplatí sjednávat práci na jeden den (když to je možné - pokud je dobrá vůle, najde se způsob, jak práci rozdělit na kroky, které udrží vyvíjený systém provozuschopný při každodenní aktualizaci).

Což mi připomíná názor jednoho člověka z MS, který na konferenci věnované řízení projektů vývoje software prezentoval názor "... přece nemůžete po vedoucím projektu chtít, aby <se staral o to, co vývojáři dělají> ..." (citace není přesná, v ostrých závorkách je interpretace toho, co bylo myšleno... to je velmi ožehavé téma řízení projektů a role vedoucího projektu, neřku-li "kdo je kdo v agile").

Rádi vysvětlíme, jak je to myšleno a co se vlastně skrývá (může skrývat) pod pojmem "proces" (např. vývoje software, správy projektového portfolia nebo cokoli podobného). Navíc můžeme velmi efektivně pomoci vytvořit a rozvíjet proces projektového řízení či proces vývoje software včetně účasti na rozvoji jeho metodiky.

• Možná by stálo zato diskutovat o roli vedoucího projektu u vývoje software (resp. o tom, jestli je to projekt a jaké jsou vlastně role, jaké jsou jejich zájmy). Zjevně je tady téma "jak řídit vývoj software", jelikož spousta lidí na to má velmi rozdílné názory.
• V Agendě je pozornost zaměřena na podstatu uplatnění procesního přístupu, nezabývá se detaily - vychází celkem samozřejmě z toho, že procesní uspořádání (seskupit / organizovat a koordinovat činnost lidí se zřetelem na požadované výsledky) je výhodnější než jejich uspořádání na jakémkoli profesním či jiném principu. Navíc považuje za nesporné, že procesně musí být řízeny všechny činnosti, což znamená mít i pro aktivity projektového charakteru nadřazený proces (což je logické, protože jinak nedokážeme sdílet ani cíle, ani zdroje, ani další mechanismy). Projektově řízené činnosti prostě nemohou být "mimo" ostatní podnikové procesy (v případě skutečně procesního uspořádání), zatímco u funkčního přístupu je to právě naopak - aktivity projektového charakteru musí být z běžné organizační struktury vyčleněny.
• Určitě je nutné si přečíst "Dokonalý kód" nebo nějakou podobnou knihu.
• Bezpochyby je užitečné (kritické a nezbytné) mít pro vývoj software interní metodiku.
• Možná je potřeba položit si otázku, jestli se vývoj software řídí projektově ... nebo jestli je to proces. Třeba pomůže ilustrativní (silně zjednodušený) obrázek a případné komentáře možné podoby vývoje software.