Jak mogę otrzymać wynagrodzenie za zmniejszenie zadłużenia technicznego?

Obecnie pracuję dla małej firmy, która ma niewiele skomplikowanych technicznie produktów. Jestem jedynym programistą dla jednego z nich. Około rok temu dostałem starszą wersję produktu i zacząłem go „wspierać”.

Klient mówi tylko o nowej funkcji, wartości biznesowej i innych tego typu. Problem polega na tym, że chociaż kod jest w języku C #, jest dość proceduralny. Nie ma żadnych abstrakcji, klasy są używane tylko tam, gdzie wymaga tego Visual Studio - na przykład formularze. Implementacje tych klas są naprawdę okropne, a kod naprawdę trudny do utrzymania.

Przez cały rok spędzam swój czas na refaktoryzacji. W najnowszej wersji są całkiem abstrakcje i takie tam. Musiałem ponownie wdrożyć wiele składników od zera i naprawdę czuję, że dodanie nowej funkcji lub zmiana zachowania tych elementów jest DUŻO łatwiejsze niż dla innych.

Problem polega na tym, że spędzam swój czas. Naprawdę lubię wyniki, ale nie lubię pracować 12 godzin dziennie. Czy byłeś kiedyś w podobnej sytuacji? Co powinienem spróbować Próbowałem już o tym dyskutować, ale nadal nie udało mi się.

Boję się tylko momentu, w którym zdecydujemy się wdrożyć nową funkcję, która wymaga wielu zmian w starszym kodzie. To może być szokujące dla klienta: dlaczego potrzebujesz 8 godzin na zmianę tych ikon? Klient po prostu nie dba o to, że w kodzie jest 500 miejsc, które muszę zmienić. I powinienem najpierw znaleźć te wszystkie 500 miejsc.

Jakieś pomysły?

Krok 1: Przestań pracować za darmo w nadgodzinach.

Już od roku szkoliłeś swojego klienta i menedżera, aby wierzyć, że należy oczekiwać obecnego tempa rozwoju. Jest to część powodu, dla którego nie rozumieją, dlaczego „prosta” rzecz może zająć cały dzień. Nie musisz trzymać ich jako zakładników i próbować zaszkodzić projektowi. Musisz jednak wyjaśnić, że ich oczekiwania są zbyt wysokie i potrzebujesz innego programisty lub więcej czasu przed upływem terminu. Zwróć szczególną uwagę na to, aby wspomnieć swojemu przełożonemu, że pracujesz za darmo w nadgodzinach i planujesz nie robić tego zbyt często. Nawet jeśli zmniejszysz go do 9 godzin, różnica zostanie zauważona. Jeśli kierownik zapyta cię, dlaczego nie wykonujesz swojej pracy, możesz wskazać, że zrobiłeś to, aby go ostrzec, że tak właśnie jest.

Krok 2: Rób notatki

To, że nie masz czasu na wykonanie pracy, nie oznacza, że ​​nie możesz jej ułatwić, gdy praca (miejmy nadzieję) zostanie wykonana. Śledź pomysły na poprawienie kodu i przywoływaj je na spotkaniach, aby inni wiedzieli o twoich obawach. W końcu trafisz w wolne miejsce lub ludzie zaczną rozumieć, że twoje obawy mają wartość. Kiedy ten czas nadejdzie, będziesz już miał kilka podstawowych pomysłów na to, co robić zamiast wyschnąć, ponieważ od jakiegoś czasu nie patrzyłeś na fragment kodu.

... kod jest naprawdę trudny do utrzymania.

To Twoja droga do zarządzania. Zademonstruj, że koszt „tylko” naprawienia błędów i dodania nowej funkcjonalności jest większy niż koszt refaktoryzacji i przepisania kodu.

Na przykład, jeśli przy obecnym kodzie dodanie nowej funkcji zajęłoby 2 tygodnie, a następnie utrzymanie znacznej ilości czasu (np. 1 dzień w tygodniu), pokaż, że dzięki tygodniowemu refaktoryzacji możesz wykonać rozwój w 1 1/2 tygodni, ale zmniejszysz koszty utrzymania do 1 dnia w miesiącu (lub krócej). Liczby te pokażą, że to, co robisz, jest opłacalne w perspektywie średnio- i długoterminowej, nawet jeśli koszty są krótkoterminowe.

Chociaż firma może nie lubić wydawania pieniędzy teraz, zobaczy, że potencjalne korzyści są znacznie większe - tj. Będziesz bardziej produktywny, generując więcej kodu w krótszym czasie i że ten kod będzie lepszej jakości.

Zastosuj zasadę harcerza : zostaw kod nieco bardziej uporządkowany (tj. Z mniejszym długiem technicznym) za każdym razem, gdy go dotkniesz.

Daj temu czas we wszystkich szacunkach, które podajesz. Następnie, w magiczny sposób, z czasem dług techniczny zniknie, a ty zapłacisz za to.

Takie podejście jest znacznie łatwiejsze niż jednoznaczne ograniczenie czasu (a tym samym przekonanie klientów / menedżerów do zapłaty) za dług techniczny. Daje to znacznie większe poczucie profesjonalizmu i „dobrze wykonanej pracy”. I na koniec, Twoi klienci i menedżerowie będą Ci za to wdzięczni na dłuższą metę, nawet jeśli nie do końca rozumieją, jak to się stało .....

To mniej więcej smutna rzeczywistość programowania konserwacji. Utknąłeś z tym, co przydzielono ci do utrzymania, a jeśli osoba płacąca rachunki nie chce płacić za zmiany, które uważa za zmiany bez korzyści, zmiany te zwykle nie są możliwe.

Jeśli chcesz uzasadnić finansowanie tych zmian, zrób dziennik wszystkich miejsc, które musisz zmienić, aby dokonać nawet najprostszej aktualizacji. Po kilku zmianach omów ten dziennik ze swoim menedżerem. Jeśli potrafisz to udokumentować, istnieje szansa (choć bardzo niewielka), że osoba z łańcuchami torebki zda sobie sprawę, że na dłuższą metę faktycznie taniej jest wyczyścić kod, ponieważ spowoduje to, że przyszłe zmiany będą tańsze.

Twoje szanse na sprzedaż wzrosną, im dłużej produkt będzie używany. Szanse rosną również, jeśli awaria produktu może spowodować problem public relations dla klienta lub kosztować pieniądze klienta.

Pomijając to, dowiedz się, co możesz i przejdź do innej pozycji przy mniejszej konserwacji.

Musisz pokazać swojemu zarządowi, w jaki sposób refaktoryzacja i inna poprawa produktu przyniesie korzyści firmie.

Klient raczej nie będzie dbał o to, czy kod jest piękny, czy brzydki, dopóki działa, a zarząd nie będzie chętnie wyjaśniał klientowi, że to, co już zapłacił, było źle zaprojektowane i źle wdrożone. Jednocześnie kierownictwo nie będzie chciało zużywać kosztów czasu opracowywania, który nie poprawi produktu w jakiś widoczny (rozliczalny) sposób.

Więc ... musisz przekonać kierownictwo, że proponowane przez Ciebie zmiany pomogą firmie:

• Pokaż, że lepsza architektura pozwoli Ci szybciej dodawać nowe funkcje.
• Wyjaśnij, że podążając bieżącą ścieżką, zamalują się w kącie.
• Podaj przykłady zmian, które są bardzo drogie w obecnym systemie, ale które byłyby proste i tanie z lepszym wyglądem.
• Śledź czas spędzony na utrzymywaniu starszego kodu zamiast dodawania przydatnych funkcji. - Pomóż im wyjaśnić obecnym i przyszłym klientom, że chociaż istniejący system był całkiem dobry, nowa, zmodernizowana architektura pozwoli na wiele wspaniałych nowych ulepszeń, lepszą niezawodność i tak dalej.
• Ogranicz ryzyko związane z proponowanymi zmianami. Menedżerowie są niechętni do ryzyka, a ogromne zmiany w istniejącym systemie wydają się z natury ryzykowne.
  • Priorytetyzuj modernizację różnych komponentów zgodnie z kosztami i korzyściami i upewnij się, że kierownictwo zgadza się z Twoimi priorytetami.
  • Użyj testów jednostkowych, aby upewnić się, że zmodernizowane komponenty będą kompatybilne z pozostałym starszym kodem.
• Śledź postęp prac modernizacyjnych. Pokaż korzyści tak szybko, jak to możliwe, ale przypomnij wszystkim stronom, że jest jeszcze wiele do zrobienia.

Być może nie zdajesz sobie z tego sprawy, ale Johnny Cash przewidział ruch refaktoryzacji i napisał piosenkę o najlepszym sposobie refaktoryzacji dużej istniejącej bazy kodu.

Oczywiście musiał owinąć go motoryzacyjną metaforą, aby jego publiczność mogła się do tego odnieść.

„One Piece at a Time” - Johnny Cash

Wygląda na to, że możesz obciążyć klienta za czas, w którym zmiana „powinna” przyjść i nadal wyjdzie Z DALA w perspektywie długoterminowej.

Jeśli podoba ci się czyszczenie kodu (i wydaje się, że robisz przynajmniej trochę), kontynuuj i kontynuuj, ale nie wypalaj się na nim. To nic ci nie da, twojej firmie ani innym klientom.

Upewnij się, że Twoje kierownictwo i wszyscy współpracujący z klientem wiedzą, że kod nie jest w najlepszej formie, aby mogli podjąć świadomą decyzję - tylko dlatego, że posiadasz ten kod, nie oznacza, że ​​powinieneś podejmować decyzje biznesowe na jego temat, jeśli nie są świadomi problemów z kodem, nie mogą wykonywać swoich zadań.

Chociaż aplikacja klienta ma pewne zadłużenie techniczne, nie zapomnij, prawdopodobnie zostały one naliczone z niewielką zniżką. Być może nie zostali o tym poinformowani, ale dzieje się tak, gdy wybierzesz najniższą ofertę.

Muszą zdecydować, czy chcą zapłacić pełną cenę za zmiany funkcji, czy też bez nich. To ich wybór. Możesz pozwolić im podjąć decyzję lub kontynuować pracę za darmo. Możesz spróbować wspomnieć o wykonanej pracy porządkowej i zaoferować niewielką zniżkę za ukończone prace. Ponownie, to ich wybór.

Podejdę do tego, zaczynając od wyjaśnienia koncepcji długu technicznego swoim szefom, aby upewnić się, że go dostaną. Podejdź do tego z dolnej linii, z perspektywy biznesowej. Za każdym razem, gdy żądają nowej funkcji, dług techniczny narastający w produkcie wpływa na wydajność, a zatem każda funkcja kosztuje nieco więcej z powodu tego długu.

Kiedy zrozumieją, o czym mówisz, spróbuj negocjować trochę czasu, aby poświęcić się zmniejszeniu zadłużenia technicznego. W mojej firmie odnieśliśmy spory sukces w składaniu petycji przez 10% czasu każdego programisty, aby pracować nad techniczną redukcją zadłużenia.

Gdy masz trochę czasu na pracę nad tym, upewnij się, że faktycznie go używasz (i nie pracuj tylko 10% nadgodzin, aby to zrobić - trzymaj się pistoletów). Utwórz katalog technicznych pozycji dłużnych i uszereguj je priorytetowo i zacznij rzeźbić. Musisz jeść słonia jeden kęs na raz.

I nie zapomnij o lepszych narzędziach. Resharper to świetne narzędzie do refaktoryzacji, które podłącza się do Visual Studio.