Úskalí externího IT vývoje

Dostaň to, co chceš aneb úskalí externího IT vývoje

Každá firma, která nepodniká v oblasti vývoje ICT řešení, ale potřebuje pro vlastní potřebu či poskytuje svým zákazníkům služby skrze nějaké digitální řešení vytvořené na zakázku (weby, mobilní aplikace, software), musí učinit jedno ze zásadních rozhodnutí a to, zda vytvoří interní vývojový tým nebo zda vývoj zadá externí firmě, dodavateli ICT řešení.

Petr Háze, corphalos - byznys poradenství

Obě varianty v sobě skrývají podobná úskalí, co se týče našeho očekávání na konečnou podobu a funkčnost dodaného řešení vs. toho, co obvykle ve skutečnosti dostaneme. Při využití externího dodavatele je toto úskalí o to větší, neboť vývojový tým není zainteresován do úspěšnosti našeho byznysu a nemůžeme členy takového vývojového týmu motivovat k dobrým výkonům stejnými nástroji jako interní zaměstnance.

Situaci, se kterou se již nejedna firma potýkala, tak nádherně vystihuje následující kreslený vtip, na který jsem před lety narazil. Pro většinu lidí zodpovědných ve firmách za řízení a rozvoj digitálních řešení však tento vtip není vtipem, ale neblahou skutečností, se kterou dnes a denně bojují. A z vlastní zkušenosti vím, že s tímto problémem se potýkala a potýká spousta firem nejen u nás, ale i v zahraničí.

Projekt

Jak to tedy udělat, abychom dostávali to, co chceme a předcházeli tak nepříjemnostem (vč. možných finančních dopadů) a zbytečné ztrátě drahocenného času, který následně musíme věnovat vyřešení problému?

1. Detailní zadání

Pokud sami nevíme, co chceme, neumíme to popsat a srozumitelně předat dál, pak zákonitě dostaneme to, co nesplňuje naše představy a potřeby.

Nejlepší radou, kterou mohu tedy každému dát je, aby nezadávali vývoj dříve, než se všichni zainteresování (zodpovědní) ve firmě shodnou a odsouhlasí si zadání a očekávanou podobu a funkčnost řešení, vyjasní si přínosy (pro zákazníka i firmu) a možná rizika, která bude třeba případně řešit.

Čím lepší zadání připravíme, tím bude samotný vývoj levnější, rychlejší a výsledek kvalitnější. Pro vypracování konkrétního zadání a podoby kýženého řešení doporučuji např. použít metodu kontextového designu, jejímž výstupem by měl být návrh řešení, který koncový zákazník či uživatel (ať již interní či externí) ocení a vývojový tým nemůže zpochybnit, co jsme chtěli, co bylo zadáním a naším očekáváním.

2. Promyšlený výběr dodavatele

Sebelepší zadání nám bude k ničemu, pokud nedokážeme najít a vybrat dodavatele, který bude schopen zadání realizovat za cenu, v čase a kvalitě, které jsme si stanovili. Kritéria pro výběr nejvhodnější dodavatele mohou být různá. Jedním z nich, které bych zde vypíchl, by mělo být kritérium přiměřené velikosti a zkušeností vývojového týmu, které nám je schopen dodavatel nabídnout, s ohledem na požadovaný rozsah a složitost poptávaného řešení (tj. velká ICT firma bude pro malé a jednoduché řešení pravděpodobně nepřiměřeně drahá, malá ICT firma nám pro rozsáhlé a komplikované řešení pravděpodobně nedokáže garantovat dostatek lidských zdrojů a zástupnost klíčových lidí týmu v případě, že onemocní, budou na dovolené či odejdou do jiné firmy).

Na základě mých zkušeností bych rovněž doporučoval vybrat takového dodavatele, který vám dokáže poskytnout tým alespoň v následujícím složení:

  • Kvalitní a zkušený projektový manažer
  • IT architekt a analytik, který dokáže porozumět a pochopit byznys zadání a správně jej přeložit do technického zadání, a který zároveň dokáže přinášet a aplikovat nejnovější trendy a navrhovat řešení, která nebudeme muset za rok zahodit a začít vývoj od nuly
  • Seniorního team leadera vývoje, který dokáže uřídit tým vývojářů a bude garancí kvalitně odvedené práce



3. Jednoznačně stanovené zodpovědnosti

Nejen při řízení firmy, ale i při řízení vývojového projektu je důležité si ujasnit, kdo má v projektu jaké kompetence a za co je zodpovědný. Toto platí nejen pro interní tým firmy zadavatele, ale rovněž i pro dodavatele řešení. Pro interní potřeby je možno zodpovědnosti stanovit např. pomocí RACI modelu, zodpovědnosti a kompetence dodavatele by měly být řádně ošetřeny a podrobně vydefinovány ve smlouvě.

4. Aktivní zpětná vazba ze strany dodavatele

Když už jsme našli vhodného dodavatele, vyžadujme po členech dedikovaného vývojového týmu, aby s námi aktivně komunikovali a vyžadujme po nich pravidelnou zpětnou vazbu a reporty o stavu vývoje. Budeme tak mít větší jistotu, že správně pochopili, co po nich chceme, jak by mělo dodané řešení vypadat a předcházet tak případným nejasnostem. A také budeme informování o případných problémech při vývoji, které nastávají, dříve, než by mohly negativně ovlivnit výsledek celého projektu.

5. Jasně definované podmínky finančního plnění v návaznosti na kvalitu a časový plán

Dobrá smlouva je základem oboustranné spokojenosti a korektních vztahů mezi zadavatelem a dodavatelem. Abychom předešli nepříjemným dohadům týkajících se ceny za dodané řešení a fakturaci případných víceprací, kvality dodaného řešení a termínů dodání jednotlivých částí a celkového řešení, jasně a detailně ve smlouvě definujme, kolik za co platíme, jak budeme řešit a fakturovat případné změnové požadavky v zadání, podle čeho budeme posuzovat kvalitu dodaného řešení a stanovme si závazný harmonogram prací vč. jednotlivých iterací a předávání jednotlivých částí vývoje ke kontrole.

A nezapomeňme do smlouvy zapracovat případné sankce za nedodržení smluvních podmínek, nedodržení požadované kvality a termínů dodávaného řešení. Sankce totiž bývají jediným esem v rukávu zadavatele, které dokáže většinu dodavatelů motivovat k aktivitě a dodání toho, co chceme.

Zanechte komentář

Vaše emailová adresa nebude zveřejněna. Vyžadované informace jsou označeny *

*