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 dane dla projektów dokumentacji.

Aktualna faza:
opublikowano studia przypadków. Zobacz oś czasu.

Opisz problem

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

  • „Żądania pull dotyczące naszej dokumentacji dotyczącej rejestracji zajmują zbyt dużo czasu na scalanie. Uczestnicy rezygnują i odchodzą”.
  • „Zobaczyliśmy zbyt wiele zgłoszonych problemów, aby pomóc w rozszyfrowaniu kodów błędów”.
  • „Nasz potok CI/CD jest niestabilny. Zbyt wiele testów zawodzi z niejasnych powodów.
  • „Ludzie wydają się być marudni podczas naszych cotygodniowych spotkań”.

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ć.

  • „Przejęcie prośby o połączenie w przypadku dokumentacji wprowadzającej zajmuje tak dużo czasu, ponieważ nie mamy jasnych wskazówek dotyczących stylu. Recenzenci albo odkładają sprawdzenie PR, ponieważ nie wiedzą, co zrobić, albo wymieniają się z autorami opiniami na temat 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 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 PR-ów. Weryfikatorzy wiedzieliby, na co zwrócić uwagę. Recenzenci i współtwórcy nie będą musieli się spierać na temat formatowania, tonu i stylu.
  • „Gdybyśmy mieli dokumentację kodów błędów, użytkownicy mogliby znaleźć odpowiedzi na swoje pytania, 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 typu „pukanie, pukanie”. 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-ów trwa zbyt długo?” Dwa miesiące? Dwa tygodnie? „Jak długo autorzy będą czekać na sprawdzenie, zanim zrezygnują?”
  • „Ile problemów związanych z błędami jest 'zbyt duża liczba problemów'?”
  • „Hmm… jak bardzo marudna jest osoba, która jest „zbyt marudna”?

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 prośba 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 rezygnuje”.
  • „Możemy policzyć, ile problemów ma tag 'error-code', lub przeszukać problemy pod kątem kodu błędu”.
  • „Nie możemy w dostateczny sposób zmierzyć niezadowolenia użytkowników”.

Dodawanie dodatkowych danych

Czy istnieją 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 zbiorów PR.
  • „Możemy sprawdzić, ile razy została wyświetlona dokumentacja dotycząca kodu błędu, 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 mierzyć wyniki 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 wskaźnika musiałaby nastąpić, aby można było uznać projekt za udany? Warto wyznaczyć ilościowe cele dotyczące 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 projektów 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%”.