5 wskazówek jak zredukować ilość błędów w projekcie
Temat chwytliwy? Oczywiście. Pytanie „czy popełniasz błędy?” jest retoryczne – każdy z nas je popełnia. Inną kwestią jest to, że nie wszyscy się do tego przyznają – wbrew pozorom (czasami) słusznie, ale o tym w rozwinięciu wpisu.
Bardzo często spotykam się z podejściem u ludzi, z którego wynika, że nie zdają sobie sprawy z tego, że popełniamy błędy (generalnie). Widać to m.in w niektórych harmonogramach, gdzie całkowicie brakuje czasu na łatanie błędów. Dzisiaj jednak nie o harmonogramowaniu (ten temat poruszyłem w wpisie cała prawda o wycenach projektów IT), ale o podejściu do błędów i ich popełniania.
Kilka lat temu napisałem wpis o 7 kluczowych cechach dobrego developera – mimo upływu czas jest on wciąż aktualny. TL;DR – opisałem tam obraz „idealnego” programisty. Słowo idealnego nie bez powodu jest w cudzysłowie. Rekrutując programistów do Fresh Apps bardzo dużą uwagę zwracam na to, by osoba posiadała cechy opisane w tym wpisie. Jeśli je posiada lub jest im bardzo bliska (da się je podciągnąć) – rozpoczynamy współpracę. Można więc wnioskować, że tacy programiści nie popełniają błędów. Takie przekonanie nie wynika z mojego światopoglądu – zauważam to rozmawiając z klientami. Żeby była jasność – nie są to odosobnione przypadki. Częściej spotykam się z takim przekonaniem u managerów niż u właścicieli firm i częściej sprawa tyczy się outsourcingu – takie są moje obserwacje. Nie wiem z czego to wynika, być może nierozumienie rozliczeń T&M, a być może to kwestia układania relacji z podwykonawcą?
Czy programiści Fresh Apps popełniają błędy? Oczywiście, że… TAK!
Szczerze mówiąc nie wyobrażam sobie, że ktoś mógłby odpowiedzieć na to pytanie inaczej (w kontekście swojej firmy). Na co dzień „z tyłu głowy” mam myśl – JAK USPRAWNIĆ PRACĘ PROGRAMISTÓW? Podczas codziennych działań, prac na projektach staram się zwracać uwagę na temat tego co można zrobić lepiej. Gdy zostanie popełniony błąd staram się zastanowić co mogłem zrobić by temu zapobiec i jaka była faktyczna przyczyna. Po głębszym zastanowieniu, dochodzę (prawie zawsze) do wniosku, że błąd leżał albo w niedopracowanej analizie przedwykonawczej, albo wynikał ze źle zaplanowanego procesu wytwarzania oprogramowania (ogólnie pojęte zarządzanie). Heh, mam przekonanie graniczące z pewnością, że kiedyś takie sytuacje zakwalifikowałbym jako błąd programisty. Jednak dzisiaj wiem, że to ja zapewniłem im środowisko sprzyjające popełnianiu błędów.
Teraz trochę generalizacji nie popartej żadnymi badaniami czy statystykami – to jedynie moje obserwacje. Wraz ze zdobywanym doświadczeniem w moich projektach jest coraz mniej błędów – mimo, że pracuje z bardzo podobnymi specjalistami. Przypadek? Nie sądzę. Wraz z wnioskami, które wyciągnąłem wiem na czym się skupić żeby zapewnić dobre środowisko, w którym trudniej popełnić programistom błąd.
Mam wrażenie, że takiego podejścia brakuje w wielu projektach. Rozmawiając z klientami/kolegami po fachu często słyszę, że „programiści popełnili tyle błędów, że nam się projekt opóźnił”. W sytuacji, gdy w analizie są luki, nie jest dokładnie opisana – można ją zinterpretować dwojako lub trojako. Decyzję, które rozwiązanie wybrać (bo nie jest zdefiniowane w dokumencie) zostawia się programiście. Nie ma co się dziwić, że później software może działać nieprawidłowo gdy decyzje „analityczne” podejmuje programista, który może nie mieć ogólnego pojęcia o projekcie. Przyczyną są oczywiście luki w analizie, które powinien rozwiać analityk, a nie zostawiać do rozwiązania programiście. Zdaję sobie sprawę, że w niskobudżetowych projektach nie ma roli analityka przez okres trwania projektu, ale chodzi tutaj jedynie o wydzielenie odpowiedzialności za całokształt projektu. Może to być kierownik projektu, właściciel firmy – you name it. We wcześniej opisanym przykładzie programista wyszedł poza swoje kompetencje (bo musiał) – często developerzy nie znają całości projektu, nie rozmawiają z klientami o detalach więc nie zawsze będą w stanie podjąć najlepszą decyzję. Jednak winę za nieprawidłowo działający program przypisuje się właśnie im.
Nie raz, nie dwa słyszałem przypadki o firmach, w których programiści byli „całym złem w firmie” bo popełniali błędy. Właściciele zwalniali ich, zastępując nowymi… którzy również popełniali błędy i byli „złymi specjalistami”. Tak długo dopóki nasz proces będzie zły lub skłaniał ludzi do błędów – tak długo będziemy musieli je naprawiać. Trzeba sobie powiedzieć szczerze – są też nierzetelni programiści i w tym przypadku niewiele pomogą dobre procedury, jeśli ktoś nie będzie postępował według nich należycie. Trzeba umieć to klasyfikować i rozróżnić.
Sprawdź jak mogę Ci pomóc osiągnąć Twoje cele 🎯
5 wskazówek minimalizujących błędy
Kilka szybkich tipów ode mnie, które możesz wdrożyć do swoich projektów.
- w swoim procesie wytwarzania oprogramowania uwzględnij czas na poprawę błędów. Nie zakładaj, że ich nie będzie;
- niech testy manualne wykonują inne osoby niż twórcy kodu. Już kiedyś poruszałem temat czy programista powinien testować swój kod;
- wyznacz osobę spośród zespołu projektowego, która będzie pełniła rolę analityka (nie rozpraszaj tej odpowiedzialności na programistów);
- dokładniej planuj architekturę systemu. Zauważam (na podstawie moich doświadczeń), że najwięcej błędów powstaje w wyniku integracji modułów/fragmentów projektów. Zwróć na to uwagę podczas etapu syntezy w analizie.
- presja czasu na programistach nie zawsze działa na Twoją korzyść. Czym większa presja na skończenie zadania w krótszym czasie, często wpływa na późniejsze oddanie projektu. Dzieje się tak w sytuacji, gdy programiści mają zbyt mało czasu by oddać zadania w dobrej jakości, co później wpływa na czas poświęcony na poprawianie błędów. Jest cienka granica pomiędzy presją mobilizującą, a brakiem dostatecznego czasu.
Podsumowanie
Moim zdaniem większość błędów programistów ma korzenie w niewłaściwym zarządzaniu procesem wytwarzania oprogramowania lub niedokładnej analizie przedwykonawczej. Wychodzę z założenia, że ludzie nie popełniają błędów intencjonalnie. Starając się poprawić w/w elementy możesz zapewnić ekosystem projektowy, który będzie zapobiegał występowaniu błędów. Nie jesteś w stanie całkowicie zapobiec błędom programistycznym – każdy jest tylko człowiekiem i w nawet najlepszych procesach i najlepszym zarządzaniu mogą wystąpić błędy. Jednak jeśli możemy coś z tym zrobić – to myślę, że warto.
Dziękuję, że przeczytałeś ❤️
Pssst... przygotowałem dla Ciebie kilka prezentów - wybierz co Ci się przyda! 👍
