スタイリッシュなチームを結成

あなたのチームが他のチームよりも優れていると言うなら、その理由は何ですか?みんなが優れた専門能力を持っているからでしょうか?皆さんは素晴らしいプロセスを知っているからですか?それとも別の理由があるのでしょうか?

次のような問題に遭遇したことはありませんか?

1. 開発者が機能を完成させ、メインフローのみをテストしたところ、問題ありませんでした。その後、完了としてマークされ、テストのために QA に送信されます。 QA は重大なバグを発見しましたが、通常のプロセスの途中でキャンセル ボタンをクリックするだけで済みました。

2. 開発者に API を開発するためのサブタスクが割り当てられ、API 要件が詳細に記述されます。彼はすぐに作業を終え、発信者との統合テストを開始しました。この時点で、彼は自分が行っていたことが、発信者が当初予想していたことと大きく異なっていることに気づきました。

3. 開発者は再びバグを修正する必要があります。既存のコードをチェックして、問題があることに気付きます。しかし、この問題を修正したいだけであれば、コードを 2 行変更するだけで簡単に修正できます。しかし、コードはまだ醜いため、リファクタリングしない限り、将来的に機能を変更するのは複雑になります。彼は誰とも相談せずに黙って単純な修正を選択した。

4. QA スタッフが新しい機能をテストしています。機能は要件の説明と 100% 一致していますが、使用時に一部がスムーズに動作しないように感じています。彼は機能テストに合格した。

5. 開発者が開発環境全体を実行するたびに、4 つのコード ベースからコードを更新し、4 つのプロジェクトでビルドをクリックし、3 つのアプリケーション サーバーを起動してデータベースを起動する必要があります。彼らは次第にそのようなトラブルに慣れていった。

6. 上海に開発者がおり、アメリカ人の同僚は QA です。2 人の間にはほぼ半日の時差があります。上海の開発者はもうすぐ仕事が終わる予定で、テストのために米国の QA に渡す前に、作業中の機能の仕上げ作業が残っているだけです。おそらくあと30分ほどかかるでしょう。開発者は仕事を辞めて翌日も作業を続けることにしました。そこで、米国の品質保証部門はテストを実施する前にもう 1 日待つことにしました。しかし、この開発者以外は誰もこれを知りませんでした。

7. UI 開発者は、デザイナーが望む UI 効果を 100% 示す美しい HTML プロトタイプを作成しました。しかし、プロトタイプで使用されている UI ライブラリは、既存のアプリケーションで使用されているものと競合します。エンジニアが既存のコードのリファクタリングに多くの時間を費やすか、UI 開発者が別のライブラリを使用してプロトタイプをやり直す必要があります。

上記のすべての例で、プロセスに違反した人はいましたか?いいえ、上記のすべてをプロセスに書き込まない限りは、そうはなりません。時間があれば、プロセスでカバーされていない状況を何百も挙げることができます。したがって、すべての状況をカバーできるプロセスを用意することは不可能です。

しかし、彼らは別のやり方でそれをできたのでしょうか?

1 つ目は、問題を QA にテストのために送信する前に、簡単なスモーク テストを完了することを選択できます。または、QA がバグを見つけられないようにするために、まず QA ですべてのプロセスを可能な限り実行することを選択できます。

2. 製品マネージャーの説明をそのまま読むことも、開発前に発信者と話し合うこともできます。

#3、できるだけ早くバグを修正するか、コードの問題を取り上げ、リファクタリングが必要かどうかを確認するかを選択できます。

#4、プロダクトマネージャーの言うことだけを聞くことも、ユーザーの視点からフィードバックを与えることもできます。

#5、彼はこの退屈な手作業に耐えることを選択することも、それを自動的に完了するスクリプトを作成することを選択することもできます。

#6、彼は通常のペースで時間通りに仕事を終えることを選択することも、QA が早めにテストできるように 30 分長く残ることを選択することも選択できます。

#7、UI 効果をできるだけ早く実装するか、実装する前に開発者と話し合うかを選択できます。

彼らの考えを抽象化して要約すると、常に下流の担当者の作業を考慮する、ユーザーのように考える、改善できるものはすべて改善する、などとなります。これらのアイデアは専門的なスキルやプロセスではありませんが、チームの文化を構成し、チームを差別化するものです。新しいチームでは一般的に考え方が一貫しておらず、メンバー全員が独自の視点や立場を持っています。

十分に訓練され、経験豊富なチームは、さまざまなシナリオに遭遇し、さまざまな問題を一緒に解決し、最終的に暗黙の了解を確立しました。チームには暗黙の了解があるため、問題を明確に伝えるのに費やす時間が短縮され、行動計画についてより早く合意に達し、より速く対応でき、より少ない試行で答えを見つけることができます。このチームは強いスタイルを持ち、非常に効率的です!

文化を創るのは誰でしょうか?通常はチームのリーダーです。リーダーがプロジェクトのあらゆる詳細を把握し、あらゆる小さなことに気を配ることができれば。そうすれば、チームの各メンバーは、上司が細部まで注意を払っていることを知っているので、自然に細部まで注意を払うようになります。リーダーが各ステップを実行する際に次のステップをどうするかを考えれば、メンバーは自然と一歩先を考えるようになります。リーダーが効率性を改善し、手動プロセスを削減する方法について常に考えている場合、彼らは常にこの質問をしています。メンバーもこのような考えを持つでしょう。リーダーが常にユーザーの視点で問題を検討し、試みる場合、メンバーが問題を検討するときに、リーダーと同じ質問を自問することになります。「自分がユーザーだったらどうするだろうか？」

自分独自のスタイルでチームを作りたい場合はどうすればいいでしょうか?これを試してください:

1. これまで遭遇したすべてのシナリオを思い出し、それらのシナリオでチームメンバーがどのように考えるべきかのアイデアを抽出し、短い文章で要約します。

2. これらの文章は、チーム文化のキーワードです。

3. チームにこれらのキーワードを伝えます。

4. 今後はこれらのキーワードに関連するシーンに注目してください。

5. チームメンバーのアイデアがあなたが望む文化と一致している場合は、それを奨励します。

6. チームメンバーのアイデアが文化と一致していない場合は、それを指摘して自分の考えを伝え、メンバー自身でそれを実行する方法を見せてもらいます。

7. メンバーに、同じように新人を指導するよう依頼します。

8. これまで考慮されていなかったいくつかのシナリオに基づいてキーワードを改良し、改善します。

出典: 提出物、著者: 王衛傑。

元のタイトル: スタイリッシュにチームを構築する

キーワード: