Więcej nie znaczy wolniej cz.1

o tym, co sprawia, że jesteśmy lepsi

Ostatnio robiłem podsumowanie roku kierowania projektem (pisałem o tym tutaj) i statystyki, które ujrzały moje oczy, były dużo lepsze niż się spodziewałem:)
Nie jestem jednak osobą, która długo cieszy się sukcesami. Większą radość odnajduję w kolejnych wyzwaniach, więc następnego dnia, po przedstawieniu zespołowi efektów naszej wspólnej pracy, zacząłem się zastanawiać, co dalej? Wychodzę z założenia, że pozostanie w tym samym miejscu jest równoznaczne z cofaniem się do tyłu, tak więc jedynie kolejne ulepszenia wchodzą w grę:)

Przede wszystkim jednak zacząłem od przejrzenia rzeczy, które dodaliśmy/zmieniliśmy w naszym projekcie i próby określenia tego, które w znaczny sposób przyczyniły się do zwiększenia naszej wydajności. I właśnie o wynikach tych obserwacji i analiz chciałbym tutaj napisać:)

więcej nie znaczy wolniej

W kilku najbliższych postach chcę poruszyć kwestie analizy, projektowania, code-review, testowania, dokumentacji (tej dla klientów oraz dla deweloperów) oraz refaktoryzacji. I mam nadzieję, że uda mi się podważyć dość częste przekonanie, że te aktywności są jedynie stratą czasu, a w najlepszym wypadku - pierwszymi rzeczami, z których można zrezygnować w przypadku, gdy termin zaczyna zbliżać się nieuchronnie.

Właśnie te czynniki są najważniejszymi rzeczami, które miały wpływ na zwiększenie naszej wydajności oraz (dodatkowo) przyjemności pracy nad projektem. Chciałem jeszcze zaznaczyć na marginesie, że część z nich była obecna w projekcie, którym kieruję, gdy się w nim pojawiłem, nie wszystko było moją inicjatywą. Jednak są to na tyle istotne aktywności, że nie mogłem pozwolić sobie na ich pominięcie.

Liczę na to, że każdy post uda mi się napisać w taki sposób, że przekonam chociaż niewielką część niepokornych do nawrócenia się. Albo chociażby do spróbowania realizacji owych aktywności poprawnie.

czy kiedyś usłyszałeś/pomyślałeś takie zdanie...

• Po co Ci ta cała analiza skoro klient powiedział czego chce?
• Ty przeanalizujesz, a on i tak zmieni zdanie.
• Projektowanie jest zbędna, ponieważ to kod przedstawia jakąś wartość, a nie jakieś tam, głupie diagramy.
• Pomińmy projektowanie. Przecież wiesz, co tam się ma dziać.
• Nie traćcie czasu na review-code, przecież jesteście dobrzy w tym, co robicie.
• To review Ci nie jest do niczego potrzebne, przecież jak nie będziesz czegoś wiedział, to zapytasz.
• Testy jednostkowe są zbyteczne. Przecież sam to napisałem.
• Po co spędzać czas nad testami skoro klient powie nam, gdy zauważy bug... a poza tym przecież to przeklikamy kilka razy.
• Jak chcesz testy akceptacyjne, to zrób dwa-trzy, tylko nie trać zbyt dużo czasu na nie, bo trzeba funkcjonalność implementować.
• Po co to całe testowanie tak w ogóle, skoro nie gwarantuje nam ono, że nie ma żadnych bugów?
• Dokumentacja dla klienta jest zbędna, bo przecież wie on, jak ma to wszystko działać.
• Klient bardziej ucieszy się z dodatkowej funkcjonalności niż z kolejnych dokumentów.
• Dokumentacja dla dewelopera to niepotrzebne pliki, przecież zawsze będzie ktoś, kto będzie mógł wytłumaczyć zawiłości kody bądź logiki.
• Refaktoryzować? Po co skoro działa?
• Czy ja dobrze rozumiem, że chcesz spędzić czas nad pisaniem od nowa czegoś, co już jest w projekcie?
• Ale jaka czytelność? Przecież sam to pisałeś, to chyba mi nie powiesz, że zapomnisz jak to działa?

... i pewnie wiele innych i każde z tych zdań chciałbym podważyć i, mam nadzieję, że mi się to uda:)

toż to wszystko jest oczywiste!

Może i tak, ba, chciałbym wierzyć, że dla każdego z Was jest i w Waszej pracy, przy każdym projekcie praktykujecie czynności, które wymieniłem w drugim paragrafie.

Jednak rzeczywistość jest brutalna i wiem, że wiele osób, dopóki nie doświadczy pozytywnych efektów owych aktywności, dopóty będą uważali, że są to rzeczy, które jako pierwsze będzie można porzucić.

Zdaję sobie również sprawę, w jaki sposób realizują projekty mniejsze firmy, gdzie głównym argumentem za NIE stosowaniem tych praktyk jest - "mamy przewagę, bo zrobimy to szybciej". Wierzcie mi lub nie, ale taka przewaga, to żadna przewaga, a taki sposób prowadzenia projektów zbyt często kończy się niezrealizowanymi bądź źle zrealizowanymi zleceniami. Co pozostawia duży niesmak u klienta i skutecznie go do nas zraża.

i na koniec

W poście przedstawiłem listę zdań, które miałem wątpliwą przyjemność usłyszeć w swojej karierze programisty. Postaram się je podważyć (efekt ocenicie sami:).

Jeżeli usłyszeliście kiedyś coś podobnego, to podzielcie się tymi doświadczeniami w komentarzach. Jeżeli sami uważacie takie stwierdzenia za prawdziwe, to tym bardziej zachęcam do komentowania:)

<< Poprzednie Następne >>