Po prostu zastanawiam się na głos - my programiści uwielbiamy te wszystkie elementy głosowania / odznak / rep., Aby taki program mógł zostać wprowadzony do procesu przeglądu kodu firmy, aby zachęcić do lepszego kodowania.
Coś jak
Ty (lub inne osoby w Twoim imieniu) możesz opublikować recenzję (może to być fragment, pojedyncze zatwierdzenie lub seria) do przeglądu kodu
Inni mogą komentować (byłoby podobne do odpowiedzi w SE)
Można podać / zasugerować odznaki (niektóre byłyby dobre, niektóre byłyby złe, jak „Komentarz Pustynia” lub inne)
Możesz głosować w górę / w dół na sam kod oraz komentarze i odznaki (np. Jeśli ktoś zasugerował odznakę, a ty się zgodziłeś / nie wyraziłeś zgody)
Cel takiego schematu byłby następujący
Wprowadź trochę zabawy, aby zachęcić do korzystania z recenzji kodu
Popraw jakość (w tym schemacie zarówno osoby sprawdzające kod, jak i recenzenci prawdopodobnie się nauczą)
Zmniejsz szansę, że recenzje kodu wywołają „wojny ego”
Podaj kilka wskaźników, które pomogą zmierzyć skuteczność poszczególnych osób
Czy to może zadziałać? Myśli?
Odpowiedzi:
Nagroda zewnętrzna, taka jak pieniądze, odznaki lub przedstawiciel, będzie działać krótko , podobnie jak diety i każdy inny system oparty na nagrodach / karach.
Zamiast tego należy zastosować nagrodę wewnętrzną , taką jak cel i autonomia, która zapewni więcej długoterminowych rezultatów. W praktyce jest to o wiele trudniejsze niż proste zewnętrzne systemy nagród, ale to się opłaca.
Wielu ekspertów przeprowadziło badania na ten temat. Oto moje dwie ulubione:
Daniel Pink dokonał na TED świetnej prezentacji na ten temat, który jest łatwy do obejrzenia i zrozumienia.
Alfie Kohn , autorka książki „ Punished by Rewards” , napisała na ten temat:
Innym problemem związanym z nagrodami (i karami) jest to, że zmieni to zachowanie ludzi. Na przykład, jeśli dasz premię swojemu pracownikowi, będzie on koncentrował się na uzyskaniu tych premii, niezależnie od innych celów (dla całej firmy). Stworzy indywidualizm i konkurencję między działami i pracownikami. Nastąpi uraza i wszyscy będą obserwować wszystkich. Zwłaszcza, gdy jednym z twoich celów jest „pomoc w pomiarze indywidualnych wyników”.
Reszta pracownika może obalić zasady gry i zrezygnować. Zwiększony obrót stanie się nowym problemem.
Pamiętaj, że w tej społeczności pojawiło się wiele sugestii dotyczących poprawy motywacji .
źródło
Tak, może
Ale tylko wtedy, gdy zaprojektujesz go bardzo ostrożnie, w przeciwnym razie może się nie udać. Skomentowałem, ale pomyślałem, że podsumuję swoje stanowisko
W przypadku reputacji głównym celem powinno być zapewnienie pomiaru, za pomocą którego pracownicy będą mogli śledzić doskonalenie swoich umiejętności w czasie. Zaprojektuj to bardzo starannie, mając na uwadze, że trudno wymyślić dobre sposoby mierzenia umiejętności, nie mogę tego zrobić z góry.
Odznaki są głównie „zabawne”, trzymałbym je głównie z dala od problemów zorientowanych na umiejętności. Tj. Odznaki takie jak „sowa z tego tygodnia” lub grupa „Odznaka wysłana!” Byłyby w porządku. Jeśli masz jakieś odznaki oparte na umiejętnościach, takie jak „Naprawiono większość błędów” lub „Zgłoszono większość błędów”, zastanów się, jak można to postrzegać i grać. Odznaki powinny bardziej podkreślać zachowanie niż promować je IMO. Pamiętaj, aby mieć zarówno odznaki zespołowe, jak i indywidualne.
Zdecydowanie odradzam negatywne plakietki, te rzeczy powinny być zabawne, a obawa przed popełnianiem błędów jest niebezpieczna. Zamiast tego wygeneruj przyjazny, pomocny e-mail.
Zdecydowanie odradzam pozwalanie im na podejmowanie decyzji i głosowanie w sprawie odznak. Ludzie mogą wysyłać swoje sugestie dotyczące odznak, ale ponieważ ich wpływ na ludzi może być dość poważny, to, jakie odznaki są używane, należy podejmować ostrożną decyzją osoby, która wie, co robią, a nie większością głosów.
Przeglądy kodu to ciekawy pomysł i chyba jeden ze sposobów na wygenerowanie wartości umiejętności. Podkreślanie kodu i omawianie go może być naprawdę pomocne. Może to jednak przynieść skutki odwrotne, jeśli wszyscy wiedzą, że oceniają potencjalnie wszystko, co piszą, rozwój może spowolnić. Zwłaszcza w przypadku iteracyjnego rozwoju, w którym czasami piszesz coś szybko, a następnie refaktoryzujesz, że nie chcesz tego zachowania.
Być może może to zostać zrekompensowane przez osobę, która sama przesyła kod, lub przez osobę, która jest w stanie przesłać kod w określonym wieku. Niemniej jednak wiedza o tym, jakie będą skutki, może być trudna
W końcu myślę, że będziesz musiał spróbować i zobaczyć, co działa, a co nie, jest dobra książka o nazwie Reality is broken, która może być interesująca. Trzeba też przeczytać książkę Dyska Pinksa „Drive”.
źródło
Moim zdaniem NIE , ponieważ mierzy nie samą dobrą praktykę, ale objaw (jeśli inni uważają ją za dobrą praktykę).
Parafrazując książkę wuja Boba (zapomniałem tytułu): Dobry kod wydaje się prawie łatwy, sprawia, że problem wygląda na trywialny, jakby język został napisany.
Z mojego doświadczenia wynika, że taki kod pozostaje niezauważony i dopiero po długim czasie zwraca się uwagę, że ten kod nigdy nie powodował problemów, a być może pamięta się, że przed wprowadzeniem kodu problemem był ogromny bałagan niepewności i niejasność. Kod, który jest chwalony w recenzjach, jest zwykle tym, na który recenzenci patrzą w dobry dzień, kiedy nie ma ochoty na wyłudzanie, i który ma najmniej zmian.
źródło
Pomysł wprowadziłby nową dynamikę do zespołu. Jeśli uważasz, że zespół jest w rutynie, to jest dobry sposób, aby wstrząsnąć.
Pamiętaj tylko, że nie będą to wszystkie jednorożce i tęcze. Niektórym nie spodoba się ta inicjatywa, więc ogólna wydajność / jakość może ucierpieć. Jednak ryzyko to może być tego warte. Zależy od twojej sytuacji.
źródło
Sugeruję stosowanie motywacji zewnętrznej (to, co proponujesz, jest formą motywacji zewnętrznej), aby motywować ludzi do robienia rzeczy „mechanicznych”, powtarzalnych i nudnych, takich jak:
Nie użyłbym tego do motywacji w pracy wymagającej kreatywności lub w przypadku których nie można obiektywnie zmierzyć jakości. Na przykład, jeśli masz osobę tworzącą widżety i możesz mechanicznie zweryfikować, czy część jest dobra, czy zła, a masz proces, który nie pozwoli na wykonanie części, chyba że będzie zgodny z zatwierdzonym procesem, motywowanie motywacji jest produktywne pracownik z dodatkowymi nagrodami za produktywność, ponieważ proces nie pozwoli im na skorzystanie ze skrótów, aby wytworzyć więcej jednostek kosztem jakości.
Jeśli nie masz tych zabezpieczeń, to próba motywacji zewnętrznej z pewnością przyniesie skutek. Programowanie należy do tej kategorii - po prostu nie możemy wiarygodnie zmierzyć jakości oprogramowania. Dzieje się tak, ponieważ po utworzeniu widgetu opuszcza on fabrykę i nie wpływa na pracę wykonywaną przy następnym widżecie, ale podczas tworzenia oprogramowania należy go przerabiać w kółko. Rzeczy, które teraz robisz, mają długofalowe efekty. Te długoterminowe efekty są bardzo ważne, ale nie można ich zmierzyć. Motywacja wewnętrzna jest znacznie bardziej użytecznym czynnikiem motywującym do tego rodzaju rzeczy.
To znaczy:
źródło
Częścią tego, co czyni tę pracę, jest duża liczba uczestników, którzy się nie znają lub muszą codziennie ze sobą współpracować. Pomyślałbym, że w małej grupie stałby się bardziej sposobem na grę w system, aby wyglądać dobrze lub sprawić, że twoja konkurencja o promocję wygląda źle. Dlatego formalne oceny wzajemne są często złym systemem. W małej grupie najlepszymi przedstawicielami będą ci, którzy są najbardziej sprytni politycznie, a nie najlepsi programiści.
źródło
Krótka odpowiedź brzmi: tak, może zadziałać.
Nieco dłuższa odpowiedź brzmi: tak, może zadziałać, ale może również przynieść odwrót.
Oprócz tego, że jestem profesjonalnym programistą, jestem również amatorskim analitykiem zachowań.
Jednym z charakterystycznych ustaleń współczesnej nauki behawioralnej jest to, że na jej zachowanie wpływ mają jego konsekwencje.
Jeśli kontrolujesz konsekwencje, możesz w pewnym stopniu wpływać na zachowanie. Stopień zależy od tego, jak ważne są konkretne konsekwencje dla każdej osoby, której zachowanie próbujesz zmienić, oraz od tego, jak łatwo jest jej uniknąć konsekwencji i znaleźć innych, dla których są gotowi pracować.
Jako profesjonalny programista jedną z konsekwencji pisania kodu jest to, że dostaję wynagrodzenie; przestań mi płacić, a wkrótce przestanę się pojawiać. Wynagrodzenie jest dla mnie naprawdę ważną konsekwencją (zakładam rodzinę) i w mojej obecnej firmie nie ma żadnych innych konsekwencji, dla których byłbym skłonny pracować zamiast otrzymywać wynagrodzenie.
Gdybyś był moim szefem, musiałbyś zdecydować, jakie konsekwencje (zachęty, posiłki) mi zaoferować. Ale nie decydujesz, jak je postrzegam. Na przykład mój szef może zdecydować się zaoferować specjalne miejsce parkingowe, jeśli zostanę wybrany jako „Koder miesiąca”. Gdybym mieszkał w San Francisco lub Nowym Jorku i prowadziłem samochód, być może byłbym skłonny do tego pracować. Ale tam, gdzie teraz mieszkam, parkowanie nie stanowi problemu i i tak mogę iść do pracy.
Z mojego doświadczenia wynika, że największym ryzykiem związanym z wdrażaniem programu takiego jak SO w miejscu pracy jest to, że możesz być postrzegany jako oferujący głosy rówieśnicze zamiast płacenia ludziom za to, co są warte.
źródło