突然、上司は私を困惑させました。「しかし、関連プロジェクトには新しいアナリストが必要です。候補者にインタビューしましょうか？」
もちろん、私は同意しました。
そして、私は、アナリストにインタビューする方法、そして最も重要なことには、アナリストが良いかどうかを理解する方法がわからないことを考え、実現しました。 しかし、撤退するには遅すぎました！
すぐに私に送られた履歴書は、不適切な履歴書に加えて、ほぼ同じでした。 同じ品質、同じスキル、同じテクノロジー。 インターネットでの検索は励みにならず、トピックに関する発見された記事は同じコピーライターによって書かれたようで、あまり助けにはなりませんでした。
重要と思われるパラメーターの大群が形成されましたが、それはしばしば互いに矛盾していました。
少し頭を使い賢い人と相談した後、私はインタビューの計画を始めました。
インタビューで確認すべきアナリストの抽象的な「黄金の」資質とスキルを検索する代わりに、役に立たないものをカットし始めました。
その結果、テクノロジーとアプリケーションに関連するすべてが役に立たないことが判明しました。 私が人を探していたプロジェクトは、クライアントのビジネスアプリケーションに関するものでした。そのため、SQLやJSONなどの知識を確認する理由はなく、1週間でSparxで絵を描くようにサルに教えることができます。 あらゆる種類のUMLとBPMNの知識は、「円と矢の描き方」ではなく、作業プロセスを理解するという文脈でのみ必要でした。
それでは、どうすればいいのでしょうか？ しかし、最終的には、17人の応募者が合格した素晴らしい計画が形成されました。
計画は3つの部分で構成されていました。
- 一般的な質問。
どのような要件があり、どのプロパティに適切な要件がありますか。
彼らは理解する必要がありますが、アナリストは私の前にいますか？
その過程で判明したように、テスターや開発者、さらにはITに関係のない人々でさえ、美しい履歴書の後ろに隠れていました。
さらに、これらの単純な質問は、別の予期せぬ効果をもたらしました。 一部の求職者は、そのようなシックな履歴書の所有者である彼らがそのような簡単な質問をされたとき、おかしくなり始めました。 まあ、このような会話では、短くて気難しいアナリストには場所がありません。 - 開発プロセスとチームにおけるアナリストの役割に関する質問。
アナリストがすべきこととすべきでないこと。 開発者およびQAとの関係、彼が参加した開発方法論の理解方法など。 実践により、誰もがアプリケーション開発サイクル全体、チームにおける彼らの役割、およびビジネスが一般に開発者にソフトウェアを注文する理由を想像しているわけではないことが示されています。 - 状況の問題。
ここでは、アナリストの仕事における実際の状況と、申請者の思考の経過をたどるために私が発明した状況の両方をシミュレートしました。 アナリストの通常の問題が考慮されました：複数の顧客間の優先順位または要件の競合、チーム内の競合、あいまいな提出、顧客インタビュー、ビジネス利益の競合など。
最も有用なブロック、なぜなら 私は注意力と迅速な機知だけでなく、未知のデータを明確にする能力もチェックしました。 いくつかの状況では、私は入門者のいくつかについて故意に沈黙を守っていましたが、17人の候補者のうち3人だけが少なくとも私と一緒に何かを明らかにしました。 私の意見では、これは悲しいことです。
技術的なスキルから完全に抽象化されたため、応募者のための優れたフィルターを取得しました。合格したすべての候補者はリーダーシップによって承認され、その後のラウンドで肯定的な評価を呼び起こしました。
ですから、その側からアナリストを雇うことを見ていなかったら、見てください！
UPD：質問と予想される回答の例を示します。
入門的な質問から：
- 主な分析ツールは何ですか？
最初の質問。 これが頭だと確信しています。 しかし、判明したように、一部の申請者は、「ツール」、「スキル」、「能力」の概念を混同しています
- 要件は何ですか？
機能的および非機能的である十分な答えがあります。 機能しないものは、ビジネスルール、制限、および品質属性に分類できます。 そのフォールトトレランス要件は品質の属性であり、統合要件は制限事項です。
- 優れた要件にはどのような特性がありますか？
ここで、私はこのリストから何かを聞くことを期待していました。完全で、明確で、一貫性があり、検証可能で、理解できるものです。 もちろん、電話することもできますが、そのように私に合っています。
チームにおけるアナリストの役割に関する質問から：
- 誰がタスクの複雑さを推定しますか？
開発チーム
- 誰がテスト計画とテストケースを作成しますか？
QA。 答えは簡単でしたが、一部の応募者は、アナリストがこれをすべて行っていると言って私を驚かせました。 そのような人々のために、「QAによれば、既成のスクリプトに従ってボタンを押すことしかできないような軽率な猿ですか？」と質問がありました。しかし、プロンプトにもかかわらず、数人の人々はまだ「はい」と答えました。主な質問。
- 誰がクライアントにデモを見せますか（スクラムチームの場合）？
開発チームの誰でも、アナリストではない。
プレイした状況。
- 開発者とQAの競合
入門：開発者とQAがアナリストに来て、お互いに文句を言います。 QAは開発者が間違ったことをしたと言い、開発者はこのQAは何も理解していないと言います。
期待されるアクション ：問題が何であるかを誰が理解したかを知る必要があり、妨害の場合、曖昧に解釈される場合、分析者は要件を明確にする必要があります。
- 優先順位の競合
はじめに ：リリースは厳密に日付で計画されており、開発は1か月先にあり、すべてが順調に思えますが、ここで顧客は新しい要件のバンドルを実行し、緊急にリリースに追加するように言います。 同時に、その月の新旧の要件を満たせないことは明らかです。
期待されるアクション：新しい要件の出現の原因を調べ 、クライアントのニーズを説明します。突然古い要件は関係がなくなったので、捨てられます。 すべてが必要な場合は、クライアントに新しいものと古いものの両方、および次のリリースへの延期に適さない優先順位を再度設定させます。
- 屠殺要件
導入 ：コスト見積もりの段階で、開発者は、この要件がシステムを破壊し、それを実装するには、アーキテクチャを変更するために数ヶ月を殺す必要があると言います。 そして、顧客は言う：「もちろん、私はすべてを理解していますが、私はそれを必要とするので、あなたは開発者です！」
期待されるアクション ：多くの場合、顧客が望んでいるのは、状況と決定に関する個人的なビジョンだけです。 要件の背後には、特定のビジネスニーズ、それを特定し、開発の観点からより安価な、より最適なソリューションを提供するというタスクがあります。
- ブラインドインタビュー
はじめに ：アナリストは新しい顧客にインタビューするために送られますが、彼については何も知られていないため、彼がどのようなアプリケーションを必要としているかさえ明確ではありません。
アナリストが顧客に尋ねる主な質問は何ですか。
このような状況では、次の質問とそのバリエーションが正しいと考えます。
顧客と彼の従業員は何をしますか？
なぜソフトウェアが必要なのですか？ 問題は何ですか？
彼はこのソフトウェアに何を期待していますか？ 結果は何ですか？
顧客は結果が達成されたことをどのように理解しますか？
お客様にはどのような制限がありますか？
- 二人の監督
導入 ：アナリストチームは、ロンドンとニューヨークにオフィスを持つ国際企業向けのソフトウェアを作成します。 このソフトウェアは、この企業の顧客が使用します。 これらのオフィスのディレクターは最終顧客であり、両方ともリリースを成功させるためにサブスクライブする必要があります。 ただし、画面フォームの1つでは、1人の監督が1つのことを青のボタンで行い、もう1人が緑のボタンで別のことを行うことを望んでいます。 両方の取締役が単一の決定に同意するように、議論を見つけなければなりません。
期待されるアクション ：推論のチェーンを通じて、取締役がビジネスを管理したら、「2つの異なるページを作成しよう」または「地理的な場所によってクライアントを決定する」のではなく、議論は企業のビジネスに関連する必要があるという結論に達します。 理想的なオプションは、企業がさまざまな機能から受ける利益と、これらの機能を開発および維持するコストの比率です。