Na tento nedostatok riadenia vyvoja “na mieru” narazam prakticky od zaciatky kariery, ale doteraz som sa s tym nevysporiadal, tak ma zaujima ci a ako to riesite vy.
Pride klient s nejakou novou feature, spyta sa kolko to bude stat implementacia, team da nejake cislo a podla toho sa klient rozhodne.
Chyba tam ale podla mna este dolezitejsi parameter ako cena implementacie - ako sa zvysi komplexnost systemu - rozne zavislosti (napr na tretich stranach), technicky dlh, znizia rozne -ility (maintanability, testability) a podobne.
Castokrat je tento druhy parameter nepriamo umerny nakladom na implementaciu - lacnejsie rychle riesenie zvysuje komplexnost, narocnejsie riesenie ju moze naopak znizit.
Ak ale klient pozna iba prvy parameter, tak vzdy zvoli lacnejsie riesenie. Keby poznal aj druhy, tak mozno zainvestuje, alebo si povie, ze to ta feature nestoji zato.
Otazka: Ma ten moj “druhy” parameter nejaky nazov? Ako ste sa s tym vysporiadali vy?
My mám len inhouse vývoj, ale tiež sa s tým podotýkam. Najlepšie je sa naučiť hovoriť nie a niekedy byť za toho zlého. Ale je to aj o dôvere. To nie musím mať zdôvodnené, buď cez náklady na neskorší support a vývoj, alebo to, že na to nemáme personálne kapacity.
Najskor som si myslel, ze hladas je udrzatelnost/maintability, no po nejakom uvazovani by som to cele nazval technicky dlh. To je nieco comu by mal rozumiet aj druha strana, popripade vyvetlit, ze ten dlh bude raz treba splatit.
A suhlasim s @vlko je velmi velmi velmi dolezite hovorit Nie. Uz velkrat som videl, ked sa na vsteko zakaznikovi povedalo ano… nakoniec je to bolest pre vsetky strany (hlavne tie co to implementuju).
Termin technicky dlh neporkyva napr.:
Klient: “Kolko by stalo vytvorenie REST API do nasho interneho systemu pre nasich zakazikov”
Ja: “REST API uz vlastne mame, staci ho spristupnit, to je 0.5 manday, ale…”
S tym hovorenim NIE suhlasim, ale len ciastocne. Tak ako oni nevedia vyhodnotit skutocne naklady, tak zasa ja neviem vyhodnotit business value.
Stalo sa mi, ze som na nejaky feature request povedal nie, lebo sa mi to zdala blbost vzhladom na “technicky dlh”, ale ked som videl uzivatelov realne v praxi, ako by sa im to zislo, tak som im to dokodil vecer zadarmo.
Chces povedat, ze to mozes richlo a lacno “naprasit” (spritupnit vsetkym aktualne interne API), alebo to spravit poriadne dlhsie a drahsie (verzovane, zdokumentovane API, ktore je zrozumitelne aj pre externych ludi)?
Nielen to. Moze to byt spravene aj kvalitne, ale zaroven to prinesie do projektu zataz (komplikovanejsia schema v databaze, zlozitejsie dotazy, vynimky z pravidiel, zavislost na nejakej kniznici, zviazane ruky pri refactoringu (public api nemozem menit) a podobne