これらは、政府機関との個人的な経験から得られた小さな結論であり、真実であると主張するものではありません。 近い将来、私は州の機関で働くように切り替える予定ですので、内部からの仕事の構築に関する投稿もお待ちください。
0.始める前に
可能であれば、雇用主にとって有益でない画像プロジェクトを取り上げないようにしてください。 同社は、こうしたプロジェクトに参加して連絡先を開発し、将来の契約を獲得しています。 これには深刻なリソース削減が伴い、プロジェクトの初期利益が0であっても、要件の変更にはすべてのレビューが必要です。 そして、プロジェクトは固定価格の一部として実施されます。 コインの反対側-顧客との行動モデルが構築されたこのようなプロジェクトの積極的な完了は、まず顧客からの+100500の評判と尊敬をもたらします。 （人生の例：大規模な州の組織で評判の良いPMはその後、コンサルタントとして定期的に引き付けられ、彼はお金と専門的なつながりの形で酸っぱい利益を得ました）。
1.はじめに
契約が締結されているため、作業を開始する必要があります。 最初のステップは、婚約の規則に署名することです。 このドキュメントでは以下について説明する必要があります
•プロジェクトの位置と役割を示す、両側のワーキンググループの構成。
•文書に署名する権利を有する人。誰がどの文書に署名するかを示します。
•会議、会議などを開催するための規則。
•請負業者の内部文書およびその他のリソースへの顧客の従業員のアクセス順序（たとえば、顧客はソースコードまたはバグトラッカーのバージョン管理されたリポジトリへのアクセスを要求できます）。
•さまざまな重要性の対応を検討するための用語。
相互作用ルールに署名した後、要件の調査と収集を開始できます。 働くアナリストを立ち上げる。 競争のために準備されたToRと仕様（もちろん、それらを準備していた場合、または会社がそうでない場合）はアナリストを提供しますが、それらに依存することはできません。 新しいToRを準備する必要があります。 そして、ここに簡単なルールがあります-ToRがより詳細であるほど
また、顧客企業では、プロジェクトに本当に興味のある人を見つける必要があります。 ほとんどの場合、これらの人々は通常の専門家として、または対照的に部門および部門の長として働いています。 部門の長があなたの目標になることはめったにありません。 興味のある人とは、仕事が簡素化され、より効率的になる人です。 そのような人を見つける可能性が高くなります。 あなたとあなたのチームに、情報システムの歴史や注文を知ってもらうように頼んでください。 注文は偶然ではなく、上から発行された規制文書が先行しています。 したがって、あなたは州に必要な基本的なビジネス要件を理解し、これをまったく理解していない人が示唆するものではありません。
2.技術仕様の署名
管理、計画、開発の分野における現在の傾向にもかかわらず、参照条件は、将来の開発を正確に記述する必要があります。 規制に従って、あなたが書いた作業明細書（実行する会社）に情報を含めたり除外したりすることを意識的または無意識的に要求する人が技術タスクに署名する必要がある場合、同意します。 最初のTKを公式の通信で送信し、最後に修正されたTKにバージョン履歴シートを添付します。このシートには、TKが変更された理由が示されます。
この方法は、このすべての事務処理のためのリソースがあり、開発およびプロジェクト管理方法でこの方法を使用できる場合、CTZの承認を得て使用することもできます。
作業明細書の項目を考慮していないか、非常に曖昧に書いているが、入札中にこの項目が契約の仕様に含まれている場合、顧客はこの問題であなたを好きなように愛することができます。
また、作業スケジュールをTORに添付する必要があります。 それがガントチャートであるか、ポイントと作業の開始と完了の指示がある単なるテーブルであるかどうか-あなたが決定します。 ただし、変更の結果を顧客に視覚的にさらに説明するために、ガントチャートに署名することをお勧めします。 顧客のスケジュールと内部スケジュールは異なるものであることに注意してください。 顧客のスケジュールでは、期限は少なくとも契約の終了まででなければなりません。 これにより、機能変更のリクエストをより少なく受信できるようになり、さらに、すべての緊急事態と遅延に対応するためのタイムバッファーが確保されます。 また、変更されたスケジュールを顧客に送信するときは、不快なインシデントが発生しないように、送信内容を確認してください。
3.プロジェクトの実施と変更に対する反応
使用する開発方法とプロジェクトの管理方法は、あなた自身のビジネス（またはあなたの会社）です。 変化に対する反応についてもっと触れたい。 政府機関と協力する場合、仕事の質と製品の販売だけを考えることはできません。 雇用主の観点から、契約に基づくすべての義務を果たし、会社の利益を上げる必要があります。 そして、あなたがこれを盗んで殺すためにうそをつく必要があるとしても、彼を正当化するようにしてください。 機能の変更を求める公式のリクエストについては、すぐにこのリクエストの検討を開始する公式の手紙で返信してください。 時間とリソースのバッファがある場合でも、仕事のためにアプリケーションを受け入れないでください。 可能であればいくつかのアプリケーションを収集し、ワーキンググループの会議をスケジュールします（官僚の役人に復venしていると想像してください）。 会議では、ポリシーは次のように要約されます。プロジェクトマネージャーとして、あなたは次のことを確認します。
a）これとこのアプリケーションを実装する必要がありますが、私たちはしぶしぶ良い関係の名の下にそれを行います。 しかし、私たちに親切にしてください。 （この場所では、理論的には優れたアナリストにlyuleyを掛けます）
b）このアプリケーションは解決する必要がありますが、実装するリソースがないため、これらのリソースと時間を解放するために、重要ではない機能から何をスローできるかを決定しましょう
c）この問題は、このプロジェクトの枠組み内では解決できません。 したがって、システムを完成させるための資金調達を計画します。
無理をしないようにしてください。 どんな状況でも妥協する必要があります。 顧客が仕事とあなたに満足しているが、予算内に収まるように、少し心理学者であることが要求されます。
はい、過去に戻ります。 TKの最初のバージョンを思い出してください。TKがあれば、赤面の脂肪爆弾で屠殺されました。 この場合、設計/開発を開始する際に、やり直しが必要なことについて引き続き検討することをお勧めします。 時間を節約できる場合もあれば、そうでない場合もあります。 しかし、リスクは軽減されます。
4.実装
新しく開発されたソリューションの実装フェーズは、一定期間のソリューションの展開、トレーニング、およびユーザーサポートで構成されます。
展開する前に、高品質のドキュメントを作成するように注意してください。契約を締結する際には、それも必要です。 wikiのある種の自動ジェネレーターを使用することをお勧めします。 Wikiはゲストごとに記入するだけです。 長期の仕事では、持っている必要があります。 最大限に、フルタイムのシステム管理者を使用してみてください。そうすれば、後で手間を省くことができます。 テストサイトのリソースの割り当てをすぐに要求します。
トレーニング。 事前にトレーニング通知メールとユーザードキュメントを送信します。 手紙は、施設、技術機器の要件を示さなければなりません。 作業スケジュール（TK）では、包括的なトレーニングに1日のみが割り当てられていることを示しています。 これは、デモンストレーションの絶え間ないリクエストで悪党を強姦することを許可しません。 これの少し前に、興味のある従業員のために非公式のショーを開催します。そうすることで、トレーニング中に何らかの方法でインストラクターを助け、生徒のinりや希望を制限しようとします（関心のある従業員の忠誠心を獲得できる場合）。
ユーザーサポートには、原則として、一定の主要な機能はありません（または、まだ気づいていません）。
そして最後に。 あなたは巨大な官僚機構で働いていることを忘れないでください。 このマシンで快適に作業するには、裁判所でプロジェクトを終了する機会があるため、大量のドキュメントが必要です。 危険を減らすために、この機械の周りに紙を積み重ねてください。
そして、あなたがその市民であるので、 人々であり 、それが本当にあなたの状態に役立つように製品を作ります。