Megasoftwarecraftsmanshipper

Pojawił się nowy rodzaj programisty:

megasoftwarecraftsmanshipper - podchodzi do odziedziczonego kodu z wyższością ocierającą się o pogardę; z kpiącym uśmiechem patrzy na nazwy zmiennych, design, stan testów; sam dla siebie jest największym autorytetem; podstawowymi narzędziami poprawy jakości czyjegoś kodu jest naprzemienne stosowanie wyśmiewania i poniżania; megasoftwarecraftsmanshipper to powiernik i głosiciel Prawdy objawionej przez Święte Community; według najnowszych badań postawa taka jest objawem choroby zwanej megasoftwarecraftsmanshippentem

A więc jest nadzieja! Można to leczyć! Zebrałem kilka receptur ozdrowieniowych, więc jeśli znasz jakiegoś megasoftwarecraftsmanshippera, to koniecznie poleć mu jedną z nich, bądź nawet wszystkie. Skutków ubocznych nie stwierdzono.

Receptura Szczepana i Bartka

Szczepan Faber i Bartosz Bieńkowski w swoim wystąpieniu nt. TDD dają następującą recepturę: "musicie pozbyć się swojego Ego". Dalej wyjaśniają, że chodzi to pozbycie się zdradliwej myśli, że "mój kod jest najlepszy". Zaleca się powtarzanie tego rozumowania na głos rano i wieczorem.

Receptura Lequiera

który rzekł: "Gdy się wierzy, że posiadło się prawdę, trzeba wiedzieć, że się w to wierzy, a nie, że się to wie". Na podstawie tej światłej myśli zaleca się rozważanie następującego zdania: "Konwencja kodowania, architektura, frameworki, język programowania to tylko moje przyzwyczajenia i moje ulubione podejścia. Sprawdzają się w bardzo określonych kontekstach, a poza nimi się nie sprawdzają. Wszystkie inne alternatywy mają tyle samo sensu co te, wyznawane przeze mnie". Oczywiście powtarzamy rano i wieczorem.

Receptura percepcji błędu

Jeśli coś nie działa, w pierwszej kolejności szukaj błędu we własnym kodzie. Zadawaj sobie pytanie: "Co mogłem zrobić albo czego nie zrobić, że to przestało działać?" Rano i wieczorem to dawka minimalna. Optymalna to: przy każdorazowym wystąpieniu błędu.

Receptura "To ma sens"

Megasoftwarecraftsmanshipper przede wszystkim powinien sobie tak głęboko, że aż do szpiku kości uświadomić, że ludzie którzy stworzyli kod odziedziczony naprawdę NIE byli kretynami. Dla wielu megasoftwarecraftsmanshipperów będzie to trudne do zaakceptowania, ale jeśli tylko założą, że "istniała racjonalna przyczyna, dla której ten kod wygląda tak a nie inaczej, że ci którzy go napisali zrobili wszystko, co mogli w sytuacji w jakiej musieli pracować", to być może zaczną zauważać, że: była jedna doświadczona osoba, która dostała "darmowych" (obecnie już chyba nie:)) studentów, kod został przeportowany 1:1 z jakiegoś egzotycznego języka, to jest poprawiona wersja, która wyglądała jeszcze gorzej, itd. Megasoftwarecraftsmanshipper może wtedy zacząć uświadamiać sobie, że "to naprawdę ma sens"!

Jak radzić sobie z błędami ludzkimi?

Ostatnio na grupie WJUG pojawił się wątek Jak zmienić człowieka?, w którym do pewnego momentu dyskutowano o programiście, który nie trzyma się standardów zespołu. Potem, jak to na forach bywa, dyskusja zahaczyła o tematy metafizyczne, by po jakimś czasie odbić w kierunku swobodnych skojarzeń z tematem.

Choć jestem zdania, że lepiej (taniej) nie zmieniać ludzi, a zamiast tego zatrudniać właściwych, to pozwoliłem sobie pominąć dominującą w wątku myśl jak właściwie znaleźć konsensus, aby nie wylać programisty z kąpielą i zastanowiłem się nad pytaniem: Jak radzić sobie z osobami, które masz już w zespole i według Ciebie nie działają tak, jakbyś tego oczekiwał. Na przykład popełniają błędy, których nie akceptujesz. Oczywiście takie rzeczy zdarzają się każdemu, ale przypuśćmy, że akurat u tej osoby charakterystyka błędów mocno odbiega od dopuszczalnej.

Współpraca z ludźmi, to zawiła sztuka i konkretne sposoby postępowania nie są remedium na wszystko, aczkolwiek poniższe pomysły mogą pomóc.

Sklasyfikuj błędy

Dowolną ilość czasu możesz spędzić dyskutując, czy ktoś popełnił błąd, czy nie. Dlatego, prócz standardowych zasad definiowanych dla zespołu, proponuję od razu wprowadzić pewną klasyfikację błędów i określić sposoby postępowania na wypadek każdego z nich. A zatem mamy błędy:

Przypadkowe	Zdarzają się w wyniku okoliczności, na które mieliśmy znikomy wpływ. Nie mamy pretensji o takie błędy.	Uwidocznij
Wynikające z podjętej decyzji	Programista podjął decyzję i była to błędna decyzja. Dobrze, że ludzie podejmują decyzje. O te błędy też nie mamy pretensji.	Udziel informacji zwrotnej (@see poniżej)
Symptomatyczne	Pojawia się regularnie w podobnych okolicznościach. Nie mamy o niego pretensji, ale coś z nim trzeba zrobić	Zdiagnozuj problem Napraw błąd lokalnie, a następnie przemodeluj proces, aby błąd więcej nie występował podejmij coaching z programistą
Wynikające z zaniedbania	Programista wiedział jak postąpić i tak nie postąpił. Powinien mieć pewną wiedzę, ale jej nie pozyskał. Zrobił coś, lecz od początku było wiadomo, że robić tego nie powinien. O takie błędy mamy pretensje.	Udziel informacji zwrotnej wyciągnij konsekwencje służbowe

Udzielanie informacji zwrotnej

Tak jak pisałem kiedyś w udzielaniu informacji zwrotnej nie chodzi o to, aby na siłę być milusim i też nie o to, aby być chamem. Dla uproszczenia sprawy na początek trzymaj się następujących kroków:

1. Udzielaj informacji zwrotnej wyłącznie w cztery oczy i cztery uszy
2. Przedstaw fakty - fakty, nie twoje oceny; fakty do sformułowania, które odpowiadają na pytania: jak? gdzie? kiedy? z kim? co powiedział? co napisał? co usłyszał? co konkretnie zrobił?; zatem jeśli informacje przekazywane przez Ciebie bardziej odpowiadają na pytania: dlaczego? po co? to nie są to fakty, lecz twoje/czyjeś opinie; lepiej wtedy zakończ spotkanie i na spokojnie spisz fakty na kartce
3. FeedBACK - Przekaż co najmniej cztery informacje zaczynające się od Dobrze zrobiłeś, że...
4. FeedFORWARD - Przekaż tyle ile to konieczne informacji zaczynających się od Następnym razem oczekuję, że...
5. Poproś o podsumowanie, tego co przed chwilą powiedziałeś

Coaching

Większość z nas namiętnie uprawia co najmniej dwa zawody: doradcy i psychologa. Odpuść.
Prowadź coaching tylko, gdy ktoś o to poprosi, albo przynajmniej wyrazi zgodę.
Najprostsze formy "coachingu" to:

• Wysłuchanie - słuchaj i potakuj. Nic nie mów tylko potakuj
• Zadawaj pytania konkretyzujące (jak? w jaki sposób? po czym poznajesz, że?) - Zadawaj pytania i czekaj, aż rozmówca dozna olśnienia
• Zadawaj pytania dlaczego? po co? w jakim celu? - zadawaj tak długo, aż rozmówca dozna olśnienia

I przede wszystkim nie doradzaj i nie oceniaj, bo więcej do Ciebie nie przyjdzie. Jakkolwiek by to nie brzmiało: to co w tym momencie masz do powiedzenia jest absolutnie nieistotne:)

Test biznesowy

Od paru wieczorów, moja żona usypiająca naszą paromiesięczną córkę, zgłaszała pewien problem: Klamka w drzwiach skrzypi. Gdy dziś zamknąwszy za sobą drzwi, zobaczyłem na lodówce kartkę w kolorze czerwonym, wiedziałem, że wymaganie otrzymało status blocker.

Z namaszczeniem rozłożyłem skrzynkę z narzędziami, oliwę do maszyn, szmatkę przeciw zabrudzeniom i przystąpiłem do dzieła. Powoli, aby nie stracić żadnej chwili przyjemności rozmontowałem wszystkie śrubki i kropla po kropelce wsączałem oliwę w wadliwy mechanizm.

Nagle przyszło mi do głowy, żeby odstawić popisówkę i zademonstrować żonie, jak to profesjonalnie powinno się współpracować z klientem, jak formułować kryteria akceptacji.
- Słuchaj - powiedziałem - ile razy musisz nacisnąć klamkę, aby się przekonać, że już nie skrzypi i jest naprawiona?
Żona zastanowiła się krótko i odpowiedziała:
- Klamka będzie naprawiona, jeśli Nadia nie będzie się budzić, gdy będę od niej wychodzić.

Morał: Żaden gadżet ani wybajerzona metodyka nie mają uzasadnienia, jeśli klient za pomocą funkcjonalności nie może rozwiązać swoich problemów.

Morał2: Nie zmuszaj klienta do myślenia o technikaliach. Raczej myśl tak jak on.