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


84

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:


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ę!


16
Wolę metodologię DUMB: „Do Ur Most Best”.
Robert S.

3
Wiele zepsutych linków.
crh225

Linki są zerwane
Rodrigo Leite

Odpowiedzi:


21

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

Dzięki, podoba mi się to. Kiedy przeglądam ich kod, zwykle jestem dość analityczny, jeśli chodzi o nie tak pilne, ale na dłuższą metę ważne rzeczy, takie jak nazewnictwo zmiennych i styl kodu. Taki cel może zachęcić ich do szybszego myślenia zgodnie z moimi wytycznymi!
Paul Stephenson,

6
Też mi się to podoba, ale może to prowadzić do mrugającego schematu rozwoju, w którym każdy stara się zadowolić CIEBIE kosztem obiektywnie najlepszego kodu. Ile błędów we własnym podejściu naprawiłeś przez lata, ile według ciebie pozostało do naprawienia?
Ed Guiness,

1
Dla mnie nazewnictwo zmiennych i styl kodu należą do drugiej kategorii; z wyjątkiem sytuacji, gdy styl jest naprawdę zły, np. ponowne użycie jednej zmiennej do zbyt wielu różnych celów, mogę powiedzieć: „Będziesz musiał to przerobić, ponieważ jest to dla mnie zbyt skomplikowane, aby to sprawdzić, nie mogę sprawdzić„ przez sprawdzenie ”, czy jest poprawny” .
ChrisW,

Heh, oczywiście wiem, co jest obiektywnie najlepsze :-). Ale tak, mogą spędzać czas na zaspokajaniu moich szalonych dziwactw, zamiast robić bardziej przydatne rzeczy. Myślę, że działałoby to lepiej dla nowszych programistów niż doświadczonych starych rąk.
Paul Stephenson,

@edg: to prawda, jeśli chodzi o „migotanie” i „próby zadowolenia mnie”, ale ich kod oczywiście również musiał przejść testy systemu czarnej skrzynki QA. A mój oceniając, czy ja mógł utrzymać swój kod, jeśli konieczne jest całkiem obiektywna (nie tylko subiektywna) miara, prawda?
ChrisW,

14

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.


9

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.


1
Zasadniczo jestem liderem zespołu i biorę udział w codziennym planowaniu i rozwoju. Uważam też, że poziom wydajności każdego dewelopera jest „oczywisty”, ale to moja subiektywna opinia i nie pasuje do celów, więc stają się bezcelowe. Wolałbym, żebyśmy mogli je całkowicie zignorować!
Paul Stephenson

Chodzi o to, że nie można tu uzyskać żadnego naukowego pomiaru, więc próba zrobienia tego jest skazana na porażkę i powinieneś spędzać czas gdzie indziej imo. artykuł martinfowler.com/bliki/CannotMeasureProductivity.html zawiera artykuł na ten temat.
Martin Wickman

8

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?


1
Wszystko oprócz zepsucia kompilacji to moje podejście 1: zdarza się, że dobrzy programiści mówią „byłem zbyt zajęty wykonywaniem tego krytycznego projektu, nad którym mnie poprosiłeś, więc nie zrobiłem prezentacji ani nie napisałem artykułu”. Nie mogę ich za to karać, więc cele stają się bez znaczenia.
Paul Stephenson

1
tak samo jak Paul powiedział, i miałbym problem z czymś tak efemerycznym jak pisanie artykułów na wiki - czy były dobre? czy nadal tam są? a co z edytowaniem wkładów? czy mieli na to w ogóle czas?
annakata

8

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? ;-)


3
+1 za humor: Zastanawiałem się, czy to niejednoznaczne, ale zdecydowałem tylko wtedy, gdy celowo źle zrozumiałeś :-)
Paul Stephenson

2
Zauważ, że ktoś zmienił tytuł na „mimo że (cele) nie działają”. Od tego czasu zaostrzyłem to tylko do „nawet jeśli cele nie działają”. Po prostu dodam komentarz dla każdego, kto jest zdezorientowany tą odpowiedzią!
Paul Stephenson

7

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


1
Zdefiniuj „ćwiczone”. Jeśli używasz tylko narzędzi pokrycia, łatwo jest uzyskać kod do wykonania bez faktycznego ćwiczenia.
Kent Boogaart

@Kent, miałem na myśli ćwiczenie == wykonaj. Czy mógłbyś rozwinąć, dlaczego wykonywanie nie jest ćwiczeniem, a ja z przyjemnością zaktualizuję moją sugestię
Ed Guiness,

Pewnie. Po prostu napisz test jednostkowy, który wywołuje twoją metodę, ale nie robi żadnych potwierdzeń dotyczących wyników wywołania. Wykonałeś kod - uzyskując w ten sposób większe pokrycie kodu - bez faktycznego udowodnienia, że ​​jest funkcjonalnie poprawny.
Kent Boogaart

Dzięki, coś takiego może być wykonalne, ponieważ testy jednostkowe staną się integralną częścią ich prac rozwojowych i konserwacyjnych. Jednak mogą wystąpić problemy z pisaniem bezwartościowych testów jednostkowych, aby osiągnąć cel, gdy mogą wykonywać bardziej użyteczną pracę.
Paul Stephenson,

Zgadzam się, prawdopodobnie zawsze będzie sposób na wyegzekwowanie jakiegokolwiek konkretnego pomiaru, co w pewnym sensie wzmacnia punkt widzenia PO.
Ed Guiness,

4

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


3

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.


2

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ół.


1
+1 za wyznaczanie celów tylko na poziomie drużyny. Przypięcie każdego zgłoszenia powodującego problem jest demotywujące, niszczy ducha zespołu i często daje wypaczony i niedokładny pomiar prawdziwej sytuacji, zwłaszcza jeśli liczba prawdopodobnych zgłoszeń problemowych jest dość niska (np. Około jednego na programistę).
Paul Stephenson,

1

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.


A jeśli pracujesz przez cały rok nad jednym projektem, który nie został wysłany do klientów? 0 opinii. A co, jeśli pracujesz na ogólnej stronie internetowej bez ustalonej listy klientów?
jmucchiello

1
W obu przypadkach nadal pracujesz nad projektem, który ma klientów wewnętrznych lub nie. Starasz się o przegląd swojego zaangażowania z klientem, a nie przegląd projektu.
Nat,

1

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.

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.