Od czego zacząć, czyli analiza z głową

14 lipca 2013

graphics21Rusza nowy projekt! Masz analizę do przeprowadzenia. Od czego zaczynasz? Jaki masz na to sposób? Opowiedzmy sobie jak rozpocząć i jak poruszać się w analizie, żeby sprawnie doprowadzić ją do szczęśliwego zakończenia.

Od czego nie zaczynać?

To równie ważne, o ile nie ważniejsze 😉 Niestety analityk nie może być zawsze i wszędzie, a wiele interesujących uzgodnień i oczekiwań pada już na etapie sprzedaży. Trzeba wyrównać poziom wiedzy 🙂 W informacjach przekazywanych na pierwszy ogień (czasem też na pierwszych projektowych spotkaniach z klientem) zazwyczaj znajdzie się coś o (już!) dobranej technologii, planowanych rozwiązaniach technicznych, szczegółach integracji, wizji interfejsu… Hola, hola! Mimo wcześnejszych wizji projekt zaczyna się dopiero teraz.
Poczekaj chwilę z rozmowami na temat:

  • technologii
  • szczegółach technicznych
  • szczegółach integracji
  • interfejsu użytkownika

Od czego zacząć?

Wszystkie powyższe informacje są ważne, jednak mogą poczekać. Nie można być pewnym ich ostatecznego kształtu na samym początku (mogą się zmienić!), nie ma zatem sensu dogłębnie ich analizować i się przywiązywać. Od czego zacząć w takim razie? Na pewno pierwszymi punktami informacyjnymi będą: sprzedawca, dokumenty sprzedażowe, ofertowe, itp. oraz kierownik projektu (może już być bardziej wtajemniczony). Z dokumentami sprzedażowymi zapoznaj się, oczywiście, ale z przymrużeniem oka. Pamiętaj, że masz celować w potrzeby klienta, nie jego spisane życzenia. Być może przepisał sobie niedoskonałe lekarstwo na swoją chorobę. Szukaj objawów dolegliwości czy potrzeb poprawy kondycji, ale wszystkie propozycje rozwiązań filtruj przez swoją (osobistą czy zespołową) ekspertyzę.
Jeśli po wykonaniu systemu spojrzysz na szczegółowy dokument zapytania ofertowego (czy coś spełniającego tę funkcję), a potem na ten system i nie dostrzeżesz różnic, są 2 scenariusze:

  • klient ma świetnego analityka, albo sam w głębi serca nim jest (od kiedy pracuję, nie spotkałam się),
  • klient otrzymał to, co chciał, ale nie koniecznie to, czego potrzebował (Twoja analityczna porażka).

Innych nie ma.
OK, pierwszy research za Tobą. Co dalej? Kontakt z klientem. Tylko jaki? Od czego zacząć? Spokojnie, bez szaleństw, do omówienia jest cel projektu i analiza organizacji (struktura organizacyjna i odpowiedzialności, procesy). Na te pytania klient pownien znać odpowiedź z marszu 🙂 To jego firma i jego biznes. Może Ci też ułatwić zadanie, przesyłając opisy struktury organizacyjnej, dokumenty wykorzystywane w obszarze, jaki obejmie informatyzacja, specyfikacja interfejsów udostępnianych przez systemy do integracji.
Procesy pozwolą Ci zrozumieć z czym masz do czynienia, co masz wesprzeć. Struktura organizacyjna pokaże Ci jakich masz do dyspozycji ludzi, z jakimi umiejętnościami. Dokumenty określą, jakie dane muszą przepływać w organizacji. Interfejsy innych systemów przedstawią wsparcie, jakie możesz dostać z istniejących rozwiązań. Wtedy można zarysowywać rozwiązanie, np. przypadkami użycia.
Wstępne rozeznanie:

  • rozmowa ze sprzedawcami, kierownikiem projektu
  • dokumenty sprzedażowe, ofertowe, itd.
  • cel, analiza organizacji
  • pomocne: do przesłania od klienta – struktura organizacyjna, dokumenty, interfejsy systemów
  • zarys rozwiązania

Uwaga! To podejście nie gryzie się z agile! 😉 -> wpis

I co dalej?

Masz dobre podstawy. Jak działasz dalej? Dalej będziesz wgryzać się w szczegóły. W jakiej kolejności? Znasz procesy ogranizacji – wiesz, co dzieje się w jakim celu, w jakiej kolejności, z czyją pomocą i z wykorzystaniem jakich informacji. Wiesz jakie obszary będziesz informatyzować (przypadki użycia). Przydałoby się nakreślić plan tego doszczegóławiania, żeby dać znać klientowi o potrzebach jego dostępności i dostępności innych ważnych, posiadających kluczowe informacje osób (w końcu doszczegóławiamy, prezes nie wie o wszystkim w najmniejszym szczególe :)) no i dla samego siebie, jaki jest plan pracy.
graphics21Tutaj przydatnym rozwiązaniem może być diagram sieciowy znany z zarządzania projektami, w szczególności z PMBOK. Jak prościej pokazać poszczególne zadania omawiania kolenych części systemu i ich zależności? Nie wiem:) Takie rozpisanie elementów zajmie kilka minut. Co to da? Skupisz swoją uwagę na moment na tym, co jest zależne od czego i w jakiej kolejności warto to omawiać. Po co? Żeby nie robić niepotrzebnej roboty i zmieniać tego, co było ustalone, a teraz odkryte zostały nowe wymagania wynikające z powiązanych elementów. Przykład? Omawianie formularza zakładania konta przez użytkownika, zanim zbada się dane konieczne do pokazania na umowie i dane, jakie możemy wydobyć z innych systemów, a także przepisy prawne, dalsze części systemu wykorzystujące te dane, itd. jest bez sensu. Zignoruj kolejność, a będziesz go zmieniać kilka razy!
Co najlepsze, wiele osób w tym momencie narzeka na beznadziejnych klientów, bo zmieniają zdanie, zamiast wziąć odpowiedzialność za porządną analizę na siebie. Klient, jeśli nie robił takich systemów, ma prawo nie ogarniać wszystkich następstw swoich akceptacji pewnych ustaleń i nie odwalać analitycznej roboty za Ciebie. Od tego właśnie ma firmę, której powierzył swoją sprawę 🙂

Cześć, jestem Hania.

Jako strategiczny analityk biznesowy na pograniczu zarządzania i IT zapewniam, że projekty i działania w organizacji przynoszą wartość biznesową. Dostarczam kompetencji analitycznych managerom i zarządom z Polski, Niemiec i Szwajcarii przy tworzeniu strategii oraz wdrażaniu jej w kilkuset osobowej międzynarodowej organizacji.

Może zaciekawi Cię także:

www.analizait.pl by ProjectUP (C) 2020