私の名前はウラジミールです。私はVividMoneyでモバイル開発を担当しています。
Vivid Moneyは、支払いと送金、多通貨、財務分析、アカウント共有、投資など、幅広い機能を備えたヨーロッパ市場向けのフィンテックスタートアップです。最も近い競合相手はRevolutとN26です。
1年でモバイルフィンテックアプリケーションを作成し、正常に起動することができました。今年は、他のプロジェクトをリードしながら、約4年間頭の中で形成されていたアイデアを集めました。この記事では、これらのアイデアを、長期的かつ大規模なプロジェクトをゼロから開始するソフトウェアエンジニアリングマネージャー/リード向けのヒントの形で収集します。
前書き
1年ちょっと前、私はAndroidチームのリーダーとしてプロジェクトに参加しました。私は野心的で興味深い課題に直面しました。テクノロジーを選択し、チームを編成し、プロセスを設定し、そして最も重要なこととして、それをすべてうまく行うことです。良いというのはゆるい概念ですが、私にとっては、製品と技術の観点から見て高品質の製品です。
プロジェクトを最初から始めることは、理解できないことや難しいことと同じくらい面白くてエキサイティングな作業です。最初は何をつかむべきかわからないのですが、やるべきことがたくさんあるので、仕事の全過程は火を消すようなものです。
これを防ぐには、まず、活動の優先順位を明確に定義する必要があります。
私の意見では、リードの主な活動は次の順序で整理できます。
- 採用プロセスの構築。
- テクノロジースタックの選択。
- チームの相互作用を設定します。
- 開発およびテストプロセスの構築。
記事のこの部分では、最初のポイントのみに焦点を当てます。
免責事項：
この記事は含まれてい私に基づく考えや結論を私の大規模かつ長期的なプロジェクトでの作業の経験。ヒントのいくつかはハックニーのように見えるかもしれませんが、実際に示されているように、大企業やプロジェクトでもすべてが適用されるわけではありません。
建物を雇う
チームのさらなる仕事は人々の「質」に依存するので、私にとって、この点はそもそもです。
銀行を立ち上げるのに非常に野心的な時間枠がありました-1年。この間、定性的に膨大な量の機能を作る必要がありました。扶養家族で訓練が不十分な従業員のための時間はありませんでした。したがって、次のアドバイスが続きます。
評議会番号1。雇用の重要性を忘れないでください
弱い開発者がコードの品質と製品のバグの数に直接影響するという事実に加えて、完全な信頼がなく、継続的な監視が必要になるため、彼に委任することは不可能です。したがって、急速に成長するプロジェクトでは困難が生じます。
評議会番号2。面接でハードスキルだけでなく、ソフトスキルもチェック
多くの場合、ロシアでの開発者のインタビューは、言語/フレームワークの質問に帰着します。実際、ソフトスキルも同様に重要な役割を果たし、開発がより困難です。さらに、同じような考え方を持つ人は、チームに参加する可能性が高くなります。
私たち自身のために、次のソフトスキルを特定しました。
- 体系的な思考;
- きちんとした健康的な完璧主義。
- アドバイスではなく、経験に依存します。未確認の事実に疑問を投げかける。
そしてもちろん、基本的な非競合と人々とのコミュニケーション能力。
たとえば、候補者に「なぜ古い仕事を辞めるのか、新しい仕事を選ぶための基準は何ですか」という質問をします。体系的なアプローチが重要であるため、答え自体はそれほど重要ではありません。候補者は、自分が満足していないこと、論理的な方法でこれに到達し、頭の中ですべてを整理することができたことを認識していることを期待します。
候補者の考え方や原則を理解するのに役立つこのような質問の例としては、「理想的なチームはどのように見えるか」などがあります。または「理想的な開発プロセスはどのように見えますか？」
評議会番号3。インタビューを最適化する
インタビューは、改善および最適化できるメカニズムと見なされるべきです。または、リファクタリング可能なプログラムとして。
私たちが行った最適化の例を示します。
例12
人の開発者が各候補者にインタビューするのに約1.5時間かかります。この時間を最適化し、明らかに弱い候補者に無駄にしないために、スクリーニングを導入しました。スクリーニングは、答えを準備したいくつかの単純な閉じた質問です。採用担当者自身が候補者にこれらの質問をします。これには約10〜15分かかります。
いくつかの数字：
100人の候補者のうち、スクリーニング後、約3分の1、つまり約30人が排除されます。採用担当者は、各スクリーニングに約15分、つまり30人の排除された候補者の正味時間の約8時間を費やします。同じ30人の候補者に対する古典的なインタビューでは、最も楽観的なシナリオで約60人時間を費やしたでしょう。
例2
インタビューの目的は、最も関連性の高い候補者を選択することです。選択したテクノロジーのスタックを考慮に入れて、プロジェクトのハードスキルとスキルにとって重要なものを分析および特定しました。これにより、無関係な質問の一部を削除し、インタビュー時間を短縮することができました。
たとえば、プロジェクトで使用されていないAndroid SDKの部分（ContentProvider、JobSchedulerなど）に関連する質問を削除しました。これらの質問への回答では、これらの部分が含まれる通常のプロジェクト機能の開発に含まれるかどうかを理解できません。 SDKはめったに使用されません。
例3
最初に、技術面接は2つの別々の段階で行われました。理論的な質問と実際的なタスクです。これにより、候補者がインタビューのすべての段階を完了するのにかかる時間が大幅に増加し、IT市場は非常に競争が激しいため、多くの応募者が失われました。優れた開発者はすぐにオファーを受け取ります。
目標到達プロセスを最適化するために、インタビューをステージ1にまとめました。有益でない質問を削除し、アルゴリズムの問題を解決しました。私は前の段落で有益でない質問について書きました。ただし、アルゴリズムタスクをフレームワークの実用的なタスクに置き換えました。また、コーディングスキルとSDKの知識もテストします。
その結果、1.5時間の技術面接は1回のみでしたが、内容は可能な限り洗練されていました。
評議会番号4。「知識よりも理解が重要」
開発者を選ぶための最も重要な基準は「理解」でした。そのため、人は定義や学術的知識を与える方法を知っているだけでなく、特定のフレームワークの構造の理解を示します。この理解のない開発者は、問題に直面して、自分で解決策を見つけることができないか、問題を十分に最適に解決することができません。したがって、候補者が学んだ用語を提供するのではなく、あるトピックまたは別のトピックについて理由を説明するように、すべてのインタビューの質問を公開しました。そして、私たちは彼のトピックに関する知識と彼の論理のコースに従います。
たとえば、「AndroidでANR（アプリケーションが応答しない）検出器を作成するにはどうすればよいですか？」という自由回答形式の質問をします。この質問は、Androidでスレッドがどのように機能するかについての知識をテストしますが、ルーパーとハンドラーに関する直接の質問は避けます。また、マルチスレッドを使用してトピックに簡潔に切り替えることもできます。
評議会番号5。インタビューの機能を配布する
チームの急成長に伴い、面接は丸一日かかるほど多くなり、他の活動をする時間はありません。したがって、面接機能を部分的にチームに委任すると便利です。
これは、リードから負荷を取り除くだけでなく、開発者を潜在的な同僚の選択に含め、さらに彼を動機付けます。
さらに、候補者はチームを知り、自分自身のためにより全体的な体験を生み出します。
評議会番号6。チームのバランスをとる
採用するときは、チーム内の能力による人々のバランスを常に覚えておく必要があります。上級開発者が多すぎると、新しいソリューションを考え出すことができますが、開発者は機能を作成しません。しかし、プロジェクトの開始時に、今後何年にもわたって技術基盤が築かれるとき、それは必要です。さらに、通常の機能コードを作成する場合、署名者は不当に高額になります。ジュニアが多すぎると、コードベースが劣化し、その結果、長期的にはプロジェクトが沈没します。しかし、賢いジュニアはすぐにミドルに成長し、市場のミドルよりも会社とチームにはるかに忠実になります。私の意見では、このバランスはプロジェクトや特定の状況ごとに異なるため、特定のパーセンテージは示しません。
多くの場合、開発をスピードアップするために、チームは請負業者で希薄化されます。多数の請負業者もプロジェクトのコードを劣化させる可能性があるため、ここではバランスも非常に重要です。請負業者が、プロジェクトに対して正社員と同じ動機と関心を持つことはめったにありません。
評議会番号7。発砲することを恐れないでください
最後に、チームから人々を解雇することを恐れる必要はありません。原則と精神または技術的スキルの点でチームに適合しない人は、現時点でコードを書くことの利点よりも、長期的にははるかに多くの害を及ぼします。
発砲するのは簡単に聞こえますが、従業員とチームにとって可能な限り苦痛を伴わずにそれを行うにはどうすればよいですか？原則はここで機能します：「あなたが何をするかは重要ではありませんが、それがどれほど重要か」。事前にすべてを行う場合（役割からの期待について話し合い、試用期間の終了を待たずに時間どおりに作業についてフィードバックを提供し、コメントの理由を提供する）、これは従業員にとって驚きではありません。
チームに理由を公に理解させることも重要です従業員は解雇されました。そうしないと、チームに恐怖を植え付け、チームの雰囲気を台無しにする可能性があります。
評議会番号8。新しく到着した従業員からフィードバックを収集する
採用プロセスは、インタビューと初心者のオンボーディングの2つの段階で構成されます。
オンボーディングは、初心者だけでなくプロジェクトにも役立つはずです。
プロジェクトに没頭した後、新しい人々はオープンな外観で問題のある領域を見て、新鮮なアイデアを与えることができます。そのため、アプローチとコードベースを改善するための意見や推奨事項を意識的に聞いて分析するというルールを作成しました。これらの推奨事項のいくつかは、プロジェクトで正常に実装されています。
たとえば、Androidチームのメンバーの1人が到着した後、メモリ内キャッシュにデータを保存する方法を完全に改訂しました。
結果
結論として、私たちのモバイルチームはほぼ1年半で26人に成長したと言いたいです。すべての開発者は良い仕事をしており、誰も自分たちの意志でチームを離れることはありませんでした。製品のリリースに成功し、品質と開発速度を損なうことなくリモート作業のテストに合格しました。
この記事で収集したヒントがあなたにも役立つことを願っています。
次のパートでは、テクノロジースタックを選択してチームの相互作用を設定するためのアプローチについて説明します。