Z pierwszego wykształcenia jestem technikiem-elektronikiem. W tamtych czasach, obowiązkowym punktem uczniów technikum było zaliczenie tak zwanych warsztatów. Warsztaty polegały na pracy w…warsztacie szkolnym i wykonywaniu podstawowych prac z użyciem różnorakich maszyn, począwszy od pilnika, poprzez wiertarkę stołową, tokarkę, na frezarce skończywszy. Uczniowie mieli różne autorskie sposoby na zaliczenie warsztatów, jednak jedna rzecz była traktowana śmiertelnie poważnie – wizytacja dyrektora bądź innych szkolnych oficjeli.

Gdy taka wizytacja wpadała w trakcie zajęć, wizytujący mogli zadać uczniom dowolne pytanie z zakresu nauki. Lepiej było znać odpowiedź, gdyż nieprzygotowany uczeń oznaczał słabe prowadzenie zajęć, a to oznaczało słabą notę dla instruktora prowadzącego, a to oznaczało ekstra prace w postaci wielogodzinnego szlifowania pilnikiem metalowych sześcianów tak, aby wszędzie uzyskać idealne kąty proste (to nie jest takie trywialne jak może się wydawać.)

Zatem każdy uczeń był obryty w budowie tokarki, frezarki, instrukcjach bhp itd. Ale był jeden trik, który mógł uratować skórę. Otóż, czasem w trakcie odpytki można było zapomnieć, jak dana część maszyny się nazywa. Jednak ofcjele byli od wizytowania i na szczegółach maszyn się nie znali. W takim wypadku uczeń, który akurat stracił rezon, bez wahania i patrząc dyrektorowi prosto w oczy, mówił „A to jest bulgulator”. Ostatecznie wychodziło, iż uczniowie budowę tokarek znali doskonale. Oficjele byli zadowoleni, instruktor był zadowolony i uczeń był zadowolony. Wszyscy wygrywali i tak to się kręciło.

Miewam wrażenie, iż na spotkaniach tak zwanego biznesu z tak zwanym IT regularnie realizowane są rozmowy o bulgulatorach mniejszych i większych. Każdy przychodzi ze swoją opowieścią o bulgulatorze, rozmawiają, wygląda na to, iż rozumieją, ale później okazuje się, iż jednak nie rozumieją, iż myśleli, iż to inaczej, iż kto inny, itd.

W kilku następnych akapitach raz na zawsze i z precyzją żyletki marki Polsilver odpowiadam na 2 pytania:

• dlaczego tak się dzieje?
• jak do cholery rozmawiać „po biznesowemu” oraz po „it-owemu”?

Popatrzmy uważniej na proces dostarczania produktu

Na proces dostarczania czegokolwiek końcowym klientom można popatrzeć z kilku różnych perspektyw. Prześledźmy to na (uproszczonym) przykładzie produkcji telefona.

W pierwszej kolejności możemy patrzeć na to, co zużywamy nazwijmy to inputs. W procesie produkcji zużywać można na przykład: półprodukty, czas, etaty.

W z drugiej strony możemy patrzyć na to co robimy (activities). Produkując telefony można angażować się w takie czynności jak: składanie produktu z części, programowanie, testowanie.

Kolejno można przyglądać się temu, co produkujemy, czyli outputs. Produkujemy telefony jakby nie było.

Można również zastanawiać się nad tym w jaki sposób liczy się wartość naszej pracy, a więc outcomes. W przypadku pracy polegającej na produkowaniu telefonów jej wartość można by liczyć np. poprzez zysk ze sprzedaży, czy liczby sprzedanych sztuk.

Ostatecznie pozostaje nam jeszcze do rozważenia w jaki sposób te telefony zmieniają rynek oraz zachowania klientów, są to impacts. Powiedzmy, iż odpowiedź brzmi, iż telefon w taki sposób zmienia zachowania klientów, iż mogą oni komunikować się kiedy chcą, w jaki sposób chcą i z kim chcą.

W przypadku tworzenia systemu to, czemu przyglądamy się w poszczególnych obszarach można rozpisać następująco:

Co znaczy myśleć biznesowo?

Gdy IT spotyka się z Biznesem i zaczynają rozmawiać o dostarczaniu, to jakoś tak wychodzi, iż IT opowiada o produkcie używając pojęć, które na rysunku zaznaczone są na niebiesko. Natomiast Biznes opowiada o tym samym, używając pojęć zaznaczonych na fioletowo.

Biznes mówiąc do IT „wy nie myślicie biznesowo”, ma na myśli właśni owo skupienie IT na niebieskich obszarach. IT mówiąc do biznesu „wy nie wiecie, czego chcecie”, ma na myśli to, iż biznes skupia się przede wszystkim na obszarach fioletowych.

Uwaga spece IT: myśleć/mówić biznesowo oznacza, iż należy mówić o „niebieskich” sprawach dzięki „fioletowego” języka ????. Na przykład należy wyjaśnić w jaki sposób „jakość kodu” jest związana z „większą utylizacją ficzerów” – żeby podać przykład wprost z obrazka.

Żebyśmy się dobrze zrozumieli, nie chodzi o zarzucenie rozmówcy ogólnikami w stylu „Lepsza jakość kodu spowoduje lepsze ficzery i użytkownicy będą je bardziej lubić i będą ich używać częściej”. To brzmi jak opowieść o bulguatorze i nie ma żadnej wartości.

Żeby znaleźć związki pomiędzy „niebieskim” a „fioletowym” obszarem trzeba się nieraz nieźle napocić. Podrzucam do poczytania artykuł Jak sprzedać refaktoryzację?. Opisuję tam własny case z banku Nordea Bank AB. Zobacz w jaki sposób znaleźliśmy związek między jakością kodu a pieniędzmi i zadowoleniem klientów.