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

Będąc precyzyjnym, pytanie tytułowe powinno raczej 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ę 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 dla nich łatwiejsza i tańsza droga.

I oczywiście, 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 dobrze na tym nie wyszli. W tych przypadkach przekazanie prac dostawcy bez uprzedniego przygotowania i odpowiedniego zaangażowania się we współpracę, z góry skazywało projekt na późniejsze kłopoty.

Niezależnie który z powyższych scenariuszy miał miejsce, 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ę.

Czytaj dalej, a dowiesz się:

• (Nie) wystarczy że jesteśmy zwinni
• Przygotowanie organizacji do budowy dedykowanego oprogramowania
• Ułożenie współpracy z dostawcą zewnętrznym
• Pozorne oddanie autonomii
• Kiedy zespół wewnętrzny daje więcej korzyści?
• Podsumowanie

(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 już praktycznie pogodzili się z myślą, że wymagania i tak będą się zmieniać. Dlatego wybierają podejście, które zamortyzuje ten problem —  metody zwinne. Pozwalają one planować projekt w taki sposób, aby elementy znane i najbardziej potrzebne realizowane były w pierwszej kolejności, a dopiero w kolejnych etapach uzupełniane lub zmieniane o potrzebną funkcjonalność.

[su_service title=”Ważne!” icon=”icon: comment” icon_color=”#bbe2ef” size=”36″]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ąć.[/su_service]

Przy takim podejściu umawianie się z zewnętrznym dostawcą zaczyna się komplikować. W końcu zlecający chciałby trzymać 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ę, a także 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. Poza tym, 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 zewnętrznego partnera i ponieść czasami wyższe koszty projektu niż wynikało to 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.

[su_service title=”Uwaga!” icon=”icon: exclamation-triangle” icon_color=”#bbe2ef” size=”36″]Niewłaściwy wybór zewnętrznego dostawcy może okazać się pasmem koszmarnych trudności. W końcu mamy do czynienia z „profesjonalistą”, który potrafi wykorzystać nową dla nas sytuację i trzymać nas w szachu. Co zrobić, aby uniknąć takiego zagrożenia? [/su_service]

Przygotowanie organizacji do budowy dedykowanego oprogramowania

Praktycznie każda większa organizacja w pewnym momencie dojrzewa do decyzji, aby wykorzystać swój know-how i stworzyć dedykowane rozwiązanie IT. Manager, który nigdy wcześniej 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ę w projekt oraz doświadczenia w przekładaniu oczekiwań na rozwiązanie IT. Początek potencjalnych kłopotów diagnozuję już na etapie wyboru dostawcy. Spisanie celów i wymagań (samodzielnie lub przez wynajętego konsultanta) i na tej podstawie odpytanie rynku o oferty współpracy, aby następnie dobrać wykonawcę po ocenie jego wizji rozwiązania, referencji i atrakcyjności ceny, to niestety za mało.

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

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.

[su_service title=”Ważne!” icon=”icon: bullhorn” icon_color=”#bbe2ef” size=”36″]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.[/su_service]

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, związaną z oddaniem projektu w zewnętrzne ręce, jest strach przed utratą możliwości sterowania pracami zespołu. Tylko zastanówmy się chwilę, jeśli nie wynajmujemy zespołu w modelu leasingu, a bierzemy zewnętrzny software house, którego procesy są zoptymalizowane na wytwarzanie oprogramowania, to przecież 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 programistów i całego zespołu.

[su_service title=”Ważne!” icon=”icon: comment” icon_color=”#bbe2ef” size=”36″]Jedną z obaw wielu managerów IT, związaną z oddaniem projektu w zewnętrzne ręce, jest strach przed utratą możliwości sterowania pracami zespołu.[/su_service]

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.

[su_service title=”Ważne!” icon=”icon: comment” icon_color=”#bbe2ef” size=”36″]Zbudowanie wewnętrznego zespołu 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.[/su_service]

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