エッセイのトピックは私の仕事に関連しているので、ビジネス分析のいくつかの側面を以下で説明します。 誰かが興味を持ってくれることを願っています。
私自身の経験から、プログラマーや他のソフトウェア開発者は、プロジェクトにアナリストが必要な理由を必ずしも理解していないと言えます。 よく知っているエンジニアの中には、自分ですべてを実行できるとよく言っており、プログラミングを本当に理解していない人に、何をどのように機能させるべきかを教えてくれる人は必要ありません。
この記事では、「正しいアナリスト」がすべきことをお伝えしたいと思います 。 私のように、ええ。
そもそも、 アナリストが必ずしも必要ではないことに同意するでしょう。 あなたが精通している地域で小さなプロジェクトをしている場合、または小さなチームと指先にある種の「専門家」がいる場合 、おそらく私たちの助けなしで行うことができます。
その他の場合-たとえば、特定の大規模システムを改造したり、専門家ではない分野で何か新しいものを構築したりする場合は、アナリストの助けが必要です。
また、アナリストは多くの場合、真実を馬鹿にしていると付け加えます。 アナリストが不必要なドキュメントの山を誰かに書いて、それに時間を費やし、有用な従業員がコードを書くのを邪魔するケースを見てきました。 または、要件の代わりにアナリストが_how_を説明する場合、それが機能するはずです。これは、原則として、非常によくある間違いであり、記事の別のトピックです。
数年前、アジャイルプロジェクトにおけるアナリストの役割について書きました 。 現在、私はわずかに少ないアジャイルですが、より多くの金融プロジェクトに取り組んでいます-石油とその派生物、および金属と他のツールを販売する最大の会社の1つです。
同社は20年以上にわたって市場に出ており、創業以来信じられないほど成長しています。 このような企業ではよくあることですが、ここでは、取引を記録するシステム、リスクのシステム、会計システム、報告システムなど、さまざまな機能のシステムが離婚しました。 同社には、各機能に少なくとも2つのシステムがあり、場合によっては8〜12のシステムがあります。 多くの場合、システムは共有フォルダーの一部のexels、一部の元マクロとスクリプト、一部のストアドプロシージャは一部の自作プログラムによって呼び出されます。
先物、スワップ、オプションなどのデリバティブ金融商品取引のポジションとリスクを管理するシステムを作り直すように依頼されました。
以下に、このプロジェクトのために実施するさまざまなタイプの活動について説明しました。
*範囲を定義する
前述したように、会社には各機能に複数のシステムがあります。 これらのシステムの一部はITによってサポートされているため、識別、分解、および改造が比較的簡単です。 私にとっての主な問題はエクセルであり、自作のコンポーネントとトレーダーやリスクが使用するあらゆる種類のマクロです。
ユーザーとのほぼすべての連絡の結果、公式システムは一部の機能に十分ではないことがわかりました-レポートが間違った形式であり、次にユニットが間違っている、間違ったモデルが使用されている、または取引がまったくサポートされていない このような不幸は、特定のユーザーの技術的知識、またはトレーダーが許可を得ることができる人の存在に応じて解決されます。 ほとんどの場合、問題の解決策は、いくつかのExcelがゆるく接着されていることであり、時には他のローカルライブラリまたはデータベース...
リスクシステムを作り直し、質問の1つは「 新しいシステムがこのエクセルに取って代わるべきか？ 」です。 同意する-質問は簡単ではありません。 一方、これが既存のシステムの欠陥である場合、新しいシステムはそれを考慮に入れて修正する必要があります。 一方、トレーダーはエクセルを愛し、それを決して下車しません。
問題定義の問題には別の部分があります。 システムXがあり、特にpsi lambdaをomega-roに変換できます。 便利な変換のように見えますが、すべてのツールで機能するわけではなく、誰がそれを使用するかは明確ではありません。 誰も認識されていませんが、タスクは簡単ではなく、この機能を6か月ではなく今すぐ追加する方が安くなります。
ここでの私のタスクは、システムの境界を描き、プロセスのすべての参加者がプログラマーからリスク管理者まで、このラインに同意するようにすることです。
*トレーダーを理解する
不思議ではありません- 誰かがユーザーのビジネスを理解する必要があります 。 正直なところ、私たちとプログラマーはあまり賢くはありませんが、トレーダーのプロセスやエクセルに対処するのに十分忙しいです。
あるトレーダーが最初に言ったのを覚えています。「このスプレッドの後ろに長いガンマがあります。」 ええ、そして脚の間の有効期限。
ここでの私の仕事は、トレーダーや他のビジネスユーザーが私に言っていることを理解し、彼らの要件をエンジニアが理解できる言語に翻訳することです。 そして戻る。
*優先順位付け
次のポイントは優先順位付けです。 もちろん、 ソフトウェアエンジニアは自分でどこから始めればよいかをよく知っています。たとえば、最も複雑な、またはおそらく最もリスクの高い、またはシステムの残りの部分から構築することです。 ここで私はアドバイスしません-特に彼らが尋ねないとき。
しかし、ビジネスの観点からは、優先順位もあります。 そして奇妙なことに、彼らはしばしば神秘的で理解できない。
私が働いている会社は世界中に散らばっています。 各地域には特定の機能があります-取引された製品、プロセス、報告と規制のレベル。 したがって、電源をフェーズに分割することは非常に論理的で望ましいことです。
私は常に疑問に直面しています- 最初は誰ですか？ 最初に石炭のオプションを開発する必要がありますか、それとも外国為替サポートを追加する必要がありますか？ それとも、ディレクターにレポートを送信する必要がありますか？
この問題を解決するための多くの手法があります。たとえば、 最大のリスクがどこにあるかを確認してください。 石炭または外国為替のトレーダーである、単位時間あたりにより多くのお金を失うことができるのは誰ですか？ または、もう一方を見ることができます-2週間で石炭のサポートを、8で外国為替を得ることができるなら、何がより速く行われるべきですか？
私の仕事の一部は、それらの上司の例についていくつかの図を提供することです。 多くの場合、数字に加えて、何らかのプロセスを説明する必要があります。たとえば、あるプロセスが別のプロセスとどのように異なるか、ある種の取引が別のプロセスとどのように異なるかなどです。 そして、時には、より少ない感覚でより多くの感覚を得る方法を考えてから、少しだけ仕上げて、一般的に良い方法にすることは、一般に多くの価値があります。 同意して、プログラマーがそのようなゴミに従事したいとは思わないでしょう！
*「すべてが機能する」ようにプロセスを整理する
これは興味深い点です。 システムの変更は、多くの場合、プロセスの変更に影響します 。 プロセスの変更は非常に簡単な場合があり、システムを学習しながらプロセスを変更できます。 ただし、プロセスの変更は多くの場合、地理的に異なる場所やタイムゾーンの多くの部門に影響します。
そのような場合、 既存のプロセスの検討を開始する必要があり、すべての参加者に偏りのある尋問
私は思うし、ここであなたはプログラマーもプロジェクトマネージャーもそのようなチアゴモチンに対処したくないということに同意するだろう。
*エンジニア向けの成果物を作成する
ここでは詳しく説明しません。誰もが仕様、私たちの事例、物語、その他の成果物に精通しています。
*デモンストレーション、トレーニング、およびUAT
最後になりましたが、システムを実稼働に移します。
まず第一に、 それをユーザーに示す必要があります。 当社では、これは面倒なビジネスであり、多くの時間がかかります。 実際、私のビジネスユーザーは世界のさまざまな地域に住んでいる忙しい人であるため、デモは通常、その特定のユーザーに合わせて1対1で行われます。 私はこれに費やした人月を計算しようとさえしていません...
次はトレーニングです。 残念ながら、特別に訓練された少女はこの機能を扱うことができません-トレーダーがデルタとスケールについてトリッキーな質問をし、しばしば修正のために製品を送るためです。 また、独自のスプレッドシートも用意されています。これは、トレーニングプロセス中に、わずかな手の動きで...
最も難しい部分はおそらくUAT（ユーザー受け入れテスト）です。 これは、忙しいトレーダーを雇われたシステム（スプレッドなど）から新しい素晴らしいシステムに移行する必要がある場合です。 そして、彼女は刺し、屈みず、収andせず、アナリストは、すべてが以前、そして今、彼がクリックしたとき、なぜ働いたのかを理解しようとしています-いいえ！ ここで、デルタ-5.2とそこ-5.7-そして、一定のマトゥキの下でストレスを感じて、あなたが見つけようとしている-どのくらい必要ですか？
そして最後に、彼はトレーダーが各アイテムに「見た、動く」に署名しなければならないテストシナリオのリストを含む紙を準備し、スリップする必要があります。 楽しい、一般的に。
誰が分析を行っていますか？