Daty i harmonogramy przeszkadzają w rozwoju produktów

Trudno cokolwiek robić, nie ustalając na kiedy będzie i ile wysiłku pochłonie. Niestety tak to robimy, że najczęściej jest to strata czasu.

Biznes kocha daty i terminy (np. odbiorcy mleka kochają). Pytanie „na kiedy” jest fundamentem podręcznika szkoleń kierownika. Obok pytania „co proponujesz” jest przekazywane już na pierwszych lekcjach. Obu relatywnie łatwo się nauczyć i używać bez większego zrozumienia skutków. W rozwoju produktów cyfrowych pytanie „na kiedy” może być bardzo szkodliwe.

Nie kupuję harmonogramów, takich złożonych z wielu elementów, obejmujących kilka kwartałów. Pokazujących powiązania między rozmaitymi działaniami, w których powstają składowe jakiejś wspaniałej całości. O ile przedmiotem projektu jest produkt cyfrowy a nie most, albo dom (z którymi też różnie bywa), tworzenie takiego dzieła jest najczęściej stratą czasu.

Jest kilka poziomów zrozumienia tematu terminu realizacji projektu, w którym pisze się oprogramowanie. Na podstawowym rozmowa wygląda tak: po ogólnym ustaleniu co chcemy zrobić padają jakieś oceny, które zamieniają się w zobowiązanie. Z przekazu z łatwością znikają słowa „zgrubny szacunek” zostaje data.

Drugi poziom pojawia się, gdy zauważamy, że za często trzeba przesuwać terminy i prowadzić rozmowy na temat powodów. To te rozmowy i przekładanie są największą stratą energii. Dyskusja o tym, co trzeba napisać i w jakiej kolejności, może być dobrym ćwiczeniem poprawiającym planowanie…. Bo planować warto. Żadna bitwa nie została wygrana… żaden plan nie przetrwał konfrontacji itd. (prawdy nt. planowania wydają mi się powszechne znane, ale bardzo często się mylę w sprawie tego, co jest powszechnie znane).

Trzeci poziom jest ponadczasowy i uniwersalny. Gdy dochodzimy do poziomu głębokiej kompetencji wtedy wiemy, że nic nie wiemy i rozumiemy dlaczego. Że jeśli w projekcie powstaje kod, odpowiedzialnie jesteśmy w stanie rozmawiać tylko o tym, co poznaliśmy już bardzo bardzo głęboko. To, co ma mieć miejsce dalej niż za miesiąc – dwa, pozostaje fantazją. W ledwie liźniętych tematach, o skali wyzwań można mówić tylko w przybliżeniu. Rozumiemy, że wypisywanie dat dotyczących rzeczy, które mają się zdarzyć za więcej niż pół roku to bardziej prognozowanie niż planowanie.

Dziesiątki lat temu Peter Drucker stwierdził, że plan aby był sensowny i przejrzysty nie powinien sięgać dalej niż półtora roku do przodu (polecam książkę „The Effective Executive”). Było to w epoce przed-softwarowej, kiedy zwykle ludzie zajmowali się rzeczami złożonymi z powtarzalnych, znanych składników. Najczęściej każde coś robili po raz któryś i wiedzieli z czego się składa. Normą było planowanie wieloletnie, więc półtora roku było bliskim terminem. Dziś wszystko zmienia się co najmniej siedem razy szybciej. Kwartał może być rozsądną perspektywą. Potem już obowiązuje inny cytat z Druckera: „planowanie długoterminowe dotyczy przyszłości obecnych decyzji”. Nie warto podejmować decyzji na temat odległej przyszłości, bo przyzwyczaimy się do nich i będziemy się musieli z nimi mierzyć. A – znowu Drucker – jedyne co wiemy o przyszłości to to, że będzie inna.

Rozwój produktu najlepiej prowadzić w podejściu zwinnym, którego osią sa samodzielne zespoły i dobrze określona odpowiedzialność. W ich pracy od harmonogramów ważniejsze są priorytety i tempo. Trzeba wiedzieć co jest najważniejsze w najbliższym czasie i o tym wiedzieć wszystko. O tym, co się stanie za dwa miesiące, można wiedzieć mniej. Warto zakładać zmianę i nieprzewidywalność. Również po to, by zachować zdolność do zmiany kursu. Ona zawsze jest trudniejsza, gdy zainwestowaliśmy w planowanie.

Niestety czasem naprawdę potrzebujemy terminów. Powodem może być zbliżające sie wydarzenie np. wybory, święto, albo wejście w życie przepisu, do którego trzeba się dostosować. Czasem przedmiot działań jest na tyle duży, że wymagają koordynacji w różnych miejscach. Czasem po prostu opłaca się ustawić datę graniczną – bo robienie czegoś dłużej nie byłoby dobre dla biznesu.

Jak sobie radzić gdy terminów nie można uniknąć? Jak prowadzić rozmowę, gdy partner nie rozumie tego, co powyżej? O tym za dwa tygodnie.