小規模開発会社におけるプロジェクト管理のスケーラブルなプロセスとは何ですか？

Question

私たちは小規模な企業チームとさらに小さな開発チームを持っています。現在のプロセスは、各営業担当者（SR）が、販売された各Webアプリケーションの実際のプロジェクトマネージャーであることです。開発者はSRから要件、機能、デザインを直接入手します。開発者の実際の作業負荷を視覚的に把握することができます。私たちはより多くのプロジェクトを手に入れることができますが、セールス担当者と開発者が増える中、このプロセスはスケーラビリティに欠けます。

テクニカルPMをSRと開発者の中間に置くことについて考えました。

SR1、SR2、SR（N）---> TPM - DEV1、DEV2は

これは大丈夫そうですが、私たちの現在のプロセスは、当社の営業担当者/ QuasiPMは実際には非常に即時の方法で、開発者の時間を得ることができます> 。そして、彼らは実際にこれを逃げようとしています。我々は現在のプロセスを持っている

問題は、次のとおりです。

SR1、SR2 - > DEV1、DEV2（アドホック）

• ない可視性、当社の開発者への負荷（メイキング開発者があまりにも多くを持って働きます
• 緊急時に休暇を計画できない
• 編集1：SRが朝の会議にあり、優先度が緊急に応じて変更されるということを忘れてしまったもう一つの問題です。

私は受け取ったコメントに応じてさらに情報を追加します。いつものようにあなたの時間をありがとう。

EDIT2：一般的に は3つのSRまたは製品の所有者、3-4開発者、1技術PMがあります。

Answer 1

は、PMの間の営業担当者や開発者を入れないでください。ここには2つの無関係な問題があります。

• どのような機能を提供していますか？ （SRだけがこれを知っています）

• 進歩していますか？時間通りに物事を進めていますか？ （これはPMのためのものです。）

これは何ですか？

sales rep -> [ developers + PM ] 

さらに、相互作用の周囲にいくつかの構造が必要です。

SRがランダムな要件を開発チームに落とせるようにすることはできません。代わりに、開発者が目標に集中して目標を作り出すことを望みます。彼らがスプリントを終えると、PMとセールスの人々と会い、次のスプリントが何であるかを判断できます。

これはScrumメソッドであり、スケールがよくなります。それは、相互作用の方法に人を追加することなく、相互作用を制御します。

Answer 2

可視性のために、ある種のボードを考えてみましょう。私たちは最近、Kanban（Leanの1つの部分）を使用し始めました、そして、これまでは正の力であるようです。作業負荷（または流量）を均等にするよう試みます。

休暇/計画の場合、かんばんが1つの選択肢です。その他には、XPおよびScrumが含まれます。 IMHO Scrumは経営哲学であり、XPは開発方法論です。 Planning Extreme Programmingは間違いなく読む価値があります。

お客様（お客様のSR）は、常に開発プロセスを回避しようとします。 「この話を反復の途中に入れることはできませんか？」どのような方法を選んでも、管理のバイインとサポートを受ける必要があります。 SRの利点は、（1）彼らがストーリー（機能リクエスト）の優先順位をつけること、（2）彼らのストーリーがいつ行われるのかをよりよく理解できることです。

Answer 3

私はあなたの現在の問題と全く新しいプロセスを選ぶことに集中します。主な問題にトラッキングトラッキングが必要な場合は、時間トラッキングシステムをインストールします。開発者が時間を費やしている場所を示し、プロジェクトごとに損益を表示することもあります。

通常、プロセスはゆっくりと進化しますが、連続的に進化します。ボスに迷惑をかけている問題だけでなく、金銭や士気を抱える問題を解決するよう、自分の問題とこれらの問題の実際のコストを監視します。

ヒント：ビジネスにあらゆる種類の指標を実装するのは難しいことがあります。大きすぎるスティックが付属していないことを確認し、開発者や営業担当者が同じ方向にデータを操作することを奨励しないように設定してください。ビジネスモデルとその取引のそれぞれに応じて、SRは数時間をプッシュアップまたはプッシュダウンする傾向があります。開発者にとって、彼らの偏見は、仲間と同じくらい熟練していない、または効率的ではないと誰かが指摘するまで、彼らが忙しいと感じる傾向があります。

追加のヒント：メトリックを変更するためにメトリックを使用しない場合は、それを盲目的に収集してください（参加者は知らないでしょう）。あなたはおそらく最も正確な情報を得るでしょう。

Answer 4

同様の状況で立ち往生しているので、私たちのバージョンと私たちがどのようにゆっくりと拡大しているかをお知らせします。あなたの場合のように、私たちのPMは開発者の時間を管理します。私たちはしばらく盲目的にやってきましたが、現在は開発時間を優先させ、社内の全員に公開するソフトウェアを使用しています。当社のすべての午後は同じ建物内にあるので、開発者が話し合ってまとめて作業する必要があるかどうかを判断することができます。

しかし、このプロセスには依然として非常に欠陥があります。あなたが言ったように、朝の会議は優先順位を変えることができますが、一般にプロジェクトで何かが間違っている場合のみです。私は個人的に開発者PMが多くの問題を解決すると感じていますが、開発者の中には在宅勤務者の数人がいるため、 PMプロセスを管理下に置くためのアドバイスを以下に示します。

• すべてを文書化してください！
• PM/Devs間の簡単なコラボレーションのために、ユーザー/開発者にやさしいソフトウェアを使用する
• 開発者に優先待ち行列を与える（PMのどのようなプロジェクトのニーズだけで
• はあなたのプロセスを分析し続け、私はラインの下のおよそ与えるために、より多くの情報があればいいのに必要な

などの分野を置き換える）次のタスクを通して押すのではなく、次の行われたが、私は、私言ったように私は次のレベルにヒントを与えています。もちろん、中小企業の外では、このモデルはあまりにも妥当ではありませんが、今の私たちの進歩を助けています。