バスに轢かれた時の心構えは？

ドキュメント。

適度な頻度でコードをコミットする。また、あなたのアイデアやデザイン、コードを文書化してください。

もしあなたがポリシーが緩い環境で働いているのであれば(ジュニアの開発者はドキュメントの変更を提出しないようにしてください - 関連するドキュメントの更新はすべてのブランチマージと一緒に_義務づけられているべきです)、ピアレビューがない環境で働いているのであれば(ジュニア/シニアの開発者は理解できる怠惰の間に捕まってしまいます)、ドキュメントはコードとは別に保存されているのであれば(簡単に失われてしまう可能性があります)、これらの問題が起こらないように環境を変えられるかどうかを考えることも重要です。そうでなければ、ドキュメントを書いているあなたの努力が無駄になってしまうかもしれません。

そうは言っても、私はそれを個人的な責任と呼ぶには、いつもそこまで行かないでしょう。

その考え方は、「バスに轢かれた」というケースでは通用しません。このような場合は、経営陣（および上級開発者）に、できるだけ早くこのようなことに真剣に取り組み始めるように働きかけることをお勧めします。

NOTHINGを別の方法で行う。

この問題は組織の問題であって、あなた自身の仕事の目標に明示的に取り上げる必要はありません。もし経営陣がここでの潜在的な問題に気づいていないのであれば、それは彼らが完全に手を抜いていることを意味しますし、あなたが思っていたほどあなたは必要不可欠ではないかもしれません。しかし、企業が目先の利益のために気まぐれにキャリアを「バスに轢かれて」しまう時代に、どれだけ気を遣うべきなのでしょうか？

「バスに轢かれて」というジレンマの多くの問題を解決してくれるのが、真面目なエンジニアリングの実践です。それを超えて、即時かつ恒久的に消滅する準備ができているところまで行くことは、個々の貢献者にとって多くのオーバーヘッドを生み出すことになります。それは、OPによって記述された環境は、単により良いプラクティスとスタッフの配置によって恩恵を受けることができるように聞こえる、彼がいつでも蒸発するかもしれないかのように働く必要はありません。

もしあなたが請負業者として働いているのであれば、これは100%あなたの雇用主に責任があると言えるでしょう。彼らはあなたのために設定されている目標を達成することは、あなたが目標とみなされるべきだと思う他のものが行われていないことを意味することを教えて、彼らはあなたの目標を調整したいかどうかを尋ねる。彼らは、あなたの時間は高価であり、彼らはお金のための最高の短期的な価値を望んでいるので、彼らはよく、あなたがそのまま続行するように言うかもしれません。それでも、彼らは問題について知っている必要がありますし、あなたがどのようにしているか、そしてあなたがすべきだと思いますので、あなたのチームのリードやマネージャーとそれを持って来る、あなたの時間を費やしています。

いくつかのことは、それが後継者のための計画に役立つだろう：

• 毎日のプロセスは、ある程度文書化されるべきですが、それはあなたのチームの他の人々が同じプロセスに従うと新人にそれらを教えることができる可能性があります。もし全員が同じようなプロセスを使っていないのであれば、それは解決すべき現在の問題です。
• メールや会議、何気ない会話で伝えられる重要なことは、共有ドライブ上のドキュメントのフォルダからwikiまで、共有リソースにする必要があります。これは、チームメイクが変化することを考慮に入れていないし、どんなトレーニング（もしそれが起こったとしても）も、すべての知識を転送することはありませんが、頻繁に使用される知識のサブセットのみが転送されることを考慮に入れています。例えば、あなたのクライアントが「正しくない」と思われる何かをするようにあなたに頼んだ場合（「私はドメインの専門家ではありませんが、本当にそうしたいのですか？ソフトウェアが仕様通りに機能しているということだけでは、リプレースのためには十分ではありません。
• 解決するために多くの時間/研究が必要な問題に遭遇した場合、問題、症状、解決までの最短経路(つまり、今知っていることを知り、症状を特定してから解決までの最短経路は何だったか)、および解決策を文書化してください。なぜなら、問題を完全に把握する前に、問題を発見してしまうからです。
• 前述のポイントは、ライブラリやプラットフォームのように、新しいバージョンがリリースされているが、製品では使用されていないレガシーシステムに関しては、さらに重要です。あなたのバージョンで遭遇した問題は、将来のバージョンで解決される可能性があるため、その欠陥の存在は、その欠陥についての情報を見つけることがほとんど不可能になるまで、世間から消えてしまいます。

休暇は、そのようなものに備えるための良い「訓練」になります。また、どれだけ準備ができているかを測るのにも役立ちます。2-3 週間後に仕事に戻り、「バックログ」の掃除に費やされた日数と労力を数える - これは「ヒットバイバスのシナリオ」の近似値を作ることができます。自分が解決しなければならないバックログ項目を分析して、これを他の誰かができるようにするにはどうしたらいいのか、と自問自答してみましょう。過去の仕事の1つでは、これは私が1年未満で約3週間から2日に約2日に “休暇のバックログ "努力をドロップするのに役立ちました。

• 私はこの情報を持っている唯一の1つであるように見える、私はチーム全体のために利用できるようにするためにそれを文書化する必要があります。
  このバグは私以外には誰にも直せません。バックアップ要員を見つけて訓練しなければなりません。どのくらいあなたがバスファクターと戦うためにwantするかを自分自身に尋ねて、それに応じて進めてください。 そうすれば issue tracker で私の記録を見ている他の人は、私がそれに取り組んでいる間に考えていたことを 図解 に私の助けを必要としません
• …そうすれば、私の wiki ページ を読んでいる他の人は、私がそこに文書化されたものを説明する必要はありません
• … …私がどのように私が作ったものが成長し、繁栄し、自分の人生を生きているかを見て楽しむことができるように

…私は何を残したかについての心配に気を取られることなく、新しいものを行うことに集中することができるように。

あなたのチームに聞いてみてください。上司に聞いてみてください。あなたが私たちに持っている方法で彼らに問題を提示してください。

彼らにオプションを与えてください。将来の開発者のためのドキュメント。彼らのためのドキュメンテーション。技術的な負債の返済。あなたが考えられることは何でもしてください。彼らに時間の見積もりを与える。選択肢を与えてください。日々の仕事との兼ね合いも考慮してくれ 決めるのは彼ら次第だけどね

決めたのなら罪悪感を感じないようにしてね

私は手を差し伸べて、それらの質問に答えたかった…

私が今までに学んだ中で最も難しいレッスンは、それらの質問に答えないことでした。しかし、自分自身のための答えを見つけるために彼らを導くために正しい質問をするために、疑うことなく、。

与えられた答えは、学んだ教訓とは異なります！

説明

基本的には、OPが対処している失敗の単一のポイントを作成する2つの異なるシナリオがあります。それはまた、成長する知識のギャップを認識し、対処するために不作為または失敗の結果である可能性があります。

方法に関係なく、ビジネスは、彼らが彼らの知識ベースのコアを形成する単一の個人または個人の小さなグループにスーパー依存を持っている状況を作成します。多くの企業では、メンタリングプログラム、クロストレーニング、そして公式と非公式の知識共有の両方を使用して、これに対処しています。私の経験では、これが最も成功している企業はティーチングアプローチを促進していると言えます。教え方は確かに両方の道を歩むことができます。私が「行く人」と「守る人」と呼んでいるものです。どんな仕事やプロジェクトでも 任せられるし 心配する必要もない これらは、会社の中で自分のニッチを切り開いて、人に行く人になり、答えを持っている可能性が高いものになる人々です。彼らは自分の知識を守ることで、会社での自分の地位、重要性、将来を保証していると感じています。

一言で言えば、世界のドキュメントのすべては、失敗の単一のポイントの根本的な問題を解決しないということです。はい、それは重要であり、すべてのBCPと災害対策計画の一部であるべきです。しかし、ドキュメントは、誰かが手の前に200ページのドキュメントをかき分けることなく、あなたの仕事のタスクを実行し、ステップインすることができるべきであるという意味では、実際に知識の共有ではありません。

私が働いているところでは、以下のようなことをしています:

a) 文書化のためにwikiを使用しています。Microsoft Word ファイルやテキストファイルではありません。(私は Confluence をお勧めしますが、Confluence v4 は他の場所を探すことをお勧めします)

• 反復的なプロセスや委任可能なプロセスは文書化する必要があります。
• 「ここでは私たちがどのようにするか _______\」のチェックリストは書かれるべきです
• チェックリストは、リストに従うことができる誰でもプロセスを可能にするので、チームを構築するために非常に重要です…

b) バージョン管理、明らかに

c) ケース/問題の追跡システム、明らかに

d) あなたの仕事にコメントをつけること。これは最もニュアンスのあることで、教えるのがとても難しいのですが、契約者/独立者としては、これをグロッキングすることができるかもしれません。コメントは、あなたの思考プロセスと、あなたが何をしているかの理由を説明する必要があります。ドキュメントやStack Overflowなどへのリンクが適切です。コメントは段落やページが適切です。やってみたこと、やってみなかったことを説明するのが適切です。コードの最大の問題の一つは、ある方法で（別の方法とは対照的に）何かを動作させるための思考と汗が失われてしまうことです。美しいコード」のような本がありますが、それは、大きなオープンシステムである VCS Subversion または Git だったと思います）の一つのユニットのコメントブロック上のチャンクを持っています。) それが物語っているので美しいです。このコードが何をしているかというと、次のようになります。これがどのように動作するかです。これがどのように構成されているかです。(私の記憶では、このブロックは、「なぜ」という質問には大きく入らないかもしれないことを告白します。)

これの従属関係は次のとおりです。どのくらいの人がコメントを追加するためだけにコードを編集しているのでしょうか？私たちは皆、そうすべきです…たくさん。しかし、実際にはほとんどの人がそうしていません。

NetflixにはChaosMonkeyと呼ばれるシステムがあります。これは本質的にはランダムに特定のシステムを壊すことを「壊す」かエミュレートするものです。ChaosMonkeyは、同僚に内緒で映画を見に行くように言っています。短期的には、あなたがバスに轢かれたのと同じような効果があります。

これは、より堅牢なシステムの方が故障が少なく、注意が必要な大規模なバグも少ないので、知識の伝達に役立つかもしれません。基本的にFDICは、銀行が主要な銀行の従業員に少なくとも2週間連続で有給休暇を課すことを推奨しています。仝それにしても、このようなことがあったのですね。第一の考慮事項は、これにより銀行は、退社する従業員の責任を担う別の人物を指名せざるを得なくなるということです。退任する従業員が横領をしていた場合、後任の従業員の監視下でスキームは崩壊します。これは、銀行がバスの攻撃を受けにくくなることも意味しています。

私なら

1. 標準化

2. 定期的かつ強制的なコード/プロジェクトのレビュー

3. チームスピリット

4. 明らかに ドキュメント。古い歌です。もう二度と歌わない

これは、バスに襲われた場合よりも大きな災害に備えた計画についてですが、このプロセスでは、重要なプレーヤーが密猟されているような小さな事件から、建物を奪う災害のような大きな問題に回復するためのピースを配置し、それらのスタッフを配置します。Wiki-Howには、「BCPの作成方法」(http://en.wikipedia.org/wiki/Business_continuity_planning)についての記述があり、実際にこの方法を使用することをお勧めしませんが、BCPを作成するために必要なプロセスや考え方についての良い洞察を提供しています。一般的にBCPは、最大のリスクを処理し、より可能性の高いシナリオを最初に準備し、リスクの低い懸念事項に対処するという段階的なアプローチで行われます。しかし、各会社は一般的に彼らの自身の必要性に従ってそこにBCPを造る従って正確なプロセスは変わる。

プロセスは一般的に含む:

-リスクの区域を識別しなさい -文書化しなさい -関係したプロセスを -さまざまなsceneriosへの適切な応答を決定しなさい -sceneriosに対処するためにEnactの計画

• 誰かがスクリプトやルーチンを書いたら、**誰かがそれを最初に本番で使わなければなりません。
• 誰かが新しいシステムを導入したら、誰もそのシステムを使用したり、サポートしたりしません。それはあなたの後継者があなたの仕事をリバースエンジニアリングすることを可能にします。

事実上、「まだリスト化されていない/テストされていないものは、私たちのためには存在しない」のです。リスト化されているものだけが信頼できるのです。

私たちはそれを" arcane knowledge“と呼んでいます。(誰かの頭の中にしか保存されていない) そして誰もがそれに基づいて行動することを拒否しています。

明らかにそれはハイテクな話題と非ハイテクな話題の間では機能しません。しかし、私たちは技術者が経理部から財務計算を引き継げるとは思っていません。ということは、経理部でさえも、たった一人の経理担当者が計算をしていたら、「墓場までの知識」を持っていかれてしまうかもしれないのです。チームが少なすぎると、必ず誰かがバスに轢かれることになる。

以下のポイントは、あなたに渡された業務内容書に記載されており、会社のオーナーが制定したものです。その場所でこれを持っている彼らの責任。しかし、これが必要であることを伝える知識を持っているのはあなただけかもしれません。

• あなたの分野や組織のために確立された基準の中で仕事をすること。
• あなたが何をするかを文書化すること。
• あなたが確立された基準から逸脱している場合、なぜそうしたのかを詳細に文書化すること。それのための長いランダムなパスワードを生成します。紙に印刷してください。署名する。それを封筒に入れて封をし、CEOではなく取締役会に渡す。CEOは悪い条件で会社と別れることができるので、パスワードはまだ持っています。それを安全に格納するためにそれらを伝えるオフサイトとそれの使用（それはあなたの不在または適用される可能性があります他の理由の場合には、ネットワーク上のスーパーユーザーのステータスを与えることができます）。