質問:
誰かの仕事をやる気をなくさせることなく、どのように批判/フィードバックを与えるのですか?
Lucas Kauffman
2012-04-11 02:09:02 UTC
view on stackexchange narkive permalink

誰かの仕事をやる気をなくさせることなく、どのように批判/フィードバックしますか?

誰かの仕事をレビューする必要がある場合、彼らが悪い仕事をしたときに彼らの意欲を削ぐのをどのように防ぎますか?

私の答え-再投稿しない-http://programmers.stackexchange.com/a/131749/39294
関連する質問(重複ではありません):[メンバーの1人が批評を受け入れないチームに対処する方法](http://workplace.stackexchange.com/q/6409/316)
セブン 答え:
#1
+16
John N
2012-04-11 02:13:51 UTC
view on stackexchange narkive permalink

率直に、正直に、失敗を罰するのではなく、間違いから学ぶことを重視する文化の中で。

それがなければ、それは非常に困難です。

間違いから学ぶことについての文化のための大きな+1。誰かが引き受けることができる、そして引き受けたいと思う責任と説明責任の量と、プロジェクト/仕事/ビジネスを危険にさらすことなく安全に与えることができる量との間にはバランスがあります。そのバランスを取り、ロープをかけずに成長するのに十分なスペースを人々に与えてください。次に、途中で定期的にフィードバックを提供します。
#2
+13
Nicole
2012-04-11 02:12:54 UTC
view on stackexchange narkive permalink

教師はどのようにそれを行いますか?

  • 良い点を見つけて、それらについて話します。
  • 質問して彼らの理解を深めます考えます。
  • 次に、正しい答えにつながる質問をします。

結局のところ、問題とより良い解決策の間に点を結ぶことができない場合は、 、その後、彼らはプロセスから何も学ぶつもりはありません。したがって、問題を自分で解決できるように支援する必要があります。

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

人ではなく仕事に集中する。とはいえ、正しく理解するのは非常に困難です。

あなたが望んでいるのは、人が何らかの方法で行動を変えることです。そのことに集中して、既存の行動は問題であり、それを改善するために何ができるかです。これにより、(うまくいけば)人と問題の間に感情的な距離が生まれ、それが個人的なものではないことがわかり、解決策に集中できるようになります。

これは一般的には良い考えです。これは、[Principled Negotiation](http://en.wikipedia.org/wiki/Principled_negotiation)の最初のポイントです。原則交渉のもう1つのポイント、つまり客観的な基準を使用することは、職務遂行能力に関する議論にも容易に適用できます。
#4
+4
HLGEM
2012-04-11 03:34:49 UTC
view on stackexchange narkive permalink

誰かがうまくいっていないとき、あなたが彼らのためにできる最善のことは、何が間違っているのか、そして何を修正する必要があるのか​​を彼らに伝えることです。彼らの後ろで物事を直さないでください(彼らは彼らがすることが受け入れられないことを決して知りません)、すべてがうまくいくふりをしないでください。問題について正直に話し、解決策を求めますが、必要に応じて必要な解決策を示します。

嫌なことや個人的に攻撃する必要はありませんが、何が受け入れられ、何が受け入れられないかについて明確な期待を設定する必要があります。私にはかつて2人の従業員がいて、一方を昇進させ、もう一方を昇進させなかったので、彼女と一緒に座って、その昇進を得るために彼女が何をする必要があるかを正確に伝えなければなりませんでした。彼女には、改善が必要なことの具体的なリストがあり、シニアになる前に達成できることを私に示さなければなりませんでした。彼女は自分が満たす必要のある基準を知っていたので、最終的にその昇進を得ました。彼女がその基準を満たしたらすぐに私が彼女を昇進させます。それらの会話は難しいです、彼らはマネージャーにとって楽しいものではありません、しかしあなたがそれらの会話をする気がない限りあなたはうまく管理することができません。

ソフトウェア開発の世界では、コードレビューから始めるのがよいでしょう。あなたはその人を攻撃しているのではなく、コードが何をするのか、そしてそれをどのように改善できるのかを見ているだけです。開発者に自分がコードを所有していると思わせず、他の誰もそれを見たり触れたりしてはならないようにすることもコードレビューの一部であり、ソフトウェアショップで行うことがさらに重要になります。そして、パフォーマンスの悪い人をレビューするだけでなく、全員がコードをレビューした場合、批判はより良くなります。

ソフトウェア以外の世界では、特にその人が新しい人や非常に若い人の場合は、時間をかけて定期的に誰かの仕事をチェックすることもできます。彼らがあなたのために働いた最初の数週間で問題を見つけるのは、彼らが1年間そのようにやっていて、あなたが何も言わなかった後に長年の問題に腹を立てるよりも簡単です。

必要に応じて肯定的なフィードバックを提供します。特定の関心領域に改善が見られる場合は、その人があなたが気づいたことを知っていることを確認してください。

そして公平に。ある人にすべての賞賛を、別の人にすべての批判を留保しないでください。

そして公に批判しないでください。賞賛は公の場で行われますが、批判は私的な場で行われます。

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

彼らにすべての良い点を示してから、悪い点を説明し、彼らの仕事を批判します。

次に、それらを改善する方法について率直かつ率直に話し合います。あなたが問題について話し合うことにオープンであり、決してひいきにしないことを示してください(これが最も害があると思います)。

これは、否定的な行動についてのフィードバックを与えるなど、他の状況にも当てはまります。

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

これらの答えはすべて素晴らしいです。しかし、それらはすべて非常に明白なものを見逃しています。あなたの人々を知ってください!

あなたがあなたの直属の部下を知っているなら..そして私は仕事に関係のないことを意味します..そうすればあなたはこの状況に取り組む方法を知るでしょう。

現在のポジションでは、24の直属の部下がいますが、他の4人のマネージャーと協力して、セクション全体を管理しています(それぞれ約24の直属の部下がいます)。ご想像のとおり、一人一人が個人です。私は、Xさんと一緒に彼のところまで歩いて行き、「Xさん、あなたの仕事はそれをカットしていません。それを手に取ってください」と直接彼に言うことができることを知っています。 Yさん「ねえ、Yさん、あなたの仕事はそれをカットしていません。これは私たちが期待するものに到達するためにあなたがすべきことです。」と私は言うことができます。しかし、私はまた、人Zのカテゴリーに属するいくつかを持っています。彼らが正しくやっていない一つのことを議論するために、私は彼らがしているすべての良いことを彼らに話さなければなりません。他の方法で、彼らはそれを個人的に受け止めます。

あなたがしばらく管理している人なら、今では彼らを知っているはずです。それらが初めての場合は、サンドイッチ法を使用する必要があります。私はこの方法を数年使用していますが、平均的な人に最適であることがわかりました。つまり、あなたは良いものを2つ見つけ、その人に改善してもらいたいものを1つ見つけます。あなたはその改善を2つの良いものの間に挟みます。そうすれば、会議を上手く始め、会議が実際に話しているトピックにぶつかり、それからそれを良いもので終わらせることができます。

私が学んだ最大のことは、一度に1つの欠陥に集中することです。 。要件を達成することで、測定可能な目標を設定します。必要な場所に配置する時間を設定します。現実的であることを確認してください。

もちろん、あなたが彼らのマネージャーでないなら、これはすべて議論の余地があります。その場合の最善の方法はサンドイッチ法です。しかし、あなたは彼らがあなたのフィードバックを望んでいることを確認したいです。多くの人は、仲間からこの種のことについて聞くのが好きではありません。その人がこのタイプであることがわかっている場合は、上司と話し合うのが最善の方法です。

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

2つの質問:

  1. 失敗したことを知っている必要がありますか?

  2. 失敗したことを知っていますか?

  3. ol>

    [はい、いいえ]:お尻で(激しく)蹴ります。

    [いいえ、はい]:エラーを認めますが、ユーモアのセンスがあります

    [いいえ、いいえ]:時間をかけて新人にロープを見せ、問題の性質を指摘します。

    [はい、はい]:「わかりました。どうしたの?」



このQ&Aは英語から自動的に翻訳されました。オリジナルのコンテンツはstackexchangeで入手できます。これは、配布されているcc by-sa 3.0ライセンスに感謝します。
Loading...