Gdzie się podziała nasza efektywność?

2018-04-01 | Sebastian Pietrowski

Kiedy rozmawiałem ostatnio ze znajomym, martwił się, że jego zespół nie dostarcza tak szybko jakby się tego spodziewał. Kiedyś był programistą, dziś jest menadżerem i wspomina, że “za jego czasów” dużo szybciej dostarczało się nowe “ficzery”. A przecież świat programisty jest coraz łatwiejszy… Znajomy ten pracuje w firmie, która poświęca uwagę i czas na to by programistom żyło się lepiej: powtarzalne wdrożenia dzięki odpowiedniej platformie, automatyczny monitoring i wiele innych udogodnień. Dodatkowo ruch open source powoduje, że dziś patrząc na ilość rozwiązań, które możemy po prostu wziąć i wykorzystać w swoim systemie jest ogromna.. Dla przykładu:

Dlaczego tak się nie dzieje?

Sam problem nie jest trywialny i wydawać by się mogło, że dzisiejszy software inżynier ma, oprócz bibliotek open source, do dyspozycji wszystko by dostarczać produkt szybko i w doskonałej jakości. Rozbudowane środowisko programistyczne (IDE) ze wspomaganiem w postaci automatycznego refaktoringu kodu, które mierzy jego jakość oraz podpowiada nam kod w trakcie jego pisania.

Do tego wszystkiego dochodzą narzędzia wspomagające ciągłą integrację, wdrażanie kodu, obsługę wielu środowisk uruchomieniowych w chmurze. Programista nie ma potrzeby czekać tygodniami na nowy serwer czy wykonanie instalacji oprogramowania.

Patrząc na rozbudowane portfolio dostawców rozwiązań chmurowych możemy dojść do wniosku, że programista ma wszystko, czego może potrzebować do pracy, zaczynając od dostępu do maszyn (IaaS), przestrzeni dyskowej, baz danych (różnego zastosowania), systemów kolejkowych, algorytmów, rozbudowanych API przetwarzających określone typy danych (jak np. rozpoznawanie mowy czy obrazów), a kończąc na rozwiązaniach do przetwarzania dużych zbiorów danych:

Czego nam jeszcze trzeba? Czego nam może brakować?

By zajrzeć głębiej w istotę problemu, przytoczę dwa inne przykłady znajomych, którzy w trakcie rozmowy wyrazili wątpliwość w dzisiejsze szybkie dostarczanie wartości:

Pierwszy - po godzinach dorabia tworząc różne produkty. Rozmawiając ostatnio stwierdził coś, co dało mi do myślenia: robiąc po godzinach dostarcza więcej przyrostu niż cały jego zespół. Zakładając, że zespół to około 7 osób i “po godzinach” oznacza około 50% czasu standardowej pracy wynika z tego, że z jakiegoś powodu jest on 14 krotnie bardziej produktywny. Zastanawiające!

Inny kolega w trakcie rozmowy stwierdził: “Wiesz Pedro, tam jest pracy na kilka godzin, niestety jak przepuścimy to przez scruma, to wyjdzie nam ze dwa tygodnie”. Hmm… znów przyjmując proste założenie, że kilka godzin to mniej niż dzień pracy, a dwa tygodnie to 10 dni osiągamy różnicę w produktywności ponad 10-cio krotną.

Co idzie nie tak? W czym mamy problem?

O ile wypowiedź pierwszego kolegi nie daje nam twardego dowodu, który pozwoliłby odnaleźć nam przyczynę tego stanu rzeczy, to druga wypowiedź dobitnie wskazuje na scruma, na pewne ceremonie lub procedury, które spowodują, że “ta sama praca” trwa dłużej.

Scrum jest świetnym frameworkiem do organizowania, wytwarzania oprogramowania, jednakże widziałem wielokrotnie coś, co nazywam religijnym scrumem. Czym on się charakteryzuje?

Wskazałbym kilka wypaczeń, które z rozsądnej grupy zasad, jaką jest między innymi scrum, tworzą “niezbędne do sukcesu PRAWA, które musisz obligatoryjnie przestrzegać” Charakterystyczne dla tych praw są:

  • Jeśli będziesz podążał według tych praw, to Twoja produktywność wzrośnie (hmm… rozumiem, że poranne daily załatwi wszystko),

  • Nie podążasz według jakiegoś “prawa, ‘to powinieneś ponieść karę” (czapka z napisem: “spóźniłem się na daily”)

  • Podążasz za prawem, to powinieneś być z tego dumny - robisz (z pewnością ;/) dobrą robotę (to nieważne, że wdrożenie opóźniło się o kolejny tydzień - ważne, że byłeś na planningu).

Hmm…, nie udało się - nadal nie pracujesz produktywnie - to zapewne oznacza, że nie przestrzegasz prawa lub przestrzegałeś go źle - (daily o złej porze bo nie z samego rana, albo za długo trwa, albo nie zrobiłeś groomingu, itd)

Efektem ubocznym jest również fakt, że skoro mamy zbiór praw i podążamy za nim, to musimy mierzyć nasz sukces w kontekście korelacji z wprowadzonymi prawami. W ten sposób dość często powoływana jest instytucja mierzenia, co w krótkim czasie przeradza się w “mierzenie zajętości” - nieważne czy to co robisz ma sens, ważne że podążasz za prawem i wszystkie wskaźniki pokazują, że robisz to cudownie! :)

Sebastian Pietrowski Technical Advisor Pasjonat nowych technologii, ekspert IT oraz architekt na każdym poziomie - od architektury rozwiązań do architektury enterprise. Menadżer, mentor, coach i konsultant w dziedzinie inżynierii oprogramowania.

Bądźmy w kontakcie

If you have a problem who'd gonna call? Tech Rebels ;)



Jeżeli chcesz zapoznać się bliżej z naszymi usługami lub chcesz z nami rozpocząć współpracę skorzystaj z formularza.

Pozdrawiamy i do usłyszenia,

TechRebels Team.

Napisz do nas