
W ramach cyklu warsztatowego Transformacja cyfrowa w instytucjach kultury wspieramy pracowników instytucji GLAM (galerie, biblioteki, archiwa, muzea) w efektywnym korzystaniu z możliwości oferowanych przez technologie, by angażować zróżnicowane grupy odbiorców w korzystanie z cyfrowych zasobów dziedzictwa.
Z terminem Transformacja cyfrowa wiążą się konkretne praktyki wspierania pracy projektowej i realizacji wdrożeń narzędzi cyfrowych. Wdrożenie ich pozwala uniknąć instytucji najpoważniejszego błędu związanego z realizacją projektów IT – stworzenia produktu, który nie ma odbiorcy. Po każdym warsztacie w cyklu publikować będziemy wpis z katalogiem dobrych praktyk w danym zakresie tematycznym.
Wśród tych praktyk możemy wymienić:
- zarządzanie projektami IT w sposób zwinny i prace w trybie “prototypuj, testuj, ulepszaj”;
- projektowanie zorientowane na użytkownika;
- tworzenie interdyscyplinarnych zespołów i dbanie o jakość komunikacji;
- transparentność procesu wdrożeniowego;
- dbanie o ekologię praktyk instytucjonalnych.
Wszystkie elementy tego katalogu są równie ważne i są ze sobą ściśle powiązane. Poniżej prezentujemy ich ogólną charakterystykę.
Zarządzanie projektami IT w sposób zwinny
Projekty IT obciążone są dużym ryzykiem niepowodzenia. Z raportu zaprezentowanego w 2012 przez firmę Gartner około 60% wdrożeń wielkich systemów informatycznych kończy się klęską (https://dlapilota.pl/wiadomosci/pap/nieudane-wdrozenie-wielkiego-systemu-informatycznego-w-usa). Ta zniechęcająca statystyka nie wynika z ograniczonych środków finansowych lub zasobów ludzkich, a brakach w komunikacji i zarządzaniu. Przesłanie listy funkcjonalności do zespołu programistów to za mało, nawet jeśli programiści są świetni a projekt prosty. Po pierwsze, jak pokazuje praktyka, ta sama lista funkcjonalności może być różnie rozumiana w zależność od tego czy czyta ją programista, grafik, koordynator projektu czy zleceniodawca. Po drugie, między opracowaniem specyfikacji a jej realizacją mogą pojawić się okoliczności, które wymuszą na nas przedefiniowanie założeń naszego projektu. Zawsze też na etapie prac programistycznych pojawiają się pytania, na które sama specyfikacja nie odpowiada. Dlatego ważne jest jak nasz sposób zarządzania projektem radzi sobie ze “zmianą”. Pytanie o sposób zarządzania zmianą nie jest pytaniem tylko do menadżera projektu ale do całej instytucji. Na ile wewnętrzne procedury instytucji są przygotowane na to, że zatwierdzone przez kierownictwo założenia projektu będą zmieniane przez koordynatorów projektu.
Zwinne metodyki i praca w trypie “prototypuj, testuj, ulepszaj” zdecydowanie pomaga we wdrażaniu projektów IT. Dzięki nim możemy na bieżąco weryfikować, czy wszystkie osoby zaangażowane w projekt rozumieją go tak samo, a także czy cele naszego projektu wciąż odpowiadają na potrzeby odbiorców. Wśród zwinnych metodyk najpopularniejszy jest Scrum (https://www.scrum.org/).
Projektowanie zorientowane na użytkownika
Projektowanie zorientowane na użytkownika jako punkt centralny stawia odbiorce i jego potrzeby. Niby oczywiste, a jednak nie brakuje inicjatyw, które zaczynają się od pomysłu “zróbmy aplikacje”, a dopiero na etapie testów mierzą się z zdefiniowaniem jej użytkownika. Uczciwe trzymanie się kolejności: poznaj odbiorcę, określ jego potrzeby, zdefiniuj problem może przynieść nam odpowiedź, że to czego potrzebuje nasza instytucja to responsywna wersja naszej strona internetowej, a nie aplikacja. Metodologią, która pomaga w procesie tworzenia nie zapominać o odbiorcy końcowym i jego potrzebach jest design thinking.
Tworzenie interdyscyplinarnych zespołów i dbanie o jakość komunikacji
Instytucja, która chce realizować projekty cyfrowe musi być świadoma jakie kompetencje i zasoby są do tego potrzebne, a także które z nich posiada w swoim zespole, a których musi poszukać na zewnątrz. W rzeczywistości instytucji kultury, nad narzędziami cyfrowymi pracować będą nie tylko pracownicy z branży IT, ale także tzw. osoby merytoryczne ( kuratorzy, specjaliści różnych dziedzin, pracownicy naukowi). Bywa, że te dwie grupy pracują oddzielnie. To błąd. Na tyle na ile to możliwe, powinni pracować w ramach jednego zespołu, którego członkowie znają się i rozumieją swoje potrzeby i ograniczenia. Efektywne korzystanie z możliwości oferowanych przez technologie może więc się okazać dla instytucji procesem, w który mniej lub bardziej zaangażowany będzie większa część zespołu. A jeszcze nie wspomnieliśmy o roli prawników…
Transparentność procesu wdrożeniowego
Nawet jeżeli mierzymy się ze skomplikowanym wdrożeniem IT, nie znaczy to, że sam proces musi być nie transparentny. Kiedy możemy powiedzieć, że proces jest transparentny? Punktem wyjścia może być próba odpowiedzi na następujące pytania:
- Kto należy do zespołu projektowego?
- Jakie są kompetencje i zakres odpowiedzialności członków zespołu projektowego?
- Czy zgadzamy się na to, by zespół projektowy zmienił się w trakcie realizacji projektu?
- Jaki jest budżet naszego projektu?
- W jaki sposób rozliczamy nasz budżet? Na podstawie przepracowanych godzin przez zespół projektowy czy na podstawie oddanych, działających “półproduktów”?
- Jaki jest harmonogram naszego projektu?
- Kto jest upoważniony do wprowadzania zmian i podpisania protokołu odbioru?
- Jakie kryteria musi spełniać produkt, by uznać go za skończony? Czy wszyscy znają te kryteria i rozumieją je w ten sam sposób?
- Jak wygląda procedura naprawy błędów po zakończeniu projektu?
W utrzymaniu przejrzystości może nam pomóc…. umowa. Sytuacja, w której istnieją dwie równoległe rzeczywistości: ta projektowa oraz ta z umowy, jest zła. Zła nie tylko dlatego, że taka umowa przestaje skutecznie chronić ale również dlatego, że proces przestaje być transparentny.
Ekologia praktyk instytucjonalnych
A może narzędzie, które chcemy stworzyć już istnieje? W internecie nie brakuje rozwiązań udostępnianych na otwartym kodzie więc uczciwy risercz może przynieść zaskakującą odpowiedź na to pytanie. Być może nie znajdziemy dokładnie tego samego narzędzia, ale może podobne będzie wystarczające dobre? Po za tym, weryfikacja dostępnych na rynku rozwiązań pomoże nam lepiej zdefiniować nasze potrzeby oraz zorientować się jak na podobne usługi reagują użytkownicy.