私の名前はダーシャ・ルスラノワです。アルファ・バンクのデジタル・ソリューション部門のディレクターです。 今日は、非常に大きな変化の中で私たちがどのように生きているか、この再フォーマット中に1年で達成できる結果の速度、およびソリューションアーキテクトが必要な理由を説明します。
ITチームにとって、2018年は組織の変更、プロセス、エンジニアリングカルチャーのビジネスへの浸透という点で大きな課題でした。 そしてもちろん、生産プロセスを拡大し、フロントエンドシステムの開発における競合をめぐる緊張状態を取り除きます。
スピードを上げるために、従業員の雇用とベンダーとの連携に関連するプロセスを再編成するだけでなく、既存のプロセスに重要なイノベーションをもたらす必要がありました：インラインリリーステクノロジー、いわゆるリリーストレイン-価値をモバイルアプリケーションに配信する最大の毎週のプロセス。 現在、20以上のチームが取り組んでいます。 毎週の初めに、リリース候補が自動的に収集され、リリースパイプラインが開始されます。
私たちが求めていたのは、アプリケーションのアセンブリを自動化し、変更の説明をコンパイルする-Gitの開発者が行った変更の「チケット」とjiraのコマンドボードからのユーザーストーリーの説明を組み合わせ、クライアントと利害関係者の完全な透明性を実現することです。 今後の計画では、リリースサイクルが1週間未満になるように、手動受け入れテストを除くすべての段階を自動化する予定です。
ところで、透明性について-「ビジネスパートナー」の実践を積極的に紹介しています。ここでの考え方は、同僚がITで働き、ビジネスの利益を表し、条件付きで互いの利益を尊重することです-50/50 もちろん、これは理想的な状況であり、基準のバランスです。実際には、すべてが少し異なり、どちらか一方がそれを上回りますが、私たちはそれを目指して努力しています。 このような状況では、同僚がチームの適切な充満と同期の両方を監視していることがわかります。 問題解決の質と予算の両方を遵守します。
さらに進んで「生産のリズム」システムを作成しました。これにより、チームの現在のパフォーマンス、評価と実装の段階でのボトルネック、選択と予測ロードのステータス、およびこのすべてをオンラインで確認できます。
数が少ない
2014年から2017年までの期間で、約900のタスクが解決され、1年が終わりました。 2018はすでに940タスクのマークで終了しています。 現在、銀行のプラットフォームで毎月約1,500回の変更を実施しています（つまり、1日に1回約50個の要因が変更されます）。 この速度は、柔軟で進化的なアーキテクチャでのみ可能です。
アルファラボにあったように
2016年には、銀行商品の実装に対して、「ラボ」と従来のITアプローチという2つのアプローチが同時にありました。 Labovskyは、実装の事実に基づいてアーキテクチャを合法化し、多くの場合既に実装の承認を得ています。 このため、Alpha Labのコアではないアプリケーションとこれらすべてを統合するプロセスで問題が発生することがありました。
従来のITは、標準プロセスで作業していました。
- ビジネス要件の準備。
- アーキテクチャの準備と調整。
- 実装。
見た目は良いのですが、要件が変わると、このプロセスは非常に長く非効率的になりました。
したがって、アプローチを組み合わせて、それぞれの長所を活用することにしました。 その結果、ソリューションアーキテクトサービスが登場しました。
これらのスタッフは、銀行で確立された概念に基づいて作業し、チームと事業単位の両方と密接に連絡を取り合っています。 これにより、プロジェクトの開始時に、銀行全体のアーキテクチャと完全な調整と実装の効率性の両方を組み合わせたソリューションを提供できます。 これにより、アーキテクチャとプロジェクトの評価の調整には、古いスキームでは1か月ではなく約1週間かかります。
なぜこれがとても重要なのでしょうか？
テクノロジーレースをキャンセルした人はいません。2年ごとに、市場でテクノロジースタックのかなり重要な更新が行われます。これには、ITマネジメントが常に外部市場と同期する必要があります。 新しいスタックの迅速な導入、新しい専門家のトレーニング、および新しいチームメンバーのオンボーディングを迅速に実行できる必要があります。
そのため、作業とチームの同期の両方をサポートする環境を構築し、可能な限りコンポーネントを再利用しようとしています。 また、これは主にソリューションアーキテクトのメリットです。 レガシーシステムを撤回するための特別な予算がない場合でも、その作業により、この指標に対するチーフアーキテクトの期待を20％上回ることができました。
人と文化
ここでは、チームから絶えず学んでいる主なものに注目します。
結果の認識。 これは重要な部分です。結果はビジネスレベルで認識される必要があります。小さな休日の感覚だけでなく、すべてを正しく行っただけでなく、追加の同期も行われます。関係者は開発チームから特定の何かを期待し、彼女はそれを完全に完了しました。 人々は開発に携わっているため、専門的に開発し、その結果のために特別に働くことが非常に重要です。 そして、あなたが結果を見ただけならこれを行うのは難しく、他の場所ではあまり認識されていません。
高速で解析エラーが発生します。 間違いは、迅速に特定する必要があり、議論する必要があるものです。 ストリームのヘッドレベル、またはビジネスレベル。 装飾なしで、何が起こったのか、誰もがそれについて考えていることを言って、先に進んでください。 もちろん、これに基づいて矛盾が生じることもありますが、1年の間に、私たちはお互いの声からではなく、共通の原因の価値から出発することを学びました。
合計-現在、開発チームとアーキテクト向けに30を超える求人を募集しています。 更新の配信速度に関連するものを含むアルファラボのベストプラクティスを採用し、それらをバンキングITにシームレスに統合して、特定の決定に同意するプロセスで同僚間の競合を無効にしました。
さらに、開発者、デザイナー、テスター向けの会議を引き続き開催しています（ニュースについてはこちらをご覧ください ）。
そして、明後日、 アトラシアンのファンのために 、エカテリンブルクでミーティングを開催します。