Zaskakująca liczba problemów z jakością, skalowalnością i obciążeniem pojawiła się w aplikacji, którą obecnie obsługuję, której pierwotnie nie napisałem. Na szczęście mam nowe projekty, które realizowałem od podstaw, aby zachować pozory mojego zdrowego rozsądku.
Pierwotny zespół składał się z 20 programistów (większość z nieaktualnymi zestawami umiejętności), bez dokumentów wymagań biznesowych lub testerów zapewniania jakości i od samego początku źle zarządzanych w sposób wodospadowy. Wczesne dni produkcji były krępującym koszmarem, który wymagał łatania kruchego kodu proceduralnego za pomocą jeszcze większej liczby kruchych poprawek. Później dodano funkcje, które zostały wpuszczone w model danych, który nigdy nie miał ich obsługiwać i często zdarza się, że ten sam kod jest powielany 10 razy, a zasoby nie są bezpiecznie zamykane, a zapytania ORM, które pobierają dziesiątki tysięcy jednostek, wyrzucić wszystko oprócz garstki.
Teraz jestem tylko ja i za każdym razem, gdy pojawia się nowy problem, przepisuję moduł na lepsze standardy i sprawiam, że DUŻO jest on bardziej stabilny, ale Zarząd potrzebuje odpowiedniego wyjaśnienia, dlaczego to wszystko się dzieje.
Wydają się zszokowani i zakłopotani myślą, że ta aplikacja jest niskiej jakości i tonie w długach technicznych. Na szczęście rozumieją koncepcję długu technicznego i wspierają mnie w dążeniu do jego zlikwidowania, a także bardzo mnie wspierają i doceniają, ale czuję się tak, jakbym wciąż obwiniał oryginalny zespół (który zszedł, by zrujnować inny projekt w innym podział).
Najważniejsze jest to, że nie chcę być „tym facetem”, który zawsze narzeka na deweloperów projektu przed nim. Widziałem już wcześniej taką postawę od ludzi w mojej karierze, którzy osobiście uważałem, że byli ignorantami i nie brali pod uwagę okoliczności i wpływów projektowych, które zachęcały do bycia takimi, jakie były.
Zazwyczaj widzę to podejście polegające na obwinianiu poprzedniego zespołu za kiepski projekt i wdrożenie od idealistycznych młodszych programistów, którzy nie mieli doświadczeń życiowych, z których korzystało więcej starszych członków.
Czy uważasz, że istnieje lepszy, być może łagodniejszy sposób zgłaszania tego rodzaju problemów kierownictwu, bez narażania reputacji osoby / zespołu przed tobą?
źródło
bad-codeponieważ kod rzeczywiście powoduje błędy i problemy. Oznaczyłem to,bad-programmerponieważ obawiam się, że staję się jednym, obwiniając poprzedni zespół, zmęczoną i oklepaną wymówkę, o której wszyscy wcześniej słyszeliśmy. Jeśli chodzi o pierwsze trzy akapity, być może nie musiałem być tak opisowy, ale chciałem namalować dokładny obraz mojej bezpośredniej sytuacji i podać historię tego, co do tej pory zebrałem.Odpowiedzi:
Dług techniczny jest jak dług finansowy. Przyjmujesz to (miejmy nadzieję) strategicznie podczas opracowywania programu z zamiarem, że zostanie on spłacony w przyszłości. Czasami ludzie podejmują złe decyzje dotyczące długu technicznego (np. Uruchomienie karty kredytowej), ale czasami pewna ilość długu technicznego jest po prostu normalna. Decyzja, aby nie poświęcać dzisiaj czasu na „właściwe” podejście, przy założeniu, że w przyszłości będzie trzeba to zmienić, jest całkowicie normalna i należy się tego spodziewać. Oczywiście jest cienka linia, ale myślenie, że zrobisz to we właściwy sposób za pierwszym razem, może spowodować własny zestaw problemów (paraliż analizy).
Podsumowując, każdy nietrywialny projekt, który trwa dłużej niż kilka lat, będzie musiał poświęcić nowy czas na spłatę zadłużenia technicznego. Chodzi o to, że to prawda, nawet jeśli piszesz swoją aplikację we właściwy sposób . Jeśli tego nie robisz, gromadzisz długi na długach, a zarząd z pewnością może to zrozumieć, jeśli przedstawisz je w ten sposób.
Wyjaśnij to kierownictwu i zamiast „obwiniania” poprzedniego zespołu cały czas możesz to przedstawić jako „biznes jak zwykle”.
źródło
IMO już teraz robisz to właściwie we właściwy sposób: nie sugerujesz gruntownego przepisywania, ponieważ „stary kod jest do bani”, ale naprawiasz jedną rzecz na raz.
Aby uniknąć poczucia, że obwiniasz stary zespół, wyobraź sobie, że prawdopodobnie musieli stworzyć ten kod pod wielką presją czasu. W tamtym czasie kierownictwo prawdopodobnie tak naprawdę nie rozumiało tego tylko dlatego, że kod „mniej więcej działa” nie oznacza, że możliwa jest konserwacja bez większego bólu i przeróbek.
Doceń stary zespół za stworzenie produktu, który rzeczywiście przyniesie pewną wartość biznesową - nie byłby już w użyciu, gdyby tego nie zrobił. Możesz być zaskoczony, jak często projekt nie zapewnia wartości biznesowej, nawet jeśli jest pięknie napisany.
źródło
Poproszony o wypowiedzenie się na temat obecnego stanu produktu, którego dotyczy problem, zawsze polegam na tym, że „tak jest”, a potem zaczynam mówić o planach jego ulepszenia.
Nie znasz wszystkich czynników, które wpłynęły na decyzję, która spowodowała ten problem - być może były w tym czasie nawet rozsądne. Wszystko, co możesz zrobić, to iść naprzód i poprawić sytuację jutro. I wygląda na to, że wykonujesz dobrą robotę - masz odpowiednie podejście do tej sytuacji.
Kiedy zostaniesz o to poproszony, skoncentruj się na zgłaszaniu faktów. Nie musisz dodawać narracji ani komentarzy; po prostu powiedz „system zawiedzie w przypadku X” lub „raporty są niepoprawne w przypadku Y”. Następnie szybko dodaj, w jaki sposób planujesz poprawić obecną sytuację.
źródło