Wdrażanie narzędzia w organizacji - szybki kurs pilotażu
Po tym jak wybierzesz narzędzie może pojawić się pokusa, żeby od razu przejść do pełnego wdrożenia go w swojej organizacji. Ale moje doświadczenie i wiedza pozwoliły mi dawno temu dojść do wniosku, że nie jest to najlepszy pomysł.
Nieistniejąca już organizacja ITCQF pozostawiła po sobie dużo cennej wiedzy, m.in. o wprowadzaniu nowego narzędzia w organizacji. Z grubsza ten proces można podzielić na trzy etapy:
- Wybór narzędzia na podstawie wymagań. Możecie poczytać o tym więcej w naszym artykule "Jak wybierać narzędzia".
- Projekt pilotażowy. Tutaj jesteś.
- Pełne wdrożenie.
Podobnie jak w pokerze, żeby nie stracić wszystkich żetonów z powodu blefu drugiej strony, musisz powiedzieć "sprawdzam" w odpowiednim momencie. Pilotaż daje Ci właśnie możliwość sprawdzenia wybranego narzędzia w warunkach bojowych. Nic tak nie weryfikuje teorii i założeń jak praktyczne zastosowanie rozwiązania.
Taki projekt pilotażowy ma sens zarówno w przypadku narzędzi płatnych jak i darmowych, bo na całkowity koszt wdrożenia składa się wiele rzeczy.
Pieniądze to nie wszystko
Przeanalizuj dokładnie ile wydasz na wybrane narzędzie.
W przypadku zakupu oprogramowania od dostawcy, licencja to najbardziej oczywisty koszt wdrożenia. Dowiedz się:
- Jaki model licencyjny obowiązuje (jednorazowa płatność czy subskrypcja)
- Czy liczba użytkowników ma znaczenie
- Na jak długo musisz podpisać umowę i jaki jest okres wypowiedzenia. Jeśli nie ma wymogu podpisania umowy na określony czas to w jaki sposób można zrezygnować z usługi.
Poza licencją istnieją jeszcze koszty w postaci czasu poświęconego na instalację, konfigurację, szkolenia i późniejsze utrzymanie. Pochłoną one zapewne sporą część Twojego budżetu, szczególnie jeśli Twój zespół writerski jest duży. Weź to pod uwagę przygotowując przysłowiowego Excela.
Narzędziowy escape room
A co z ewentualną migracją na inny system? Nikt z nas nie chce znaleźć się w sytuacji, w której używamy narzędzia tylko dlatego, że nie da się go zmienić na inne.
Na początku wszystko może być w porządku, ale z biegiem czasu zaczniesz odkrywać nowe potrzeby, nowe problemy i nowe możliwości. Jeśli rozwój narzędzia nie nadąży za potrzebami, możesz chcieć je zmienić. Wtedy vendor lock-in spowoduje, że przejście na inne rozwiązanie będzie jak próba wyjścia z escape roomu. Bez zaangażowania grupy ludzi i rozwiązania skomplikowanych zagadek nie uda się otworzyć drzwi, które pozwolą Ci opuścić pomieszczenie. Taki lock-in może też mieć miejsce w przypadku darmowych narzędzi, chociaż prawdopodobieństwo jest niższe.
Vendor lock-in to awers, ale zostaje jeszcze rewers, czyli sytuacja, w której vendor z jakiegoś powodu przestaje utrzymywać narzędzie. Na przykład, biznes przestaje być dla niego opłacalny. W najgorszym wypadku zostaniesz bez narzędzia, a w najlepszym z narzędziem, które nie będzie rozwijane, ulepszane i naprawiane.
Jeśli jest to usługa chmurowa, istnieje ryzyko, że produkt może zostać po prostu wyłączony. Jeśli to aplikacja instalowana lokalnie, to możesz stracić część funkcji, bo np. łączy się ona z jakimś serwisem, albo z narzędziem. Przestaniesz też dostawać aktualizacje, które załatają dziury w bezpieczeństwie i wydajności produktu.
Postaraj się przygotować na taki scenariusz poprzez odpowiednie zapisy w umowie.
Pomoc potrzebna od zaraz
Życie lubi nas zaskakiwać, szczególnie na początku naszej przygody z nowym narzędziem. Jeśli nie lubisz przykrych niespodzianek to dowiedz się dokładnie o koszt i dostępność wsparcia technicznego.
Przykładowa lista pytań:
- Czy istnieje wsparcie techniczne? Jeśli to narzędzie open source, to czy istnieją miejsca, do których możesz pójść po pomoc kiedy napotkasz problem?
- Czy dostajesz jakieś wsparcie techniczne w cenie narzędzia? A jeśli tak to w jakiej formie? Może się okazać, że za wsparcie techniczne trzeba dopłacić ekstra.
- Jak zgłosić problem i jakie jest SLA na jego rozwiązanie?
- Jaki jest model dodawania i zmiany funkcji w narzędziu? Ile to kosztuje?
Lepiej dmuchać na zimne, żeby nie okazało się, że pudełko z produktem nie zawiera w sobie tego, co Ci się wydawało.
Oczekiwania kontra rzeczywistość
Jeśli chodzi o kwestie opisane wcześniej w tym artykule, to ciężko postawić jasną granicę na jakim etapie powinny się one wydarzyć.
Z jednej strony, kalkulacja kosztów może lepiej pasuje do etapu wyboru narzędzia niż samego pilotażu. Z drugiej strony to dopiero w trakcie pilotażu będziesz w stanie ocenić realne koszty, bo odkryjesz rzeczy, które Ci umknęły wcześniej. Sytuacja wygląda podobnie jeśli chodzi o wsparcie techniczne. Na etapie wyboru narzędzia możesz częściowo ocenić zakres i koszt takiej usługi, ale w trakcie pilotażu będziesz mieć okazję empirycznie stwierdzić jak ona działa.
Co zatem jest to główną i najważniejszą częścią pilotażu? Z pomocą przychodzi tutaj syllabus wspomnianej wcześniej fundacji ITCQF, w którym cele pilotażu zostały tak zdefiniowane:
- Ocena czy balans korzyści i poniesionych kosztów jest rozsądny
- Lepsze poznanie narzędzia
- Ocena jak narzędzie wpisuje się w istniejące procesy i praktyki oraz ustalenie co będzie wymagać zmiany
- Uzgodnienie jak narzędzie i jego dokumentacja będą używane, zarządzane, przechowywane i utrzymywane (np. ustalenie zasad nazewnictwa plików i sekcji)
Po odhaczeniu powyższej listy dostaniesz solidną porcję danych, która pomoże Ci podjąć ostateczną decyzję czy testowane rozwiązanie jest tym czego oczekujesz.
Operacja się nie udała, pacjent przeżył
Po zebraniu danych z testów może pojawić się u Ciebie pokusa "dopasowania" ich do decyzji, która została podświadomie podjęta w Twojej głowie przed rozpoczęciem projektu. Nie tędy droga.
Celem pilotażu nie jest za wszelką cenę udowodnić, że wybór padł na właściwe narzędzie, tylko zderzenie teorii z praktyką, a następnie chłodna ocena wyniku tego zderzenia. Żeby nie wpaść w pułapkę myślenia tunelowego, przed rozpoczęciem pilotażu, określ jasno kryteria, które zadecydują o tym, czy testowane narzędzie jest tym właściwym. Jeśli okaże się Twój wybór nie był dobry, to nie oznacza, że pilotaż się nie udał. Porażka to też forma zwycięstwa.
Lepiej odkryć w trakcie testów, że coś nie działa tak jak chcesz niż dojść do tych samych wniosków już po wdrożeniu na produkcję. W szerszej perspektywie, oszczędzi Ci to sporo czasu i pieniędzy. Jeśli Twój pilotaż pokazał, że wybrane narzędzie jednak nie spełnia wymagań, wracasz do początku. A czasami nawet cofasz się jeszcze dalej, czyli ponownie analizujesz swoje wymagania i założenia, żeby mieć pewność, że Twoje oczekiwania są realne i przystające do rzeczywistości. Potem powtarzasz proces wyboru narzędzia.
Jak to zrobić dobrze
Przede wszystkim, Twój pilotaż musi mieć mierzalny cel i punkty do zweryfikowania.
Żeby móc spełnić to wymaganie, nie bierz na warsztat projektu w stylu "Hello World!" albo "Test1". Zamiast tego przeprowadź pilotaż na prawdziwym projekcie, np. dokumentacji do konkretnego produktu na konkretny release. Ustal zadanie, które zweryfikuje każde wymaganie. Na przykład, jeśli wymagasz reusu ostrzeżeń i innych notek (tak jak w artykule o wyborze narzędzia), to rozpisz punkty, które pozwolą Ci go zweryfikować:
- Czy łatwo zarządzać reusem notek
- Czy notki spełniają wymagania
- Czy używanie notek nie prowadzi do pomyłek
- Co się stanie kiedy wymagana będzie zmiana treści notki (czy trzeba ręcznie publikować wszystkie instancje czy zmiana zaciągnie się automatycznie do wszystkich instancji)
Oceń wykonanie każdego zadania bez naginania rzeczywistości. Opisz wszystko, co było niespodziewane, niezależnie od tego czy było pozytywne czy negatywne.
Odpowiedni projekt to jedna rzecz. Drugą jest odpowiedni zespoł, który przeprowadzi pilotaż. Grupa powinna być na tyle duża i zróżnicowana, żeby wszystkie kompetencje i obowiązki zostały w niej uwzględnione. Właściwy dobór osób jest też kluczowy z innego powodu. Staną się one ekspertami od testowanego narzędzia. Jeśli projekt zakończy się sukcesem to grupa pilotażowa będzie zapewne szkolić i wspierać resztę zespołu na późniejszych etapach wdrożenia.
Pilotaż to dopiero początek
Jeśli Twój pilotaż zakończył się wnioskiem, że testowane narzędzie jest właściwym rozwiązaniem, to masz powód do zadowolenia. Ale nie rozsiadaj się na długo, bo to nie koniec. Sukces odtrąbiony, czas zakasać rękawy i brać się do roboty.
Droga od projektu pilotażowego do rozwiązania produkcyjnego jest przeważnie długa i kręta. Nie chcę tutaj brzmieć jak Pan Maruda Niszczyciel Dobrej Zabawy, ale przechodziłem ją kilka razy i rzadko kiedy wszystko idzie jak po maśle. Zapewne wyjdzie trochę nieprzewidzianych problemów. To normalne, więc nie martw się tylko skup się na szukaniu rozwiązań. Pamiętaj tylko, żeby w kalkulacjach i planowaniu wdrożenia produkcyjnego wziąć to pod uwagę, bo ktoś będzie musiał zainwestować czas i pieniądze w gaszenie takich pożarów.
Powodzenia!
Zdjęcie wykonane przez Kristophera Allisona i pobrane z Unsplash