Od software house’u do konsultingu technologicznego. Jakie umiejętności rozwijać u pracowników, aby taka transformacja była możliwa?

Jak zatem przejść od software house do konsultingu technologicznego? Po wielu rozmowach z właścicielami i menedżerami z polskich firm tworzących oprogramowanie stawiam tezę, że aby software house faktycznie stał się partnerem technologicznym dla swoich klientów nie wystarczy posiadać tylko wygadanych handlowców czy kilku „technicznych” wyjadaczy, którzy nie boją się rozmawiać z klientem. Aby przejść od software house do konsultingu technologicznego potrzeba systemowej zmiany, która dotyczy w zasadzie całego zespołu. Zmiany świadomości, nawyków i umiejętności.

Od czego zatem zacząć przejście od software house do konsultingu technologicznego? Jakie kompetencje rozwijać? Co docenią klienci szukający sparing-partnera, a nie tylko wykonawcy projektu? Nurkujemy? 🙂 

Od czego zacząć przejście od software house do konsultingu technologicznego?

Mental to podstawa. Dla mnie zmiana mentalności to nie są jakieś magiczne sztuczki motywacyjne. To plan wdrażany krok po kroku połączony z ustawiczną komunikacją: po co to robimy.

Zacząłbym od tych aspektów: 

1. Głębokie zrozumienie celów biznesowych klienta 

Zrozumienie celów biznesowych stojących za projektem technologicznym to sztuka wymagająca doświadczenia, otwartości, umiejętności słuchania oraz odkrywania potrzeb klienta. Warto wdrożyć frameworki warsztatów discovery czy product design, statusów i retro z klientem, podczas których na różnych etapach wszyscy (nawet programiści z niższym stażem) zaangażowani w projekt mają szansę wsłuchać się w perspektywę klienta (tzw. biznesu) i stopniowo włączać ich do rozmów. Brzmi jak oczywistość, ale jak obserwuję branżę software house’ów czasami takich schematów komunikacji brakuje. Albo firma przez brak systemowego podejścia do wdrażania programistów w rozmowy z klientem, ciągle żongluje tymi kilku(nastoma) najbardziej doświadczonymi osobami pomiędzy projektami. Duże ryzyko biznesowe. 🫤

2. Edukacja o wartości biznesowej technologii 

Zespoły techniczne często koncentrują się na kodzie, wydajności i architekturze. I żeby było jasne. Nic w tym złego! Jednak jak to kiedyś usłyszałem od klienta, który bardzo dobrze znał swoich amerykańskich klientów – „klient z USA oczekuje, że dostanie sparingpartnerów do rozwiązania jego problemu biznesowego, a nie osoby, którym będzie musiał tłumaczyć podstawy [jego biznesu]”. 

Aby zbliżyć zespół (nie tylko techniczny) do biznesu (klienta), warto organizować transfery wiedzy, regularne warsztaty czy szkolenia dotyczące: 

• Strategii biznesowej klientów – Jakie problemy rozwiązujemy i jak nasze rozwiązania wpływają na metryki ważne dla klientów? 

• ROI technologii – Jak klient oblicza zwrot z inwestycji w oprogramowanie? 

• Zastosowań technologii w różnych branżach – Jak AI, cloud computing czy IoT wpływają na biznes? 

3. Prezentowanie wartości 

Technologicznie polskie software house’y często należą do światowej czołówki. Problem pojawia się, gdy trzeba skutecznie zaprezentować wartość tego, co robią. Przygotowując się np. do prezentacji rozwiązania czy też demo konkretnego feature’a skupiłbym się na odpowiedzeniu na te 2 kluczowe pytania: 

• Jak zaproponowane rozwiązanie/funkcjonalność odpowiada na potrzeby klienta – na poziomach technicznym, finansowym i osobistym, czyli np. jak może ułatwić klientowi lub konkretnym udziałowcom pracę/życie? 
• Jakie korzyści biznesowe przyniesie dany sposób wdrożenia i dlaczego zaproponowany przez Was sposób ma największy sens?

4. Analiza biznesowo-systemowa zawsze żywa 

Ten punkt będzie nieco bardziej rozbudowany, bo właściwie to etap analizy biznesowo-systemowej w rozmowach z potencjalnym klientem jest tym kluczowym momentem, kiedy klient albo poczuje na własnej skórze, czy znalazł sparingpartnera do rozwiązania swojego problemu biznesowego, czy musi szukać dalej. Jednak jeden czy nawet cały zespół analityków to często za mało, by mówić o powodzeniu na rynku konsultingu technologicznego. Kompetencja ta musi być rozproszona, przynajmniej częściowo, również w zespołach deweloperskich, szczególnie, że w realnych projektach często nie ma czasu na długie pętle komunikacji.

Kilka sposobów rozwijania kompetencji analizy biznesowo-systemowej w zespole:  

„Shadowing” analityków  

Jednym z najskuteczniejszych sposobów nauki jest obserwacja – czyli „shadowing”. Słyszałem, że w pewnej firmie, analityk ma obowiązek zaprosić do każdej rozmowy z klientem jednego członka zespołu developerskiego. Podobno już po pół roku od wprowadzenia tego „rytuału” programiści nie tylko zaczęli szybciej i dokładnie rozumieć potrzeby biznesowe klienta stojące za wymaganiami, które otrzymywali od analityków, ale też byli w stanie szybciej proponować adekwatne rozwiązania. Taki „cień” więcej widzi i lepiej rozumie. W długim terminie może również odciążyć analityków choćby przez to, że będzie mniej przerzucania się pytaniami typu „co klient/analityk miał na myśli”.  

Wspólne tworzenie dokumentacji projektowej 

Jako uzupełnienie „shadowingu” warto zaangażować członków zespołu technicznego we współtworzenie backlogu z Product Ownerem, opisywanie przypadków użycia i analizę „edge cases”. Dokumentacja przestaje być wówczas tylko formalnością, a staje się narzędziem do rozmowy z biznesem. Jest to też doskonałe ćwiczenie myślenia systemowego i precyzyjnego opisywania wymagań, co ułatwi późniejszą komunikację z klientem czy QA. 

Analiza feedbacku od klientów 

Jeśli klient przekazuje feedback dotyczący logiki działania, doświadczeń użytkowników czy integracji z innymi systemami – warto zaangażować w analizę tych uwag również developerów i testerów. Dzięki temu lepiej zrozumieją wpływ decyzji technicznych na realia użytkownika końcowego, a także szybciej zareagują na zmiany. Bonus – rozwój empatii wobec klienta i pełniejsze zrozumienie realiów biznesowych. 😊

Business Case Days / Business Sprints 

Zamiast klasycznego hackathonu skupionego na kodowaniu, zorganizuj wewnętrzne wydarzenia, oparte o problemy klientów, gdzie zespoły np. analizują case’y na podstawie prawdziwych danych i opisów problemów biznesowych, projektują propozycje rozwiązań systemowych i/albo prezentują je zarządowi lub „klientowi” (np. headowi sprzedaży lub PM-owi w roli stakeholdera). Efekt? Powinny powstać ciekawe koncepcje techniczne, a dodatkowo (po raz wtóry) wzrośnie zrozumienie sposobu myślenia „biznesu”. 

Szkolenia i certyfikacje z analizy biznesowej 

Oczywista oczywistość, ale tylko dla… analityków. Może warto wiedzę z obszaru analizy zaszczepić również w developerach. Nie trzeba zaraz wysyłać każdego programisty na zaawansowane szkolenia. Na początek wystarczyłby mini warsztat od analityków dla developerów z modelowania procesów biznesowych, czy też zbierania i interpretacji wymagań. Ucząc innych najlepiej utrwalamy wiedzę, więc i analitycy skorzystają. 😉

5. Ekspertyza w architekturze systemów 

Kiedyś od CEO firmy, która ma mocną markę na rynku holenderskim usłyszałem coś w stylu: “w Polsce brakuje doświadczonych architektów, nie mają się od kogo uczyć. Nie ma systemowej edukacji w tym obszarze, bywa, że musimy zatrudniać doświadczonych ludzi w Holandii, a to wiadomo, że nam obniża rentowność projektu”.

Może taki stan rzeczy bierze się z tego, że nierzadko nowoczesny architekt musi: analizować potrzeby klienta (bo np. w projekcie brak analityka) i przekładać je na rozwiązania systemowe, myśleć o tym, jak zrealizować wymagania w kontekście istniejących systemów, infrastruktury i ograniczeń, współpracować z zespołem technicznym, zapewniając spójność rozwiązania z celami biznesowymi, czy tłumaczyć decyzje techniczne interesariuszom biznesowym. Jak widać dużo tego jak na jednego człowieka.

A dodatkowo wszystkie cechy „idealnego architekta” łączy konieczność posiadania wysokich umiejętności komunikacyjnych. Bo nowoczesny architekt systemów to nie tylko osoba, która projektuje infrastrukturę. To również łącznik między technologią a biznesem. Architekt to również ktoś, kto potrafi powiedzieć „nie” albo „zróbmy to inaczej”, bo rozumie obie strony stołu. I potrafi to zrobić z klasą. Beż pośredników w postaci menedżera projektu itp. 

6. Sprawna komunikacja jako przewaga konkurencyjna  

Wielokrotnie słyszałem, że pracownicy w rolach technicznych mają trudności z wytłumaczeniem technikaliów w sposób zrozumiały dla biznesu. Jest w tym sporo prawdy. Jednak to naturalne i da się poprawić. Co więcej, wielokrotnie podczas naszych audytów komunikacji po angielsku odkrywaliśmy, że osoby „sprzedażowe” mówiły płynnie, dużo, brzmiało to dobrze, ale słowa niekoniecznie precyzyjnie komunikowały to, o co klient pytał lub niosły inną intencję niż mówiący chciał wyrazić.  

Niezależnie od roli i mając na uwadze cel stawania się partnerem technologicznym dla klientów, warto rozwijać w pracownikach umiejętności komunikacyjne. Poniżej podzieliłem je według kolejnych faz współpracy z klientem albo jak to określamy w CoAction – według sytuacji biznesowych z klientem.  

Faza Discovery: wstępne spotkania i warsztaty 

✅ Identyfikacja stylu komunikacji interesariuszy po stronie klienta i dostosowywanie własnego stylu do m.in. preferowanego stopnia dyplomacji czy wpływów kulturowych;
✅ Precyzyjne, nienachalne zadawanie pytań, w tym pytania pogłębiające;
✅ Stosowanie technik aktywnego słuchania m.in. parafrazowanie, pytania otwarte, odnoszenie się do wcześniejszych wypowiedzi;
✅ Prezentowanie ekspertyzy firmy i zespołu w tym przedstawienie case studies adekwatnych do problemu klienta;
✅ Facylitacja warsztatów: moderowanie i stymulowanie dyskusji, utrzymywanie zaangażowania uczestników, kontrolowanie czasu, pośrednie i bezpośrednie wyrażanie opinii, mówienie o faktach, dyplomatyczne wtrącanie się, budowanie jasnych instrukcji, prowadzenie efektywnej komunikacji w grupie.

Faza prezentowania koncepcji/rozwiązania 

✅ Storytelling: opowiadanie historii produktu/systemu/koncepcji rozwoju oprogramowania – tworzenie angażujących historii, które wspierają kluczowy przekaz bez zbędnych szczegółów technicznych;
✅ Gotowość klarowanego wyjaśnienia niuansów technologicznych w odniesieniu do celów biznesowych;  
✅ Mówienie językiem korzyści biznesowych płynących z danej propozycji rozwiązania;
✅ Umiejętne porównywanie rozwiązań z wskazaniem zalet i wad, ukierunkowanie klienta na najlepsze dla niego rozwiązanie;
✅ Techniki oratorskie: wykorzystanie powtórzeń, pytań retorycznych, grupy „trójek” w celu wzmocnienia siły przekazu i poprawy zapamiętywalności przekazu;
✅ Techniki pytania klienta o feedback, umiejętność dyplomatycznego rozbijania obiekcji/wątpliwości klienta.

Faza negocjacji 

✅ Techniki skutecznego przekonywania: język argumentów i dowodów, odniesienia do faktów i danych;
✅ Techniki perswazyjne, budowanie autorytetu i wiarygodności;
✅ Rozwiązywanie konfliktów: stosowanie języka do rozwiązywania sporów, zbliżanie stron do porozumienia;
✅ Zastosowanie strategii „win-win”;
✅ Sprawne operowanie językiem umów, warunków i cen. 

Faza projektowa 

✅ Statusowanie: precyzyjne, konkretne komunikaty wskazujące na postęp i kluczowe działania w projekcie;
✅ Podsumowywanie: wyciąganie wniosków, rozwiązywanie problemów i podejmowanie decyzji w trakcie spotkań projektowych; 
✅ Argumentowanie i rozwiązywanie problemów: akceptowanie propozycji, sugerowanie, argumentacja sprzeciwu, proponowanie alternatyw, oddzielanie faktów od opinii, konstruktywna informacja zwrotna, nakierowywanie na cel, konkludowanie, formułowanie ustaleń i dalszych działań. 

Faza podsumowywania projektu

✅ Storytelling danych i faktów: przedstawianie wyników projektu w angażującej narracji;
✅ Sprawne podsumowywanie: precyzyjne komunikaty, uwypuklające kluczowe „deliverables” i ich wpływ na wskaźniki biznesowe; 
✅ Inspirowanie do działania, ustalanie dalszych kroków i follow-upów;
✅ Podziękowania za współpracę, podkreślenie osiągnięć projektu.

7. Elastyczność języka

Sam język to jeszcze nie komunikacja, ale brak języka (na odpowiednio wysokim poziomie) to przeszkoda nie do przeskoczenia. Oczywiście piszę tu o sytuacji, w której software house celuje w klientów zagranicznych, z którymi potrzebuje się komunikować po angielsku. 

Wyobraźmy sobie, że polski ekspert z angielskim na B2 (przez lata uznawanym za „good enough” w branży) ma zastosować powyżej opisane umiejętności w rozmowie z klientem z zagranicy. No nie da się! A na pewno taka komunikacja nie ułatwi zbudowania relacji z klientem. Dodatkowo może rodzić nieporozumienia albo klient po prostu nie będzie się czuć komfortowo w interakcjach z zespołem.  
 
W procesie transformowania się od software house do konsultingu technologicznego, w pełni operacyjny, zaawansowany angielski u pracowników staje się warunkiem koniecznym. Oczywiście rozwój języka można zaplanować tak, by w pierwszej kolejności biegłość uzyskali najbardziej eksponowani na klienta członkowie zespołu a w dalszej kolejności Ci mniej. Dobrym narzędziem służącym do szybkiego zorientowania się “gdzie faktycznie jesteśmy z angielskim w firmie” są audyty językowe oparte na symulacjach rzeczywistych rozmów z klientami. W CoAction badamy angielski między innymi w kontekstach opisanych w punkcie 6.  

Jak przejść od software house do konsultingu technologicznego? Podsumowanie

Przejście od software house do konsultingu technologicznego, czyli inaczej mówiąc transformacja w partnera technologicznego, to nie kwestia jednej osoby ani nawet jednego działu, ani też nie proces, który zamknie się w tygodniach czy miesiącach. Wymaga ona kompleksowej, systemowej zmiany, obejmującej cały zespół na wielu płaszczyznach. Budowanie kultury głębokiego zrozumienia celów biznesowych klientów, rozwijanie umiejętności analitycznych i wnioskowania, a także doskonalenie kompetencji komunikacyjnych to kluczowe elementy tej zmiany. Jak już powtarzali starożytni: „jedyną pewną rzeczą w życiu jest zmiana”. Stawka jest jednak wysoka – dla niektórych firm to walka o przetrwanie, dla innych – szansa na rozwój, którą w lepszych czasach trudniej było dostrzec a teraz jest ku temu doskonała okazja.