10 praktyk tworzenia oprogramowania, które musisz znać jako Klient, aby spać spokojnie

Paweł Huryn

10 praktyk tworzenia oprogramowania które musisz znać jako Klient
Maj 21, 2019 Paweł Huryn
10 praktyk tworzenia oprogramowania 2
Dla większości Klientów zamawiających oprogramowanie na zamówienie oczywiste jest, że nie wystarczy, aby dedykowana aplikacja “działała zgodnie z dokumentacją” i “przechodziła testy”. Najważniejsze, aby biznes wypalił i by zminimalizować ryzyko związane z inwestycją. Niekonieczne jest to jednak perspektywa działającego w tradycyjny sposób dostawcy, który ma tendencję do ogniskowania uwagi na technologii.
W tym artykule podzielę się moimi wieloletnimi doświadczeniami dotyczącymi relacji dostawca – Klient. Podpowiem Ci na co warto zwracać uwagę i czego unikać podczas tworzenia oprogramowania “szytego na miarę”. Zaprezentuję również zestaw dobrych praktyk, które znacząco zwiększą prawdopodobieństwo sukcesu Twojego projektu, poprawią jakość współpracy z dostawcą i pomogą zminimalizować stres.

1. Systematycznie kontroluj dostawcę

Jednym z największych błędów popełnianych przy tworzeniu oprogramowania na zamówienie jest przekazanie kompletu wymagań i pozostawienie ich implementacji w gestii dostawcy. W takim wariancie dostawca tworzy dokumentację, uzyskuje Twoją akceptację (podpis), a następnie miesiącami samodzielnie pracuje nad finalną wersją, którą przedstawia do odbioru.

Dostawca może się kierować nawet najlepszymi pobudkami, ale nie uchronią go one przed popełnianiem błędów. Dlaczego? Bardzo trudno opisać każdy możliwy przypadek już na etapie analizy wymagań, jeszcze przed rozpoczęciem pracy. Część decyzji projektowych podejmowana jest zawsze na etapie implementacji. Kolejnym problemem bywa interpretacja analizy wymagań. Zdarza się, że obie strony inaczej interpretują te same zapisy lub że nieświadomie uzupełniają luki w nich w oparciu o własne doświadczenia i oczekiwania.

Warto mieć świadomość, że jeśli po zakończeniu pracy okaże się, że kluczowe założenia projektu zostały niedostatecznie dobrze zrozumiane, wprowadzenie zmian może być bardzo kosztowne. W skrajnym przypadku może nawet okazać się, że należy zaplanować i zbudować od nowa całą architekturę.

Pamiętaj, że ciągła kontrola dostawcy to wyraz dojrzałości, a nie braku zaufania. Przydatne mogą być częste, krótkie (nawet 10-minutowe) poranne spotkania (ang. “stand up“), podczas których zespół opowie o zrealizowanych poprzedniego dnia zadaniach, przedstawi pytania i problemy oraz opowie nad czym planuje dziś pracować. Podstawą dobrze zrealizowanego projektu jest odpowiednia komunikacja i dążenie do wzajemnego zrozumienia.

2. Podziel implementację na etapy

Aby usprawnić pracę warto podzielić implementację na 2-4 tygodniowe etapy, w ramach których “od a do z” zostaną zrealizowane ustalone wcześniej scenariusze. Nawet jeśli po pierwszej lub drugiej iteracji aplikacja nie będzie finalnie gotowa, warto angażować się w jej testy i jak najszybciej zgłaszać dostawcy wszystkie zastrzeżenia i uwagi.

Jeśli masz pytania lub nie rozumiesz przedstawionej przez IT koncepcji, nie bój się pytać dopóki nie uzyskasz wszystkich odpowiedzi. Pamiętaj, że dostawca w rozmowie z Tobą nie powinien używać terminów technicznych. Jeśli nie odpowiada na Twoje pytania językiem, który zrozumiesz, istnieje spore ryzyko, że dostawca niewystarczająco dobrze zrozumiał Twoją perspektywę.

Dzieląc implementację na etapy znacznie ograniczysz ryzyko niezrozumienia wymagań i zwiększysz szansę, że finalny produkt będzie lepiej dostosowany do Twoich potrzeb.

3. Unikaj myślenia w kategoriach CRUD

Masz prawo wymagać, aby każdy etap projektu wnosił konkretną wartość biznesową. Nie daj się przekonać, że firma IT “pracuje nad fundamentami”, “aktualnie nie jest w stanie nic pokazać”, albo że interfejsem użytkownika zajmie się “na końcu”.

Specjaliści IT często myślą kategoriami klas, interfejsów, wzorców czy warstw. Skupiają się na operacjach tworzenia, odczytu, aktualizacji i usuwania obiektów (ang. “CRUD”). Tymczasem same operacje CRUD nie wnoszą najczęściej żadnej wartości. Analogiczne operacje można przecież wykonać np. w Excelu.

Jako Klient masz prawo wymagać, aby każdy etap kończył się dostarczeniem konkretnych scenariuszy korzystania z aplikacji. Przykładem dla sklepu internetowego może być zalogowanie się przez Klienta do portalu, wyświetlenie listy produktów z wybranej kategorii i dodanie produktu do koszyka. Przydatne może być tu tzw. “event storming”, czyli sposób modelowania domeny w oparciu o zdarzenia (szczegóły znajdziesz w artykule pt. An introduction to event storming: The easy way to achieve domain-driven design).

Oczywiście po pierwszym etapie lista produktów może być “zakodowana na sztywno” i może nie udać się sfinalizować zamówienia. Na pewnym etapie prac to normalne. Zyskasz jednak pewność, że projekt zmierza w dobrym kierunku i odpowiada oczekiwaniom lub będziesz mógł odpowiednio wcześnie wprowadzić poprawki.

4. Pracuj makietami, dbaj o UX

Nawet najlepiej opisany system może nie trafić w oczekiwania i potrzeby użytkowników końcowych. Dodatkowo, jako Klient wcale nie musisz zostawać ekspertem w zakresie opisów procesów biznesowych (notacji BPMN), diagramów klas, przypadków użycia czy weryfikowania zależności pomiędzy wymaganiami.

Pamiętaj, że obraz mówi więcej niż tysiąc słów. Niezależnie jak dobrze opiszemy wymagania, bardzo trudno zweryfikować opis bez ekranów, najlepiej takich, które można przeklikać i zaprezentować użytkownikom. Nie oznacza to, że należy wykonać pełną implementację. Wystarczy wykorzystać lekkie narzędzia z obszaru szkicowania (ang. “wireframing”) czy szybkiego prototypowania (ang. “rapid prototyping”) interfejsu.

W mojej ocenie najlepiej sprawdzają się krótkie cykle budowania interaktywnych makiet, weryfikacji z użytkownikami i uwzględniania poprawek aż do skutku. Zazwyczaj po kilku iteracjach uzyskujemy wysokiej jakości produkt końcowy.

Szczególnie polecam wykorzystanie narzędzi takich jak:

  • Balsamiq – szkicowanie ekranów / wirefrming,
  • Mockplus – szybkie prototypowanie,
  • FluidUI – szybkie prototypowanie,
  • InVision – wygodne udostępnianie prototypów, mniej interaktywne.

Sama technika prowadzenia warsztatów UX to temat na osobny artykuł.

5. Stosuj RWD, rozważ mobile first

We­dług ra­por­tu Pol­ska.​Jest.​Mobi 2018 firmy Mobee Dick, aż 48% Polaków deklaruje, że korzysta z mobilnych urządzeń ponad 2 godziny dziennie, podczas gdy w roku 2016 było to 1,8 godziny. Dlatego projektując interfejs trzeba koniecznie pamiętać o telefonach i tabletach.

Wiele zmieniła w tym zakresie popularyzacja podejścia RWD (ang. “Responsive Web Design”), czyli takiego projektowania aplikacji, aby dostosowały się do urządzeń mobilnych.

Mobile first to pójście o krok dalej i rozpoczęcie od projektu interfejsu mobilnego, a dopiero w dalszej kolejności projektowanie interfejsu desktopowego. Takie podejście wprowadza spore ograniczenia, co w efekcie wymusza upraszczanie interfejsu, minimalizację wymagań i skupienie się na UX. A przecież nie o to chodzi. Oczywiście nic nie stoi na przeszkodzie, aby wersja desktop oferowała pewne dodatkowe udogodnienia i funkcjonalności, warto powiązać to z priorytetowymi wymaganiami.

Zalecam stosować podejście mobile first wszędzie tam, gdzie konwersja ze strony desktopowej na mobilną może nie być oczywista. Na przykład w jaki sposób wyświetlić na urządzeniu mobilnym tabelę z 10 kolumnami? Pozostawić jedynie pierwszą kolumnę? A może każdą komórkę wyświetlić w osobnym wierszu? W takim przypadku prościej najpierw zaprojektować rozwiązanie mobilne, a dopiero w dalszej kolejności zastanowić się jakie dodatkowe opcje (np. filtrowanie, sortowanie, grupowanie) może oferować rozwiązanie desktop.

6. Jak najszybciej uruchom wersję MVP

Bardzo dobrą praktyką jest szybkie wdrażanie minimalnej aplikacji gotowej do wprowadzenia na rynek, czyli MVP (ang. “Minimum Viable Product”). To trochę jak wypożyczenie na kilka dni samochodu, który zamierzamy kupić, jednak bez ponoszenia pełnych kosztów inwestycji.

Wersja MVP jest z definicji gotowa do zaprezentowania Klientom i weryfikacji “czy będą kupować”. W zależności od branży i pomysłu może to oznaczać coś innego. W niektórych przypadkach będzie to implementacja podstawowych scenariuszy użycia, w innych rozwiązaniem może być fałszywa witryna (ang. “fake door”), np. odpalenie sklepu internetowego bez podpisywania umów z dostawcami. Zamiast od razu inwestować w pełną automatyzację sprzedaży, przez pewien czas wystarczy realizować zamówienia ręcznie, kupując towar w sklepie lub umożliwiając wcześniejszy zakup w formie “pre-order”.

7. Zastanów się, co naprawdę ważne

Szczególnie w kontekście MVP utrzymywanie, że wszystkie wymagania mają najwyższy priorytet to prosta droga do porażki.

Weźmy przykład sklepu internetowego. Czy naprawdę automatyczna obsługa reklamacji jest tak samo ważna, jak umożliwienie zakupu? A może jesteśmy w stanie przez pierwszy miesiąc realizować reklamacje poza systemem, a w zamian za to wcześniej ruszyć ze sprzedażą?

Warto uświadomić sobie, że jeśli wszystko jest ważne, to w praktyce wszystko staje się mało istotne, a przez to termin oddania gotowego do użytku projektu odsuwa się w czasie.

8. Stosuj “Zasadę Pareto” i radykalnie upraszczaj wymagania (KISS)

Zgodnie z “Zasadą Pareto”, 80% rezultatów osiągamy wkładając 20% wysiłku. Przy tworzeniu oprogramowania można nawet zaryzykować proporcję 90:10. Dlatego poświęć chwilę, aby zidentyfikować kluczowe funkcje, które można prosto dostarczyć. Bardzo możliwe, że po uruchomieniu produkcyjnym w ogóle nie wykorzystasz wielu z zaplanowanych opcji, zidentyfikujesz za to zupełnie nowe potrzeby.

Przykładowo: czy naprawdę potrzebujesz interfejsu do zarządzania cenami produktów bezpośrednio z poziomu przeglądarki na urządzeniu mobilnym? A może wystarczy zwykły import Excel z poziomu aplikacji desktopowej? To zweryfikuje praktyka dnia codziennego.

Pamiętaj, że zbyt restrykcyjne projektowanie aplikacji (np. nadmiar reguł biznesowych, nadmierna komplikacja algorytmów) utrudni jej późniejsze utrzymanie i dostosowanie do nowych potrzeb. Każde nowe wymaganie to kolejny “przypadek testowy”, który będziesz musiał weryfikować przy kolejnych wdrożeniach.

Zamiast tego postaraj się radykalnie uprościć wymagania, zgodnie z regułą KISS (ang. “Keep It Simple, Stupid”).

9. Zadbaj o architekturę klasy Enterprise

Aplikacje klasy Enterprise to w skrócie profesjonalnie przygotowane i wysokiej jakości rozwiązania. Adresują one potrzeby takie jak:

  • Skalowalność (np. dziesięciokrotne zwiększenie liczby użytkowników),
  • Bezpieczeństwo (np. zgodność z OWASP),
  • Zgodność z obowiązującymi regulacjami prawnymi (np. 5 RODO, Rozliczalność),
  • Odpowiednie zaprojektowanie domeny biznesowej (tematy takie jak “domain driven design” czy “event storming“),
  • Podział aplikacji na niezależne komponenty (“microservices”),
  • Transakcyjność,
  • Wydajność.

Każdy z tych obszarów tworzy tak zwane “wymaganie niefunkcjonalne”. Warto wymagać od dostawcy, aby jeszcze przed rozpoczęciem implementacji pomógł Ci przygotować listę takich wymagań wraz z korespondującymi z nimi założeniami. Do ich weryfikacji najlepiej wykorzystać niezależnego eksperta IT.

10. Podziel się ryzykiem z Dostawcą

Podziel się ryzykiem z dostawcą. To dostawca ma wiedzę i doświadczenie umożliwiające określenie harmonogramu i pracochłonności dla założeń, które podasz. Nie daj się przekonać, że projekt innowacyjnego oprogramowania będzie realizowany “zwinnie w formule time & material”. Time & material to w praktyce płacenie za prace, nie za ich efekty (zob. artykuł pt. Agile 2.0, czyli współpraca zdefiniowana na nowo). Przy takim sposobie rozliczeń ryzykuje tylko Klient.

Zwinna realizacja powinna oznaczać pracę w krótkich iteracjach, do których wybieramy konkretne funkcjonalności z kolejki (ang. “backlog”). Dopóki zakres nie odbiega od ustalonego po analizie wymagań, nie ma uzasadnienia dla ponoszenia przez Klienta dodatkowych kosztów, a dostawca powinien wywiązywać się deklarowanego z terminu.

Podsumowanie

Nie sposób streścić w krótkim artykule wszystkich niuansów, które mogą wpłynąć na końcowy sukces Twojego projektu. Jestem jednak przekonany, że wdrożenie 10 wymienionych powyżej praktyk znacząco zwiększy prawdopodobieństwo odniesienia sukcesu, umożliwi uniknięcie wielu często popełnianych błędów i pozwoli spać spokojniej.

W przyszłości opiszę między innymi na jakie zapisy w umowach powinien uważać Klient i w jaki sposób prowadzić analizę wymagań, dlatego zachęcam Cię do obserwowania bloga i profilu LinkedIn firmy APN Promise.

Zapraszam do kontaktu

Masz pytania dotyczące artykułu? Chcesz umówić się na rozmowę? A może zainteresowała Cię nasza oferta oprogramowania na zamówienie? Zapraszam do kontaktu.

Polecane zasoby

  1. Dawid Lewandowicz (2018). Daily (Scrum, standup) – codzienne spotkanie zespołu deweloperskiego [agilestarter].
  2. International Design Founddation (2019). Rapid Prototyping, Faking It Until You Make it in a UX Driven World.
  3. Connor Hood (2016). Mobile First Design: Why It is Great and Why It Suck.
  4. jestem.mobi (2018). Raport POLSKA.JEST.MOBI 2018.
  5. Biznesowe Rewolucje. MVP – minimum viable product praktycznie. Od czego zacząć biznes?
  6. GOGO.Developer (2015). Aplikacje klasy „Enterprise” – czym tak naprawdę są?.
  7. OWASP™ Foundation. The Open Web Application Security Project (OWASP).
  8. Paweł Huryn (2018). Rozliczalność – czyli o nowej filozofii w ochronie danych osobowych.
  9. Andrew Powell-Morse (2017). Domain-Driven Design – What is it and how do you use it?
  10. Steven A. Lowe. An introduction to event storming: The easy way to achieve domain-driven design.
  11. Paweł Huryn (2019). Agile 2.0, czyli współpraca zdefiniowana na nowo.

Podziel się

Autor: Paweł Huryn

Paweł Huryn

Paweł Huryn

Ostatnie artykuły autora

10 praktyk tworzenia oprogramowania które musisz znać jako Klient

10 praktyk tworzenia oprogramowania które musisz znać jako Klient

Paweł Huryn, bazując na swoim wieloletnim doświadczeniu podpowiada na co warto zwracać uwagę i czego unikać w procesie tworzenia oprogramowania “szytego na miarę”. Przedstawia także zestaw dobrych praktyk, które znacząco zwiększą prawdopodobieństwo sukcesu Twojego projektu i poprawią jakość współpracy z dostawcą.

Agile 2.0, czyli współpraca zdefiniowana na nowo

Agile 2.0, czyli współpraca zdefiniowana na nowo

Według badania Project Management Institute z 2018 roku, metodyki zwinne lub hybrydowe stosuje ponad 46% organizacji. Czy tradycyjne podejście Agile wystarczy? Paweł Huryn wyjaśnia, dlaczego my preferujemy ulepszone podejście Agile 2.0.

Skontaktuj się z autorem

 

Administratorem danych gromadzonych z wykorzystaniem formularza jest A.P.N. Promise S.A. Podane przez Ciebie dane będą przetwarzane w zakresie niezbędnym do podjęcia kontaktu lub realizacji określonego żądania zgodnie z art. 6 ust. 1 lit. b RODO przez okres niezbędny dla realizacji Twojego zgłoszenia. Wszelkie informacje w zakresie przetwarzania podanych przez Ciebie w formularzu danych oraz posiadanych uprawnieniach znajdziesz w Polityce prywatności. Kliknij i dowiedz się więcej jeżeli informacje podane powyżej nie są dostatecznie jasne!