リーダーシップは、マシン構成と新しい開発者志向の標準プロセスに価値を見出していません
約3か月前、私たちの主要なWeb開発者とデザイナー（同じ人物）が会社を辞めました。緑の牧草地が退職の理由でした。私が言う彼らにとって良いことです。私の問題は、彼の部門が完全に文書化されていないことです。リードが去って以来、物事は厳しく、新しいプロジェクトを引用するために使用する理論的知識と、彼の辞任の結果として失った既存の製品の技術的/実装的知識の両方の知識がたくさんあります。私の通常の役割は、製品マネージャー（製品自体）およびプロジェクトベースのコンサルティング業務のビジネスアナリストです。私は過去1年間コードを習得し、前進し続けるために、ラップトップを開発マシンとしてセットアップするタスクを引き受け、より簡単な機能要求のいくつかを実装し、いくつかの修正を行うことを望んでいます。チケットシステムに送信される簡単なバグはありません。ただし、新しいWindowsマシンを取得して、本番用アプリとシームレスに動作するように構成する方法は誰にもわかりません。
去った開発者とまだ連絡を取っている上司に、新しい開発者をオンボーディングするプロセス、ソフトウェアのインストール、必要なパッケージ、本番アプリケーションサーバーにデプロイするプロセスなどを文書化して作成するように依頼しました。これは存在し、コンピュータを機能開発マシンとして機能させるために、私はホイールを回転させています。しかし、彼女はそのようなプロセスが存在する必要性を理解していないようです。どうやら、去った人を入れ替えた新しい開発者は、私たちの環境用に事前構成されたマシンを使用していたので、別の開発者を追加すると、新しい開発者でさえ新しいマシンをセットアップできませんでした。
私の質問は2つの部分です：
新しいコンピューターをオンボードして、開発エコシステムの一部として構成するプロセスが存在する必要があると想定するのは間違っていますか？
私は気まぐれな赤ちゃんですか？プロセスを理解して自分でドキュメントを作成する必要がありますか？
まず第一に、開発者が作業環境をセットアップしなければならないのは奇妙です。このタスクは通常、システム管理者向けです。したがって、これはあなたが行うべきことではないことを考慮に入れて、あなたは誰かがあなたのためにこれを行うことを期待する権利を持っています。
ほとんどの（すべてではないにしても）企業では、通知期間があります。通常、1週間から1か月の範囲です。しかし、とにかくその時間は会社を助けるために去る人にとって十分です_いくつかのドキュメントを作成し、コードにコメントを追加し、アーキテクチャをドキュメント化します。今これを行うには遅すぎるのではないかと思いますが、忘れないでください次回誰かが去るとき。
新しい環境をセットアップするためのプロセスがあるはずだと期待するのは絶対に正しいです。実際、会社が成長し、開発者が増えた場合、同じ問題に直面することになります。これは、上司を説得するための重い議論になる可能性があります。引数を使用して、そのようなタスクのためにシステム管理者を雇うように経営陣を説得することもできます（問題に直面しているので、あなたはそれを持っていないと仮定します）。開発環境の設定に加えて、新しいマシンがある場合は、ローカルネットに統合する必要があります。
新しいコンピューターをオンボードして、開発エコシステムの一部として構成するプロセスが存在する必要があると想定するのは間違っていますか？
いいえ。これらのプロセスを使用すると、すでに直面している問題を回避できます。一部の大規模な組織では、開発者のマシンがどのように見えるかを示す標準のディスクイメージがあります。新しい開発者が採用されると、適切なハードウェア仕様を備えた利用可能なコンピューターがワイプされ、この「開発者」ディスクイメージを使用して再イメージ化されます。標準のチェックリスト（イメージに含まれていない特定のツールのイメージング後のソフトウェアインストールが含まれる場合があります）の後に、すべての開発者のマシンが同じように起動することを保証するためにこれを行う技術者が続きます（ユーザーは取得後にそれらを微調整して変更できますそれら-彼ら自身の危険で！）。
同様に、悪名高い複雑なセットアップの一部のアプリケーションには、コードをチェックアウトし、サーバーを構成し、アプリケーションをビルドしてローカルにデプロイするための新規開発者howを説明するドキュメントがあります。 1つのアプリケーションには、このプロセスを簡単にするためのワークステーション専用のセットアップスクリプトもあります。
私は気まぐれな赤ちゃんですか？プロセスを理解して自分でドキュメントを作成する必要がありますか？
あなたはそうですが、ほんの少しだけです。これはすべてずっと前に文書化されているべきであり、去った開発者は彼らが去る前に彼らの交換日（または可能であれば数週間）に完全な知識移転を行うべきだったと言うことは一つのことです。それは何も起こらなかったように聞こえます、そしてそれはとにかく今はすべて過去のものです。
ならどうしよう？私が去った開発者が多くの助けになるとは思いません。彼らはすでに新しい日の仕事をしていて、誰が彼らが自分の人生で忙しいのかを知っています。あなたのマネージャーが彼らを助けるよう強制するために使用できる法的根拠があるとは思えません。彼らがいくつかの質問に答えるのに彼ら自身の時間の数時間を費やしたが、それを当てにしてはいけないならそれはいいです。あなたはそれのほとんどを自分で理解するのに行き詰まっているようです。これにより、適切なプロセスを完全に文書化し、正しく理解する機会が得られます。あなたをフォローしている人はこれに感謝します！幸運を！
まず最初に、VisualSourceSafeを終了する必要があります。それは言う必要があると思います。少なくともTFSに移行してください。また、他のオプションもあります。
さて、それは邪魔になりません。これは「物事を正しくやりたいのなら...」の場合だと思います。最終的な目標は、開発者が新しくインストールしたマシンをオンにしてソースに接続し、最新のものを入手し、f5（またはあなたが使用するものなら何でも）を押すことです。アプリケーションショートカットを実行）、動作するアプリケーションを用意します。
1つのオプションは、作業環境をゼロから構築し、それをベースライン開発者イメージとして使用することです。開発者が参加するとき、あなたがしなければならないのは、そのイメージを彼のマシンに配備することだけです。
環境をよりハンズオフ状態に移行する方法についての本がいくつかあります。私はFowlerシリーズの Continuous Delivery および Continuous Integration が好きですが、他にも選択肢があります。
私が現在の仕事を始めたとき、開発者用PCをセットアップするための文書化された手順がありました。
私は自分で手順に従い、既存のチームの「助け」を断固として避けました。
（知識は、最も長い間存在していた開発者ではなく、ドキュメントに具体化する必要があります。）
私は、手順が間違っていたり不完全だったりしているところに赤線の変更を加えてマークアップしました。1週間後、2つのことがありました。
1年後のハードディスクの故障後、再構築には2日かかりました。
上司に連絡してください：そのPCでハードドライブが故障した場合、開発は行われません！
2日は2日の無駄だと思いました…。
次に、各開発プロジェクトでディスクイメージを備えた仮想マシンを使用します。
セットアップでは、VMイメージをターゲットPCにコピーして起動します。「runme」と呼ばれるアイコンをクリックすると、ユーザー名を尋ねられ、アクセスに使用されるユーザー名が変更されますソースコードを独自のものに変更します。また、IDEの空白のドキュメント作成者フィールドを自分の名前に変更します。
（私は約2時間でrunmeを作成しました。私たちは開発者であり、問題をプログラムします）
開発者のPCは、VMサーバーを除いて、標準的なマシンです。
高価ではないvirtualboxを使用しています。
仮想マシンを使用すると、マシンの交換は簡単な20分の作業になります。 VM over）をコピーするギガビットイーサネットがあれば、このタスクはより高速になります。
完全な開示：私は私が働いているチームリーダーであり、私の経営陣は私に自由な（-っぽい）抑制を与えてくれます。
アプリケーションをコンパイルして実行するために必要なソフトウェアについてのドキュメントがいくつかあるはずです。
また、アプリケーションを実行するためにクライアントボックスが必要とするものを概説するドキュメントも必要です。
それらは同じリストではありません。
あなたの会社が新しい開発者を雇うとしたら、彼らがコーディングを始めるのにどれくらいの時間がかかりますか？一日？一週間？コードのコンパイルに必要なソフトウェアがわからない場合、これはしばらく時間がかかる試行錯誤のプロセスになる可能性があります。しかし、それは一度だけ行う必要があるものでなければなりません。
私の質問は、新しい開発者は何をしているのかということです。これはあなたの仕事ではなく、彼の仕事であるべきです。彼は他の男の代わりです。はい、彼がドキュメントのない環境に入ったのは残念ですが、物事をドキュメント化するのは彼の仕事であるべきです。彼に座って、開発環境が何であるかを理解し、それを文書化してもらいます。クライアントボックスでアプリを実行するために必要なものを理解して文書化するように彼に依頼します。
古い開発者に連絡することに関しては、私はしません。 IMHO、開発者がドキュメントや知識の伝達なしに会社を辞めた場合、彼らはコンサルティングレートで何らかの仕事をするために呼ばれることを望んでいます。それは専門家ではなく、報われるべきではありません。はい、自分でそれを理解するのに少し時間がかかるかもしれませんが、あなた/チームはその過程で何かを学び、作成されたドキュメントは最新で最新のものになります。