„To zróbcie” nie działa. Nigdzie. Szczególnie w IT. Zwłaszcza gdy budżet jest ograniczony i nie można w nieskończoność płynąć w stylu agile. Trzeba dokładnie określić, co ma być zrobione. Ustalić ramy, wymyślić to. Kiedy masz wizję całości, ze szczegółami, znalazłeś wszystkie oczywiste konflikty i konsekwencje, a przy tym wszystko wygląda rozsądnie, to jest dobry początek do tego, żeby pracować elastycznie. Krótkie, kilkudniowe sprinty. Szybka identyfikacja problemów. Najpierw jednak dokumentacja.
Kiedy zaczynasz projekt, wydaje się on prosty. Kiedy zaczynasz go opisywać, kolejne strony lecą jak oszalałe. Przy pięćdziesiątej stronie jesteśmy w trzech czwartych. Wygląda to jak książka. Po drodze wyszło wiele problemów, o których nie pomyśleliśmy. Pisanie dokumentacji jest świetnym ćwiczeniem – pozwala stworzyć mentalny obraz całości. Rozpoznać oczywiste i czasami nieoczywiste problemy, zanim zostanie napisana jedna linia kodu. Zaczynasz rozumieć strukturę, zależności, ograniczenia. Kodowanie to będzie podróż po przetartej trasie, a nie w gąszczu.
Przy siedemdziesiątej stronie dochodzimy do momentu, gdy rozwiązanie zaczyna się niespodziewanie komplikować. Siedzimy nadal nad dokumentacją. Daliśmy sobie dwa dni na zastanowienie. Kilka prób podejścia do tematu. To wszystko jest bez sensu, trzeba stworzyć nową dokumentację. Większość się przyda, ale całość trzeba przepisać z innymi założeniami. Tym razem się udało: sześćdziesiąt stron. Koniec, ścieżka przetarta. Wiemy jednak dobrze, że jedno to wytyczyć ścieżkę przez góry, a drugie to poprowadzić tamtędy drogę. Przed nami poprowadzenie drogi. Teraz jednak czujemy się pewniej. Byliśmy tam.
