仕事で開発をしていると、他の人とコミュニケーションをとりながら進めることが多いと思います。
新しいプロジェクトに入った場合、先輩や周りの人に聞くスキルで仕事の進みが変わります。
整理されてない状態で質問すると、質問される方も何を答えればよいか判断できなく、お互いにやり取りが負担になります。結果、必要なことまで質問できないようになってしまうと更に悪い方向に行ってしまいます。
聞くことのテンプレート
ということで、テンプレートにまとめました。
全くの新規案件でしたら、「動いているもの」はないかもしれませんが、実際、既存の修正などが多いと思うので入れました。
仕様が「まとまってない、メンテされてない」などの事情で使えない場合や、仕様読むよりソースの方が早くて確実などあると思うので、動いているものの確認以降は、ケースバイケースで順番が変わると思います。
# 案件があったら
## 何をやればいいのかを確認
要件はどこにありますか?
## 動いているものを確認(再現)
どのサービスですか?
どこで動いてますか?
ログはどこにありますか?
確認できる環境はありますか?
## 仕様を確認
仕様はどこにありますか?
(信頼性はどの程度ですか?)
## ソースコードを確認
ソースコードはどこにありますか?
(リポジトリの信頼性はどの程度ですか?)
それぞれで、まずは「どこにあるか?」を聞くようにします。
どこにあるかが想像つかない状態だと、相当にロスが発生するためです。どこにあるかわかれば、それを調べて「わかる・わからない」だけです。
対象にたどり着いたら、調べます。
たどり着けなかったか、理解できない場合は、そこでストップして周りの人に聞きます。
「ここまではわかりました。これを調べてますが、わかりません。」と聞くと質問される方もどこまで分かっていてどこまで分かってないのかがわかり、何をどのレベルで答えればいいのか判断できるので答えやすいです。
手書きでもいいので、書いたものを持って行って見せながら言うとさらに確実になります。
全ての質問は、「この話は、誰に聞くのが一番ですか?」を入れて、適切な相手を探すステップを入れると更にいいと思います。
聞く方、聞かれる方お互いにスムーズにコミュニケーションとれるといいですね。
0 件のコメント:
コメントを投稿