通常、回答を試みた後、変更されていないコメントが続きます。「ああ、プログラマー、冷蔵庫さえ修理することはできません。」 同僚に自分が何をしているかを本当に説明できないビジネスアナリストについて、私たちは何を言うことができますか。
私自身、父からこの質問をよく聞きますが、まだ正しい答えが見つかりません。 そして真実は私たちが仕事で行うことです-私たちは分析します！
ITアナリストは何に時間を費やしていますか？
特にこの記事では、最後の3つの作業場所からJIRAアーカイブを徹底的に掘り下げる必要がありました。 私は絶対的な正確さを保証することはできません（はい、また、最後の最後まですべてのクラスをペイントするのは好きではありません）が、全体像は実行された職務からの私自身の気持ちと本当に一致します。
仕事のおおよその分布は次のように説明できます。
- ミーティング-20％
- ドキュメント-30％
- チームワーク-25％
- テスト-5％
- 出張-5％
- 自己啓発-15％
過去3か月の正確な時間数は次のとおりです。
ご覧のとおり、写真は本当に似ています。 職場の最近の変更とそれに応じた新しい環境への統合プロセスにより、出張の不在とチームでの長時間労働の小さな違いが生じます。
それでは、各項目をさらに詳しく見ていきましょう。
ミーティング
最も重要なことから始めましょう。実際、ビジネス分析はビジネス会議から始まります。ビジネス会議には、クライアントとの会議やチームとの内部会議が含まれます。
まず第一に、これはサブジェクト領域と要件のコレクションの分析です。 クライアントが私たちに何を望んでいるか、どのような問題を抱えているかを見つけ、実装のための最初のアイデアを提供し、一緒に予備的なプロジェクト計画を作成します。
クライアントとの会議の他の重要な要素は、提案された製品の使用方法を説明する作業の実施、変更計画、プレゼンテーション、およびトレーニングです。
おそらくそれが私たちの仕事の基礎となる会議であり、アナリストとチームにさらなるタスクを提供するので、最も慎重に準備する価値があります。
ドキュメントを操作する
アナリストが会議に出席していない場合、彼は座ってドキュメントを操作しています。 誤解しないでください、これはあなたが愚かにキーボードをたたくだけでいいということを意味するものではありません-それはあなたが私たちの知性のすべての機能を使用しなければならないことです、この部分は最も時間がかかります。
定期的に対処する必要があるもののほんの一部の例を次に示します。
- 要件仕様は、クライアントの思考の自由飛行を、チームが何をする必要があるかを明確に説明する構造化文書に変換することです。 後で、この特定のドキュメントはクライアントで承認され、進行中のプロジェクトの基礎を形成します。
- 変更要求（変更要求）-開発の開始後または完了後でも製品に変更が必要な場合にクライアントが開始するプロセス。 このドキュメントには、システムのどの部分とどのように変更する必要があるかが記述されており、作業の実行の評価が時間とコストで含まれています。
- ユーザーの指示およびその他のトレーニング資料-プロジェクトの終了後、クライアントのドキュメントを作成する必要があることは明らかです。ドキュメントには、システムの使用方法、一般的な質問へのヒントと回答が記載されています。
各アナリストは、ドキュメントを操作するためのお気に入りのツールキットを持っています。誰かが図を描くのが好きで、誰かがWordでテキストのキャンバスを書きます。 いずれにせよ、UML、BPMN、ユーザーストーリーの概念、および受入基準の基本に精通することをお勧めします。 彼らはすべての雇用者で見つかる可能性があります。
チームワーク
大部分は、チームにとってアナリスト、つまりクライアントの声です。 理解できない状況では、彼らは「ここでどういう意味ですか？」という質問で彼に来ます。そして、顧客がそれを望んでいるかどうかを確認するのは彼と一緒になります。
ITのビジネスアナリストは、開発者とビジネスをつなぐ役割を果たし、クライアントとプログラマーの言語を同時に話すことができるといつも言っています。 日常業務では、要件を一緒に議論し、タスクを計画および配布し、プログラマーの現在の質問に答えなければなりません。
多くの場合、ビジネスアナリストはチームの各メンバーと多くの時間を過ごし、副マネージャーとして独特の役割を果たします。 私の練習では、リーダーが私に来て、彼の同僚の誰が賞を与えるべきか、誰が賞を与えるべきではないかを議論するケースさえありました。
テスト中
何よりも、クライアントの要件を理解して、プログラマーの仕事の結果を確認する必要があることは明らかです。
ビジネスアナリストは、いわゆるユーザー受け入れテスト-ユーザー受け入れテストを実行することが期待されています。 自動化されたスクリプトを記述したり、サイト上のボタンのサイズと色を確認したりする必要はありません。 必要なのは、ユーザーとして自分自身を紹介し、完成品を活用することだけです。 システムを使用する際に不便がないか、システムがユーザーの希望どおりに機能するか、明らかなエラーや要件との矛盾がないかを確認してください。
重要なポイント！ アナリストは常にチームと時間を費やし、議論に参加し、プログラムのさまざまな「ハッキング」やボトルネックを認識していることを覚えておく必要があります。 同時に、テストを実行するとき、クライアントはこの知識を持たず、クリックする場所とクリックしない場所を知らないことを理解する必要があります。 心を開いてシステムを評価し、開発者にすべてのエラーを指摘することは絶対に必要です。エラーを特定できるほど、修正が容易になります。
自己啓発
彼らは、プログラミングのすべての新技術に遅れずについていくために、ほぼ毎日新しいフレームワークを学び、お気に入りの言語の新しいバージョンを試し、世界中のベストプラクティスに従う必要があると言います。
幸いなことに、ビジネス分析の基本はそれほど頻繁に変わりません。 ただし、前回の記事で述べたように、多くのビジネスアナリストから目立つためには、最も包括的に開発されたスペシャリストである必要があります。
また、ITの変化を監視し、ソフトスキルを開発し、ビジネス管理、財務の基礎を学び、顧客の主題分野を理解する必要があります。 一般的に、他のプログラマーよりもトレーニングにさらに多くの時間が必要になることがよくあります。
結論として、私は自己啓発について助言します-その必要性を受け入れ、あなたのリーダーと話し合います。 明日、完全に異なる分野からの新しいクライアントと新しいプロジェクトが出現するため、ビジネス開発では、確立されたプロセスのフレームワークに身を押し込まないことが非常に重要です。 ビジネスアナリストは、変化する環境に素早く慣れ、新しいサブジェクトエリアで作業する準備ができている必要があります。 あなたが視野を広げるために費やしたすべての時間があなたの助けに来るのはここです。