Mou profesí je vývoj zákaznického software. Zákazník má problém a jeho řešením je software – nástroj, který mu pomůže. Jde o složité systémy, jejichž vývoj trvá měsíce až roky a podílí se na nich desítky lidí. Má role je zpravidla zastřešit vývoj, navrhnout a realizovat část systému. Má práce končí úspěšným nasazením do produkce. Vývojem software se profesionálně zabývám více než 15 let. Při vývoji vždy docházelo k problémům, ke kterým člověk profesionálně přistoupil a řešil je. Co mě trápí je povaha zvětšující se části problémů. Dá se říci, že jsou to problémy, co si způsobujeme sami.
Svou pracovní kariéru rozděluji na 3 období. Období první je spojeno s razantním nástupem informačních technologií do zaostalého prostředí, jakým náš region byl. Vyrostl jsem na osmibitech, pak jsem přesvědčil rodiče o potřebě mít doma PC a brzy zjistil, že z pokusů s technologiemi se dá udělat byznys. V té době jsem dělal všechno, hardware, sítě i software včetně vývoje. Vývoj se mi líbil nejvíce a dostal jsem se do malé softwarové firmy. Zákazníkovi jsme často pomohli s dodávkou hardware, zřízením sítě, výběrem software (Novell Netware + MS DOS na klientech a pár krabic s dalšími sw produkty, později prostředí Windows a SQL databáze) a jeho speciální potřeby jsme řešili dodáním vlastního software. Mluvili jsme přímo s budoucími uživateli, zjistili, co je nejvíce trápí a navrhli, co dodáme. Výstupem byly jednoduché specifikace, samozřejmostí pravidelné navštěvování uživatelů a ukázky/dodávky průběžně vyvíjeného software. Uživatelé často software od prvních dodávek prototypů už používali a my postupně přidávali další a další funkčnosti. Jeden program vyvíjelo jen pár lidí a ti dělali všechno, chodili za klientem, vymýšleli a programovali, testovali a nakonec ještě pár let opravovali chyby. V této skupince fungoval princip mistr a žák, často už tehdy na principech Extreme Programmingu. Fungovala zastupitelnost, problémy se řešily napřímo (a často navíc přímo u zákazníka, nainstalované vývojové prostředí u zákazníka bylo běžné …) a rychle. Pokud už měl zákazník IT oddělení, šlo zpravidla o správce sítě a díky jejich plné důvěře v nás nám nekladli žádné byrokratické pasti. Většina členů softwarové firmy se přímo podílela na dodávkách zákazníkovi a práce byla velice efektivní.
Období druhé přišlo s nástupem Internetu. Je třeba si uvědomit, že to nebyl soukromý sektor, kdo s Internetem přišel. Soukromý sektor zde nebyl zrovna motor vývoje. Zájem o Internet přišel až v okamžiku, kdy se začal dramaticky zvedat počet uživatelů, kteří byli zároveň klienty soukromého subjektu (třeba banky). Banky lákaly úspory, které jim nový elektronický kanál dokáže zajistit, a objevili se klienti, kteří takovou službu vyžadovali. Nastala velká poptávka po webových aplikacích ze strany představitelů byznysu i uživatelů Internetu. Dodávka nové webové aplikace často znamenala zásadní změny v IT společnosti, kde třeba bankovní systémy fungovaly z pohledu IT na prehistorických technologiích. Výsledkem byl velký boom pro softwarové firmy schopné dodávat potřebná řešení. Šlo o velké dodávky, vývoj probíhal v mnoha projektech a já na tyto projekty ve velmi dobrém vzpomínám. Snad silou zvyku ještě stále platilo, že vývojový tým byl v blízkém styku s byznysem zákazníka, byznys měl představy a vývojáři navrhovali nástin řešení od stolu. Často už pár hodin po poradě s byznysem začali vývojáři software tvořit či měnit, všichni věděli, co mají dělat. Komunikační šum byl nízký a dodávalo se, co se dohodlo. Vzpomínám si na kreativitu, kterou někteří vývojáři předváděli (vymysleli, v krátkém času vykomunikovali se spokojeným zákazníkem a často třeba i po večerech dobrovolně do software přidali). Kreativita, to je možná to, proč tehdy bylo slovo challenge – výzva bráno celkem pozitivně. Zúčastnění to často brali jako hru. Radostí bylo sledovat, jak se lidé učili nové technologie, zkoumali, zkoušeli nová řešení. Tlak na termíny ještě tehdy nebyl tak silný, byl dostatek času software vyladit jak z pohledu chybovosti tak rychlosti. Vývojáři nečekali, až jim o chybách někdo řekne a nastaví priority, odladění byla samozřejmost už během vývoje a úročily se zde zkušenosti, schopnosti a motivace členů vývojového týmu. Ti věděli, co od software zákazník chce, pamatovali si i důraz, jaký na jednotlivé funkčnosti lidi za byznys na poradě kladli. Fungovaly principy osobní zodpovědnosti, čemuž odpovídala kvalita vývoje. Dnes už s úsměvem vzpomínám, jak jsme tehdy byli schopni do banky dodat novou verzi a dostat jí do produkce ještě ten samý den. Výsledkem byl kvalitní software a spokojený zákazník.
Poslední období už prožívám poměrně dlouho a problémy, se kterými se setkávám, mi radost nedělají. Zcela zásadní problém vidím ve virtuálním světě, v jakém tým vyvíjející software pracuje. V období prvním vývojáři chodili za uživateli osobně, v období druhém chodili alespoň na občasné porady s byznysem. Nyní se často setkávám s tím, že člen vývojového týmu v životě člověka z byznysu neviděl. Nemá ani představu o uživatelích. Informace o tom, co má tvořit dostává v podobě podrobné funkční specifikace či modelu. Hodně záleží na tom, kdo tyto vstupy připravil. Mohl to být zkušený architekt designér, který byl v pravidelném kontaktu s byznysem a nyní je součástí vývojového týmu. Mohl to ale také být někdo cizí. Nejhorší případ je, pokud je tvořil netechnický člověk, typicky analytik, který se na místo popisu toho, co je třeba zabýval návrhem řešení bez elementárních znalostí vývoje softwaru. V každém případě je zde velký prostor pro nepochopení toho, co je třeba a ztrátu kontextu. Dalším neštěstím je plánování, kdy se mnoho měsíců software tvoří bez kontaktu se zákazníkem. Vývojáři si vzájemně vybudují falešnou představu o tom, co má software dělat, pokud vůbec nějak mají! V době složitých distribuovaných systémů jsou realitou vývojáři tvořící něco, o čem vůbec netuší, k čemu a jak bude použito. Není nad to se pak bavit s někým, kdo jako správný představitel špionážní buňky zná pouze, kdo po něm software chtěl a koho jiného software používá. Vývoj v takovém prostředí nepovažuji ani za příliš výchovný. Dříve se mnoho lidí v takovém prostředí dokázalo rychle vypracovat ve schopné kreativní architekty a manažery schopné řešit jakýkoliv problém. Dokázali zúročit nejen své zkušenosti se samotným kódováním, ale také komplexním řešením problémů. Nyní je tato výchova výrazně utlumená. Navíc se zákazníkem členové týmu nepřichází do kontaktu ani na druhém konci. Stalo se zvykem, že řádné odladění software se naplánuje na konec vývoje a pak na něj nezbude čas. Já vím, jsou zde přece unit testy. Ano, ale ty co často vidím bohužel jen alibisticky testují programový kód se znalostmi pouze virtuálního světa. Aplikace se předávají buď internímu testovacímu týmu, nebo testování zákazníka. V obou případech testuje software někdo, kdo má jinou představu o tom, co má software dělat, ať už je to představa virtuální nebo je alespoň testovací tým v úzkém styku s byznysem zákazníka. Opravují se chyby, na které by vývojář při řádném ladění přišel sám (typicky technické chyby nebo mizerný výkon při větším množství dat, nedostupnosti jiného software apd.). Logickým důsledkem je hlášení chyb, které vývojový tým okamžitě považuje za změnové požadavky – protože přeci odporují vytvořené virtuální představě. Z oprav se stává bezmyšlenkovité kolečko stovek až tisíců záplat. Výsledkem je nekvalitní software odlišný od představy zákazníka.
Nespokojený je i tým vývojářů software. Někteří přijdou na to, že se takto mnoho nenaučí a posunují se na jiné pozice. Bohužel už nemají tak kvalitní základ, jako měli zkušení vývojáři dříve, což bude mít dopad na kvalitu IT architektů a manažerů obecně. Jiní mění projekty či firmy, často pracují demotivovaní a snad čekají na lepší dobu. Podobnou zkušenost mám nejen se zákaznickým softwarem, ale i vývojem sw produktů. Samostatnou kapitolou je offshoring (a nearshoring), kde jsou popsané principy neměnitelnou vlastností a je třeba s nimi počítat. Vývoj zákaznického software jsem vždy považoval za kreativní řemeslo. Trend degradující vývoj na výrobu v továrně se mi nelíbí. Kvalitní zákaznický software nemůže tvořit někdo, kdo bezmyšlenkovitě kóduje bez širších znalostí.
