Gdyby tytułowe pytanie zadał mi mój przełożony lub rekruter poprowadziłbym temat w stronę astronomicznie wysokich kwot. Na szczęście, ten post nie dotyczy moich osobistych zarobków, dlatego postaram się być obiektywny. Pewnie widzieliście kontrowersyjny film na kanale #białko o tym, czy Scrum Master powinien zarabiać 30 tysięcy złotych miesięcznie. Główny wniosek był taki: „zależy od tego ile on/ona dostarcza firmie”. Chciałbym dziś pokazać, jak możemy ten zysk ocenić.
1. Ile powinien zarabiać Developer?
Inspiracją do wspomnianego wyżej filmiku był mem/plotka odnośnie oferty dla Developera z wynagrodzeniem 40.000 zł miesięcznie. Czy ta stawka jest adekwatna? Widziałem kiedyś raporty dotyczące pewnego produktu, które pokazywały, że generuje on 10 milionów dolarów czystego zysku rocznie. Produkt był tworzony przez 10 osób (Developerzy + Scrum Master + Product Owner). Czyli, programista pracujący nad tym produktem dostarczał firmie około miliona dolarów czystego zysku lub – przeliczając to na złotówki – ponad 300 tysięcy złotych netto miesięcznie! Takie zyski argumentują, że sprawiedliwie było by płacić takiemu Developerowi nawet więcej, niż 40k miesięcznie.
Ale są też argumenty w drugą stronę. Firma może stracić na produkcie 10 milionów dolarów w rok, a tworzący go programiści wciąż dostaną swoje wynagrodzenie. O ile oczywiście wykonują swoją część umowy: przychodzą do pracy, pracują 8 godzin, piszą kod który odpowiada wymaganiom jakościowym. I nie muszą szukać sposobów na spłacenie milionowego długu. Mówiąc wprost – nie muszą mieć do czynienia z ryzykiem prowadzenia działalności.
I zamiast zastanawiać się, to ile w końcu miałby zarabiać Developer (patrząc na obie strony problemu) proponuję spojrzeć na jeszcze większy problem – posiadanie dobrych Developerów nie gwarantuje, że produkt osiągnie sukces komercyjny. Developerzy znają języki oprogramowania, biblioteki, frameworki, bazy danych, wzorce architektoniczne i tym podobne techniczne rzeczy. Niekoniecznie znają się na tym, jak dowozić klientowi to, co będzie generować dla niego zyski, a nie tylko koszty. Jak wspominałem już wcześniej, kod sam w sobie nie ma wartości. Wartość ma oprogramowanie, które potrafi rozwiązywać konkretne problemy.
Wartość oprogramowania = zysk z aplikacji / wartość jej wytwarzania
Fajnie by było mieć kogoś, kto zna się na zwiększaniu wartości oprogramowania…
2. Wartość transformacji zwinnej
Każdy, kto zna historię Agile Manifesto, wie, że powstał on z praktycznego doświadczenia najbardziej wydajnych firm tworzących oprogramowanie. Czyli, z definicji, jest to podejście, które pozwala tworzyć oprogramowanie większej jakości niż w waterfallu. Mamy też dane, które podtwierdzają, że projekty zwinne sprawdzają się lepiej komercyjnie, niż te Waterfallowe. Projekty zwinne osiągają sukces prawie dwa razy częściej i mają 2,5 raza mniejszą szansę na porażkę. Empiryzm mówi, że jeżeli będziemy tworzyć oprogramowanie w podejściu klasycznym, to możemy oczekiwać, że co piąty nasz projekt będzie odnosić porażkę, w porównaniu do 8% dla projektów zwinnych. Możemy teraz policzyć, jaki poziom strat i ryzyka możemy oczekiwać przy jednym lub drugim podejściu.
Konkretne kwoty będą mocno się różnić w zależności od firmy. Jedne organizacje operują w setkach tysięcy dolarów, a inne w miliardach. W obu przypadkach dwukrotne zwiększenie szansy na sukces oraz zmniejszenie szansy na porażkę o 2,5 razy – to spora różnica w tabeli zysków i strat. Ale to jeszcze nie całość tej sytuacji. O ile możemy jakoś oszacować potencjalne dochody oraz straty, np. na kolejny rok, dosyć trudno określić kwoty patrząc bardziej długoterminowo.
Prosty przykład: porażka kilku projektów, oprócz bezpośredniej straty niesie za sobą więcej potencjalnych konsekwencji: firma może zbankrutować, stracić kluczowych klientów i/lub reputację. I na odwrót, sukces projektu lub produktu skutkuje polepszeniem wizerunku publicznego, przyciągnięciem uwagi potencjalnie nowych klientów oraz gromadzeniem środków, które pozwolą wykorzystać nieprzewidziane możliwości i lepiej dostosować się do zmian rynku. I tu już jest bardzo trudno określić jakieś konkretne kwoty. Nie zdziwię się, jeśli w tym zdaniu zawiodłem dużą część czytelników, ale niestety to jest dzisiejsza rzeczywistość tej branży i w dużym stopniu – dzisiejszego świata.
Odnośnie potencjalnych możliwości, przedstawię przykład, który wszyscy znamy. Przez lata Skype był najbardziej rozpowszechnioną aplikacją do prowadzenia rozmów wideo, jednak kiedy wybuchła totalnie nieprzewidziana pandemia, Microsoft nie potrafił tej okazji odpowiednio szybko wykorzystać. Za to potrafił Zoom. Dzisiejszy świat jest tak dynamiczny, że nie możemy wytworzyć precyzyjnego planu nawet na dosyć bliską przyszłość. Bardziej ważne jest, aby być przygotowanym na zmiany, na nowe możliwości oraz wyzwania, dzięki którym możemy sporo wygrać… lub stracić. W skrócie: w dzisiejszych czasach opłaca się bycie zwinnym. I Scrum jest jednym ze sposobów realizacji podejścia zwinnego.
3. Osoba do zwiększania wartości oprogramowania
Według Scrum Guide’a odpowiedzialny za wartość dowożoną przez Developerów jest Product Owner. Nie wiem dlaczego nikt nie zastanawia się, ile on (lub ona) powinien zarabiać. Jest to dobry temat na jeden z kolejnych tekstów. Ośmielę się natomiast zaryzykować stwierdzenie, że Scrum Master też jest za to odpowiedzialny. Tylko pod innym kątem.
SM musi zadbać o to, żeby PO był i wiedział, jak powinien pracować z interesariuszami oraz z Developerami. Musi zadbać o to, żeby procesy wspierające tworzenie oprogramowania o wysokiej wartości (np. Daily, Review, Retro, PBR) odbywały się pomyślnie. Żeby zespół ciągle rozwijał się, uczył się na swoich błędach i nie powtarzał ich. Jestem przekonany, że oburzenie co do sugestii wysokich zarobków SM-a wywodzi się z tego, że ludzie postrzegają tę rolę jako kogoś, kto przeprowadza Daily oraz planowanie Sprintu. Taka mieszanka sekretarki z administratorem.
W rzeczywistości zaś, posiadanie wiedzy na temat zasad Scruma i umiejętność rozpowszechniania ich w organizacji to tylko pierwszy poziom dla SM-a. Scrum Master musi być nauczycielem, trenerem, mentorem, przywódcą. Musi umieć przeprowadzać prezentacje oraz przekazywać wiedzę, znajdować odpowiednie podejście do różnych ludzi o różnych backgroundach i osobowościach. Musi też potrafić rozpoznać, kiedy jest dobry moment na wykorzystanie którejś z wymienionych wyżej umiejętności, a kiedy nie. Scrum Master jest psychoterapeutą dla biznesu tworzenia oprogramowania.
Patrząc na tę listę, robi się wrażenie, że rola Scrum Mastera wymaga osoby o talentach na poziomie Da Vinci’ego. Cóż, w rzeczywistości prawie tak i jest. Bycie Scrum Masterem jest bardzo trudne. Scrum jest bardzo trudny. Bardzo łatwo jest zepsuć wdrożenie tego frameworka – i nie uzyskać jego zalet (patrz: punkt 2). Można nawet stworzyć coś, co sprawdza się gorzej, niż waterfall. Pseudo-Scrum Master nie da rady. Potrzebujemy kogoś o odpowiednich talentach i kompetencjach. A ta osoba potrafi być dużo warta.
