ユーザー名非公開
回答3件
コミュニケーションは相手があるものですし、具体的な状況は個々で違うものだとは思います・・という前置きは必要そうです。 ワインバーグの「プログラミングの心理学」で取り上げられた問題ですが、一般的なマネジメントが想定している従業員は工場のラインに機械と同様に並べられてるような扱い方ですし、心理学も精神を病んだ人だとか脳を損傷した人だとかを日常生活に支障なくするぐらいを目的としたものだったりします。 でも、頭脳労働者のエンジニアは賢くてプライドが高く、多少マネージャーが態度を変えても、どんどん対応してきてしまうタフな存在なわけで、理解のために人を単純化して見てしまう理論は意味がないです。 私のPMのやりかたを書いておきますね。 ブリーフィングで仕事で実現したい目標と、作戦と役割を与えて走り始めたら、指示しないですし、内部の会議もやらないです。進捗は自分で個々のメンバーの席に行って、見通しや課題を聞きます。進捗2割ぐらいで最後が間に合うかは教えてよ、とは言います。 午前中の1時間以外は作業場所にはいませんし、飲みにも行きません。 ・・つまりコミュニケーションとしては、かなりドライでして、悩む要素ないって感じなのですが、そういうのは、個々の性格による部分が多いかと思います。
「苦労しないコミュニケーション」「円滑に仕事が進む状況」ってどういうものを想像していますか？まず、その自分の中での理想形をイメージしてみると、考えるポイントが増えるかと思います。上の方も仰ってますが、状況により異なるので、一概に言えないと思いますので。 あくまで参考レベルですが、私が考える時の内容を話します。 もし、メンバーが情報を共有してくれなくて困るという話なら、「メンバーが情報を共有したい」と感じるように動きを進めます。例えば、全体としての課題が共有されたら、見過ごさずになんとか対応します。対応が難しいなら、やってみたけど難しいという話も共有します。これだけで、そこそこ課題はあがってくるようになります。（自分が伝えた課題に対応してくれるなら、課題は伝えたほうがいいと感じると思うので。）そして、難しい課題が解決されたり、課題解決のスピードが速かったりすると、全体の状況や課題の報告は、もっとスムーズになります。（だって、課題を伝えて解決してくれるなら伝えたほうが楽ですし、自分たちの状況を考慮しない形で解決されると困るので、状況を伝えたくなると思いますので。） あとは、技術的な課題は「すいません。知っていたらでいいんですが、〇〇について教えてくれませんか？」みたいな感じで聞きます。細かい話ですが、「〇〇について教えてくれませんか？」と聞くと、知らなかったりすると、「調査中です」という返答が来てよくわからなくなるので、「今の所、知ってる話だけ教えて欲しい、そもそも自分は知識がない」というスタンスは示してます。 私のやり方がいいのか悪いのかわかりませんが、参考までに。
エンジニアをやっています。 ぼくの場合はですが、なるべくコミュニケーションを取らなくても仕事が進むタイプの人と組むとすごい楽に感じます。 コミュニケーションをいちいち取るくらいだったら作ったほうが早いみたいな気持ちになってしまいます。逆にエンジニアとのコミュニケーションは密にとりたいです。 仕様が変わるならなるべく早く伝える、期日が守れるかだけハンドリングするって感じで充分だと思います。
ユーザー名非公開
ユーザー名非公開
09000ghk
ユーザー名非公開
ユーザー名非公開
ユーザー名非公開
ユーザー名非公開
jobq2444521
ユーザー名非公開
ユーザー名非公開
Googleで登録して続きをみる
LINEで登録して続きをみる
