Wybór odpowiednich wskaźników dla projektu

Ten przewodnik ma pomóc organizacjom zrozumieć, jakie problemy można rozwiązać dzięki lepszej dokumentacji, oraz jak wybrać odpowiednie wskaźniki do projektów dokumentacji.

Obecna faza:
ogłoszono wyniki. Zobacz oś czasu.

Opisz problem

Zanim wybierzesz dane, musisz dobrze zrozumieć problem, który chcesz rozwiązać. Podaj jak najwięcej szczegółów.

  • „Prośby o połączenie dotyczące naszej dokumentacji wdrożenia zajmują zbyt dużo czasu. Uczestnicy rezygnują i odchodzą”.
  • „Zobaczmy, że otwiera się zbyt wiele problemów, abyśmy mogli pomóc w rozszyfrowywaniu kodów błędów”.
  • „Nasz potok CI/CD jest niestabilny. Zbyt wiele testów zawodzi z niejasnych powodów”.
  • „Na naszych cotygodniowych spotkaniach ludzie wydają się być marudni”.

Opracowanie hipotezy

Poszukaj przyczyn i skutków. Co może być przyczyną opisanego problemu? Pamiętaj, że problemy mogą mieć wiele przyczyn lub ich przyczyny mogą się nakładać.

  • „Przeniesienie żądań pull request dotyczących dokumentacji wprowadzającej zajmuje dużo czasu, ponieważ nie mamy jasnych wskazówek dotyczących stylu. Recenzenci albo odkładają sprawdzenie PR, ponieważ nie wiedzą, co zrobić, albo wielokrotnie odwołują się do współtwórców w sprawie formatowania.
  • „Użytkownicy muszą zgłaszać problemy, ponieważ nie mogą znaleźć informacji o kodach błędów w dokumentacji”.
  • „Nasze testy CI/CD się nie udają, ponieważ napotykamy ograniczenia planu i limity czasu u naszego dostawcy”.
  • „Na naszych cotygodniowych spotkaniach ludzie są źli, ponieważ odbywają się one o 5:30 rano w ich strefie czasowej”.

Zaproponuj rozwiązanie

Czy problem można rozwiązać, wprowadzając nową lub lepszą dokumentację?

  • „Gdybyśmy mieli przewodnik po stylu, osoby dokonujące commitów mogłyby go sprawdzić przed przesłaniem prośby o przeniesienie. Weryfikatorzy wiedzieliby, na co zwrócić uwagę. Recenzenci i współtwórcy nie musieliby się spierać na temat formatowania, tonu i stylu.
  • „Gdybyśmy mieli dokumentację kodów błędów, użytkownicy mogliby znaleźć odpowiedzi w niej, zamiast zgłaszać problemy”.
  • „Hmm, nie sądzę, żeby lepsza dokumentacja rozwiązała nasz problem z CI/CD”.
  • „Możemy zacząć każde spotkanie od żartu. Stworzenie kolekcji żartów typu „pukanie, pukanie” pomogłoby nam rozpocząć spotkania z uśmiechem”.

Unikaj ogólników.

Czy możesz określić rozmiar problemu?

  • „Co tak naprawdę oznacza „łączenie PR zajmuje zbyt dużo czasu”? Dwa miesiące? Dwa tygodnie? Jak długo autorzy będą czekać na sprawdzenie, zanim się poddadzą?
  • „Ile problemów związanych z kodami błędów jest „zbyt dużą liczbą problemów”?
  • „Hmm… jak bardzo „zbyt zły”?

Sprawdzanie możliwości pomiaru

Jak sprawdzić zaproponowane dane? Czy można je łatwo i precyzyjnie zmierzyć? Czy pomiar zależy od tego, kto go przeprowadza?

  • „Możemy łatwo sprawdzić, jak długo trwa rozpatrywanie prośby o przechwycenie i jak długo minęło od momentu, gdy poproszono o sprawdzenie. Nie możemy dokładnie określić, kiedy współtwórca się poddaje.
  • „Możemy policzyć, ile problemów ma tag „error-code” (kod błędu) lub wyszukać w problemach tekst kodu błędu”.
  • „Nie możemy w dobry sposób zmierzyć niezadowolenia użytkowników”.

Dodawanie dodatkowych danych

Czy są jeszcze inne dane, które pomogą Ci ustalić, czy dokumentacja rozwiązuje Twój problem? Czy wskaźnik docelowy jest taki sam w każdym przypadku?

  • „Dłuższe PR wymagają więcej czasu na sprawdzenie. Powinniśmy mieć różne progi dla różnych rozmiarów PR. Chcemy zmierzyć czas potrzebny na scalenie w przypadku małych, średnich, dużych i gigantycznych PR-ów.
  • „Możemy sprawdzić, ile razy została wyświetlona dokumentacja dotycząca kodów błędów, i sprawdzić, czy ta liczba koreluje z mniejszą liczbą zgłaszanych problemów”.

Wybierz przedział czasu

  • „Uważamy, że 2 tygodnie to rozsądny czas na połączenie małych i średnich PR-ów, a wszystkie PR-y powinny zostać połączone w ciągu miesiąca. Dlatego będziemy to mierzyć co 2 tygodnie”.
  • „Nie ma sensu codziennie aktualizować liczby problemów związanych z kodami błędów, ponieważ zwykle zajmuje nam to tydzień. Będziemy to mierzyć co tydzień”.

Zapisz cele

Jaka zmiana wybranego rodzaju danych musiałaby nastąpić, aby można było uznać projekt za udany? Rozważ ustawienie ilościowych celów dla wybranych danych.

  • „Gdybyśmy osiągnęli nasz cel, czyli zamknąć każdy nowy projekt PR w mniej niż miesiąc, byłby to sukces. Gdyby średni czas zamykania dużych spraw PR skrócił się o 2 tygodnie, byłby to ogromny sukces”.
  • „W idealnej sytuacji nie powinno być żadnych nowych problemów związanych z błędami. Uważamy jednak, że projekt był udany, jeśli liczba zgłoszonych problemów związanych z błędami spadła o 50%”.