Projektowanie Tworzenie Utrzymanie
i rozwój
Projektowanie
systemu informatycznego
Tworzenie
oprogramowania
Utrzymanie i rozwój
aplikacji biznesowych
Robert

O tym jak projektuje się złożone aplikacje biznesowe opowiada
Robert Marek – założyciel i Prezes Zarządu FINGO

Od czego zaczyna się rozmowa z nowym Klientem?

Rozmowę z nowym Klientem zaczynamy od omówienia jego potrzeb. Rozmawiamy o tym, co chce osiągnąć i na ile jego wymagania są już sprecyzowane. To ważne, ponieważ Klienci przychodzą do FINGO w różnym stadium projektu: czasami tylko z ideą, czasami z gotową dokumentacją, grafiką i szczegółowymi opisami funkcjonalności, niekiedy z rozbudowaną, formalną specyfikacją.

Na co zwracasz szczególną uwagę?

Na etapie pierwszej rozmowy staramy się zrozumieć, z jaką firmą rozmawiamy, jaki jest jej profil i jakie cele biznesowe możemy pomóc jej zrealizować. Bardzo ważne jest, aby obie strony rozumiały, jak nasze kompetencje przełożą się na sukces Klienta.

A konkretnie? Jakie pytania zadajesz na wstępnym etapie?

Pytam o cele przygotowania aplikacji - chcę zrozumieć, po co jest tworzony dany system. Bardzo pomocne jest, gdy Klient spisze wymagania i udokumentuje planowany sposób działania aplikacji. Oczywiście forma i złożoność opisu aplikacji bardzo zależy od jej rodzaju. Jeśli uznamy, że opis wymaga doprecyzowania, zadamy dalsze pytania, dzięki którym zgłębimy istotę zagadnienia.

Odpowiedź na pytanie o biznesowy cel tworzenia aplikacji jest naprawdę kluczowa. Pozwala nam to na podejmowanie właściwych decyzji co do wyboru rozwiązań funkcjonalnych i technicznych na wszystkich etapach współpracy. Drugie pytanie dotyczy funkcjonalności aplikacji – jak nasz Klient wyobraża sobie sposób, w jaki dana aplikacja ma działać.

Pytanie o cel wydaje się bardzo istotne…

Ważne jest, aby pytanie „dlaczego?” nie zostało odebrane jako kwestionowanie idei naszego Klienta. To nie jest sedno tego pytania. W FINGO zastanawiamy się „dlaczego?”, ponieważ chcemy zgłębić problem, wyzwanie i cel, który ma być zrealizowany przy wsparciu oprogramowania – to pozwala zrozumieć kolejne wybory Klienta dotyczące funkcjonalności oraz podpowiedzieć rozwiązania.

Nie zapominajmy jednak o pytaniach o sposób działania aplikacji i jej funkcjonalność. Odpowiedzi na nie dają mi wiedzę o procesach w firmie Klienta i wyobrażeniu, w jaki sposób chce zrealizować zamierzone cele. Jeśli nie mamy pewności, że to pozwoli osiągnąć cele biznesowe i mierzymy się z wyzwaniem, z którym wcześniej się nie spotkaliśmy, to często, na etapie projektowania metodą z wyboru jest postawienie hipotez i zweryfikowanie ich poprzez stworzenie prototypów rozwiązania.

Właśnie. Kiedy prototypowanie ma sens?

Prototypowanie ma sens w większości przypadków, zwłaszcza gdy podejmujemy się stworzenia złożonych aplikacji, bo pozwala to uniknąć kosztowych błędów. Zawsze warto wykonać prototyp, gdy oprogramowanie ma obsługiwać nowy proces.

Prototypy tworzy się z trzech powodów: po pierwsze, by zweryfikować poprawność założeń dotyczących funkcjonowania aplikacji jako całości; po drugie by sprawdzić, jak z aplikacji korzystają użytkownicy i wyeliminować niedoskonałości na poziomie interfejsu; po trzecie – tam, gdzie aplikacje przetwarzają duże ilości danych – by zweryfikować wydajność.

Z jakich narzędzi korzystacie, gdy tworzycie prototypy?

Wykorzystujemy narzędzia, w których można to zrobić najszybciej, ale nie ma jednego standardu dla wszystkich – wybór metody zależy od konkretnej sytuacji. Generalnie najlepiej, gdy prototyp powstaje w narzędziu, które dobrze zna prototypujący – wtedy możemy osiągnąć efekty najszybciej. Oczywiście, gdy chcemy sprawdzić wydajność, wykorzystujemy technologię docelową – tę, w której powstaje system lub aplikacja.

Zrozumienie oczekiwań i położenia Klienta ma kluczowe znaczenie w procesie projektowania aplikacji.

Posłużę się przykładem: gdy przygotowywaliśmy aplikację dla hurtowni komputerów, poszedłem na jeden dzień do pracy w tej firmie, by dobrze zrozumieć, na czym polegają zadania osób, dla których przygotowujemy system. Zrozumienie, jak wygląda proces i co jest ważne w tej pracy i które czynności zabierają najwięcej czasu, pozwoliło nam na zdecydowanie lepsze przygotowanie aplikacji, niż gdybym spędził ten dzień np. tylko na rozmowie z zespołem klienta.

Jaka jest rola firmy tworzącej oprogramowanie. Ma być doradcą, czy tylko wykonawcą?

W zależności od oczekiwań Klienta jesteśmy doradcą lub wykonawcą. Gdy wykonujemy system pod dokładną specyfikację Klienta, oczekuje się od nas roli wykonawcy. Po prostu mamy dobrze zaimplementować to, co szczegółowo określa specyfikacja. W dużej części projektów jesteśmy jednak również doradcą – nasi Klienci oczekują doświadczonego partnera do rozmowy o tym, jak ma być zaprojektowane oprogramowanie, jak ma funkcjonować i w jakiej technologii ma zostać wykonane. Po prostu chcą, żebyśmy podzielili się swoim doświadczeniem z nimi. Oczywiście chętnie to robimy.

Tworzenie oprogramowania jest drogie?

Określenie czy tworzenie oprogramowania jest drogie jest względne – drogie w stosunku do obrotów Klienta, w stosunku do ręcznego wykonywania prac, które można zautomatyzować, czy w wartościach bezwzględnych?

Myślę, że należy raczej zastanawiać się nad tym, jak optymalizować wydawanie pieniędzy na oprogramowanie. Często dobrym rozwiązaniem jest tzw. "produkt o minimalnej koniecznej funkcjonalności" – to podstawowa wersja produktu, która powinna zostać dostarczona użytkownikom. Podejście to pozwala również uruchomić aplikację bez ponoszenia nadmiernych kosztów na funkcje, które mogą okazać się mało przydatne w praktyce. Często po pierwszych tygodniach czy miesiącach użytkownicy sami wskażą nam drogę dalszego rozwoju. Jest to znacznie skuteczniejsze niż planowanie całości na wczesnym etapie tworzenia aplikacji.

Prowadzi to do wniosku, że dobre wersjonowanie jest jedną z podstaw planowania projektu informatycznego.

Wersjonowanie pozwala rozłożyć koszty w czasie i uniknąć tworzenia rozwiązań, które nie będą potrzebne.

W jaki sposób wybieracie technologie do stworzenia aplikacji?

Przy wyborze technologii bierzemy pod uwagę kilka czynników. Pierwszy to dojrzałość danej technologii. Drugi element to dopasowanie technologii do danego zadania. Oczywistym przykładem jest PHP – to technologia webowa – nie da się w niej przygotować aplikacji desktopowej.

Trzecim kryterium jest to, z jakimi urządzeniami dana technologia ma współpracować. Jeśli chcemy, by aplikacja pracowała nie tylko na komputerach wyposażonych w Windows, to nie możemy jej tworzyć w .NET, musimy wybrać technologię, która działa na wielu platformach.

Kolejnym kryterium są preferencje Klienta. Mogą one wynikać zarówno z posiadanych zasobów – np. Klient korzysta z baz danych Oracle i nie chce wykorzystywać innych baz danych, jak i np. z posiadanych kompetencji w swoim zespole.

Jest wreszcie jeszcze jedno kryterium, może nie tak bardzo oczywiste. Preferujemy te technologie, w których sami czujemy się dobrze. Wybieramy technologie przyjazne. Wtedy tworzenie aplikacji odbywa się znacznie szybciej i efektywniej.

Kiedy więc możemy uznać, że faza projektowania jest zakończona?

Projektowanie uważamy za zakończone, gdy zdefiniowane zostały wszystkie najważniejsze kwestie dotyczące tego, jak ma zostać wykonane oprogramowanie. Na rozstrzygnięcie szczegółów położenia pól na poszczególnych ekranach przyjdzie czas w trakcie tworzenia aplikacji, ale takie obszary jak cele biznesowe, wymagania funkcjonalne, interfejs użytkowników, wybór technologii, sposoby wymiany danych z innymi systemami i plan rozwoju są kluczowe i pozwalają nam na przejście do etapu realizacji.

Kontakt

FINGO sp. z o.o.
  • Plac Powstańców Śląskich 7
    53-329 Wrocław, Polska
  • godz. 8:00 – 16:00
  • NIP 8942683871
FINGO sp. z o.o. z siedzibą we Wrocławiu, Plac Powstańców Śląskich 7, 53-329 Wrocław, zarejestrowana w Sądzie Rejonowym Wrocław-Fabryczna we Wrocławiu, VI Wydział Gospodarczy Krajowego Rejestru Sądowego pod nr KRS 0000020323. NIP 8942683871, REGON 932670710. Kapitał zakładowy 50.000,00 zł w pełni opłacony.
Używamy plików cookies, aby zwiększyć wygodę użytkownika strony. Brak zmiany ustawień przeglądarki oznacza na to zgodę.
Więcej