Ošklivá pravda o procesu vývoje softwaru

zdroj obrázku: perfectdigital.com

Tenhle obrázek znáte, že?

Myslím, že to velmi dobře ukazuje, že velké nesrovnalosti a nedostatek vize se mohou objevit v... vývoj softwaru projektů mezi všemi účastníky a zapojenými osobami. Problémy často vznikají již na samém začátku, kdy klient přichází s (teoreticky) konečným návrhem. produkt a předkládá ji tým. Pak přicházejí další nedorozumění, chybné interpretace a nakonec i... projekt se rychle vydá špatnou cestou vývoje.

Při analýze výše uvedeného grafu postupně představím všechny možné hrozby a navrhnu, jak proti nim bojovat. Pojďme rovnou na věc!

1. Jak zákazník vysvětlil svůj nápad?

Budou se vyskytovat nesrovnalosti v vize produktu od samého počátku. Proč? Důvod je velmi jednoduchý - každý si vykládá realitu po svém, má o něčem v hlavě představu a nemusí ji přesně prezentovat druhé straně. Pokud slovy popíšete produkt, který byste chtěli vytvořit, je vysoká pravděpodobnost, že se vám to vývojový tým pochopí vaši vizi jinak, než jste zamýšleli.

Samozřejmě je možné se tomu vyhnout. S vizualizací je třeba začít co nejdříve a na základě náčrtů probrat jednotlivé prvky funkčnosti produktu. Zajímavé je, že první skici obvykle nemají s finálním produktem nic společného. V této fázi je však nejdůležitější, aby vize byla ucelená.

2. Jak tomu rozuměl vedoucí projektu?

Zajímá vás, proč se první a druhý obrázek tak liší? Vedoucí projektu se vždy blíže podívá na vizi produktu. Nicméně, je důležité, aby taková osoba, která je v podstatě zodpovědná za celý projekt. software proces vývoje, plně rozumí problému a potřebám souvisejícím s produktem.. Vedoucí projektu musí mít jasný "širší pohled". Jak vidíte, oba snímky se z hlediska funkčnosti neliší. Pouze jinak vypadají. Pro lepší pochopení tohoto bodu se vraťme k obrázku číslo jedna. Na začátku projektu neexistovaly žádné náčrty, a to už vedlo k nedorozumění. Funkčnost výrobku je správná, ale design je zcela odlišný.

3. Jak ji analytik navrhl? a 4. Jak to programátor napsal?

Někdy analytici a vývojáři neznají potřeby uživatelů nebo stanovené obchodní cíle. Vidí pouze malou část celého projektu, která zachycuje jejich hlavní zaměření. Nejsou schopni pohledu z širší perspektivy, což platí zejména pro velké projekty, na kterých pracuje mnoho vývojářů najednou.

Můžeme použít i jiný příklad. Může se stát, že problém, který je třeba vyřešit, je nesprávně popsán například vlastníkem produktu. Jde o poskytnutí neúplných informací, na jejichž základě si vývojář nebo designér vytvoří vlastní interpretaci, a produkt se stále více odchyluje od zamýšlené cesty vývoje.

Jak to změnit? Myslím, že dobrým řešením je zajistit, aby lidé, kteří jsou pro projekt klíčoví, o něm měli podrobné znalosti - takzvaný "širší obraz". V případě nedorozumění pro ně bude snazší přivést k řešení problém. proces vývoje softwaru zpět na správnou cestu. Proto nezapomeňte - pokud každý vidí jen svůj malý kousek rozvinuté funkčnosti, stávají se nedorozumění ve vizi pravděpodobnou hrozbou.

5. Jak to popsal obchodní konzultant?

Zde je věc jednoduchá. Výrobek se musí prodávat. Musíte nějak vyniknout, aby například jednoduchá houpačka na zahradu dosáhla mimořádných prvků. Jde o to přesvědčit potenciálního kupujícího. Marketingové a obchodní oddělení jistě udělá vše pro to, aby ukázalo, že výrobek je jedinečný.

6. Jak byl projekt zdokumentován?

Chybějící dokumentace je velmi častým problémem. Někdy je vytváření dokumentace během vývoj produktů se zdá být zbytečnou ztrátou času. To je chyba. Velmi často říkám, že změny se dělají rychleji na papíře než v praxi. kóda něco na tom je. Navíc je snazší nahlédnout do dokumentace a sledovat případné změny. Věřte mi, že u projektu bez dokumentace je velmi vysoké riziko, že se minete vidinou.

7. Které operace byly nainstalovány?

Tato fáze se týká umístění prostředí na server. Stejně jako v bodě o programátorech a analyticích se může ukázat, že bez úplných dat a s komunikačními mezerami byla vytvořena pouze část potřebného prostředí.

8. Jak byla zákazníkovi vystavena faktura?

Je to důsledek špatné komunikace, nedostatečného UX a podobně. Výskyt chyb prodlužuje dobu vývoje. A čas jsou peníze, že? Mým tipem je vést projekt v souladu s agilním přístupem., udržovat nejvyšší komunikační standardy a dodržovat jasné rozpočtové zásady. Nepochybuji o tom, že tímto postupem se podobným problémům vyhnete.

9. Jak byla podporována?

Zákazníci se často soustředí pouze na vytvoření produktu a tím to končí. Žijeme však v době mnoha změn a technologických inovací, a proto je nutné udržovat stálou technickou podporu. Jde o to, aby nedošlo k situaci, kdy něco náhle přestane fungovat, protože zastará a produkt ztratí svou hodnotu. Ani na tento aspekt bychom neměli zapomínat.

10. Co zákazník skutečně potřeboval?

Dosáhli jsme posledního bodu. Podívejte se na rozdíl mezi prvním a posledním grafem. Oba se přece týkají pohledu klienta. Proč k tomu dochází? Všichni lžou, že je to tak jednoduché 🙂 Výsledky průzkumu se vždy liší od skutečných potřeb vašich respondentů. Při odpovídání na otázku výzkumníka chtějí uživatelé ukázat svou nejlepší stránku. Proto se snažíme, abyste se mohli vyjádřit, jak se cítí, ČASTO NEODPOVÍDAJÍ PRAVDIVĚ, ale spíše způsobem, o kterém si myslí, že by na něj měli odpovědět. V podstatě nechtějí být vystaveni negativnímu hodnocení druhých. Zde je pro vás malá nápověda - v pokynech zmiňte, že neexistují ani dobré, ani špatné odpovědi.

Kde se ještě objevují rozdíly? Lidé často nevědí, co skutečně chtějí. Poměrně často se stává, že uživatelé zpočátku říkají, že potřebují 10 funkcí v produktu, a později ve skutečnosti používají třeba jen 3.

Jak tedy tento problém vyřešit? Kromě toho, že se uživatelů zeptáte, co chtějí a potřebují, umožněte jim testování produktu, nejlépe na autentických předmětech, abyste zachovali důvěryhodnost. Čím více testů při tvorbě produktů, tím větší šance, že výsledek bude přesný.

Souhrn

Pokud se někdy stanete členem vývoj softwaru projektu, zapamatujte si mé příklady a vyvozujte závěry tak, abyste nekopírovali výše uvedené chyby. A nezapomeňte, že tyto pojmy jsou velmi důležité při vytváření produktu (aplikace) od nuly:

- dobré UX a testy, abyste zjistili, co vaši uživatelé skutečně potřebují,

- komunikace v rámci projektu, aby klíčové osoby v projektu měly k dispozici hluboké porozumění problému a potřebám,

- vyvinout produkt v souladu s Agilní,

- nezapomeňte na technickou podporu.

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

– Jak efektivně řídit vzdálené vývojáře? Průvodce pro CTO

– Python vs. Ruby? Kterou technologii byste měli použít pro vývoj produktů?

– Stručný průvodce budováním a rozvojem vlastního tržiště. Co stojí za to vědět?