rss

Tajniki pisania dokumentów wizji

Najlepszą motywacją do pracy, dla programistów i nie tylko, nie są pieniądze, premie ani prywatne ubezpieczenie zdrowotne – jest nią wizja – odpowiedź na pytanie „dlaczego” siedzimy i piszemy to oprogramowanie. Od ustalenia takiej wizji na piśmie należy zacząć każdy nowy projekt, jeszcze zanim napiszemy pierwszą historyjkę użytkownika.

Michał Paluchowski, 10 maja 2010

Martin Luther King

Mam marzenie” to być może najlepiej znane zdanie na świecie, wypowiedziane 28 sierpnia 1963 roku przez Marthina Luthera Kinga. Przemówienie to popchnęło ruch społeczny, który na zawsze zmienił świat. Simon Sinek niedawno w znakomitej prezentacji na TEDxPugetSound posłużył się między przykładem Kinga żeby zademonstrować jak ważna dla sukcesu w dowolnej dziedzinie jest odpowiedż na pytanie „Dlaczego?” Innym przykładem jakim się posłużył była innowacyjność Apple. Bo skoro wiedzieć „dlaczego” było istotne w zwalczaniu dyskryminacji rasowej, to równie istotne jest ono w produkcji komputerów i oprogramowania. Większość metodyk zarządzania projektami programistycznymi nazywa to „wizją„, którą spisuje się na samym początku w ramach „dokumentu wizji„.

Dokument wizji to szczególny tekst, który zawiera wyjaśnienie przyczyn dlaczego w ogóle wszyscy spędzamy czas przy danym produkcie – jaką rolę ma on odegrać, co ma zmienić, jaką lukę wypełnić – oraz w jaki sposób ma to osiągnąć. Odpowiada na pytanie po co właściwie siadamy do klawiatur i piszemy nowy kod, na świecie który tylko w 2010 roku wyprodukuje 1 zettabajt danych. Możnaby spytać: czy musimy to aż zapisywać? Czy nie jest to oczywiste? Nie bardzo.

Dokument wizji ma trzy cele:

  1. Zastępuje jakże zawodną pamięć ludzką. Spisujemy w nim to co ustaliliśmy, a czego szczegóły zostaną zatarte przez czas.
  2. Uzgadnia wspólną wersję. Komunikacja to sztuka trudna i to co sądzę, że usłyszałem jest niekoniecznie tym samym co mój rozmówca sądzi, że mi przekazał. Spisując ustalenia i pokazując dokument sobie nawzajem weryfikujemy to co wydaje nam się, że wiemy.
  3. Stanowi drogowskaz na drodze produkcji. Łatwo się zgubić po drodze w gąszczu problemów i konfliktów. Dokument wizji przypomina wszystkim, że idziemy w tym samym kierunku.

Reguły spisywania wizji

Przede wszystkim wizja powinna być krótka. Jeśli każdy uczestnik projektu miałby przeczytać tylko jeden dokument, to powinien być to właśnie dokument wizji. A im będzie krótszy, tym większa szansa, że faktycznie każdy przez niego przebrnie. Żadnych długich wywodów, broń boże żadnej korporacyjnej paplaniny, a jeśli faktycznie do jego zrozumienia przydatne są jakieś zewnętrzne dane, zawsze można je podlinkować w przypisach.

Po drugie powinien być konkretny. Jeśli zaczniemy pisać o chęci „zadowolenia klientów i akcjonariuszy firmy” to piszemy bezwartościowe bzdury. KON-KRE-TNIE – dlaczego są obecnie niezadowoleni i co ma spowodować, że używając naszego programu staną się szczęśliwsi?

Wyobraźnia ludzka jest nieograniczona, a czas i budżety przeciwnie, tak więc dobra wizja musi również opisywać granice tego, co chcemy zrealizować. Zapisujemy nie tylko to, co chcemy zrealizować, ale również to, czego nie chcemy. Explicite zapisujemy, że tego i owego nie zrobimy, bo…

Po trzecie napisać go należy ludzkim językiem. Pod żadnym pozorem nie może go pisać prawnik! To dokument pisany przez ludzi dla ludzi i powinien brzmieć jak dobre przemówienie. Umiejętność dobrego pisania jest zresztą jedną z ważniejszych dla liderów. Pomaga poczucie humoru – żarty, wyolbrzymienia czy nieco sarkazmu ożywią dokument.

A skoro o tym mowa – dokument powinien cały czas być żywy. Jak mawiał generał Dwight Eisenhowerplany są bezwartościowe, ale planowanie jest wszystkim.” Z biegiem czasu na pewno warunki na rynku się zmienią, być może pewne założenia, które pierwotnie znalazły się w wizji, stracą na znaczeniu. Dlatego dokument wizji należy aktualizować regularnie – w przypadku projektu Agile po każdej znaczącej zmianie rejestru historyjek.

Przykładowy dokument

Wszystko to oczywiście w teorii wygląda pięknie, ale jak to wygląda w praktyce? Podzielę się dokumentem, który napisałem niedawno dla prywatnie tworzonej aplikacji do zarządzania zadaniami w systemie GTD. Tak, tak – nawet jeśli tworzę program samemu zapisuję dlaczego to robię. Wszystko po to, żeby przypomnieć sobie dlaczego akurat piszę kod źródłowy zamiast spędzać czas przyjemnie z kawą i książką.

eXecutr

Bruce Lee

eXecutr to program do zarządzania zadaniami w systemie GTD. Zostanie stworzony z inspiracji dotychczas wykorzystywanym GTD-PHP. Ten ostatni służył mi dobrze przez ponad 2 lata, od początku przygody z GTD.

GTD pozwala mi osiągnąć więcej mając do dyspozycji te same 24 godziny dziennie. Może mniej – czasem sypiam. Pozwala mi błyskawicznie ocenić co w ogóle powinienem robić, czym zająć się w danej chwili, i przeskakiwać od zadania do zadania bez opóźnień. Aby było to możliwe, moje narzędzie do GTD musi być szybsze ode mnie – nie może mnie w żaden sposób opóźniać ani wymagać czynności, które nie są absolutnie konieczne do utrzymania systemu. Musi być jak Bruce Lee w „Wejściu smoka„!

eXecutr ma więc pokonać GTD-PHP na następujacych obszarach:

Szybkość obsługi

GTD-PHP dla typowych działań wymaga znacznie więcej kliknięć czy uderzeń w klawisze niż to jest konieczne. Większość procesów wymaga przeładowania strony, co dodatkowo wydłuża oczekiwanie. Jeśli jakąkolwiek czynność w systemie można wykonywać szybciej, przy mniejszej ilości kroków – eXecutr będzie to umożliwiał. Oznacza to, że:

  • każda czynność będzie wymagać możliwie najmniejszej ilości kroków, kliknięć czy uderzeń w klawisze.
  • gdziekolwiek można wykorzystać AJAX, zostanie wykorzystany, aby zminimalizować ilość odwołań do serwera.
  • wszystkie istotne funkcje – w szczególności przetwarzanie notatek, rejestrowanie akcji i projektów – można będzie wykonać nie odrywając rąk od klawiatury. Wszystkie formularze będą miały jedynie wymagane potrzebne pola, uporządkowane według częstotliwości wykorzystywania.

Przejrzystość

GTD-PHP jest systemem estetycznie brzydkim, a użytecznie mało przejrzystym. Wielkość czcionek i kolory utrudniają ich czytanie. Charakterystyka samego systemu GTD powoduje, że powstają w nim długie listy akcji, projektów i innych elementów, które w GTD-PHP są albo niemożliwe do przefiltrowania, albo jest to utrudnione. W eXecutr:

  • każdy ekran zawierać będzie wyłącznie minimum elementów związanych ze swoją funkcją.
  • główne menu będzie zawierać wyłącznie najczęściej wykorzystywane funkcje.
  • reszta menu będzie schowana.
  • główna lista następnych akcji będzie umożliwiać błyskawiczne filtrowanie, aby przedstawić jednoznaczną odpowiedź na pytanie „co powinienem w tej chwili zrobić?”

Czego eXecutr miał nie będzie?

eXecutr powinien mieć całą funkcjonalność, jaką posiada GTD-PHP. Poza kilkoma wyjątkami:

  • elastyczność poza systemem GTD – interesuje mnie tylko „czysty” GTD, z identyczną strukturą, procesami i nazewnictwem.
  • tagi – stanowią niepotrzebny dodatek, który trzeba dodatkowo aktualizować.
  • wsparcie dla starych przeglądarek – wybaczcie, Internet Explorer 6 został pochowany.

Tyle. Piszę zupełnie nowy program, praktycznie od podstaw, tylko (albo aż) dlatego, że dotychczasowy zbytnio mnie spowalnia i jest miejscami irytująco niewygodny. Jeśli więc w najbliższym czasie będę miał ochotę rzucić go, dokument mi przypomni, że po jego ukończeniu będę mógł osiągać jeszcze więcej tych rzeczy, na których naprawdę mi zależy.

Ta wizja może nie mieć dla nikogo poza mną żadnej wartości – i tak jest dobrze, skoro jestem jednoosobowym zespołem. Jeśli chciałbym kogoś zaprosić do współpracy, „sprzedałbym” mu na początku taką właśnie wizję i znalazł kogoś, kogo również ona wciąga. Wówczas, nawet jeśli mu zapłacę, nie będzie pracował dla pieniędzy ale dla idei. Tak właśnie się tworzą cuda.