Shame Driven Development – zarządzanie przez wstyd

W roku 2009 Robert C. Martin, współautor Agile Manifesto, napisał książkę „Clean Code: A Handbook of Agile Software Craftsmanship”, ugruntowując ideę Test Driven Development, czyli TDD. Jak wiadomo istnieją inne techniki pisania kodu takie jak chociażby BDD, czyli Behavior Driven Development, chciałbym jednak przedstawić sposób zarządzania projektem, który kiedyś zdarzyło mi się zaobserwować w działaniu, a który można określić mianem SDD, czyli Shame Driven Development . Po polsku – zarządzanie przez wstyd. Podejście jest unikalne, łatwo je zastosować i przynosi zaskakujące (co nie znaczy, że zaskakująco dobre) rezultaty. Po krótce opiszę co można osiągnąć, stosując Shame Driven Development oraz wybrane, dostępne na rynku narzędzia, które wspierają prowadzenie projektu w ten sposób.

Shame Driven Development – opis podejścia

Shame Driven Development jest to technika “motywacyjna” polegająca na wywołaniu w członkach zespołu deweloperskiego poczucia wstydu, niskiej własnej wartości, zakłopotania, poczucia bycia kimś gorszym poprzez prezentowanie na forum rezultatów ich pracy. Doskonale sprawdza się w projektach scrumowych, ale jest kompatybilna również z każdym innym sposobem prowadzenia projektu, zarówno zwinnie, jak i waterfall’owo. Sprawdza się niezależnie od tego, czy projekt ma ustalony budżet czy nie, znany czy nie znany zakres oraz zbliżający się deadline lub nie. Daje szczególnie doskonałe rezultaty w zespołach zajmujących się szeroko rozumianym wsparciem

Dostępne narzędzia oraz sposób ich efektywnego wykorzystania

Na rynku dostępnych jest wiele narzędzi wspomagających ten rodzaj pracy. Zaletą Shame Driven Development jest to, że niekoniecznie trzeba od razu kupować bardzo drogie narzędzia IT. Wystarczy zwykły arkusz kalkulacyjny i do dzieła!

1. Narzędzia z zakresu continues integration (praktyka wytwarzania oprogramowania, która zakłada ciągły proces budowania i instalacji projektu) są wdzięcznym polem do popisu. W założeniu służą do integracji na bieżąco tworzonego kodu przez wielu programistów. Ułatwiają jego automatyczną integrację, uruchamiają automatycznie testy jednostkowe i raportują, jeśli testy nie przechodzą. Otóż konfigurujemy takie narzędzie w taki sposób, aby każdy błąd skutkował mailem wysyłanym automatycznie do zdefiniowanej grupy odbiorców, a jego wydźwięk jest mniej więcej taki: „TO TY ŹLE ZROBIŁEŚ I JEST TO TWOJA WINA”. Taki mail powinien mieć znamiona tego, że wydarzyło się coś naprawdę strasznego, a projekt jest zagrożony. Staramy się co jasne, poszerzyć również tak, jak to tylko możliwe grupę odbiorców. Zespół to mało! Wyślijmy to dwa poziomy wyżej oraz do innych zespołów niekoniecznie z nami współpracujących i jeśli tylko firewalle przepuszczą, wyślijmy do klienta! Nie ma to jak dobre słowo i docenienie przed całym światem.
2. Doskonałe rezultaty przynosi również takie „motywowanie” osobiście, na forum zespołu. Tak jak wspomniałem, wystarczy nawet zwykły arkusz kalkulacyjny. Jeśli na przykład mamy zespół scrumowy na codziennym spotkaniu, ustawiamy wszystkich w salce, a za pomocą rzutnika prezentujemy arkusz. W arkuszu w jednej kolumnie mamy nazwiska (albo lepiej tylko numer pracownicze, nie ma to jak anonimowość) wszystkich członków zespołu. Następnie kolejne kolumny oznaczają ilość pracy wykonanej przez każdą z osób w zespole w kolejnych tygodniach . Odpytujemy niczym obozowy kapo co, kto i ile zrobił (z podtekstem dlaczego tak mało). Konieczne jest posortowanie osób w kolejności od tych najlepiej (cokolwiek to znaczy: najszybciej, najwydajniej, najbardziej produktywnie) pracujących do tych pracujących najsłabiej. W okolicy końca listy okazujemy swoje sadystyczne przywódcze cechy po to, aby jeszcze lepiej zmotywować zespół i pokazać jak bardzo nam zależy na projekcie. Porównujemy osoby z końca arkusza do osób z początku. Pamiętamy, że osoby powinny czuć zakłopotanie z powodu tego, że nie są tak dobre jak osoby figurujące wyżej w arkuszu. Jako efekt uboczny budujemy naszą pozycję jako project managera silniejszą i jesteśmy nielubiani poważani przez zespół. Dobrym pomysłem jest co jakiś czas rewidowanie kolejności osób w jakiej pojawiają się w arkuszu kalkulacyjnym, uwzględniając aktualnie osiągane efekty. Kto zaprzeczy, że wprowadzenie do pracy elementu współzawodnictwa jest motywujące?!

Osiągane rezultaty oraz wnioski

Osoby w zespole powinny być zmotywowane do tego, aby osiągać lepszą wydajność w pracy. Powinny również pośrednio, dzięki lepszym efektom, mieć większe poczucie własnej wartości, pewność siebie oraz poczucie przynależności do zespołu. Przynajmniej w teorii. Niestety opisana metoda ma pewne skutki uboczne (wierzę, że w tym miejscu już wiecie co o niej myśleć), jak na przykład niechęć zespołu do pojawiania się na porannych spotkaniach i w efekcie nieobecność. Dzieje się tak zapewne z powodu częstszego spóźniania się do pracy członków zespołu. Ale myślę, że nie powinniśmy łączyć przecież porannych korków z zastosowaniem tak nowatorskich metod  jak SDD.