少し前[約1年-長い時間を経て「テーブルの上に」という記事がありました）私たちは友人と座って、IT会社を組織する問題について考えました。 私たちは本当に大規模なIT会社では働いていませんでした;私たちの人生はすべて、ITがビジネスの主なタイプではない組織のIT部門で過ごしました。 したがって、組織構造については考えていますが、ソフトウェアの実装と保守を主な目的とする規模の大きなオフィスへの適用の詳細には精通していません。
2時間の反省の末に判明しました。この写真のようなものがあります。その主な規定はカットの下で説明されています。
はじめに
そのため、非常に大規模なITプロジェクトを実施し、全国に展開し、それらをサポートするために多くの時間を費やす組織があります。 また、入門書から、会計は外部委託されていると想定しています。
また、このデータを処理するための大規模なデータベースとシステムのサポートの詳細に言及することは理にかなっています。サポートが必要ないくつかの実用的なソリューションが既にあります。
まず、組織がすべきことを書き留めます。
- 技術要件のリストに従って技術仕様を作成し、それらを顧客と調整します。
- 本格的な技術文書の作成（プロジェクトのその後のサポートに焦点を当てているため）;
- 方法論的および数学的サポートの研究;
- ソリューションアーキテクチャの開発。
- ソフトウェア作成;
- テスト;
- 実装;
- 護衛。
構造説明
実際には、各アイテムは部門ですが、いくつかのアイテムはまとめるのが理にかなっています。 たとえば、最終テストを技術文書と組み合わせ、実装をメンテナンスと組み合わせることは理にかなっています。
この関連付けにはいくつかの理由があります。
- テスト部門および技術文書の場合：
- 統合テストでは、実際にプログラムが仕様に準拠しているかどうかを確認します。 技術設計;
- 適切に定義された最終テスト手法により、実際のエラーだけでなく論理エラーも明らかになります。つまり、プログラムがクラッシュしないが、設計された結果とは異なる場合です。
- 書かれたソフトウェアはブラックボックスのように見え、内部から抽象化することができます。
- 実装およびサポート部門の場合：
- 実装と保守が「1本のボトル」であるため、技術サポートの代表者と顧客の代表者の間で連絡が確立されています。
- 「ゼロ実装」はテスターのサイトで実行されます。これにより、さまざまなインストールシナリオを実行し、自宅で戦闘経験を積むことができます。
このようなスキームには別の理由があり、これについては以下で説明します。
開発では、すべてがよりシンプルになります。システムおよびアプリケーションソフトウェアを開発する部門、Webテクノロジーの部門、およびデータベースを扱う部門が割り当てられます（データベースの作業量が多いため）。
委任事項の開発と契約の締結に関しては、これらは「顧客に同意し、請負業者にタスクを割り当て、すべてがスケジュール通りであることを保証する」タスクでプロジェクト単位で作業する典型的なマネージャーです。 ディレクターは、おそらく報告期間ごとにオフィスでこれらのワシを楽しみにし、彼の代理に彼らを解散させる機会を決して委ねません。
完全に明確ではないいくつかのポイントがあります。 これは、数学的ソフトウェアとソフトウェアアーキテクチャの開発に関する研究です。
ソフトウェア部門のタスクは、メソッドを策定し、数式を作成し、顧客のビジネスプロセスの方法論を作成することです。 トピックに完全に精通した専門家の一種であり、概念的な問題について決定を下す準備ができています。
ただし、ソフトウェア設計部門は、むしろ製品の概念的な整合性に取り組み、開発部門の骨組みを提供する必要があります。 プロジェクトオフィスはマネージャーが座っている場所であり、ソフトウェア設計部門はチームリーダーが座っている場所です。
両方のタスクは、実動にも運用活動にも関係しません。 むしろ、これらは将来を楽しみ、最適なソリューションを収集し、それらを実践し、開発を管理する研究部門です。
したがって、開発、開発、技術サポートという3つのブランチがあります。 各プロジェクトは、プロジェクトオフィスでの開始段階、開発部門での概念化、運用部門での技術文書の作成、開発を経て、実装のためにサポート部門に戻されます。
このようなプロジェクトパスにより、理論的には、組織の概念的な欠陥や事実上のエラーを顧客に届けることなく特定できます。
ここでは、少し余談する必要があります。
これをすぐに自動化しましょう！
2007年には、「それらを良くする」ための完全に非公式なタスクが受け取られました。 誰がどのように「うまくやる」かを正確に見つけた後、すべてが書かれた健全な文書が生まれました。 率直に言って、文書を承認する方法は厄介で曲がりくねっており、すべての利益を考慮に入れました。 今、私がこれをすべて書いたら、1Cでなければ、似たようなものになっていたことを理解しています。 それは私には全く自明ではありませんでした。 「オーケー」と思いました、「でたらめ、私たちのものは消えませんでした！..」-職場で座った。 4か月後、いくつかのプロトタイプの準備が整い、私はそれを取りに行きました。
すべてが間違っていたことがわかりました。不便で、間違っています。ここでビジネスプロセスが変更されました...まあ、一般に、誰もがこの状況を想像できると思います。 不機嫌になって、私は再び仕事に座った。
数回の反復の後（および規則の作成と概念の変更に気を取られた後）、プログラムは受け入れられ、数か月後に導入され、戦闘の義務を引き受けました。 その時までに、組織の内部構造の変更、優先度の変更などにより、オリジナルの書面TKの75％が関連性を失いました。 しかし、これは実際には問題ではありません。 問題は、ソフトウェアの記述速度を追求するために、これらすべての変更が文書化されていないことです。 したがって、現在（はい、まだ動作しますが、驚くべきことです）、ソフトウェアに同行できるのは1人、つまりIです。 また、護衛の同意がないため、ドキュメント（およびイルカのソフトウェア自体）を書く理由はありません。 その結果、年に一度彼らは私に電話し、私は一週間以下の期間のためにいくつかのささいなことを修正し、別の年の間このソフトウェアを忘れています。
そのようなサポートを他の場所に移すことは基本的に不可能です。 そして、この話をきっかけに、技術プロジェクトとソフトウェアの作成の間、およびソフトウェアの作成とその実装の間で責任を共有するためのスキームを提案しました。
組織構造に戻る
したがって、理想的な構造では、前の段落で説明したエラーと同様の潜在的なエラーを、テクニカルライターからドキュメントを転送するときとソフトウェアを実装者に転送するときに2回フィルタリングする必要があります。 期限に間に合わない場合は、各部門の責任者とプロジェクトマネージャーによるレビューの対象となります。 これらは、プロジェクトが依存する明確なマイルストーンです。 さらに、マイルストーンの両側のプロセスは異なる部門によって制御され、責任の曖昧さや「仮釈放」の移転を回避します。
生産部分です。 ファイナンシャルディレクター、AHOの部門、弁護士、およびheycharnyuを追加する必要があり、IT会社の組織構造は準備ができています。
プロジェクトチームの構成について
スタッフは、「マネージャーの密接な監督の下で、ソフトウェアグループの方法論者の支援を受けて、ソフトウェア設計部門のタフなスペシャリストが率いる開発部門の代表者が、顧客を熱心に満足させています」。 そのため、このアプローチでは、「古典的な」ウォーターフォールだけでなく、マネージャーが製品所有者として行動する柔軟なテクノロジーも使用できます。 唯一のことは、技術文書部門からのフィードバックにわずかなオーバーヘッドが必要なことです。これにより、プロセスの速度が大幅に低下することはありません。
統一と対立の闘争
開発、開発、およびサポートの責任分担と同様に、描かれた組織でのプロジェクトの経路に基づいて、これらの部門の長の個人的な資質について興味深い結果が得られます。
- 副 開発ディレクター-鋭く、幅広い考えを持ち、常に新しい知識、新しい技術を求めています。 彼の部門はほとんど常にネットマイナスで働いていますが、彼で生まれたアイデアは他の部門に食べ物を与え、会社を前進させます。 確信した楽観主義者。
- 副 オペレーションディレクター-慎重に経験を積んだ従業員で、3歩先を行くすべてを見るため、悲観主義者ですが、ほとんどの場合は逆行者と呼ばれます。 彼の部門は安定した、しかし小さな収入をもたらし、彼はイノベーターの新しいトレンドのためにすべてが無駄になることを望んでいません。
- 副 プロダクションディレクター-最もバランスのとれた、最初の代理。 それは、革新者と伝統主義者との間のバランスとして機能し、進化論に準拠しています。 彼はほとんどの利益をもたらし、全員にボーナスを、監督に新しいマシンを提供します。
- ファイナンシャルディレクター-収入と支出を考慮し、これがさらに進んだ場合、ディレクターは年次カイエンポルシェを受け取らず、他のすべての人がボーナスを受け取ることをイノベーターに時々思い起こさせます。
おわりに
私は決してマネージャーではないので、このスキームと正当化は「主題に関する」考えの単なる形にすぎないため、他の人にとって非常に役立つかもしれない賢明なコメントと建設的な批判をすることを強くお勧めします。