Role IT: Produktywność i dostępność

Jako menedżerowie IT stoimy przed koniecznością zarządzania dwoma zupełnie różnymi typami specjalistów technicznych. Te dwa typy profesjonalistów różnią się od siebie nie osobowością ani stylem pracy, lecz samą naturą swoich ról zawodowych. Zrozumienie unikalnych potrzeb tych dwóch typów ról jest kluczowe dla efektywnego zarządzania pracownikami technicznymi, jednak niewiele działów IT naprawdę poświęca czas na zrozumienie i docenienie niuansów tkwiących w tych dwóch różnych rolach zawodowych.

Pierwszy typ, zdecydowanie najlepiej rozumiany, nazwę "inżynierem". Ta rola inżynierska obejmuje ogromną gamę funkcji zawodowych, od programistów i projektantów, architektów, inżynierów systemowych, inżynierów sieciowych po każdego, kogo główną funkcją jest twórcze projektowanie lub wdrażanie nowych systemów dowolnego rodzaju. Termin "inżynier" jest luźny, ale stosunkowo znaczący.

Drugi typ roli pracownika technologicznego można ogólnie określić jako rolę "wsparcia". Do zawodów wsparcia mogą należeć helpdesk, administracja systemami, wsparcie techniczne dla użytkowników, monitorowanie sieci, centrum poleceń itp. To, co odróżnia profesjonalistów wsparcia od inżynierów, polega na tym, że nie są oni odpowiedzialni za procesy twórcze związane z nowymi projektami lub wdrożeniami, lecz pracują z istniejącymi systemami, zapewniając ich prawidłowe działanie i szybką naprawę w razie awarii.

Oczywiste jest, że żaden prawdziwy człowiek nigdy nie będzie całkowicie w tylko jednej kategorii lub drugiej, ale niemal wszystkie funkcje zawodowe w IT koncentrują się bardzo mocno na jednej lub drugiej. Można dość bezpiecznie założyć, że niemal każda rola będzie wyjątkowo ukierunkowana na jedną z nich. Bardzo rzadko zdarza się, by pojedyncze stanowisko było równo podzielone między te role.

Znaczenie identyfikacji ról ujawnia się w wiedzy o tym, jak mierzyć i zarządzać personelem technicznym. Mierzenie i zarządzanie inżynierami, na bardzo wysokim poziomie, jest dość dobrze rozumiane. Pojęcie produktywności jest bardzo proste i znaczące dla ról inżynierskich. Celem zarządzania inżynierem lub zespołem inżynierów jest umożliwienie i zachęcanie tej roli do wytwarzania jak największej ilości twórczego projektu lub wdrożenia. Pojęcie jakości istnieje oczywiście również, ale możemy myśleć ogólnie o rolach inżynierskich w stosunkowo konkretnych kategoriach, takich jak liczba napisanych funkcji, liczba wyprodukowanych pakietów wdrożeniowych, rozmiar zaprojektowanej sieci itp. Metryki są sprawą rozmytą, ale mamy przynajmniej dobre pojęcie o tym, co oznacza efektywność dla inżyniera, nawet jeśli nie możemy jej dokładnie zmierzyć.

Role wsparcia nie mają tego samego pojęcia. Oczywiście można by użyć sztucznej metryki, takiej jak "zamknięte zgłoszenia", do mierzenia produktywności w roli wsparcia, ale byłoby to bardzo mylące. Jedno zgłoszenie może być błahe, a następne stanowić duże wyzwanie badawcze. W wielu przypadkach przez długi czas może nie być żadnych zgłoszeń, a następnie nadchodzi ich wiele naraz, których nie można obsługiwać jednocześnie. Produktywność jest prawdopodobnie sporadyczna i niemożliwa do utrzymania, a ostatecznie zupełnie bez znaczenia do mierzenia.

Stanowiska inżynierskie zarabiają na swoje utrzymanie przez efektywne wytwarzanie efektów przez dość długi czas, często nawet obejmujący miesiące i lata w przypadku dużych projektów. Celem w przypadku stanowisk inżynierskich jest zatem zapewnienie środowiska sprzyjającego zrównoważonej produktywności. Powszechnie wiadomo, że inżynierowie często zwiększają produktywność, pracując skrócone lub alternatywne godziny, regularnie korzystając z urlopów itp. Nie tylko często zwiększa to produktywność, ale często znacznie podnosi też jakość efektów pracy.

Stanowiska wsparcia zarabiają na życie przez "bycie dostępnymi", gdy są potrzebne. Jeśli osoba wsparcia próbuje pracować z maksymalną wydajnością, naturalną implikacją jest to, że istnieje ciągły backlog zgłoszeń czekających na uwagę zespołu wsparcia i że wiele osób potrzebujących pomocy musi na nią czekać, tworząc kolejkę. Utrzymywanie zawsze kolejki oznacza również, że personel wsparcia stale ściąga pracę ze stosu zamiast rozwiązywać bieżące elementy — albo ignorując elementy o wysokim priorytecie, albo będąc regularnie przerywanymi, powodując ciągłe przełączanie kontekstu, co znacznie zmniejsza zdolność do efektywnej obsługi kolejki — której cały cel istnienia polegał na tworzeniu pozorów sztucznej produktywności w pierwszej kolejności.

Role wsparcia są "sterowane zdarzeniami". Lubię tę terminologię, ponieważ uważam, że najdokładniej opisuje tryb, w którym pracuje niemal każdy profesjonalista wsparcia. Niezależnie od tego, czy zdarzenie jest generowane przez telefon, wiadomość błyskawiczną, e-mail czy zgłoszenie, jest to "zdarzenie", które uruchamia przejście osoby wsparcia ze stanu bezczynności do działania lub, w niektórych przypadkach, z elementu o niskim priorytecie do elementu o wysokim priorytecie. W każdym przypadku zdarzenie reprezentuje "przełączenie kontekstu" dla specjalisty wsparcia. Bez zdarzenia nie ma nic do zrobienia dla specjalisty wsparcia. Nawet jeśli "zdarzenie" jest reprezentowane przez kolejkę zgłoszeń lub zaległości e-mailowe, nadal jest to forma zdarzenia.

Posiadanie naprawdę efektywnego działu wsparcia wymaga starannego zarządzania procesem zdarzeń. Posiadanie nigdy nie kończącej się kolejki zgłoszeń jest wyczerpujące dla specjalistów wsparcia i oznacza również, że żadna ilość personelu nie znajduje się w stanie "bezczynności" czekając na elementy o wysokim priorytecie. Z tego powodu elementy o wysokim priorytecie albo nie są obsługiwane tak szybko, jak powinny, albo bieżące elementy są zaniedbywane.

Zrozumienie sterowanej zdarzeniami natury personelu wsparcia jest kluczowe dla zrozumienia podejścia do zarządzania tymi zespołami. Nie ma prostych odpowiedzi, a metryki personelu wsparcia są często jeszcze bardziej bez znaczenia niż metryki personelu inżynierskiego — więc używaj ich z niezwykłą ostrożnością, ale przez empatię z rolą wsparcia możemy zacząć dostrzegać, jak nasza rola jako menedżera wsparcia wpisuje się w szerszy obraz wspierania i promowania członków zespołu wsparcia.

Najważniejszym pojęciem, na podstawie moich doświadczeń, jest zapewnienie dobrego przepływu przerwań trafiających do zespołu wsparcia. Często zespoły wsparcia obsługują szereg różnych kanałów wsparcia, takich jak e-mail i telefon. Ograniczanie i kanalizowanie zdarzeń do odpowiednich kanałów jest kluczowe.

Problem z telefonami polega na tym, że są agresywne i wymagają natychmiastowego przełączenia kontekstu, niezależnie od tego, czy odbiorca jest bezczynny, czy obsługuje aktualnie najbardziej krytyczną awarię produkcyjną w historii firmy. Osoba dzwoniąca zakłada, że jej natychmiastowa potrzeba przeważa nad bieżącymi potrzebami kogokolwiek, kogo aktualnie obsługuje specjalista wsparcia. Telefony powodują ten problem wszędzie tam, gdzie są używane.

Przypomnij sobie ostatni raz, gdy byłeś w pizzerii i składałeś zamówienie przy ladzie. Cierpliwie czekałeś w kolejce, gdy każda osoba była obsługiwana. Zrobiłeś to właściwie. Dotarłeś na początek kolejki. Zacząłeś składać zamówienie, gdy dzwoni telefon. Osoba przyjmująca twoje zamówienie stawia cię na "hold", mimo że stoisz tuż obok, odbiera telefon, przyjmuje zamówienie, odkłada słuchawkę i wraca do ciebie. Co to mówi? Że osoba dzwoniąca, będąca "piszczykiem", jest ważniejsza dla restauracji niż osoby faktycznie w restauracji. Ten sam efekt pojawia się w wielu działach wsparcia — bieżąca praca jest przerywana przez telefony trafiające na linię grupową lub bezpośrednio do osoby wsparcia. Jest to w najlepszym razie nieefektywne, a w najgorszym może zakłócać krytyczne procesy wsparcia w przypadku wysoce krytycznych problemów.

Myśląc o tym, jak zarządzać specjalistami IT, zastanów się nad celem ich roli. Celem inżyniera jest produktywność. Celem specjalisty wsparcia jest dostępność.