Dlaczego CIO nie lubią pracować z software house’ami?

27/05/2020

Będąc precyzyjnym, pytanie tytułowe raczej powinno brzmieć: „Dlaczego niektórzy CIO mają obawy przed zaangażowaniem się we współpracę z typową fabryką oprogramowania lub mają złe wspomnienia pochodzące z takich projektów?”. Kierując się tymi uprzedzeniami, decydują się tworzyć oprogramowanie we własnym zakresie – budują wewnętrzny zespół lub wynajmują programistów w modelu body leasingowym, uznając, że będzie to droga dla nich łatwiejsza i tańsza.

Nie twierdzę, że tak być nie może. Jednak moje wnioski z dziesiątek rozmów z managerami IT dużych firm pokazują, że w wielu przypadkach nie były to optymalne wybory. Zazwyczaj zabrakło spojrzenia z „zewnątrz”, które wniosłoby wiedzę i doświadczenie z podobnych projektów, unikając tym samym bolesnej nauki na własnych błędach.

Z drugiej strony rozumiem też argumenty tych CIO, którzy oddali swoje projekty w ręce software house’u i też dobrze na tym nie wyszli. W tych przypadkach, przekazanie prac dostawcy bez uprzedniego przygotowania i odpowiedniego zaangażowania się we współpracę z nim, z góry skazywało projekt na późniejsze kłopoty.

Niezależnie który z powyższych scenariuszy miał miejsce, to zazwyczaj sedno problemu leżało gdzie indziej, a model realizacji projektu software’owego mógł tylko pogłębić albo złagodzić kłopotliwą sytuację.

(Nie) wystarczy, że jesteśmy zwinni

Zauważam, że najczęstszą przyczyną problemów w projektach budowy oprogramowania jest niedocenianie złożoności wymagań lub spójności wizji tego co chcemy osiągnąć. Wszyscy się już praktycznie pogodzili z tym, że wymagania będą się zmieniać. Dlatego wybierają takie podejście, które będzie amortyzowało ten problem – a więc metody zwinne. Pozwalają one planować projekt tak, aby elementy znane i najszybciej potrzebne były robione w pierwszej kolejności, w kolejnych etapach zaś uzupełniane lub zmieniane o potrzebną funkcjonalność.

„ Zauważam, że najczęstszą przyczyną problemów w projektach budowy oprogramowania jest niedocenianie złożoności wymagań lub spójności wizji tego co chcemy osiągnąć”

Przy takim podejściu umawianie się z zewnętrznym dostawcą zaczyna się komplikować. Zlecający chciałby uzyskać kontrolę nad budżetem i sterować wydajnością zespołu. Jednakże bez precyzyjnego określenia przedmiotu zamówienia, może bazować jedynie na dość ogólnych szacunkach. Jeśli pomimo tego dojdzie do współpracy, to taki projekt kończy się konsumpcją budżetu przy mocnym niedosycie z osiągniętych rezultatów.

Z drugiej strony, własny zespół daje managerowi IT pozornie bardziej komfortową sytuację, lepszą kontrolę nad przebiegiem i wynikami projektu. Dokładnie znamy potencjał naszych ludzi, którzy lepiej rozumieją „biznes” niż zewnętrzny dostawca. Wewnętrzny zespół często jednak nie ma wystarczająco szerokiego spektrum doświadczeń procesowych, technologicznych, czy narzędziowych. W dużej mierze ukształtował się na rozwiązaniach wewnętrznych i monokulturze jednego środowiska, utrwalając zastałe praktyki.

Po zakończonym projekcie organizacja ma skłonność do „szukania” dla wewnętrznego zespołu uzasadnienia jego dalszego istnienia, argumentując je chociażby koniecznością utrzymania i modernizacji wytworzonego oprogramowania, bez weryfikacji kosztów takich prac „na rynku”.

Z zewnętrznym software housem wyzwania są inne. Już w chwili wybierania partnera trzeba mieć dosyć precyzyjnie przemyślane i przygotowane wymagania, a przynajmniej posiadać spójną wizję całości rozwiązania. Organizacja musi zaangażować się w pracę przy wypracowywaniu szczegółów systemu oraz być gotowa zaufać umiejętnościom partnera zewnętrznego i ponieść czasami wyższe koszty projektu niż by to wynikało z kalkulacji budżetu płac zespołu wewnętrznego.

Końcowy bilans może być jednak w wielu aspektach pozytywny, pod warunkiem że wybór dostawcy był właściwy. Partner mający doświadczenie w pracy z różnymi organizacjami jest w stanie „wycisnąć” więcej cennych informacji z naszej organizacji oraz wnieść własną ekspertyzę rynkową z tworzenia rozwiązań w podobnych przedsiębiorstwach. Partner zewnętrzny, jako swego rodzaju facylitator, często lepiej skomunikuje wewnętrzne działy, uspójni pojęcia i zoptymalizuje wymagania pod kątem końcowej wartości oprogramowania dla organizacji.

Pomijam oczywiste aspekty wysokiej sprawności wytwórczej typowej dla software houseów, doświadczeń technologicznych z licznych projektów, czy samego przygotowania procesu wdrożenia rozwiązania i późniejszego utrzymania systemu w ruchu. W końcowym rozliczeniu cały ten proces okazuje się dużo bardziej efektywny kosztowo i czasowo niż w przypadku budowania oprogramowania wewnętrznymi siłami.

Niestety, niewłaściwy wybór zewnętrznego dostawcy może okazać się też pasmem koszmarnych trudności. W końcu mamy do czynienia z „profesjonalistą”, który potrafi wykorzystać sytuację, która jest dla nas nowa i trzymać nas w szachu. Co zrobić aby nie doprowadzić to takiej sytuacji?

Przygotowanie organizacji do przedsięwzięcia budowy dedykowanego oprogramowania

Praktycznie każda większa organizacja w pewnym momencie rozwoju dochodzi do decyzji wykorzystania swojego know-how i stworzenia dedykowanego rozwiązania IT. Manager, który nie budował takiego oprogramowania, może nie zdawać sobie w pełni sprawy z wyzwań z jakimi będzie się mierzył. Jest to głównie kwestia gotowości całej organizacji do zaangażowania się i jej doświadczenia w przekładaniu oczekiwań na rozwiązanie.

Początek potencjalnych kłopotów diagnozuję już od etapu wyboru dostawcy. Spisanie celów i wymagań (samodzielnie lub przez wynajętego konsultanta) i na tej podstawie odpytanie rynku o oferty współpracy, by następnie dobrać wykonawcę po ocenie jego wizji rozwiązania, referencji i atrakcyjności ceny – to za mało.

Zapisanie w miarę spójnego obrazu wymagań na system informatyczny jest rzemiosłem samym w sobie. Bez doświadczenia nie warto samemu się za to zabierać. A tym bardziej, na podstawie tak przygotowanego materiału, oczekiwać rzetelnej propozycji modelu współpracy i wiarygodnej oferty cenowej. Złudnym jest też oczekiwanie, że jeśli będziemy pracować z dostawcą w modelu zwinnym, to brak dobrych wymagań nie będzie już przeszkodą. To jest tylko odłożenie problemów budżetowych i czasowych na później.

„Jedną z obaw wielu managerów IT przed oddaniem projektu w zewnętrzne ręce jest obawa przed utratą możliwości sterowania pracami zespołu.”

Kolejnym tematem jest wybór partnera przez pryzmat atrakcyjności cenowej. Mając opis oczekiwań szukamy kogoś, kto wykona je najtaniej i w rozsądnym czasie. Czyli albo wybieramy firmę o atrakcyjnych stawkach godzinowych i liczymy, że agile załatwi resztę, albo wymagamy aby dany software house oszacował cenę całości i tę kwotę jak najskuteczniej zabezpieczamy w kontrakcie. A przecież na początkowym etapie współpracy obie strony niewiele wiedzą o sobie, szczątkowo znają wzajemne potrzeby i zdolności do współpracy.

Doświadczony i odpowiedzialny software house wskaże w takiej sytuacji konieczność zrobienia kroku wstecz. Zaproponuje metodyczne podejście do pracy, potrzebę precyzyjnego określenia celu biznesowego i miar jakimi będziemy oceniać postępy. Przeprowadzi proces odkrywania poszczególnych grup wymagań, ujednolici słownictwo i pojęcia jakimi posługują się poszczególne jednostki biznesowe, co często okazuje się zaskakującym odkryciem dla samej organizacji. Następnie zaproponuje metody pracy adekwatne do danej organizacji, uwzględniając dostępność poszczególnych kluczowych osób. Zaplanuje komunikację pomiędzy potrzebnymi stronami i w końcowej fazie pomoże przeprowadzić proces zmiany w samej organizacji pracy z nowo powstałym rozwiązaniem.

Posiadanie planu projektu pozwoli na przystąpienie do ułożenia prac programistycznych, czyli uszeregowania poszczególnych grup wymagań funkcjonalnych pod kątem ich istotności biznesowej lub wynikających z zaplanowanej architektury rozwiązania. Odpowiednie dobranie i z wymiarowanie składu zespołu projektowego dla poszczególnych etapów projektu pozwoli też optymalnie zaplanować budżet przedsięwzięcia.

Samo przygotowanie projektu jest oczywiście kluczowe dla jego powodzenia, ale kolejne schody to faza realizacji, czyli praca programistów. Budowanie pierwszych wersji rozwiązania i zderzanie ich z oczekiwaniami biznesu to ważny czas wykuwania się docelowego rozwiązania. U ważność i doświadczenie w zarządzaniu oczekiwaniami interesariuszy versus możliwości czasowo-budżetowe to prawdziwa ekwilibrystyka. Powstający system staje się w rzeczy samej wypadkową podejmowanych na bieżąco decyzji i właśnie możliwości budżetowych i czasowych. Koniec końców otrzymujemy albo rozwiązanie wnoszące oczekiwaną wartość biznesową, albo rozwiązanie, które staje się od początku zmorą dla organizacji i po cichu zaczyna się planowanie jego wymiany…

Ułożenie współpracy z dostawcą zewnętrznym

Zbudowanie dobrego kontraktu z dostawcą to istotny element powodzenia projektu. Celem dobrej umowy nie jest wbrew pozorom zabezpieczenie własnych interesów na wypadek niepowodzenia, tylko partnerskie uregulowanie modelu pracy nad rozwiązaniem, przedstawieniem zasad komunikacji, procesu odbiorów, umocowania poszczególnych osób w projekcie czy też opisanie sposobów rozwiązywania sytuacji kryzysowych.

Umowa, która skupia się na restrykcjach i karach, z założenia wywołuje postawy obronne zamiast wzniecać ducha kooperacji i dążenia do zapewnienia wartościowych rezultatów projektu.

W długoterminowych umowach, szczególnie ważny jest aspekt finansowy współpracy, w tym zachęt do dostarczania wyników w ustalonym czasie, czy model indeksowania cen. Bez tego na tak konkurencyjnym rynku IT można znaleźć się w sytuacji, w której dostawca straci zainteresowanie danym projektem, gdy tylko pojawią się klienci, którzy zaczną płacić więcej. Jeśli przy realizacji kontraktu dostawca włącza nowe, mniej doświadczone osoby, to ostateczny sygnał, że trzeba porozmawiać o przyczynach tej sytuacji.

Pozorne oddanie swojej autonomii

Jedną z obaw wielu managerów IT przed oddaniem projektu w zewnętrzne ręce jest obawa przed utratą możliwości sterowania pracami zespołu. Jeśli nie wynajmujemy zespołu w modelu leasingu, a bierzemy zewnętrzny software house, którego procesy są zoptymalizowane na wytwarzanie oprogramowania, to właśnie po to, aby czerpać z tego korzyści! Tymczasem próba wpływania na pracę poszczególnych osób kończy się obniżeniem motywacji poszczególnych programistów i całego zespołu.

Jedną z obaw wielu managerów IT przed oddaniem projektu w zewnętrzne ręce jest obawa przed utratą możliwości sterowania pracami zespołu.

Nie oznacza to pozbycia się kontroli nad wydajnością pracy wynajętego zespołu. W dowolnym modelu realizacji projektu, czy to w podejściu tradycyjnym, w którym powstają produkty w konkretnych interwałach czasowych, czy w zwinnym, gdzie w każdym sprincie budowana jest wartość biznesowa, warto stosować różne metryki związane z efektywnością pracy zespołu. Na przykład, jakościowe, związane z liczbą błędów na ustaloną jednostkę czasu, czy związane z prędkością powstawania kodu, jak liczba zrealizowanych story pointów na sprint).

Dobre wyważenie pomiędzy samodzielnością zespołu i kontrolowaniem postępów stworzy w projekcie środowisko do powstawania optymalnych technologicznie oraz procesowo rozwiązań, które przełożą się na skuteczne dostarczenie wartości biznesowej, będącej ostatecznym celem każdego projektu.

Kiedy zespół wewnętrzny daje więcej korzyści?

Zbudowanie zespołu wewnętrznego jest optymalnym rozwiązaniem jeśli pracujemy nad własnym produktem (popularne wśród startupów) lub wiedza biznesowa jest tak niszowa, że włączenie do współpracy zewnętrznego partnera okupione jest dużym kosztem zapoznania się ze specyfiką biznesu. W takich przypadkach partnerzy zewnętrzni są głównie używani jako źródło konkretnych umiejętności technologicznych, które można relatywnie szybko pozyskać, nie wchodząc w długoterminowe zobowiązania pracownicze.

„Zbudowanie zespołu wewnętrznego jest optymalnym rozwiązaniem jeśli pracujemy nad własnym produktem lub wiedza biznesowa jest tak niszowa, że włączenie do współpracy zewnętrznego partnera okupione jest dużym kosztem zapoznania się ze specyfiką biznesu”

Własny zespół to też konieczność podejmowania wyzwań. Jednym z istotniejszych jest zapewnienie stałego rozwoju technicznego poszczególnym pracownikom nie tylko poprzez dostęp do szkoleń ale przede wszystkich poprzez możliwość zdobywania doświadczeń w różnych projektach, w różnych technologiach lub zespołach developerskich. To jest dosyć trudne w istniejącej monokulturze jaką tworzą działy IT. Innym aspektem jest też utrzymywanie optymalnej wydajności pracy, tak aby z czasem, codzienne rutyny czy wytarte ścieżki komunikacyjne wewnątrz firmy nie cementowały jednego modelu pracy.

Podsumowanie

W obu przypadkach pracy nad budowaniem oprogramowania dla firmy, czy to poprzez skorzystanie z zespołu wewnętrznego czy wybrania do współpracy dostawcy zewnętrznego, warto korzystać z doświadczenia poprzedników i perspektywy jaką mogą wnosić osoby spoza organizacji. Szczególnie ważne jest to wtedy, kiedy czujemy, że sprawy w toczącym się projekcie zaczynają układać się mało optymalnie. W takich momentach obiektywna ocena sytuacji, chociażby w postaci audytu może okazać się najszybszym i najtańszym sposobem wyjścia z impasu w toczącym się projekcie. Ale to już temat na kolejny artykuł.

Autor: Adam Lejman, CEO w Altkom Software & Consulting