RegułyChaosu

Instytucja „tajemniczego klienta” jest znana od wielu już lat. To taki „podstawiony” klient, który korzysta z usług określonej firmy, a w tym czasie dokonuje zaplanowanego badania sposobu świadczenia tych usług. Oczywiście, na zlecenie kierownictwa badanej firmy. Zawsze wydawało mi się, że ja nie mógłbym pełnić takiej roli (kompletnie nie umiem kłamać i nie toleruję kłamstwa), ale ostatnie doświadczenia z dwoma firmami telekomunikacyjnymi nakazują mi się nad tym jeszcze zastanowić (nad byciem tajemniczym klientem, nie kłamstwem, rzecz jasna).

Literatura gatunku proponuje kilka metod oceny dojrzałości kierownika projektu. Większość z nich opiera się o dojrzałość o charakterze Capability Maturity Model. Ja uknułem sobie nieco inny, trzystopniowy model dojrzałości kierownika projektu. Oto on.

Od miesiąca zbieram się, żeby napisać kolejny wpis w tym blogu, ale nie bardzo mam jak. Od ponad 6 miesięcy pracuję w bardzo ciekawym projekcie. Jedna ze służb wchodzących w skład administracji publicznej w Polsce uzyskała całkiem spore wsparcie unijne, dzięki czemu może dokonać poważnej transformacji swego działania – organizacji procesowej, wsparcia informatycznego, nastawienia na wzrost kraju. Może o tym kiedyś napiszę, jak już będzie się czym chwalić. Tym razem zachowam się jak typowy Polak – będę narzekał.

Czytaliście “The Big Switch” napisane przez Nicholasa G. Carra (tego od “IT Doesn’t Matter”)? Jak to w jego stylu, promuje on zmuszającą do przemyśleń wizję tego, co dzieje się teraz w IT, czyli – w mojej nomenklaturze – w informatyce użytkowej. Złożoność systemów informatycznych, ich rola i sposób, w jaki wchodzą w interakcje z ich użytkownikami ewoluuje przez czas liczony już w dziesięcioleciach. W efekcie tej ewolucji, podczas kilku dekad istnienia oprogramowania w cywilizacji ludzkiej, relacje między oprogramowaniem a jego użytkownikiem zmieniło się dość dramatycznie. Na samym początku tej drogi, zarówno programowanie (jako czynność tworzenia oprogramowania) jak i używanie go nosiły znamiona tajemnicy. Choć dzisiaj trudne to jest do zrozumienia, korzystanie z komputera wymagało głębokiej wiedzy inżynierskiej. Troszkę później, kiedy zamiast kart perforowanych były już urządzenia wejścia-wyjścia (klawiatura, stacja dysków), programowanie stało się odrobinę wygodniejsze, a w dziedzinie użytkowania programowania odczuwano nawet większe postępy. Tym niemniej, role twórcy oprogramowania i jego użytkownika były dość mocno rozdzielone. W dzisiejszych warunkach, te dwie role są coraz mocniej „zmiksowane”, istnieje coraz mniej zagadnień, które mogą być bezdyskusyjnie określone jako przynależące do domeny inżynierskiej, jaką nazywany software engineering.

Skończyła mi się ostatnio umowa „promocyjna” na usługi telefonii komórkowej. Bez wątpienia nie jest bardzo wartościowym klientem dla operatora (jestem raczej małomówny, a przez telefon tym bardziej), więc nie spodziewałem się wodotrysków. Potraktowałem tę sytuację jako pretekst do badań z pogranicza psychologii społecznej i biznesu. I dobrze, bo przy innych założeniach te proces zakończyłby się po drugim kroku. A było to tak.