これらのプロジェクトと、特にコンピューターアプリケーションを組織のビジネスプロセスに導入するプロジェクトとの違いを十分に理解する必要があります。
多くの場合、問題につながる2つのリスクがあります。
1.ソフトウェア開発を専門とする人は、彼らがどのように実装の領域に入るのか気づかず、プロジェクトが膨張し始めます...通常は致命的な結果になります;
2.実装および組織プロジェクトを専門とする人は、複雑さを理解せずに開発を開始し、結果の品質が大幅に低下し始めます。これが最良の場合です。
クリーンな実装またはクリーンな開発に従事している人にとって-これらの問題は不明です。 しかし、これらはまれな幸運なものです。
詳細に入る...
特徴的な機能
まず、コンピューターアプリケーション開発プロジェクトを区別できる基準を分析しましょう。
1.そのようなプロジェクトの結果は、コンピューターアプリケーション（Web、Windows、Android、iOSなど）、モジュール（機能ブロック）、またはいくつかの重要な変更（「重要な変更」とは何か-以下で分析します）です。
2.これらのプロジェクトには、コンピューターアプリケーションのアーキテクチャと対応するテクノロジースタックの詳細な知識が必要ですが、同時に、ビジネスプロセスに関与するユーザーまたは従業員との最小限の対話が含まれます。
条項2-「ユーザーとの対話にほとんど影響を与えない」部分-これは、コンピューターアプリケーションを開発するプロジェクトと、ビジネスプロセスにコンピューターアプリケーションを導入するプロジェクトを区別する重要な機能です。 これは、そのような相互作用がないことを意味するものではなく、もちろん存在するものであり、最小限のものです。
開発プロジェクト中に人との相互作用の割合が増加し始めた場合、そのようなプロジェクトは実装プロジェクトにエスカレートするリスクがあり、これは複雑さとリスクの別の重要なカテゴリーです。
重要な変更
個別のサブカテゴリは、1つの目標によって結ばれた変更のグループに関して起動する価値のあるプロジェクトとして識別できます。これは、長時間続き、複数のバージョン（リリース）に影響を与える可能性があります。
変更または変更のグループが単一のリリースに適合する場合は、プロジェクトを開始しないでください。
ただし、1つの変更によって他の一連の変更が行われた場合、プロジェクトを開始することを検討する価値があります。理由は次のとおりです。
1.これらの変更を調整する必要があるのは、 さまざまな専門家が変更を加えることができます。また、さまざまな人々を知っており、調整できる人が必要です。
2. 1つの変更がシステムの他のメカニズムの変更につながる可能性があります。これにより、さまざまなリスクを考慮に入れ、それらのリスクに備える必要があります。
3.多くの場合、変更により開発者はさまざまなメカニズムを複製し、新しいメカニズムを古いメカニズムの隣に作成します。一連の変更が完了したら、古いメカニズムをシステムから削除する必要があります。 調整がなければ、これらの「欠陥」は永遠にそこにとどまる可能性があり、長期的には悲しい結果をもたらします。
例 ：
タスク管理システムでは、参加者ブロックを拡張する必要がありました。 従業員だけでなくグループも選択する機能を追加します
-インターフェースの調査から始めましたが、アクセスサブシステムを変更する必要があることが判明しました
-アクセスサブシステムの変更を開始し、古いサブシステムをしばらく残す必要があることを認識したため、古いサブシステムを壊さずに近くに新しいメカニズムを作成しました。
-インターフェースに変更を加え、新しいモデルと友達になり、新しいモデルをデバッグしました
-今、あなたは古いメカニズムを削除する必要があります
4つのポイントすべて-5か月と3つの開発バージョンにまたがりました。 調整がなければ、それははるかに長くなり、その結果、単にターゲットベクトルを失い、古いメカニズムを削除する必要があるという事実を忘れることができます。
危険な瞬間
非常に危険であるが非常に一般的な状況は、顧客が特定のシステムの開発を要求するときです：財務会計、営業マネージャーの仕事、またはそのような何か。
一見、これは一般的な開発プロジェクトのようです。 何かを開発する必要があります。
しかし、このプロジェクトは次のように成功する可能性がほとんどありません。 すぐにアプリケーションの準備ができたことがわかりましたが、何らかの理由で顧客は満足していません。 システムが機能しません。
その理由は、実装は別の知識領域であるためです。 また、実装プロジェクトはプロジェクトの別のカテゴリです。
著者はこれらのプロジェクトを長い間専門としており、この間ずっとコンピューターアプリケーション開発プロジェクトの存在を信じていませんでした。
長い間、私はさまざまなITプロジェクトを実装することができましたが、開発に影響を及ぼすのはエッジのみです。 これは大きな問題を引き起こしたため、私は常に開発者を避けようとしました。 タイプ1C UPP 8の一般的な製品を導入することをお勧めします。その後、変更できます。 そして、これは非常に現実的ですが、多くの1C開発者はそれを本当に信じていません。
合計
しかし、私はこの1年間、実装プロジェクトに携わることができ、幸運にも開発プロジェクトと密接に結びついていました。 とても難しい年でした。
その後、これらの定義が作成され、記事の冒頭で読みました。
おそらくアプリケーション開発者向け-私は新しいものを発見していません。 エンドユーザーから遠く離れたインターネットの壁の後ろに座っている人は、コンピューターアプリケーション開発プロジェクトにのみ関与しています。これはすべて灰の日と理解されています。
しかし、さまざまな組織のIT部門で働く人々にとって、彼らはすべて厳しい「仕事の日」です。
ほとんどの組織では、そのようなプロセスはないと確信しています。
1.開発プロジェクト管理
2.リリース管理
3.リリース変更管理
ITILの慣行では必要であると言われていますが、これらの推奨事項の多くは無視されています。 または試してみましたが、失敗しました。
私はしばしば実装プロジェクトに対処する必要がありますが、今年は開発のトピックを掘り下げ、上記のプロセスをストリームに入れなければなりませんでした。
何に気づきましたか？
1.情報システム開発のリソースとコストの予測が容易になりました
2.開発者は、変更またはリリースだけでなく、意図的に長期にわたって調整および調整されたプロジェクト全体を閉じると、より前向きな仕事ができます。
3.プロジェクトが開発者によって閉じられている場合に特に適しています。 これは小さな変更ではありません-これはすでにプロジェクトです。 非常に異なる感覚。
4.そしてもちろん開発の品質-テールは失われず、一連の変更はより正確でエラーが少なくなります
5.理解できる限り、SCRUMでは、プロジェクトは「要求」または「注文」に似ており、「顧客」から来ることができ、異なるリリースで閉じることができるタスクに分割する必要があります。
ITILの推奨事項を実装した経験は何ですか？ また、コンピューターアプリケーション開発プロジェクトをどのように定義しますか？ それらを実装プロジェクトと区別していますか？