Za górami, za lasami, za siedmioma routerami, był sobie projekt. Był dobry. Deadline był odległy, a budżet zatwierdzony. Zespół liczny, doświadczony. Pomysł na produkt miał ręce i nogi.
Co mogło pójść nie tak?
Zabraliśmy się do pracy. Spotkania, telekonferencje, ustalenia. Planowanie za planowaniem, meeting za meetingiem, sprint za sprintem. Szybko okazało się, że głównodowodzący projektem ma osobowość radiowego spikera. Człowiek ten uwielbiał rozmawiać, mówić, przemawiać i omawiać. Nie ma w tym nic złego. Dobrze jest być towarzyskim. Projekt był rozproszony geograficznie, więc siedziało się na słuchawce godzinami, ale jeśli trzeba coś omówić, to przecież naturalne.
Po rozmowie wypadałoby zacząć pracę, a ustalenia spisać. Nasz lider jednak lubił jedynie mówić. Zadania, jakie dla nas tworzył składały się zwykle z jednozdaniowego opisu staniowącego tytuł.
Projekt trwał i trwał, postępy nie były imponujące. Nadszedł sezon urlopowy. Nasz lider również postanowił udać się na zasłużony wypoczynek. Dwutygodniowy. Przed opuszczeniem biura zorganizował – a jakże! – spotkanie, na którym omówił zadania, jakie przed nami stały. Wydawało nam się, że zrozumieliśmy jego intencję. Dla uspokojenia przekazał nam kontakt do dwóch osób, które miałyby rozwiać nasze wątpliwości w razie, gdyby takowe zaistniały.
Przyszedł kolejny tydzień. Zajrzeliśmy do notatek, zajrzeliśmy do zadania (z jednozdaniowym opisem). Po kilkunastu minutach pojawiły się wątpliwości. Po godzinie rozmawialiśmy z pierwszą osobą, jaka miała nas wspomóc. Okazało się, że zrozumiała naszego lidera inaczej, niż my. Zaniepokoiło nas to. Zadzwoniliśmy do kolejnej. I ona zrozumiała inaczej. Tyle tylko, że nie inaczej niż my, ale również inaczej niż pierwsza osoba. Mieliśmy trzy interpretacje i dwa tygodnie bez autora.
Puenta okazała się zaskakująca. Gdy lider wrócił z urlopu i zaczęliśmy drążyć, jak konkretnie mamy wykonać zadanie i na czym ma ono polegać, po kikudziesięciu minutach kluczenia przyznał, że nie wie.
To najjaskrawszy, z jakim miałem do czynienia, przykład jednego z grzechów programistów – pobieżnego opisywania tasków. Oczywiście nie można być pedantem i opisywać ich przesadnie szczegółowo, ale pewien sensowny poziom detalu i dbałości jest wymagany, by projekt nie eksplodował spotkaniami.
Zastanówmy się. Bierzemy do ręki, na warsztat nowe zadanie. Czytamy opis i połowy z niego nie rozumiemy. Co robimy? Idziemy do autora. Jeśli autor jest z biznesu, to pewnie jest na spotkaniu i nie idziemy, a wysyłamy mail. Czekamy albo bierzemy inne zadanie. Jeśli inne są równie dobrze opisane, to piszemy kilkanaście maili zanim uda nam się zabrać do roboty. Jeśli natomiast autor jest programistą z zespołu to idziemy do niego i… odrywamy go od pracy w skupieniu, przychodząc z naszym pytaniem.
W obu scenariuszach tracimy czas. Wszyscy. Czas i efektywność.
Opis zadań powinien być precyzyjny, napisany prostym językiem i wystarczająco dokładny, żeby zrozumiała go osoba, która nie posiada naszej wiedzy, a wiedzę wspólną dla członków zespołu. Nie możemy wychodzić z założenia, że jak nie wie to dopyta. To nieefektywne, szkodliwe, złe. To tworzy kulturę rozproszeń, chodzenia od biurka do biurka w nieustającym rytuale dopytywania, ustalania, marudzenia jeden drugiemu. Programista powinien móc jak najdłużej pracować w skupieniu. Tylko tak tworzy się sprawnie dobrej jakości oprograowanie.
Opisuj taski. Opisuj je dobrze. Jeśli nie umiesz ich dobrze opisać, to może nie wiesz w ogóle co jest do zrobienia?