ゴミだらけのアーキテクチャとスクラム スキルの欠如の状況で、コンポーネント間のチームをどのように作成したか

Привет!

私の名前はアレクサンダーです。UBRD で IT 開発を指揮しています。

2017 年、UBRD の情報技術サービス開発センターに所属する私たちは、世界的な変化、つまり機敏な変革の時期が来たことを認識しました。 集中的な事業開発と金融市場での競争の急速な成長という状況では、XNUMX 年は印象的な期間です。 したがって、プロジェクトを要約する時期が来ました。

最も難しいのは、考え方を変えて組織の文化を徐々に変えることです。そこでは、「このチームの上司は誰になるだろう?」「上司は私たちが何をすべきかをよく知っている」と考えるのが一般的です。私たちはここで 10 年間働いており、クライアントのことをよく知っています。」、彼らが何を必要としているのかを知っています。

アジャイルな変革は、人々自身が変化する場合にのみ実現できます。
私は、人々が変わることを妨げる主な恐れを以下に挙げたいと思います。

  • 力と「肩章」を失うことへの恐怖。
  • 会社にとって不要になるのではないかという不安。

変革の道を歩み始めた私たちは、最初の「経験豊富なウサギ」、つまり小売部門の従業員を選びました。 最初のステップは、非効率な IT 構造を再設計することでした。 構造の目標コンセプトを考え出し、開発チームを編成し始めました。

ゴミだらけのアーキテクチャとスクラム スキルの欠如の状況で、コンポーネント間のチームをどのように作成したか

私たちの銀行のアーキテクチャは、他の多くの銀行と同様、控えめに言っても「ゴミ」です。 膨大な数のアプリケーションとコンポーネントが DB リンクによってモノリシックに相互接続され、ESB バスがありますが、本来の目的を果たしません。 ABSもいくつかあります。

ゴミだらけのアーキテクチャとスクラム スキルの欠如の状況で、コンポーネント間のチームをどのように作成したか

スクラム チームを結成する前に、「何を中心にチームを編成すべきでしょうか?」という疑問が生じました。 缶の中に製品があるというコンセプトはもちろんありましたが、手の届かないところにありました。 熟考した結果、私たちはチームを方向性またはセグメントに基づいて集める必要があると判断しました。 例えば、レンディングを展開する「チームクレジット」。 これを決定した後、私たちは、この分野の効果的な開発に必要な役割の目標構成と一連の能力を考案し始めました。 他の多くの企業と同様に、私たちはスクラム マスターを除くすべての役割を考慮しました。当時、この素晴らしい人物の役割が何であるかを CIO に説明することはほとんど不可能でした。

その結果、開発チームを立ち上げる必要性を説明した後、次の XNUMX つのチームを立ち上げることになりました。

  1. ローン
  2. カード
  3. パッシブ操作

一連の役割を使用すると、次のようになります。

  1. 開発マネージャー(テックリード)
  2. 開発者
  3. アナリスト
  4. テスター

次のステップは、チームがどのように機能するかを決定することでした。 私たちはチームメンバー全員を対象にアジャイルトレーニングを実施し、全員を同じ部屋に座らせました。 チームにPOはいなかった。 おそらく、アジャイル変革を行った人なら誰でも、PO の役割を企業に説明することがいかに難しいか、そして彼をチームの隣に座らせて権限を与えるのはさらに難しいことを理解しています。 しかし、私たちは持っているものを使ってこれらの変化に「足を踏み入れた」のです。

融資プロセスやその他の小売ビジネスに非常に多くのアプリケーションが関与しているため、私たちは誰がその役割に適しているだろうかと考え始めました。 あるテクノロジー スタックの開発者が、別のテクノロジー スタックの開発者を必要としていることに注目してください。 そして今、あなたは必要とされる人材を見つけましたが、従業員の願望も重要であり、その人に気に入らない場所で働くことを強制することは非常に困難です。

融資ビジネス プロセスの作業を分析し、同僚との長い会話を経て、ついに妥協点を見つけました。 こうしてXNUMXつの開発チームが登場しました。

ゴミだらけのアーキテクチャとスクラム スキルの欠如の状況で、コンポーネント間のチームをどのように作成したか

次は何ですか?

人々は変わりたい人と変わりたくない人に分かれ始めた。 誰もが「問題を与えられた、私がやった、放っておく」という状況で働くことに慣れていますが、チームワークはこれを意味するものではありません。 しかし、私たちはこの問題も解決しました。 合計すると、8 人中 150 人が変更中に辞めました。

それから楽しいことが始まりました。 コンポーネント間のチームが独自に開発を開始しました。 たとえば、CRM開発者の分野でスキルが必要なタスクがあります。 彼はチームの一員ですが、一人です。 Oracleの開発者もいます。 CRM で 2 つまたは 3 つのタスクを解決する必要がある場合はどうすればよいですか? お互いに教え合いましょう! 彼らはお互いに能力を移転し始め、チームは能力を拡大し、XNUMX人の強力な専門家への依存を最小限に抑えました(ちなみに、どの会社にも、すべてを知っていて誰にも話さないスーパーマンがいます)。

現在、私たちはビジネスとサービス開発のあらゆる分野に対応する 13 の開発チームを集めました。 私たちはアジャイルな変革を継続し、新たなレベルに到達します。 これには新たな変更が必要になります。 チームとアーキテクチャを再設計し、コンピテンシーを開発します。

私たちの最終目標は、製品の変更に迅速に対応し、新機能を迅速に市場に投入し、銀行のサービスを向上させることです。

出所: habr.com

コメントを追加します