Jak zacząć pracę nad nowym systemem IT

Ważne pytanie – jak zacząć pracę nad nowym systemem IT.Przyjmijmy scenariusz – mamy burzę myśli, pomysłów, a z drugiej strony potrzeby nasze, naszej firmy lub potencjalnych klientów.

Tak zwykle zaczyna się praca nad nowym systemem IT.

Burza mózgów

Na etapie kreacji pomysłów dobrze jest je zbierać w jakimś miejscu: w notatniku fizycznym czy komputerowym, na karteczkach; a potem normalnie je spisać i uszeregować.

Gdy mamy problem, który chcemy rozwiązać nowym systemem IT, dobrym narzędziem będzie mapa myśli.

Narzędzia

  • mapa myśli

Jest wiele takich prostych aplikacji darmowych i płatnych , które w łatwy sposób pomogą nam zobrazować nasze pomysły na rozwiązanie problemu czy realizację naszych zamierzeń, marzeń, planów.

Przykład mojej mapy „Tematy na bloga”, która powstała z rok temu i sukcesywnie jest realizowana i zmieniana:

mapa mysli

Mi pomaga i wiem, że wiele osób stosuje takie narzędzia do zobrazowania swoich pomysłów.

  • 6 kapeluszy de Bono – metoda rozwiązywania problemów i szukania niestandardowych rozwiązań w grupie – tutaj krótki i treściwy opis metody

Metoda bardzo popularna i skuteczna. Pozwoliła mi kiedyś wymyślić wiele rozwiązań niestandardowych, które ulepszyły pracę pracowników i zmniejszyły konieczność kontroli o 20%. Świetnie nadaje się na różne projekty konsultingowe, gdy nie do końca posiadam wiedzę wewnętrzną firmy, a angażując pracowników firmy w tą zabawę w 6 kapeluszy, rewelacyjnie wzmacnia się ich wartość własna, bo ktoś ich słucha, bo mają coś ważnego do powiedzenia, a na koniec, bo znajdują świetne rozwiązanie.

  • fish bone – czyli diagram Ishikawa – pomaga w analizie problematycznego procesu, jego optymalizacji poprzez rozrysowanie procesu i interakcji w procesie, który sprawia problemy i nie tylko. Ta metoda jest też świetnym narzędziem analitycznym, który stosuje się też przed kodowaniem systemu IT. Obrazuje interakcje między procesami, danymi, ludźmi, etc. Więcej tutaj

Wizja systemu IT

Gdy mamy już wybrane pomysły czy zanalizowane problemy, zaczynamy pracę nad wizją systemu.  Tutaj często jest to też analiza rynku i otoczenia, bo być może jest już gotowe narzędzie. Często tak jest, lecz brakuje kilku funkcji, które są dla nas najważniejsze i wtedy zastanawiamy się nad budową własnego rozwiązania lub modyfikacją istniejącego.

To nadal jest tylko analiza, wymyślanie, sprawdzanie, czego nie ma konkurencja, a co nam by się przydało czy naszym klientom.

Ostatnio często otrzymujemy zapytania ofertowe tylko z wizją klienta na temat systemu, który potrzebuje.

Dlaczego sama wizja systemu IT to za mało dla firmy programistycznej?

  1. system IT inaczej jest budowany dla 100 użytkowników, inaczej dla 100000 użytkowników. Tutaj dam przykład rozwiązania crm – zgłosiła się do nas firma z 100 pracownikami stacjonarnymi oraz druga z 10 pracownikami, którzy pracują zdalnie po całej Polsce. Zupełnie inne wymagania, inny biznes, inne interakcje między pracownikami a klientami.
  2. system IT może być zbudowany w różnych technologiach, na różnych platformach, co wiąże się z różnymi kosztami już w trakcie programowania, jak i potem utrzymania
  3. budżet klienta jest podstawą wyboru rozwiązania. Może okazać się, że wybór gotowego rozwiązania z kilkoma doróbkami jest najlepszym rozwiązaniem w ramach budżetu. Wielu klientów chciałoby system klasy Porsche za cenę malucha. W sumie ja też:) jednak jest to niemożliwe do osiągnięcia, bo praca specjalistów, narzędzia, licencje programistyczne kosztują.
  4. oczekiwany czas realizacji – zdarza się, że klient chce zbudować system w 2-4 tygodnie. Bez przynajmniej ogólnej specyfikacji systemu nie ma możliwości ustalenia czasu realizacji.

Specyfikacja wymagań systemu IT

Idealnym rozwiązaniem jest otrzymywanie specyfikacji technicznej, projektowej takiego systemu z:

  1. wymaganiami funkcjonalnymi
  2. wymaganiami niefunkcjonalnymi
  3. opisem procesów wewnętrznych
  4. interakcjami z użytkownikami
  5. założeniami graficznymi – styl, wygląd

Dlaczego taka specyfikacja jest ważna w całym procesie ofertowym:

  1. firma programistyczna jest w stanie określić zakres prac i zasobów, jakie będzie potrzebować do realizacji zlecenia
  2. ofertę można wysłać do wielu firm i wybrać z większej grupy
  3. przy tworzeniu specyfikacji jest robiona analiza w miarę szczegółowa potrzeb firmy, klienta, jak i zmian jakie wprowadzi ten system w działanie firmy czy procesu – i nie ma niespodzianek
  4. ktoś już wcześniej zastanowił się nad użytkownikami, kto ma używać system, jaki jest przepływ pracy, dokumentów. Oczywiście szczegóły zawsze są ustalane w trakcie całego projektu IT. Chodzi o to, że użytkownicy i pracownicy firmy wiedzą czego się od nich będzie oczekiwać i dlaczego, a przynajmniej wybrani pracownicy. Jest to ważny aspekt przy wdrażaniu projektu.
  5. łatwiej jest wycenić poszczególne elementy programistyczne
  6. łatwiej dla klienta jest porównać oferty, bo ma specyfikacje i wyceny z różnych źródeł.
  7. w trakcie projektu można zawsze wracać do specyfikacji jako zakresu prac i w ten sposób rozwiązywać problemy komunikacyjne, które są nieodzowną częścią projektu IT. W trakcie budowy systemu IT mogą zmieniać się wymagania, bo zmienia się rynek, klient może dorzucać nowe funkcjonalności. Taka specyfikacja pomaga nie stracić z oczu głównego celu projektu i najważniejszych uzgodnionych funkcjonalności. Bywa, że zmiana może spowodować niewłaściwe funkcjonowanie pozostałych elementów. Każda zmiana w trakcie projektu powinna przechodzić przez proces zarządzania zmianami i akceptację ludzi, którzy projektowali ten system. To taka mała dygresja.

Wycena projektu może być zrobiona poprawnie właśnie po otrzymaniu takiej specyfikacji wymagań projektowych, wymagań systemu i firmy.

Jeśli jej nie ma  – możemy pomóc w ustaleniu i sporządzeniu takiej specyfikacji. Jest to pierwszy etap budowy systemu.

Większość firm tak działa. Najpierw analizuje i przygotowuje projekt, aby zorientować się w kosztach, technologiach, rozwiązaniach i własnych potrzebach, możliwościach.

Kilka razy mieliśmy klientów, którzy mieli świetną specyfikacje wymagań, z interakcjami, z opisem bazy danych, interfejsu, itd. Ale zapomnieli o zasobach i własnych możliwościach uczestnictwa w projekcie. Okazało się, że projekt wymaga zaangazowania kilkunastu osób z rożnych działów, a de facto przydzielone zostały 2 osoby. Od razu jest to element, który może doprowadzić do klęski projektu i samych problemów.

Pamiętajmy, że każdy projekt IT potrzebuje zasoby wewnętrzne firmy:

  • pracowników,
  • czas,
  • budżet,
  • narzędzia
  • sponsora projektu, który będzie żywo zainteresowany doprowadzeniem go do końca.

 

Jeśli potrzebujesz pomocy – skontaktuj się z nami

0 replies

Leave a Reply

Want to join the discussion?
Feel free to contribute!

Dodaj komentarz