私の組織は、ここ 1、2 年で、製品指向のビジネス モデルではなく、契約指向のビジネス モデルにゆっくりと転用し始めました。この 1 年間、私は火消しと注文の履行を支援する新しい請負業務にシフトしました。1 年全体としては利益を上げていましたが (したがって、少なくとも 1 つの指標では成功していましたが、6 月頃に 2 つのプロジェクトがあり、2018 年 6 月頃に 1 年間の数値を大きく下げました。
私はクリスマス休暇の前にマネージャーと話していましたが、彼は「事後分析」という言葉が好きではないと言いました (私はこの言葉の何が問題なのかわかりませんが、ビジネス関係者やマネージャーは知っていますか?) 、彼は1月中旬に会議を開き、契約グループ全体がその年を振り返り、何がうまくいき、何がうまくいかなかったか、そして収益性を改善するために私たちが実行できる取り組みを理解しようとすることを望んでいました.
さまざまな理由から (要望があれば詳しく説明します)、私たちのチーム、そして組織全体が恩恵を受けることの 1 つは、なんらかの組織的なコード共有であると考えています。同じことが別の人によって何度も行われ、最終的には別の方法で行われます (そして壊れます)。少なくとも、人々が特定のタスクを実行するコードを取得し、そのコードを自分のプロジェクトに含める (または、現実的にはコピー/貼り付けする) ことができるリポジトリを確立したいと考えています。
少なくとも 10 人から 12 人のフルタイムの開発者のチームと、専門的な仕事のために契約グループに一時的に出向している 5 人から 50 人の (非常に) パートタイムの開発者のチームに対して、実行可能な共通ソース リポジトリとして何を提案すればよいでしょうか?
答えには、合理的な答えを得るために何らかの文化的情報が必要だったので、このトピックに関する私の考えとともに、ここでそれを提供します。
- 開発者は、このリポジトリの使用を強制されません。参入障壁は、参加を促すためにできるだけ低くする必要があります。そうしないと、無視されます。 残念ながら、これは、追加のソフトウェア クライアントをインストールして実行する必要があるものはすべて失敗する可能性が高いことを意味します。ClickOnce の展開は可能な限り近いものですが、それは非常に不確かです。
- 私たちはリスクを嫌う Microsoft ショップです。 オープンソース ソリューションを販売できるかもしれませんが、疑いの目で見られるでしょう。すべての開発者は VSS を使用しており、コーポレート ディレクターは VSTS は今後実行できないと宣言しています。セットアップがそれほど難しくなく、ライセンスが自由であれば、VSTS サーバーをラボに忍び込ませてみることもできます。
- 私の仲間の開発者の中には、高品質で信頼性の高いソフトウェアを書くことに関心がある人もいれば、気にしない人もいます。 私は、気にする人によって書かれた共有コードを、気にしない人から保護したいと考えています。一般的な構成管理の慣行 (作業中にコードをチェックアウトするなど) は、契約チームの同僚の少なくとも 5 分の 1 によって完全に無視されています。
- 私たちは、プロセスに従うよりもプロセスを書く方が得意です。 これをマネージャーに売り込むには、なんらかのプロセスを書面で作成する必要があります。私のマネージャーだけがそれを読むことができるので、それは軽量で柔軟性があり、リモートで関連するツールによって強制される必要があると思います.
- ベスト プラクティスを想定しないでください。 一般的なコードで静的分析ツール (FxCop、StyleCop) の使用を強制するために、必須のコード レビューなどを含めたいと考えています。ただし、これはハードルを上げます。現在、そのようなプラクティスは一貫した方法で実行されていないからです。
リクエストされた追加情報を提供させていただきます。:)
編集：（質問への回答）
おそらく、契約という言葉は適切ではありません。私たちは独自のコード資産を完全に所有しています。紙の上でのビジネス モデルの重要な部分 (まだ実際にはそうではありませんが) は、私たちが書いたコード/プロジェクトを所有し、それらを他の顧客に再販できることです。私たちのプロジェクトは通常、会社の多くの既存のソフトウェア製品の 1 つに特別な機能を追加するという形をとっています。