ITの請負業者との仕事の整理

バリケードの両側のトピックに関する意見に興味がある。 ITサービスを提供する人と、職業によって請負業者とやり取りする人。 すぐにすべてがITサービスの消費者の利益のために書かれていることを考慮に入れてください。



以下のすべては、ITが主要なビジネスの効率を向上させるためのツールであると考えられている、その活動が情報技術に関連していない企業の観点から書かれています。 ゼロから作成された、または会社のプロセス用に高度にカスタマイズされた情報システムの例。



会社は事実の実現まで成長したと理解されています-コンピューターと情報技術のすべての面で、「管理者はチョコレートを飲まない」と書かれたTシャツを着た1人のひげを生やした男では対処できません。 プリンターカートリッジの補充からサーバーの管理、いくつかのプログラミング言語でのコードの作成まで、あらゆることを実行します。



すべてのコンピューターアプリケーションは製品です。 たとえば、紙のように。 それはすべてのオフィスで必要ですが、誰もがすべてのオフィスで紙屋を作りません。 彼らはそれを買うだけです。 ソフトウェア製品は、プロベースで作成する人からも購入する必要があります。



すべてを書き留めるために1人または2人を雇うという選択肢はまったく考慮されるべきではありません。 なぜなら この状況では、だれも適切に文書化することはできません。 そして、これらの人々が去ると、彼らが作成したものがどのように機能するかを理解することは非常に困難です。 そして、会社の作業プロセスが構築されるシステムについて話すと、この問題はビジネス上および財政的に重要になります。



また、ITコンサルティングサービスを提供し、完全なITサポートビジネスを提供する組織を雇うことは正しくありません。



会社が幸運であり、プロのチームが請負業者として選ばれたとしましょう。 その後、彼らは本当にすべてを行います-要件を収集し、分析を行い、製品を作成して実装します。 それらに依存してビジネスのメッセージを置くことによって。 結局のところ、それらを除いて、誰もこのすべてがどのように機能するかを知りません。 したがって、継続的なサポートが必要です。 彼らが提供する価格で。



サポートの価格だけで、誰も制限されません。 製品開発の価格はずっと高くなっています。 そして、あなたのビジネスが常に経験のある人々のために彼らの製品の開発と改良を必要とすることを確実にすることは難しくありません。 しかし、その後、専門家を雇った、忘れないでください。



しかし、このシナリオでは、彼らは会社の内部機密情報の大部分にアクセスできます。 はい、もちろん、秘密保持契約が締結されます。 しかし、企業秘密を外部組織に委任することに全員が同意するとは限らないと思います。 機密保持契約があっても。

彼らは別の組織です。 そして、どの組織でもそうですが、彼らには1つの目標があります-お金を稼ぐことです。 単なるビジネスであり、それ以上のことはありません。



私の意見では、開発プロセスを分離するのは正しいことです。 組織内で分析とタスク定義が形成され、開発自体が請負業者に転送される場合。



請負業者と組織内の両方で通常の作業を整理するには、チームを作成する必要があります。 最も単純なケースでは、このチームに4つの役割があります。 プラス1つの役割として請負業者。



マネージャー（システム所有者）

何をする

システムがどの方向に開発しているか、企業がこのシステムから1年で必要とするもの、おそらく2つの開発戦略を決定します。 予算を承認します。 全体として請負業者と協力する責任があります。 請負業者にタスクを承認します。 タスクの優先度を設定します。



しないもの

彼は会社の責任者ではありません（責任者は、そのようなタスクを可能な限り部下に委任し、対象ビジネスの対象問題を処理する必要があります）。 おそらく、機能のいずれかの副長または長。 しかし、ITではありません。 システムの開発方法の問題は扱いません。 つまり タスクを設定します-データストレージの信頼性を高める必要があります。 実際に増加する方法の問題に対処することなく。



特徴

会社の中核事業を完全に理解している人。 会社のさまざまな機能で豊富な経験を持つ。 会社に一定の権限と政治的重みを持っている。 管理上はIT構造に属しておらず、ITテクノロジーの専門家でもありません。



アナリスト

何をする

会社の現在のプロセスを内部文書の形式で説明します。



既存のプロセスの最適化と新しいプロセスの導入を開発して管理を提供します。 たとえば、売り手がクライアントと契約を結ぶのに2時間かかります。 分析の過程で、自動製図と印刷を実装すると、契約の準備に2分かかることが判明しました。



内部顧客の空間的希望を特定のドキュメントに変換します-ビジネス要件。 顧客の当初の希望に基づいてビジネス要件を満たす責任があります。



新しいソリューション、製品、および改善の実装に関する請負業者の提案を受け取りました。 会社がどれだけ必要かを分析します。 必要に応じて、会社の経営者に実装を提供します。



しないもの

管理上の決定を行うのではなく、それらを提供するだけです。 請負業者のタスクに優先順位を付けません。 一般に、彼はITを理解しているため、完全に実現不可能なアイデアをアーキテクトに伝えません。 請負業者との交渉では、彼は彼自身の意見の権利を持たない-彼は経営者と合意されたものだけを表明する。



特徴

企業のプロセスに精通している。 彼は、たとえ従業員自身がこれを言うことができないとしても、部門または個々の従業員の仕事を最適化する方法を提案できます。 表面的にIT技術に精通している。 アナリストが彼自身であり、請負業者に引き付けられないことが重要です。 そうでなければ、請負業者がお金を稼ぐために開発が行われます。



建築家

何をする

マネージャがシステムの開発方向を決定する場合、アーキテクトはシステムの開発方法を決定します。 つまり 開発戦略の技術面。 20人の新しい従業員によって作成される負荷を増やしながらシステムが機能することを保証するために何人のサーバーを引き付ける必要があるかなどの質問に答えます。



彼はアナリストから提供されたビジネス要件の技術仕様を作成し、請負業者に渡します。 技術仕様のビジネス要件への準拠を担当します。



それらの請負業者から作業計画を受け取ります。 人件費の評価を伴うタスク。 人件費の過大評価について提供された計画を分析します。 必要に応じて、請負業者と調整して修正します。 マネージャーが署名する前に作業計画を承認します。



請負業者が提供するパッケージが技術仕様に準拠しているかどうかを確認します。 彼はテストに参加しています。 作業の受け入れと、メイン環境への変更の転送を決定します。

請負業者との交渉では、彼はこれがどのように行われるかについて彼自身の立場を持つべきです。 しかし、何をすべきかという質問はマネージャーによって決定されます。



しないもの

独立したシステムの改善を行いません。 テスト中に見つかった欠陥またはそれらの不適合を修正しません。 割り当て。 それらについてのみ請負業者に通知します。 アプリケーションを管理またはサポートしません。



特徴

システムの絶対的な知識が必要です。 一般に、テクノロジーとITプロセスの両方に関する深い知識。 交渉できるように、あなたの視点を有能に主張します-作品の最終的な価格と結果の製品の品質はそれに依存します。



管理者

何をする

ユーザーと連携します。 システムを起動して削除し、パスワードをリセットします。 このフォームを開くためにクリックする必要があるものや、そのボタンが非アクティブである理由などの問題についてアドバイスします。



クラッシュやシステムエラーにタイムリーに対応します。 サービスを再起動し、サーバーを再起動できる必要があります。 他の定型的なアクションを実行して、システムの健全性を維持または復元します。 彼が解決できない事故が発生した場合、問題を正確に説明し、サポート契約に基づいて請負業者に渡します。



請負業者から受け取ったパッケージをテスト環境にインストールします。 テスト環境でのパッケージの受け入れテストに参加してください。 作業を受け入れた後、メイン環境にパッケージをインストールします。



パスポート、ユーザーへのサービスの提供に関する合意、およびシステム上の他の内部文書を作成します。

管理者が実行できるすべてのアクションは、システム管理者をコンパイルし、システムの更新および改善後に関連性を維持する「管理者ガイド」で説明する必要があります。



しないもの

システムに対して独自の改善や変更を行いません。



特徴

実際、彼の仕事は継続的なルーチンです。 彼は特別な知識を必要としません。 数十の操作を実行する必要があります。 そのほとんどは、管理者ガイドで説明されています。 しかし、マインドフルネスはストレス耐性と責任です。



請負業者 （チーム全体が請負業者の側でも作業していることは明らかですが、顧客の観点から見ると、チーム全体が1つのまとまりです）



何をする

アーキテクトから参照条件を受け取り、分析します。 建築家に、マネージャー、アナリスト、プログラマー、テスターの人件費を示す作業計画を提供します。 計画に同意して明確にした後、マネージャーが署名した作業指示書と、この計画を作成したアナリストの作業に対する支払いを受け取ります。 合意された計画に従って作業を実行します。 変更されたパッケージと変更されたバージョンのユーザーガイドを管理者に提供します。 受理証明書をテストして署名した後、彼は支払いを受け取ります。

彼の経験に基づいて、彼は企業分析（および分析のみ）のソリューションを提供しています。



しないもの

企業内の要件を収集してプロセスを分析しません。 請負業者によるプロセスの分析には、会社にとってそれほど必要ではないが、請負業者に収益をもたらす決定が含まれています。



彼は、アナリスト（ビジネスパートの場合）またはアーキテクト（テクニカルパートの場合）を除き、システムに関する提案を行いません。 会計士、マーケティング、販売、または他の人に決定を「売る」試みは、責任者の公罰で止められるべきです。



メイン環境にアクセスできません。 テスト環境に-おそらく、ただし変更を加える権利なし。 すべての開発は、開発環境で実施する必要があります。



特徴

請負業者の役割は、会社のアナリストに対する経験に基づいてソリューションを提供し、アーキテクトから受け取った委任条件に基づいてコードを記述することに限定すべきです。



契約について一言

会社間で、クライアントと請負業者は2つの独立した契約を締結する必要があります。



サポート契約 。

自身の管理者が解決できない重大な事故に関する決定を提供する期限と、これらの期限に違反した場合の罰則について説明します。 サポート契約は安価です。 彼らは、情報システムの誤動作が原因で発生した損失を部分的に補償することができます（それに関しては）。 したがって、彼は常に関連性があり、タイムリーに再交渉されることが望ましい。 独自の管理者とともに、IT障害からビジネスを保護するツールです。 自分の管理者を辞めた場合、管理タスクを請負業者に一時的に完全にシフトできます。 サポート契約の更新に問題がある場合-契約が次の期間に更新されるまで、システムの完全なサポートを引き継ぐ独自の管理者がいます。 通常の状況では、管理者とサポート契約の両方が必要です。



システム開発契約 。

クライアントから請負業者にタスクを転送する手順、完了した作業、支払いを受け入れる手順、および論争のある問題を解決する手順を説明するフレームワーク契約。 ここでは、請負業者のサービスの価格を規定する必要があります。 たとえば、請負業者（アナリスト、プログラマーなど）の各リソースの単位時間あたりのコスト。 欠席しても、これは会社の現在の仕事に影響しません。 請負業者からの事業の独立性を確保する。 はい、新しい機能はありませんが、少なくとも現在の機能はすべて動作します。 極端な場合には、システムの開発のための入札を発表し、開発を別の組織に移すことが可能です。 同社には、システムに関するドキュメント、彼自身の知識を持つ建築家もいます。 しかし、これは最悪の場合であり、同じ組織がサポートと開発に従事する必要があります。