Informatyka należy zmierzyć i mądrze nim zarządzać

Dla przykładu: w pewnej firmie tworzącej oprogramowanie nie ma zdefiniowanych procesów, bo jej informatycy uważają (a kierownictwo podziela ten pogląd), że takie ustrukturalizowane, deterministyczne środowisko stoi w sprzeczności z twórczym duchem informatyki. Błędy w systemie zgłaszane przez klienta wędrują różnymi kanałami i opisane są na różnym poziomie szczegółowości. Nie ma zdefiniowanych procedur postępowania z nimi; czas reakcji jest jasno określony, ale nie ma narzędzia i osób odpowiedzialnych za dotrzymanie go (a gdyby nawet były, to i tak za przekroczenie nie ma żadnych konsekwencji).

Wizja człowieka jako trybika, organizacji jako systemu, podlegającego statystycznym równaniom, zaś ludzi jako istot biernie poddających się systemowi kar i nagród, nie ma za wiele wspólnego z rzeczywistością.

W innej firmie przyjęcie błędu odbywa się przez ustrukturalizowaną formatkę, która wymaga podania m.in. szczegółowego opisu, warunków występowania, osób kontaktowych. Proces obsługi błędu ma określone terminy i osoby odpowiedzialne, zaś narzędzie i pracująca z nim osoba czuwają, aby klient w określonym czasie dostał odpowiedź i poprawkę. Zdefiniowane i osadzone w narzędziach procesy biznesowe pozwalają na stworzenie ilościowego obrazu sytuacji i comiesięczne rozliczenia: to było robione dobrze, to źle i wymaga poprawy.

W której firmie pracownicy mają więcej czasu na myślenie i innowacyjne działanie w dziedzinie inżynierii oprogramowania? W której mogą poświęcić swoją uwagę dochodzeniu istoty rzeczy i wymyślaniu nowych rozwiązań? Oczywiście, w tej drugiej - nie przerywają im ciągłe telefony, listy elektroniczne od zirytowanych klientów, zmiany planów, terminów, priorytetów i osób odpowiedzialnych za daną sprawę. Każdy wie, czy w ostatnim miesiącu było dużo problemów, czy mało i czy oprogramowanie zainstalowane u klientów jest stabilne, czy raczej nieustająco "chwieje się" i wymaga angażowania specjalnych sił, w celu poprawnego działania. Wiadomo także, czy wsparcie użytkowników aplikacji wykonywane jest dobrze, czy źle - bo istnieje obiektywne, ilościowe kryterium.

(Ir)racjonalne zarządzanie

Gdyby w ten sposób zarządzane były firmy informatyczne! Niestety, menedżerowie, zdefiniowawszy procesy i miary, idą o krok dalej, czyli zaczynają wyobrażać sobie, że skoro mają liczby i obiektywne kryterium prawdy, mają już cały "system zarządzania". Wystarczy związać poziom wynagrodzenia pracownika z poziomem miary i oto mamy organizacyjne perpetuum mobile. Wystarczy usiąść i w zachwycie patrzeć, jak samooptymalizująca się machina działa! Prawda?

Niestety, nie, co dawno wykazało życie. Pojawienie się czynnika kary i nagrody sprawia, że maszyna nie tylko nie działa sprawniej, ale w ogóle się psuje. Jeżeli, na przykład, zaczniemy płacić premie uzależnione od czasu rozwiązania błędów, szybko zacznie pojawiać się bardzo dużo bardzo szybko rozwiązywanych błędów. Jeśli od liczby błędów, to przestają być one notowane, tylko są przekazywane "pod stołem", żeby nie pogorszyć wskaźników - przecież wszyscy jesteśmy ludźmi i musimy sobie pomagać, prawda? Jeśli zaczniemy płacić administratorom w zależności od dostępności ich aplikacji, szybko będziemy mieć bunt na pokładzie, bo niby dlaczego administratorzy mieliby odpowiadać za awarie wywołane przez tani sprzęt, programistów albo oprogramowanie podstawowe (system operacyjny, motor bazy danych). A do tego mamy także niesnaski miedzy jednymi a drugimi ("przez tych idiotów programistów straciłem premię!").


TOP 200