リーダーシップは、マシン構成と新しい開発者志向の標準プロセスに価値を見出さない

約3か月前に、私たちの主要なWeb開発者およびデザイナー（同じ人物）が会社を辞めました。緑の牧草地が退職の理由でした。彼らに良いと私は言う。私の問題は、彼の部門が完全に文書化されていなかったことです。リードを離れてからの状況は厳しく、私たちが新しいプロジェクトを引用するために使用する理論的な知識と、彼が去ったために失った既存の製品の技術/実装に関する知識の両方がたくさんあります。私の通常の役割は、製品マネージャー（私たちの製品自体）およびプロジェクトベースのコンサルティング業務のビジネスアナリストです。私は過去1年間、自分でコーディングすることを学び、前進し続けるために努力しました。私のラップトップを開発マシンとしてセットアップするタスクを引き受けて、より簡単な機能リクエストのいくつかを実装し、私たちのチケットシステムに送信されるいくつかの簡単なバグを修正することを期待しています。しかし、新しいWindowsマシンを使用して、本番用アプリとシームレスに動作するように構成する方法は誰にもわかりません。

私は上司に、去った開発者とまだ連絡を取り、新しい開発者、ソフトウェアのインストール、必要なパッケージ、プロダクションアプリケーションサーバーにデプロイするプロセスなどを文書化して作成するプロセスを依頼するよう依頼しました。これは存在し、コンピュータを機能開発マシンとして機能させるために、私はホイールを回転させています。しかし、彼女はそのようなプロセスが存在する必要性を理解していないようです。どうやら、去ったものを交換した新しい開発者は、私たちの環境用に事前構成されたマシンを使用していたため、新しい開発者でさえ、別の開発者を追加すると新しいマシンをセットアップできませんでした。

私の質問は2つの部分です：

1. 私たちの開発エコシステムの一部である新しいコンピューターを搭載して構成するプロセスが存在するはずであると想定するのは間違っていますか？

2. 私はひどい赤ちゃんですが、プロセスを理解して自分でドキュメントを作成する必要がありますか？

まず第一に、開発者が作業環境をセットアップしなければならないのは奇妙です。このタスクは通常、システム管理者向けです。したがって、これはあなたがすべきことではないことを考慮に入れて、あなたは誰かがあなたのためにこれをすることを期待する権利があります。

ほとんどの（すべてではないにしても）企業​​では通知期間があります。通常は1週間から1か月です。しかし、とにかく、会社を去る人にとって、その時間は十分です。ドキュメントの作成、コードへのコメントの追加、アーキテクチャのドキュメント化などです。今これを行うには遅すぎると思いますが、忘れないでください。次に誰かが去ったとき。

新しい環境をセットアップするためのプロセスが存在することを期待するのは絶対に正しいことです。実際、会社が成長して開発者が増えると、同じ問題に直面することになります。これは上司を説得するための激しい議論になる可能性があります。引数を使用して、そのようなタスクのためにシステム管理者を雇うよう経営陣に説得することもできます（問題に直面しているので、あなたはシステム管理者を持っていないと仮定します）。開発環境の設定に加えて、新しいマシンがある場合は、ローカルネットに統合する必要があります。

私たちの開発エコシステムの一部である新しいコンピューターを搭載して構成するプロセスが存在するはずであると想定するのは間違っていますか？

いいえ。これらのプロセスがあれば、すでに直面している問題を回避できます。一部の大規模な組織では、開発者のマシンがどのように見えるかを示す標準のディスクイメージがあります。新しい開発者が採用されると、適切なハードウェア仕様を備えた利用可能なコンピューターがワイプされ、この「開発者」ディスクイメージを使用してイメージが再作成されます。標準チェックリスト（イメージに含まれていない特定のツールのイメージング後のソフトウェアのインストールが含まれる場合があります）の後に、これを行う技術担当者がすべての開発者マシンが同じ方法で起動することを確認します（ユーザーは取得後にそれらを微調整および変更できます）それら-彼ら自身の危険で！）

同様に、悪名高い複雑なセットアップの一部のアプリケーションには、コードをチェックアウトし、サーバーを構成し、アプリケーションをビルドしてローカルにデプロイする方法を新しい開発者に説明するドキュメントがあります。このプロセスを簡単にするために、1つのアプリケーションにはワークステーション専用のセットアップスクリプトさえあります。

私はひどい赤ちゃんですが、プロセスを理解して自分でドキュメントを作成する必要がありますか？

あなたはそうですが、ほんの少しだけです。これはすべてずっと前に文書化されているはずであり、開発者が去る前に、交換日まで（または可能であれば数週間）に完全な知識の伝達を行っている必要があるということは言うまでもありません。それは何も起こらなかったように聞こえます、そしてそれはとにかく今はすべて過去のものです。

ならどうしよう？私が去った開発者が多くの助けになるとは思いません。彼らはすでに新しい仕事をしていて、自分の人生で何が忙しいかを知っています。あなたの上司が彼らを助けるよう強制するために使用できる法的根拠はないと思います。彼らがいくつかの質問に答えるのに彼ら自身の時間の数時間を費やしたが、それを当てにしないでください。あなたはそれのほとんどを自分で理解するのに行き詰まっているようです。これにより、適切なプロセスを徹底的に文書化し、正しく理解する機会が得られます。あなたをフォローしている人はこれに感謝します！幸運を！

まず最初に、Visual SourceSafeを終了する必要があります。それは言う必要があると思います。少なくともTFSに移行してください。また、他のオプションもあります。

さて、それは終わりです。私はこれが「物事を正しく実行したい場合...」の場合だと思います。最終的な目標は、開発者が新しくインストールしたマシンをオンにして、ソースに接続し、最新の状態にして、f5（または、アプリケーションのショートカットを実行します）、動作するアプリケーションを持っています。

1つのオプションは、ゼロから作業環境を構築し、それをベースラインの開発者イメージとして使用することです。開発者が参加するとき、あなたがしなければならないのは、そのイメージを彼のマシンにデプロイすることだけです。

環境をより実践的な状態に移行する方法についての本がいくつかあります。私はFowlerシリーズの継続的デリバリーと継続的統合が好きですが、他にも選択肢があります。

現在の仕事を始めたとき、開発用PCをセットアップするための文書化された手順がありました。

私は自分で手順を実行し、既存のチームの「ヘルプ」を断固として避けました。

（知識はドキュメントに具体化する必要があり、最も長く続いた開発者ではありません。）

間違っていたり不完全だったりしている箇所に赤線の変更を加えて手順をマークアップしたところ、1週間後には、機能する手順と機能する開発用PCの2つがありました。

1年後のハードディスクの故障後、再構築には2日かかりました。

上司に言ってください。そのPCでハードドライブが故障した場合、開発は行われません。

2日は2日の無駄だと思いました。

次に、各開発プロジェクトでディスクイメージを備えた仮想マシンを使用します。

セットアップは、VMイメージをターゲットPCにコピーして開始することです。「runme」と呼ばれるアイコンをクリックすると、ユーザー名を尋ねられ、ソースコードへのアクセスに使用されるユーザー名が独自のものに変更されます。また、IDEの空白のドキュメント作成者フィールドを自分の名前に変更します。

（私はrunmeを約2時間で書きました。私たちは開発者であり、私たちは問題をプログラミングします）

開発者用PCは、VMサーバーを除いて標準的なマシンです。

高価ではないvirtualboxを使用しています。

仮想マシンを使用すると、マシンの交換が簡単な20分の仕事になります。このタスクは、VMをコピーするためにギガビットイーサネットを使用している場合に高速になります。

完全な開示：私は私が働いているチームリーダーであり、私の経営陣は私に自由な（-ish）手綱を与えます。

アプリケーションをコンパイルして実行するには、どのソフトウェアが必要かを示すドキュメントがいくつかあるはずです。

また、アプリケーションを実行するためにクライアントボックスが必要とするものを概説するドキュメントも必要です。

それらは同じリストではありません。

あなたの会社が新しい開発者を雇うとしたら、彼らがコーディングを始めるのにどれくらいの時間がかかるでしょうか？一日？一週間？コードのコンパイルに必要なソフトウェアがわからない場合、これはしばらく時間がかかる試行錯誤のプロセスになる可能性があります。しかし、それは一度だけ実行する必要があるものでなければなりません。

私の質問は、新しい開発者は何をしているのですか？これはあなたの仕事ではなく、彼の仕事であるべきです。彼は他の男の代わりです。はい、彼がドキュメントのない環境に入ったのは面倒ですが、物事をドキュメント化するのは彼の仕事であるべきです。彼に座って、開発環境が何であるかを理解し、それを文書化してもらいます。彼に、クライアントボックスでアプリを実行するために必要なものを理解して文書化してもらいます。

古い開発者に連絡することに関しては、私はしません。私見、開発者がドキュメントや知識の移転のない会社を辞めた場合、彼らはコンサルティングレートでいくつかの仕事をするために呼ばれることを望んでいます。それは専門家ではなく、報われるべきではありません。はい、あなた自身でそれを理解するのに少し時間がかかるかもしれませんが、あなた/チームはその過程で何かを学び、作成されたドキュメントは最新で最新のものになります。