Vraag:
Hoe bekritiseer / geef je feedback op iemands werk zonder hem / haar te demotiveren?
Lucas Kauffman
2012-04-11 02:09:02 UTC
view on stackexchange narkive permalink

Hoe bekritiseer je / geef je feedback op iemands werk zonder hem / haar te demotiveren?

Als je iemands werk moet herzien, hoe voorkom je dan dat je hem / haar demotiveert als hij of zij slecht werk levert?

Mijn antwoord - niet opnieuw plaatsen - http://programmers.stackexchange.com/a/131749/39294
Gerelateerde vraag (maar niet dubbel): [Hoe om te gaan met een team waarin een van de leden geen kritiek accepteert?] (Http://workplace.stackexchange.com/q/6409/316)
Zeven antwoorden:
#1
+16
John N
2012-04-11 02:13:51 UTC
view on stackexchange narkive permalink

Openlijk, eerlijk en in een cultuur die het leren van fouten benadrukt in plaats van het afstraffen van mislukkingen.

Zonder dat is het heel erg moeilijk.

Grote +1 voor een cultuur die draait om leren van fouten. Er is een evenwicht tussen hoeveel verantwoordelijkheid en aansprakelijkheid iemand kan en wil nemen, en hoeveel u hem veilig kunt geven zonder projecten / werk / zaken in gevaar te brengen. Probeer dat evenwicht te vinden, en geef mensen genoeg ruimte om te groeien zonder zoveel touw dat ze zichzelf ophangen. Geef ze dan regelmatig feedback.
#2
+13
Nicole
2012-04-11 02:12:54 UTC
view on stackexchange narkive permalink

Hoe zou een leraar het doen?

  • Vind de positieve punten en praat erover.
  • Stel vragen zodat je hun denken.
  • Stel vervolgens vragen die hen naar het juiste antwoord leiden.

Immers, als je de punten tussen het probleem en een betere oplossing niet kunt verbinden , dan leren ze niets van het proces. Dus je moet ze helpen het probleem zelf op te lossen.

#3
+9
ChrisF
2012-04-11 03:11:01 UTC
view on stackexchange narkive permalink

Concentreer je op het werk, niet op de persoon. Dat gezegd hebbende, het is is erg moeilijk om het goed te krijgen.

Wat je wilt is dat de persoon zijn gedrag op de een of andere manier verandert, dus concentreer je daarop en leg uit waarom de bestaande gedrag is een probleem en wat kan er worden gedaan om dat te verbeteren. Dit zou (hopelijk) enige emotionele afstand moeten creëren tussen de persoon en het probleem, zodat ze kunnen zien dat het niet persoonlijk is en ze zich kunnen concentreren op de oplossing.

Dit is over het algemeen een goed idee. Het is het eerste punt in [Principled Negotiation] (http://en.wikipedia.org/wiki/Principled_negotiation). Een ander punt uit Principled Negotiation - gebruik objectieve criteria - kan ook gemakkelijk worden toegepast in discussies over werkprestaties.
#4
+4
HLGEM
2012-04-11 03:34:49 UTC
view on stackexchange narkive permalink

Als het met iemand niet goed gaat, kunt u hem het beste vertellen wat er aan de hand is en wat moet worden opgelost. Repareer dingen niet achter hun rug (ze zullen nooit weten dat wat ze doen onaanvaardbaar is), doe niet alsof alles in orde is. Wees eerlijk over het probleem, vraag hen om oplossingen, maar wijs hen desnoods op de oplossing die u wilt.

Je hoeft niet gemeen te zijn of ze persoonlijk aan te vallen, maar je moet duidelijke verwachtingen stellen over wat acceptabel is en wat niet. Ik had ooit twee werknemers en ik promoveerde de ene en promootte de andere niet en ik moest met haar om de tafel gaan zitten en haar precies vertellen wat ze moest doen om die promotie te krijgen. Ze had een specifieke lijst met dingen die verbeterd moesten worden en die ze me moest laten zien dat ze kon bereiken voordat ze een senior werd. Ze kreeg uiteindelijk die promotie omdat ze wist aan welke norm ze moest voldoen en dat ik haar zou promoten zodra ze aan die norm had voldaan. Die gesprekken zijn moeilijk, ze zijn niet leuk voor de manager, maar je redt het pas goed als je bereid bent om die gesprekken te voeren.

In de wereld van softwareontwikkeling zijn codebeoordelingen een goede plek om te beginnen. U valt de persoon niet aan, u ziet alleen wat de code doet en hoe deze kan worden verbeterd. De ontwikkelaars laten denken dat ze niet de eigenaar zijn van de code en dat niemand anders deze mag zien of aanraken, is ook een onderdeel van de codereview, waardoor het nog belangrijker is om dit in een softwarewinkel te doen. En bekijk niet alleen de slechtere presteerders, als iedereen de code heeft herzien, dan wordt de kritiek beter opgevangen.

In de niet-softwarewereld kunt u ook de tijd nemen om regelmatig iemands werk te controleren, vooral als die persoon nieuw of zeer junior is. Het is gemakkelijker om een ​​probleem op te vangen in de eerste weken dat ze voor je werken, dan om boos te worden over een al lang bestaand probleem nadat ze het een jaar lang op die manier hebben gedaan en je nooit iets hebt gezegd.

Geef positieve feedback wanneer dit gerechtvaardigd is. Als je verbetering ziet in een specifiek aandachtsgebied, zorg er dan voor dat de persoon weet dat je het hebt opgemerkt.

En wees eerlijk. Bewaar niet al uw lof voor één persoon en al uw kritiek voor een ander.

En bekritiseer niet in het openbaar. Lof wordt gegeven in het openbaar, maar kritiek wordt privé gegeven.

#5
+2
Renan
2012-04-11 02:35:41 UTC
view on stackexchange narkive permalink

Laat ze al hun positieve kanten zien, leg ze vervolgens de negatieven uit / bekritiseer hun werk.

Bespreek vervolgens open en eerlijk hoe u deze kunt verbeteren. Laat zien dat je openstaat voor het bespreken van kwesties en wees nooit betuttelend (ik vind dat dit het meest kwetsende is).

Dit kan van toepassing zijn op andere situaties, zoals feedback geven over negatief gedrag.

#6
+2
Randy E
2013-02-22 21:40:45 UTC
view on stackexchange narkive permalink

Al deze antwoorden zijn geweldig. Maar ze missen allemaal een heel duidelijke. Ken uw mensen!

Als u uw directe ondergeschikten kent ... en dan bedoel ik niet-werkgerelateerde zaken ... dan weet u hoe u deze situatie moet aanpakken.

Met mijn huidige functie heb ik 24 directe ondergeschikten, maar werk zij aan zij met 4 andere managers om een ​​hele sectie te beheren (elk met ongeveer 24 directe ondergeschikten). Zoals je kunt raden, is elke persoon een individu. Ik weet dat ik met persoon X naar hem toe kan lopen en direct tegen hem kan zeggen: "Hé X, je werk is het niet snijden. Raap het op." Persoon Y Ik kan zeggen "hey, Y, je werk is niet voldoende. Dit is wat je moet doen om te bereiken wat we verwachten." Maar ik heb er ook een paar die onder de categorie van persoon Z vallen. Ik moet ze alle goede dingen vertellen die ze doen om te bespreken wat ze niet goed doen. Elke andere manier en ze nemen het persoonlijk op.

Als het een persoon is die u al een tijdje beheert, zou u die nu al moeten kennen. Als ze nieuw voor je zijn, moet je de sandwich-methode gebruiken. Ik gebruik deze methode nu een paar jaar en ik merk dat deze het beste werkt voor de gemiddelde persoon. Dat wil zeggen, je vindt twee dingen die goed zijn en één ding waarvan je wilt dat de persoon verbetert. Je plaatst die verbetering tussen de twee goede dingen. Op die manier begin je de bijeenkomst goed, raak je het onderwerp aan waar de bijeenkomst eigenlijk over gaat, en eindig je het met iets goeds.

Het grootste dat ik heb geleerd, is me concentreren op één tekortkoming tegelijk . Stel meetbare doelen om ze aan de vereisten te laten voldoen. Stel een tijd in waarop ze moeten zijn waar ze moeten zijn. Zorg ervoor dat het realistisch is.

Natuurlijk, als je niet hun manager bent, dan is dit allemaal betwistbaar. Het beste wat je dan kunt doen is de sandwich-methode. Maar u wilt zeker weten dat ze uw feedback willen. Veel mensen horen niet graag over dit soort dingen van hun leeftijdsgenoten. Als u weet dat die persoon dit type is, kunt u dit het beste met zijn manager bespreken.

#7
+1
Erik Reppen
2012-05-17 09:16:26 UTC
view on stackexchange narkive permalink

Twee vragen:

  1. MOETEN ze weten dat ze het verprutst hebben?

  2. WETEN ze dat ze het verprutst hebben?

[ja, nee]: schop ze (hard) in de reet.

[nee, ja]: erken de fout maar heb gevoel voor humor over het.

[nee, nee]: neem de tijd om de rookie de kneepjes van het vak te laten zien en wijs de aard van het probleem aan.

[ja, ja]: "Oké, dus wat is er gebeurd? "



Deze Q&A is automatisch vertaald vanuit de Engelse taal.De originele inhoud is beschikbaar op stackexchange, waarvoor we bedanken voor de cc by-sa 3.0-licentie waaronder het wordt gedistribueerd.
Loading...