RegułyChaosu

Możliwość globalnej optymalizacji, szczególnie jeśli chodzi o zdolność do prowadzenia biznesu w dowolnym wymiarze, jest często elementem uzasadnienia biznesowego dla wprowadzania istotnych zmian. Dotyczą one zarówno sposobu funkcjonowania (procesy biznesowe) jak i narzędzi wspomagających (architektura systemów informatycznych). Wiele razy spotykałem się z takim uzasadnieniem i jeszcze nigdy – w wyniku uzasadnianych przemian – nie powstał „organizm” globalnie optymalny. Ewidentnie, globalna optymalizacja w przyrodzie nie występuje. Tylko dlaczego?

Odpowiedź szybka: wszędzie. Co więcej, w im większym obszarze doszukujemy się stosowania filozofii agile, tym lepiej, bo sukces we współczesnym świecie coraz częściej zależy od rozwiązań “good enough”, nie “perfect”. A właśnie w związku z istnieniem takich problemów pojawiła się filozofia agility i skuteczności w takich sytuacjach służy filozofia agile.

W ostatnim czasie miałem przyjemność uczestniczyć w II Forum Kierowników Projektów IT, a nawet prowadziłem stolik ekspercki na temat komunikacji w projekcie. Było bardzo ciekawie, ale podczas tego forum naszły mnie przemyślenia jakby nie licujące z tematyką i majestatem tego wydarzenia. Otóż mam wątpliwości co do instytucji projektu IT. I to poważne. Trochę nie wiem, jak z tego wybrnąć, ale może rozgorzeje jakaś dyskusja poniżej tego wpisu i okaże się, że jestem w karygodnym błędzie. Tym niemniej, na teraz uważam, co następuje.

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.