Keď každý chápe projekt trochu inak
Jedným z najčastejších problémov je, že klient, dizajnér, developer a project manager nemajú úplne rovnakú predstavu o výsledku.
Klient povie: „Potrebujeme jednoduchú aplikáciu na objednávanie.“
Designer začne navrhovať obrazovky. Developer dostane jednotlivé obrazovky a začne ich implementovať. Až počas vývoja sa ukáže, že aplikácia musí riešiť napríklad registráciu používateľa, rôzne typy objednávok, notifikácie alebo platby.
Tieto požiadavky pritom nemusia byť nové. Mohli byť súčasťou pôvodnej predstavy, len nikdy neboli poriadne definované.
Výsledkom je, že každý pracuje s inou verziou zadania.
Dobrý projekt preto nezačína taskmi. Začína spoločným pochopením produktu.
Pred samotným developmentom by malo byť jasné, čo aplikácia rieši, pre koho je určená, aké sú jej hlavné funkcie a čo patrí do prvej verzie produktu.
„Dorobíme to ešte počas vývoja“
Táto veta môže vyzerať nevinne. Pri vývoji aplikácie však dokáže narobiť veľké problémy.
Počas projektu prirodzene vznikajú nové nápady. Niektoré sú užitočné a niektoré môžu byť dokonca nevyhnutné. Problém nastáva vtedy, keď sa nové požiadavky pridávajú bez toho, aby sa zohľadnil ich vplyv na rozpočet, termín a ostatné funkcie.
Ak sa napríklad počas vývoja rozhodnete pridať nový typ používateľského účtu, nejde len o jednu novú obrazovku. Môže to znamenať zmeny v databáze, backendovej logike, API, používateľských oprávneniach, dizajne aj testovaní.
Ak sa takéto zmeny pridávajú priebežne bez jasného procesu, projekt sa začne rozrastať.
Tento problém poznáme ako scope creep.
Riešením nie je zakázať zmeny. Riešením je mať spôsob, ako ich prijímať.
Každá nová požiadavka by mala prejsť jednoduchým procesom: Čo presne mení? Koľko práce si vyžiada? Ovplyvní existujúce funkcie? Posunie termín? A čo za to prípadne z projektu odstránime?
Tak sa z „malej zmeny“ nestane po troch mesiacoch úplne iný produkt.
Nekonečné revízie nie sú proces
Ďalším častým problémom je dizajn alebo funkcionalita, ktorá sa neustále vracia na prepracovanie.
Klient pošle feedback. Dizajnér upraví návrh. Klient príde s ďalším feedbackom. Niečo sa zmení počas developmentu. Potom sa zistí, že zmena ovplyvňuje ďalšiu časť aplikácie.
A celý proces sa opakuje.
Revízie samozrejme patria k vývoju produktu. Problém nastáva vtedy, keď nie je jasné, kedy je konkrétna časť projektu schválená.
Pomáha napríklad rozdeliť proces do jasných fáz:
návrh → feedback → úpravy → schválenie → development
Po schválení by sa už zmeny nemali robiť neformálne „popri tom“. Ak sa objaví nová požiadavka, mala by sa zaradiť do backlogu a vyhodnotiť ako samostatná zmena.
Tak development tím nemusí pracovať na pohyblivom terči.
Backlog nie je zoznam želaní
Dobre nastavený backlog je jedna z najdôležitejších vecí pri riadení vývoja.
Nemal by však byť len zoznamom všetkého, čo by aplikácia niekedy mohla potrebovať.
Dobrý backlog hovorí:
- čo treba urobiť,
- prečo to treba urobiť,
- aká je priorita,
- čo je podmienkou dokončenia,
- a čo môže počkať.
Predstavte si backlog obsahujúci 80 úloh, pričom všetky sú označené ako „urgentné“.
V skutočnosti potom nie je urgentné nič.
Prioritizácia je preto rovnako dôležitá ako samotné vytváranie taskov. Development tím potrebuje vedieť, čo má najväčší dopad na produkt a čo má byť ďalším krokom.
Pri MVP je to ešte dôležitejšie. Cieľom nie je vytvoriť všetko, čo by aplikácia raz mohla obsahovať. Cieľom je vytvoriť najmenšiu zmysluplnú verziu produktu, ktorú môžeme dostať k používateľom a na základe spätnej väzby ďalej rozvíjať.
Keď sa klient a development tím míňajú
Project manager má v tomto procese ešte jednu dôležitú úlohu: prekladať potreby klienta do jazyka, s ktorým vie development tím pracovať, a naopak.
Klient nemusí vedieť, čo znamená zmena API architektúry alebo prečo jednoduchá úprava používateľského flow ovplyvňuje backend.
A developer zase nemusí mať všetky informácie o obchodnom dôvode, prečo klient danú funkciu potrebuje.
Ak medzi nimi chýba komunikácia, vzniká priestor na nedorozumenia.
Dobrý project manager preto nie je len človek, ktorý organizuje meetingy. Musí rozumieť produktu, vedieť sa pýtať správne otázky a dokázať vysvetliť technické rozhodnutia spôsobom, ktorý dáva zmysel aj človeku mimo developmentu.
Status meeting ešte nie je project management
Ďalší extrém vyzerá opačne.
Kalendár je plný meetingov, existuje množstvo tabuliek, statusov a reportov, ale projekt sa napriek tomu nehýbe.
Project management totiž nie je množstvo administratívy.
Ak meeting každý týždeň skončí vetou „pozrieme sa na to nabudúce“, pravdepodobne nechýba ďalší meeting. Chýba rozhodnutie.
Dobrý project manager by mal pomáhať odstraňovať blokery, držať priority, sledovať závislosti medzi úlohami a zabezpečiť, aby rozhodnutia nezostávali visieť vo vzduchu.
Cieľom nie je mať čo najviac procesov.
Cieľom je mať dostatok procesu na to, aby sa projekt mohol hýbať.
Čo teda funguje?
Neexistuje jeden project management framework, ktorý vyrieši každý vývojový projekt. Dôležitejšie je nastaviť základné princípy.
Na začiatku projektu by mal tím rozumieť produktu, jeho cieľu a rozsahu prvej verzie. Požiadavky by mali byť dostatočne konkrétne na to, aby sa dali rozbiť na jednotlivé úlohy.
Backlog by mal mať jasné priority a úlohy by mali mať definované podmienky dokončenia.
Zmeny by mali mať svoj proces. Nie preto, aby sa projektu bránilo v evolúcii, ale aby každý rozumel ich dopadu.
A komunikácia by mala byť pravidelná, ale účelná. Nie je potrebné organizovať meeting len preto, že je v kalendári.
Projektový manažment je súčasť produktu
Pri vývoji aplikácie sa veľa pozornosti prirodzene venuje technológiám, dizajnu a funkcionalitám. To všetko je dôležité.
Rovnako dôležité je však to, ako sa tieto časti stretnú v jednom projekte.
Zle riadený projekt môže mať skvelých developerov, kvalitný dizajn aj dobrý nápad a napriek tomu strácať čas na nejasnostiach, zbytočných revíziách a neustále sa meniacich prioritách.
Dobrý project management pritom nemusí znamenať viac dokumentov, viac meetingov alebo komplikovanejšie procesy.
Často znamená presný opak:
menej nejasností, menej zbytočnej práce a viac času venovaného samotnému produktu.
A práve to je jeho skutočná hodnota.