開発チームを1から2にスケーリングする際の課題は何ですか？
私は20人の開発チームと非常に強力なエンジニアリング文化を持つ中小規模のスタートアップで働いています。エンジニアリング自体は小さなサブチームに分割され、私は特定のコンポーネントを担当する唯一の人物です（これは組織全体にとって非常に重要です）。
これでようやく別のエンジニアを雇って私と一緒に仕事を始めることができました。これは素晴らしいことであり、多くの助けになりますが、ソロ開発チームから離れるという固有の課題が伴います。
チームに2人目のエンジニアを追加するときに存在する課題は何ですか？私はすでに この質問 を見ましたが、ここで受け入れられた回答はgood onboarding processしかし、それが実際に何を意味するのかについては、詳細には触れません。この移行を成功させるために、毎日どのようなことを変更する必要があるかを理解することに、より関心があります。
基本的に、それはすべてコミュニケーションに帰着します。
プロジェクトで作業しているのがあなただけの場合は、チームが行う方法でプロジェクトを必ずしも文書化する必要はありません。ドキュメントをまったく書かず、2年後にはすべてを覚えていると信じるか、自分の視点からそれを行います。これは、初心者にいくつかの課題をもたらします。
- あなたにとって明確であるかもしれない処方は、他の人にとってそれほど明確ではないかもしれません。
- 仮定は完全に文書化されていない場合があります。あなたにとって、これらの仮定は自然です。他の人はそれらを自然とは思わないかもしれません、またはそれらを完全に間違っていると考えるかもしれません。
設計またはアーキテクチャに関して行った選択は明確に文書化されていない場合があります。これは、それらの選択を行ったのはあなただけだったからです。チームによって選択が行われると、それが議論され、その議論から、そのようなことが所定の方法で行われた理由を説明するドキュメントを書くのは比較的簡単です。あなたはおそらくあなた自身との議論を持っていなかったので、おそらく選択自体だけを文書化しましたが、選択の理由は文書化していません。
コードの中で明らかなあなたにとっては、文書化されないままにされるかもしれません。それらのことが他の人にとってほとんど明白である場合、それは問題です。これは、他の人が知らないことを知っているときに、特に発生する可能性があります。たとえば、リアクティブプログラミングに優れていても、相手がそうでない場合、彼は2行を超えるすべてのリアクティブ式が文書化されることを期待しますが、理解しやすいものを文書化するポイントはまったくわかりませんコードから。
それに加えて、新人はもう一つの困難に直面するでしょう：
- 歴史的要素。あなたのプロジェクトは、ある時点で起こったイベントのために進化しました。あなたはそれを知っているので、説明を必要としないことがたくさんあります。他のサービスにはJSONシリアライザーのバグのある実装があり、2年前の大晦日に本番がクラッシュしたため、JSONの代わりにXMLを使用したことがわかります。しかし、初心者はこの外傷的な出来事について何も知らず、XMLを使用する理由はなく、簡単にJSONに切り替えることができると信じているかもしれません。
したがって、あなたの目標は、新しい開発者と緊密に連携し、この質問がどれほど愚かに見えても、どんな質問に対してもオープンにすることですあなたに。成功するかどうかは、明確に答える能力と、新規参入者にとって最も驚くべきことを適切に文書化するために時間をかけることに大きく依存します。
Arseniの回答に加えて、利用可能で正しいbeforeオンボーディングに関するすべてのドキュメントが少なくとも利用可能かつ正しいafterオンボーディングであることを確認してください。新しい人のための最初の仕事。
コードレビュー、タスクリスト、誰がどのジョブを開始するかを決定するなど、より整理しなければならない場合があります。
まず第一に、アルセニがすでに書いたすべてのものを検討してください。
私が投げ入れたいもう一つのポイントは、物事の個人的な方法です：私はあなたが人間であると想定しているので、あなたにはyour問題解決のスタイルとyourがあります=あなたの仕事に近づくスタイルとyourコードを書くスタイル。
そして今まで、ソフトウェアは100％あなたのやり方でした。
これで、別の人がhisスタイルとhisアプローチなどを持ちます。あなたがずっと7人のチームのメンバーであったなら、あなたはすでに他の人々のアプローチに対処することに慣れているでしょうが、プロジェクトが100％にならないことに対処する必要があります。
したがって、物事を行う方法が1つだけであると想定して、新しい同僚を失望させないでください。他のアプローチに対処します。彼があなたの個人的な方法に合うようにすべてを書き直すという衝動に抵抗します。客観的に明らかに間違っている場合にのみソリューションを拒否します（たとえば、ストリームを使用するループまたはその逆のループを使用しているためではありません）。
技術レベルで誰が製品を所有するかは明確でなければなりません。あなたはあなたが仕事を成し遂げるのを助けるための相棒を得るという考えを持っているかもしれません。他の人は、あなたが台無しにしたものを修正するために彼らが本当の開発者を連れてきたアイデアを持っているかもしれません。突然の責任分担ほど破壊的なことはありません。 1から2への移行は、開発チームにとってこれまでに発生する最大の変更です。明確な期待が必要であり、技術的な所有権は石に刻まれるべきです。