Při psaní softwaru mnoho firem zaměstnává analytika, což je označení pro člověka, který má za úkol fungovat jako filtr mezi klientem a vývojářem a domýšlet software do konce. Protože analytik musí obhajovat svou práci a ukázat, že je prospěšný, píše na papír, jak má software fungovat. Tyto papíry se typicky odsouhlasí ještě před samotným psaním software, klient na ně dá štempl a začne se psát.

Vidím tady několik potíží:

• klient z analýzy nemusí pochopit, co nakonec dostane
• klient má při čtení analýzy strach, protože jí nerozumí, vzniká tak blok pro používání softwaru

• vývojář z analýzy nemusí pochopit, co se po něm chce
• vývojář je frustrován, co ten blbec analytik zase vymyslel

• analytik systém na papíru nevymyslí, to lze zjistit až při psaní softwaru
• analytik nemusí pochopit, co klient chce
• analytik nemusí pochopit, co vývojář umí naprogramovat
• analytik, fungující jako filtr přináší vždy informační šum a chyby, protože v podstatě jen zprostředkovává komunikaci mezi klientem a vývojářem
• analytik dává vývoji software lidskou tvář, vývojáři často neumí mluvit a klienti je berou jako zvířátka, kterým nerozumí

• analýza se musí v průběhu psaní aktualizovat
• analýza je po rozběhnutí softwaru mrtvá, protože je jednodušší podívat se přímo do systému
• analýza je drahá a špatně se sdílí, musí se verzovat, odsouhlasit, atd.
• analýza se používá jako štít pro softwarovou firmu v případě, že klient nedostane co chce (“ale vždyť jste to přece podepsal”).

• psaní analýz je vopruz
• čtení analýz je vopruz

Mnohem lepší je analytiky vyhodit a pustit vývojáře rovnou ke klientovi. V praxi je tohle jedna z největších překážek a velká zátěž pro obě strany. Vývojář se stydí, neumí mluvit, neumí si prosadit svůj názor a klient vůbec nechápe, proč se má s těmito zvířátky bavit.

Pokud však budeme trpěliví a vytrváme na pravidelném kontaktu, náš software bude lepší:

• vývojář nejlépe ví, co umí napsat a co je blbost, klienta tak usměrní
• vývojář dokáže nejlíp zhodnotit, kolik mu to zabere času
• vývojář se na systém bude dívat z pohledu klienta, tohle je naprosto zásadní pro pochopení, proč software vůbec píše
• vývojář přijme odpovědnost za vývoj softwaru a nemůže se vymlouvat na špatnou analýzu
• vývojář se naučí prezentovat svou práci
• vývojář se socializuje
• vývojář pochopí, že klient je také jen člověk a má právo na chyby

• klient pochopí, co lze napsat a co je blbost
• klient se na systém podívá z pohledu vývojáře, což po něm vyžaduje jistou technickou investici do svého vzdělání, která se mu ale dlouhodobě jen vyplatí
• klient osobně vysvětlí vývojářům, proč je software pro jeho business důležitý, tím si také pravidelně uspořádá priority a provádí na sobě sebereflexi
• klient pochopí, že vývojář je také jen člověk a má právo na chyby

Setkání klientů s vývojáři je samozřejmě nutné dělat pravidelně. Doporučuji týdenní iterace. Na každé schůzce vývojář prezentuje svou práci za poslední týden, klient určí priority pro další týden, opraví a zkoriguje možné odchylky při vývoji a má dobrý pocit z toho, jak práce hezky pokračuje. Nejhorší, co se může stát, je 1 ztracený týden práce. Což je v porovnání s chybně napsanou analýzou a dlouhým vývojem v řádu měsíců, kdy nakonec klient dostane něco, co vůbec nechtěl, dobrá daň.

A analytik může dělat něco užitečnějšího. Třeba se učit programovat nebo měnit svět jinak.