Corporate vs. SME - čím se mohou navzájem inspirovat

Napsat blog o rozdílech práce pro korporát nebo segment SME (dejme tomu „malé a střední podniky“) je asi tak užitečné, jako psát, nebo ještě lépe graficky znázorňovat, rozdíl mezi šéfem a lídrem. To téma je dávno vytěžené a navíc nikdy nepatřilo mezi bůhvíjak přínosné vzhledem k tomu, že základní logiku dokáže rozpoznat i selský rozum a více toho nabídnout moc nedokáže.

Proč o tom teda píše? Ptáte se.

Protože procesy. A protože vztah mezi businessem a IT.

Není to totiž o tom, jestli je lepší sedět v malém kanclíku s kolegyněmi z marketingu nebo ve velkém openspacu s dalšími třemi týmy. A už vůbec to není o tom, jestli a kolik dostanete stravenek nebo zda si jednou za měsíc můžete pátek odpracovat v pyžamu z postele. A už vůbec vůbec to není o tom, že někde najdete lepší šéfy/kolegy nebo jestli se někde dokážete lépe „schovat“ a předstírat práci. Tyhle přednosti a zápory nechť si každý zhodnotí sám dle svých osobních preferencí a možností.

O čem chci mluvit, jsou nebetyčné rozdíly v řízení interních projektů a procesů. Především těch z oblasti IT. Přeci jen, v těch se pohybuji a měl jsem tu možnost pracovat na projektech jak pro malé až středně velké české společnosti, tak pro obrovskou banku fungující na českém trhu v rámci nadnárodní korporace. O tom, že se nehraje na stejném hřišti, ba dokonce se nehraje ani stejný sport, hovořit nechci (myslím, že to už došlo i těm, kteří to nevědí). Chci se podívat na to, co by si tyto dva segmenty mohly od sebe vzít, aby jim tato oblast fungovala lépe (ano, druhým předpokladem je, že interní procesy mezi businessem a IT fungují špatně. Tedy většinou.)

A lze se vůbec inspirovat?

Rozdíly mezi malými podniky a nadnárodními korporacemi jsou samozřejmě příliš velké, než abychom mohli navzájem přepoužít celé postupy či metodiky. Existují však dílčí procesy, ze kterýchby jeden segment od druhého čerpat mohl a já se vám je nyní pokusím přiblížit na několika klíčových problémech z osobních zkušeností.

Zdroj: http://blogs.starcio.com

Agile, scrum, kanban, DevOps...když slova předchází činy

Možností, jak řídit vývoj i správu aplikací, existuje celá řada. Každá má svoje výhody i nevýhody a každá se hodí do jiného prostředí. Či spíše do jiného projektu.

Velké korporace nemívají problém s dostatkem expertů v různých metodikách. Dokáží pracovat v klasických vodopádových metodikách na obrovských programech sdružujících i desítky projektů a stejně tak dokáží identifikovat dílčí celky, ve kterých se snaží o agilní vývoj. Dokonce chápou problém rozděleného vývoje a následného provozu, kterým je "PNJ", tedy "Problém někoho jiného", a snaží se oba celky propojit v jeden celek, DevOps. Potíž je, že v praxi to nefunguje. Z mého pohledu pro to existují 3 základní důvody:

• Poměrně zásadní překážkou bývá kontrast krátkodobě nastavených cílů manažerů oproti dlouhodobým cílům společnosti. Těžko lze očekávat od projektového manažera s cílem dodat aplikaci do měsíce 10 v roce 2017 (na který jsou vázány jeho odměny), že si v dubnu po několika sprintech řekne: "Hm, to nestihneme v požadované kvalitě podle metodiky. Tak pojedeme agilně dál a dodáme třeba v březnu 2018." Jasně že ne. Bylo by to sice lepší pro společnost, pro aplikaci i pro lidi, kteří na ní pracují. Ale nebylo by to lepší pro NĚJ! A o to jde ne ;).

Zde by mohl pomoci standardní přístup malých firem, který je, i když v mnoha případech možná nechtěně, v zásadě víc agilní = Je nás málo a tak jedeme tak, jak budeme stíhat.Často se bavíme o odměně vázané na úkol a nikoliv "odseděné" fixní mzdě, tudíž motivace není nutně vázána na rychlost dodání, ale spíše na kvalitu.

• Metodiky bývají často pouze na papíře. Jsou, nebo bývají, zpracovány opravdu skvěle, to je třeba podotknout. Jakákoliv snaha o obměnu, modernizaci nebo agilitu však končí většinou v zárodcích a vrací se do klasického skokového vodopádu. A velké vodopádové metodiky tvrdě odolávají snahám o zjednodušení zejména z důvodů časté chybovosti, která je ovšem většinou řešena ještě větší byrokratizací celého procesu. Přibývají komise, spletitosti mezi rolemi…a přibývají i problémy. I přesto, že malé týmy v rámci projektů se často snaží o moderní způsoby vývoje, díky vnějším tlakům z velké projektové metodiky jsou však často nuceni se přizpůsobovat a, byť možná nechtěně, stejně sklouzávají do stejného rytmu.

Malé projektové týmy v menších firmách často pracují na základě velmi jednoduchých odhadů a ganttových diagramů. Žádné složitosti, žádná byrokracie a pokud má projekt zkušeného manažera, dost často to také funguje. Tady vidím možnosti, kde se poučit a řešit problémy spíše zeštíhlování metodik, než jejich komplikováním. Souvisí to trošku i s dalším bodem, všechny ty XXXX-boardy jsou…jak to říci slušně…přirovnal bych to ke komisím v poslanecké sněmovně. Hezká funkce s dodatečným ohodnocením „za odměnu“, která je ale úplně k ničemu.

• Skutečně otravnou záležitostí korporátů je rozsekání celého IT aparátu na co nejmenší celky pokryté nezávislými týmy. Asi aby mohli do struktury nabouchat víc manažerů. Každý trošku komplexnější úkol se tak stává strastiplnou cestou Honzíka s ranečkem buchet, který nakonec po 3 dílech pohádky najde tu správnou princeznu, která je zodpovědná a oprávněná (divili byste se, ale najdete i osoby, které splňují pouze jednu z těchto vlastností) za vykonání činnosti A, která stojí mezi vámi a splněným úkolem. Během měsíců a měsíců snahy o spuštění banální věci tak posloucháte věty typu: "K tomu potřebuju souhlas téhle role", "To my neděláme, to dělá tým XX" a z týmu XX pak: "To my sice děláme, ale musí nám to schválit šéf týmu ZZ" a podobně. A to nemluvím o tom, že když toho správného člověka najdete, klidně se vám může stát, že vám řekne něco jako "Já to nemam kam vykázat, obrať se na mýhoresourcemanagera." Bezva.Jo..a to jsem ještě nemluvil o třecích plochách úrovní liniových a projektových, ale to už by bylo asi moc J

Co by mohlo pomoci? Zeštíhlení aparátu. I kdybych věřil, že na všechny ty činnosti firma skutečně potřebuje stovky zaměstnanců či externistů, rozhodně nepotřebuje tolik manažerů. Spoustu segmentů by mohlo být sdružených do logických celků, tak abyste k nastavení prostupů do backendů konkrétní aplikace pro počítače třetích stran (rozumějte dodavatel) nemuseli svolávat armádu řešitelů a po měsících se dobrat řešení. Malé firmy mají jednoho, možná dva ajťáky (i kdyby deset) a ti moc dobře vědí, že to za ně nikdo neudělá ;).

Projektové řízení…když jsme přesvědčeni, že to zvládneme sami

U malých společností také nefunguje vše ideálně a pozorování v průběhu delší doby lze vysledovat několik archetypů patologického chování, které ohrožují celkovou úspěšnost IT projektů. Těch je v těchto firmách samozřejmě méně, často jde o jednorázové projekty po několika letech, kdy se aktualizuje stávající systém nebo se nahrazuje zcela novým. Neprobíhají kontinuálně desítky paralelních IT dodávek, které se navzájem musí integrovat a napojovat na řešení projektu jiné, což jim situaci samozřejmě značně ulehčuje.  Jaké základní problémy jsem osobně vysledoval?

Zdroj: https://blog.ganttpro.com

• „Uděláme si to sami“. Někdo z vedení (nebo managementu) firmy se rozhodne, že dokáže takový projekt uřídit sám. K ruce si vezme interního ajťáka a najme si externího dodavatele, od kterého si nechá vše poradit. Nedokáže to. Firma se pak ocitne zcela napospas dodavateli, nedokáže revidovat jeho návrhy a efektivně kontrolovat jeho výstupy.

Právě zde vidím jednu z mála situací, kdy je třeba tým naopak rozšířit. Externí nezávislý architekt, interní IT specialista se zkušenostmi vedení projektů…možností je vícero, firma však potřebuje na své straně někoho, kdo dokáže navrhnout potřeby společnosti a na základě těchto návrhů vybrat ideálního dodavatele, se kterým následně spolupracuje i během implementace.

• Skoro absolutní NEspráva změnových požadavků. Ano, druhým velkým problémem bývá představa, že si systém navrhneme tak nějak v průběhu. Je to taková hurá varianta agilního vývoje, která nemůže ve světě IT dodávek uspět. Souvisí to trošku s prvním bodem a faktem, že by podobným situacím ze strany „businessu“ měl předcházet nějaký profesionál, nicméně i uvědomění na straně samotných zadavatelů by mělo přijít ve výrazné míře. Ano, klidně pojďme projektovat agilně, ale řízeně.

Je třeba si uvědomit, že changerequesty (změnové požadavky) jsou v IT projektech běžnou věcí. Bez jejich řízení však v důsledku mohou nastat pouze dva stavy – buď se vztahy mezi dodavatelem a zadavatelem ochladí k bodu mrazu, nebo se cena projektu vyšplhá do nesmyslných výšin. V horším případě nastanou stavy oba. Největším problémem bývá fakt, že si společnost objedná dodavatele na základě FTFP (fixedtime, fixedprice) s nějakou podepsanou analýzou a následně očekává, že změny budou přijaty s otevřenou náručí. Tak to samozřejmě není a pokud chceme pracovat s do jisté míry otevřeným scopem, můžeme si od dodavatele najmout tzv. bodyshopy (najmeme si přímo lidi, které sami řídíme) nebo musíme pracovat s otevřenou analýzou a otevřenými body v productbacklogu.

Slovo závěrem…

Neberte prosím předcházející text jako návod nebo nějaké neprůstřelné tvrzení. Je to souhrn mých osobních zkušeností, ze kterých sám čerpám ve své kariéře a ve prospěch svých klientů. Věřím, a statistická data mi dávají za pravdu, že lze úspěšnost projektů držet na takřka stoprocentní úrovni a mě osobně k tomu pomáhají nejen výše zmíněné body. Jde to. A s dobrými lidmi to půjde i vám.