Zaznacz stronę
Home 9 IT 9 Projekt Feniks Powieść o IT, modelu DevOps

Projekt Feniks Powieść o IT, modelu DevOps

utworzone przez | sierpień 2, 2021 | IT, zarządzanie | 0 komentarzy

 

Projekt Feniks to książka dedykowana dla managerów, specjalistów IT oraz osób, które chcą lepiej zrozumieć biznesową część wytwarzania oprogramowania. W dość przystępny sposób pozwala zrozumieć, z jakimi problemami zmagają się spółki technologiczne wytwarzające oprogramowanie. Jest to powieść, więc książkę czyta się przyjemnie (nie jest to typowy podręcznik zarządzania).

Firma Parts Unlimited Boryka się z wieloma problemami. Konkurencja wyprzedza ją pod każdym względem. Realizują kolejny rok z rzędu projekt Feniks, który pochłonął firmę miliony dolarów i jest wciąż niegotowy. Na domiar złego w dziale panuje niesamowity chaos. Zadania są realizowane na ostatnią chwilę, brakuje priorytetyzacji, dokumentacji czy procedur. Cały know-how technologiczny posiada główny programista Brenet zaangażowany we wszystkie kluczowe projekty.

 

Fabuła książki Projekt Feniks

 

Głównym bohater jest Bill Palmer, który na początku książki awansuje z kierownika działu systemów klasy Midrange na stanowisko wiceprezesa ds. eksploatacji systemów informatycznych CIO. Bill zostaje rzucony od razu na głęboką wodę. Jego celem jest poukładanie procesów w dziale IT, release największego projektu informatycznego w historii firmy Feniksa oraz ścisła współpraca z pozostałymi działami w zakresie wsparcia IT.

 

Każdy, kto miał styczność z wytwarzaniem oprogramowania w IT, znajduje odpowiednika w przynajmniej jednym z bohaterów z tej książki. Dostajemy obraz ludzi ze sprzedaży, marketingu, administracji, logistyki, managerów najwyższego i średniego szczebla, aż do specjalistów włącznie. Dzięki temu autor przedstawia nam obraz całej firmy oraz oczekiwań poszczególnych działów w stosunku do działu eksploatacji systemów informatycznych.

 

Pozwala to zrozumieć, że z punktu widzenia każdego managera firmy Parts Unlimited, każdy projekt ma najwyższy priorytet. Natomiast zadaniem Billa było określenie tych najważniejszych z punktu widzenia całej organizacji. Dzięki wsparciu Erika (nowego członka zarządu) Bill odkrywa krok po kroku nowe problemy w dziale i dochodzi do następujących wniosków…

 

Trzy główne drogi zarządzania Dev Ops Projekt Feniks

 

Pierwsza droga pomaga określić jak zapewnić szybki przepływ pracy między działami w rozwoju aplikacji i eksploatacji systemów informatycznych, ponieważ to właśnie one znajdują się między biznesem a klientem. Autor nawiązuje do linii produkcyjnej, w której optymalny przepływ prac to taki w którym czas od rozpoczęcia zadania do jego zakończenia jest jak najkrótszy.

 

Druga droga uczy jak skrócić i wzmocnić obieg informacji zwrotnych, co pomaga podnieść jakość pracy. Pozwala uniknąć tych samych błędów. Standaryzuje obecne działania, tak aby były wykonywane optymalnie.

 

Trzecia droga pokazuje jak rozwinąć kulturę, która jednocześnie, zachęca do eksperymentowania i wyciągania wniosków, z błędów, a także prowadzi do zrozumienia, że powtarzanie i praktyka są niezbędne, by osiągnąć mistrzostwo. Zachęca do podejmowania ryzyka i szukania niestandardowych działań, dzięki temu rozwija się kultura innowacyjności.

 

Drugi fundament Dev Ops – cztery rodzaje wykonywanej pracy

 

Pierwsza praca nad projektem biznesowym. Budująca wartość dla klienta oraz zapewniająca przychód firmie.

 

Druga praca to projekty wewnętrzne. Nie wpływa w sposób bezpośredni na projekty biznesowe, ale jest nieunikniona w celu zapewnienia funkcjonowania firmy.

 

Trzecia praca to wprowadzanie zmian. Powstaje wskutek nieustannego uczenia się.

 

Czwarta praca to zapobieganie nieplanowanym pracom “pożarom”. Wynika z błędów zarządzania i jest najczęstszym katalizatorem problemów w firmach.

 

Pierwszym kluczowym krokiem poza odnalezieniem powyższych dróg oraz rodzajów prac głównego bohatera jest odcięcie Breneta (głównego dewelopera) zaangażowanego w niemalże każdy większy projekt od zadań pobocznych i ustandaryzowanie jego pracy. W tym celu Bill powołuje zespół 3 programistów, którzy wyłącznie mogą się kontaktować z Brenetem oraz dokumentują jego pracę.

Kolejnym wydającym się bardzo ryzykownym krokiem naszego bohatera jest zamrożenie wszystkich prac, niezwiązanych z głównym projektem Feniksem, aż do momentu jego releasu. Dzięki temu zespół może skupić się wyłącznie na najważniejszym z punktu widzenia biznesu projekcie.

 

Najciekawsze cytaty z książki

 

Projekt Feniks

 

 

 

“Dopóki nie uzyskasz kontroli nad planowanymi pracami. Nie będziesz mógł tak naprawdę niczym zarządzać.”

 

“Nieplanowane prace mają też inny efekt uboczny, gdy cały czas zajmowany jest przez gaszenie pożarów zostaje mało czasu i energii na planowanie. Jeśli zespół tylko reaguje na wydarzenia, nie ma, kiedy wykonać ciężkiej pracy umysłowej, by ustalić, czy może podjąć się nowych zadań. Dlatego rozpoczynane są kolejne projekty, a na każde z nich jest coraz mniej czasu. To oznacza więcej niekorzystnego przeskakiwania między zadaniami. Więcej eskalacji problemów wynikających z niskiej jakości kodu oraz więcej skrótów. Jak ujął to Bill, który kręci się w kółko: “to prawdziwa spirala śmierci dla wydajności w dziale IT”.

 

“Problem polega na tym, że nie potrafimy odróżnić, które pracę mają dla firmy znaczenie, a które są nieistotne. Ty, masz ten sam problem polegający na umiejętności wyeliminowania systemu zbędnych prac.”

 

“Eliminowanie zbędnych prac jest ważniejsze niż dodawanie do niego nowych zadań.”

 

„Usprawnienia codziennej pracy jest ważniejsze nawet od jej wykonywania.”

 

“Świetny zespół nie musi składać się z wyjątkowo inteligentnych ludzi. Tym, co daje zespołowi jakość, jest wzajemne zaufanie. Wynikająca z niego magiczna dynamika może, dać nam prawdziwą siłę.
Jedną z moich ulubionych książek na temat dynamiki w zespołach jest five dysfunctions of a team.”

 

Cytat odnoszący się do tempa wykonywanych prac

 

“Przestań koncentrować się na docelowym tempie wdrożeń. Elastyczność w biznesie to nie tylko sama szybkość. Ważne jest, jak dobrze radzisz sobie z wykrywaniem zmian na rynku i reagowaniem na nie, a także czy potrafisz podejmować większe i lepiej skalowalne ryzyko istotne są ciągłe eksperymenty.”

 

Cytaty, które zrozumie, każdy pracujący w IT 🙂

 

“Najwyższy priorytet ma ten, kto najgłośniej krzyczy.”

“Nic nie jednoczy ludzi bardziej, niż narzekanie na dział IT. “

Podsumowanie

 

Książka przedstawia wdrażanie zmian, jako część rutynowego procesu, w którym krok po kroku eliminujemy zbędne prace, standaryzujemy wykonywane czynności, czy zamrażamy wszystkie projekty z niskim priorytetem na rzecz projektów o najwyższej biznesowej wartości. Bohater bez względu na bodźce z zewnątrz (presję managerów innych działów) dokonuje całkowitej restrukturyzacji działu. Co ciekawe na drodze do ustandaryzowania prac działu Bill musiał postawić się zarządowi i odejść z pracy na krótki czas, aby dopiąć swego.

Grzegorz Sękowski
Grzegorz Sękowski

eCommerce manager oraz właściciel sklepu internetowego napnell.pl. Zawodowo pomagam tworzyć sklepy internetowe oraz zwiększać w nich sprzedaż. Prywatnie miłośnik szachów, sqasha oraz kina.

Tagi:

0 komentarzy

Wyślij komentarz

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *