.st0{fill:#FFFFFF;}

Za mało ludzi do pracy 

 21 stycznia, 2020

Tomasz Dzierżek

Lubię w swoich tekstach rozkładać na czynniki pierwsze często spotykane hasła. „Mamy za mało ludzi do pracy!” to okrzyk, który często można usłyszeć z wielu różnych zakamarków mniejszych i większych organizacji. A mnie zawsze przyprawia on o dreszcze, bo gwarantuje on pewne bardzo określone spojrzenie na sprawę…

 

Za mało ludzi do pracy?

Jeżeli wychodzimy z założenia, że mamy za mało ludzi do pracy, to prawdopodobnie wydaje nam się, że wszystko co jest do zrobienia, trzeba zrobić. Stoi to w sprzeczności z tym, co możemy znaleźć chociażby w 12 Zasadach Zwinnego Tworzenia Oprogramowania, czyli części Agile Manifesto.

Prostota – sztuka maksymalizowania niezrobionej pracy – jest kluczowa” – Agile Manifesto

Temat ten jest przez nas wałkowany od samych początków #białko. Czasami mówimy na ten sposób myślenia „pozytywne lenistwo”, a czasami – pragmatyzm. Chodzi o wyrobienie w sobie nawyku powątpiewania w obowiązkowość wszystkich wymagań. Tak w pracy, jak i w życiu codziennym, bycie sceptykiem jest korzystne. Im bardziej kategoryczne jest jakieś stwierdzenie, tym bardziej podejrzliwie powinniśmy na nie patrzeć.

„Mamy za mało ludzi do pracy” może oznaczać, że tej pracy po prostu za dużo na siebie bierzemy. Nikt nie zastanawia się, który zespół aktualnie realizuje zadania o mniejszym priorytecie. Wszyscy wychodzą z założenia, że „moje jest najważniejsze” i „to musi być zrobione teraz”. A to droga donikąd.

Przede wszystkim, sporo rzeczy może być zrobione później. Nawet jeśli są niezbędne, to wcale nie znaczy to, że są pilne. Ten temat poruszałem już w ostatnim moim tekście „Szybko, bo to ważne„. Idąc dalej, często rzeczy, nad którymi pracujemy teraz mają większy priorytet niż to, co przychodzi z boku. I rozwiązaniem wcale nie jest zatrudnianie kolejnych osób, tylko upewnienie się, że robimy to, co w danej chwili jest najważniejsze.

Jak to zrobić? Na Agile Warsaw zdradziliśmy „Najważniejsze zwinne pytanie, którego nikt nie zadaje„. Brzmi ono „Co się stanie, jak tego nie zrobimy?” Warto je zadawać, bo czasami konsekwencji „niezrobienia” po prostu nie ma. A to nam daje otwartą furtkę do robienia tego, co ważne.

 

Za dużo pracy dla ludzi?

Niezależnie od tego czy weźmiemy pod lupę DSDM i jego metodę MoSCoW, czy Story Mapping, wszędzie znajdziemy ten sam przekaz. Przy tworzeniu rozwiązań informatycznych potencjalnej pracy zawsze jest więcej, niż naszych możliwości.

link-wodotryski,interes,bklg
Każdy klient, sponsor, interesariusz i odbiorca jest w stanie bez końca generować nowe pomysły na funkcjonalności i ulepszenia. A do tego dochodzą jeszcze nasze własne inicjatywy, wodotryski i chęć przeróbek tego, co już zostało zrobione. Backlog nigdy się nie skończy, bo cały czas będziemy do niego dorzucać nowe elementy.

I nawet jeśli mamy „projekt agile” o z góry zdefiniowanym zakresie, to i tak w trakcie jego realizacji mamy gwarancję pojawienia się nowe pomysły i rozszerzenia starych. Nie da się tworzyć skomplikowanych rozwiązań z góry zakładając jak wszystko będzie wyglądało w szczegółach, od początku do końca.

Patrząc na „problem” z tej perspektywy, mówienie, że „mamy za mało ludzi do pracy” jest wtórne. Zawsze będzie ich za mało, niezależnie od tego ilu ekspertów i profesjonalistów zatrudnimy. Prawdziwa przewaga nie polega na robieniu jak najbardziej skomplikowanych rozwiązań jak najszybciej, ale na „szybkim i częstym” wypuszczaniu wartościowych i prostych produktów.

Poziom skomplikowania produktu oczywiście będzie rósł wraz z kolejnymi wydaniami, ale skoro pracy jest za dużo (a nie ludzi za mało), to musimy zająć się jej priorytetyzacją. I to jest najważniejsze zadanie Product Ownera – decydowanie o tym, na co warto poświęcić czas i pieniądze.

Mając nieograniczony budżet i możliwości budowy czego tylko dusza zapragnie, wcale nie skończymy z idealnym produktem, ale z jakimś potworem.

 

Nigdy nie będzie idealnie

Ideały nie istnieją. I nie jest to wcale smutne ani negatywne stwierdzenie. Jest bardzo pomocne dla nas, w naszych codziennych zajęciach i codziennej pracy. Przede wszystkim pozwala nam walczyć z perfekcjonizmem, który jak dobrze wiemy, jest skazany na porażkę. Perfekcja jest ulotna, a pomyłki i niedoskonałości są codziennością.

Empiryzm opiera się o to, co faktycznie się dzieje. Nie jest to życzeniowe myślenie, ale opieranie się o fakty. Nie istnieją idealne umowy, perfekcyjnie rozpoznane potrzeby, niezmienne wymagania oraz świadomi klienci i przewidujący odbiorcy. Dlatego też uważamy, że warto poznać metodyki z pod znaku agile, które takich założeń nie czynią.

To, o czym tak się tu rozpisujemy, wcale nie znaczy, że promujemy nihilizm i/lub bylejakość. To, że nigdy nie osiągniemy ideału nie znaczy, że nie powinniśmy do niego dążyć. Musimy tylko mieć świadomość, że w pewnym momencie ta pogoń przestaje być opłacalna.

Wracając do tematu dzisiejszego tekstu – nie powinniśmy zatrudniać ludzi na hurra, jak tylko pojawią nam się nowe pomysły. Z drugiej zaś strony, robienie Rejtana przed backlogiem i bronienie się rękami i nogami przed każdym nowym wymaganiem również nie wspomaga celu zwinności. Tu potrzebny jest złoty środek. Ale, żeby go osiągnąć musimy zadać sobie bardzo ważne pytania.

Po co tworzymy nasz produkt? Jaki jest nasz cel i jaka docelowa wizja?

Nie da się optymalizować żadnego procesu, jeżeli nie zdefiniujemy kryteriów, które będą oznaczały dla nas sukces. Jeżeli najwięcej korzyści osiągniemy z realizowania wszystkich wymagań, niezależnie od ich jakości – zatrudniajmy ile wlezie. Tylko w świetle tego, co mówiliśmy o zadowoleniu klienta, to nie wydaje się być rozsądną drogą.

Tak więc, najpierw zastanówmy się, po co w ogóle się tak męczymy. A potem spróbujmy zoptymalizować nasze podejście według zadanego kryterium. Dopiero wtedy mamy szansę osiągnąć jakiś sukces, głównie dlatego, że dopiero wtedy zrozumiemy czym dla nas ten sukces jest.

Tomasz Dzierżek


23+ lat doświadczenia w IT, 15+ lat doświadczenia w Scrum i agile, PSM III (i inne), konsultant zwinnych procesów i zespołów, Agile Coach, trener

Your email address will not be published. Required fields are marked

Witryna wykorzystuje Akismet, aby ograniczyć spam. Dowiedz się więcej jak przetwarzane są dane komentarzy.

{"email":"Email address invalid","url":"Website address invalid","required":"Required field missing"}