Veľa požiadaviek. Veľa, veľa, veľa

Príbeh o tom, čo v dlhodobom horizonte spôsobí vaša odpoveď „Áno“.

Veľa roboty. Keby to nebolo o tom, že raz horí tu a raz inde. Ale horí vždy, všade a každý deň. Vyvíjame viaceré customizácie systému a naša apka už ani je je tým čo sme chceli. Veľa verzií, chyby opravené v jednej sa nestihnú dostať do ďalšej verzie.

Prečo je to tak?

Nooooo, na začiatku sme si predstavovali univerzálny produkt, ktorý poskytne klientom rôzne možnosti. Jeden produkt pre klientov rôznej veľkosti.

Aha. A podarilo sa?

Nie, kód začal byť veľmi zložitý, požiadavky išli proti sebe, systém sa nedá udržať. Jedna zmena spôsobí, že niektorí klienti prestanú fungovať. A tak ich radšej nechávame na starších verziách. A modlíme sa, aby nechceli nejakú verziu, ktorá bola publikovaná na webe. Keď sa to stane tak merguje, nestíhame testovať  a potom opravujeme.

Pravdupovediac nás už to ani nebaví. Furt dookola.

Hmm, a čo tak rozdeliť produkt na viaceré?

Huuuuuuh? Si sa zbláznil?

Prečo je to tak?

Príčiny tejto situácie nie sú ani tak v malom počte ľudí, ako si väčšina myslí, alebo  v zlom nastavení tímu, ale:

1. V zlej stratégii. Produkt je od začiatku pre všetkých. Pre malých aj veľkých klientov. V rôznych segmentoch. S absolútne inými potrebami.
2. Klientom mal produkt pomáhať s komplexným tokom hodnoty (value flow). Teda robiť všetko. Produkt sa stal brutálne zložitý​ a ťažko udržiavateľný.
3. Produkt používa veľa rolí. S rôznymi skúsenosťami s používaním IT. Jedni by potrebovali advanced vlastnosti, iní budú v nich stratení.
4. Klienti priamo navrhovali správanie produktu, jeho vlastnosti. Tím bol veľmi rád, že klienti komunikujú a robili  pre nich čo najviac. V podstate žiadna odpoveď NIE. Žiadna otázka Prečo? Aký problém chcete riešiť?
5. Produkt nebol dizajnovaný modulárne. Nerozšíriteľná architektúra spôsobila mikádo kód (tu už ani špagety nenájdete).
6. Žiaden poriadny setup Gitu, nesprávne používanie princípov verzionovania. Súbory nekomitované ako changeset, ale po súboroch. Áno, v dnešnej dobe, do prčic.
7. Používanie produktu nebolo merané. Rozširovali sa aj vlastnosti, ktoré v podstate používal iba jeden dvaja klienti. Doslova. Ostatní to dostali ako free upgrade. Veď nice to have, aj tak to nepoužijú.
8. Kvôli zložitosti sa začali používatelia strácať v produkte. Ale to nič, napíšeme manuál, nahrávke videjko, spravíme kólcentrum….
9. Staré vetvy sa neodrezávali a energia tak nešla do ovocia. Neodstraňovali sa nepoužívané vlastnosti.

Entropia rástla a rástla a rástla. Až produkt sa stal neudržateľný, klienti začali byť nespokojní kvôli kvalite a trvaniu dodávok, vývojári na nervy, rezignovaní. Žiaden čas na refaktoring, žiadna výzva, zaujímavosť, zábava. A tak začali aj oni opúšťať loď.

Rady

• Zmapovať si klientov a používateľov. Napr. s pomocou Lean canvas, alebo business model canvas a pomocou value proposition.
• Nadizajnovať produkt tak, aby používateľ pri svojom raste ľahko prešiel na vyššiu verziu pluginmi, modulmi. My sme takto postavili ScrumDesk Start. Pre začiatočníkov majú k dispozícii podporu Scrum. Ako rastú, ich produkty sú zložitejšie a preto potrebujú hierarchiu požiadaviek, roadmapy, custom fields a pod. Neskôr si môžu dokúpiť modul ProductDesk, ktorý je síce integrovaný, no v podstate vyvíjaný ako samostatný produkt s podporou platformy.
• Prejdite na git (alebo niečo podobné) čo najskôr. Naučte sa gitworkflow.
• Produktový vlastník má rozbiť požiadavky na malé. Preveriť si, že vôbec riešia problém daného segmentu.
• Merajte požívanie od samého začiatku. V podstate by to malo byť default súčasťou úlohy. Aby tento vedeli vyhodnocovatlť, ktoré časti ďalej rozvíjať.
• Už naprogramované produkty nemusíte refaktorovať vo veľkom. Pomaly ďalej zájdeš. V každom šprinte po trochu. Najprv spraviť moduly, nadizajnovat interfaces, potom začať meniť moduly. 20% vlastností používaných 80% času.
• Snažte sa vyvíjať malé vlastnosti.  Dodávajte časti pravidelne, najlepšie denne. Aby ste rýchlo zistili či zmenený kód funguje.
• Investujte najmenej 20% do rozvoja. Ak nie, o rok dva už nebude income.

Najdôležitejšie je stretnúť sa s používateľmi a počúvať ich. Nerobiť však všetko čo hovoria. Snažiť sa pochopiť čo potrebujú riešiť. Veď riešenia môžu byť nakoniec jednoduchšie aj drahšie. A oni sami začnú chápať, že menej je viac. Že ste ich partnermi, ktorí im pomáhajú s ich biznisom a nielen dodávatelia, ktorí inkasujú.

…. A teda, ako menej?