Ankiety na temat doświadczeń programistów w praktyce
Przykładowy sposób przeprowadzenia ankiety na temat doświadczeń programistów za pomocą narzędzia ankietowego.
Plot survey results on an XY graph using our rating system: red signs need the team’s attention, yellow signs are areas for improvement, and green signs are already well-served.
Używaj tablic Confluence do przedstawienia na wykresie najważniejszych podstawowych parametrów, omawiania potencjalnych rozwiązań i planowania działań mających na celu poprawę doświadczeń programisty.
Czego będziesz potrzebować
Zdalne
Narzędzie ankietowe
Narzędzie do współpracy cyfrowej
Osobiście
Narzędzie ankietowe
Tablica lub duży arkusz papieru
Karteczki samoprzylepne
Instrukcje dotyczące gry
Uwaga: ankiety na temat doświadczeń programistów są najbardziej przydatne wtedy, gdy dotyczą konkretnej organizacji. W poniższej grze dołączamy ankietę przeznaczoną dla firmy Atlassian. Nasza ankieta może okazać się pomocna, ale zalecamy jej spersonalizowanie pod kątem Twojego zespołu i organizacji.
1. Wybór podstawowych parametrów 30 min
Aby naprawdę zrozumieć doświadczenia programistów ze swojego zespołu, musisz zadać właściwe pytania. W Atlassian koncentrujemy się na kluczowych podstawowych parametrach, które pomagają nam odkryć, co przeszkadza programistom. Podstawowe parametry to punkty danych, które działają jako wskaźniki kondycji i wydajności zespołu. Podobnie jak funkcje życiowe ciała, mogą one umożliwić szybką identyfikację problemów w systemie.
Podstawowe parametry są niezbędnym elementem całej tej gry, więc zanim zaczniesz, ustal z zespołem, które parametry są ważne dla Waszej działalności. Zalecamy uwzględnienie od sześciu do ośmiu podstawowych parametrów w ankiecie przeznaczonej dla konkretnej organizacji.
Oto osiem podstawowych parametrów, które utworzyliśmy na potrzeby naszej ankiety na temat doświadczeń programistów w Atlassian:
- Zrównoważone tempo dostarczania: jak szybko Twój zespół dostarcza wysokiej jakości kod bez powodowania wypalenia zawodowego. Chodzi tu o typowy cykl tworzenia oprogramowania od momentu, w którym programiści w zespole zaczynają pracować nad historyjką użytkownika do momentu wdrożenia funkcji do produkcji.
- Czas oczekiwania: czas, jaki programiści marnują, czekając na kompilacje, testy, przeglądy kodu i niepotrzebne spotkania.
- Niezależność wykonania: zdolność zespołu do dostarczania produktów bez polegania na innych zespołach, niezależnie od tego, kto jest właścicielem kodu.
- Metody pracy: Ile wysiłku wymaga znalezienie i wdrożenie nowej metody pracy, której Twój zespół potrzebuje lub z której mógłby skorzystać, w tym narzędzi, ram postępowania, procesów i praktyk.
- Standardy zewnętrzne: praca potrzebna do spełnienia standardów firmy. Standardy te są generowane zewnętrznie dla Twojego zespołu i stanowią uzupełnienie wymogów dotyczących produktów, takich jak bezpieczeństwo i zgodność z przepisami.
- Utrzymanie: ile czasu Twój zespół poświęca na utrzymanie bazy kodu, pipeline'ów i infrastruktury. Tę pracę generuje wewnętrznie Twój zespół.
- Onboarding: jak szybko inżynier może stać się skuteczny po zatrudnieniu lub przeniesieniu wewnętrznym.
- Zadowolenie programistów: jak zadowoleni są inżynierowie ze swojej wydajności.
Włącz nasze podstawowe parametry do ankiety przeznaczonej dla swojej organizacji lub wykorzystaj je jako inspirację i stwórz własne. Jeśli podstawowy parametr Was nie dotyczy, możesz go usunąć z ankiety w kroku drugim. Jeśli masz wątpliwości co do znaczenia podstawowego parametru, zalecamy pozostawienie go do momentu uruchomienia gry przynajmniej raz.
Zastanawiasz się, jak stworzyliśmy te podstawowe parametry?
Najpierw przeprowadziliśmy ankiety w całej organizacji w celu zebrania danych. Następnie zastosowaliśmy zasady innowacji opartych na wynikach z książki Anthony'ego Ulwicka What Customers Want, aby nadać każdemu podstawowemu parametrowi ocenę punktową możliwości.
2. Przeprowadzenie ankiety 10 MIN
Po wybraniu lub utworzeniu parametrów podstawowych dotyczących programistów w Twoim zespole przygotuj ich do ankiety, przekazując im informacje na temat celu gry i sposobu, w jaki planujesz podejmować dalsze działania w związku z wynikami ankiety.
Następnie zaproś wszystkich programistów do wypełnienia ankiety. Wyznacz konkretny termin — zalecamy od trzech do siedmiu dni.
Jeśli nie możesz wymagać od wszystkich wypełnienia ankiety, warto zarejestrować dodatkowe informacje, takie jak poziom roli lub lokalizacja. Pomoże to upewnić się, że wyniki nie są wypaczone.
Poniższa ankieta opiera się na podstawowych parametrach Atlassian. Jeśli zdecydujesz się uwzględnić inne podstawowe parametry, musisz dostosować pytania w ankiecie. Zadaj dwa pytania dotyczące każdego podstawowego parametru — jedno o jego znaczenie dla programisty, a drugie o to, jak dana osoba jest zadowolona z obecnej zdolności zespołu do dostarczania produktów zgodnie z tym parametrem. Użyj w ankiecie skali od 0 do 10, gdzie 0 oznacza brak znaczenia i zadowolenia, a 10 — duże znaczenie i wysokie zadowolenie.
PRZYKŁADOWE PYTANIA ANKIETOWE W CELU OCENY DOŚWIADCZEŃ PROGRAMISTY:
Zrównoważone tempo dostarczania
- Jak ważne dla Twojego zespołu jest zrównoważone tempo dostarczania kodu wysokiej jakości?
- Jak jest poziom Twojego zadowolenia ze zdolności Twojego zespołu do dostarczania kodu wysokiej jakości w zrównoważonym tempie?
Czas oczekiwania
- Jak ważne dla wydajności Twojej pracy jest ograniczenie czasu oczekiwania?
- Jaki jest poziom Twojego zadowolenia z czasu oczekiwania programistów w Twoim zespole?
Niezależność wykonania
- Jak ważna jest dla Ciebie zdolność Twojego zespołu do dostarczania produktów niezależnie od innych zespołów?
- Jaki jest poziom Twojego zadowolenia z niezależności dostarczania produktów przez Twój zespół?
Sposoby pracy
- Jak ważne dla Twojego zespołu jest odkrywanie i wdrażanie nowych metod pracy, w tym narzędzi, procesów i praktyk?
- Jaki jest poziom Twojego zadowolenia ze zdolności Twojego zespołu do znajdowania i wdrażania nowej metody pracy, w tym narzędzi, procesów i praktyk?
Standardy zewnętrzne
- Jak ważna dla Twojej wydajności jest ilość prac konserwacyjnych lub pracy na platformie potrzebna do spełnienia wygenerowanych zewnętrznie standardów firmy, za które odpowiada Twój zespół?
- Jaki jest Twój poziom zadowolenia z ilości prac konserwacyjnych lub pracy na platformie potrzebnej do spełnienia wygenerowanych zewnętrznie standardów firmy, za które odpowiada Twój zespół?
Obsługa
- Jak ważny dla Twojej wydajności jest nakład pracy wymagany od Ciebie w celu utrzymania standardów zespołu w zakresie kodu, narzędzi i pipeline'ów?
- Jaki jest Twój poziom zadowolenia z nakładu pracy wymaganego do utrzymania kodu, narzędzi i pipeline'ów?
Wdrażanie
- Jak ważna dla Twojej wydajności jest ilość czasu potrzebna nowo zatrudnionym osobom lub pracownikom przeniesionym wewnątrz firmy, aby zacząć efektywnie funkcjonować w Twoim zespole?
- Jaki jest poziom Twojego zadowolenia z tego, ile czasu potrzebują osoby nowo zatrudnione lub pracownicy przeniesieni wewnątrz firmy, aby zacząć efektywnie funkcjonować w Twoim zespole?
Zadowolenie programistów
- Na ile ważne jest zadowolenie dla Twojej produktywności?
- Jaki jest poziom Twojego zadowolenia z produktywności programistów pracujących z Twoim zespołem?
3. Oblicz wyniki 10 MIN
Gdy wszyscy wypełnią ankietę, zamknij ją i przeanalizuj dane.
Następnie przypisz każdemu parametrowi podstawowemu ocenę punktową możliwości. Jeśli stwierdzisz wartości odstające, odnotuj je w uwagach i omów ze swoim zespołem. Jeśli chcesz, możesz w celu usprawnienia obliczeń użyć arkusza kalkulacyjnego.
Pokazujemy, jak obliczyć ocenę punktową możliwości dla każdego parametru podstawowego:
- Najpierw określ średnią ważność i średnie zadowolenie w odniesieniu do parametru podstawowego.
- Przykładowo odpowiednio 8,22 i 5,88.
- Następnie oblicz różnicę między średnią ważnością a średnim zadowoleniem.
- Przykładowo 8,22 – 5,88 = 2,34
- Jeśli ta liczba jest dodatnia, dodaj ją do średniej ważności, aby uzyskać ocenę punktową możliwości swojego parametru podstawowego. Jeśli liczba jest ujemna, Twoją ocenę punktową możliwości stanowi średnia ważność.
- Przykładowo 8,22 + 2,34 = 10,56
Ocena punktowa możliwości = ważność + maks. (ważność – zadowolenie, 0)
Next, take the opportunity score for each of your vital signs and designate a rating:
Wskazówka: ZMAPUJ SWOJE DANE
Jeśli pomaga Ci wizualizowanie każdego z parametrów podstawowych w stosunku do innych, możesz wykreślić wyniki na wykresie punktowym.
When to remove a vital sign
If average satisfaction is higher than average importance, the vital sign is probably not very important to your team, or your team is satisfied with it already. In the future, you can replace the vital sign with one you want to watch more closely.
15+: Extremely under-served areas to address first.
10-15: Areas that should be addressed soon.
10 and below: Well-served areas that do not need to be addressed.
We've organized results from a sample survey into a table below.
Przykładowe wyniki ankiety
Parametry podstawowe | Średnia ważność | Średnie zadowolenie | Ocena punktowa możliwości | Wyniki |
---|---|---|---|---|
Zrównoważone tempo dostarczania | Średnia ważność 6.93 | Średnie zadowolenie 4.83 | Ocena punktowa możliwości 9.03 | Results GOOD |
Czas oczekiwania | Średnia ważność 7.48 | Średnie zadowolenie 3.41 | Ocena punktowa możliwości 11.55 | Results IMPROVEMENT NEEDED |
Niezależność wykonania | Średnia ważność 4.56 | Średnie zadowolenie 6.34 | Ocena punktowa możliwości 4.56 | Results GOOD |
Sposoby pracy | Średnia ważność 8.3 | Średnie zadowolenie 1.33 | Ocena punktowa możliwości 15.27 | Results NEEDS ACTION |
Standardy zewnętrzne | Średnia ważność 2.67 | Średnie zadowolenie 5.87 | Ocena punktowa możliwości 2.67 | Results GOOD |
Obsługa | Średnia ważność 9.15 | Średnie zadowolenie 3.23 | Ocena punktowa możliwości 15.07 | Results NEEDS ACTION |
Wdrażanie | Średnia ważność 3.6 | Średnie zadowolenie 9.76 | Ocena punktowa możliwości 3.6 | Results GOOD |
Zadowolenie programistów | Średnia ważność 7.82 | Średnie zadowolenie 5.49 | Ocena punktowa możliwości 10.15 | Results IMPROVEMENT NEEDED |
Zaawansowane rozwiązania matematyczne
Opcjonalnym sposobem na lepsze wykorzystanie wyników jest obliczenie luki w zadowoleniu dla każdego parametru podstawowego.
Kiedy zauważysz różnicę między średnią ważnością a średnim zadowoleniem w przypadku poszczególnych parametrów podstawowych, możesz obliczyć lukę w zadowoleniu. Jest to różnica między tym, jak ważny jest parametr podstawowy dla programistów, a tym, na ile są z niego zadowoleni. Mniejsza luka w zadowoleniu wskazuje, że z parametrem podstawowym wiąże się albo niska ważność i niskie zadowolenie, albo wysoka ważność i wysokie zadowolenie, a więc w obu przypadkach ten parametr podstawowy jest mniej priorytetowy. Większa luka w zadowoleniu wskazuje, że parametr podstawowy jest bardzo ważny dla zespołu, ale zespół obecnie nie jest zadowolony ze sposobu zarządzania nim, więc rozwiązanie tego problemu ma wysokim priorytet.
4. Spotkajcie się, aby omówić wyniki i opracować rozwiązania 30 min
Na koniec omów wyniki ankiety z zespołem, określ trzy najpilniejsze obszary możliwości, i przeprowadź wspólną burzę mózgów.
To facilitate this important meeting, we recommend creating a Confluence page or Trello board with a simple vital signs table that lists your ratings. This makes for an effective, simple setup to keep remote or hybrid teams aligned. You can mark the most pressing opportunity areas and even share a link to the raw, anonymized responses if you want to dig deeper.
Możesz także użyć tablic Confluence, aby utworzyć sekcje dla każdego z najpilniejszych parametrów podstawowych i razem z innymi poszukać potencjalnych rozwiązań, a także dodawać własne przemyślenia.
- Wróć do pomysłów, aby sprawdzić te, które warto realizować.
- Dodaj do backlogu czynności do wykonania.
- Po spotkaniu upewnij się, że wszyscy mają dostęp do strony i zaproś programistów do dalszego dodawania pomysłów.
To spotkanie jest ważnym sposobem, aby zespół pokazał programistom, że ich głos ma znaczenie, i może prowadzić do zmian, a to może zapewnić wysoki wskaźnik wypełniania ankiet w przyszłości. Zaproponowanie sposobu, dzięki któremu programiści będą mieli swój wkład w ostateczny efekt, może pomóc w zwiększeniu ich zaangażowania, co często prowadzi do lepszej realizacji zadań i uzyskiwania bardziej spójnych wyników. Różnorodne perspektywy prowadzą do uzyskania lepszych rozwiązań, a każdy, nie tylko kierownictwo, może przyczyniać się do zmian i rozwoju.
Wskazówka: NIE POMIJAJ TEGO KROKU!
Zadawanie pytań bez omawiania wyników jest często gorsze niż niezadawanie pytań.
Kolejne czynności
Zalecamy przeprowadzanie gry Developer Experience Survey co najmniej dwa razy w roku, jeśli jesteście zadowoleni ze swoich wskaźników sukcesu parametrów podstawowych, lub co kwartał, jeśli aktywnie pracujecie nad poprawą jakości środowiska programistycznego.
Poznaj inne gry
Mamy coś dla Twojego zespołu
Nasz newsletter zawiera aktualne porady, wskazówki oraz informacje o najnowszych grach.