序文
5、6人の小さなチームから40人以上の大きなチームに成長するのを目の当たりにしてきました。この数年間の仕事を振り返ると、とても幸せで、時折、以前の仕事の写真を見返すと、心が和みます。私はまだ比較的幸運な方だと思います。好きな仕事を見つけ、一緒に働くのが好きな仲間を見つけ、さらに成長し続け、新しい結果を出し続けています。
チームはその過程で成長し続けており、良い経験もたくさんありますが、今回はプロジェクトマネジメントについてお話したいと思います。なぜ私が最初にこの話題を選んだかというと、最近会社がプロジェクト管理システムの新しいセットの実装では、自分の使用は、プロジェクト管理手法のセットを放棄する上で、これらの2つの管理システムを使用して、私は比較を行うことができます。
現状
プロジェクト管理の話をするために、私は最初にグループのビジネスプロセスについて話をする必要があると思います、結局のところ、異なるビジネスプロセスは、別のプロジェクト管理手法を使用する必要があります。
当グループはモール事業を担当しており、モールの主要な枠組みを改善し、商品から需要側。
モールの学生の理解は、モールのビジネスは急速な反復を必要とすることを知っている必要がありますので、並行して週に30または40のプロジェクトがあるかもしれない、マンパワーのプロジェクトは、開発からオンラインへのプロジェクトは、一般的に1〜2ヶ月。
毎週のミーティングは指定された時間に開催され、製品チームはプロジェクトの進捗状況やプロジェクトの優先順位を校正し、次週の計画を決定します。
これが現状です。
つのシステム
マネジメントなし
人が5、6人しかおらず、ほとんどすべてのプロジェクトに締め切りが設定されていたとき、製品は「その日に使います。
ビジネスが急成長しているのを目の当たりにし、活気と熱意を感じ、プロジェクト管理は必要ありませんでした。
もちろん、まったく管理されていないわけではなく、多かれ少なかれ、スケジュールや関連する計画は今でも行っていますが、一般的には少し大雑把です：
今思うと、本当に車輪が回るような作業で、他の人が不可能だと思うようなこともたくさんやり遂げました。
これは、事業の野放図な成長期に使われた最初のプロジェクト管理システムです！
自作プロジェクト管理システム
事業が成長し、プロダクトマネージャーや研究開発学生が増え続け、プロジェクトが増えすぎた結果、上記の方法では管理しきれなくなりました。これにはいくつかの理由があります。
- 製品部門と研究開発部門の両方が、リソースと計画を管理できるように、現在のプロジェクトをすべて表示できる場所が必要です。
- プロジェクトには様々なステータスがあり、どのプロジェクトが長い間扱われていないのか、あるいはリスクがあるのかを確認する必要があります。
- 研究開発担当者は、研究開発リソースがどのように使用されているかを知る必要があります。
当初、私は自分自身のセットをやりたかったのですが、プロジェクト自体が多く、リーダーシップも必要ないと考えており、少なくともプロダクトマネージャー1人、フロントエンド1人、リソースがなかったので、やりませんでした。今思えば、あのときやらなくてよかったと思います。 最初にプロジェクト管理システムを作ったほうが楽なはずだと思っていたので、まったく昼夜逆転です。プロジェクト管理システムは技術的に複雑になるのではなく、本当にみんなのニーズに応えられるかどうか。当時は事業規模も、事業数も、プロジェクトをやる上で遭遇するいろいろなことも、比較的小さかったので、そういう知識で作ったものは、あまりいいものではなかったかもしれません。
その後、今ある管理ツールを調べてみると、使い方が複雑なものもあり、最終的にはもっとシンプルなソリューションで解決しました。TBの使用
TB
まず、プロジェクトの状態を決定します： 要件キューイング、要件レビュー、技術レビュー、スケジューリング、開発、テスト、オンライン、中断、放棄。これらの状態には、それぞれ対応するプロジェクト リストがあります。製品部門と研究開発部門が協力して、プロジェクト ステータスの継続的な変更を推進します。
プロジェクトリーダー
プロジェクトの開始時刻と終了時刻
プロジェクトの進捗状況
製品ライン：どのビジネス関係者が要求を出したか
マ イ ルス ト ーン ： 重要な時点、 開発開始時間、 テ ス ト 時間、 稼働時間。
要求提案者
プロダクトオーナー
研究開発部長
テストリーダー
推定値
wiki
備考
製品との週次ミーティングがあるため、週次ミーティングの前日にプロジェクトリーダーが進捗状況をアップデートし、リスクポイントがあればメモを作成します。
TBの良いところは、検索が非常に柔軟なので、気になるプロジェクトを簡単に絞り込めることです。TBを使うことでプロジェクトは管理されます。
標準化
もちろん、TBだけに頼ることはできません。もう一つできることは、プロジェクト要件を正規化することです。すべてのプロジェクトには
要件文書：製品要件の詳細とプロトタイプを含みます。
技術文書：プロジェクトが複雑な場合、技術文書にはアーキテクチャ、API、その他の技術的な詳細を含める必要があります。
スケジューリング文書：非常に重要な部分で、一般的に以下の内容が含まれます。
- ゴー・ライブとロールバック・ドキュメンテーション
これらの文書は、TB wikiのリンク設定項目に置かれ、すべての人が見ることができます。
プロジェクトがテストされるとき、テスト内容はテストシステム上に記入され、また、R&Dによってプロジェクトが全く使えなくなることを防ぐために、テスト生にも実演されます。もちろん、研究開発学生もテスト学生のテストケースに目を通します。
プロジェクトに延長と本稼働のリスクがある場合、事前に製品に連絡する必要があり、リスクを回避できない場合、すべての担当者と会議を行い、プログラムを再作成し、新しい時点を決定し、延長メールを送信する必要があります。
プロジェクトがオンラインで完了した後、プロジェクトの実施に従って、誰もがレビューを行うことができます。このように、常に管理を最適化します。
個人的には、今でもこのような管理が好きです。
第一に、一つのプロジェクトの詳細な情報を得るのが簡単で、多くのプロジェクトの情報を一目で見ることができます。
第二に、タイトでルーズ、つまりすべてのプロジェクトをひとつの流れにまとめつつ、問題が発生したときには開発者が調整できること。
第三に、プロジェクトの維持費が安く、毎週更新されるため、すべての関係者がプロジェクトについて同じ見解を持つことができます。
もちろん、これはまた、欠点を持って、欠点は、各研究開発学生の作業負荷を定量化することができないということです、直接リーダーの下でおおよそのことを知っているかもしれませんが、数字で表現することはできません、昇進、評価、およびその他の事項の不足につながる、基礎。
自己研究プロジェクト管理システム
今年、当部は独自のプロジェクト管理システムの開発に着手し、分解した内容をプロジェクトに入力し、小項目の完了後にプロジェクトの状況を更新する必要があります。こうすることで、セルフリサーチシステムは全員の作業時間や作業状況を見ることができます。
このシステムはまだ構築中なので、主に以下のような改善点があると思います。
- 分割された小項目の記入が面倒。従来は、スケジューリングドキュメントを書くだけで、各グループの仕事量を簡単に見ることができました。今は、まずスケジューリングドキュメントを書き、そのスケジューリングドキュメントの小項目をシステムに記入する必要があり、工数が何倍もかかっています。小項目記入の機能をもっと直感的なものにし、内容をわかりやすく表示することができます。
- 更新の手間各項目の完了後、更新しないとプロジェクト全体の進捗が更新されないため、タイムリーに小項目を更新する必要があり、忘れると進捗表示に支障が出ます。これはリマインダーメールで解決できます。
- プロジェクトが見つからない気になるプロジェクトを見つけたいが、フィルタリングが難しい場合、プロジェクトのプロパティを整理し、プロジェクト検索機能を最適化することができます。
- マイルストーンの表示に問題があります。管理システムにはマイルストーンを表示する明確な場所がないため、マイルストーンを見つけるには通常スケジュールドキュメントをチェックする必要があります。
- プロジェクトの変更がない現在、通常の管理プロセスしかなく、プロジェクトにリスクがある場合、この変更操作を行う場所がありません。
- ポイント付与が難しい各プロジェクトには点数があり、プロジェクト終了後、参加者はその点数を分けるために、関係する学生をそれぞれ採点する必要があります。これはどちらかというと、人間性や他人の作品に対する慣れなどが試されます。
- バグの修正、問題の追跡、質問への回答など、システムには反映できない細かい変更点もあります。
データが正確かどうかは別として、このシステムの良い点は、全員の仕事量を数値化し、全員の労働時間と獲得ポイントを確認できることです。このシステムがどんどん良くなることを願っています。
プロジェクト管理システムの設定はまだかなり難しく、記入しやすく、見やすく、更新しやすく、さらに各人の貢献度を計算し、より人間的な部分、製品や研究開発の知恵をもっと試す必要があります。
要約すると
プロジェクト管理は最終的に必須であり、誰もが物事をよりよく制御するために、安心感を感じるために実行されているすべてのものを見ることができます。しかし、プロジェクト管理の意図とは何でしょうか？最も基本的なことは、ビジネスをより良く、より速くすることだと思います。
では、なぜ今までプロジェクトマネジメントを使わずに、これほど多くの課題を達成することができたのでしょうか？もっと重要なことが含まれていたのではないでしょうか？
この記事が多少なりともお役に立てれば幸いです。
結論として
過去の記事レビュー
