Software development: 3 modele współpracy z naszym software housem

Software development: 3 modele współpracy

Standardowo oferujemy naszym klientom 3 modele rozpoczęcia współpracy:

1. PoC/Pilot – Proof of Concept/ Pilot Project,
2. Długoterminowe partnerstwo – Long-Term Partnership,
3. Utrzymanie i wsparcie – Maintenance & Support.

Wszystko zależy od etapu i celu projektu, a także zaufania, jakim obdarza nas firma zainteresowana współpracą. Poniżej w tekście opisujemy, komu dokładnie dedykujemy poszczególne modele, jak przebiega początek naszych prac oraz w jaki sposób budujemy zespoły developerskie i zarządzamy efektywnością ich pracy.

1. PoC/Pilot – Proof of Concept/Pilot Project

Ten model rozpoczęcia współpracy dedykujemy firmom, które jeszcze nas nie znają i obawiają się pełnego zaangażowania w rozbudowany proces tworzenia oprogramowania z nieprzetestowanym software housem.

Chcąc rozwiać obawy i sprawdzić wspólne flow projektowe, zaczynamy od małego pilotażowego projektu, który zweryfikuje nasze doświadczenie i metody pracy.

Co wyróżnia model PoC/Pilot?

• Czas trwania: 2-3 miesiące;
• Zespół: 2-4 specjalistów;
• Cel: budowa zaufania i identyfikacja ryzyk (zarówno po stronie klienta, jak i naszej);
• Brak zobowiązań: klient może zakończyć współpracę w dowolnym momencie, jeżeli nie jest zadowolony z naszych usług.

Główne cechy modelu PoC/Pilot

• Potwierdzenie koncepcji: klient i software house rozpoczynają współpracę od niewielkiego projektu dowodowego lub pilotażowego. Projekt skupia się wokół budowy konkretnej części rozwiązania lub funkcjonalności, która ma zostać przetestowana i zweryfikowana.
• Wykonalność i zgodność z oczekiwaniami: celem projektu PoC/Pilot jest zweryfikowanie czy rozwiązanie jest technicznie wykonalne i czy spełnia oczekiwania klienta. Pozwala to uniknąć potencjalnych ryzyk związanych z zaangażowaniem w rozbudowany projekt, niespełniający pokładanych w nim oczekiwań.
• Skupienie na innowacji i złożoności: model ten jest szczególnie korzystny w przypadku projektów, które są innowacyjne lub mają skomplikowaną naturę. Pozwala na eksperymentowanie i testowanie nowatorskich pomysłów bez konieczności natychmiastowego zobowiązywania się do dużego projektu.
• Decyzja o kontynuacji: po ukończeniu projektu PoC/Pilot, klient ma możliwość oceny wyników i decyzji o kontynuowaniu współpracy na większą skalę. Jest to elastyczne podejście, które pozwala na zminimalizowanie ryzyka finansowego i operacyjnego przed pełnym zaangażowaniem w projekt IT.

Model PoC/Pilot jest idealnym narzędziem do budowania zaufania między klientem a software housem oraz do oceny potencjału długoterminowej współpracy. Jest to również sposób na uniknięcie niepotrzebnych kosztów i problemów związanych z projektami, które na końcu okazują się nierentowne.

2. Długoterminowe partnerstwo – Long-Term Partnership

Ten model zakłada długoterminową współpracę między klientem a dostawcą usług z zakresu wytwarzania oprogramowania, dlatego dedykujemy go przede wszystkim firmom, które już wcześniej z nami współpracowały (także tym, które przeszły przez model PoC/Pilot i chcą kontynuować pracę nad budową rozwiązania).

Co wyróżnia ten model?

• Czas trwania: tak długo, jak jest to konieczne;
• Zespół: elastyczne podejście (zaczynamy od małego zespołu i skalujemy go w górę — w zależności od potrzeb etapu rozwoju oprogramowania, o czym piszemy poniżej);
• KPI: comiesięczna ocena wydajności (na podstawie ustalonych wskaźników KPI związanych z dostarczonymi parametrami i jakością oprogramowania);
• Kontrola budżetu: po ustaleniu zasad współpracy klient zyskuje gwarancje, że budżet nie zostanie przekroczony.

Jest to dobre rozwiązanie, kiedy klient potrzebuje stałego wsparcia w zakresie budowy i rozwoju oprogramowania. Długoterminowe partnerstwo może obejmować tworzenie dedykowanego oprogramowania od podstaw, ale także okresowe dostarczanie nowych funkcji, rozwijanie istniejących rozwiązań czy zapewnianie ciągłego wsparcia technicznego.

Zespół Scrumowy w modelach PoC/Pilot i Long-Term Partnership 

W przypadku dwóch wyżej wymienionych modeli współpracy oferujemy 3 różne podejścia do budowy zespołu IT:

• Zespół autonomiczny

Jedyną osobą po stronie klienta jest Product Owner, który odpowiada za biznesową wizję rozwiązania. Do realizacji projektu brakuje mu pozostałych członków zespołu: developerów i Scrum Mastera, analityka i testerów, którzy zaangażują się w proces wytwarzania oprogramowania. W tym podejściu dostarczamy cały autonomiczny team, który wykona analizę, zaprojektuje system, wytworzy oprogramowanie, przetestuje je, wdroży, a także będzie odpowiadał za utrzymanie.

• Dedykowany zespół

W tym podejściu dostarczamy developerów zaangażowanych w proces wytwórczy, ale to klient ma po swojej stronie osoby odpowiedzialne za analizę, nadzór i zarządzanie projektem.

Analitycy klienta produkują wymagania w postaci historyjek, które trafiają do naszego zespołu scrumowego, a następnie – w uzgodnieniu z Product Ownerem – tworzymy na ich podstawie backlog sprintu. Pracujemy zgodnie z podejściem Scrumowym, dbając o rozwój produktu w sposób iteracyjno-przyrostowy z wczesnymi i częstymi wdrożeniami.

• Zespół mieszany

Istnieje również możliwość współpracy z nami na zasadach body leasingu — dostarczamy ludzi, którzy dołączają do zespołów klienta, stając się ich integralną częścią. W tym podejściu odpowiedzialność za dostarczanie oprogramowania leży głównie po stronie klienta. Oczywiście możemy dołączyć do jego zespołów doświadczonych ekspertów, którzy pomogą poprawić wydajność i efektywność software developmentu.

Klient Enterprise – rozpoczęcie współpracy

Ponieważ duża część naszych klientów to klienci korporacyjni, wypracowaliśmy wygodną ścieżkę rozpoczęcia współpracy, którą można przedstawić w kilku krokach:

• Przywitanie (Handshake): poznajemy się, podpisujemy NDA, przeprowadzamy ocenę projektu (project assessment), składamy propozycję współpracy i podpisujemy umowę.
• Organizacja (Setup): konfigurujemy kanały komunikacyjne, określamy częstotliwość i zakres spotkań, ustawiamy VPN-y, repozytoria oraz narzędzia do raportowania. Na samym początku zakładamy obecność u klienta, aby się lepiej poznać i dobrze zrozumieć wszystkie potrzeby projektu. Następnie pracujemy zdalnie, chociaż istnieje możliwość, że ktoś z naszego zespołu (najczęściej project manger) na stałe przebywa na miejscu u klienta, aby koordynować i nadzorować pracę.
• Transfer wiedzy (Knowledge transfer): przeprowadzamy warsztaty — biznesowe, Product Discovery i techniczne.
• Scrum development: przechodzimy do fazy developmentu, pracujemy zazwyczaj w 2- lub 4-tygodniowych sprintach.
• Retrospektywa (retrospective): stawiamy na feedback, nie tylko na poziomie developmentu, ale także jeżeli chodzi o samą współpracę i efektywność zespołów. Wspólnie z klientem oceniamy, czy jest zadowolony z naszych developerów i poziomu wymiany wiedzy; dajemy swój feedback. Jest to również odpowiedni czas na zaplanowanie kolejnych celów i KPI.

Klient Enterprise – budowa zespołu

Jesteśmy przygotowani na zaangażowanie do naprawdę rozbudowanych i skomplikowanych projektów. W takiej sytuacji nasz model współpracy opiera się na zgrupowaniu zespołów w tzw. Tribe’y, w które wchodzi maksymalnie pięć zespołów developerskich (zespół składa się zazwyczaj z Tech Leadera, czterech developerów i testera).

Każdy nasz Tribe pracuje z dedykowanym Product Ownerem, a na jego czele staje Tribe Leader wyznaczony po stronie klienta.

Takich Tribe’ów możemy dostarczyć do klienta wiele, w zależności od potrzeb projektu.

Po naszej stronie leży odpowiedzialność za wszystkie zespoły — mamy Delivery Managera (z punktu widzenia klienta jest to komunikacja na zasadzie Single Point of Contact), który opowiada za przepływ pracy między zespołami i ich efektywność. Na bieżąco kontrolujemy wymianę informacji między zespołami i ich synchronizację.

Skalowanie Scruma – Nexus Team

Pracując w Scrumie, możemy naszą pracę dowolnie skalować. Wykorzystujemy do tego podejście znane szerzej jako Nexus, które definiuje sposób pracy od 3 do 9 zespołów scrumowych. Jak widać na powyższej grafice, zespoły sukcesywnie realizują przyrosty w kolejnych sprintach.

Trudność jednak kryje się w zarządzaniu zależnościami między zespołami — już na etapie historyjek musimy być w stanie wyłapywać te zależne od innych. 

Oczywiście dobrą praktyką jest rozdzielanie historyjek, aby jedna w całości trafiała do określonego zespołu i była realizowana niezależnie od pracy innych. Niestety, ale nie zawsze jest to możliwe, dlatego alternatywnym podejściem jest odpowiednie planowanie sprintów, aby historyjki zależne były realizowane w pierwszej kolejności.

Jeżeli i tutaj coś stoi nam na przeszkodzie, historyjki trafiają do kilku zespołów w tym samym czasie, które to muszą się między sobą zsynchronizować.    

Jest to bardzo ważny aspekt w zakresie efektywności developmentu, dlatego w takich przypadkach powołujemy tzw. Nexus Team — wirtualny zespół, złożony z przedstawicieli każdego z zespołu zaangażowanego w proces wytwórczy oprogramowania.

Pomimo bycia wirtualnym, funkcjonuje on w klasyczny Scrumowy sposób: ma swoje spotkania, daily, retrospektywę itp. Nexus Team dba o to, aby praca odbywała się bez przeszkód, nie dochodziło do opóźnień i zastojów między zespołami, a także o jakość wytwarzanego oprogramowania. 

3. Utrzymanie i wsparcie – Maintenance & Support

W tym modelu start i przebieg współpracy różnią się od pozostałych dwóch wyżej opisanych podejść. Przed przystąpieniem do przejęcia projektu i utrzymania systemu, najpierw musimy ustalić tzw. stan zero (czyli jakiej jakości i w jakim stanie jest przejmowane oprogramowanie).

Podchodzimy do tego w kilku krokach:

1. Pre-transfer: przygotowanie zasobów i planu działania.
2. Przejmowanie wiedzy: zapoznanie się z dokumentacją użytkownika. Ustalenie wstępnego zakresu dokumentacji technicznej i uzyskanie dostępu do repozytoriów kodu źródłowego. Przegląd kodu, opracowanie dokumentacji technicznej, uzyskanie dostępów, warsztaty techniczne i funkcjonalne.
3. Secondary support: uruchomienie i weryfikacja działania systemów w infrastrukturze Altkom Software. Weryfikacja stanu środowisk, aktualizacja dokumentacji, rozpoczęcie wspomagania obecnego dostawcy w świadczeniu usług serwisowych.
4. Primary support: weryfikacja listy błędów w systemie, ustalenie harmonogramu prac oraz zakresu naszego udziału w rozpoczętych pracach rozwojowych. Rozpoczęcie przejściowego etapu utrzymania systemu we współpracy z obecnym dostawcą, potwierdzanie przez obie strony naszej gotowości do przejęcia samodzielnej obsługi systemu w określonym umową zakresie.
5. Pełna gotowość: rozpoczęcie samodzielnego świadczenia usług na warunkach zapisanych w umowie.

Utrzymanie: Service Level Agreemen

Usługę utrzymania systemów IT świadczymy w ustalonym i dopasowanym do potrzeb klienta zakresie godzin, w ramach zdefiniowanego SLA. Utrzymanie odbywa się po podpisaniu odpowiedniej umowy serwisowej, standardowo w godzinach 8:00-16:00 w dni robocze. Zgłoszenia rejestrowane są w specjalnym systemie zgłoszeniowym, a w przypadku zgłoszeń krytycznych mailowo lub telefonicznie. Istnieje możliwość rozszerzenia usługi nawet do ciągłego wsparcia, 24/7.

Utrzymanie: Rozwój systemu

Jeżeli klient powierza nam system na utrzymanie i chce go dalej rozwijać, możemy działać w dwóch modelach współpracy:

1. Rozwój na zasadzie Time & Material 
   • Powołujemy interdyscyplinarny zespół Scrumowy o stałym składzie i pojemności wytwórczej;
   • W iteracyjny sposób (i w ścisłej współpracy z Product Ownerem) dostarczamy kolejne przyrosty;
   • Wydania zmian i rozliczenie następują w cyklach miesięcznych;
   • Koszt rozwoju liczony jest zgodnie ze stawkami MD określonymi w umowie.
2. Rozwój we współpracy z innym wykonawcą
   • Klient zgłasza nam zakres zmian;
   • Szacujemy pracochłonność zmiany w MD. W przypadku rozbieżności między naszą wyceną a wyceną klienta, w drodze negocjacji ustalana jest wspólna wartość;
   • Klient lub firma trzecia wprowadza zmianę oraz udostępnia środowisko, na którym został umieszczony kod;
   • Dokonujemy audytu kodu, zgłaszając ewentualne uwagi;
   • Warunkiem wprowadzenia kodu na środowisko produkcyjne jest poprawa błędów;
   • Koszt autoryzacji wynosi 10% kosztu zmiany.

Start współpracy

Wszystkie powyżej opisane modele współpracy i budowania zespołów są efektem naszego wieloletniego doświadczenia i udanych współprac z klientami o różnych potrzebach biznesowych. Jednakże rozumiemy, że każdy projekt, każda firma i każda potrzeba są w jakimś zakresie unikalne, dlatego standardowe modele współpracy nie zawsze są najlepszym możliwym rozwiązaniem.

Z tego względu zachęcamy naszych klientów (i osoby wstępnie zainteresowane naszymi możliwościami) do wyrażania swoich indywidualnych oczekiwań i potrzeb. Jako Altkom Software podchodzimy do współpracy elastycznie i reagujemy na indywidualne sytuacje klientów.

Dlatego, jeżeli nie widzisz modelu, który w pełni odpowiada Twoim potrzebom, daj nam znać. Jesteśmy gotowi do współpracy przy tworzeniu niestandardowych rozwiązań, które będą idealnie dopasowane do Twojego projektu.