Clever Geek Handbook

良い建築家の秘密の成分

何がくるのか

オークはドングリから成長します

ごぼうの種から-ごぼうのみ

専門教育-

これらは、私たちがsoく種です...



高度な資格を持つスペシャリストの検索は、ソフトウェア開発に関連するビジネスで最も難しい問題の1つです。 世界経済および国内経済のすべての困難にもかかわらず、有能な人材は非常に不足しています。 高い資格を必要とするプロジェクトの数は、スペシャリストの「成熟」よりはるかに速く成長しています（開発者-2-3年、主任開発者-2年、ソリューションアーキテクト-3-5年...）。



その結果、労働市場で開発者を見つけることは難しく、資格のある建築家を見つけることはほとんど不可能です。 問題は、優れた開発者のトレーニングは簡単な作業ではないという事実によってさらに悪化します。せいぜい、標準プログラムで勉強し、実務経験のないIT学生の半分だけが卒業後に実際のタスクを実行できます。 同時に、これらの学生は原則として2〜3年目から専門分野で働き始めますが、理解することは困難です。彼らは「感謝」または「反対」することを知っており、それができます。 大学で建築家を訓練する能力は、原則として、ヒステリックではないにしても、疑わしいものであり、笑っています。



そのため、2012年5月にMail.Ru Technoparkから大学の建築家をトレーニングするプロジェクト（「バウマンカ」のような大きな名前であっても）に参加するという申し出を受け取ったとき、それを控えめに言って困惑し、興味をそそられました。



このトピックの研究の結果、非常に興味深い結果が得られました。

この問題を解決するために、次のことを行いました。



  1. 問題の一番下に到達しました：

    -大学で建築家を準備することは可能ですか？

    正解は「NO」です

    -大学の研究は開発を加速し、建築家のトレーニングの質を向上させることができますか？

    私たちの答えは「はい」です
  2. コースを作成するためのルールを作成しました。

    a）「素材」の基本的な選択と初期品質を確認します（詳細については、こちらをご覧ください： Mail.Ru Technopark Home ）。

    b）学生がトレーニング外で受ける体験の「効果」を最大化します。 線形の状況では、最初に経験が主な開発者に学生を「連れて行き」、次に別の経験が学生を建築家のレベルに「再教育」させます。 再トレーニングを除外すると、パスを1.5〜2倍短縮できます。 これには、経験を分析し体系化する能力が必要です。

    c）知識ベースを強化するためのトレーニングプラクティスを提供する
  3. 品質を確保するための特定された方法：

    a）経験が過ぎないように、知識の強固な基盤（820時間+マスタークラス）;

    b）ベストプラクティスを直接実践する（すべてのコースは開業医と一緒に設計および実施されます）。




コース「建築家のためのビジネスおよびシステム分析」





このコースの一環として、学生が「問題領域」と「ソリューション領域」をつなげるのを支援するタスクを設定します。つまり、技術スキルだけに基づいて成長した経験豊富なプログラマーにとっては非常に難しい知識を習得します。 その後、この知識により、作成されたソリューションの品質を大幅に改善できます（赤い楕円形）。







「問題領域」の所有に関連する能力には、次のものが含まれます。



  1. 製品およびサービス開発におけるビジネスおよびシステム分析。 この講義は、ソフトウェア開発に基づくさまざまなタイプのビジネスのコンテキストを理解するための基礎を築きます。 システムと複雑さの応用理論を使用して、ソフトウェア開発の分野における主要な問題と推進力のアイデアを紹介します。 複雑な技術ソリューションの作成に基づいたビジネスなどのシステムを含め、複雑なシステムのメカニズムの概念は修正されています。

    （開発速度+2、意思決定の品質+2）
  2. ライフサイクルテクノロジー、ソフトウェアアーキテクチャとの関係。 このレッスンでは、ビジネスと、革新的なプロセスと技術の進化に関連して作成された技術的ソリューションに影響を与える、さらに広いコンテキストを検証します。 破壊的で支援的なテクノロジーの概念であるガートナーの誇大宣伝曲線を探ります。 この知識により、技術の世界の変化とイノベーションプロセスのカオスを意識的に観察し、それを支配する法則を確認することができます。

    （開発の速度に+1、意思決定の品質に+2）
  3. ビジネスモデル。 値ストリーム。 業界全体の発展を決定する外力と法律から、製品と企業の成功を達成するという特定の問題に進みます。 会社のビジネスモデルを伝え、理解する方法を検討します。

    （意思決定の質に+2）

    得られた経験に基づいて、開発サービスモデルのバリューストリームの側面が次のコースに追加されます。
  4. モデリングの使用。 問題の分析。 システム要件に取り組む際のアーキテクトの役割。 製品、プロジェクト、およびアーキテクチャの利害関係者の特定。 利害関係者と協力する。 ユーザーモデリング。

    （開発の速度に+1、意思決定の品質に+3）
  5. 概念モデル、分析パターンの紹介。 このモジュールは、コースの最初の部分を完了します。 オブジェクト指向設計のメカニズムを要約し、研究の主題分野で作業するためのツールの平面に変換します。また、既に得た経験を使用して、独自のソリューションのパターン（テンプレート）を作成します。

    （開発速度+2）












「ソリューションエリア」の所有に関連する能力には、次のものが含まれます。



  1. 品質属性。 高品質の製品とソフトウェアアーキテクチャ機能間の一種の概念的な橋渡し。 このモジュールでは、ソフトウェアアーキテクチャに対する非機能要件の影響、およびソフトウェア品質モデルと品質属性シナリオを調べます。

    （開発の速度に+1、意思決定の品質に+2）
  2. ソフトウェアアーキテクチャの重要な概念。 ビューポイント。 この講義の枠組みの中で、ソフトウェア開発の分野における複雑さのトピックの研究を続けるために、用語ベース、作業ツール、および関係者の観点から作成された製品/ソリューションの整合性を確保する方法を紹介します。

    （開発速度が+2、意思決定の品質が+1）
  3. ソフトウェアアーキテクチャの重要な概念。 見通し。 この講義では、プロセスおよびドキュメントとしてのアーキテクチャの開発について説明します。

    （開発の速度に+1、意思決定の品質に+1）
  4. アーキテクチャを構築するプロセス。 この最終講義では、アーキテクチャの調和と採用のプロセス、非技術専門家へのアーキテクチャの伝達プロセスなど、高品質のアーキテクチャを作成するためのすべての重要な側面をまとめて繰り返すことができます。

    （成功への+2）








練習する



練習は最も困難な側面の1つでした。 「Hello world」またはオンラインストアの別のWebサイトの例を使用して建築家に教えることは、控えめに言っても正しくありません。これは「貨物カルト」に直結します。 比較的短いコース内で製品を作成し、その上でアーキテクチャとそのビジネスコンテキストとの相互作用を感じることも、あまり現実的ではありません。

決定はすぐに熟しました。 医師と同じように、外科医になる前に検死から始まります。そのため、最初に学生はユニークに成功した製品を分析し、製品がその位置を占めるようになる関係を特定する必要があると判断しました。 医師とは異なり、ビジネスおよびシステム分析を成功させるためには、死んだ製品を分析することは完全にオプションであり、生きている製品も適切です。 :-)



コースの一環として、ミニグループの学生は、ビジネスコンテキストとそのパブリックプロダクトのアーキテクチャとの関係を復元することに取り組んでいます。



この学期に、学生は次の製品を選択しました。







理論的な資料のブロックを受け取り、教師をかなり苦しめた男たちは、パズルの一部に取り組み、同僚にそれを提示しています。



その結果、各ミニグループは特定の製品を包括的に理解し、グループ全体として、さまざまな市場の特性と成功したソリューションの「解剖学的アトラス」を理解します。



まとめ



「建築家向けのビジネスおよびシステム分析」コースでは、次のことができます。



  1. 行われたアーキテクチャの決定の品質を向上させ、技術的な卓越性を実際のユーザーの問題とビジネス目標に関連付けます
  2. 現在および将来の作業の枠組みで得られた経験にシステムを導入する
  3. アーキテクチャ分析のスキルを獲得し、分析結果を同僚に伝える
  4. 来年のコースの実施で得られた経験に基づいて、ビジネスのニーズとシステムのユーザーの理解に関連する宿題を生徒がより効率的に完了することができるコースの一部を拡大する予定です。




ベズグリ・ドミトリー

cless75

http://www.facebook.com/dmitry.bezuglyy



コースの準備に使用される文献：



  1. Alexander OsterwalderとYves Pinier Buildingのビジネスモデル。 戦略家と革新者のハンドブック
  2. Dean Leffingwell、Don Widrigソフトウェア要件を扱う原則。 ウィリアムズ統一アプローチ2002 Ch 8-13
  3. クレイグラーマン、UML 2.0とデザインパターンのアプリケーション（第3版）ウィリアムズ2006。
  4. クレイトンM.クリステンセンイノベータージレンマ。 新しいテクノロジーのために新しい企業がどのように死ぬか2012
  5. マーティン・ファウラー、デビッド・ライス、マシュー・フォンメル、エドワード・ハイエット、ロバート・ミー、ランディ・スタッフォード。 エンタープライズアプリケーションテンプレート
  6. マーティンファウラーの分析パターン：再利用可能なオブジェクトモデル
  7. Nick Rozanski、EóinWoods、ソフトウェアシステムアーキテクチャ：ビューポイントとパースペクティブを使用した利害関係者との連携（第2版）2011
  8. www.viewpoints-and-perspectives.info/
  9. L.バス、P。クレメンツ、R。カッツマン実践ソフトウェアアーキテクチャ（NFR）
  10. マーティン・ファウラーUML。 基本。 標準オブジェクトモデリング言語のクイックリファレンス
  11. Alistair Coburnシステムの機能要件を記述するための最新の方法
  12. 患者の手にあるアラン・クーパー精神病院
  13. バーバラミント。 ミントピラミッドの原則思考、ビジネスライティング、スピーキングの黄金律
  14. Michael Rother、John Shook ビジネスプロセスを確認します。 バリューストリームマッピングプラクティス


More articles:


All Articles