Skryté náklady a skutečná agilita v procesu vývoje produktů

Wu-Tang Clan měl pravdu

Všemu kolem mě vládne hotovost. To nemohou popřít ani ty nejtyrkysovější organizace. Vývoj projekt metody řízení, vylepšování a optimalizace procesů nebo motivace zaměstnanců je v podstatě vyvolána všeobecnou potřebou peněz. Agilita návrhu s sebou nese určitá rizika.

Všichni chceme být štíhlí a agilní aby výsledek naší činnosti, měřený počtem, byl co nejvyšší. I když většinu energie zaměřujeme na snižování ztrát, v konečném důsledku zohledňujeme zisk, který se díky vygenerovaným úsporám zvýšil.

Tyto úspory spadají do stejné kapsy jako ostatní faktory a zůstávají dostupné jen těm nejzvídavějším. Tímto způsobem ztrácíme pozornost a neúmyslně vynecháváme mnoho cenných údajů a nakonec i informací.

Poučení z neúspěchů

Učení se z vlastních chyb je obzvlášť užitečná (i když drahá) dovednost, ale... organizační kultura a diplomacie, která je v této schopnosti obsažena, ne vždy pomáhají. Negativní dopady financí často zakrýváme slovy "kouřová clona". Když investor křičí "Přišel jsem o peníze!", manažer to sděluje na tým tím, že říkáme "měli bychom být efektivnější" a všichni standardně hledáme nová řešení a zlepšení - místo abychom se ohlíželi zpět, neustále hledáme způsoby, jak se posunout vpřed.

Ztráty jsou přitom často klíčem k vyvození správných závěrů. Pokud určité kroky toku v procesu přejdeme bez řádného zvážení, další řešení budou s největší pravděpodobností infikována stejnými chybami.

Příklad: 

Malý tým seniorních vývojářů JS nezajistí funkčnost v očekávaném čase. Investor, který chce vývoj urychlit, nařídí najmout nového programátora. Zavedení nového člověka do projektu rozptýlí tým, což postup projektu ještě více zpomalí.

Pokud by investor lépe pochopil důvody neefektivity týmu, dospěl by k závěru, že využívá svůj potenciál pouze v 60-70%. Problém by vyřešilo lepší vybavení a několik pracovních dnů věnovaných automatizaci práce.

Bohužel nyní musí zaplatit za jiného vývojáře, který bude pracovat na stejném zařízení a jeho účinnost bude také na úrovni 60-70%.

Řešení A:

• Tým (2 x senior JS dev): $20k / měsíc
• Cloud služby: 200$ / měsíc
• Nový hardware pro vývojáře: $10k

Od této chvíle stojí projekt $20,200 / měsíc

Celkové výdaje za 12 měsíců: 12 * 20 200 + 10 000 = $252 400

Řešení B:

• Tým (2 x senior JS dev): $20k / měsíc
• Nový vývojář (1 x senior JS dev): $10k / měsíc

Od této chvíle náklady na projekt: $30,000 / měsíc

Celkové výdaje za 12 měsíců: 12 * 30 000 = $360 000

Dva vývojáři pracující při 100% odvedou zhruba stejnou práci jako tři vývojáři pracující při 60-70%. Investor zaplatí za stejnou výpočetní kapacitu o více než $ 100 000 ročně více kvůli chybnému rozhodnutí o návrhu!

Vytváření dokonalého produktu je jako honba za králíkem

Agilita v procesu nemusí nutně znamenat snahu o pokrytí testů 100% nebo překonání výkonnostního rekordu. Tyto metriky sice poskytují přehled o technickém stavu projektu, ale z pohledu koncového zákazníka jsou natolik nevýznamné, že jejich uvedení do ideálního stavu ve skutečně agilním procesu nemusí být dosaženo, protože nepřinášejí skutečné trh hodnotu.

Vývoj dokonalých technických řešení vyžaduje velké týmové nasazení a mnohem rozsáhlejší komunikaci. Výsledkem je, že opravy pracují pomaleji a projekt se kvůli nadměrnému vývoji stává těžkým.

Agilní vývoj jde o to, abyste poskytli funkční kód s minimálním úsilím. Testování kódu je bezpochyby dobrá praxe a testy vypovídají o fungování kódu, ale neměly by se dělat jen pro to, aby se dělaly a chlubily se tím - optimální technická kvalita řešení leží někde mezi minimem určeným podle vývojový tým a maximum, které je omezeno rozpočtem.

Dokonalost nakonec nikam nevede. Zajímavé je, že tomuto pravidlu podléhá i otázka bezpečnosti - teoreticky lze hacknout jakýkoli systém. Výše zmíněné vývojové minimum však musí být odpovídajícím způsobem vyšší a odpovídající váze, rozsahu a nákladům na možné následky chyb v kódu. Často je místo psaní přihlašovacího modulu od nuly, které je vždy zatíženo vysokým rizikem chyby a vnesení bezpečnostních chyb, lepší použít například tlačítko "Přihlásit se pomocí Google", jehož správná implementace je relativně rychlá a bezpečná.

Pokud je cílem krátká doba uvedení na trh, jsou příliš ambiciózní předpoklady kontraproduktivní. Ve zdánlivě dokonalém procesu může být přílišné nadšení plýtváním zdroji..

Je dobré vědět o něčem všechno a o všem něco.

Design zaměřený na uživatele je cool. Spolupráce zaměřená na člověka je důležitější. Když tým komunikuje na stejné vlně, může spontánně snížit další potenciální ztráty.

UX designér, který má přehled o frontendových technologiích, nenavrhne řešení v okamžiku. MVP fáze, která ve fázi implementace zabere nepřiměřeně mnoho času.

Frontendový vývojář, který zná heuristiku použitelnosti, bude schopen přizpůsobit rozhraní danému rozlišení obrazovky bez zapojení designéra UX - rychlá oprava, náhled, přijetí.

Práce na aplikaci vyžaduje synchronizaci činností lidí se zcela odlišnými kompetenčními profily. Abyste mohli efektivně poskytovat hodnotu svým zákazníkům, musíte znát rozložení dovedností ve svém týmu.

Zapojený a synchronizovaný tým je klíčovým zdrojem úspor. Tento typ agility vyžaduje optimální vývoj produktu.

Takto chápaného dobrého týmového výkonu je nesmírně obtížné dosáhnout, zejména v éře práce na dálku. Společnosti, které jsou již léta "přátelské" ke vzdálené komunikaci, mají v této oblasti značnou výhodu oproti těm, které byly nuceny vyladit organizaci během výluky a teprve nyní se seznamují s novými metodami a formami komunikace.

Výkonné vybavení před odjezdem

V souvislosti s rostoucími komunikačními potřebami zaznamenávají nástroje jako Whimsical, Miro, Mural, Figma a Balsamiq impozantní nárůst popularity.

Svou roli v tomto nárůstu počtu uživatelů jistě sehrála výluka a potřeba pracovat na dálku. Domnívám se, že výběr nástroje by měl odpovídat individuálním preferencím, ale podívejme se na Miro:

Popularizace těchto nástrojů přirozeně vede k nárůstu popularity samotných metodik. Někdo, kdo si koupil Miro pro práci na personech, získá přístup k desítkám dalších šablon, které se mohou ukázat jako zajímavé a pozitivně ovlivnit každodenní práci týmu.

Vždy byste se měli vybavit nástroji, které zefektivní tok informací v projektu. Otevřenost vůči novým nástrojům a metodám je také jedním ze základů efektivního vývoj produktů.

Můžete (a měli byste) být líní

Zkušení návrháři rozhraní i systému architektura softwaru obvykle si na začátku spolupráce všimnou několika možných řešení, která je třeba ověřit, a efektivně hledají vhodné inspirace nebo dokonce hotová řešení na trhu. Dobrým příkladem je framework Material UI, který je ve fázi prototypu obvykle sázkou na jistotu..

Někdy stačí prohlédnout si několik realizací na Behance nebo Dribble a na základě inspirace vytvořit mood board a ten pak předat vývojáři. Ten ji použije k sestavení klikací plochy. prototyp které mohou být předloženy prvním uživatelům za účelem získání zpětné vazby. Tato organická snaha o efektivní proces je u designově smýšlejících a angažovaných lidí přirozená.

Pokud chcete efektivně dodávat digitální produkty, musíte nechat lidi dělat jejich práci. Víte, jakou hodnotu/službu chcete svým zákazníkům poskytnout - to stačí. Kompetentní a dobře řízený projektový tým bude nejlépe vědět, jak tuto hodnotu/službu dodat co nejrychleji a s potřebnou efektivitou nákladů.

Projevte důvěru, sdílejte zodpovědnost a otevřete se skutečné oboustranné komunikaci, aby vaše produkt bude lepší a z vašich ramen spadne břemeno, že vše musíte zvládnout sami, což se pro zakladatele a podnikatele často ukáže jako vysilující jízda! Na adrese The Codest, tuto zásadu promítáme nejen do projektů, ale také do interních procesů - pravděpodobně proto se těšíme vysoké míře retence zákazníků i zaměstnanců (true story, both> 90%).

Dopřejte si trochu lenosti, odvážně přeneste odpovědnost a vypusťte nadbytečnou práci, která není nutná pro posun vpřed - funkce, které by bylo "hezké mít", mohou vždy počkat.

Zaměřte se na hledání správných odpovědí

Proces tvorby digitálního produktu je neustálým střetem různých pohledů, zkušeností a zdrojů informací - každý takový střet s sebou nese riziko chybného rozhodnutí o návrhu.

Dobrá interní komunikace toto riziko snižuje, ale je to jen jedna strana mince. Otázku, jak zůstat v kontaktu s trhem, je třeba teprve zodpovědět.

Business Intelligence, oddělení zákaznické podpory, oddělení výzkumu UX a mnoho dalších - stejně jako oddělení. vývojový tým, měli by se snažit o minimum potřebné k poskytnutí konkrétních odpovědí na otázky položené vlastníkem produktu nebo týmem UX.

Důležitý je také samotný branding a komunikační strategie značky. Slouží k budování kvalitního vztahu se zákazníky, který se pak promítá do jejich závazku. Pokud chcete klientům klást otázky, měli byste se ujistit, že jsou ochotni na tyto otázky odpovídat. Záleží na tónu vašeho hlasu.

Je jisté, že neustálý kontakt s trhem vám umožní definovat správné trajektorie projektu, aby byl úspěšný. Méně zřejmá je skutečnost, že o potřebě tohoto kontaktu je třeba uvažovat již na samém počátku projektu, kolem předvídání správných kompetencí v týmu (klást správné otázky a odpovídat na ně) a budování produktové strategie, která bude zahrnovat cílové skupiny.

Závěry

S ohledem na všechny výše uvedené problémy můžeme pozorovat několik problémů, které se v procesu navrhování pravidelně objevují:

- přílišná orientace na zisk a vyhýbání se neúspěchům,

- nepřesnost a nerentgenování vlastních chyb,

- honit se za dokonalým produktem, který máte v hlavě, ale který trh nepotřebuje,

- příliš horlivé zavádění učebnicových postupů - nadměrný vývoj a nadměrný návrh,

- nepružnost týmové práce a nucení zaměstnanců, aby zůstali pouze ve své specializaci,

- neefektivní komunikace,

- tendence znovu vynalézat kolo.

Optimalizace procesů v makroměřítku zahrnuje součet úspor. Abyste mohli správně čelit výše uvedeným výzvám, musíte zapojit své kolegy tak, aby otevřeně předkládali nápady na zlepšení procesu.

Někdy stačí k dosažení úspěchu méně mluvit a pozorněji naslouchat podřízeným, klientům, partnerům - podle role a odpovědnosti každého z nich.

Když vám to nestačí, nejspíš investujete příliš mnoho.. Máte příliš mnoho peněz?

Sklapni a vezmi si své peníze! A kromě toho:

1. Nezavádějte Scrum jen proto, abyste ho praktikovali.
2. Věnujte větší pozornost nedostatkům v procesu.
3. Stanovte si menší cíle, které jsou krátkodobě dosažitelné a měřitelné - obecně se držte minima.
4. Někdy je dobré plán cesty stačí, aby tým získal pocit společného cíle a zapojil se do efektivní práce tady a teď.
5. Vybudujte dobrý tým, abyste mu mohli dát potřebnou volnost.
6. Vždy zpochybňujte stávající sadu nástrojů - hledejte možná vylepšení ve své dílně.
7. Navrhněte proces z pohledu lenocha - jako byste chtěli udělat co nejméně práce.

Přečtěte si více:

Výzvy CTO - rozšiřování a růst softwarových produktů

Jakou DB zvolit pro konkrétní typ dat ve vašem softwarovém projektu