Rozwijanie produktu IT - Skalowanie rozwoju

Do napisania tego tekstu zmotywowała mnie sytuacja kilku z naszych ostatnich klientów, którzy mimo różnych branż mają ze sobą wiele wspólnego. Znamienne, że nasze ścieżki przecięły się właśnie w momencie gdy ich produkty odniosły sukces. Jednak tak to już jest w biznesie, że każdy sukces wiąże się z szeregiem nowych wyzwań.

Plan sytuacyjny

Oto kilka elementów, które łączą tych klientów:

• są to firmy produktowe, oferujące produkt informatyczny B2B,
• zostały założone przez programistów, którzy byli pierwszymi koderami w firmie,
• wytworzyły doskonałe produkty, które z sukcesem są wdrażane u szeregu klientów w Polsce,
• prowadzą udaną ekspansję zagraniczną,
• są średniej wielkości, przy czym IT stanowi aktualnie mniej niż połowę zespołu (reszta to działy biznesowe i administracja),
• mają świetny zespół programistyczny, znający na wylot oferowany produkt,
• własne zasoby IT nie wystarczają do pełnego zaspokojenia nowych potrzeb wynikających ze skalowania, nowych rynków itp.

Właśnie sukces, jaki odniosły ich produkty, stawia ich w trudnej sytuacji. Można by powiedzieć, że są to problemy, które chciałoby się mieć. Jednak trzeba mieć świadomość ogromu wyzwań, przed jakimi stoi kierownictwo dynamicznie rozrastającej się firmy. Paradoksalnie sukces biznesowy może być dużym problemem, jeśli infrastruktura i produkcja nie nadążają za biznesem. Poza wspomnianą wyżej koniecznością zwiększenia efektywności produkcji (w tym wypadku działu programistycznego) pojawia się kwestia szeroko pojętej administracji, która musi udźwignąć nowy ciężar. Firma musi rosnąć, rekrutować, zmienić biuro na większe. No i oczywiście ktoś nadal musi planować i prowadzić działania marketingowe, sprzedażowe, podejmować kluczowe decyzje itp. Procesy, które zarząd jeszcze niedawno prowadził bezpośrednio (lub przynajmniej ściśle nadzorował) muszą być przekazane w inne ręce. Najlepiej w ręce fachowców. Ale już samo rozeznanie, kto jest fachowcem,wymaga czasu i uwagi zarządu. Istne błędne koło.

Pole bitwy

Idąc w militarystyczne paralele, dochodzi do sytuacji, w której generał walczący na froncie nowych wyzwań biznesowych odkrywa, iż ma spore problemy na tyłach. Kwatermistrzostwo sygnalizuje, że wydajność logistyki spada, a dodatkowo coraz trudniej ściągać posiłki. W dodatku każdy nowy zaciągnięty rekrut nie dość, że prochu nigdy nie powąchał, to jeszcze jest coraz młodszy, coraz mniej potrafi i nie zna realiów pola bitwy. Sytuacja jeszcze nie jest zła, ale doświadczony generał wie, że już teraz musi podjąć działania, by zapobiec tragedii. Opcji jest wiele, ze wstrzymaniem ofensywy włącznie. Ale to oznaczałoby porażkę. Zamiast tego lepiej skorzystać z pomocy zaprzyjaźnionego mocarstwa. I tu na scenę wkraczamy my. 😉 Nasz desant zapewnia dopływ świeżej krwi i podnosi morale wojska. Wraz z posiłkami w postaci nowych szeregowców na front przybywa również kadra oficerska i komandosi. Co więcej, nasz oficer sztabowy całym swym doświadczeniem wspiera głównodowodzącego.

No, może trochę popłynąłem z tą militarystyczną analogią. 😉 Ale w gruncie rzeczy oddaje ona sytuację, o której mówię. Czyli sytuację firmy programistycznej, która stopniowo (albo gwałtownie) przekształca się z ze start-upu w dojrzałą firmę. W której zarząd jeszcze niedawno nadzorował każdy detal produktu, zatrudniał osobiście każdego nowego programistę, czytał każdą linijkę większość kodu. A teraz musi skupić się na działaniach typowo biznesowych. Wręcz musi się zmuszać do ignorowania detali na poziomie mikrozarządzania. I jest w stanie płacić za to, że ktoś zdejmie z jego barków nie tylko ciężar rekrutacji, ale również wdrożenia nowych członków zespołu, zarządzania nowymi ludźmi, prowadzenia rozwoju czy debugowania produktu. Tak, w tej sytuacji najlepiej sprawdza się stary dobry outsourcing programistyczny. Oczywiście pod warunkiem, że jest dobrze prowadzony.

Wyzwania

I to jest właśnie rola, w której czujemy się najlepiej. Każdy taki temat to osobne wyzwanie, z własną specyfiką. Ale łączy je to, że w każdym przypadku musimy wejść w istniejący projekt. Nie tylko na poziomie technicznym, lecz również organizacyjnym, a nawet (a może raczej "zwłaszcza") biznesowym. Cały proces składa się z kilku kroków, które można streścić następująco:

1. poznanie aktualnej sytuacji i celów biznesowych klienta,
2. zbadanie infrastruktury projektowej (repozytoria kodu, narzędzia zarządzania projektami),
3. analiza architektury systemu,
4. rozeznanie w kodach źródłowych, plikach konfiguracyjnych itd.

W tej właśnie kolejności!

Na poziomie operacyjnym wejście w projekt zwykle zaczynamy w ten sam sposób - prosimy o zdefiniowanie w miarę samodzielnego, niezależnego zadania (nowa funkcjonalność, jakiś dodatkowy moduł itp.). Mierząc się z wyznaczonym zadaniem przechodzimy kolejno przez wszystkie przedstawione wyżej kroki. Potem kolejne zadanie, i kolejne itd., aż w końcu zespół klienta przestaje postrzegać nas jako dostawcę i stajemy się pełnoprawnym partnerem. W końcu nic tak nie buduje więzi jak braterstwo broni. 😉

Dzięki temu rozwiązujemy bardzo konkretny problem. Chwilę nam zajęło, zanim uświadomiliśmy sobie, że jedną z dostarczanych przez nas wartości jest nie tylko zapewnienie wysokiej jakości programistów i zapewnienie przewidywalnego tempa prac w projekcie. Przede wszystkim zdejmujemy z klienta spory problem administracyjny, dzięki czemu zarząd może poświęcać swój cenny czas na to, co jest aktualnie najważniejsze - na rozwój biznesu. Nie martwiąc się przy tym kwestiami rekrutacji, zarządzania większym zespołem programistów, zapewnianiem jakości. Tak to już jest, że czasem trudno uświadomić sobie, co jest największą siłą własnego biznesu. 😉