wtorek, 13 marzec 2018 09:05

Jak producenci psują swoje oprogramowanie?


Na rynku w tym momencie mamy do wyboru ogromną liczbę dostawców oprogramowania CRM. Proces tworzenia tego oprogramowania u każdego producenta wygląda podobnie i jest w dużej mierze zależny od rzeczywistych możliwości firmy, zarówno technicznych, jak i personalnych. Zakładam, że w tym miejscu każdy producent chciałby napisać, jak doskonały produkt stworzył i jak wiele testów to oprogramowanie przeszło. Niestety, w większości przypadków nie wygląda to zawsze tak kolorowo, jak byśmy tego chcieli. 
Tutaj mógłbym zacząć od wymieniania liderów branży IT takich jak: Microsoft, Google, czy Facebook, którzy mają opracowane szczegółowe, wielostronicowe dokumenty opisujące wszelkie zmiany, wdrożenie itd., od  A do Z nie pomijając żadnego szczegółu. Jednak dzisiaj skupię się na branży, którą znam najlepiej, czyli open source CRM.



Jeden plik, którym możemy prosto zaktualizować cały system CRM

Wyobraźmy sobie typową sytuację, kiedy system CRM, z którego korzystamy na co dzień daje nam znać, że oprogramowanie jest przestarzałe i wymaga pobrania aktualizacji. Najczęściej wygląda to tak, że  otrzymujemy gotowy plik, który wymaga od nas jedynie zainstalowania. Po wykonaniu tych kilku czynności, możemy znów cieszyć się bezpiecznym i aktualnym systemem. 

 

Moim zdaniem najlepszą praktyką jest sytuacja, kiedy użytkownik końcowy dostaje od producenta łatwy w obsłudze, prosty mechanizm aktualizacji. Wtedy cały proces trwa krótką chwilę, jest sprawny i użytkownik potrafi przede wszystkim wykonać całą tę sekwencję sam. W przeciwnym wypadku dostawca będzie borykał się z setką zgłoszeń pod tytułem: "jak zaktualizować system CRM do nowej wersji?!".

A czy można prościej?

Oczywiście, że tak. Jeszcze prostszą metodą jest aktualizacja automatyczna. W takiej sytuacji użytkownik nie musi pobierać i instalować niczego ręcznie, ponieważ wszystko odbywa się bez jego interwencji.  Co prawda, jeszcze kilka lat temu w przypadku zespołu YetiForce (wówczas 8-osobowego) nie było to najlepsze rozwiązanie, ponieważ:

  • Nasze doświadczenie było jeszcze zbyt ubogie, by móc wprowadzić tę metodę;
  • Nie mieliśmy pewności, czy automatyczna aktualizacja naszego CRM-u jest bezpieczna i czy będziemy w stanie sami ją zabezpieczyć.

Do dzisiaj wszystko wskazuje na to, że rezygnacja z automatycznych rozwiązań w YetiForce CRM ostatecznie była słuszną decyzją.

Proces przygotowania paczki aktualizacyjnej

Od strony producenta, samo przygotowanie aktualizacji jest dość skomplikowane i często trwa tygodniami lub nawet miesiącami - w zależności od cyklu wydawniczego.

Liczba zmian i jakość aktualizacji

Oczywiście liczba i wielkość zmian w systemie determinuje, czy proces ten okaże się być prosty, czy trudny. Im więcej zmian wprowadzimy, tym ciężej będzie nam utrzymać paczkę aktualizacyjną w stanie bezawaryjnym.

Wersje testowe

Tutaj obowiązuje prosta zasada:


Im więcej wersji testowych przed wersją końcową,
tym lepiej - dla jakości kodu i dla nas samych.


Kilka lat temu, jeszcze w początkowych wersjach YetiForce CRM, najczęściej publikowaliśmy jedną wersję testową przed oficjalną wersją finalną. Z kolei w przypadku wersji 4.3 wydaliśmy aż 9 wersji testowych, a dodatkowo system można było na bieżąco testować online.


Naprawianie błędów

Błędy muszą być łatane! Każdy użytkownik, który widzi, że zgłoszony przez niego błąd w danym oprogramowaniu nie został naprawiony, zastanowi się dwa razy zanim zgłosi kolejny, nie wspominając już o nadużytym przez producenta zaufaniu użytkownika.

Z każdym kolejnym wydaniem YetiForce CRM dokładamy największych starań, aby likwidować wszystkie zgłaszane nam przez społeczność błędy, ponieważ jest to jedyna słuszna droga do wydania dobrego oprogramowania. Niestety, wielu producentów wydaje kolejne wersje systemu [w tym również LTS] mimo, że wiele błędów jest nadal nienaprawionych!

YetiForce potrzebował około 2 lat, aby usprawnić cały proces zamykania błędów jeszcze przed publikacją nowej wersji.

Unikanie błędów

Kluczem do unikania powstawania błędów jest pisanie dobrych testów jednostkowych zarówno na warstwie systemu, jak i użytkownika. Idealna sytuacja to taka, w której mamy 100% pokrycia systemu testami jednostkowymi. W przypadku systemów CRM (również zamkniętych) jest to niewielki odsetek.

Podsumowanie

O tym, jak powinna zostać poprawnie przeprowadzona aktualizacja systemu mogę pisać godzinami. Podobnie zresztą każdy inny producent oprogramowania, ale ilu z nas faktycznie wciela w życie (albo w kod) swoje własne rady?  Każdy producent dojrzewa do standardów w swoim tempie i nie mnie to oceniać, a Wam, użytkownikom.

Należy jedynie pamiętać, że


każda niskiej jakości paczka aktualizacyjna najbardziej odbija się
na samym producencie,


ponieważ odbija się na wizerunku jego i produktu, który oferuje.

Przeczytano 253 razy