それで、あなたは世界に新しいソフトウェア製品またはサービスを提供することに決めました。 よく考え抜かれたアイデア、ビジョン、明確なポジショニング、最初の数人の潜在的な顧客、さらには予算さえあります。 一般的に、中小企業は開発チームを集めて製品を作ることです。



この記事では、人を選択するときの正しい決定と間違った決定、彼らの動機付け、チームの維持を考慮します。これが新しい資産です。 最高の人材をどのように採用し、完璧な開発マシンを構築するかについてではなく、人材の選択と作業の組織化における重大な間違いがあなたの仕事を台無しにする可能性があることについてです。

パートI.リスク

理想的な状況では、新製品の開発は次のようになります。人々を募集し、見たとおりに製品を説明し、用語に名前を付けます。 チームは仕事を辞め、適切なタイミングで完成した高品質の製品を持ち込み、それが徐々に（そして迅速かつ効率的に）完成します。



人生では、もちろん、これはめったに起こりません。 いずれの場合にも一連の問題がありますが、一般的には非常に典型的なものです。 したがって、プロジェクトの開始時でさえ、最も一般的なリスクのセットを記述することができます。そのいくつかは、作業の過程で一般的な問題として認識されます。 最も頻繁に実装されるものを見てみましょう：

1. 致命的な先延ばし。 製品は開発中であり、高品質であることが判明しました。機会の窓が閉じているか、予算が終わっているかのいずれかです。
2. 安定した低品質の製品。 製品は準備が整ってリリースされており、顧客は来ていますが、製品を使用するときに常に問題に直面しています。 そして、チームは毎週、毎月、通常の仕事を提供することはできません。 クライアントは立ち上がったり、立ち去ったりしません-競合他社にも、どこにも行きません。
3. 新しい要件の面倒な実装。 顧客は並んでいて（中にはお金を持っている人もいます）、新しい機能を追加するように求めていますが、何らかの理由で、洗練が非常に遅いです。 または、開始から1年後の大量のユーザーデータでは、すべてが突然非常にゆっくりと動作し始め、問題をすばやく解決する方法を誰も知りません（そして、クライアントは最後の言葉であなたをscり、去ります）。 一般的に、製品の「内部品質」の低さについて話します。失敗したアーキテクチャ、コードの重要なブロックのテストの欠如、複雑な内部依存関係-これらはすべて、合理的な速度で製品を開発し、顧客と戦うことを許可しません。
4. 実行可能なチームの損失。 ある時点で、キースペシャリスト（特にそのようなスペシャリストが1人だけの場合）は、突然、彼らが別の会社で働いたり、路面電車に乗ったりするのがより面白いと判断する場合があります。 残りのチームは、開発できるだけでなく、許容できる品質の製品を維持することさえできません。 そして、インタビューの候補者は、潜在的な同僚の憧れの目を見て、次にコードを見て、もはや連絡を取りません。

トラブルは単独では発生せず、多くの場合、一度にいくつかのリスクが発生します。 たとえば、期限の致命的な遅延、一貫して低品質の製品、および新しい要件の面倒な実装の両方があります。 この場合、実行可能なチームを失うリスクは、そこになかったため、実現する可能性は低いです。



または、製品が迅速かつ効率的に製造される場合、顧客の特定の問題をうまく解決できます。 しかし、今では追加の機能を追加したいという要望があり、元のソリューションはそのような要件が決して存在しないという事実を定めました。 新しい機能は、長くて難しいバランスのとれた松葉杖システムによって実装されます。 そして、これはすべて主要な専門家を悩ませ、彼らは去ります。



これらのリスクのいずれか、またはいくつかの組み合わせであっても、それが実現することは、製品とビジネスの文ではありません。 原則として、努力して製品を持続可能な開発のレールに戻すことができます。 特に、会社がすでにまともなお金を稼いでいる場合。 しかし、費やされた時間とお金は開発に費やされることはなく、顧客は問題を解決するためにずっと待つことになり、競争は有利になります。 予防は治療よりもはるかに安価です。 彼女について話しましょう。

パートII 資格と動機

開発者（ただし、これは開発に関係する他の専門家にも適用されます）には、2つのわずかに条件付きですが非常に重要なパラメーターがあります。 これは資格と動機です。



資格は、人が自分の仕事をどれだけうまくできるかを表します。 そして、やる気は、彼がこの能力を実際にどれだけ実現するかを決定します。



4つの極端なケースについて説明します。

1. 最高の資格、オフスケールの動機。 これは止められないクリエーターです。 効率的かつ簡潔です。 彼はすでにこれをすべて行っているため、自分が何をしているかを常に知っています。 動けなくなるため、昼夜を問わず機能します。
2. 最高の資格、動機はマイナスになりました。 彼は全能でもあり、何も必要としません。 どういうわけか緊急のタスクを解決しますが、強制と制御が必要です。
3. 資格も動機もありません。 専門的な教育を受けたステレオタイプの学生で、職業の入り口で高い給料を望んでいますが、そのために働くのに年に2か月しかありません。
4. 資格はありませんが、圧倒的なモチベーション。 人間はめちゃくちゃ元気で、新しいことを学び、学びます。 しかし、あなたの費用で。 あらゆる種類の間違いを犯します。その中にはすぐに現れるものもあれば、後で撮影するものもあります。 経験豊富な同僚（もしあれば）の時間を、彼らの間違いの質問、管理、修正によって食い尽くします。

これらのパラメーターは両方とも時間的に一定ではありません。



資格（何らかのトリッキーな数でそれを測定する場合）は通常、時折、けいれん的に成長します-貴重な経験を積む期間、新しいアプローチと技術​​の開発。 しかし、それは時々落ちると言うことができます。 たとえば、開発者にまだ知られていない新しいテクノロジーに切り替えると、チームの彼の資格はわずかに低下します。 そして、その逆も同様です。



動機は狂ったように上下にジャンプします。 膨大な数の要因に影響されます。 製品に対する信念、ユーザーと管理者からのフィードバック、面白くて日常的なタスクの割合、問題がリリースされるまでの数日間の緊張、同じポジションの新しい同僚が1.5倍以上受けるというニュース、同僚からの賞賛-これらすべてがやる気になります非常に広い範囲で変動します。 実際には、数日以上生産性のピークにとどまることや、数か月以上にわたって非常に高い平均的な動機を維持することは非常に困難です。 しかし、モチベーションのピーク時に、クールな開発者は、将来の製品の基礎を築く作業を行ったり、製品の新しい機会を開くような深い処理を実行したりできます。



簡単に言えば、私たちは個々の従業員とチーム全体の仕事の結果を動機付けの資格の仕事と考えることができます。 いずれかのパラメーターのゼロに近い値は非常に平凡な結果をもたらし、大量の製品により画期的な製品を作成できます。

資格についてもう少し

資格はいくつかのコンポーネントに分解できます。

1. 技術的な資格とは、ツール（アルゴリズム、言語、プラットフォーム、開発環境、フレームワークとライブラリのヒープ、デザイナーやテスターの作業用アプリケーションなど）の知識、および効果的なアプリケーションのスキルです。
2. 経験とは、特定の状況で行動する方法に関する知識です。 間違い（たとえば、開発者自身が複数のマルチスレッドアプリケーションを作成し、すべてのメインレーキを踏んだとき）または他の問題（たとえば、負荷の高いソリューションのチームで作業し、他の人がこれらの間違いをどのように解決するかを確認する）で取得できます。 経験の価値は、目標に向かう過程で製品やビジネスにコストをかける可能性のあるミスを回避できる可能性にあります。
3. インタラクションスキルとは、同僚、ユーザー、顧客など、他者とのインタラクションを効果的に構築する能力です。 これには、考えを明確に表現する能力、チーム内の相互支援の雰囲気、仕事の質に対する責任、エンドユーザーのケア、および必要に応じて自分で主張する能力が含まれます。 この資格を取得するのはおそらく最も難しいでしょう。 おそらくそれが文化と呼ばれる理由です。

モチベーションについてもう少し

動機もそれほど単純ではありません。 ある基本的なレベルを持っていると言えます。それは、人が自分が取り組んでいる製品を信じるかどうか、自分自身の見通しを見るかどうか、全体としてはすべてが正常に進んでいると感じるかどうかによって決まります。



この基本レベルを中心に、毎日の動機は非常に広範囲に変化します。 しかし、基本レベルが低すぎる場合、画期的な製品を製造できる生産性のピークはありません。 そして、「ゼロへ」のfall落は、一日が自分自身との闘いの中で、そして活動を模倣して通過するとき、はるかにあります。



逆に、モチベーションの基本レベルが高い場合、従業員の全体的な効果（特に相互作用の面で）ははるかに高くなります。 それでも、（少なくとも疲労の蓄積のために）「ゼロ」になることを避けることはできませんが、これは日常的なことではありません。



そのため、長期的なパラメータによって決定される基本レベルの動機付けと、毎日監視する必要がある「現在」があります。

それでは、従業員とチームに何を求めますか？

すべてが非常に簡単です。 開発の問題が原因ではなく、後の段階でプロジェクトを失敗させたい場合（さらに、起動したい場合はそれ以上）、次のことを行う必要があります。

1. すべての役職について、十分なスキルを持つ人々のみを募集します。
2. 高い基本的なモチベーションを提供します。
3. 毎日、現在の動機を監視します。

パートIII。 人々の選択。 善悪

そして、資格のある人が必要です。 つまり、技術的に精通し、経験を積んだだけでなく、生産的に協力する準備ができている人もいます。 どこで入手できますか？

方法

適切な文化の経験と予防接種を受けた人々を募集します。 通常、これらは5年以上の経験を持つ人々であり、大企業および中規模企業でかなりの期間働いています。 私たちの場合の文化は、どんな状況でもたわごとをするのが慣習ではない場合（これは実際に私たちの分野で一般に受け入れられている言葉であるという事実に我慢します）、チーム内の協力の雰囲気が支配し、会社と従業員は効果的な仕事を組織するための現代的なアプローチなどに開かれています。 一般に、大規模および中規模のIT企業の名誉ある役割は、従業員を訓練することです。 そして、彼らは十分に大きく、プロ、キャリア、または給与の伸びにとらわれている優秀な開発者なので、彼らは確かにそこにいるでしょう。 ここでも必要です。



正しい選択をしたことに対する報酬は、それが何をしているかを知り、プロセスに関与し、ビジネスに対して透過的であり、それを使って良いことをするチームです。

なんて間違ってる

経験のない人（昨日の学生、今日のインターン）、社内開発の人、カスタム開発に携わっている中小企業を雇います（もちろん、上記の経験がない場合）。



適切な意思決定を行うための経験と視野（たとえば、データ量、ワークロードの予測、モジュール性の編成、懸念の分離など）、または効果的なチームで働く文化（責任、計画スキル、アジャイル、設計、コード）がありませんレビュー、テスト、テストの作成など）。



そして、経験の浅い開発者はあなたの費用で学び、ほとんど利益をもたらさないでしょうが、同時に、すでにあなたのビジネスを動かすことができる人の代わりになります。 経験豊富な開発者（問題を説明するHabréの優れた記事）の時間を食い尽くします。開発者は質問に答え、初心者のコードを慎重にチェックし、彼の後にやり直す必要があります。 そして、リメイクしないと、悪い決定がはるかに後に発生し、最大数時間かかるリワークが数日、さらには数週間かかることもあります。



もちろん、幸せな例外はそれほど珍しいことではありません。 しかし、目標が時間と予算内で製品を入手することである場合は、まず、記事の最初の部分で詳細に検討したリスクに注意する必要があり、運に頼る必要はありません。

間違った選択で何が起こるか

適切な技術的資格のない人を選ぶと、昨日、学生が古き良きSQLの代わりに最初からエキゾチックなDBMSを選択し、JSONでのシリアル化のコストが非常に大きくなり、アプリケーションが完全にタイトになる状況に陥ることがあります。 そして、3週間にわたり、チームはキャッシュ内の情報の陳腐化の問題に取り組んでいます。これは、ストレージを変更するよりも速いためです。 そして、問題の雪だるま式は下り坂を一掃し続けています。



そして、適切な文化のない人を選ぶと、ある日、開発者は自分で書いたコードをチェックせず、すぐにテストに渡して、そこから3回返されることがわかります。 また、各リリースの期間は1週間シフトされます。 そして、リリース日がどこかに戻っており、ビジネスがすでに危険にさらされていることをもう一度理解すると、突然、全員が完了を待っているタスクがあることがわかります。 しかし、誰もそれをしません。 そして誰もが仕事は彼のものではないと言う。 このような背景に対して、3回目に更新した後、3回目に既に修正されたバグがポップアップする少数のクライアントがポップアップする状況は、ささいなことのように思えます。

特別なケース-開発アウトソーシング

スタートアップが失敗した場合、アウトソーシング開発は素晴らしいソリューションです。



あなたは人を探して雇う必要はありません、すべての能力はすでに選択されており、請負業者はテストされています。 しかし、彼の関心はお金を稼ぐことであり、可能な限り効率的に高品質の製品を作ることではなく、将来の変更につながるすべての間違いは請負業者にとって問題ではなく、追加のお金です（主なものは現在の段階を閉じることですからね？ ） しかし、とにかく製品が運命づけられていれば、それは怖くありません。 しかし、製品が突然利益を上げるようになった場合、請負業者は疑問を抱くかもしれません。彼のサービスは安すぎるのか、実際、その製品は本当に誰なのか。



請負業者のチームのパフォーマンスに影響を与えることができず、何か問題が発生した場合にチームを変更することはできないという事実について、私たちはそれについて話すことさえしません。

パートIV チームの動機。 善悪

そのため、有資格者のチームが募集されます。 ここで、問題の2番目の部分を解決する必要があります。これらすべての人々がうまく機能することを保証するためです。 ですから、モチベーションを維持することについて話します。



簡単に言うと、開発者（テスター、デザイナー、インターフェイステクノロジスト、レイアウトデザイナー、チームリーダー）は、「自己実現」、「給料のために働く」、「解雇されるのを待つ」という3つのモードのいずれかで作業します。 そして、絶対にすべての人々は、生活の異なる時期にこれらの基本的な動機のモードを切り替えます。



自己実現のモードでは、人は自分のプロジェクトとしてあなたのプロジェクトに取り組みます。 彼はプロジェクトのファンであり、彼の足元だけでなく、先を見据えて仲間を助けています。 まあ、そして何を隠すのが罪なのか、彼は新しい技術を引き込み、新しいアプローチを試し、すべてをゼロから作り直したいと考えています。 しかし、一般的に、この状態では、チームのメンバーは他の2人よりも生産性が高くなります（ここでは、読者がフレデリックブルックスの「神話のマン月」に精通していない場合、読者にそれを知ってもらいます）。 また、チーム全体としても、一種のターボモードで作業できます。 この場合、チームは「ドロップアウト」参加者を一般レベルにまで引き上げます。 もちろん、一定の制限内です。



「給料のための仕事」モードでは、責任感があれば、本当に悪いことも何もありません。 人は燃えませんが、生産性は安定しています。 彼は「from and to」のみを行いますが、「from and to」はうまく行います。 そして明確な良心をもって、彼は6時に家に帰ります。 このモードでは、人は良い仕事をすることができますが、将来を見つめ、特定の解決策がもたらす潜在的な問題を考え、そして最も重要なこと-真剣に正しい決定を下すために戦うための動機がありません、製品の品質は高いです、そして、開発のペースはビジネスのニーズを満たしました。



そして最後に、最後のモード。 通常、人は「私が最終的に解雇されるのを待って」ピットに落ちます。彼がエネルギーを使い果たし、すべてがより良くなるという希望を失います。 おそらく、すべての読者はこの状態にあり、そのような従業員の生産性のレベルを記述する必要はありません。



チームが最大限の生産性の状態で可能な限り多くの時間を費やし、決してマイナスにならないようにすることが重要です。問題の価格は、競争力のある製品でビジネスチャンスの窓を得るチャンスです。



これを達成する方法を理解しましょう。

方法

私たちの目標は、大規模および中規模のIT企業の経験豊富な開発者（テスター、デザイナー、レイアウトデザイナー、アナリスト）を、経験と高いレベルの「生産文化」で結び付けることです。そして、最大の効果的な動作モードを維持します。



原則として、適切な人があなたのオフィスに行って「話し」ます。なぜなら、あなたの現在の仕事では、あなたは職業上のキャリア上のデッドロックに陥っているからです。つまり、彼らは製品への信仰、興味深い仕事、より大きな権限と賃金の伸びを欠いています。そして、誰もが感謝され、尊敬され、投げられないことを望んでいます。



これらの人々が必要な場合は、不足しているものを提供してください。



もちろん、それぞれにわずかに特別な要求があります。そして、それは雇用の瞬間だけでなく、このプロジェクトの仕事の翌日にも関係しています。したがって、最初の人があなたのことをよりよく知るようになるよりもずっと前に、チームの条件を熟考することをお勧めします。そして、考え直すだけでなく、予算と事業計画に課すことも。



将来のチームに何を提供できますか：

製品の関与

製品の観点から始めます。私たちは、あなたがすでによく考え抜かれたアイデア、ビジョンなどを持っていることを前提としています。チームを「自己実現」モードで動作させたい場合は、製品を販売してください。誰もが熱心に有名なUGを作ったことはありません。



しかし、一度製品を販売するだけでは十分ではありません。製品の価値、重要性、成功、展望、その成功と失敗が見えなければなりません。チームが進行状況、成功、失敗を確認できない場合、チームはこの製品に関連付けられず、「自己実現」モードを忘れることができます。誰もが次の緊急事態で自分のお尻をさらさないためだけに忙しいでしょう。

お金

製品が将来のチームメンバーに販売された後、良好な金銭的および社会的および労働条件を提供します。



あなたは経験豊富な専門家を自分自身に連れて行くので、給与（ボーナスを含む）は市場よりも高くなければなりません。



まず、平均を上回っており、平均的な従業員に給与を支払いたくない、または支払うことができない企業の人を採用します。



次に、従業員に次のように伝えます。「従業員の価値を理解し、あなたは私たちの重要な資産であり、私たちは従業員に市場を超えて支払う必要があります（これは「自己実現体制」を維持するために重要です）と同時に、それに応じて働くことを期待します方法。私たちは、劣悪な仕事をしている従業員への支払いを減らす準備ができていません。そして、そのような費用はビジネスを飛び立たせないので、私たちはそれ以上支払うことができません。」

, : -- , , , ( ) . , , , , .



, . , . , – . – . : . , , : . .

第三に、十分に高い給与は、上記のように、従業員にある程度の効率性を合理的に要求することを可能にします。これは、現在の労働条件を変更し、ビジネスプロセスを変更することが必要な場合（そして、この瞬間が確実に、そして複数回）必要になるときに重要になります。変更の影響を受けるすべての人にとって、これは快適な領域から抜け出す方法になるので、リーダーやチームの外部からの圧力がなければ、ビジネスはしません。変更が利益をもたらした場合、賢い人々は最終的にそれらに同意しますが、中間の衝突なしに行う方法はありません。この場合、適切な金銭的動機は、貴重な従業員の損失に対する重要な保険です。

責任

責任の問題は、チームとビジネスの両方のソフトウェア開発における重要な問題です。客観的なタスクに1週間の作業時間が必要であり、マネージャーが2日間でそれを解決することを要求し、議論を聞かない場合、99％のケースで結果が不十分に満たされ、カーペットの下で問題の山が気づきます。開発者はたわごとをすることを余儀なくされ（たわごとを物理的に不快な人を特別に募集したことを覚えています）、カーペットの下で気づいた問題は将来数時間または数週間の遅延がかかります。動機が落ち、問題が現れました。そのため、労働力の評価はチームメンバーから行うことが重要です。交渉し、タスクをより詳細に策定し、要件（アジャイル）を調整できますが、最終評価はそれを実行する人が行う必要があります。タスクの評価は、この問題を解決する時間と質に責任を負う行為だからです。正しい評価には経験が必要であり、責任を取るには文化が必要です。これらは、記事の第2部で作成したチームメンバーの要件です。

期待と現実

欲求不満は、期待と現実のギャップです。常に専門家の期待に遅れずについていき、物事がどのように現実になっているかを確認してください。



たとえば、1日だけ警告なしで給与が遅れると、「動機付け」のカルマが差し引かれます。正当な理由がないために、反復の途中で要件が突然変更されましたか？カルマに少ない。 同僚はあなたと同じくらい多くのことを受け取りますが、中途半端に働いており、誰も今まで2ヶ月間何もしていませんか？ カルマに少ない。同じレベルの新しい従業員を同じ職位に連れて行き、給与を1.5倍増やしますか？それでも同じように、カルマではマイナスになります。その日の期限の期限を常に許していましたが、今回は厳密に契約に従って、保険料を減らしましたか？しかし、まだカルマにマイナス。彼らは明確な条件で賞を約束し、そして「客観的に、そんなに支払うお金がない」と？あなたは忘れられないでしょう。



カルマの短所は避けられません。それらのいくつかは意図的であり、絶対に必要です。しかし、ある時点で、フラストレーションがたまると、チームメンバーの生産性が急激に低下します。そして、ある重要な時点で、チーム自体のモチベーションが低下し、チームは「失われた」メンバーのモチベーションを引き上げるのではなく引き下げます。したがって、期待と現実のギャップの大きさを監視することは非常に重要です。

なんて間違ってる

開発チームを最も貴重な資産の1つとして扱わないでください。

そして、元のアイデアと最初の製品とその顧客がお金を持ってこられないように、物事は常に判明する可能性があり、急いで靴を急いで交換する必要があります。この時点で、すべての資産のうち、お金、創業者と開発チームの意志のみがあります。

チームに「報告」しないでください。結局のところ、考えてみると、どのような開発者が売上の推移を気にしているのでしょうか？クライアントと話し合った新機能をチームから最後まで秘密にしてください。同時に、顧客と合意した機能をチームが表示する時間を常に2倍にします。



タイムラインの推定に関しては、「死ぬが、やる」というイデオロギーを受け入れます。チームリーダーのモチベーションを監視および維持するという問題を解決します。これが彼の仕事です。約束を守らず、給料の遅れを謝罪したり、「腐った」従業員を解雇したりしないでください。そしてもちろん、従業員が関心を持っているのは当然だと思います-より多くの（ところであなたの）お金を稼ぎ、仕事を減らすことです。



もちろん、開発はこれらすべてで機能し、製品は徐々に登場します。ただし、同時に機能が大幅に低下し、ユーザーエクスペリエンスが非常に悪くなることがあります。また、製品が予期せず離陸した瞬間に、チームが適切なペースで実行できないことが判明しました。レーキコード。

1つの段落で最も重要なこと

バーを高く設定します。チームで働くことができる経験豊富な専門家を募集します。経済的および時間的な機会を正確に把握してください。製品をチームに販売します。良好な状態を提供します。人々にあなたの製品を検討する機会を与えてください。責任は証明書ではなく、配布されるものではなく、自分の手で取られることを忘れないでください。期待と現実を追跡します。意欲的なチームを使用して、競争力のある製品を入手してください。そして今、あなたは顧客の信頼と投資家の関心と同じくらい重要であり、脆弱ではない非常に価値のある資産を持っていることを忘れないでください。

次の部分で

次の記事では、チームの組織を検討します-リスクを最小限に抑えるという立場から。 切り替えないでください。