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

16

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?

Andrey Agibalov
źródło
3
Jakie jest Twoje pytanie? Jeśli jesteś pracownikiem, dlaczego masz ten kod i dlaczego sam go zmodyfikowałeś? Co chcesz? Aby otrzymać rekompensatę za niepłatny czas pracy nad nim? A może po prostu pracować mniej godzin? Czy Twój pracodawca wie, że wprowadziłeś usprawnienia we własnym czasie? Twoje pytanie jest bez odpowiedzi, ponieważ jest obecnie napisane.
Robert Harvey
3
OK, więc jakie jest twoje konkretne pytanie? Dlaczego chcesz zachować proceduralne, jeśli architektura, którą opracowałeś w swoim czasie, jest lepsza?
Robert Harvey,
8
Nie mówią w twoim języku, więc musisz nauczyć się ich. Tak to jest CZĘSTO. To nie jest powód do ucieczki, bo tak jest prawie wszędzie. Potrzebujesz półprawdopodobnego, ale wiarygodnego powodu, aby wprowadzić na pokład innego DOBRY koder, a następnie poświęcić czas na ponowną faktoryzację. W przeciwnym razie postaraj się uzupełnić własne szacunki i dodać czas na ponowną faktoryzację do dowolnego projektu robić. Ludzie biznesu zwykle mają gdzieś słabość. Niektóre zadania są w ich oczach większe niż inne. Wypełnij te „duże”. Aha, i nie zapomnij napisać testów :) Ponadto, nadal rób nadgodziny - invstmnt
Job
2
@Robert Harvey, pytający wie, jak postępować właściwie, ale utknął w czyimś gównie i jest jedynym, który widzi wiele zagrożeń, jest jedyną winą, gdy bzdury się psują. Mały biznes stara się przetrwać, a sprzedaż / przychody są agresywne, ale narastający dług techniczny go stresuje, a inni go nie zauważają. Potrzebuje mapy drogowej i wskazówek, jak wydostać się z tej dziury.
Job
1
Zmieniłem tytuł twojego pytania. Mam nadzieję, że nowy tytuł dokładniej odzwierciedla twoje zamiary. Nie jestem pewien, czy możesz odzyskać utracone godziny; Zrobiłbym to, co sugerują inni, i dodałbym trochę dopełnienia do niektórych twoich szacunków, aby były dostępne pieniądze na wprowadzenie ulepszeń.
Robert Harvey,

Odpowiedzi:

37

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.

unholysampler
źródło
to, co mówisz, to absolutnie świetne pomysły. Mniej więcej miesiąc temu postanowiłem dodać zadania do naszego narzędzia do śledzenia błędów. Nie obchodzi mnie, że to zadanie nie zostało potwierdzone, za każdym razem, gdy widzę potencjalny problem, dodam zadanie i powiadomię klienta. Następnym razem, gdy będę musiał naprawić coś, czego oczekiwałem jak najszybciej, po prostu przypominam klientowi o zadaniu, które już stworzyłem kilka miesięcy temu. Mam nadzieję, że to pomaga.
Andrey Agibalov,
17
„Przestań pracować za darmo w godzinach nadliczbowych” powinno obowiązywać, nawet jeśli absolutnie kochasz tę pracę. Nie korzystasz z dodatkowych godzin; oni są. Jeśli chcesz spędzić czas przed komputerem, zrób to dla swoich projektów, w domu.
Christopher Mahan
1
Po ponad dekadzie w tej branży wciąż nie „trafiłem w powolną łatkę”. Co ja robię źle?
sbi
@sbi Myślę, że może to być „robienie tego dobrze” :)
Stephen
13

... 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.

ChrisF
źródło
7

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 .....

mikera
źródło
Jednak takie podejście uniemożliwi dalsze znaczące refaktoryzowanie.
sbi
1
@sbi - byłbyś zaskoczony: jeśli masz dobre testy jednostkowe na miejscu i przyzwoity SCM do wycofania, możesz zrobić ogromną ilość w kontrolowanych, zweryfikowanych krokach. Kiedyś zmieniłem dużą (50+) hierarchię dziedziczenia na model oparty na prototypach w serii przyrostowych refaktoryzacji, z których żadna nie wymagała więcej niż kilku godzin pracy.
mikera
@sbi: Nigdy nie należy przeprowadzać znaczącej refaktoryzacji - wystarczy jedna zmiana / refaktoryzacja na raz. Małe jednostki pracy, małe zmiany i oczywiście przeprowadzanie wszystkich testów itp., Aby (podwójnie) upewnić się, że niczego nie zepsułeś.
Cthulhu
@Cthulhu: Jeśli masz dobre testy jednostkowe, możesz powalić i odbudować prawie tyle kodu, ile chcesz, ponieważ testy wychwytują większość błędów.
sbi
4

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.

Dave Wise
źródło
3

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.
Caleb
źródło
3

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

JohnFx
źródło
2

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ń.

DKnight
źródło
1
@robertharvey: tak, czyści kod w swoim własnym czasie, aby klient, który byłby obciążony kosztami aktualizacji, nie musiał płacić więcej, niż gdyby kod był dobrze napisany. Myślę, że jego firma musi zjeść większość kosztów (jeśli wystąpią). Rozsądne jest, aby klient płacił trochę czasu, ale jeśli przepłacisz, ponieważ kod to bzdury, to dobry sposób na utratę dobrej woli i przyszłej działalności.
DKnight
2

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.

JeffO
źródło
1

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.

RationalGeek
źródło
1

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

SnoopDougieDoug
źródło