１週間前に、機能担当として現状のチームの作業プロセスを改善しようとしました。
そして、今週に別の観点で更に思った形でチームを導きました。
やり方は前職の経験であって、今回のプロジェクトにも適応できることを実感しました。
僕は以前開発者として富士通の会社で７年ほど勤めました。
ですので、普通の開発作業についてはもちろん問題はありません。手を動かす能力があります。
そして、直近の前職は今とほぼ同じ、ブリッジSEとして働きました。
その時、チームメンバーから絶大な信頼を得て、顧客とも非常に仲良く、順調に3年間を過ごしました。
一方、この仕事がうまくできるように二つの注意点、教訓を学びました。
その一つを紹介します。
それは、作業内容の期待値について、自分は曖昧のままで依頼した場合、良い結果が得られないことです。
極普通のことですが、うまくコントロールできなければ、結果として苦労することが多いようです。
チームリーダーの場合、細かい仕事を開発メンバーに依頼するのがほとんどです。
しかしだからと言って、自分は分からないまま丸投げできるとは大間違いです。
僕は観察した周りの失敗の例、大体のパターンはリーダーがきちんとした各タスクへの期待値を自分が描けないまま、作業を他人に依頼し、その結果だけを待つケースです。
自分が分からなければ、はっきりした期待値が見えません。
そして、その後のメンバーからの成果物に対しても良しか悪しかは判断できません。
この時点ですでに品質の保証ができなくなります。
そして最後に、顧客の質問にも回答できなくなります。
その結果、いつも対顧客と対チームの２方面確認作業で時間ロスが発生し、納期の遅れによって、責任の押し合いが発生し、対顧客も対チームも信頼関係が薄くなってしまいます。
僕の場合、それが発生しないように、最初から、作業が進むにつれ、常に各ステークホルダーに確認しながら、期待値を修正していきます。
最初ははっきりした期待値が分からなくても、常に、ここに「常に」がポイントです。常に学習しながら、確認しながら、期待値を修正していきます。
そして同時に、常に自分が修正した期待値をチーム内に周知して適応してもらうように注意します。
これでチーム一丸となって、お互いのズレがなくなりまり、信頼関係も同時に強化されます。
具体的に、常に会話して、疑問点を解消した上で新しい依頼をします。
そして期待値をドキュメント化して、適応してもらいます。
「このようにしてください〜〜〜」と、最初の型を自ら決めて、示してから、従ってもらいます。
単に「お願い〜〜、どうぞ〜〜〜」と言っても、結果はどうなるかは人によってバラバラだからです。
これで決めたフォーマットで成果物を出していただけるから、バラバラな品質の成果物が出なくなります。
完全に自分が予想した型の成果物になりますので、顧客の質問に回答できるし、開発者に責任の押し付けもなくなります。
今のところ、このやり方でチーム内部では一丸になれます。
次回、スケジュール進捗管理の注意点と信頼関係についてお話しします。
コメント