Mecenas radzi – jak nie pogubić się we własnych decyzjach?
Jednym z chyba bardziej popularnych nurtów myślowych jeśli chodzi o wytwarzanie oprogramowania, szczególnie w branży w IT, szczególnie w startupach 😉 jest nurt Zwinnego Wytwarzania Oprogramowania. (w ramach ciekawostki – dlaczego Zwinne Wytwarzanie Oprogramowania a nie Zwinność → “Agile is Dead” prezentacja po angielsku). Jednym z głównych postulatów Zwinnego Wytwarzania Oprogramowania (ZWO) jest to, że proces jest oparty o empiryzm, czyli doświadczanie, czyli też o eksperymenty. Definicja z Wikipedii podpowiada „Klasyczny eksperyment świadomie ingeruje w naturę i polega na analizie skutków tej ingerencji.„
Wydawało by się że to cholernie prosta sprawa i w ogóle o czym mowa w tym artykule. Niestety istnieją sytuacje kiedy samo podążanie do przodu nie wystarcza, a wręcz zaczyna być kłopotliwe
Prawdopodobnie największą zaletą ZWO jest możliwość bardzo szybkiego dowiadywania się nowych rzeczy i adaptowania oprogramowania do nowego stanu wiedzy. Mówiąc potocznie można dużo szybciej podejmować kroki. W niepewnym lub mocno zmiennym otoczeniu rynkowym czy technicznym jest to bardzo pożądana, czy wręcz niezbędna super-moc organizacji. Istotne dla zrozumienia tego artykułu jest to, że podejmowane decyzje mogą być kluczowe nie tylko dla samego rozwiązania technicznego, ale też wpływają na całą organizację, model sprzedaży, marketing, dystrybucję.
Jakie więc zagrożenie pojawia się na horyzoncie gdy w pełni zwinnie i radośnie podążamy setkami kroków w stronę horyzontu? Zagrożeniem tym jest niestety zawodność ludzkiej pamięci. Moim zdaniem przy odpowiednio dużej wielkości jednego z parametrów:
- ilość podjętych decyzji w historii organizacji,
- ilość osób pracujących w organizacji,
- rozmiar produktu,
- dni które upłynęły od podjęcia danego wyboru
w końcu dojdzie do tego że ktoś zakwestionuje status quo, albo przynajmniej zapyta dlaczego COŚ działa w ten sposób a nie inny.
Pytanie takie może się pojawić na przykład dlatego że rozwiązanie samo w sobie przedawniło się i nie wygląda sensownie, bo wiedza o powodach nie jest dostatecznie rozpropagowana (co gorsza skupiona w pamięci tylko jednej osoby w całej organizacji czy też całkiem zaginęła), lub też ktoś wpadnie losowo na pomysł zmiany danego elementu w produkcie.
Gdy już dojdziemy do takiego momentu moim zdaniem istnieją 3 główne sposoby kontynuowania:
- odrzucamy zupełnie nowy pomysł nie zagłębiając się w jego potencjał,
- nie zastanawiając się długo rzucamy się do wdrożenia proponowanej zmiany,
- rozmawiamy o tym która opcja (bieżąca czy proponowana) są lepsze w aktualnej sytuacji.
Opcji 1 i 2 nie będę omawiał, bo są one obie nierozsądne moim zdaniem – pochopne wprowadzanie zmian “na czuja” rzadko kiedy jest dobrym pomysłem. Pozostaje więc opcja zastanowienia się nad bieżącym i nowym potencjalnym rozwiązaniem. Nie napotkamy wielkiego problemu jeśli omawiany fragment produktu był modyfikowany stosunkowo niedawno i cały proces mamy na świeżo w pamięci. Schody zaczynają się gdy pojawi się pytanie o decyzję z przed 12 lub więcej miesięcy. A od tego czasu przecież wykonaliśmy conajmniej 100 nowych wdrożeń i za cholerę nie pamiętamy o czym wtedy myśleliśmy.
Sytuacja beznadziejna? Bynajmniej!
Całkiem niedawno przypadkowo natknąłem się na bardzo ciekawe narzędzie jakim jest Dziennik Decyzji Biznesowych (BDR – Business Decision Record).
Jest to swojego rodzaju „changelog” tak dobrze znany z obszaru programowania, tyle tylko że poświęcony istotnym decyzjom biznesowym. W ramach pojedynczego wpisu w takim dzienniku możemy zanotować:
- jaki problem/sytuacja wymusiły w ogóle rozmowę o danym zagadnieniu,
- jaki jest kontekst podejmowanej decyzji (np. aktualna sytuacja organizacji, potrzeby, ogólnie „screenshot” czynników które wpływają na decyzję)
- informacja o podjętej decyzji wraz z uzasadnieniem (co i dlaczego)
- konsekwencje – w momencie podjęcia decyzji zapewne nie ma wiele wiedzy o tym co przyniesie dany ruch, ale z czasem na pewno warto zbierać te informacje i uzupełniać dziennik.
Ot i cała filozofia. Raptem jedna tabelka w Excelu albo kilka dokumentów na współdzielonym dysku. Największą rolę odgrywa tutaj dyscyplina jaką sobie narzucamy żeby przede wszystkim sumiennie prowadzić ten dziennik. Może to być o tyle trudne, że zwrot z takiej inwestycji czasu i pracy nie przychodzi natychmiast (choć wyobrażam sobie że za pomocą takich dokumentów można także zgrabnie dzielić się na poziomie całej organizacji informacjami o kluczowych krokach strategicznych, decyzjach biznesowych itd.).
Zrozumienie i wdzięczność z kolei przychodzą dopiero po pewnym czasie gdy natkniemy się na sytuację typowej sklerozy, gdzie nie będziemy pamiętali dlaczego w jednym z dziesiątek modułów jest wdrożone takie a nie inne rozwiązanie – wszystko podane na tacy.
W tym miejscu czułem pokusę aby podać przykładowy „wzór” dokumentu czy struktury dla Dziennika Decyzji Biznesowych, ale pozostawię Tobie jako dociekliwemu czytelnikowi dwa hasła które i mnie doprowadziły do tego konceptu. Liczę że doprowadzą Cię do jeszcze ciekawszych odkryć niż mnie samego 🙂
1) ADR – Architecture Decision Record – forma bardzo podobna, do BDR, tylko że zorientowana na decyzje techniczne/architektoniczne
2) BDR – Business Decision Record – ciekawostką jest że istnieją firmy/organizacje które publicznie prezentują takie dzienniki dotyczące swoich poczynań strategicznych (wiwat transparencja! 🙂 )
Tak więc kończąc ten przydługi artykuł chciałbym odpowiedzieć na pytanie postawione w tytule – aby się nie pogubić, dobrze jest sumiennie prowadzić dziennik który po czasie pozwoli nam wrócić po własnych notatkach jak po śladach z okruszków do momentów i myśli które nam towarzyszyły przy podejmowaniu kluczowych wyborów dla produktu i organizacji.
