プロジェクトの役割は次のようになります。
- アナリストは、「より速く作業する必要がある」という精神でビジネスからタスクを聞き、これに必要なものを見つけに行きます。 長い間、彼は自分自身を選んで、たとえば、生産には注文を処理するためのよりシンプルな、またはより透明なプロセスフローが必要であることを学びました。 チームと議論します。 ビジネスが行うことを決定します。 アナリストは、アーキテクトの新しいシステムに要求を投げかけます。 アナリストはどこに行くべきかを知っています。
- アーキテクトは要件を見て、システムを見て、驚いて、何度もやり直します。その後、正確な技術タスクを設定します。 アーキテクトは、何をする必要があるかを見ます。
- デザイナーが一番幸せな人です。 彼はアーキテクトの要件を採用し、システムの詳細設計のレベルまで単純にそれらをラボします。 設計者は、特定の詳細を作成する方法を知っています。
- プロジェクトマネージャーがプロジェクトを引き受け、必要な人、ハードウェア、お金、その他のリソースの数を確認します。 作業計画を作成します。 PMは誰がするか、そしてそれがいくらするかを知っています 。
次に、逆の順序で、プロジェクトが受け入れられます。
また、チーフエンジニア（鉄が多い場所や複雑な作業が必要な場所）や他の人々もここに参加できます。 多くの場合、役割は組み合わされます-たとえば、建築家は設計者であり、分析の一部を担うことができます。 PMは、開発者のチームリーダーになることがあります。 しかし、役割モデルはこのようなものです。
次-最初の3つの役割から必要なものについて私見。
建築家は、奇妙なことに、現実世界と接触する人です。 開発モデルを開発者またはエンジニア→デザイナー→アーキテクト（プロジェクトの一部）→主要なアーキテクトと見なすと、最初は現実の世界が見えなくなり、安全に思えます。 入り口の設計者は、上級建築家の同僚の乾燥した要件を持っています。 このチェーンに沿って成長するにつれて（それが唯一の可能性ではなく、開発が必ずしもそのように進むとは限りません）、チームおよび顧客の他の人々とますますコミュニケーションをとる必要があります。
追加のスキルが必要です。 まず技術的なスキルがあります-たとえば、開発者やエンジニアからデザイナーを選択する場合、大規模なネットワーク、アプリケーショングループの監視を明確に監視し、ネットワーク構成を管理し、ネットワークのインベントリを作成し、ネットワークモデルと制御プロトコルの理論を理解できるようにしたいと考えています。 若い建築家の場合、データ収集スキルだけでなく、その表示も必要です。視覚的に組み立てられたデータの配列を操作し、チームの全員が理解できるスキームを構築できる必要があります。
この場合も、設計者がサービスデスクを管理するスキルや移行変更のスキルを必要とすることはほとんどありません。 そして、アーキテクトにとって、プロセスには3つの段階があるためです。現在はどこにいるのか、来年はどのように生きるのか、プロジェクトの最後にはどこにいるのか。 そして今年は、「建設中」というモットーに負けないことが良いでしょう。
アーキテクトの洗練度が高まるにつれて、標準の知識に対する要件が増加します。 愛情深く穏やかなGOST 34から始めて、個人データと支払いデータを含むGISをすぐに配置するための原則について読むことができます。 そこで、設計方法論。 設計者はプロジェクト管理の理論を知る必要はなく、設計者は人々の働き方を理解する必要があります（少なくとも計画エラーとは何かを理解するレベルで）。 リードアーキテクトは、必要に応じてPM'omになれなければなりませんが、そのような仕事をすることはありません。
そして、非標準で、しばしば過小評価されているものが始まります。 たとえば、通常のIT専門家がプレゼンテーションを行うスキルを必要とするのはなぜですか？ そして、少なくとも基本的なものが必要です。 はじめに-新しいシステムの説明を言葉で始めないでください：
「あなたはすべてここで至福のバカです。」 どうするか見てみましょう。
ちなみに、実際のケース。 最も重要なことは、その人が言葉に答えて、なぜ彼らがそのような人々であるかを証明したことです。 しかし、この開始後のパフォーマーは仕事に熱心ではありませんでした。 実際、プレゼンテーションのスキルはこれには必要ありませんが、チームの他のメンバーにアイデアを説明するために必要です。 誰にとっても非常に時間の節約になる基本的なことがいくつかあります。
理論的には、デザイナーと普通の建築家は、販売について多くを知る必要はありません。 一流-それは必要です、彼はITソリューションを販売するために少なくとも一度はいました。 そのため、彼はビジネスが話す言語を知っているからです。 これは「ナビゲーションシステムのFRRを高めるリスク」ではありませんが、「これを変更しないと、ストリップに完全な死体があります」。 レポートの信頼性と正確性にはわずかな違いがあります。 テクノロジーについて何も明確でない場合に有望な製品を選択するスキルは非常に近いです（自分で選択できる場合、アーキテクトがいくつかのオプションを示したときに顧客が同様の状況にあることがわかります）。
他の人のインフラを監査する能力が必要です。 これは、何が重要で何が重要でないかを理解できるようにすることです。 標準では、だれでもできますが、アプリケーションレベルでより重要であり、インフラストラクチャとプロジェクトの一部の機能（ビジネスに必要なだけ機能した場合）を使用できるようになると、それはもはや重要ではないことを理解しています。
設計ソリューションを選択する際の非常に重要なスキルは、選択を正当化する方法を人が知っているかどうかです。 評価が価格、信頼性、拡張性、およびその他の要因に基づいて行われる場合、これは合理的な設計者です。 そして、アナリストが収集したすべての可能なシナリオを考慮して評価が行われる場合、これがリードアーキテクトです。 なんで？ プロジェクトの依存関係、そのリスク、正確な要件を特定できる必要があるためです。 明らかにすることは、何かが欠けていることを紹介してわかったときではなく、何が起こるかを事前に知って事前に準備したときです。 数年間。 ここで、一流の建築家は彼のより応用された同僚とは異なり、常にそれについて考えています。
一般的に、これは事前に準備し、すべてのオプションを検討することです。おそらく、プロとシステムを設計できる人との最も重要な違いです。 アーキテクトは、考えられる型破りな使用、愚か者からの保護、すべてを考慮し、失敗のポイント、移行プロセスを考えなければなりません。 単純化された例えは次のとおりです。都市戦略をプレイした場合、「10年後」に最適なアーキテクチャが非常に直感に反する場合があることがわかります。 最初に都市を構築し、次にそれをリファクタリングして適切な方法を理解する必要があります。 建築家にはそのような贅沢はありません-建設とリファクタリングが頭に行き、すでに最適化されたモデルが機能します。 アーキテクト-彼はコンセプト、関連システムへの影響、目的、適用性、利点について考えています。
重要なスキルは、技術要件と参照条件の策定です。 また、リスクと変化の評価。 たとえば、50日までプロジェクトでしか作業していなかった場合、評価スキルはおそらく不十分です。 本当に大規模なプロジェクトには、顧客の詳細に関連する独自の特性があり、通常のエラーが大量に蓄積されると、「夕方の30分で終了」することができなくなります。 より正確には、時間は非常に限られたリソースであり、余分な労働時間はどこからともなく現れません。
さまざまなプランの準備-ユニットのプランを用意するだけでは不十分です。リソースプランはまだ準備中です（ユニットとの関係に関係なく）。 これにより、エイリアンユニット全体の計画を管理する必要がなくなります。チームの能力と能力を理解する必要があります。
ドキュメント開発は、あらゆる段階で必要とされる単なる有用なスキルです。 彼はまた、システム思考の面でも非常に規律があります。
作品の分解-PMのスキルではないようですが、実際には建築家の仕事です。 プロジェクトマネージャー自身は、設計されたシステムに十分な能力がないため、これを行うことはできません。彼は単に建築家、デザイナー、エンジニアから情報を収集し、スケジュールを作成し、実行を慎重に監視し、必要に応じてチームを動機付けます。 はい、多くの場合、プロジェクトはそれがどこから来たのかを理解するのに十分な知識がありますが、適切な分解を行うのはアーキテクトです。
ビジネスコミュニケーションスキル-主要なアーキテクトがこれを行う方法を知らない場合、真面目な人は彼と話をしないため、彼はすぐにリーダーになるのをやめます。 喫煙室の真ん中に「お尻」という言葉を付けてシステムに関する意見を述べることと、ヨーロッパの企業の副社長にとって同じことだからです。 さらに、ベンダーと通信するには流な英語が必要です。 肝臓と脳は元の形で保存されます。 例えば、私はしばしば「セールス」が指で空気中の正しいパターンを描くために建築家がどんな種類の会議を必要とするかを知っているプロセスで会います-そして彼らはそれらを顧客に持って行きます。
「普遍的な」スキルのうち、通常は役割を割り当てる際に、労働者の伝記に関する前の人のリーダーのフィードバックが評価されます。 結果に焦点を当てる必要があります。システムを通過させるのではなく、問題を解決するためです。 「すべてがToRに従って行われますが、機能しません」-これは問題の解決策ではありません。
好奇心は非常に重要な基準です。原則として、人が新しい知識を求めて自分自身を学ぶなら、これは彼が生きる理由を考える機会です。 だから彼は気にします（まあ、または彼は会社を変える準備ができています、ジージー）。 建築家は他の誰よりも気にするべきではありません。
時間管理は重要です：デザイナーにとって-短距離スプリントの精神で優先順位を設定する（タスクを受け取る-する-渡す-新しいものを受け取る）が、建築家にとって-タスクの期限、優先順位を決定し、自分ですべてを行う また、時間の不足、資源の不足、周囲のすべてが燃えている状況で意思決定を行う能力もあります。自転車が燃え、松葉杖が燃え、あなたが燃えています。 何かがうまくいかなかった場合の「延長」プロジェクトは、神経が1キロも離れず、睡眠不足になるだけでなく、涼しくなるチャンスでもあります。
このように。 繰り返しますが、これは厳しい私見ですが、経験豊富な同志のいる私の学校は、ほぼこの方向で成長する必要があることを示しました。 そして、プロジェクトの分野で同僚に似たようなことを期待しています。
したがって、私が言ったように、建築家であることは熱心で興味深いものです。 特に、クラウドに基づいて比較的迅速に変更できるインフラストラクチャが登場した近年、特に興味深いものになりました。 たとえば、テクノサーブクラウドでは、ほとんどすべての動きにアーキテクトが必要です-多くの場合、これはインフラストラクチャをクラウドに移行するだけでなく、レガシーや松葉杖から「テール」を切り取り、システムを正しく設計する機会でもあります-それはとにかく変化するからです
急に建築家になりたいが、本当に必要なコースが会社にない場合は、考えてみてください。 多くの能力は、プロジェクト管理や交渉などの基本的なことに関連しています。 これはPM'aまたは「販売」の話ですが、予想外に便利な場合もあります。
これは、Cloud Technoserv Cloud Alexander Shubinのアーキテクトの資料です。 建築家に関する彼の最後の投稿は次のとおりです。彼の作品はどのようなものか。