この記事では、初心者やキャリアを始めたい人のためのビジネスアナリストの職業についてお話しします。
この分野での経験がなければ、「ビジネスアナリストとシステムアナリストの違いは何ですか？」彼らはハブレで何度もこの質問への答えを見つけようとしました、誰も明確な答えはありませんが、多くの良い記事があります。
それらの1つ：ITのビジネスアナリストとシステムアナリスト。私たちは品種を理解しています
前書き
私は3年以上Oracle Siebel CRMアナリストとして働いており、1年以上の間、厳しい労働日の現実に対応するためにインターンを準備しています。原則として、私の学習スタイルは、小規模な入門講義と、品質管理を伴う実際のタスクへの研修生の即時の活用で構成されています。
自己分離の状況で、私は興味深い事例に直面しました。厳しいセキュリティ要件を持つ会社のコンサルタントとして働いている間、私は転送された理論的知識を実用的なアプリケーションに統合する機会がありませんでした。これは私をメンターにとって非常に興味深い課題に導きました：訓練生の抽象的な概念を最小限に抑え、実際の経験のない実際の問題に備えるように理論を提示する必要性。この記事で得た経験をキャプチャしようと思います。
アナリストは何をしますか？
通常、私の職業についての質問に答えるとき、アナリストは人文科学の言語から技術者の言語への翻訳者であると言います。しかし、世界のすべてがそれほど単純なのでしょうか？
実際、分析は次のステップで構成されています。
- システム改定の依頼を受ける
- プロセスの最後にユーザーが得る望ましい結果を洗練する
- 現在の作業プロセスの明確化
- ソリューションの予備設計
- 結果を達成するために必要な場合は、プロセスの追加ステップの顧客との調整、
- ソリューションの修正
- 顧客とのプロセスの調整
- 開発者向け技術仕様の登録
- 機能の主なシナリオのテスト
- 文書の準備、ユーザーへの指示の作成
- 顧客への機能の移転
各ステップの詳細
修正依頼を受ける
原則として、モディフィケーションのお客様は、ITの領域から離れた人々です。要件が体系化されていることはほとんどなく、明確かつ論理的に記述されています。これは、タスクを開発者に引き渡す前に修正する必要があるものです。
望ましい結果の明確化
ここでは、お客様が具体的に何を望んでいるかを明確にする必要があります。アプリケーションのステータスの変更、ドキュメントの生成、SMSまたはEメールの送信など、ITシステムが実行できるすべてのことを行うことができます。
この段階では、常に次のガイドラインを使用してください。
- あなたのために、顧客からの問題ステートメントに単一の抽象的な概念があるべきではありません。あなたと顧客がいくつかの単語を同じように理解しているかどうかわからない場合は、必ず理解するようにしてください。
- 馬鹿げた質問はありません。誤って定式化され、正しく対処されていない質問があります。アナリストは、ビジネスのすべての領域の専門家ではありませんが、新しい領域をすばやく把握できなければなりません。恐れずに質問してください。
現在のプロセスの明確化
ほとんどの場合、現在の作業プロセスは「AS-ISプロセス」と呼ばれます。
この段階を完了すると、プロセスをブラックボックスとして想像する必要があります。
ソリューションの予備設計
この段階は、将来のプロセス、または彼らが言うように「TO-BEプロセス」の定義を意味します。
この段階を完了すると、ブラックボックスが白に変わります。つまり、プロセス内で何が起こっているかを正確に把握する必要があります。これは次のように
なります。次の原則に従ってください。
白いボックスに「入力3」が表示されていることに気づいたかもしれません。場合によっては、システムに結果を達成するのに十分なデータがないことがわかります。例として、顧客の会社とクライアントの間の契約の締結に関するある種の証明書を考えてみましょう。これは、システムに保存されていないクライアントのパトロニクスを反映しているはずです。この場合、これをお客様に通知し、問題の解決策を提供する必要があります。たとえば、「Patronymic」フィールドをシステムに追加して、それが入力されていることを確認します。ユーザーにとって、これはシステムを使用するときに追加フィールドに入力することを意味します。これは顧客と合意する必要があります。
ソリューションの修正
プロセスの新しいステップの調整は、顧客からの決定に関するコメントで行われる場合があります。この場合、提案されたソリューションを修正する必要があります。しかし、これは常に発生するわけではありません。つまり、あなたは立派な仲間であり、「ソリューションの予備設計」のステップで設計を終えているということです。
プロセス調整
設計が完了したら、プロセスをお客様と合意する必要があります。ほとんどの場合、契約の形式は、特定の会社や特定の顧客の現実に依存します。これらは、プロセスのテキストによる説明、ビジネスプロセスを説明するための表記法での説明、または口頭による合意です。
技術仕様の登録
技術的な割り当ての形式は、顧客とエグゼキュータの企業で採用されている規範、および多くの場合、開発者の能力にも依存します。経験の浅い開発者は、プロセスのより詳細な説明が必要です。私のキャリアの中で、技術仕様がまったくなく、すべてが自由な形式で議論された会社に出会いましたが、すべてのステートメントに共通の特徴があります：設計ステップで定義された算術および論理関数を、テキストまたは視覚的に、ブロックの形で記述する必要がありますスキーム。
機能テスト
質問を見越して、はい、アナリストはしばしばテストを行います。ただし、原則として、このテストは表面的なものであり、開発者があなたを正しく理解していることを確認します。通常、重大な欠陥、つまり、どのような方法でも望ましい結果を達成できないバグの存在を特定するために、作業の主なシナリオを通過することに限定されます。QAスペシャリストは、さまざまな条件での軽微な欠陥の検索と機能のテストに従事しています。
ドキュメンテーション
これはおそらく、ほとんどのアナリストにとって最も嫌いな段階ですが、機能に関する専門知識は書面で記録する必要があります。ドキュメントをよく書く：啓蒙されていない人が白い箱の中で何が起こっているのかを理解できるようにプロセスを十分に詳しく説明し、それを読んで目を覚ますことができるように十分に短くする必要があります。
ユーザーの指示は、機能のエンドユーザー向けの短いメモであり、ユーザーのアクションがステップごとに説明されています。このタイプのドキュメントは、アクションのリストで構成されている必要があります。技術用語は含まれていません。
これらのドキュメントの形式は、特定の顧客企業で採用されている基準にも依存します。
顧客への機能の移転
仕事の最も楽しい部分。ここでは、お客様に行われた作業を紹介し、栄誉を集め、行われた作業に誇りを持ち、次のタスクのために前向きな感情で自分を充電します。
出力
アナリストの仕事には、多くのコミュニケーション、ブレーンストーミング、そして自然がもたらしたロジックのすべての可能性を使用することが含まれます。
整理と最適化を楽しむ場合、人生のすべてを明確かつ論理的にしたい場合は、アナリストとして働くことで多くの喜びが得られ、確実にキャリアのトップに到達します。
私の記事が分析についての印象を形成し、人生におけるあなたの道の認識につながったことを願っています 幸運を！