„Potrzebuję więcej ludzi!”

Data: 2014-10-17
Autor: Sebastian Konkol
„Potrzebuję więcej ludzi!”

To jeden z najczęściej głoszonych przez menedżerów IT problemów. Choć widziałem kilka organizacji IT, w których to zagadnienie rzeczywiście było problemem, w większości przypadków postrzegałem go raczej jak wymówkę, nie rzeczywisty problem. Poprawne sformułowanie problemu brzmi nieco inaczej: jak przydzielić ludzi do zadań, aby w najlepszy sposób wykorzystać ich potencjał. Czy to tylko nieco inne słowa? Być może. Ale w mojej ocenie zakłada ono spojrzenie optymalizacyjne na alokacje wysiłku całej organizacji IT, zamiast po prostu dorzucać ludzi do kociołka.

Tradycyjne podejście „HR dla IT” zakłada statyczne przydzielanie ludzi do zadań oraz wypełnianie „bieżączki” ludźmi. Nawet kontraktorzy, zatrudniani – wydawałoby się – w określonym celu, prędzej czy później „zasilają” rzeszę ludzi przełączających się miedzy trybami „czekam na zadanie rutynowe” i „gaszę pożar”. Nie jest ro, rzecz jasna, rozwiązanie dla problemu braku ludzi.

Moje propozycja podejścia do tego tematu opiera się na dwukrokowej ocenie:

  • Każda praca do wykonania (bez względu czy wynika ona z zakresu projektu, zadania jednorazowego czy powtarzalnego) powinna być oceniana w kategoriach charakterystyki pracy do wykonania i wartości osiąganej dzięki wykonaniu tej pracy.
  • Sposób przydzielenia takiej pracy powinien brać pod uwagę wszystkie dostępne możliwości (pracownik, kontraktor, firma zewnętrzna) oraz opierać się na ocenie wagi biznesowej (wartość, poufność) i ryzyka (przewidywalność, kompetencje, ograniczenia czasowe, nieokreśloności).

Spojrzenie na wartość i ryzyko czyni prostymi decyzjami wiele zagadnień trudnych. Dwa przykłady obszarów, w których prace do wykonania można w łatwy sposób określić:

  • W tradycyjnym podejściu do rozwoju oprogramowania wykonywane są zadania architektoniczne, projektowania systemu, tworzenia oprogramowania, testowania i utrzymania po wdrożeniu. Po nałożeniu na ten obszar miar wartości i ryzyka, natychmiastowym wnioskiem w obliczy „braków zasobów” jest outsourcing prac programisty, testera, inżyniera utrzymania oraz pozostawienie pod kontrolą organizacji prac architekta.
  • W sferze utrzymania systemów podstawową kwestią jest wymagany poziom obsługi („Niby dlaczego znów 24/7?”). Stosunkowo łatwo wskazać systemy, które – w sytuacji braków kadrowych – muszą być bezpiecznie utrzymane siłami własnymi (systemy mission critical), takie, których utrzymanie można outsource’ować (ważne, ale obciążenie pracą nieprzewidywalne) oraz takie, których zabezpieczenie ciągłości działania może być poświęcone („Jak się wywróci, to będziemy myśleć.”).

Jak więc w to wszystko uwikłana jest architektura? Jak zwykle, w prosty sposób:

  • kojarzę pracę do wykonania z konkretnym komponentem architektury (proces, system, moduł, element infrastruktury);
  • skupiam się na rolach i kompetencjach, nie na konkretnych ludziach;
  • określam wymiernie wysiłek wymagany dla realizacji konkretnej pracy;
  • dopiero wtedy dobieram ludzi z właściwymi kompetencjami dostępnymi w wymaganym czasie;
  • w taki sam sposób integruję zarówno prace dotyczące projektów jak i działania rutynowe.

Dobór ludzi to miejsce na zderzenie oczekiwań z dostępnością i możliwością realizacji pracy, ale przede wszystkim na ocenę jej wartości i ryzyka. Jeśli na przykład zadanie jest jednorazowe z charakterystyką nieprzewidywalności, to bezpieczniej jest oddać go na zewnątrz, dokonując transferu ryzyka. Zaczynając od „znalezienia człowieka” taki proces analityczny oparty o wartość i ryzyko w ogóle nie jest realizowany.

Efekty, jakich doświadczają organizacje stopniowo włączając taki tryb myślenia do sfery HR dla IT, są wielorakie, ale można je scharakteryzować według kilku grup:

  • Urealnienie priorytetów dla utrzymania systemów. Zwykle deklarowane reżimy utrzymania są nieadekwatne (zbyt wysokie) do roli systemów.
  • Zapoczątkowanie programów rozwoju zawodowego wynikających z rzeczywistych potrzeb kompetencji. Wprowadzanie współzawodnictwa jest tu bardzo dobrym pomysłem.
  • Obsadzanie najważniejszych funkcji pracownikami własnymi. Kluczowe było tu zrozumienie – często po poważnym zaskoczeniu menedżerów – gdzie te kluczowe funkcje się rzeczywiście znajdują.
  • Outsourcing każdej funkcji, która nie jest kluczowa lub wolumen pracy jest zbyt zmienny. Outsourcing nie oznacza braku kontroli, a w warunkach typowej organizacji IT oznacza wręcz lepszą kontrolę.

Dlaczego w to wszystko ma być uwikłana architektura? Przede wszystkim dlatego, że obrazuje ona obszar rzeczywistej odpowiedzialności – procesy, systemy, infrastrukturę – jakiej musi podołać organizacja IT. Z każdym komponentem architektury – zadaniem w procesie, modułem systemu, elementem sprzętowym – można skojarzyć role wymagane dla utrzymania, optymalizacji i rozwoju architektury. Na bazie tak określonych ról i ich zadań stosunkowo łatwo określić wymagane dla ich pełnienia wysiłek i kompetencje, a przez to skład zespołu. Architektura pozwala bowiem połączyć podstawowy „przedmiot” działań IT z organizacją i uzasadnić strukturę i skład zarówno pracowników jak i partnerów zewnętrznych.

W związku z szybkością zmian zachodzących w IT, kuszącym jest skupienie się wyłącznie na nowych obszarach wiedzy, technologii, czy rozwiązań. Wszak „stare mamy i musimy z tym działać”, więc „do nowych rzeczy potrzebujemy nowych ludzi”. Brak takiego ogólnego podejścia do „HR dla IT” staje się dla menedżerów IT frustrujące, bo ich organizacje puchną nie tworząc żadnej dodatkowej wartości. W końcu, przy kolejnej rundzie „walki o etaty” dyrektor finansowy zwykle sięga po benchmarki i stwierdza, że nie widzi powodu dla zatrudniania dodatkowych pracowników, ani kontraktorów… Architektura korporacyjna (EA, Enterprise Architecture) pozwala na uzasadnienie tej tezy, ale przede wszystkim pozwala na weryfikację samej podstawy dla stawiania takich tez – wprowadza systemowe mechanizmy uzasadniania powodów „decyzji haerowych” do organizacji IT. Traktowana jako kanwa, daje możliwość osiągnięcia stanu ciągłej zgodności w rozwoju zespołu IT ze zbiorem systemów i technologii, jakimi to IT zarządza.

Pozostaw komentarz