Jak zmierzyć potencjalną wartość refaktoryzacji

Jak w wiarygodny sposób oszacować lub zmierzyć korzyści wynikające z refaktoryzacji kodu w starym, dużym projekcie z zadłużeniem technicznym?

Załóżmy na przykład, że masz niektóre komponenty w stosie oprogramowania napisane w starszym języku, a niektóre późniejsze komponenty w nowszym języku. Zespół programistów stale dodaje do tego rozwiązania nowe funkcje i poprawki błędów.

Deweloperzy sugerują, że zastąpienie istniejących komponentów starego języka nową wersją byłoby „dobrą rzeczą”. Jednak ta praca nie dodałaby żadnych dodatkowych funkcji i będzie kosztować x dni roboczych.

Sprzedawca sugeruje dodanie „świetnej nowej funkcji”. firma mierzy wartość swojej sugestii za pomocą formuły. to znaczy. Będzie zarabiać firmę F milionów funtów, w ciągu t lat, kosztem x dni roboczych

W jaki sposób firma może w znaczący sposób kosztować propozycję refaktoryzacji? i w jakich okolicznościach jest to najbardziej opłacalna opcja dla firmy?

Będzie zarabiać firmę F milionów funtów, w ciągu t lat, kosztem x dni roboczych

To ignoruje koszty utrzymania, koszty wsparcia, koszty sprzedaży / marketingu i zawiera wiele założeń dotyczących tego, jak ta funkcja zostanie wykorzystana na rynku.

Ale cokolwiek; twoje pytanie jest wystarczająco jasne na temat tego, czego szukasz:

Jak zrobić uzasadnienie biznesowe do refaktoryzacji?

Najważniejsze, aby zdać sobie sprawę, że czas to pieniądz. Możesz przejść bezpośrednio do „5 programistów 2 tygodnie = 80 godzin * 5 programistów * 50 USD / godz. -> 20 000 USD”, co ma sens dla ludzi biznesu. Inteligentni ludzie biznesu zauważą, że tych 5 programistów otrzymuje wynagrodzenie w obie strony, co oznacza, że ​​nie wydaje się / nie oszczędza 20 000 USD - wykorzystuje 20 000 USD w najbardziej dochodowy sposób. W każdym razie, dalej z listą.

• Wydajność - przypuszczalnie można uzyskać więcej rzeczy dzięki C # niż VB6. Lepsze oprzyrządowanie, lepsze biblioteki, cokolwiek. Nowsze technologie są zazwyczaj lepsze od starszych. Jeśli możesz zrobić rzeczy w krótszym czasie, oznacza to, że oszczędzasz pieniądze firmy.
• Koszty ogólne - Kodowanie to nie jedyny koszt oprogramowania. Zastanów się, co się stanie, gdy wyjdzie system Windows 2020. Ile czasu i wysiłku poświęcisz na pracę nad aplikacją VB6? Ile to więcej czasu i wysiłku niż aplikacja C #? To oszczędza pieniądze Twojej firmy.
• Jakość - przypuszczalnie można wykonać rzeczy z wyższą jakością w C # niż VB6 (lub z czystszą architekturą lub czymkolwiek innym, co jest twoim celem refaktoryzacji). Wyższa jakość oznacza mniej błędów. Mniej błędów oznacza mniej kosztów naprawy tych błędów, niższe koszty obsługi klienta w celu rozwiązania tych problemów, mniej strat klientów z powodu problemów z jakością, zwiększoną sprzedaż dzięki reputacji jakości ... wszystkie dolary dla Twojej firmy.
• Oszczędności HR - Spójrzmy prawdzie w oczy: nikt nie chce pracować z tą gównianą aplikacją VB6. Oznacza to, że więcej osób opuści firmę, prowadząc do czasu i pieniędzy wydanych na ich zastąpienie. Oznacza to, że zatrudnienie nowych pracowników zajmuje więcej czasu i pieniędzy. Co najgorsze, oznacza to, że będziesz mieć programistów, którzy całkowicie popełniają samobójstwo w pracy z tą aplikacją VB6. Ci programiści z kolei przyspieszają spiralę śmierci problemów z jakością. Skrócenie czasu rotacji i wynajmu oszczędza pieniądze Twojej firmy. Trzymanie się z dala od samozadowolenia i gównianych programistów ratuje Twoją firmę.
• Morale - Podobnie, programiści, którzy już tam są, nienawidzą pracy w VB6. Zrobią to, a może nawet zrobią to dobrze. Ale to jest do bani. Może nie dla wszystkich, ale na pewno dla niektórych. Oznacza to więcej czasu spędzonego na przeglądaniu sieci w celu odzyskania motywacji. Oznacza to dłuższe obiady. Oznacza to mniej robienia rzeczy, podczas gdy programiści potrzebują więcej czasu na regenerację po podstępnej pracy.
• Możliwości - Jest to mniej przydatne w przypadku reaktorów opartych na technologii, ale dotyczy architektury typu reaktorów. Niektóre problemy z kodem aktywnie uniemożliwiają udostępnienie fajnej funkcji X, która pozwala zarobić mnóstwo pieniędzy. Może nie możesz skalować. Może nie możesz uzyskać danych, aby zrobić fajną informatykę. Być może kod jest takim gniazdem szczura, że ​​zabicie jest naprawdę trudne do wykonania. Cokolwiek. Czasami jesteś w tym momencie, czasem jedziesz prosto do tego punktu. Trudno to przełożyć na język biznesowy, ale jeśli potrafisz, „ten problem uniemożliwia nam korzystanie z możliwości X, Y i Z” może być potężny.

Podsumowując, sprowadza się to do: „te rzeczy pomogą nam lepiej wykonywać naszą pracę; jeśli wykonamy naszą pracę lepiej, możemy zarobić / zaoszczędzić więcej pieniędzy”.

Pytanie, które powinieneś sobie zadać, to skąd sprzedawca wie, że ta funkcja będzie kosztować x dni pracy programisty. Biorąc pod uwagę, że nawet dobrzy kierownicy projektów z wieloletnim doświadczeniem zawodowym często nie mogą tego powiedzieć, takie dane pochodzące od sprzedawcy wydają się niezwykle ... spekulacyjne .

Zgodnie z moim doświadczeniem sprzedawcy zwykle nie dokonują szacunków, ale zgadują, ile to za dużo dla kierownictwa lub klienta: jeśli kierownictwo jest gotowe zapłacić 50 roboczotygodni, ale absolutnie odrzuci 75 osobodni, powiedzmy że ta funkcja zajmie 70 osobodni, podczas gdy będzie gotowa do renegocjacji (co jest niemożliwe do oszacowania), do 55 osobodni.

• Z jednej strony masz szacunki wykonane przez ekspertów IT, którzy mówią coś takiego:

  Zgodnie z tym konkretnym audytem marnujemy 8 000 USD dziennie przy użyciu przestarzałej technologii w porównaniu do podobnych projektów o podobnej wielkości, które wykorzystują nowsze technologie. Wydaje się również, że migracja całej bazy kodu zajmie od 50 do 80 osobodni. w tym czasie nie zostaną wydane żadne nowe funkcje. Istnieje również 10% ryzyko, że migracja określonego komponentu może spowodować 20-30 dodatkowych tygodni pracy.

• Z drugiej strony masz domysły sprzedawców, oparte na ich dźwigni podczas negocjacji z osobą, którą muszą przekonać.

Wszystko zależy od tego, jak wpływowy jesteś w swojej firmie. Komunikacja jest tu kluczowa i tutaj sprzedawcy zwykle zdobywają specjalistów IT, jeśli chodzi o wyjaśnienie korzyści danej funkcji zarządowi (lub klientowi).

Pamiętaj, że jeśli w przeszłości twoje szacunki były dość dokładne, zyskasz reputację i wpływy. Jeśli twoje szacunki były zawsze błędne, kierownictwo prawdopodobnie zignoruje twoje propozycje.

Jeśli chodzi o szacunki, niezwykle trudno jest tutaj uzyskać wartościowy, ponieważ należy wziąć pod uwagę ogromną liczbę parametrów. Pośród innych:

• Czy faktycznie wiesz, jak umiejętny jest Twój zespół w C # w porównaniu do VB6? Czy opiera się na rzeczywistych pomiarach, czy tylko zgaduje?

• Czy ten zespół opracował duże projekty w języku C #? Czy znają narzędzia, których powinni używać (IDE, debuggery, profilery itp.)? Czy potrzebujesz dodatkowych licencji (które w świecie Microsoftu oznaczają tysiące dolarów na maszynę)?

• Czy obecny projekt jest całkowicie jasny i czy możesz zagwarantować, że migracja nie przyniesie niespodzianek? Czy łatwo jest przepisać wszystko , każdą funkcję, czy też będą niespodzianki?

• Czy masz infrastrukturę obsługującą język C #? Co z ciągłą integracją? Co z twoim serwerem kompilacji? Przewodniki po stylu? Statyczne warcaby?

• Czy podczas produkcji serwery (jeśli jest to aplikacja internetowa) lub komputery klienckie (jeśli jest to aplikacja komputerowa) mogą obsługiwać wersję systemu .NET Framework, której oczekujesz?

Ale najważniejsze jest, aby wiedzieć, dlaczego chcesz przepisać wszystko. Jaki problem próbujesz rozwiązać poprzez przepisanie? Utrata wydajności? Jak to mierzysz? Jak pokazać zarządowi tę utratę produktywności?

Gdy już wykażesz, że marnujesz, powiedzmy, 8 000 USD dziennie z powodu VB6 (co oznacza, że ​​zaoszczędzisz 8 000 USD dziennie po migracji do C #), jak wyjaśnisz korzyści wynikające z posiadania każdej nowej funkcji rozwoju i koncentrujesz się na całkowitym przepisaniu? Jaka jest korzyść w porównaniu z progresywnym przepisywaniem, w którym migrujesz komponenty w małych porcjach jeden po drugim, jednocześnie dostarczając nowe funkcje?

Po pierwsze, należy oszacować koszt deweloperski ponownego faktorowania, tak jak w przypadku żądania funkcji opartego na sprzedaży.

Może to być trudne do uzyskania dokładności, jeśli jest to duża praca, ale zakładając, że masz wystarczająco doświadczonych ludzi w 2 technologiach, powinno to być wykonalne.

Po drugie, musisz oszacować koszt nieprzerejestrowania. Jeśli robisz dla mnie szacunki, oczekiwałbym pewnego poziomu wskaźników. Na przykład różnica między średnim kosztem tworzenia kodu VB i kodu C # w ciągu jednej czwartej. Lub niektóre takie. Będzie oczywiście zależeć od tego, jak dokładnie to wyśledzisz.

Za pomocą tych 2 liczb możesz oszacować okres spłaty, który zapewni ci faktoring, tzn. W którym momencie faktoring zostanie zmieniony z kosztu netto na zysk netto.

Mogę tylko zgadywać, jak przekonujący byłby dany wynik. Jeśli jednak minie mniej niż rok, prawdopodobnie będzie dość silny, znacznie dłużej niż 2 lata, więc możesz z tym walczyć.

Ponadto prawdopodobnie warto dodać inne wymiary, aby pomóc w budowaniu swojego przypadku. W przeszłości korzystałem z tego, czy w wywiadzie wyjazdowym wymieniano technologię jako kierowcę. Jeśli tak, możesz argumentować, że faktoring zostanie zatrzymany przez personel (zatrudnienie i szkolenie są bardzo drogie).

Oczywiście można argumentować te rzeczy bez poparcia dowodów, ale uważam, że może to mieć ogromny wpływ na wpływ sprawy.

Wartość refaktoryzacji pojawia się na wiele różnych sposobów.

Pomaga później wprowadzić inne zmiany, więc ukończenie X dni, które zajęłaby ta funkcja, zajęłoby 2/3 X dni. Aby użyć zwinnej terminologii, zwiększa prędkość.

Wymieniona wyraźna zmiana z czasem pomógłaby, ponieważ nie trzeba już utrzymywać programistów z doświadczeniem VB6, tylko tych z doświadczeniem C #.

Pomaga również w innych mniej namacalnych sposobach, takich jak utrzymanie personelu i rekrutacja. Czy praca wykonująca C # i VB6 byłaby mniej lub bardziej atrakcyjna niż praca wykonująca tylko C #? Czy byłbyś mniej lub bardziej skłonny do podjęcia pracy lub pozostania przy pracy w oparciu o dobrą bazę kodu lub kiepską?

Myślę, że punktem, za którym tęsknią inne odpowiedzi, jest to, że musisz zmierzyć koszt refaktoryzacji w stosunku do utraconych przychodów z braku refaktoryzacji.

Refaktoryzacja ze względu na zmianę kodu jest stratą czasu. Musi wnieść wartość do stołu. W tym kontekście nie mam na myśli spędzenia godziny na refaktoryzacji klasy problemów, ale na głównych refaktoryzacjach, takich jak zmiana na inny język CLR, jak użyłeś w swoim przykładzie.

• Jeśli nadal robimy to, co robimy, czy coś nam brakuje? Czy istnieje jakiś stary, kruchy projekt, który powstrzymuje nas przed uświadomieniem sobie wartości? Na przykład, jeśli chcemy dodać funkcję, czy jest to tak trudne, że wdrożenie może zająć np. 100 godzin, a refaktoryzacja 50 godzin, a wdrożenie nowego projektu - 25 godzin?

• Czy istniejący kod pociąga za sobą dług techniczny, który kosztuje nas pieniądze? Czy ten gówniany stary kod jest źródłem błędów? Czy z tego powodu pracujemy za darmo, aby naprawić problemy? Nikt nie lubi rozdawać intratnych płatnych godzin za darmo.

• Czy koszt refaktoryzacji jest równy lub mniejszy niż koszt braku refaktoryzacji?

• Czy można amortyzować koszty, skoro mały zespół rockstars refaktoryzuje kod, powodując najwięcej problemów? Czy możemy rozłożyć refaktor na poszczególne wersje? Wszędzie występują małe nieefektywności: czy możemy „uzupełnić luki”, żeby tak rzec, z dodatkowym dziełem?

Korzyści z posiadania refaktoryzowanego systemu

Przedstawiasz uzasadnienie biznesowe dla refaktoryzacji, porównując korzyści biznesowe pomiędzy robieniem a nie robieniem tego. Oznacza to albo zmniejszenie bieżących rzeczywistych kosztów, albo zwiększenie przyszłego rzeczywistego napływu środków pieniężnych.

Najważniejsze pozycje w budżecie, na które wpływa refaktoryzacja, są następujące:

• Koszty utrzymania - jeśli obecny system to delikatna kupka spaghetti, a w praktyce można zaobserwować, że naprawianie drobnych błędów (zarówno w fazie rozwoju, jak i operacji) wymaga dużej liczby roboczogodzin, można oczekiwać, że koszty takiego konserwacja będzie mniejsza dla „właściwie przeprojektowanego” systemu. Zobacz, jakie są twoje roczne koszty czystej konserwacji i jak mogą się realistycznie zmienić po przepisaniu.

• Koszt dodania nowych funkcji - ponownie, jeśli obecny projekt i struktura systemu powoduje, że pisanie nowych funkcji jest nadmiernie czasochłonne, przepisywanie może zapewnić oszczędności. Spójrz na swój planowany budżet na nowe funkcje, ale bądź realistą - jeśli twierdzisz, że zobaczysz 50% poprawę, spodziewaj się, że faktycznie opracujesz funkcje w x osobo-miesiącach, których realizacja zajęła wcześniej 2 * x osobo-miesięcy; takie obietnice mogą być trudne do dotrzymania.

• Wpływ jakości oprogramowania na sprzedaż - jeśli obecny system często powoduje problemy widoczne dla klientów, np. Awarie lub przestoje pomimo odpowiednich prac konserwacyjnych, wówczas przepisanie może być rozwiązaniem. JEŻELI jest to poważny problem, to ci sami sprzedawcy mogą określić wartość „funkcji” zwanej „bardziej stabilnym produktem”.

Jeśli powyższe trzy punkty nie osiągną oczekiwanego kosztu przepisania (i więcej; koszt alternatywny spędzenia x dni deweloperskich na niefunkcjach jest równy wartości tych funkcji, która jest większa niż czysty koszt x dev -dni), obawiam się, że to wszystko - oczekiwane oszczędności nie uzasadniają przepisania.

Ponadto, jeśli twoja mapa drogowa nie pokazuje potrzeby „tyle, ile możesz zapewnić” nowe funkcje, wówczas oszczędności powinny mieć formę „zwykło to robić 10 osób, aby wykonać wszystkie wymagane czynności, ale po przepisaniu „Będę mógł zrobić to samo tylko z 6 osobami” . Jeśli możesz „sprzedać” więcej projektów deweloperskich niż masz programistów, to poprawa wydajności pozwala ci rozwijać więcej rzeczy, ale jeśli firma z obecnymi zasobami jest już w stanie opracować wszystkie rzeczy, które przynoszą dodatkową wartość, to jedyna korzyść finansowa może pochodzić z płacenia mniejszej liczby osób lub posiadania tańszych osób.

Wartość refaktoryzacji można zmierzyć w ten sposób: obecnie nowa funkcja x będzie kosztować 5 programistów 2 tygodnie. Jeśli zmienimy stary komponent, koszt nowych funkcji zostanie zmniejszony o około 20%. Nowa funkcja x kosztuje tylko 4 deweloperów w ciągu 2 tygodni.

Refaktoryzacja to inwestycja w obniżenie kosztów przyszłych rozwiązań. Jeśli nie możesz argumentować za refaktoryzacją, prawdopodobnie nie ma na to uzasadnienia biznesowego.