Jak na technický dluh

Technický dluhNo jo, jsem pořád tady. Ač mi pozice vedoucího vývoje dává k programování zhruba stejně prostoru, jako manželka na pivo s klukama, stále mám pár es v rukávu. V tomto zamyšlení bych se pokusil vyjádřit své naivní pocity ohledně problému starému jak programující lidstvo samo. Ať už Vás bičuje Váš Scrum master, Projekťák, Produkťák nebo manželka, pointa je stejná. Všichni chtějí nové krásné věci. Jenže vy moc dobře víte, že to takhle prostě pořád nejde.

I když budete dělat všechno skvěle, což dokáže jen pár lidí a já, stejně se dřív nebo později dostanete do situace, kdy jsou prostě Vámi použité technologie a postupy zastaralé. Nová verze Reactu vychází častěji než demonstrace proti Babišovi, LTSka Linuxu či NodeJs jsou o něco pomalejší, ale všechno tohle dohromady je pořád mnohem rychlejší než výstavba jednoho kilometru dálnic v České Republice. Problém ale je, že ten obchodník v křesle, s telefonem u ucha, co by prodal i vlastní babičku o tom nemá ponětí. A ani vlastně nechce. On chce prodávat, on chce vydělávat. Včera bylo pozdě. A je to vlastně špatně?

Krátká odpověď. Není. Když vydělává on, pravděpodobně i dostanete výplatu a až si příští týden půjdete říct o víc, máte určitě vetší šanci, že příští rok vezmete maminku dál, než do Chorvatska. Technický dluh je ale nenažraná sviňa, která se zvětšuje každým dnem, aniž by jste ji museli krmit. Zvládá to totiž sama. A teď tedy vážně, co s tím?

Postupné vylepšování

Pokud se Váš produkt ještě nedostal do technického kómatu, tak je možno zvážit variantu postupného vylepšování a malých refactoringů. Prvním a nejdůležitějším krokem v této situaci je třeba dobře stanovit Vaši situaci a to, kam chcete Váš produkt dostat. Chcete jen získat další rok navíc nebo se jedná o dlouhodobý produkt, který je třeba držet při životě ještě deset let? Pokud nejste v pozici, kdy dokážete toto objektivně posoudit, je Vaším prvním úkolem najít ty, kteří to dokážou. Ať už je to projektový manager, produktový manager nebo věštecká koule. Dalším důležitým krokem je dobře naplánovat jak přesně bude vylepšování probíhat. Zde bych zmínil jedno velmi šikovné skautské pořekadlo:

„Zanech tábořiště v lepším stavu, než jsi ho našel.“

V našem případě je to ale krapet složitější, protože k tomu budete potřebovat kompetentní vývojáře. Ono se totiž dost snadno může stát, že ti co zrovna máte k dispozici jsou ti samí, kteří se podíleli na technologickém deficitu. Určitě nechci generalizovat, ale je potřeba tuto možnost efektivně posoudit, ne nadarmo se říká:

„Starého psa novým kouskům nenaučíš.“

No a pro natvrdlé vývojáře to platí taky 🙂 Nespornou výhodou tohoto řešení je, že to neznamená stopku pro nové features, jen je jejich dodání pomalejší.

Znovu od nuly

Další, pro vývojáře velmi atraktivní alternativa. Druhý (případně třetí) pokus. Alias „A teď znovu a doopravdy“. Dá se jim ale věřit? No jak kdy. Pokud opravdu uvažujete o přepisu projektu od nuly, je třeba si uvědomit, že to bude hodně práce i na celý team okolo. Bude třeba zpětně prozkoumat a rozkrýt jak každé zákoutí aplikace vlastně pracuje a proč. Dalším nepříjemným side efektem je stopka pro vývoj nových věcí. Jasně, jde to i bez toho, ale to zbytečně prodlouží čas potřebný pro přepis. Veškeré takové úpravy systému budou vývojáři dělat dvakrát. Na starém i na novém. Not cool.

Pokud se rozhodnete postupovat tímto směrem, je naprosto zásadní mít po ruce kompetentní vývojářský team, který vám zaručí, že to co Vám dodá bude opravdu lepší a moderní. Vhodným řešením může být team obohatit o nové moderně naladěné duše. Nebo můžete vytvořit úplně nový team, který bude mít nový projekt na starosti. Zde si ale dejte velký pozor. Pro Vaše stávající vývojáře to může znamenat kopání vlastního hrobu a s tím související nelibost a nespolupráci.

Outsourcing

Pro vývojáře nejméně oblíbené řešení, které představuje konečnou. Když si spočítáte, že interní náklady na řešení technického dluhu jsou větší než projekt outsourcovat, utíkejte tímhle směrem. Vybírejte ale dodavatele velmi pečlivě a počítejte s tím, že z manažerského hlediska bude toto řešení nejnáročnější. Ideálně si k cenové analýze přizvěte i vývojáře, který Vám pomůže odhadnout kvalitu a vlastnosti kupovaného projektu. Opět bude třeba rozkrýt veškeré funkcionality Vašeho produktu. Práci Vám bude komplikovat složitá komunikace s potenciálním dodavatelem. Z mé zkušenosti můžu říct, že se často stává, že realita bývá oproti slibům dosti jinde a co si nepodepíšete, jako by nebylo. A občas ani to co si podepíšete. Dbejte i na domluvení adekvátní spolupráce po dokončení projektu. Dodavatel se pak často začne soustředit na jiný projekt a vás přehodí na odstavnou kolej.

 

Ať už se rozhodnete pro jakékoliv řešení, držím Vám palce 🙂

PS: Veškeré sarkastické poznámky o manželkách (speciálně té mojí) nejsou založeny na pravdě a jsou smyšlené za účelem zvýšení zajímavosti článku. Všem účinkujícím se tímto omlouvám. Při psaní článku nebylo ublíženo žádnému zvířeti. Třiďte odpad.

Napsat komentář

Vaše emailová adresa nebude zveřejněna. Vyžadované informace jsou označeny *