User/docdeveloper/kurs pilotazu

blog/szybki-kurs-pilotazu/index.md

@@ -0,0 +1,200 @@
+---
+title: 'Wdrażanie narzędzia w organizacji - szybki kurs pilotażu'
+authors: mojk
+date: '2026-04-22'
+tags:
+  - 'dobre-praktyki'
+  - 'narzędzia'
+  - 'warsztat'
+coverImage: 'szybki-kurs-pilotażu.png'
+---
+
+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ł.
+
+<!-- truncate -->
+
+Nieistniejąca już organizacja [ITCQF](../koniec-itcqf/index.md) 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:
+
+1. Wybór narzędzia na podstawie wymagań. Możecie poczytać o tym więcej w naszym
+   artykule ["Jak wybierać narzędzia"](../jak-wybierac-narzedzia/index.md).
+2. Projekt pilotażowy. Tutaj jesteś.
+3. 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ę:
+
+1. Jaki model licencyjny obowiązuje (jednorazowa płatność czy subskrypcja)
+2. Czy liczba użytkowników ma znaczenie
+3. 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ń:
+
+1. 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?
+2. 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.
+3. Jak zgłosić problem i jakie jest SLA na jego rozwiązanie?
+4. 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](https://www.gasq.org/files/content/gasq/downloads/certification/ITCQF/ITCQF_Syllabus_v2_0Jun2020.pdf)
+wspomnianej wcześniej fundacji ITCQF, w którym cele pilotażu zostały tak
+zdefiniowane:
+
+1. Ocena czy balans korzyści i poniesionych kosztów jest rozsądny
+2. Lepsze poznanie narzędzia
+3. Ocena jak narzędzie wpisuje się w istniejące procesy i praktyki oraz
+   ustalenie co będzie wymagać zmiany
+4. 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](../jak-wybierac-narzedzia/index.md)), 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](https://unsplash.com/@kristopher_allison?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText)
+i pobrane z
+[Unsplash](https://unsplash.com/photos/man-flying-aircraft-under-cloudy-sky-KU4zYj4u0mo?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText)