Błogosławiona i przeklęta wiedza o silniku IT

Czy wystartujesz w ekstremalnym rajdzie samochodowym, nie wiedząc, jaka jest moc silnika i ile jest benzyny w baku? Prawdę mówiąc, już wystartowałeś w podobnym wyścigu – rozpoczynając cyfrową transformację, nie znając zakresu zadań i tego, ile „koni mechanicznych” ma zespół rozwijający dla Twojej firmy oprogramowanie. Jeppe Hedaa, CEO firmy 7N, wynalazł metodę pomiaru efektywności IT i napisał na ten temat książkę „Nucleon”. Rozmowa o niezwykłych możliwościach, które daje ta miara, i wstrząsie, jakie jej zastosowanie przyniesie firmom. Chodzi o radykalną zmianę reguł i status quo, jakiemu podlegają CxO.

CEO: Jeppe, gratuluję Ci odważnej i wizjonerskiej książki o Nucleonie, nowym sposobie pomiaru wydajności Developmentu IT. Wydaje mi się niezbędny w erze cyfrowej transformacji, a przy tym to nowe spojrzenie na kluczowy, strategiczny obszar wydajności IT.

Jeppe Hedaa: To rzeczywiście jak odkrywanie nowych, niezbadanych terenów. Efektywność organizacji to dyscyplina zupełnie nieugruntowana.

Zobacz również:

  • 9 cech wielkich liderów IT
  • GenAI jednym z priorytetów inwestycyjnych w firmach

Bardzo mocno sygnalizujesz to już we wstępie książki: tajemnicą Poliszynela jest, że firmy tak naprawdę nie mają żadnej miary wydajności swoich zespołów deweloperskich IT, nie ma też prawdziwej miary wydajności projektów IT.

Dwa tygodnie temu rozmawiałem z członkinią zarządu międzynarodowej organizacji, zajmującej się tematyką zarządzania projektami i zakresem projektów IT. Gdy zapytałem o optymalną metodykę pomiaru wydajności w IT, odpowiedziała: punkty funkcyjne lub tzw. Story Points. Moim zdaniem to sedno sprawy: pomyliliśmy pomiar wielkości projektu z pomiarem wydajności zespołów, ponieważ nie znamy odpowiedzi, jak szacować poziom wydajności organizacji. A wraz z nadejściem metod Agile odkryliśmy, że tak naprawdę problem istnieje nawet przy określaniu wielkości poszczególnych zadań, ponieważ w istocie chodzimy po moście, który jest jeszcze w budowie. Tym samym szacunki i prognozy dotyczące wydajności stały się jeszcze bardziej subiektywne.

W starych metodach kaskadowych przynajmniej wiedzieliśmy, co robić po ukończeniu fazy planowania w projekcie. Czy łatwiej było wówczas przewidzieć koszty projektu i potrzebny czas?

Możliwe, ale nawet w modelu kaskadowym punkty funkcyjne to miara względna. Dlatego że metoda punktów funkcyjnych opiera się na założeniu, ile czasu i ilu ludzi potrzeba do realizacji projektu. Ale i tak wiadomo, że nie jest łatwo określić, ilu osób potrzebujesz do tego projektu. Jeśli są piekielnie dobrzy, zapewne nie potrzebujesz ich zbyt wielu. Ale jeśli to osoby niedoświadczone, będą go zapewne realizować dłużej, a może nawet w ogóle nie uda się go ukończyć. Podsumowując wątek, o którym wspomniałem: kiedy moja rozmówczyni przeczytała „Nucleon”, zaprosiła mnie jako prelegenta na dużą konferencję poświęconą efektywności zarządzania zespołami w Bengaluru.

Nawiązując do poprzedniego wątku, jeśli uda się uzyskać liczbę, która w sposób wiarygodny opisuje wydajność organizacji, zasadniczo zmieni to i uprości zarządzanie zakresem projektu. A kiedy te dwa elementy stają się wymierne, to jakby odkryć sekretne drzwi do świata nowych możliwości. Będziemy mogli wówczas precyzyjnie obliczyć, jak szybko z punktu A dotrzemy do punktu B w danym projekcie, z danym zespołem. Potrzebujemy jasnego zrozumienia prac deweloperskich nad złożonymi systemami IT.

Firmy na całym świecie wydają coraz więcej pieniędzy na projekty IT, zarówno wewnętrznie, jak i na zakupy od dostawców. Nikt jednak samodzielnie, niezależnie od swego doświadczenia, nie jest w stanie opracować planu i określić priorytetów poprawy wydajności poszczególnych elementów nowoczesnego IT.
Rzecz jasna, czynnik ludzki jest najważniejszy, ale wiemy, że wielkość zespołu, kultura organizacyjna, architektura korporacyjna, metodyka projektowa itd. to czynniki, które mogą nas wspomagać albo przeszkadzać w naszych działaniach. Większość ludzi nie będzie w stanie po prostu przeliczyć wpływu tych wszystkich czynników w pamięci. Potrzebujemy do tego narzędzia.

Błogosławiona i przeklęta wiedza o silniku IT

500 egzemplarzy książki "Nucleon" dotrze wraz wydaniem CEO 4/2018 do prenumeratorów magazynu CEO .

Jeppe Hedaa w Polsce

Jeppe Hedaa będzie gościem konferencji Computerworld Zarządzanie Zespołami IT, która odbędzie się w dniach 24-25 stycznia w Warszawie w Centrum Mikołaja Kopernika. Będziemy z nim dyskutować oczywiście o metodzie Nucleon.

Jeden z moich największych klientów zatrudnia 14 tys. osób w IT. Chociaż jest to dojrzała i nowoczesna organizacja, nikt nie wie, co naprawdę dzieje się wewnątrz. Wciąż jest ogromne pole do poprawy. Gdyby ta firma była zarządzana w sposób perfekcyjny, tak jak zarysowałem powyżej, IT byłoby zapewne w stanie dostarczać tyle samo, nawet gdyby zatrudniała nawet 5 tys. osób. Bardzo trudno jest jednak rozwiązać wszystkie ukryte problemy w tak dużej organizacji. To zresztą sygnalizuje kolejną ważną zmianę, która będzie wynikać z wdrożenia metodyki Nucleon. To potrzeba znalezienia najlepszego miejsca pracy dla każdego specjalisty IT w organizacji lub stworzenia dla każdego z nich planu wykorzystania maksimum jego potencjału. Nucleon to błogosławieństwo i klątwa jednocześnie.

Czy zgodzisz się, że wprowadzenie Nucleona może spowodować radykalną zmianę sposobu, w jaki rzeczywistość postrzega dziś wielu decydentów?

Są dwa typy CIO [Chief Information Officer]. Tacy, którzy chcą przetrwać, dopóki nie przejdą do następnej firmy, i tacy, którzy pragną radykalnie zmienić firmę i pozwolić jej zasadniczo poprawić wyniki. Nie sądzę, aby Nucleon przemówił do tych, którzy chcą tylko przetrwać. Natomiast

CIO, którzy chcą zmieniać wielkie organizacje, potrzebują narzędzia, jakie pozwoli im zarówno uzyskać szerszą perspektywę, jak i wniknąć w szczegóły działania poszczególnych zespołów i jednostek w ich organizacji. To niesamowite, ile możesz dostrzec dzięki tej metodzie.
To niczym iluminacja. Nie chodzi o to, aby po wprowadzeniu Nukleona CIO zwolnił 60% pracowników. Będzie mógł natomiast zdecydowanie podnieść wydajność ich pracy w kolejnych projektach.

Dla kogo pisałeś tę książkę?

Pisałem ją z myślą o wszystkich decydentach biznesowych, w tym CIO czy CTO, zaangażowanych w dostarczanie produktów i rozwiązań technologicznych oraz odpowiedzialnych za ich wdrożenie.

Jaki jest odbiór książki i samej idei Nucleona?

Miałem ostatnio dwa bardzo ciekawe i zapadające w pamięć spotkania. Na pierwszym rozmawiałem z jednym z najambitniejszych CIO w Skandynawii. Jest naprawdę mądrymi sympatycznym człowiekiem, a przy tym konkretnym i zorientowanym na wyniki. Powiedział mi, że jeśli udałoby mu się wdrożyć Nucleon we wszystkich podlegających mu 200 zespołach, byłby to najistotniejszy wkład w rozwój organizacji IT od początku objęcia w niej roli CIO. Jego entuzjazm wzbudziła zwłaszcza możliwość lepszego doprecyzowania oczekiwań biznesu. Gdy przedstawiał projekt, zawsze wiedział, jaka jest wielkość przedsięwzięcia, ale nigdy ile rzeczywiście czasu zajmie jego realizacja. Zatem często zawodził oczekiwania, natrafiał na opóźnienia i większe od zakładanych koszty, co wiązało sięz utratą zaufania, na które wcześniej ciężko pracował.

Rozmawiałem także z Jimem Hagemannem Snabe, który jako menedżer jest dla mnie jednym ze wzorów do naśladowania. Obecnie jest przewodniczącym rad nadzorczych firm Maersk i Siemens. Spotkałem się z nim cztery miesiące po objęciu przez niego stanowiska w Maersk i opowiedziałem mu o formule Nucleon. Jim był wcześniej szefem Departamentu Rozwoju w SAP, a potem także prezesem tej firmy. Rozmawialiśmy przez 20 minut, kiedy powiedział: „W ciągu tych pierwszych czterech miesięcy miałem, jak sobie pewnie wyobrażasz, wiele ciekawych spotkań. Ale dzisiejsze jest najciekawsze”.

Czy zatem te spotkania zachęciły Cię do wszczęcia Nucleonowej rewolucji?

Tak i... nie. To nowe podejście do pracy i musimy włożyć jeszcze wiele trudu, aby je upowszechnić. Szczerze mówiąc, nie zastanawiałem się jeszcze nad modelem biznesowym dla Nucleona, nie zastanawiałem się, jak i czy tę koncepcję monetyzować. Postrzegam dziś Nucleona raczej jako mój osobisty wkład i wkład mojej firmy do dziedziny zarządzania w złożonych projektach deweloperskich. Ale prawda jest też taka, że jesteśmy gotowi realizować alternatywne scenariusze.

Pospekulujmy. Może zaczniesz od zebrania społeczności pierwszych użytkowników, którzy zechcą dzielić się doświadczeniami...

Tak. Wspólnie mogliby zbudować podstawy dla analizy porównawczej swoich wskaźników Nucleon: w obrębie branży, według typu projektu, ceny za Nucleon, Nucleonów w przeliczeniu na punkt funkcyjny itd.

Kto powinien być najbardziej zainteresowany zdefiniowaniem obecnej wydajności w zespołach deweloperskich: klienci, dostawcy czy programiści?

Zakładam, że pionierami metody Nucleon będą dostawcy systemów i integratorzy, ponieważ ciąży na nich odpowiedzialność komercyjna. Obecnie mamy powszechnie do czynienia z sytuacją, że menedżer projektu zaprasza CEO do złożenia oferty na dostawę nowego systemu. CEO sam nie wie, czy cena jest odpowiednia, ale od czego ma zaufanego architekta, o skroniach przyprószonych siwizną, który dźwiga na barkach brzemię wielu lat doświadczeń w firmie. Pyta więc go, czy cena jest uczciwa, a harmonogram w miarę realny. Zarówno złożona propozycja, jak i oszacowanie, które wykona ktoś doświadczony, będą mniej lub bardziej oceną intuicyjną.

Nucleon to obietnica zmiany. Wielcy dostawcy systemów czy rozwiązań, integratorzy, software house’y wiele tracą z powodu błędnego oszacowania rzeczywistych kosztów wdrożenia. Administracja jest obligowana do wdrażania usług lub produktów cyfrowych dla społeczeństwa. Jakość oszacowań dotyczących perspektywy wprowadzenia w życie uchwalonych cyfrowych zmian poprawi się radykalnie,

jeśli będą w stanie stwierdzić, że zespół zrealizuje zadanie.

Porozmawiajmy o samej formule Nucleon. Odpowiada ona na pytania dotyczące wydajności w IT, schodząc do szczegółowego, nawet indywidualnego poziomu, a zatem jest u podstaw subiektywna. Czy to słabość?

Przypuszczam, że ocena Nucleona może stać się bardziej obiektywna, kiedy dokona się indywidualnych ocen 360 stopni. Ale koncepcja Nucleon zakłada uproszczenie czegoś, co jest bardzo złożone. Określenie każdego ze wskaźników może zostać zamienione na wielomiesięczny projekt audytu. To tylko kwestia tego, ile chcemy włożyć wysiłku w poznanie potencjalnego rezultatu i jak precyzyjny wynik jest dla nas niezbędny. Istota Nucleona pozostanie taka sama.

Błogosławiona i przeklęta wiedza o silniku IT

Wzór na wydajność developmentu IT (Nucleon)

WZÓR NA WYDAJNOŚĆ ZESPOŁU IT

Elementy składowe formuły NUCLEON

P – czynnik ludzki, oceniamy poziom wydajności osób w zespole, przyznając każdej ocenę

od 1 do 10, każda ocena niesie określone implikacje dla wydajności.

O – czynnik organizacyjny, którego wartość jest dodawana lub odejmowana w zależności

od tego, jak zorganizowany jest departament.

C – czynnik złożoności, odejmujemy wartość opisującą złożoność środowiska.

Nucleon ma potencjał do zastosowania w analizie porównawczej, ale wymaga silnej legitymizacji statystycznej. Aby wiedzieć na pewno, że jeśli dostawca deklaruje, że „wartość Nucleon dla zespołu, który wysyłam do twojego projektu, wynosi 428”, to jest to naprawdę obiektywna miara, a nie sztucznie podbita, np. z myślą o zdobyciu lukratywnego kontraktu.

Byłby to oczywiście ważny krok naprzód, gdyby stworzyć niezawodną, przewidywalną miarę zastępującą oszacowania i zamienić narzędzie intuicyjne w dyscyplinę naukową. Taki nowy sposób pomiaru efektywności pozwoli również profesjonalizować pracę takich funkcji jak HR czy działy zakupów usług IT.

W książce nawet bardziej to akcentujesz: Nucleon to sposób pomiaru, ale także ogólna metoda, która fundamentalnie zmienia podejście działów zakupów.

Zgadza się.

Działy zakupów są obecnie nastawione na dostarczanie jak największej liczby „ludzkich zasobów” w jak najniższej cenie za godzinę. Poza zakresem ich zainteresowania pozostają więc takie sprawy jak efektywność czy cele. Działy ds. rozwoju systemów nie cierpią ich za to, ponieważ dla nich z kolei jedynym kryterium sukcesu jest efektywność dostarczania i kompetencje jednostki. Jeśli ten układ się zmieni dzięki Nucleonowi, te funkcje i działy w firmach zaczną działać spójnie.

Jak jednak porównywać wartości Nucleon dla zespołów Agile i niedziałających w metodykach zwinnych? Myślę, że zrodzi to pewne wątpliwości i może spowodować problemy przy wdrożeniu Nucleona. Organizacje są pod względem metodyki projektowej zwykle hybrydowe. A co jeśli Nucleon nadaje się tylko dla tych elastycznych i sprawnych organizacji z Agile?

Zgodzę się, że Nucleon w obecnej formie nie do końca jest narzędziem uniwersalnym. To nie jest obiektywne narzędzie, które ma dawać wszechwiedzę o wydajności. Ale to bardzo dobry wskaźnik, z którym możesz pracować jako CIO lub CxO i który daje do myślenia. Zastosowanie tej koncepcji najpierw otworzy Ci oczy na obszary i sprawy, które powinny mieć dla Twojej organizacji znaczenie.

Można zacząć od prostego, bezpłatnego narzędzia internetowego do oceny, dostępnego na stronie internetowej Nucleon Formula. Pozwoli to dostrzec kilka ogólnych, ale istotnych faktów dotyczących organizacji. Jeśli np. firma boryka się z kulturą organizacyjną, na pewno w wynikach znajdzie się tego odzwierciedlenie. Otrzymasz jasną i ważną informację zwrotną, która podpowie, gdzie należy szukać potencjału i zmian.

NUCLEON

to jednostka mocy i kluczowy wskaźnik wydajności zespołu deweloperskiego IT. Wartość Nucleona dla zespołu deweloperskiego IT jest tym samym co wartość koni mechanicznych silnika samochodu z zastrzeżeniem, że jednostka konia mechanicznego to naukowa jednostka miary, a Nucleon to narzędzie nawigacyjne pozwalające na szybką ocenę obecnego i potencjalnego

poziomu wydajności twojego zespołu deweloperskiego IT. Nucleon umożliwia obliczenie oceny wyrażonej liczbą z wyróżnieniem obszarów sugerowanej poprawy i ich implikacji dla wydajności.

A to dopiero początek?

Bądźmy realistami. Nucleon nie powinien sterować ludzkim życiem, ale pozwolić na lepsze zaplanowanie działań. Co trzeba poprawić w pierwszej kolejności, którzy pracownicy są najlepsi? Ocena wymaga wiedzy o kontekście, uwarunkowaniach, np.: „Ok, dziś on jest na 5, ale dopiero zaczyna. Ma potencjał na 10”. Lub: „Jest na 5, ale jest z nim coraz gorzej, stracił motywację. Zastąpmy go w zespole 10-tką, zobaczmy, jak taka zmiana wpłynie na zespół”. Taka symulacja to funkcja, którą dodamy do narzędzia online w 2019 r.

Czy umożliwi to użytkownikowi zarządzanie portfelem zespołów?

Tak. Pozwoli to na umieszczanie ludzi na odpowiednich stanowiskach, aby osiągali lepsze wyniki, mogli się lepiej rozwijać itd.

Czy potrafisz sobie wyobrazić, że Nucleon obejmie zarówno wewnętrzne, jak i zewnętrzne zespoły pracujących dla firmy programistów? To wymagałoby powstania długotrwałych relacji, zaufania itp., ale wtedy Nucleon dałby CIO więcej możliwości do skutecznego reagowania na potrzeby biznesowe.

Tak, moim zdaniem to powinien być kolejny krok. CIO, CxO lub PM odpowiedzialni za projekt powinni mieć dostęp do najlepszych osób lub przynajmniej mieć możliwość rozpoczęcia negocjacji: „Potrzebuję Wojtka, który będzie idealny do tej roli i który najlepiej sobie z tym radzi, albo przynajmniej Adama i Pawła”. Obie strony wiedziałyby dokładnie, dlaczego pyta o te osoby i jakie ma to przełożenie na wydajność.

Co dalej? Czy planujesz wprowadzić Nucleon jako swego rodzaju standard? W jaki sposób można upowszechnić tę ideę?

Widzę, że nasi klienci coraz częściej korzystają z metody, i to skłania nas do pomyślenia o modelu biznesowym dla Nucleona. Problem z rozpowszechnieniem Nucleona polega na tym, że nie mogę sobie po prostu zatrudnić ludzi z ulicy i rozwijać go dalej. Muszę szukać osób, które zarażę tym pomysłem i które wiedzą, do czego go użyć. W przypadku firm przymierzających się do Nucleona, to muszą one mieć dość wewnętrznej wiedzy i projektów, aby chcieć szukać możliwości zmian organizacyjnych podnoszących wydajność zespołów ze skromną pomocą Nucleona. To skłania mnie do szukania takich okazji do promowania pomysłu jak Estimation Conference w Bengaluru, o której wspominałem, gdzie wystąpię przed ponad 250 specjalistami. Będą oni mieli szansę na zbudowanie zadaniowej grupy kompetentnych wolontariuszy, którzy sprawdzą skuteczność Nucleona pod względem np. punktów funkcyjnych. Mogą poprosić członków społeczności o tworzenie takich zespołów zadaniowych i rozpowszechnianie pomysłu oraz metodyki.

Jeśli uda nam się ustalić relację między Nucleonem jako wskaźnikiem bezwzględnym a względnymi wskaźnikami punktów funkcyjnych jako sposobem pomiaru zakresu zadań, wtedy jeszcze lepiej będziemy mogli zarządzać oczekiwaniami naszych klientów. Znacznie przybędzie udanych i dostarczonych projektów, wielu CIO zyska popularność, środowiska biznesowe odniosą większe sukcesy itd. A jeśli taki będzie mój wkład, będę z tego bardzo dumny.

Może udałoby się to zrobić tak jak w GitHubie: dostarczysz jądro Nucleona, ale społeczność tworzy dodatki funkcjonalne ważne dla pewnych sektorów, branż itp.

To byłoby świetne. Nie mam nic przeciwko temu, aby inni budowali swój model biznesowy wokół Nucleona. Na doradztwie czy tworzeniu rozszerzeń. Śmiało, zarabiajcie na tym! Zmieniajcie inne firmy na lepsze!

Poza ogólnymi uwagami i pomysłami w swojej książce podzieliłeś się pewnymi praktycznymi, ale i fundamentalnymi zaleceniami. Poruszmy niektóre z nich. Dlaczego 7 to najlepsza liczba dla zespołu?

Dokładna wartość 7 nie jest wcale najlepsza, ale raczej żaden zespół nie powinien liczyć więcej osób niż siedem. (n^2-n)/2 to wzór opisujący liczbę połączeń komunikacyjnych w zespole.

Jeśli zatem masz w zespole trzy osoby, powstają trzy połączenia komunikacyjne, a jeśli cztery osoby – powstaje ich sześć itd. Naprawdę trudne do opanowania robi się to powyżej siedmiu osób w zespole.
Strata energii na komunikację w przypadku zespołów liczących więcej niż siedem osób wynosi 50% lub więcej przy każdej nowej dołączającej osobie. Jeśli więc Twój zespół liczy wiele osób, tak naprawdę nie będziesz wiedzieć, jakie są silne i słabe strony członków zespołu, jak daleko są ze swoimi zadaniami w projekcie itd. Staniecie się głusi i ślepi, a w rezultacie niewydajni.

Sądziłem, że platformy komunikacji cyfrowej eliminują te ograniczenia, uwalniają dostęp do informacji i sprawiają, że komunikacja przebiega gładko.

Właściwie najlepszą liczbą dla zespołu jest 3 – wówczas nie występują żadne straty energii w komunikacji. Aby dostarczyć projekty, niestety, potrzebujesz zwykle więcej kompetencji niż posiadane przez trzy osoby. Wtedy musisz powiększyć swój zespół, za czym idą straty energii na dodatkową komunikację. Tworzenie ruchu, przepływu informacji, komunikacji jest cenne, ale dostarczanie aplikacji tego nie wymaga. Platformy społecznościowe są dobre w tworzeniu przepływu informacji, tworzeniu społeczności i do wymiany pomysłów. Projekty to inna rzeczywistość. To inny modus operandi. Zmiana opinii publicznej to nie to samo co realizacja projektów. Platformy komunikacyjne nie pomogą zbytnio przy projekcie. Przy projekcie wymagana jest bliska współpraca.

Co to znaczy: „zawsze staraj się zatrudniać 10-tki” – najlepsze osoby według Nucleonowej skali od 1 do 10?

Prawda jest taka, że ludzie nie mają takiej samej wydajności. Niektóre osoby radzą sobie niewspółmiernie lepiej niż ich koledzy. Odkryliśmy, że różnica pomiędzy najgorszymi a najlepszymi pracownikami może być nawet stukrotna. Ludzki umysł napotyka na trudności w postrzeganiu tego, ponieważ różnica w wydajności jest z natury wykładnicza. Tymczasem jeśli idziesz na ustępstwa w kwestii idealnego doboru pracowników (zatrudnianie 9-tki zamiast 10-tki), twój zespół traci ok. 43% zdolności dostarczenia projektu.

Nie twierdzę, że na każde stanowisko możesz znaleźć 10-tkę, ale powinieneś zrobić wszystko, co w Twojej mocy, aby tak było. To główne wyzwanie, które stoi przed Tobą jako liderem. Będąc CEO, musisz doskonalić plan działań na każdym polu.
Wyłonić najlepszych pracowników, więcej im płacić, uparcie dążyć do zatrudniania tylko najlepszych, dowiadywać się, jak ich pozyskać do swojej organizacji i jak ich w niej zatrzymać – takie muszą być główne zadania każdego CEO.

W większości firm, w których szef nie kładzie na te elementy nacisku, zaobserwować możemy inne priorytety. Dział zamówień jest wynagradzany za wynegocjowanie najniższych stawek godzinowych, a dział HR toczy zwycięską wojnę z pracownikami, tnąc ich płace za wszelką cenę, tracąc najlepszych. Takie podejście okazuje się ostatecznie wyjątkowo kosztowne.

Znam kilku świetnych CIO, którzy radykalnie zmieniali swoje organizacje IT. Ich motywacje były podobne do tych, które proponujesz: uwolnić ludzkie talenty od nudnej i niekreatywnej pracy, pozwolić im stać się „dziesiątkami”. Ubiegłoroczny zwycięzca konkursu „CIO Roku” zmienił metodykę firmy na DevOps, gdyż wiedział, że standardowy shared services center nie pozwoli prawdziwie rozkwitnąć jego najlepszym ludziom.

Jestem przekonany, że „dziesiątki” są dziś w najczęściej poukrywane w firmach. Nawet w wielu tych firmach, które z dumą znajdują i dbają o małe i elitarne grupki inżynierów, 20 razy wydajniejszych niż średnia. Oni po prostu nie mają pojęcia, gdzie w firmie można znaleźć takie osoby.

Dlaczego?

Precyzyjnie rzecz ujmując, potencjalne „dziesiątki” i tak naprawdę nie są ukryte. Menedżerowie wiedzą, kto dostarcza, a kto nie. Walczą oni o lepsze pensje czy lepsze warunki dla swoich najlepszych członków zespołu itp., ale w korporacjach to nieomal walka z wiatrakami. Prawie każda osoba ma potencjał godny 10-tki, jednak rzadko której udaje się go wykorzystać. Odkrycie własnych umiejętności i optymalne dopasowanie do stanowiska to wielkie wyzwanie.

Czy w taki sposób Nucleon działa już wewnętrznie w 7N?

Najkrótsza odpowiedź brzmi: tak. Od 30 lat pracuję przy rozwoju złożonych systemów IT i często irytowało mnie, że jedyną miarą wydajności było przeczucie. Zacząłem formułować koncepcję Nucleona dwa lata temu. Przez dwa lata była to niejako praca laboratoryjna, w której towarzyszył mi nasz COO. Z czasem, gdy koncepcja nabierała dojrzałego kształtu, zaczęliśmy eksperymentować, obliczając, jak określone zmiany wpłyną na mój zespół.

Jakie są zatem Twoje spostrzeżenia i doświadczenia?

Jak już powiedziałem, formuła Nucleon to zarazem klątwa i błogosławieństwo. Błogosławieństwem jest to, że otwiera Ci oczy. A przekleństwem to, że właśnie otwiera oczy. Bo kiedy tak bezlitośnie obnażysz swój problem, musisz coś z nim zrobić. Nie możesz go zignorować. Mogłeś domyślać się, że problem istniał już wcześniej, ale teraz krzyczą wręcz o nim konkretne liczby, tak jak i o konsekwencjach, jeśli zignorujesz ostrzeżenie.

Dziękuję za rozmowę.

W celu komercyjnej reprodukcji treści Computerworld należy zakupić licencję. Skontaktuj się z naszym partnerem, YGS Group, pod adresem [email protected]

TOP 200