Dobrze pamiętam, sensownie się umówiliśmy. Nic jednak się nie stało. Nikt też nie pamięta, co dokładnie się miało wydarzyć. A wystarczyło spisać. Ciągle jeszcze mi się zdarza doświadczyć sensowności prostej zasady: nie ufaj swojej pamięci. Zapisuj. Twórz notatki, zwłaszcza jeśli pracujesz z dużą liczbą osób.
Dokumentowanie kojarzy nam się z biurokracją i odrabianiem zadań domowych. Bardzo tego nie lubimy. Na dodatek wiemy z opowieści, że produkty cyfrowe mogą się bez tego obejść. Wszystko da się zrobić w kodzie, bazując na szkicach. Wystarczy zgrany zespół i rozproszona w mailach i zapisach z komunikatorów korespondencja. Tak może zaczynać dowolny startup, ale wzrost wymusi na nim zmianę.
Nie lubimy dokumentów, założeń i notatek, bo często stają się czymś koszmarnym. W korporacjach standardowe kwity, zwłaszcza dotyczące tzw. projektów informatycznych zwykle są fatalnie sformatowane i wypełnione pustymi formularzami, które bardzo rzadko mają zastosowanie (są w każdym kwicie, bo format jest uniwersalny). Na 5 stronach mamy kilka zdań treści, a reszta to elementy dokumentu, których używa się raz na jakiś czas. Na dodatek nazwy pól są bardziej czytelne niż treść. Dlaczego się tak dzieje? Bo rzadko kto zawraca sobie głowę dbaniem o przejrzystość tych rzeczy. Kolejne generacje pracowników używają tego, bo muszą. Na dodatek uczą się, że tak ma być i.. przenoszą czasem wzory w nowe miejsca.
Po co spisuje się rzeczy? Przede wszystkim – by wyręczyć pamięć i nie tracić czasu na dyskusje o tym, co raz się ustaliło. Gdy coś jest spisane może krążyć i wywoływać dyskusję. Tylko ludzie, którzy „wiedzą lepiej” jej nie potrzebują. Pisanie wspomaga też myślenie. Zwłaszcza u wzrokowców – osób, które najlepiej odbierają informacje, gdy je czytają. Taki przekaz zaoszczędza też czas na osobiste tłumaczenie. W końcu kwity są potrzebne, by uchwycić moment podjęcia decyzji. Potem można do tego wracać. Spisane ustalenia pozwalają na weryfikację dokonań.
W każdej organizacji, w której niewielu decyduje o pracy większości, pewne rzeczy trzeba ustalać zanim zacznie się coś realizować. Nawet jeśli mamy całkowicie samodzielne zespoły, coś musi wyznaczyć ramy ich działania. Gdy wszystkie ustalenia są w mailach, to czasem ten stan wymaga tylko drobnej ewolucji. Wystarczy wyjść z poziomu dyskusji do spisanych ustaleń, a efekt przerzucić do notatki z nazwą, datą i autorami. Stworzyć minimalną liczbę wymaganych dokumentów i napisać, czego nie może w nich zabraknąć. Minimum jakie ma się w nich znaleźć wymaga dyscypliny. Lepiej przy tym unikać długich kwitów. Czasem to nie wychodzi, wtedy można wymuszać pisanie w punktach.
Poza tym warto jeszcze zadbać o sensowne nazwy tych kwitów (naprawdę macie 50 plików o nazwie zalozenia.rtf?). Formatowaniem nie trzeba się zajmować, jeśli nikt nie formatuje. Gdy ludzie zaczynają korzystać z wymyślnych możliwości oprogramowania, lepiej narzucić prosty standard. Żeby nie tracili czasu na wybór kształtu bulletpointa a skupili się na treści.
Warto pamiętać, że – to wychodzi zwłaszcza w rozwoju produktów – tekst pisany każdy rozumie po swojemu. Jednoznaczne jest dopiero to co powstało, coś czego można użyć. Dobre, proste kwity są jak terminy. Same nie mają mocy sprawczej, ale pozwalają się nam znaleźć na „tej samej kartce”. Nie są celem samym w sobie, dlatego warto dobrze się umówić jakie powinny być, a jakich tworzyć nie trzeba.
Warto spisywać kluczowe ustalenia dotyczące zmian w produktach, lub tworzonych funkcjonalności. Po każdym projekcie dobrze jest stworzyć podsumowanie. Powody nieźle opisuje UxBooth, choć trochę przesadza z ilością dokumentów. Ważniejsze niż spisywanie tego jest sprawienie, by rzeczywiście ktoś do tych zapisów wracał i ich użył. Na wyższym poziomie warto mieć spisaną strategię, wizję i jakąś roadmapę / backlog z postulowanzmi zmianami (pamiętając, że wielomiesięczna roadmapa zawsze jest fikcją). Ten ostatni to na szczęście nie literatura – raczej sztuka dzielenia, nazywania i priorytetyzowania rzeczy.