大学で得られるようなものについて話しているのではなく、開発者向けのジョブの進捗レポートを実装することです。
開発チームを編成する上での私の考えは心強いものであり、開発者が過去 1 時間または数時間に何をしたか、およびタスクにかかった時間を報告する定期的な進捗状況の更新がある程度必要でした。以下に、私の頭に浮かぶいくつかの長所をリストしました
私が見たくないのは、それが開発者を息を吹き返す方法になることです.
毎時はあまりにも頻繁です。多くの中断は生産性を低下させ、開発者のフラストレーションを増大させます。スクラムの方法論を調べることをお勧めします。彼らは「毎日のスクラム」ミーティングを持ち、毎朝、前日の進捗状況と当日の計画された作業についてチームに更新します。それは私にとってはうまくいきましたが、あなたにとってはうまくいくかもしれません。
スクラムには、時間を見積もるストーリーカードとタスクカードの概念も含まれており、最終的に戻って見積もりがどれだけずれているかを確認します。これにより、将来の見積もりの精度を高めるために使用できる「フォーカス ファクター」が得られます。
この PDF Scrum and XP from the Trenchesをチェックして、よく読んでください。
通常、ステータス レポートを 1 日 1 回以上要求すると、多くの Office Space TPS Report コメントが得られます。より多くのプロジェクト データで得られるメリットは、士気の低下とチーム全体の倦怠感によってすぐに打ち消されます。
定期的に (おそらく毎日) 更新を依頼してみてください。正式な書面によるレポートを求めないでください。それは、上司のためにレポートを作成する PM としてのあなたの仕事です。開発者には、開発作業があります。管理タスクで彼らに負担をかけないようにしてください。
これは、プロジェクト マネージャーが自分の役割を理解していないもう 1 つの例です。スクラムは答えではなく、他の教義でもありません。どのような組織においても、意思決定をより適切にサポートしたり、決定に参加したりするために、一体なぜ時間ごとのレポートが必要なのですか? あなたは働き者の魚ですか？彼らは 60 分以上の記憶を持っていないので、「ヘイ、ジェフ... 調子はどう?」とトロールする必要があります... 完全に精神を消耗させる考えキラー 鉗子主導の一時停止「wazup patcouch22?. . 59分前に会った人...」
そして、最後のスリップで何がうまくいかなかったのかを非常に詳細に理解した場合はどうなりますか... 次のプロジェクトでまったく同じ脱線が起こるでしょうか? たとえそうなったとしても、あらゆる形態のスリップ/エラー/進行を回避するために必要なロボット化を理解していますか?
人間になろう…人間を助けよう、大声で叫ぶのに！高レベルの生産性を達成するための奇跡的な数学的に構造化された方法はありません...ただのヒューリスティックです。The Mythical Man Month などを読んでください... 不十分な管理手法についてではなく、事故についてであり、私たちが人間を扱っているためです.
チームの生産性を向上させるために私が行った最高のこと (私が「ただの」PM だったとき): スタッフに十分な食事を与え、十分な睡眠を取り、定期的なスケジュールを維持し、「ばかげた質問をしてください」と提案します。 IFFFF にだけ答えます。答えは 10000% 確信しています。」上のプレッシャーから彼らを守り、下の問題を解決し、あなたがパンチングバッグの義務のためにそこにいることを彼らが知っていることを確認してください.
状況報告をまとめて行うのは避けたいと思いますが、どうしても使用しなければならない場合は、週 1 回以下にしてください。優れた開発者は、労働者というよりアーティストに似ています。彼らは、時計仕掛けの規則性ではなく、クリエイティブなスパートで素晴らしい作品を生み出します。頻繁にステータス レポートが必要な場合、彼らは不必要なプレッシャーを感じ、実際には満足度が低下し、創造性が低下し、最終的には生産性が低下します。
チームの最新情報にはtwitter.comを使用します。私はチームに、タスクを開始したとき、タスクの途中、タスクを終了して新しいタスクを開始したときにツイートするように依頼しています。こちらです：
私たちは全員、アカウントを非公開アカウントに設定して、グループ外の誰かが私たちのツイートを取得しないようにしています。私たちはそれを 2 か月間使用してきました。
数時間ごとの進捗レポートはやり過ぎです。ソース管理を使用している場合は、チェックインを追跡し、開発者が行ったコミット/チェックインにコメントするための標準を設定することで、多くのマイレージを得ることができます。このようにして、彼らにバッジを付ける必要はありません (そして、非常にコストのかかるコンテキスト スイッチが発生します) が、進行状況を監視しながら、フローに留まることができます。
ソース管理がどれほど洗練されているかに応じて、タスクをコミット/チェックインに関連付けることができます。これは、見積もりを追跡するための追加の粒度です。
やりたいことは2つあります。
毎日の会議
あなたがしたいのは、2つの質問をすることだけです。
開発者が進歩しているかどうか、または遅延の原因となっている問題があるかどうかをすぐに確認できます。より定期的に更新を取得しようとすると、やり過ぎであることが判明し、おそらくマイクロ管理として認識されます.
毎週の進捗レポート
週に 1 回、30 分かけて次の内容を含む簡単なレポートを作成します。
これを行うのに多くの労力を費やす必要はなく、プロジェクトがどのように追跡されているかについて非常に優れた洞察が得られます。また、経営陣やクライアントに、何が起こっているのか、何に対処する必要があるのかについての概要を提供するのにも非常に効果的です。
より包括的な概要については、次のリンクを参照してください。
乾杯、マーティ
スクラムの方法論は、これをうまく処理します。進捗状況と障害を報告するために、毎日短い会議があります。細かな点にとらわれることなく、誰もが追いつくことができます。
スクラムを調べてください。これは、やりたいことをすべて定義するアジャイルなアプローチであり、私たちのチーム (および私が読んだ他の多くのものと同様) にとってうまく機能します。
実際にこれを実施するアジャイル スクラム。すべてのタスク/バグなどを追跡するために、VSTS スクラムの方法論とプロジェクト テンプレートに従っています。時間レポート用のフィールドを簡単に設定できます (すぐに実装することを考えています)。評価のために人々を評価します。専門知識が不足している場合は、この綿密な追跡で簡単に見つけることができます。しかし、これの実用性は大きいですか？
できれば近況報告はやめておきます。良いアイデアのように聞こえますが、それは、あなたが人々を管理しようとしているというメッセージを送信し、仕事を成し遂げるための最善の方法に焦点を当てていません. 私が見た限りでは、やらなければならない仕事のいくつかを説明し、彼らに十分な余裕を与え、リソースとして自分自身を提供すると、人々は最もうまく機能するようです. 時報のようなものは、あなたも含めてみんな大変だと思います。
朝の簡単なミーティング (スクラムに似ています) は役に立ちます。誰かが電話を切った場合、毎日同じことを言っているため、すぐに明らかになります。また、他の人にステップアップして支援を申し出る機会を提供します。これは、必要に応じて、またはレビューのアイデアが好きな上司がいる場合に、いつでも個人的にメモすることができます.
チームを率いることに関するすべては、スケジューリング、動機付け、優先順位付け、および競合管理です。
毎週月曜日の朝、仕事を始める前にチームを集めて、彼らの仕事について話し合っています。
前の週に達成したことと、次の週に達成することを楽しみにしていることについて話します。
その上で、ある意味で本当に刺激的だった何か (通常はコード関連) をそれぞれ持ち出します。うまくいったコードの一部。新しいアプリのアイデアのナプキン スケッチ。チームの他のメンバーを豊かにする新しいテクノロジー。
常に何かがあります。
満足のいく成果のリストで週を始めることに加えて、将来がどうなるか、そしてどんな素晴らしいプロジェクト/成果が待っているかを考えるのも元気になることがわかりました.
私たちは会議の外でロジスティクスを解決します。スケジュール、優先順位は個別に対応いたします。
このような会議は、 Finisht.comやTwenis.comのような小さな成果を実際にもたらしました。とてもクールで、私が一緒に働いているチームはコーディングにとても興奮しているので、信じられないこともあります。