Abstrakt: Tato případová studie si bere za cíl vyzkoumat možnosti aplikace iterativních metodik při kusové výrobě nábytku. Popisuje nedostatky využití vodopádového přístupu a možnosti zefektivnění výroby použitím iterativních metod.
Výzkumnému týmu pod mým vedením byl svěřen nadmíru náročný úkol – sestrojit na míru vyrobený botník. Pro vývoj byla zvolena vodopádová metoda.
Sběr požadavků
Ve fázi sběru požadavků byly sebrány následující požadavky:
- Vhodnost rozměrů – botník musí svými rozměry vyhovovat danému prostoru a obecným zvyklostem
- Shodnost barvy s přilehlým věšákem – zbarvení výsledného produktu musí být totožné jako u již používaného věšáku
- Velikost vnitřních rozměrů musí být taková, aby alespoň do jedné části bylo možné vložit dámskou zimní obuv o výšce 21cm.
- Možnost uzavírání – botník musí být uzavíratelný, aby se zvýšila jeho estetická hodnota
- Zvládání zátěže – musí být možné na výsledném produktu bez obav sedět
Na základě požadavků a průzkumu trhu bylo rozhodnuto, že dojde k vývoji vlastního řešení, protože žádný na trhu dostupný produkt nesplňoval uvedená kritéria.
Návrh
Na základě požadavků bylo přistoupeno do fáze návrhu a byl vyprodukován následující design:
Tento byl předložen zadavatelce ke schválení a po jeho odsouhlasení bylo možné přistoupit k další fázi vývoje.
Realizace
Při realizaci se začaly vyskytovat nenadálé problémy. Bylo zjištěno, že subdodavatel je schopen dodat komponenty o maximální šíři pouze 40cm. Tento fakt znemožnil možnost výroby uzavírací části, jejíž rozměry byly naplánovány na 47x50cm. Díky flexibilnosti vývojového týmu došlo k jednoduché změně návrhu. Byl navržen sokl, který sníží potřebnou výšku uzavírací části na potřebných 40cm. Došlo tedy k změně návrhu. Tímto krokem se už celý projekt začal odchylovat od zvolené metodiky, která nepočítá s možností změny návrhu ve fázi vývoje.
Po skompletování a povrchové úpravě základního modulu se projekt setkal s dalšími obtížemi. Protože byl tento typ projektu pro vývojový tým nový, zjistilo se, že mu chybí dostatečné zkušenosti a žádný z jeho členů neumí vypočítat potřebnou šířku uzavírací části. Tu ovlivňuje množství proměnných jako je šířka samotného botníku, rozestup mezi oběma částmi zavírací části a typ dveřních závěsů (nesprávně pantů).
K další odchylce od zvolené metodiky došlo z důvodu skluzu v termínu. Zadavatelka se vrátila z inspekční cesty v tuzemském pohoří a viděla produkt v průběhu vývoje. Netuše, že tím narušuje metodiku, začala poskytovat zpětnou vazbu. Všimla si například, že je výrobek v zadní části otevřený a vznesla obavu, že používáním dojde k znečišťování povrchu zdi. Byl proto vznesen požadavek na úpravu návrhu tak, aby k obdobným potížím nedocházelo. Protože je tento zákazník pro náš tým důležitý, nebylo možné použít standardní procedury pro change request a požadavek musel být zapracován. Naopak, po informování o obtížích při výrobě uzavírací části nám bylo sděleno, že tento požadavek není nikterak kritický a není nutné ho dodržet.
Po implementaci krycí zadní části byl produkt hotov, úspěšně otestováno splnění všech požadavků a nasazen do používání (viz. foto)
Diskuze
Viděli jsme, že zvolená metodika není příliš vhodná při výrobě nového výrobku, se kterým nemáme přílišné zkušeností. Vývoj pomocí vodopádu je velmi obtížný pokud:
- Nemáme zkušenosti s oblastí v které se pohybujeme. Vzniká tím velké riziko, že mezi námi a zákazníkem vznikne nedorozumění.
- Není snadné zjistit všechny požadavky předem.
- Využíváme nové a neznámé technologie.
- Existuje riziko, že zákazník bude chtít v průběhu projektu měnit a rozšiřovat zadání.
- Není jisté, že zvolený návrh bude schopen vydržet všechny zátěžové testy.
Je zajímavé, i když vcelku logické, si všimnout, že na většinu obtíží pří vývoji pomocí vodopádu narazíme až ve fázi realizace a předvedení zákazníkovi. Ve fázi sběru požadavků a návrhu obvykle k tomuto „střetu s realitou“ nedochází.
Navrhovaný postup
Po prostudování dostupné literatury, navrhujeme následující iterativní postup.
Při prvním kontaktu se zákazníkem se nevyhýbat sběru požadavků, zjistit co nejvíce o jeho představách a požadavcích. Pro první iteraci z vybrat nejdůležitější a nejrizikovější část. V našem případě by to byl základní modul botníku. U této části by proběhl návrh (s přihlédnutím na další rozšíření) a realizace opravdu nejnutnějšího minima. Doporučujeme například minimalizovat práci na povrchové úpravě. Po dokončení první fáze provést testovaní a vyžádat si od zákazníka zpětnou vazbu. Je důležité ho upozornit, že se jedná o první nehotovou verzi. Na základě jeho zpětné vazby potom volit obsah další iterace.
Přínosy iterativního vývoje
- Počítáme se změnou – nejsme překvapeni tím, že musíme do návrhu zavádět změny.
- Minimalizace nepotřené práce – v každé iteraci myslíme hlavně na práci pro současnou iteraci. Netvoříme věci, které možná nebudou vůbec potřeba.
- Minimalizace rizik – snažíme se nejrizikovější části přenést do co nejbližší části výroby. Když se při testech zjistí, že daný návrh výkonnostně nevyhovuje, je minimalizováno množství práce o kterou přijdeme z důvodu špatného návrhu.
- Brzký úspěch – již v od začátku máme něco, co můžeme předvést zákazníkovi. Tento fakt zvyšuje důvěra zákazníka a sebevědomí vývojového týmu.
Nedostatky iterativního vývoje
- Nutí zákazníka poskytovat zpětnou vazbu – někteří zákazníci se neradi podílejí na vývoji. Chtějí mít výrobek hotový, ale nechtějí do něj investovat svůj čas a práci.
- Není vhodný pro hromadnou výrobu – vyrábíme-li produkt hromadně (např. dodáváme kuchyňské linky) není vhodné postupovat iterativně. Zde je možné a doporučené použít vodopád.
- Při výrobě nábytku je obtížný refaktoring – v případě, že by nás nenapadl problém s maximální výškou dveří již při návrhu, museli bychom ho obtížně řešit v dalších iteracích.
Závěr
Ukázali jsme, že pro kusovou výrobu nábytku je možné použití iterativních metod. Je tu ovšem riziko zvýšení nákladů způsobené obtížným refaktorováním. V jiných odvětvích, kde je refaktorování levnější by byl tento způsob výroby zcela jistě vhodný.
detailna stranka jedneho clanku nezobrazuje obrazky
Myslím, že ještě jeden nedostatek je schovaný v samotném příběhu. Zadavatelka měla v dodavatele naprostou důvěru a cíl zadavatelky byl totožný s cílem dodavatele, tj. mít hotový botník. Takže, když si zadavatelka kladla požadavky až v průběhu výroby botníku, měla jistotu, že nadbytečná práce nebude zbytečně protahována a tudíž prodražována a všechno spěje k požadovanému konci.
Pokud by ale dodavatel nebyl tak úplně korektní, mohl by práci protahovat s vidinou většího výdělku nebo na práci nasadit mladé, nezkušené truhláře, chraň bůh, možná i učně. V takovém to nemilém případě, pokud by zadavatelka nerozuměla truhlařině a takovou fušerskou práci nepoznala, by ji možná nezbylo nic jiného než dodavateli vařit tak dlouho, než by botník byl hotový. Přece už do výroby botníku investovala takových peněz, že by je nechtěla vyhodit z okna tím, že by výrobu botníku zadala jinému truhláři.
V takovém případě podle mě nepomůže rozdělení do jednotlivých iterací, protože cena za iteraci je ujednávána teprve v okamžiku ukončení iterace předchozí. Dodavatel pak může cenu za iteraci napálit a nebát se nižší konkurenční nabídky, protože v určitých odvětvích nemůže jiný dodavatel jednoduše pokračovat v práci předchozího dodavatele.
Myslím, že iterativní vývoj může vést k tomu, že zadavatel dostane opravdu to co od počátku chce, i když to na začátku nemusí být schopen dostatečně přesně popsat. Lze ale uplatnit, pouze pokud má zadavatel naprostou důvěru v dodavatele. A tu lze získat až po mnoha zakázkách. A to, že dodavatelem je jiné oddělení v téže firmě, nemusí automaticky znamenat, že cíle obou oddělení, zadavatele i dodavatele, jsou shodné.
Chápu, že pro zadavatele je bezpečnější vybrat si z nabízených cen od různých dodavatelů a pak už je na dodavateli, aby stanovil sám co nejpřesnější zadání a nemusel se v průběhu vývoje produktu dohadovat se zadavatelem, jestli dveře od botníku jsou součástí zadání “chci botník”.
No a občas je úplně nejlepší radši zajet do IKEY a vybrat si botník, co možná není úplně to pravé co bych chtěl, ale aspoň vidím, co kupuji 🙂
Dovolím si nesouhlasit. Při iterativním vývoji má odběratel mnohem dříve možnost reagovat na fušerskou práci dodavatele. Právě tím, že se vývoj děje v iteracích, které jsou kratší než by byl vývoj vodopádem. To, že projekt spěje někam kam nemá má šanci vidět po skončení každé iterace. U vodopádu se na to přijde až po skončení vývoje, což může být za hodně dlouho (a draho).
Není pravda, že se cena dohaduje na začátku každé iterace. Hodně často se uzavírá rámcová smlouva, která říká. My vám dodáme takový a takový tým na takovou a takovou dobu a zavazujeme se, že že za tu dobu naimplementujeme tyto základní funkce. Snejvětší pravděpodobností stihneme naimplementovat tyto funkce a když zbyde čas, tak doplníme tyto funkce. Pokud se zákazník bojí, že se stane naším rukojmím, může si uzavřít něco jako opční smlouvu.
A IKEA je samozřejmě nejlepší. Vývoj software na zakázku si platí jenom ti největší zbohatlíci, kteří mají specielní neobvyklá zadání, jako třeba zobrazit data z databáze na Webu.
Nesouhlasím s tím, že IKEA je nejlepší ;). Tam máte jistotu, že tam dostanete průměrný ne moc kvalitní kus něčeho. Po nějaké době používání možná zjistíte, že to stejně nakonec není úplně ono, jak jste si na začátku mysleli – a to třeba i z toho důvodu, že jste na to zprvu kladli takové požadavky a představy, které se v reálu ukázaly jako ty méně důležité a naopak to co to mít mělo se objeví až ve chvíli, kdy ten kus umístíte ve svém bytě. Taky můžete zjistit, že pod hezkým zevnějškem je fušersky odvedená práce a že nakonec by možná i bylo lepší kdybyste si to udělali sami nebo si dali větší práci se sháněním důvěryhodného a kvalitního dodavatele (vlastní zkušenosti s kuchyní na míru :().
S krabicovým SW je to to samé (až na to, že se vám může spíš podařit dobře odvedenou práci než v IKEE 😉 ).