1

フロントエンド開発者、バックエンド開発者、グラフィックデザイナーからなる技術リソースのプールがあります。これらのリソースは、クライアントごとに1人または2人のアカウント担当者によってクライアントから直接分離されています。

クライアントからのリクエストは、アカウント担当者を介して受信され、同期マネージャーに送信されます。同期マネージャーは、すべてのクライアントプロジェクトを追跡し、各リソースのワークロードの基本的な考え方を持っています。彼の仕事は、プロジェクトの優先順位とリソースのプロジェクトへの精通度（ある程度）に基づいて、リソースに作業を割り当てることです。現在、このデータ/ロジックの大部分は複雑なExcelスプレッドシートで処理されています。毎週月曜日にスケジュールを見直し、人々が自分たちの将来を明確に把握できるようにします。

このタイプのシステムは、期間が長い線形プロジェクトでは問題なく機能しますが、同時に発生する小さなプロジェクト/タスクが多数あると失敗し始めます。多くの場合、更新が週の半ばにスケジュールに来ると、技術リソースは「失われます」。既存のスケジュールに取って代わる「緊急の」要求がある場合は言うまでもありません。

毎日/毎週複数のクライアントと連携する場合、ワークロードの割り当てをどのように処理しますか？リソースの可用性のスケジューリング/決定を支援するために推奨するソフトウェアはありますか？優先順位やプロジェクトは頻繁に変更されることを覚えておいてください。現在から1〜2週間後に何が起こるかはわかりません。

4

3 に答える 3

3

私には、古典的なコンサルティングの難問のように思えます: 最も少ないリソースが最大の収益を生み出すスイート スポットに到達することです。

私の頭に浮かぶ最初の質問は、これがどのくらいの痛みを引き起こしているのかということです. 開発者の間で不満？上層部からの苦情？激怒するクライアント？解決策は、発生したトラブルのレベルに一致する必要があります。

スケジュールの中断に関しては、知らないことを知ることができないという単純な事実は、大部分、この問題に対するソフトウェアの修正がないことを意味します。予期せぬ需要に備えて十分な余裕を事前に構築し、その場で再割り当てできるようにしておく必要があります。

また、クライアントがブーイングを言うたびに開発者がジャンプする、パンツの座席モデルが選択であることにも言及する必要があります. 誰もが他のオプションを検討する意思がある場合、必ずしもそうである必要はありません。

于 2009-12-14T19:35:45.150 に答える
0

JIRAなどの問題トラッカーを使用する

于 2009-12-14T19:31:19.723 に答える
0

個人的には、スクラム ボードの使用を検討します。これは、物理的なウォール、PowerPoint スライド、または Bugzilla を使用して実現できます。
以下を試してみてください:
1. 各技術をセルに
割り当てます。 2. 各技術 x ジョブ/タスクの量を割り当てて、各ジョブ/タスクに優先度レベルを与えます。
3. スライド/ウォールで、To Do、Test、Very、Done のさまざまなステージを作成し、開発者にそれらをステージ間で移動させて、技術とプロジェクトの可視性を高めます。

于 2009-12-14T19:32:58.307 に答える