diff --git a/blog/szybki-kurs-pilotazu/index.md b/blog/szybki-kurs-pilotazu/index.md new file mode 100644 index 00000000000..55347ba6fa9 --- /dev/null +++ b/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ł. + + + +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) diff --git "a/static/img/cover/szybki-kurs-pilota\305\274u.png" "b/static/img/cover/szybki-kurs-pilota\305\274u.png" new file mode 100644 index 00000000000..6947e04246b Binary files /dev/null and "b/static/img/cover/szybki-kurs-pilota\305\274u.png" differ