Jak tworzyć projekty, które sprostają środowiskowym wyzwaniom?

„Skupienie się na technologii może skutkować tym, że dostarczamy co prawda dobrze napisane oprogramowanie, ale nikt nie chce go używać. […] Wszystko to dzieje się wtedy, kiedy za bardzo skupimy się na tym, JAK chcemy wykonywać naszą pracę, a nie CO tak naprawdę mamy zrobić”.

Z publikacji Aleksandry Kunysz, prowadzącej na co dzień szkołę testów i dbającą o to, by projekty realizowane z sukcesem, można dowiedzieć się wielu przydatnych informacji. Nie skupia się stricte na kodzie, który dla wielu byłby niezrozumiały, chociażby dlatego, że obecnie jest tak wiele języków programowania, że nie sposób znać ich wszystkich.

Przystępny język, jakim jest napisana publikacja pt. „Kierunek jakość. Jak unikać błędów w projekcie” sprawia, że można uznać ją za wyjątkowo pożyteczną. Nie będąc programistą ani z zawodu, ani z zamiłowania, nie miałam większych problemów ze zrozumieniem, o czym są poszczególne rozdziały.

Wracając jednak do głównego wątku, czyli tworzenia owocnych projektów – to, co się przydaje poza umiejętnościami, to właściwy sposób komunikacji w zespole. Bez tego elementu w zasadzie nie można stworzyć dobrej aplikacji. Na poszczególnych etapach jej tworzenia każda osoba, czy zespół odpowiedzialny za określone zadanie, ma bowiem zupełnie inne wyobrażenie o tym, jak powinna ona wyglądać.

Innym językiem posługuje się programista, innym tester, a jeszcze innym osoba z działu marketingu, czy klient, który zleca wykonanie określonego projektu. Każda z tych osób może być ekspertem w swojej dziedzinie. Jednocześnie ma nierzadko niewielkie wyobrażenie o pracy ludzi z innych branż, które są zaangażowane w realizację oprogramowania. Może zatem nieraz deprecjonować włożony trud pozostałych w to, by projekt okazał się sukcesem. 

Praca zespołowa w szerszym wymiarze

Tworzenie projektów w branży IT jest o tyle trudne, że często zdarza się, iż na pewnym etapie dochodzi do różnych błędów. Na fazie testów jest to do przyjęcia. Gorzej, jeśli gotowa aplikacja trafi już do klienta i pojawi się poważna luka w kodzie. Wtedy jest wielce prawdopodobne, że wielu jej użytkowników zrazi się do firmy, która ją oferuje lub na bazie której proponuje swoje produkty bądź usługi.

Ważne jest więc to, by zespół, który odpowiada za tworzenie projektów IT, miał na uwadze to, co jest faktycznie istotne dla klienta. Co więcej, ludzie, którzy w nim są, powinni również zwrócić uwagę na środowisko, w jakim będzie się korzystać z takiego oprogramowania. Zwykle zapomina się o tym, że będzie ono działać w zupełnie innych warunkach, niż te, właściwe dla wewnętrznych testów, jakie wykonują zespoły IT.

Innym istotnym zagadnieniem jest to, żeby rozmawiać o tym, z jakimi błędami, czy trudnymi sytuacjami można spotkać się w danym okresie. Podczas otwartej rozmowy, można często znaleźć rozwiązanie dla tego problemu. Zyskuje na tym wtedy cały zespół. Można uczyć się na swoich błędach, ale również i na tych, które popełniają inni. O ile podczas dyskusji o tym mniej przyjemnym aspekcie pracy panuje dobra atmosfera i nikt „nie bierze do siebie” sytuacji, o jakiej jest mowa.

Testy są równie ważne, jak samo tworzenie projektu. Testy powinny być tak samo dobrze i zrozumiale napisane oraz wykonane, jak oprogramowanie. Niekiedy albo nie prowadzi się testów, albo tworzy się osobno testy i program, przez co te dwa środowiska nie są ze sobą kompatybilne.

Aktualizacja starszych programów do nowych środowisk

Jesteśmy dzisiaj przyzwyczajeni do tego, że co jakiś czas aktualizujemy programy, czy systemy operacyjne do nowszych wersji. Niekiedy ludzie z branży IT, jak i klienci, którzy korzystają z takich technologii, są również przekonani, że taka procedura sprawdziłaby się w przypadku wielu programów. Czasem jednak okazuje się, że po wszystkich wprowadzonych zmianach, program przestaje spełniać swoje zadanie. Może też znacznie różnić się od pierwowzoru, do jakiego użytkownicy byli przyzwyczajeni. W konsekwencji oprogramowanie sukcesywnie traci na zainteresowaniu.

Kłopotliwe może być też zbytnie zaufanie, jakim darzy się nowe programy, które jeszcze nie zebrały żadnego feedbacku, czy recenzji. Zdarza się nieraz, że taka świeżynka może wprowadzić więcej zamieszania niż pozytywnych zmian w strukturach firmy, czy organizacji. Warto więc zwracać uwagę na to, czy są podane jakieś informacje dotyczące na przykład wydajności pracy danego systemu. Nie zawsze można to z góry obliczyć, a wtedy nie zaszkodzi spytać producenta o taki istotny szczegół. Można podać przy tym konkretne parametry oprogramowania, na jakich opiera się dane środowisko pracy.

Tworzenie oprogramowania na miarę możliwości

Terminy stoją dzisiaj przed jakością i starannością. „Jakby klient był niezadowolony, to się poprawi i będzie ok” – takie podejście funkcjonuje dość często. Presja czasu nie pomaga natomiast w tworzeniu wydajnych i bezpiecznych programów. Warto o tym pamiętać, kiedy zleca się na przykład wykonanie aplikacji, na jakiej będzie bazować cały system danej firmy. Jeśli wystąpi błąd, który nie przejdzie niezauważony przez odbiorców, może mieć to bardzo poważne konsekwencje dla dalszych losów takiej instytucji. Na pewno jej reputacja zostanie mocno nadszarpnięta po takiej spektakularnej wpadce.

Trzeba również starannie dobierać ludzi, którzy są odpowiedzialni za „cegiełki”, które składają się na cały proces tworzenia projektu. Nowi pracownicy są pełni zapału, ale nie poradzą sobie z pracą, jeśli dołączą do zespołu, gdy projekt jest już na bardzo zaawansowanym etapie. Mogą najczęściej tylko spowalniać pracę nad programem, co przekłada się na niknące zainteresowanie z zewnątrz projektem, który ma powstać. Spada również morale całego zespołu, który, bądź co bądź, także jest odpowiedzialny za to, że takiej osobie powierza się zadanie do wykonania i nie monitoruje postępu prac.

Często też marnuje się potencjał i energię nowych pracowników, których przez pierwszy tydzień pracy zarzuca się typowo biurowymi obowiązkami i formalnościami. Do tego przez ten czas osoba ta zdąży się już nasłuchać na temat tego, co w danej firmie „nie gra” i jej zapał może wyraźnie się obniżyć. 

Na etapie dobierania zespołu, można popełnić taki błąd, że szuka się osób podobnych sobie. Być może w ten sposób relacje będą się świetnie układać, ale zarazem nie będzie w zespole kogoś, kto miałby inny punkt widzenia na daną kwestię. Doświadczona autorka zaznacza, że przydają się zarówno tak zwani maruderzy, jak i osoby, które widzą pozytywne aspekty podczas tworzenia projektu. Bez krytycznego spojrzenia na to, jak się tworzy program, nierzadko nie dostrzega się m.in. pewnych niedociągnięć, czy linijek kodu, które mogłyby być znacznie krótsze i prostsze.

Zespół programistów czasem też zapomina o tym, że najczęściej testuje oprogramowanie wtedy, gdy ma dostęp do super szybkiego Internetu. Docelowi użytkownicy aplikacji nie zawsze mogą pozwolić sobie na taki luksus, na przykład będąc w podróży. Okazuje się wtedy, że programiści nie zadbali za bardzo o to, by oszczędzać zasoby pamięci, przez co w nieidealnych warunkach program bardzo traci na swojej funkcjonalności lub w ogóle przestaje działać.

W moim odczuciu publikacja ta może przydać się nie tylko osobom, które są bezpośrednio związane z tematyką i technologią IT. Znaleźć w niej można wiele cennych uwag i spostrzeżeń, dzięki którym uda się poprawić wydajność i polepszyć relacje zawodowe także w innych branżach, a nawet w życiu prywatnym.