Software house w Poznaniu - zespół i współpraca w projekcie

O powodzeniu projektu informatycznego rzadko decyduje sam kod. Częściej rozstrzyga to, czy zespół wykonawcy i zespół zamawiającego mają wspólny obraz zakresu, wiedzą, kto zatwierdza zmiany, i widzą postęp prac w tym samym czasie. Ta strona opisuje takie zasady współpracy z perspektywy firmy pracującej jako software house w Poznaniu.

Inne aspekty usługi zostały opisane osobno: zakres usług i model rozliczenia oraz stos technologiczny. Tutaj uwaga skupia się na ludziach i rytmie pracy oraz na sposobie odbioru rezultatów.

Zespół po obu stronach projektu

W projekcie uczestniczą dwie grupy. Po stronie wykonawcy pracuje zespół programistów z analitykiem, testy prowadzi tester, a koordynację ma kierownik projektu. Po stronie zamawiającego potrzebni są właściciel procesu i użytkownicy, którzy znają codzienne wyjątki od procedury. Brak którejkolwiek z tych ról najczęściej ujawnia się dopiero przy odbiorach, kiedy poprawki są najdroższe.

Rola właściciela procesu bywa niedoceniana. Jeśli w firmie nikt nie ma uprawnień do rozstrzygania sporów między działami, backlog zapełnia się sprzecznymi żądaniami, a zespół programistów czeka na decyzje. W takiej sytuacji lepiej wyznaczyć jedną osobę i dać jej mandat, niż zbierać opinie od wszystkich.

Software house w Poznaniu - zespół i współpraca od startu

Pierwszym krokiem w każdym projekcie jest zebranie wymagań od klienta. Robi się to na wywiadach, w krótkich ankietach albo na warsztatach z użytkownikami. Zespół analizuje wymagania i tworzy plan projektu, który zawiera harmonogram oraz kamienie milowe z rezultatami poszczególnych etapów. Dopiero po zatwierdzeniu planu przez klienta programiści przystępują do pracy. Podobny porządek opisuje strona o analizie przedwdrożeniowej.

Warsztat otwierający

Warsztat otwierający trwa zwykle kilka godzin i ma jeden cel: spisać proces tak, jak działa naprawdę, a nie tak, jak opisuje go instrukcja. Uczestnicy rysują przepływ dokumentów i zaznaczają miejsca, w których dane są przepisywane ręcznie. Na tej podstawie analityk przygotowuje pierwszą wersję listy wymagań i pytania otwarte, na które klient odpowiada przed wyceną.

Plan i kamienie milowe

Kamieniem milowym nazywa się punkt kontrolny z mierzalnym rezultatem, na przykład wersję testową z obiegiem zamówień. Plan nie musi zakładać, że wszystko zostanie opisane z góry. Jego rolą jest wskazanie kolejności i punktów odbioru, żeby obie strony wiedziały, kiedy zobaczą pierwszy działający fragment i kto go oceni.

Prototypy i wczesne testy

Podczas procesu rozwoju zespół tworzy prototypy i testuje oprogramowanie, aby upewnić się, że spełnia wymagania klienta. Prototyp może być szkicem ekranów bez działającej logiki albo wąskim fragmentem aplikacji z prawdziwą bazą. Pierwszy rodzaj służy do szybkiej korekty układu formularzy, drugi do sprawdzenia trudnych założeń technicznych, na przykład wydajności listy dokumentów przy dużej liczbie rekordów.

Wczesny prototyp przenosi rozmowę z poziomu opisu na poziom ekranu. Użytkownicy łatwiej wskazują braki, gdy widzą formularz, niż gdy czytają specyfikację. Szkice pokazuje się więc przed rozpoczęciem programowania, a nie po nim, bo zmiana układu na rysunku kosztuje minuty, a zmiana gotowego kodu godziny.

Iteracje i backlog

W praktyce prace prowadzi się w iteracjach, w których zespół dostarcza fragment działającej aplikacji. Podstawowym narzędziem jest backlog, czyli uporządkowana lista zadań. Każdy wpis opisuje wartość dla użytkownika, a nie sposób wykonania, dzięki czemu właściciel procesu może nim zarządzać bez wiedzy programistycznej. Ramy tego podejścia definiuje Scrum Guide, a szersze omówienie zwinnego prowadzenia projektów zawiera strona o zwinnym zarządzaniu projektami IT.

Rytm iteracji

Iteracja ma stałą długość, zwykle od jednego do czterech tygodni, i kończy się przeglądem dla zamawiającego. Na początku zespół wybiera z backlogu zadania na najbliższy okres, a na końcu pokazuje, co udało się zrobić. Stała długość ułatwia przewidywanie, ile pracy da się wykonać, bo zespół zbiera własne dane o przepustowości.

Porządkowanie backlogu

Backlog wymaga regularnej pielęgnacji: usuwania zadań nieaktualnych, dzielenia dużych wpisów i doprecyzowania tych, które trafią do najbliższej iteracji. Wpis, którego nie da się odebrać w jednej iteracji, jest po prostu za duży. Warto go podzielić tak, żeby każda część miała własny widoczny rezultat.

Reguła: do iteracji trafia tylko zadanie z kryterium akceptacji, które właściciel procesu potrafi sprawdzić bez pomocy programisty.

Odbiory etapów i kryteria akceptacji

Odbiór jest momentem, w którym rezultat przechodzi na stronę zamawiającego. Żeby nie stał się polem sporów, kryteria akceptacji zapisuje się w formie testowalnych scenariuszy. Popularny zapis opisuje stan wyjściowy oraz działanie użytkownika i oczekiwany wynik. Poniższy przykład jest ilustracyjny.

Scenariusz: Zatwierdzenie zamówienia przez uprawnioną osobę
  Zakładając, że zamówienie ma status "Nowe"
  Gdy użytkownik z rolą "Kierownik" zatwierdza zamówienie
  Wtedy status zmienia się na "Zatwierdzone"
  I w historii zapisuje się użytkownik oraz data operacji

Taki scenariusz służy dwóm celom. Dla zamawiającego jest instrukcją testu akceptacyjnego, a dla programisty definicją ukończenia zadania. Testerzy zamieniają część scenariuszy na testy automatyczne, dzięki czemu zmiany w kolejnych iteracjach nie psują funkcji odebranych wcześniej. Wersje i poziomy testów szczegółowo opisuje strona o procesie tworzenia aplikacji biznesowych.

Statusy zadań

Przejrzysta lista statusów pozwala obu stronom czytać stan prac bez pytania zespołu. Najczęściej zadanie przechodzi od wpisu w backlogu przez implementację i testy techniczne do odbioru. Każdy status ma właściciela, który decyduje o przejściu dalej.

Odbiór z uwagami

Zdarza się, że etap spełnia większość kryteriów, a drobne uwagi nie blokują dalszej pracy. Wtedy stosuje się odbiór z uwagami: protokół wymienia usterki, przypisuje im priorytety i termin poprawy, a etap uznaje się za zamknięty. Ważne, aby uwagi trafiły do backlogu jako osobne wpisy, bo w przeciwnym razie giną w treści protokołu i wracają dopiero przy rozliczeniu całego projektu. Usterki krytyczne, które uniemożliwiają pracę w procesie, wyłączają taką formę odbioru.

Komunikacja i raportowanie postępu

Regularność ma większe znaczenie niż liczba spotkań. Krótka odprawa zespołu wykonawcy służy synchronizacji, a przegląd z zamawiającym na końcu iteracji służy pokazaniu rezultatu. Między spotkaniami komunikacja toczy się w systemie zgłoszeń, gdzie każda uwaga ma numer i historię, więc ustalenia nie giną w wątkach pocztowych.

Raport postępu

Raport dla zamawiającego mieści się na jednej stronie. Pokazuje, które zadania zostały odebrane, co jest w toku i jakie ryzyka wymagają decyzji. Nie powinien zawierać wyłącznie procentu ukończenia, bo ta liczba wprowadza w błąd: ostatnie dziesięć procent pracy bywa najdłuższe. Lepszym wskaźnikiem jest liczba odebranych zadań w stosunku do planu iteracji.

Eskalacja problemów

Nie każdy problem da się rozwiązać na poziomie zespołu. Ścieżka eskalacji określa, kto i kiedy przejmuje sprawę: uczestnik zgłasza blokadę kierownikowi projektu, a ten, jeśli w ciągu jednej iteracji nie znajdzie rozwiązania, przekazuje ją właścicielowi procesu. Wcześniejsze uzgodnienie takiej ścieżki zapobiega sytuacji, w której zadanie stoi tygodniami, bo nikt nie ma uprawnień do decyzji. Kryterium eskalacji powinno być mierzalne, na przykład brak postępu przez określoną liczbę dni roboczych.

Języki i zasięg współpracy

Zespół SoftwareStudio deklaruje w opisie oferty pracę w całej Polsce i na obszarze Unii Europejskiej. Projekty prowadzi się także w języku angielskim i niemieckim, a dodatkowo po rosyjsku. Dla firmy z zagranicznymi oddziałami ma to praktyczne znaczenie, bo dokumentacja i szkolenia mogą powstać w języku użytkowników. Opis oferty wskazuje obsługę firm z Poznania i Warszawy, a także z Wrocławia, a kontakt zdalny nie wymaga obecności zespołu na miejscu.

Reguła: przy wyborze wykonawcy warto ustalić na piśmie, w jakich językach będzie prowadzona dokumentacja i szkolenia oraz komunikacja z oddziałami zagranicznymi.

Zmiany zakresu i rejestr ryzyk

Wymagania zmieniają się w czasie prac i nie jest to wada, tylko cecha projektów, w których użytkownicy dopiero po zobaczeniu ekranu zauważają braki w opisie. Kłopot pojawia się wtedy, gdy zmiany wchodzą bez oceny skutków. Prosta procedura zgłaszania zmian chroni obie strony.

• Zgłoszenie zmiany - właściciel procesu opisuje potrzebę i cel biznesowy w jednym wpisie.
• Ocena skutków - zespół wykonawcy określa wpływ na harmonogram i wycenę oraz na istniejące funkcje.

Po ocenie właściciel procesu wybiera jedną z dróg: włączenie zmiany do bieżącej iteracji kosztem innego zadania, przesunięcie jej do kolejnej albo rezygnację. Zasada zamiany zadania przy stałej pojemności zespołu jest prosta i skuteczna, bo uświadamia, że każda nowa funkcja wypycha inną.

Rejestr ryzyk projektu

Kierownik projektu prowadzi rejestr ryzyk, czyli listę zdarzeń, które mogą zaszkodzić harmonogramowi lub jakości. Każdy wpis ma sygnał ostrzegawczy i zaplanowaną reakcję, dzięki czemu zespół nie improwizuje w chwili kryzysu. Rejestr przegląda się na spotkaniach z zamawiającym, bo część ryzyk leży po jego stronie.

Rejestr decyzji bywa pomijany, choć kosztuje niewiele. Wystarczy wpis z datą i treścią ustalenia oraz z nazwiskiem osoby, która je zatwierdziła. Po kilku miesiącach pracy takie wpisy rozstrzygają spory o to, dlaczego funkcja działa w określony sposób, i oszczędzają powrotów do dyskusji zamkniętych wcześniej.

Przekazanie wiedzy i uruchomienie systemu

Zespół pracuje także nad dokumentacją kodu i oprogramowania, aby w przyszłości dało się je łatwo konserwować i aktualizować. Na przekazanie składają się opis architektury i konfiguracji środowiska oraz instrukcje dla użytkowników. Ta część pracy jest odbierana tak samo jak funkcje aplikacji. Ostatnie testy przed dostarczeniem klientowi obejmują działanie ekranów oraz odtworzenie środowiska według dokumentacji.

Rolę osób, które łączą wiedzę o produkcie z pracą u klienta, omawia strona o zespołach wdrożeniowych. Ogólniejsze spojrzenie na dostawcę usług informatycznych zawiera strona o firmie informatycznej, a doradztwo na wczesnym etapie tworzenia systemów opisano w tekście o doradzaniu przy tworzeniu systemów IT.

Szkolenia i uruchomienie u użytkowników

W opisie oferty SoftwareStudio pojawiają się także szkolenia oraz konsultacje z wsparciem technicznym. W praktyce szkolenie prowadzi się na środowisku testowym z danymi zbliżonymi do rzeczywistych, w grupach dobranych według ról w procesie. Magazynier potrzebuje innego przekazu niż kierownik, który zatwierdza dokumenty, więc jedna sesja dla wszystkich zwykle nie działa.

Uruchomienie produkcyjne poprzedza próbny import danych i lista kontrolna, na której zamawiający potwierdza gotowość użytkowników i uprawnień. W dniu startu zespół wykonawcy pozostaje w gotowości do zgłoszeń, a pierwsze tygodnie pracy traktuje się jako okres podwyższonej uwagi. Błędy zgłoszone wtedy trafiają na początek kolejki, bo dotyczą funkcji, z których użytkownicy korzystają po raz pierwszy.

Wsparcie po odbiorze

Po zakończeniu projektu SoftwareStudio oferuje wsparcie techniczne i konserwację, aby oprogramowanie działało bez zarzutu. Zasady zgłoszeń i czasów reakcji ustala się w osobnej umowie serwisowej. Dobrą praktyką jest zachowanie tego samego kanału zgłoszeń, który działał w projekcie, bo historia ustaleń pozostaje wtedy dostępna dla nowych osób w zespole.

Przykładowe rozwiązania firmy można obejrzeć w demo online, a ogólny opis usług programistycznych zawiera strona oprogramowania na zamówienie. Ścieżkę pracy nad aplikacjami dla firm z innej perspektywy przedstawia tekst o procesie tworzenia oprogramowania dla firm.