社内の単一ソースソフトウェア開発チームの作成
私たちの会社は、ソフトウェア開発をすべての事業部門ごとに管理するのではなく、すべてのソフトウェア開発作業に対して1つの部門を作成したいと考えています。次に、ビジネスユニットは、ソフトウェアのニーズをこの部門に「外部委託」します。これを行う前にクリアしなければならない懸念/期待として何を設定しますか？例えば：
- 各ユニットに割り当てられる実際の時間（FTE）について、ユニット間の合意が必要
- スタッフのスケジュールについて合意が必要
- 片方の当事者が追加の時間を必要とする場合、要求手続きについて合意が必要
- 等...
あなたはこれを使う運命にあるユニットのマネージャーとしてこのような状況にありましたか？その場合、どのような問題が発生しましたか？何を実装するか、実装しましたか？共有チームのマネージャーの場合も同様です。
議論のために、関係者はあなたが気まぐれに開発者を出し入れできないことを知っていると仮定してください。このアプローチの欠点を知りたくありません。私はそれらを知っています。問題を予測し、放射性降下物を軽減する方法を知りたいです。
検討する必要があるかもしれないいくつかの事柄：
プロジェクトと優先事項の「門番」として1人（あなた！）がいることを確認します。
共有ユニットの最も難しい部分は優先度を定義することです。これは、オープングループではなく、経営陣と率直に話し合いたいものです。すべてのタスクが同等であるとは限らず、すべてのタスクが組織にとって同等の優先順位であるとは限りません。 （つまり、オンライン販売ポータルと人事レポートシステムの設定に問題がある場合、販売ポータルが最初に表示されます。）
いくつかの高品質の火災処理された服を購入します。座席は時々熱くなることがあります。 :-)
プログラマーはコーヒーマグではありません！
コーヒーマグ、家具、ラップトップ、そして時には労働力さえ、部門、部署、チーム間で共有できます。そして、私は間違いなく、コーヒーマグはベビーベッドや失敗することはありません。それは単にプログラマーを共有することですが、良い可能性は簡単ではありません。
共有に関しては何も問題はありません。問題は、実際に共有しようとしている2つの異なる部門に関するものではありません。問題は通常、絶え間ない変化に直面するプログラマーにあります。
ここにあなたが考慮したいかもしれないものがあります：
タイムスライスとスラッシング。 -人がジョブをシフトするためのタイムスライスの時間数（またはさらに悪い分）を分割するだけでは、全体のスライスが小さくなるため、プログラマーは指数関数的に非生産的になります。具体的には、少なくとも1週間、時には少なくとも数日は一度に切り替えたいと思っていますが、間違いなく制限されます。
親しみやすさと依存関係。
ドメインと問題の親しみやすさと他者への依存は、プログラマーの独創的なスキルよりも多くのソフトウェアプロジェクトを成功または失敗させるものです。 2番目のプロジェクトの（コーディングとテストを行う）ときにプログラマーに自由を与えることができますが、他のチームメンバーに会う必要がある場合は、ブレインストーミングと要件、プロジェクト管理、顧客とのやり取りに関する意思決定を行う会議に出席してください-これらすべてを実際に単独で行うことはできず、会議間で争うことになるかもしれません。スコープと責任非常に重要なことは、プログラマをどのように借りたいかということです。ガイダンスや相談を期待していますか？または、彼/彼女はいくつかの独立したコードを書くことが期待されています;それとも、要件、設計、統合など、インタラクティブなプロセスに参加する予定ですか？誰が保守するのか
最後ですが最も重要です-常にそうであるとは限りませんが、チームによって、ソリューションへのアプローチ方法やコーディングの種類が異なります。一部のチームの顧客はタイムラインを非常に重要視しており、バグのないソフトウェアを絶対に期待している顧客もいます。別のプロジェクトで作業すると、この要因のいくつかに適応することができます。ただし、さまざまなタイプのプロジェクトに絶えず切り替える場合は、大きな負担がかかります。
そうは言っても、リソースを交換してプロジェクトを最適化することが重要であり、頻繁にあることは常に目に見えます。しかし最終的には、それは共有される個人の能力と能力に要約されます。
私が見た最大の問題は、各ビジネスユニットが自分たちのプロジェクトが最優先であると信じ、他のビジネスユニットは重要でないということです。
おそらく、すでにいくつかの正式なリソース割り当て計画があるでしょう。重要なのは例外の管理です。アプリケーションに重大なバグが発生し、その時点でそのアプリケーションに割り当てられている開発者がいない場合はどうなりますか。または、それがジュニア開発者の場合。
あなたが望まないのは、開発者の電話がさまざまなビジネスユニットで終日鳴り続けることです。ビジネスユニットと開発者の間の明確なコミュニケーションライン、および作業を行うための定義されたプロセスを確立し、誰かが停止したからといってすべてを落とさずに機能に取り組んでいないという開発チームの規律を強化する必要があります。問題のある彼らの立方体によって。彼らはプロセスに従う必要があります。
あなたの質問から明らかでないことは、なぜ彼らがこれをしたいのかということです。開発プロセスを理解する管理構造を持つだけの場合、最も簡単な方法は、既存のチームを1つの部門内に維持することです。ライン管理構造を除いて、ほとんど変更はありません。その理由が、開発者がプロジェクト間でコンテキストをすばやく簡単に切り替えられるようにして、リソースの「より効率的な」使用を可能にすることである場合、どの開発者が消費可能で、誰が配信に不可欠であるかを検討します。コンテキストの迅速な切り替えの大部分は、最も役に立たない開発者によって行われることを確認します。彼らが残そうとしていることを何も達成しないことにうんざりしているとき、その間、あなたはより高い経営陣のサバウテージの最善の努力にもかかわらず、最も効果的な開発者の生産性を維持することができました。
時間の割り当て、スケジューリング、手順などは、単なる管理作業です。それは必要悪です。より重要なのは意図です。
通常、開発者の生産性は、（特定のプロジェクトおよびテクノロジーの）専門知識に比例します。彼らがプロジェクトに集中し続けるほど、彼らはそれをよりよく理解し、より効率的になります。
それらをいくつかの間でプール/共有すると、この生産性が失われます。しかし、そうする理由があるかもしれません：知識の移転。自分の生産性を犠牲にして、他の人がテクノロジーに慣れ、生産性が上がるように他の人に教えたり、助けたり、支援したりします。学習は時間のかかる作業であるため、これは非常に良い結果をもたらす可能性があり、メンターは、特にまばらに文書化されたプロジェクトまたはテクノロジーに対して非常に役立ちます。
ただし、「来週は締め切りです。N人の開発者を追加しましょう！」彼らは運命づけられています。実際、開発者は交換可能な部分ではありません。さらに悪いことに、プロジェクトの最後に開発者を追加することは、それを助けるよりも妨げになり、それをさらに遅らせるかもしれません。
まず、統一された配信プラットフォームが必要です。それがWebサイトか単一の複合アプリケーションかどうか。複数のビジネスユニットの機能を管理することと、複数のアプリケーションをまとめて管理することの1つです。単一のプラットフォームを持つことにより、コードを再利用する機会が増えます。また、複数のビジネスユニットの機能を調整することもできます。
次に、 かんばん トレーニングに投資します（まだない場合）。複雑さ、影響、優先度が大きく異なる多くの機能リクエストを受け取ることになります。これらのニーズに対処するプロジェクトまたはスクラムスプリントを計画することは、ロジスティックな悪夢です。代わりに、優先事項の1つに焦点を当てます。ビジネスにバックログの優先順位を決定させ、パイプにフィードさせます。チームが新しい機能の準備ができたら、リストの一番上から次の機能を選択します。また、大規模な展開を行う必要がなく、完了時に新しい機能を提供できるように、 継続的デリバリー 戦略に投資する必要があります。
私たちは、ビジネスのさまざまな部分（最終的にはクライアント）に属するさまざまなアプリケーションをサポートする、一種のワンストップショップを持っています。
まず成功のために組織することです。たとえば、同じソース管理でグループの全員を取得します。次に、すべてが異なるビジネスグループではなく同じ人物に報告する場合でも、製品ラインまたは内部クライアントによってプログラマーを指定することを内部で妨げるものは何もありません。
私たちは緊急時や新しい大きなプロジェクトが発生したときに人々を移動させますが、通常は同じクライアントの同じアプリケーションで作業します。ただし、各内部グループは複数の内部クライアントをサポートする場合があります。これは、少なくとも、アプリケーションに精通している誰かがそれを見ている可能性が最も高くなります。これは、C＃プログラマーがC＃プログラムを使用して作業することを意味し、Accessプログラマーが突然、スキルセットからプロジェクトを引き継ぐことは期待されません。
まったく異なる専門知識を持つグループをまとめる場合は、誰が何に取り組む資格があるかというマトリックスを構築する必要があります。 （これはリソース計画に役立ちます）。クロストレーニングを設定する時間を見つける必要がある場合があります。そうすれば、プロジェクトがあまりない言語を使用する開発者がスキルを伸ばして、グループにとってより価値のあるものにすることができます。
また、開発者が組織内で上に移動するためのパスを作成したことを確認する必要がある場合もあります。加えようとしている変更のいくつかの利点の1つは、1か所でより多くの開発者が上級開発者およびテクニカルリードに昇格する機会が増えることを意味します。
あなたは以前、組織のさまざまな部分に多くのプログラマーがいたことを考えると、非常に異なるタイプの専門知識、コーディング標準、プロセスを持っている可能性があります。チームによってはアジャイルである場合もあれば、ウォーターフォールを使用している場合もあります。これを長期的に有効にしたい場合は、ビジネスをより標準化された方法に移行する必要があります。ソース管理から始めて、プロセスに移動します（全員がアジャイルになることができる場合、誰かがスプリントに入ると、彼または彼女はスプリントに留まるので、リソースの問題のいくつかを助ける可能性があります。）一部のチームでは、サポートがある場合があります。開発者と新しい開発開発者などは、人が新しい開発とサポートの両方を行うことを期待するかもしれません。 1つの方法で標準化します。可能性のあるすべてのツールを使用するか、すべての新しいプロジェクトで使用するかを決定します。すべての新しいプロジェクトに使用されるコーディング標準を設定します（多種多様な標準を使用して行われたすべての既存のコードを変更することを期待するには多すぎるかもしれません）。
次に、リソースをどのように処理するかを設定する必要があります。毎週または毎月のリソースミーティングが必要で、すべての新しいプロジェクトがそれに参加し、リソースが割り当てられます。リソースは会議間で再割り当てできますが、特定のグループが利用できるリソース内でのみ割り当てることができます（したがって、経理に今月3つのリソースが割り当てられている場合、突然話題になったときにプロジェクトAからプロジェクトBにリソースを移動できますが、それはできませんセールスチームから次のリソースミーティングまでリソースを盗みます）。アジャイルを行う場合、リソース計画会議はスプリントの開始の1週間前である必要があり、すべてのスプリントは同じスケジュールと期間である必要があります（たとえば、全員が2週間のスプリントを持ち、すべてのスプリントが同じ日に開始されます）。 。リソースプランニングで生産サポートの時間を確保することを忘れないでください。
各プロジェクトに必要な時間を見積もる方法について設定された標準プロセスを取得します。 QA、バグの修正、導入の問題、技術仕様の開発、コミュニケーションに時間をかけることを忘れないでください（プロジェクトで会議やメールに多くの時間を費やすことができます）。あなたのリソーシングでは、時間の75％を超える人を計画しないでください（休暇、休日、必要な会社の会議、不可避の遅延、新しいコンピュータがある場合のコンピュータのセットアップなど）プロジェクト作業の時間の100％を想定した経験は、締め切りを逃す最大の理由の1つであり、誰も永久に直接作業に時間を費やすことはありません。
要件文書を作成する責任は、サポートする個々の部門にしてください。不慣れな人がプロジェクトに取り組む場合は、正式な要件文書が必要です。要件ドキュメントなし、プロジェクトなし。限目。また、正式なプロジェクト管理システムをセットアップする必要があります。内部クライアントが時間を請求するプロジェクトを設定するまで、誰も何もしません。もはや「ああ、そう」ではなく、すべてが正式に要求され、リソース計画に組み込まれる必要があります。ギリギリのリクエストも（もちろん実際の本番のバグを除いて）、すべてのリソースがX時間前もって計画されることを知らせてください。バグも正式なシステムで報告する必要があります。バグトラッカーは多数あります。
変更を実装するにあたって、今は、誰にとっても優れた設備や、希望するが購入する予算がなかったツールなど、以前は得られなかったものを手に入れる良い機会かもしれません（トレンチの人々）。全員が少なくとも2つのモニターを持っていることを確認してください!!そして良い椅子。少なくとも彼らのために何かがあるので、より良いeuipmentを得ることは新しいシステムを受け入れる人々を助けるかもしれません！
まだまだあると思いますが、この2番目に頭に浮かぶのはそれだけです。少なくとも、それを実装する方法の計画プロセスに着手するでしょう。
まず、さまざまな非技術部門のマネージャーが、コーディングのバックグラウンドを持つ誰かに直接報告することに慣れていて、そこに技術プロジェクトを引き渡すことができ、今ではそれらの技術担当者全員が他の誰かに報告する部門にいる場合、マネージャーは、新しい「通常の」プロセスを回避し、以前の技術者に到達するために、できる限りのことを行います。彼らはこの新しいアレンジメントを少し気に入らないでしょう。彼らは、新しい仕事の要求に対するより遅い応答、ジャンプするためのより多くのフープ、および技術者の給与で固定されていた追加のコストを知覚します（技術者の時間が他の部門の間で「予算」に入れられている場合）。
あなた（この新しい技術部門の新しいマネージャーの立場にある）は、これを芽でつかむ必要があります。まず、必要に応じて、技術チームへのアクセスを物理的に制限する必要があります。これは技術チーム自身から始まります。彼らは今、新しい上司のために働いていることを理解する必要があります。新しい上司は、heが各技術者に古いものではなく、何をするように言ったかに基づいてパフォーマンスを評価しますボスは、プロセスの最後の実行を介して完了しようとしています。再編成と同様に、移行期間があります。技術者は古いボスと「別れる」必要があります（「わかった、あなたは素晴らしかったが、私たちはこのようにお互いに会うのをやめなければならない」）。古い上司に頑固に忠実であり続ける人々は、手放す必要があるかもしれません。彼らがあなたが望むことをしないなら、彼らは彼らの能力に関係なくあなたにとって役に立たない。
技術チームが試みているのに、古いボスがまだ、セットアップしたゲートウェイを通り過ぎて小刻みに動いている場合は、そのゲートウェイを物理的にします。メンテナンスに、開発者のオフィスに通じるキーカードドアを取り付けてください。アクセスできるのは、あなたと開発者だけです。彼らの古いボスがこれに怒って来たとき、あなたの立場を立ててください。彼らは今ではあなたのために働きます、彼らのためではありません.
他の部門のプロジェクトで技術者の時間をスケジュールすることに関しては、それはこれらのプロジェクトの数と範囲に依存するビジネス上の決定です。通常、古いシナリオが部門が必要とするあらゆることを行う個々の開発者の集まりであった場合、それは通常多くの小さなことを意味します。優先順位を付けて、作業に最も適した開発者に渡します。完成したら完成し、依頼した部署への配送を手配します。
さて、その戦略はあなたを冗長にするように見えるかもしれません。すべての技術者がまだ古いボスの下で行っていたのと同じ作業を行っている場合、何が変更されますか？変更された点は、入ってくるものに基づいて全体像を把握できるようになり、途中で開発作業をガイドできるようになったことです。あなたはそれをより良くする方法を見つければ、技術者に部長が要求することを正確に行わせる必要はありません。プロセスを改善し、断片的なソリューションをより目的に特化したものに統合する機会を探します。もちろん、さまざまな部門と連携しますが、この新しい開発部門の責任者として、あなたは基本的に事実上のビジネスアナリストの立場にいます。あなたが求められていることを行うためのより良い方法を見つけたら、是非ともパイプアップしてください。
また、変更されたのは、これらすべての個々の開発者がチーム構造で編成されるようになり、1つの開発週にかかっていたはずのものがチームの日数を費やす場合があることです。ビジネスプロセスの自動化とエンジニアリングのためのこれらの「大きなプロジェクト」は、チームの努力が必要です。それが彼らが以前に成し遂げなかった理由です。それを行うチームがなかったためです（そして、単一のソリューションで複数の部門間で調整する意欲や権限を持つ人がいませんでした）。