Webinarium z cyklu Kultura w sieci, organizowanego przez Centrum Cyfrowe, które prowadził Krzysztof Urbański, w gruncie rzeczy opierało się na pytaniach, a odpowiedzi były gównie przykładami, czasem (często?) jak czegoś nie robić. Oczywiście zostały zaproponowane pewne narzędzia, które mogą pomóc w prowadzeniu, ale przede wszystkim w przygotowaniu strategii IT w odniesieniu do rozwiązań, które wydają nam się potrzebne (tak, bardzo często wydają się potrzebne, a wcale nie są). Cennej wiedzy dostarczały również anegdoty z projektów, z którymi ekspert miał do czynienia.
Pierwsze, o czym pomyślałem, to: czy strategia produktów IT w ogóle istnieje i czy ma rację bytu w szeroko pojętych instytucjach kultury. Co do istnienia, to często jest tak, że instytucji wydaje się, że jakiegoś rozwiązania potrzebują jej użytkownicy, a po czasie okazuje się, że jednak niekoniecznie tak było. Podobnie jest z całym cyklem życia oprogramowania, rzadko można spotkać spisaną strategię dla jakiegoś rozwiązania. Jeśli chodzi o rację bytu, to czasem niepewne finansowanie jest powodem tego, że plany odnoszą się do najbliższego okresu budżetowego, przez co nawet sensowne inicjatywy nie mogą wyjść ponad jakiś przyjęty wymiar czasowo-finansowy. Dodam od razu, że nie jest to powód do zaprzestania myślenia o budowaniu narzędzi/produktów IT, ale konieczne jest przyłożenie większej wagi do planowania oraz przemyślenia rozwiązań jako całości. I to chyba tego właśnie najczęściej nam brakuje.
Na początku wykładu wyszczególnione zostały przesłanki klęski projektu IT, pozwolę sobie je zacytować, bo przekładają się one na pytania, które powinniśmy sobie zadać myśląc o jakimkolwiek oprogramowaniu:
Nie bardzo będzie to komukolwiek potrzebne.
Zródło: https://otwartakultura.org/wiedza/warsztaty-i-szkolenia/transformator-kultury-webinaria/
Organizacja nie będzie potrzebować.
Nie będzie działać jak powinno.
Zainteresowani nie będą umieli z tego skorzystać.
Zainteresowani nie będą mogli z tego skorzystać.
Zainteresowani nie dowiedzą się, że to istnieje.
Nie będzie nas stać na zbudowanie.
Nigdy nie skończymy.
Za kilka lat nikt nie będzie wiedział, jak tego używać.
Zbudujemy i nie będzie nas stać na utrzymanie.
Pierwsze, co kojarzy się z projektami IT, to pieniądze, a raczej koszty takich przedsięwzięć. Zarobki specjalistów IT (i zapewne nie tylko specjalistów) znacznie przewyższają przeciętną płacę, nie bez powodu. Popyt na usługi osób tworzących oprogramowanie jest duży przez co również koszty pozyskania takiej „siły roboczej” są znaczne, czy to w ramach zatrudnienia, czy jako usługi firm zewnętrznych. Do tego należy dodać sprzęt lub inną formę posadowienia produktu IT, nad którym chcemy pracować. To znów duże wydatki, ale przecież każdy chce sobie kupić serwer z projektu 😉
I tu dochodzimy do rzeczy, o której często się zapomina. Mianowicie do utrzymania produktu ciężkiej pracy zespołu tworzącego dane rozwiązanie. A utrzymanie to nie tylko prąd potrzebny na działanie serwera, czy środki na jego serwis, ewentualnie koszty takiej usługi gdzieś w chmurze. To też „serwis” samego oprogramowania, naprawianie błędów (nie tylko tych krytycznych). Wreszcie, w kontekście utrzymania nie wolno zapomnieć o samym prowadzeniu czy nadzorowaniu danego produktu IT. Ktoś musi umieć, mieć czas i chęci na dodawanie nowych treści, monitorowanie działania czy rozwiązywanie problemów użytkowników, a na tego kogoś trzeba zapewnić środki. Rzecz trudna do zaplanowania, ale nie można o niej zapomnieć, a przykładów na serwisy, które powstały, bo pojawiły się dodatkowe środki zewnętrzne, a potem już zainteresowanie nimi (ze strony twórców) jest nikłe jest dość dużo w naszej cyfrowej rzeczywistości.
Druga grupa pytań, na które warto sobie odpowiedzieć, jeszcze przed przystąpieniem do realizacji, a właściwie jeszcze wcześniej – przy pracach nad założeniami projektu, dotyczy użytkowników danego rozwiązania. Czy i komu dane rozwiązanie będzie potrzebne? Czy użytkownicy będą umieli z niego korzystać? Czy do niego dotrą? Te pytania są kluczowe, zarówno w kontekście tworzenia oprogramowania dla użytkowników instytucji kultury (np. czytelników bibliotek cyfrowych), ale należy też brać pod uwagę pracowników danej instytucji, czy dane rozwiązanie pomoże im w pracy, czy będą umieli je wykorzystać. Dobrze, żeby decyzje o konieczności wytworzenia oprogramowania i jego kształcie czy funkcjonalnościach nie opierały się na przeświadczeniu, że nam się to przyda, że przyda się użytkownikom, ale najlepiej na badaniach, choćby w miarę rzetelnych 😉
Wreszcie dochodzimy do samego rozwiązania IT, naszego produktu. Tu oczywiście liczy się jakość, rozumiana bardzo różnie. Z punktu widzenia końcowego użytkownika musi być intuicyjnie, „kłania się” User Experience (UX) i dostosowanie do powszechnie stosowanych w sieci rozwiązań. Czasem niestety (pewnie nie zawsze niestety :), to, co zaimplementuje Facebook czy Google, powinno pojawić się również w serwisie dotyczącym kultury czy sztuki. O jakość samego produktu od strony użytkownika można oczywiście zadbać stosując choćby User Experience Design wspomniany na webinarium.
Natomiast jakość tzw. front-endu powinna być podparta solidnością samego oprogramowania (kodu i zaimplementowanych rozwiązań). Warto korzystać z już gotowych i w miarę powszechnie stosowanych narzędzi czy modułów zapewniających odpowiednie funkcje oprogramowania. Cały produkt IT powinien być porządnie przetestowany (również obciążeniowo), musi posiadać instrukcję, zarówno dla użytkownika końcowego, jak i obsługującego je pracownika, a także dla administratora (niezależnie czy będzie to pracownik wykonawcy, instytucji zlecającej czy firmy trzeciej). Sam produkt powinien posiadać też odpowiednią dokumentację techniczną, która może okazać się przydatna w najmniej oczekiwanych okolicznościach.
Warto pamiętać, że źle zaplanowany proces tworzenia oprogramowania może skutkować tym, że nigdy nie uda nam się go skończyć lub zanim osiągnie swoją właściwą formę już stanie się przestarzałe.
Ekspert zwrócił też uwagę, że przy planowaniu, tworzeniu i utrzymaniu jakiegoś rozwiązania z zakresu IT powinien być tak zwany product owner – osoba podejmująca ostateczne decyzje co do wszelkich kwestii związanych z produktem.
Z własnych doświadczeń z różnymi projektami związanymi z IT mogę jeszcze dopowiedzieć, że stara zasada szybko-tanio-dobrze, konwertowana do jakość-cena-czas realizacji, gdzie zawsze można wybrać tylko dwie z tych trzech opcji, sprawdza się również w przypadku oprogramowania.
Szkolenie odbyło się 29 września 2020, oczywiście online. Ale Centrum Cyfrowe na swojej stronie udostępniło zarówno zapisy wideo oraz skompensowaną wiedzę w ulotkach, do wszystkich modułów w ramach Kultury w sieci.
Na blogu możecie przeczytać relacje z innych wykładów z cyklu Kultura w sieci: Kultura w Sieci: Metodyki, etapy i narzędzia prowadzenia prac IT w instytucjach kultury; Kultura w Sieci: Dostępność narzędzi i wydarzeń online dla osób z niepełnosprawnościami; Kultura w Sieci: Jak organizować pracę pracowników instytucji kultury online”
Grzegorz Kłębek, ORZE