Krzysztof Olszewski

Dyrektor Technologii i Architektury Oprogramowania

Krzysztof Olszewski

Dyrektor Technologii i Architektury Oprogramowania

Niezapomniany Steve Jobs – dla wielu, guru połączonego świata technologii, wzornictwa i marketingu – zaaprobował kiedyś tytułowe słowa, jako główny slogan reklamowy kampanii Apple’a. Dał tym świadectwo swojej filozofii życiowej i jednocześnie postawił drogowskaz dla wielu jego późniejszych naśladowców. Geniusz tego stwierdzenia (autorstwa Craig’a Tanimoto, jednego z pracowników agencji reklamowej Chiat\Day) tkwi w prostocie i skuteczności. Gdyby uznać, że miarą prawdziwego sukcesu jest sukces, ten taki typowy, z zachodniego świata, wyrażony w finansach czy posiadanej władzy, to właśnie „Think different” jest skutecznym sposobem na osiągnięcie takiego. Dlaczego? To proste. W rynkowym wyścigu działań typowych i szablonowych, można się czymś wyróżnić, czymś oryginalnym. Wyróżnienie to szansa na zauważenie a to w konsekwencji budzi zainteresowanie, co jest już pierwszym krokiem do sprzedaży a jak sprzedajesz – to masz sukces, im więcej – tym większy. Proste. I w dodatku działa nie tylko dla takiej definicji sukcesu. Czy „Think different” może się przysłużyć komuś spoza biznesu? Oczywiście, tak. Rozważmy kolejno przykłady z naszego IT podwórka.

Zmiana. Któż ją lubi? Już wszystko ustalone, rozrysowane, zaplanowane spotkania, wiemy kiedy oddajemy każdy z etapów, jest termin startu testów i najważniejsze, termin startu produkcyjnego. I wtedy pojawia się ona. Albo one. Klient jednak chce inaczej, zmienił zdanie. Zespół testowy nie będzie mógł zacząć zgodnie z planem. Cloud nie będzie gotowy z maszynami a poniedziałek. Jednym słowem, wszystko jest inaczej, niż zaplanowaliśmy. Wiele lat trwała walka z rzeczywistością. Ale od chwili, gdy ktoś postanowił „think different”, wszystko się zmieniło. Agile, mówi, że nie ma sztywnego planu, zmiana jest czymś podstawowym i pożądanym, bo to ona zmienia na lepsze, słabe, początkowe założenia. Działamy iteracyjnie, adaptujemy się do zmian. Klient to rozumie (czy na pewno?) i akceptuje. Wie, że w takim procesie otrzyma nie 100% wymagań, ale coś co jest realnej (dającej się osiągnąć) wartości. Świat stał się lepszy.

Porażka. Tyle pracy, starań i się nie udało. To boli, nie lubimy tak. A gdyby podejść do tego inaczej, zmienić myślenie. Jak wszystko idzie dobrze, to z każdym dniem powinniśmy czuć się coraz mniej pewnie. Podążanie drogą ciągłego sukcesu powoduje stopniowe ślepnięcie, postępujący brak czucia. Po pewnym czasie tak naprawdę już śpimy, zapadamy w lukrowany kasą letarg, nic nie wiemy, poza tym, że mamy sukces. Cokolwiek, drobina piasku w trybach, lekki zefirek zmian, jest w stanie całkowicie nas zatrzymać. A porażka? Tu jest całkiem inaczej. Jest ona ogromnym źródłem doświadczeń i wiedzy, skoro zrobiłem coś źle, a o tym wiem, mam szanse zrobić to lepiej. Uczę się, rozwijam. Wzmacniam. Ktoś powie, że to nie tak. Istnieje taki rozmiar porażki, który zabija, wcale nie wzmacniając. Jasne, oczywiście. Ale kolejny raz pomyślmy inaczej. Skoro tak jest, to spróbujmy zrobić tak, aby spotykające nas ew. porażki były małe, nie zabijające, tylko wzmacniające. Jak to zrobić? Stara jak świat zasada „Dziel i zwyciężaj”. Podzielmy sobie zadania na mniejsze, wielkie projekty na sprinty, wielkie monolity na komponenty. Nawet jak się nie uda to podzielone ryzyko materializując się daje podzielone porażki, mniejsze, takie co nie zabijają. Zauważmy, że prawdziwa droga to sukcesu wiedzie poprzez małe, uświadomione i nie poddane porażki. Mam nadzieję, że dla wielu z nas – dla mnie także – prawdziwy smak i wartość ma sama droga a nie wyłącznie sukces, jej cel ostateczny.

Kontrakt. Każdy lubi jak inni dotrzymują umów. Ale wiemy także, że zazwyczaj nie dzieje się to bez wysiłku. W IT ponosimy ogromne koszty związane z kompatybilnością. Jest to rodzaj umowy dostawcy z odbiorcą. Umowa taka to zazwyczaj deklaracja, że coś czego użyliśmy, będzie miało zachowany kontrakt. Wszyscy wiemy jakie konsekwencje spowodowała decyzja twórców Java’y, kiedy postanowili nie łamać kontraktów z wersji 1.0 aż do dzisiaj. Koszty są ogromne, jednak korzyści są o wiele rzędów większe. A zatem stosując zasadę myślenia inaczej, czy powinniśmy zrezygnować z przestrzegania kontraktów? W tym przypadku proponuję pomyśleć jeszcze inaczej i uznać, że:

kontrakty to jedyna naprawdę istotna rzecz,
implementacje mają mniejsze znaczenie

kontrakty są drogie, powinny być jak najmniejsze, tak małe,
że mniejsze już by nie działały

Zgodnie z tymi zasadami odmiennego myślenia, zastanówmy się osobiście nad pewnymi kwestiami: (1) dlaczego blisko 100% klas w Twoim projekcie jest publiczne? (tak było w tutorialu od Java?), (2) po co Ci tyle testów które testują nie kontrakt tylko implementację (lubisz poprawiać testy?), (3) dlaczego nowa wersja biblioteki psuje Ci builda (czułeś/łaś się jak geniusz, haker, używając jej klas wewnętrznych?), (4) nad API siedziałeś/łaś mało i na końcu (czy na pewno cała reszta jest ważniejsza?), (5) czy powinieneś/nnaś być dumny/a, że można w Twoim narzędziu zrobić wszystko (nie lepiej aby dało się zrobić tylko to co trzeba?). Może uda się Ci zadać samemu/ej sobie podobne pytania? Spróbuj pomyśleć „inaczej”.

Na nadchodzący rok, życzę wszystkim aby był to rok zmiany myślenia w podejściu do wielu kwestii, odejścia od powszechnego szablonu. W tak (tymczasowo, mam nadzieję) niesympatycznie zmienionym świecie, polubienie zmian, akceptacja porażek, skupienie się na zwięzłych sensownych kontraktach, może pozwolić nam wszystkim przetrwać i cieszyć się nowym, lepszym 2021 rokiem.