Każdy wie, że zarządzanie ma jakieś zasady. Problem w tym, że nikt nie wie ile tych zasad właściwie jest. Henri Fayol w latach 10. XX wieku wymyślił 14. Peter Drucker w 1966 w “The Effective Executive” opisał 5 praktyk efektywnego działania. Fred Brooks w 1975 w “The Mythical Man-Month” ostrzegał, że dodawanie ludzi do opóźnionego projektu go jeszcze bardziej opóźnia. Każdy z nich miał rację, żaden nie miał monopolu na prawdę.
W Rocket Studio, gdzie zarządzanie projektami IT to chleb powszedni, widujemy wszystkie te zasady w akcji. Czasem działają, czasem nie. Dlatego zamiast kolejnej listy uniwersalnych prawd, przyjrzyjmy się temu, co w zarządzaniu naprawdę się sprawdza, a co wygląda ładnie tylko na slajdzie PowerPoint.
Fayol i jego 14 punktów
Henri Fayol, francuski inżynier górniczy, w 1916 roku spisał 14 zasad zarządzania. Podział pracy, autorytet i odpowiedzialność, dyscyplina, jedność rozkazodawstwa. Brzmi jak regulamin fabryki z epoki przemysłowej, bo nim w pewnym sensie był.
Co ciekawe, te zasady wciąż żyją. “Unity of command” – jeden szef, jeden kierunek – to podstawa każdego sprawnie działającego zespołu scrumowego. Kiedy product owner ciągnie w jedną stronę, a stakeholder w drugą, programiści siedzą sparaliżowani. Fayol to przewidział 100 lat temu.
Ale “scalar chain” – sztywna hierarchia od góry do dołu? W zespole 12 osób pracującym zdalnie nad aplikacją mobilną to po prostu nie działa. Nikt nie czeka, aż informacja spłynie przez 3 poziomy zarządzania. Ludzie piszą na Slacku i problem rozwiązany.
Drucker i zarządzanie czasem
Peter Drucker w “The Effective Executive” nie mówił o zasadach zarządzania w ogóle. Mówił o tym, jak być efektywnym. Pierwsza praktyka: zarządzaj czasem. Druga: skup się na wynikach, nie na pracy. Trzecia: buduj na mocnych stronach. Czwarta: ustalaj priorytety. Piąta: podejmuj efektywne decyzje.
Drucker pisał dla kadry zarządzającej z lat 60., ale jego obserwacje sprawdzają się w IT do dziś. Programista, który nie zarządza swoim czasem, ginie w morzu meetingów, Slacka i “szybkich pytań” od kolegów. Ten, kto nie zna swoich mocnych stron, próbuje być full-stackiem i robi wszystko średnio.
Ale Drucker nie przewidział jednego: świata, w którym priorytet zmienia się co sprint. W 1966 roku firma planowała na kwartały i lata. Dzisiaj roadmapa produktu to wishful thinking na najbliższe 6 tygodni. Priorytety Druckera wymagają stabilności, której po prostu nie ma.
Brooks i mit człowieko-miesiąca
Fred Brooks w 1975 w “The Mythical Man-Month” pokazał, dlaczego projekty software’owe się wykładają. Jego główna teza: jeśli projekt się opóźnia, dodanie do niego ludzi go jeszcze bardziej opóźni. 9 kobiet nie urodzi dziecka w miesiąc.
Każdy kierownik projektu IT powinien mieć wytatuowane prawo Brooksa na przedramieniu. A jednak co tydzień ktoś próbuje “wzmocnić zespół” programistami kontraktowymi na 2 tygodnie przed deadlinem. Efekt: chaos, onboarding zamiast pracy, deadline miniony.
Brooks opisywał też “surgical team” – model, w którym jeden genialny programista ma asystentów zajmujących się testami, dokumentacją, deploymentem. Dziś nazywamy to DevOps i cross-functional teams, ale idea ta sama: nie wszyscy w zespole muszą robić to samo.
Scrum Guide i to, co naprawdę się liczy
Scrum Guide, dostępny oficjalnie na scrumguides.org, definiuje role, eventy i artefakty Scruma. Nie nazywa tego zasadami zarządzania, ale zasadami są. Product Owner decyduje co, zespół decyduje jak. Sprint trwa maksymalnie miesiąc. Daily standup to 15 minut, nie godzina.
W praktyce Scrum działa, kiedy zespół ma autonomię i zaufanie. Nie działa, kiedy ktoś próbuje go nałożyć na organizację, która wciąż zarządza top-down. Wtedy mamy scrumfall: ceremonie Scruma z mentalnością waterfall.
Scrum nie mówi też, jak zarządzać ludźmi. Mówi, jak zarządzać pracą. A to nie to samo. Można mieć idealny sprint backlog i zespół, który się nienawidzi. Można mieć perfekcyjne velocity i produkt, którego nikt nie chce.
Ile zasad naprawdę potrzeba?
Fayol miał 14. Drucker miał 5 praktyk. Brooks miał jedno wielkie ostrzeżenie. Scrum ma framework. Ile z tego jest uniwersalnych zasad zarządzania? Może 3, może żadna.
Bo zarządzanie to nie lista zasad. To seria kompromisów. Między planem a elastycznością. Między autonomią zespołu a odpowiedzialnością przed klientem. Między szybkością a jakością. Kto mówi, że ma 5 uniwersalnych zasad, albo nie zarządzał wystarczająco długo, albo sprzedaje szkolenie.
Najlepsi project managerowie, których widziałem w Rocket Studio, nie cytują Fayola. Pytają: co w tej konkretnej sytuacji zadziała? Czasem to Scrum, czasem to stare dobre Gantt chart, czasem to rozmowa przy kawie. Zasady są po to, żeby wiedzieć, kiedy je złamać.
Źródła
- Brooks F.P., “The Mythical Man-Month”, Addison-Wesley, 1975.
- Drucker P., “The Effective Executive”, Harper & Row, 1966.
- Fayol H., “Administration industrielle et générale”, 1916.
- Schwaber K., Sutherland J., “Scrum Guide”, scrumguides.org, 2020.
Zdjęcie: Thirdman / Pexels
