Komunikacja z firmą wdrożeniową

Materiały do pobrania: http://goo.gl/Moln9o

Piotr Karwatka, Grupa Divante

Współpraca z firmą wdrożeniową.

Wiele projektów IT się nie udaje. Ale tak nie musi być. Komunikacja jest jednym z kluczowych elementów.


Projekt informatyczny – kluczowe momenty

- Niezależnie od wybranej metodyki i sposobu realizacji (wewnątrz, na zewnątrz) projekty informatyczne są ryzykowne

- dużo zmiennym i niewiadomych na starcie,- konieczność zaangażowania w projekt business-ownera (klienta)

i zespołu wdrożeniowego,- zmiany wymagań i zakresu prac.

Projekty zlecane na zewnątrz wymagają większego doprecyzowania (-) i są łatwiej egzekwowalne (+).

Kluczowe są następujące etapy projektu:- wybór firmy wdrożeniowej (omówione wcześniej),- analiza wymagań, projektowanie, tworzenie grafiki, specyfikacja

techniczna,- końce iteracji / etapów pracy – testy i odbiory,- etap uruchomienia,- etap utrzymania i rozwoju


Myślimy o komunikacji już od etapu umowy

Kluczowe elementy umowy:

precyzyjne określenie przedmiotu umowy - w przypadku systemów informatycznych dokładne sprecyzowanie przedmiotu umowy jest trudne i wymaga uprzedniej analizy. w przypadku wdrożenia warto załączyć do umowy projekt

funkcjonalny, który powstał na etapie analitycznym lub opis etapu analitycznego.

wyznaczenie osób kontaktowych – konieczne jest ustalenie kto może podjąć decyzję. Po stronie zarówno klienta, jak i firmy wdrożeniowej trzeba wybrać po jednej osobie koordynującej działania.

system gromadzenia wiedzy o projekcie — przechowywanie wszystkich informacji w e-mailach jest tragiczne w skutkach, jeśli do projektu dochodzi nowa osoba.. Najlepszym rozwiązaniem jest skorzystanie z systemu ticketowego i pomiaru czasu pracy. Wybór narzędzi jest ogromny — Redmine, ActiveCollab, Basecamp…

harmonogram dostarczania materiałów i akceptacji — umowa musi jasno precyzować, w jakich terminach klient i wykonawca umowy dostarczą dane materiały. Trzeba też jasno określić, jakie terminy obowiązują w przypadku oczekiwania na odpowiedź na zadane pytanie (np. brak materiałów wymaganych do przejścia dalej) oraz w przypadku oczekiwania na akceptacje prac.


Etap analityczny i projektowy

- Rozpoczęcie prac wdrożeniowych w projektach IT powinien poprzedzić etap analityczny. Powinien powstać pełen projekt aplikacji. Unikaj pokusy pomijania tego etapu (zwłaszcza przy małych projektach)!

- Podczas etapu analitycznego powinniśmy wymagać od siebie wzajemnie (firma wdrożeniowa — klient) minimum kilku spotkań lub chociaż telekonferencji. Kluczowe jest zrozumienie celu projektu po obu stronach.

- Co trzeba przeanalizować? Analiza konkurencji, sprawdzić, jak wyglądają podobne systemy, oraz przedstawić projekt interfejsu użytkownika, przygotować opis (chociażby skrócony) procesów biznesowych i działania funkcji, dokonać analizy integracji i analizy technicznej. Dobrym narzędziem prezentacji wyników analizy są makiety funkcjonalne, które wizualizują pomysł, co pozwala klientowi w łatwy sposób wyobrazić sobie proponowane rozwiązanie

- Każde spotkanie i ważne ustalenia należy podsumować pisemnie i potwierdzić. Pamięć ludzka jest niestety zawodna i ustalenia słowne mogą być szybko zapomniane. Ustalenia, które wpływają na zakres prac, koniecznie powinny być spisane i potwierdzone przez obie strony kontraktu


Testy i odbiór (koniec iteracji lub projektu)

- W trakcie niektórych etapów realizacji projektu komunikacja może zostać nieco ograniczona. E-mail lub telefon raz na tydzień powinien wystarczyć. Jeśli dobrze określiliśmy wymagania, firma wdrożeniowa będzie potrzebowała tylko czasu, aby je zrealizować.

- Harmonogram realizacji powinien zawierać odpowiednio dużo czasu na wprowadzanie poprawek.

- Warto przygotować listę scenariuszy testowych, które zostaną zweryfikowane. Powinny zawierać opis kroków, jakie trzeba wykonać w aplikacji, i uzyskanych dzięki temu efektów. Jeśli mamy gotowe opisy przypadków użycia w formie scenariuszy — to mogą one służyć jako scenariusze testowe

- Komunikacja powinna odbywać się przez system ticketowy - Dobra praktyka nakazuje, aby zgłoszenia błędów zawierały opis miejsca

występowania (np. adres URL), zrzut ekranu oraz opis kroków, które doprowadziły do jego powstania

- Zagadnienia nie powinny być od razu zamykane przez osobę, która wykonała prace. Dobrym zwyczajem jest przekazanie zgłoszenia z powrotem do osoby zgłaszającej lub do niezależnego testera (jeśli nim dysponujemy).


Uruchomienie

• Kluczowy etap projektu na którym wymagana jest maksymalna koncentracja i współpraca pomiędzy działami biznesowymi i technologicznymi.

• Analogia do startu rakiety kosmicznej – też powinniśmy kierować się checklistami, podwójnym sprawdzaniem i procedurami

• Łatwo zapomnieć o ważnych elementach? Jakich? O tym za moment…


Utrzymanie i rozwój po uruchomieniu

- Projekty informatyczne się nie kończą. Zmiany wymagań i dopasowanie do realiów rynku wymagają ciągłych zmian programistycznych.

- Cała komunikacja powinna odbywać się poprzez system kontroli zgłoszeń. W tym etapie klienci często płacą za wypracowane godziny (rozliczanie time-material) lub korzystają z pakietu godzinowego, wykupionego w ramach ryczałtu. Aby uniknąć nieprzyjemnych nieporozumień, trzeba zadbać o rzetelne rozliczanie wykorzystanych godzin oraz sprawną akceptację prac.

- Przebieg prac wygląda podobnie jak w przypadku testów — z tą różnicą, że przy zgłoszeniach rozwojowych (zapotrzebowanie na nowe funkcje) przed przypisaniem ich do osoby odpowiedzialnej za realizację szacuje się potrzebny na nią czas. Potem zgłoszenie powinno być przekazane klientowi, aby zaakceptował ten szacunek godzinowy. Klient przypisuje zgłoszenie przedstawicielowi firmy wdrożeniowej, a ten planuje konkretny termin i oddaje zadanie do realizacji. Systemy kontroli zgłoszeń umożliwiają programistom wpisywanie czasu spędzonego nad zadaniem

Kto jest w naszym teamie? Osoby które tworzyły projekt? Oprócz programistów też inne osoby? Jak wygląda rozliczenie czasu, czy godziny przechodzą? Co z gwarancją i czasami reakcji?


Dobra komunikacja to dobre narzędzia

• Wszystkie zmiany w aplikacji są wersjonowane (SVN/GIT), nowe wersje tworzone są w branchach, wersja stabilna zawsze dostępna

• Osobne środowisko developerskie, testowe, produkcyjne

• Zmiany wprowadzane tylko poprzez system ticketowy

• Transakcyjny, automatyczny deploymenynt na serwerach produkcyjych z możliwością wycofania zmian

• Automatyczne testy (checki, http, funkcjonalne) po każdym deploymencie


Dobra komunikacja to dobre narzędzia


Dziękuję za uwagę!

W razie pytań?Piotr Karwatka – [email protected]

Technology

Komunikacja z firmą wdrożeniową