Konieczność wyznaczania celów dla programistów, mimo że cele nie działają [zamknięte]

Jest ogólnie przyjęte , że ustawienie mierzalne cele dla twórców oprogramowania nie działa , ponieważ zbyt dużo skupić się na realizacji celów może prowadzić do licznika zachowanie do celów organizacyjnych (tzw „ dysfunkcja pomiaru ”).

Jednak w mojej firmie jesteśmy zobowiązani do wyznaczania celów dla wszystkich pracowników, a dział personalny zachęca nas, aby byli SMART . W przeszłości moi koledzy menedżerowie pierwszego stopnia (liderzy zespołów) i ja próbowaliśmy kilku podejść:

1. Wyznacz mierzalne cele, które są dodatkowe w stosunku do normalnej pracy, np. „Przeprowadź szkolenie z technologii X”, „Utwórz dokumentację dla fragmentu kodu Y, którego nikt nie zrozumie” i tak dalej. Jeśli chodzi o coroczną ocenę wyników, oceniaj deweloperów nie na podstawie zapisanych celów, ale raczej na podstawie mojej opinii o niewymiernej wartości ich normalnej pracy, ponieważ na tym właśnie zależy firmie.
2. Ustaw bardzo szczegółowe cele, takie jak „przepracowana liczba dni zarejestrowana przez system zarządzania zadaniami”, „liczba wprowadzonych błędów”, „liczba spowodowanych wydanych produkcji”. Prowadziło to do zawyżonych szacunków i nieprawidłowej klasyfikacji błędów w celu uzyskania lepszych „wyników”. Co ciekawe, nawet tym deweloperom, którzy osiągnęli wysokie wyniki w tym systemie, nie podobało się to, ponieważ wewnętrzne zaufanie w zespole zostało uszkodzone i nie zawsze uważali, że zasługują na swoją wysoką pozycję.
3. Wyznacz niejasne cele, które są wariantami „Wykonuj dobrze swoją normalną pracę”. Jeśli chodzi o ocenę roczną, ich ocena odzwierciedla wyniki w stosunku do celów, ale same cele nie są mierzalne ani osiągalne, co jest niezadowolone.

Żadne z nich nie jest idealne. Jeśli byłeś w podobnej sytuacji, kiedy musiałeś tworzyć znaczące, mierzalne cele dla programistów pomimo dowodów na ich skuteczność, jakie podejście jest dla Ciebie najlepsze?

Powiązane pytania, które znalazłem, nie do końca dotyczą tego samego punktu:

• Jakie są dobre cele wydajnościowe dla inżyniera oprogramowania?
• Ustalanie celów wydajnościowych dla programistów
• Jakie są odpowiednie wskaźniki wydajności dla programistów?
• Jaka jest rzetelna technika pomiaru produktywności dla programistów?
• Potrzebuję jakichś „celów” kariery na następny rok

Aktualizacja (18 listopada 2009): Na moje pytanie jest 10 głosów „za”, a najwyżej ocenione głosy mają tylko 4 głosy „za” (w tym po jednym ode mnie). Myślę, że to nam coś mówi: być może Joel i pozostali mają rację, i że połączona mądrość przepełnienia stosów nie może wymyślić żadnych przekonujących, mierzalnych celów dla programistów, w które nie można by grać bez negatywnego wpływu na prawdziwą (niewymierną) wartość ich praca. Dzięki za próbę!

jakie podejście sprawdziło się najlepiej dla Ciebie?

Tylko jeden cel: przejść inspekcję kodu / wzajemną recenzję, ze mną jako recenzentem, bez znalezienia jakichkolwiek błędów lub innej krytyki, która wymaga od Ciebie powtórzenia czegoś.

Uwagi:

• Nie mierzyłem zdolności nowych pracowników do szybkiego kończenia pracy i nie zachęcałem ich do: Chciałem, aby ludzie nauczyli się dobrze kończyć (bo jeśli nie jest dobrze ukończony, to nie jest skończony)
• Ludzie dowiedzieli się, czego szukałem w przeglądzie kodu: jest to więc okazja do nauki i środek kontroli jakości, a nie tylko cel zarządzania
• Moje komentarze miałyby dwie kategorie:
  1. To jest błąd: musisz to naprawić, zanim się zameldujesz
  2. Jako sugestia zrobiłbym to a to
• Po pewnym czasie moje recenzje kodu osoby przestały znajdować elementy, które trzeba naprawić (w tym momencie nie musiałbym już przeglądać ich pracy).

Osobiście staram się stawiać dwa rodzaje celów:

• Cele biznesowe (dlatego w końcu otrzymujemy wynagrodzenie). Na przykład „ukończ projekt X do 1 czerwca 2009 r.”). Te cele są często wspólne dla kilku członków zespołu (i są tego świadomi). Zespół może przekroczyć cel, wprowadzając projekt wcześniej lub przekraczając wymaganą funkcjonalność. Poszczególne osoby mogą przekroczyć cel, tworząc więcej funkcji, mając mniej błędów przeciwko sobie lub coaching i wspieranie innych członków zespołu.

• Cele rozwoju osobistego, na przykład ukończenie projektu obejmującego technologię, którą deweloper chce dodać do swojego zestawu umiejętności, lepsze zrozumienie domeny użytkownika, zdobycie doświadczenia przywódczego itp.

Uważam, że ważne jest, aby:

• Cele są SMART
• Cele są dostosowane do potrzeb firmy
• Do celów zalicza się „normalną pracę”, w rzeczywistości są to najważniejsze cele!
• Pracownik ma szansę przekroczyć wyznaczone przez Ciebie cele

Na koniec chciałbym trzymać się z daleka od wskaźników oprogramowania jako celów - są one zbyt łatwe do osiągnięcia i prawdopodobnie nie zapewnią Ci tego, czego potrzebujesz. Użyłbym miernika tylko wtedy, gdy chcę wyszkolić kogoś w określonym zachowaniu.

Wszystko to sprowadza się do tego, że „kierownictwo pierwszego szczebla”, a prawie żadne kierownictwo nie zna swoich pracowników. Zamiast być częścią codziennego planowania i rozwoju, pojawiają się takie rzeczy, jak SMART. Gdyby menedżerowie spędzali więcej czasu z facetami, którzy wykonują rzeczywistą pracę, nic z tego nie byłoby potrzebne.

Osobiście wolę pracować w zwinnym środowisku, w którym jest oczywiste, kto z programistów działa pod względem produktywności i świadomości jakości. Prawdziwie zwinne podejście wymaga zaangażowania nie tylko programistów, ale również projektantów, testerów, klientów i menedżerów produktu. To naturalnie prowadzi do lepszych spostrzeżeń z punktu widzenia menedżerów.

Wymierne cele, które widziałem do tej pory:

• Zdaj egzamin certyfikacyjny
• Zbadaj technologię X i poprowadź prezentację na jej temat
• Liczba zatwierdzonych zmian istotnych dla kompilacji
• Liczba artykułów wiki napisanych na temat wewnętrznego zarządzania wiedzą

Co powiesz na bezpośrednie zapytanie programistów, czy mają jakieś pomysły na rozwój osobisty, które można następnie wykorzystać do celów?

Konieczność wyznaczania celów programistom, nawet jeśli nie działają

Jeśli twoi programiści nie działają, być może niektóre cele są właśnie tym, czego potrzebują, aby zachęcić ich do działania? ;-)

„Upewnij się, że co najmniej n% Twojego kodu jest testowane za pomocą odpowiedniego testu jednostkowego” Użyj narzędzia pokrycia, aby to udowodnić, i poproś kogoś innego o sprawdzenie jakości testów.

Myślę, że posiadanie bardzo konkretnych celów z góry, tj. SMART (może faktycznie pracujemy w tym samym miejscu), wydaje się dobrym pomysłem w praktyce, ale nie jest to zbyt praktyczne dla większości zespołów.

Problem w rzeczywistości polega na tym, że zmieniają się nasze kolejne cele. Biznes się zmienia i jako programiści musimy odpowiednio reagować i reagować w rozsądnych ramach czasowych.

Rozważ wyznaczenie celów, które są powiązane z celem zespołu lub grupy w organizacji. Twój zespół nie byłby finansowany, gdyby nie służył celowi - celowi makro. Miej wspólne cele, które istnieją w całym zespole i są zgodne z biznesem. Daj ludziom odpowiedzialność i pociągnij do odpowiedzialności. Świętuj ich sukcesy i porażki (jeśli czasami nie zawodzimy, prawdopodobnie nie próbujemy i tego właśnie oczekujesz od ludzi). HTH

Mamy wiele wskaźników, które są zbierane podczas pracy programistów, takich jak:

• Liczba zmian / dodania SLOC
• Liczba błędów / błędów wprowadzonych na różnych etapach procesu (podczas wzajemnej oceny, recenzji post-peer, post-release)
• Żądania zmiany spełnione / odrzucone
• Dokumenty formalne (opisy wersji oprogramowania, dokumentacja projektowa itp.)

Wszystko to jest namacalne, które uważam za przydatne w prezentacjach dotyczących zarządzania i zapewniania jakości oprogramowania. Ale nigdy nie uważałem ich za szczególnie użyteczne w rzeczywistych ocenach osiągnięć ludzi - o czym świadczy kilka z wymienionych przez ciebie linków. Przekonałem się, że punkty Joela są tutaj ważne - wskaźniki nigdy nie sprzyjają dobrej atmosferze zespołowej.

Niestety, wszyscy żyjemy w świecie, w którym metryki są wymagane przez innych (kierownictwo, zapewnienie jakości, zewnętrzni wykonawcy itp.). Odkryłem, że wymagane jest zachowanie równowagi - dostarczenie tych metryk, ale także dostarczenie dowodów na wartości niematerialne - niematerialne jest to, co osiągnął każdy programista, co niekoniecznie jest śledzone. Na przykład miałem programistę, który spędził dużo czasu na badaniu starszego kodu, którego nikt inny nie chciał dotykać. Chociaż jego wskaźniki były niskie w tym okresie, wysiłek ten był nieoceniony.

Jedynym sposobem, w jaki znalazłem takie rzeczy, było naciskanie na stworzenie dodatkowej kategorii niematerialnej i nadanie jej równej wagi innym wskaźnikom. Zwykle jest to wystarczające, aby zmienić równowagę dla konkretnego programisty.

Wydaje się, że jednym z problemów jest to, że jako oddział / dział organizacje IT nie mają mierzalnych celów strategicznych. Gdyby to zrobili, łatwiej byłoby ustalić cele dla poszczególnych osób.

np. gdyby istniała inicjatywa departamentu mająca na celu zmniejszenie liczby zgłoszonych zgłoszeń problemów, wówczas można by ustalić indywidualne cele na podstawie liczby zgłoszeń związanych z oprogramowaniem, którym się opiekują.

Ponieważ tworzenie oprogramowania jest w dużej mierze współpracą, bardziej sensowne byłoby wyznaczanie celów na poziomie zespołu, a następnie ocenianie poszczególnych osób według ich wkładu w zespół.

Cele, które mi się podobają to:

Poproś klienta projektu o N pozytywnych recenzji swojego zaangażowania w projekt.

To pomaga, ponieważ zawsze dobrze jest mieć pisemne pozytywne opinie od klientów (wewnętrznych lub zewnętrznych). Nie jest trudno go zdobyć, jest odpowiedni i jest to łatwy, ale nie bez znaczenia haczyk na liście.

Myślę, że kluczową kwestią jest określenie, jak dostosować rozwój osobisty do realizowanych projektów. Analizowanie siebie przez programistów w celu znalezienia słabych punktów oraz udzielanie informacji zwrotnych na temat innych może być sposobem na znalezienie tego, co można poprawić, a następnie znalezienie sposobu na zmierzenie tego. Na przykład może się okazać, że rzadko dokumentuję ukończone pozycje, więc jeśli chodzi o cele na rok, mogę stwierdzić, że chcę to poprawić, a ilość dokumentacji, którą sporządzam, może być tego miernikiem. To może zadziałać lub przynieść odwrotny skutek, w zależności od tego, jak naprawdę za tym podążam. Z jednej strony mogą istnieć uzasadnione obawy co do tego, w jaki sposób poprawiam swoją pracę i robię to, co może być postrzegane jako właściwy sposób, podczas gdy pasywnym, agresywnym lub dziecięcym widokiem byłoby stworzenie góry dokumentacji, jeśli tak nie jest.

Zdefiniowanie skutecznego programisty to kolejny element tego. Czy to osoba, która najlepiej naprawia błędy? Czy nowy działa najszybciej? Czy nowa praca jest kompletna z testami i dokumentacją, mimo że nie jest wykonywana szybko? Co nazywasz skutecznym, skoro standardowa odpowiedź „to zależy” powinna zostać wyjaśniona w tym miejscu.