Wykorzystanie metodyki Team Focus w projektach Badawczo Rozwojocyh

UWAGA!!. Przedstawione w artykule informacje mają charakter fikcji biznesowo technologicznej i w żaden sposób nie są związane z pracami jakie wykonuje dla mojego obecnego pracodawcy.
Wraz ze wzrostem świadomości informatycznej firm wzrasta w Polsce znaczenie prac badawczo rozwojowych. Stopień wydatków na prace RnD i procentowy udział pracowników w tego typu projektach jest nadal niewielki lecz szczególnie w firmach związanych z nowymi technologiami można zobaczyć duży wzrost inwestycji w tym kierunku. (Firmy te w większości łagodnie przeszły przez kryzys a poczynione oszczędności pozwalają na szukanie przewagi konkurencyjnej poprzez własne badania i prace rozwojowe. Nie bez znaczenia są też możliwości dotacji unijnych , szczególnie dla małych i średnich firm , którym pozwalają nie raz na skokowy wzrost wartości dzięki projektom RnD). Projekty badawczo rozwojowe różnią się znacząco od projektów produkcyjnych , wdrożeniowych. Środek ciężkości tego typu przedsięwzięć zazwyczaj leży poza obszarem protokołu odbioru, budżetu i terminarza. Jak w każdym projekcie są to istotne cechy lecz nie stanowią podstawowego wyznacznika sukcesu i porażki. Projekty RnD mają zazwyczaj charakter problemowy , odpowiedzi na pytanie a produkty pośrednie (takimi jest np. powstałe oprogramowanie czy prototyp) są tylko środkiem do celu. Wyobrażamy sobie sytuację kiedy kierownictwo stawia przed nami pytania np. "Czy opłaca się przenosić nasz system magazynowy do chmury?" , "Jak możemy zwiększyć atrakcyjność i usability naszego interfejsu użytkownika?" , "Czy można wykorzystać technologie 3D w celu zwiększenia atrakcyjności systemu B2B?", "Jakie są możliwości stworzenia w ramach naszej firmy własnej platformy BI" . Są to znakomici kandydaci na prace badawczo rozwojowe. Oczywiście kierownik takich projektów czy R&D Manager muszą poświęcić dużo czasu na doprecyzowanie projektu, określenia jego ram itd. lecz jego sukces to rozwiązanie problemu i odpowiedź na postawione pytanie. Porażką jest jeśli stan naszej wiedzy przed i po projekcie jest taki sam. Przed tworzącym zespół mający zmierzyć się z tego typu zadaniami stają następujące pytania. Jak zorganizować projekt? Jak przygotować zespół? Jak zmobilizować pracowników (analityków , programistów) przyzwyczajonych do określonego sposobu pracy ? Jak pobudzić kreatywność i niekonwencjonalny sposób myślenia? Wydaje się ,że wykorzystanie tylko "tradycyjnych" metod prowadzenia projektów (np. AGILE) IT to zbyt mało. Są one zbyt "systemocentryczne" skupiają się na produkcie a nie na problemie. Szukając odpowiedzi na powyższe pytania trafiłem na książkę "PROJEKT McKinsey - Skuteczne techniki zespołowego rozwiązywania problemów". Dzięki tej lekturze uświadomiłem sobie, że projekty RnD są bardzo bliskie zagadnieniom konsultingu z tym ,że zazwyczaj mamy do czynienia z klientem wewnętrznym jakim jest np. zarząd firmy. Zmieniło się też moje podejście do członków zespołu nie byli oni już tylko programistami, analitykami ale stali się również konsultantami którzy powinni brać aktywny udział w pracach merytorycznych (w dużych korporacjach , organizacja działów R&D może wyglądać zupełnie inaczej ,lecz również i tam od każdego członka zespołu oczekiwana jest większa kreatywność i inicjatywa niż w przypadku typowych zespołów produkcyjnych). Paul N. Friga w "Projekcie McKinsey" przedstawił metodykę TEAM FOCUS , którą z małymi modyfikacjami można znakomicie zaadoptować do projektów badawczo rozwojowych w branży IT. T (talk) czyli jak ustanowić kanały komunikacji w zespole , zarządzać dialogiem interpersonalnym. E (evaluate) jak zespół powinien być oceniany, jak mierzyć postępy prac. A (assist) - wzajemna pomoc w zespole, jak wykorzystać unikatowe cechy i umiejętności członków zespołu. M (motivate) -w jaki sposób motywować zespoł. F(frame) - jak określić problem. O (organize) - jak zorganizować pracę. C (collect) w jaki sposób zbierać informacje. U (understand) - jak zrozumieć zebrane informacje. S (synthesize) w jaki sposób dokonać syntezy wiedzy i ją przedstawić. W następnej częśći artykułu przedstawię szczegółowo poszczególne elementy metodyki na przykładach z branży IT. Postaram się też doradzić na które elementy zwrócić szczególną uwagę a które są specyficzne dla stylu pracy firm konsultinowych jaką jest McKinsey i nie koniecznie muszą znaleźć zastosowanie w projektach IT (chociaż zawsze mogą naprowadzić nas na ciekawy trop i warto im się przyjrzeć).