前回の記事「 コンピューター情報システムとは 」では、ユーザー（顧客）とプログラマーの相互作用における基本概念と用語の理解について重要な質問を提起しました。 約束どおり、私はこのトピックを拡大し続けます。 そして、ソフトウェア製品の開発と実装のプロセスの適切な計画についてお話したいと思います。
私の仕事の性質上、私は常にデザインの仕事に出会います。 そして、プロジェクトの開始時に、私は有能な計画という困難な課題に直面しています。 なぜこれがそんなに重要なのですか？ 良い計画は成功のほぼ半分です。 計画がなければ、目標を達成し、期限を守るために、明確に一貫した作業を構築することはほとんど不可能です。 これは、チームワークに関して特に重要です。
原則として、計画の重要性について多くのことが書かれています。 そして、私はここで有名な真実を繰り返しません。 それは簡単です：あなたがどこに来て、正しいルートを得るために管理する必要があるかを知っているなら、あなたはゴールに達します。 そうでない場合-悲しいかな、誰もあなたが最終的にどこになるかを事前に推測することはできません。
ITプランニングの落とし穴
目標を達成するための計画では、次のような要因を考慮する必要があります。
- 記載された目標、すなわち 取得する結果。
- 外部要因：材料、環境、プロジェクト参加者の特徴、将来の消費者など。
物質世界のオブジェクト、たとえば家の建設について話している場合、すべてが比較的簡単です。 彼の願いを伝える顧客がいます。 特定の機能を持つ土地のプロットがあります。 さまざまなパラメーターとコストの建築材料があります。 そして、一定の予算があります。 これに基づいて、プロジェクトの最終バージョンが決定され、見積もり、作業段階が計画されます。 建設に遭遇したことがない場合でも、建設プロセス中を含め、多くの家を見てきました。 結果は重要であり、外部要因も同様です。 したがって、ソリューションの選択と計画の準備が困難になることはほとんどありません。
コンピューター情報システムを使用する場合、重要な要因と結果が不足するという問題に直面します。 たとえば、家の基礎を選択するとき、明確な初期データと物理法則に依存するため、ここでは機能しません。 さらに、各ソフトウェア製品の実装は独自のプロジェクトです。
各チームは、すべての人と同様に、独自の方法で一意です。 そして、彼らには常に独自の特別なニーズと願いがあります。 彼らは、既存の標準プログラムでは不十分な場合に「自分自身のために」ソリューションを得るために、ソフトウェアの開発と実装を命じます。
ITの分野でプロジェクトを計画する際には、次のことが必要です。
- 顧客の機能とニーズを調査するため。
- タスクを明確に理解し、すべての要望を考慮してください。
- 選択したソリューションを顧客と調整します。
そしてその後にのみ、行動計画の開発に進むことができます。 この場合、顧客は営利団体または非営利組織の任意の人です。 主なことは、プロジェクトを注文して将来使用する人が常にいるということです。
実践では、顧客との準備作業だけで問題が生じることが多いことが示されています。 そして、ここで、定義に基づいたアプローチが助けになるかもしれません：
コンピューター情報システムは、プログラミング言語で表現されたアイデアです。「コンピューター情報システムとは」という記事で、このような定義の詳細な説明と正当化を示しました。 理解を深めるために、これを読んでいない人に慣れておくことをお勧めします。
ソフトウェア製品のアイデアと選択
最初に理解するべき最も明白なこと：選択または作成されたソフトウェア製品があなたのアイデアを満たすために注文するためには、2つの要素の組み合わせが必要です：
- アイデア自体の存在;
- 他のプロジェクト参加者向けの明確で明確な説明。
そして、プロジェクトのアイデアを明確かつ第三者が理解できる説明の段階で、いわゆるBPMスキームは非常に有用であることが判明しました。 つまり、ビジネスプロセスを説明するためのグラフィカルな表記法です。 私の記事「 ビジネスプロセスとは何か、ビジネスプロセスの説明 」で、その詳細とBPM表記の詳細を確認できます。
同時に、これは必ずしもビジネスプロセスに関するものではないことを理解することが重要です。BPMツールを使用すると、労力やその他のタイプのプロセスをうまく説明できます。 アイデアを翻訳するためのオプションを明確にシミュレートします。
ビジネスの説明またはタスクの実行には、プロセスと機能の2つのアプローチを使用できます。 また、「 ビジネスモデリング 」という記事で、それらの違いと機能について詳しく書きました。 主なアプローチ 。」
ソリューションを検索する（アイデア自体を定式化する）場合、多くの人がモデリングの機能バージョンを好みます。 彼は、問題の本質とそれを解決するために必要なツールを理解するのに役立ちます。 私の個人的な経験が示すように、タスクの効果的な解決と作業計画の準備には、プロセスモデリングが最適です。
方法：
- ビジネスプロセスのグラフィカルな表記（説明）が作成されます。 最も高度で洗練されたツールとしてBPMN 2.0形式を使用することをお勧めします。これを使用すると、エラーやあいまいなソリューションの可能性が減少します。
- BPMN表記の形式で表現されたアイデアは、関係者（顧客、ユーザー、場合によっては開発者）と議論されます。
- 合意されたアイデアの下で、彼らはソフトウェアを選択するか、ゼロからソフトウェア製品を書くことにしました。
- 選択したツール、ソリューション、および詳細なアイデア（BPMN表記）を考慮して、作業計画が作成されます。
BPMNモデルを作成する方法
BPM表記のコンパイルを成功させるには、特定の知識が必要です。
- 組織の機能を理解する（ユーザーインタラクション）。 これがないと、アイデアの具体化にはエラーが含まれる可能性が高くなります。 その結果、システムを使用することは不便または不可能にさえなります。
- アルゴリズムの機能と、少なくともプログラミングの基本を理解します。 これは、ソフトウェアシステムの正確かつ現実的な要件を設定するために必要です。
- グラフィック表記を扱うスキルを持っている。 この形式は、他のインフォグラフィックと同様に、すべてのプロジェクト参加者がタスクを表示するための最も視覚的で理解しやすいオプションです。
企業または非営利団体と協力して、協力プロセスは次のように構成されています。
- 問題の一般的な声明は会社の長が作成します。
- 作業段階と実装機能の明確化-ソフトウェア製品を扱う部門の長と従業員。
場合によっては、すべての重要なニュアンスについて十分な情報を得た1人の人物が、問題全体と詳細の説明を実行できます。
さらに、結果の説明はグラフィック表記の形式で作成され、いくつかの詳細レベルも表示されます。 それらの数は、システムの複雑さに依存します。
次の段階は、洗練と調整です。 ここでは、完成した表記法が組織のリーダーと従業員によって研究され、必要に応じて明確化されます。 同じ段階で、アイデア自体の詳細に変更を加えることができます。これにより、従業員のレベルや部門間のやり取りなど、作業の最適化に役立ちます。 ここで理解することが重要です：グラフィカルモデルは、多くの「粗さ」、機能の不必要な複製などを確認するのに役立ちます。 そしてもちろん、アイデアを記法の形で定式化するとき、ワークフローのこれらの欠点を議論し、それらを最適化する方法を検討することができます。
ソフトウェア製品の選択
グラフィカルな表記の形で具体化された一貫した詳細なアイデアがすでにあります。 非常に重要なのは、記法がすべての議論を経て、会社の経営陣が最終版に署名したことです。 ソフトウェア製品の選択または作成に対する相互理解に自信を持って進むことができます。
今日では、営利団体や非営利団体がソフトウェアソリューションをゼロから作成することは非常にまれです。 高価で長いです。 さらに、ほとんどのアイデアには、少し構成および/または変更するのに十分な既製（標準）のソリューションがあります。
ここでは、トピックと機能に適したすべてのソフトウェアシステムの中から、顧客のアイデアに最も近いアイデアを持つものを選択することが非常に重要です。
たとえば、「営業部門の自動化が必要です」という考えです。
ステージ1. CRMシステムは実装に最適です。 これらのソフトウェアソリューションは、営業チーム専用に開発されています。
ステージ2。既存のすべてのCRMのうち、選択した作業アルゴリズム（アイデアの実装）に最も適した機能を持つCRMを選択する必要があります。
ステージ3.リストから適切なCRMを選択するには、追加機能を検討します。他のソフトウェア製品との統合のための既製ソリューション、アイデアに役立つ組み込みツールの存在、価格/品質比。
理解することが重要です。あらゆるアイデアの実装において、人々はプロセスの不可欠な部分です。 そして、彼らが選ばれた決定をしなければ、ソフトウェア製品は、そのすべてのメリットのために、開発者の観点から、アイデアを実装するのにふさわしくないでしょう。
さらに、ビジネスプロセスの説明（アイデアの実施形態）は、まず第一に、人々の活動の説明です。 アイデアは人間の活動に関連しています。 自動化は補助的な要素にすぎません。 したがって、ビジネスプロセスの記述は、まず第一に、人々の仕事の記述です。 そしてその時だけ-質問の技術的な部分。
残念ながら、実際には、BPMN表記が技術的な部分に完全に当てられていて、実際にはプログラマー向けのアルゴリズムを作成するための代替方法であるときに、誤ったアプローチに出くわしました。 この場合、人とソフトウェアソリューションとの相互作用は舞台裏にあります。 また、実際にソリューションを実装する場合、オーバーレイや誤解がしばしば発生します。 その結果、アイデアは長く困難な時期に実現されます。 または、失敗であることが判明しました。 その説明で最も重要な要素である人々の行動を忘れていたからです。
プロセスアプローチの利点
男は順次考えます。 同時に、いくつかの異なるアクションを通して考え、いくつかのタスクや方向をカバーすることは非常に困難です。 人は一歩一歩考え、次々とやってくる課題を解決します。 したがって、一連のアクションの形でのアイデアの実施形態が最も適しています。 それはあなたがすべての詳細を熟考し、重要なものを見逃さないようにします。
プロジェクト参加者による決定の一意性と調整の容易さ。 グラフィック表記は読みやすく、顧客企業の頭に直観的であり、アルゴリズム化のフローチャートに近いため、開発者にとって便利です。 結果として、それらは調整が容易であり、実装中に実質的に矛盾はありません。
BPMN形式はエラーの回避に役立ちます。 グラフィカルな表記法の開発環境と表示の単純さは、ほとんどのエラーを時間内に認識し、論理的な矛盾や「不完全な」プロセスを回避するのに役立ちます。
BPMN表記法、その使用の基本要素と原則、および私の記事「 例によるBPMNの簡単な説明 」で実際的な例を詳しく学ぶことができます。 その他の例は、将来の出版物に掲載される予定です。
