Yuri Kuklachevは、他の同様のチームでは考えられない結果を長年にわたって一貫して示してきたチームをどのように作成しましたか？
UPD：断食は食物の奪取に関するものではありません。
ユーリ・ククラチェフの秘密は簡単です：
1.スペシャリストの正しい選択（非常に重要）
2.プロセスの正しい調整
これらの2つの原則を使用して、ソフトウェア製品の開発において効果的なチームを構築できます。
チームマッチング
人を壊し、改ざんすることは意味がありません;あなたの原則に一致する人だけを引き付けるように試みることはよいです。 私たちにとって重要なのは、新しい人が次の資質を持っていることです。
1.作成者
面接前に、私たちは常に候補者にテストタスクを与えます（これについては以下で詳しく説明します）。 完了したテストタスクは、一度書いたコードよりもはるかに優れています。これは、候補者が作成者であり、非常に興味があることを示しています。 コードには、能力、実行されたテスト-関心のレベル（
関心-能力のマトリックスを参照）および作業へのアプローチが表示されます。
インタビューでは、前の仕事で特定の問題をどのように解決したかを詳しく調べると、作成者を区別できます。 候補者に少し経験がある場合は、特定の問題を解決するための彼の最初のステップを尋ねることができます。
2.お金ではなく動機
興味があり興味を持っていることをしたい、仕事に参加する傾向がある候補者を探しています。 消費に熱心な男性は、創造力がほとんどありません。
これについては、候補者が人生で何を目指しているのか、以前の仕事で好きだった/嫌いだったものについて、自由回答形式の質問をすることで知ることができます。 多くの開発者にとって、このような質問は奇妙で馬鹿げているように見えるかもしれません。そのため、少なくとも「5年後に自分を見ますか」というテンプレートの質問をしないようにしてください。
3.新しいテクノロジーとアプローチを学びたい。
私たちは、チームが機能横断的であることを保証するよう努めています。 市場とテクノロジーは急速に変化しています。 これはすべて、人々が柔軟に適応し、新しいことを素早く学ぶことができることを必要とします。
理想的には、テストタスク自体が候補者にとって何か新しいものになる場合です。 たとえば、GitHubを一度も使用したことがなく、テストタスクにその使用が含まれる場合、これは、人が素早く方向付けできるかどうかを完全に示します。
インタビューでは、自由回答形式の質問が再び役立ちます。 たとえば、「新しい技術を習得する準備ができていますか？」など、明らかに社会的に望ましい答えを示唆する質問は避けてください。 過去数か月間、彼または関連する分野で何が新しくなったかを尋ねる方がはるかに生産的です。
4.適切に通信する
誰かが何らかの理由でホリバーを手配したり、他の人の間違いに対して弱い耐性を持っている場合、これはチームの雰囲気を台無しにします。
面接中にこれについて疑問がある場合、候補者は彼が同僚に不満を抱いており、彼らと対立していると言います。
ドリームチームマッチングのヒント
1.空室
すべては正しいジョブテキストで始まります。 他の空席のテキストを不注意にコピーすることはできません。 心の欠員を書き、候補者の代わりに自分を置いてください。
このビジネスはマーケティングに非常に似ています-他の会社の求人を見て、あなたの古い求人に反応した人を見た人の転換を追跡し、最も成功した人をハイライトし、成功した理由を分析します。 FreelansimとHuntimには統計があり、求職者のどの見出しとスニペットが応募者を引き付けるかを評価できます。
検索を絞りすぎないでください。 すでに何らかのテクノロジーを使用した開発者が必要だと書いた場合、機能しなかった優秀な候補者を見逃す可能性がありますが、3〜4週間でこのテクノロジーを研究し、作業に参加することができます。
たとえば、yiiで開発しますが、このフレームワークでの経験はそれほど重要ではないことを強調します
2.テストタスク
私はすでに、各候補者についてまず最初にテストタスクを発行することを書きました。 興味深いテストタスクが最適です。
33回目の同じことをしたい人はいません。 しかし、あまりにも創造的なタスクは不十分です-選択した候補者が仕事で直面するタスクにテストのものが似ているとより良いでしょう。
私は、候補者が私たちのテストにどのように反応するかを自慢するしかありません：
開発者ではなく、システム管理者/マネージャー/デザイナー/その他のスペシャリストを探している場合は、テストタスクの類似物を考え出す必要があります。 たとえば、マネージャーにとって、これは彼が最初にすることである、ポストに入るための計画かもしれません。
3.インタビューと選択
テストを送信した5〜10人の候補者がいると、インタビューを実施します。 テスト結果について話し合い、指定された基準に対して値を確認し、最も適したものを選択します。
テストタスクを送信したすべての人は間違いなく答える必要があります。より詳細に言えば、タスクの実装に時間を費やしました。
開発プロセスの構築
コードを保存するには、GitHubのプライベートリポジトリを使用し、タスクの追跡とドキュメントのメンテナンスに使用します。
あなたが役に立つかもしれないいくつかのヒント：
1.
優先順位付け。 GitHubでショートカットを使用する
ショートカットを使用すると、多数のタスクから優先順位を選択し、重要度の低いタスクをプッシュできます。
2.
ゾウを噛んで食べる壮大な運搬を避け、小さな運搬でそれらを打ち負かすために努力する方が良いです。 しかし、同じタイプの小さなもの-チェックボックス付きのリストで1つの問題にグループ化します。 これにはマークアップを使用します。
-[]タスクはまだ準備ができていません
-[x]タスクの準備ができました
3.
タスクの登録。 GitHub Flavored Markdownを使用すると人生が向上します。詳しく読むことをお勧めします
4.
目標と目的の透明性。 月曜日に、その週のタスクのリストを作成し、それらをマイルストーンに結合します。 振り返ってみると、マイルストーンの結果を分析します。これは開発プロセス中に改善できます。 成功、良いアイデアをお互いに賞賛します。これはチームの雰囲気に良い影響を与えます。
その結果、現在のタスクと長期的な目標の両方、つまりどこに行き、何を達成したいかが、チーム全体で明確に明確になります。 このようなプロセスは私たちの小さなチームに関連していますが、大規模なチームでは議論が遅れて時間がかかる可能性があるため、おそらく大規模なチームでは独自の形式を使用する必要があります。
5.
個人の責任。 各タスクには、1人の責任者のみが存在し、タスクに対する集団的責任はありません。
6.
スタンドアップラリー。 午前中は、誰が何をし、何が問題で、誰が今日何をするのかについての伝統的な質問を交えた簡単なスタンドアップラリーを開催します。
強調されているのは、作成されたタスクと作成されるタスクです。 スタンドアップは、誰が何をしているのかを全員が認識し、問題を迅速に解決するのに役立ちます。
7.
情報の最大可用性。 ドキュメントはwikiリポジトリで管理されています。 チームの全員が状況を認識して読むことができるように、チームに所属していない専門家と通信するときを含め、Skypeではグループチャットを広く使用しています。
8.
クロスコードレビュー。 毎週の終わりに、相互学習とコードの品質向上のためにクロスコードレビューを行います。
9.
ユーザーサポート。 何らかの形で、彼らはユーザーと対話し、彼らのサポートに連絡します。 これにより、誰もが製品とユーザーのニーズをよりよく理解できます。
10.
展開とテスト。 自動テスト実行で開発サーバーへの中間デプロイを使用してから、実稼働サーバーにデプロイします。デプロイプロセスについては、別のトピックで詳しく説明します。