blog.testowka.pl

Gemba Walk w IT – robimy to źle?

opublikowany przez 25, Sty, 2016, w kategoriach Inne

Ostatnio wdałem się przypadkiem w bardzo ciekawą dyskusję z Michaelem Feathersem na Twitterze. Micheal sprowokował mnie do dyskusji stwierdzeniem:

Gemba is the place where value is created. In manufacturing the genba is the factory floor. In a software org, it’s the code.

Gemba Walk to sposób na odkrywanie problemów. Zgodnie z definicją chodzi o to, by osoby decyzyjne przebywały od czasu do czasu w miejscu gdzie tworzona jest wartość – w miejscu pracy, wśród ludzi (lub maszyn) wytarzających tą wartość. W ten sposób osoby decyzyjne poznają naturę problemów z jakimi boryka się ich organizacja i są w stanie je skutecznie rozwiazywać  W fabryce miejscem takim jest hala produkcyjna. Pozostaje pytanie co jest takim miejscem w organizacji bazującej na wytwarzanym oprogramowaniu?

W całym tym naszym Agile ciągle powtarzamy, że chodzi o to, żeby zbliżyć IT do biznesu. Wynika to między innymi z potrzeby przezwyciężenia  Prawa Conwey’a, które mówi o tym, że organizacje projektujące systemy, budują rozwiązania, które są odzwierciedleniem struktur komunikacyjnych tych organizacji. Jak zatem to robimy i dlaczego źle? Wszystkie te nasze Scrumy i inne metody zakładają, że trzeba zbliżyć developerów do biznesu. Trzeba rozmawiać z biznesem na temat produktów i domeny biznesowej, tak aby developerzy lepiej rozumieli biznes.

Jako Agile Coach czy Scrum Master moja praca sprowadzała się zazwyczaj do sprawienia by developerzy zobaczyli trochę szerszą perspektywę niż ich kawałek kodu i jednocześnie by biznes zrozumiał o co chodzi w tym developmencie. I zazwyczaj to wystarczało by znacząco poprawić efektywność stosowanych procesów.

A co jeśli to jest niewystarczające? A co jeśli można by osiągnąć znacznie więcej? A co gdybyśmy spróbowali zrobić to wszystko w drugą stronę, a najlepiej w obie i nie tylko ciągać developerów do biznesu, ale też biznesowi pokazać kod? W końcu w Gemba Walk chodzi o to, by to osoby decyzyjne poruszały się po miejscu, gdzie tworzona jest wartość. O ile developerzy owszem mają wpływ na wiele decyzji i sporo ich mniej lub bardziej świadomie podejmują to jednak przeważnie więcej decyzji podejmowanych jest w biznesie.

Co by się stało gdybyśmy pokazali biznesowym osobom decyzyjnym nasz kod, albo przynajmniej architekturę aplikacji? Co by było gdybyśmy co tydzień poświęcali godzinę na przeprowadzenie naszego CEO przez kawałek kluczowego dla naszej aplikacji kodu?  Ile problemów mogli byśmy w ten sposób wykryć?

No dobra, może nie od razu CEO ale może ktoś inny z biznesu powinien od czasu do czasu przejrzeć nasz kod… Jak często zdarza się wam, że nazewnictwo klas czy metod użyte w kodzie nijak się ma do języka stosowanego w biznesie? Jak często coś takiego prowadziło do nieporozumień? Jak często mówicie, że czegoś nie da się zrobić w waszej aplikacji, gdyż model aplikacji zupełnie nie odpowiada modelowi biznesowemu waszej organizacji?

 

 

 

 


Skomentuj