Привет！
我叫 Alexander，負責 UBRD 的 IT 開發！
2017 年，UBRD 資訊科技服務開發中心的我們意識到全球變革，或者更確切地說，敏捷轉型的時機已經到來。 在業務發展密集、金融市場競爭迅速加劇的情況下，兩年是個令人印象深刻的時期。 因此，是時候對這個項目進行總結了。
最困難的事情是改變你的思維，逐漸改變組織中的文化，人們普遍認為：“誰會成為這個團隊的老闆？”，“老闆更知道我們需要做什麼”，“我們已經在這裡工作了10年，更了解我們的客戶。”，我們知道他們需要什麼。”
敏捷轉型只有當人本身改變時才能發生。
我想強調以下阻礙人們改變的主要恐懼：
- 害怕失去權力和「肩章」；
- 害怕成為公司不必要的人。
走上轉型之路，我們選出了第一批「老兔子」——零售部門的員工。 第一步是重新設計低效率的 IT 結構。 提出了結構的目標概念後，我們開始組成開發團隊。
溫和地說，我們銀行的建築和許多其他銀行的建築一樣，都是「垃圾」。 大量的應用程式和元件透過DB連結單片互連，有ESB匯流排，但它沒有達到其預期目的。 還有一些ABS。
在組建 Scrum 團隊之前，出現了這樣的問題：“團隊應該圍繞什麼組成？” 當然，罐頭裡有產品的想法已經存在，但只是遙不可及。 經過深思熟慮，我們決定團隊應該圍繞一個方向或部分聚集。 例如，開發貸款的“Team Credits”。 在做出這項決定後，我們開始製定目標角色構成以及該領域有效發展所需的一系列能力。 和許多其他公司一樣，我們考慮了 Scrum Master 以外的所有角色——當時幾乎不可能向 CIO 解釋這個出色的人的角色是什麼。
因此，在解釋了組建開發團隊的必要性後，我們組建了三個團隊：
- 貸款
- 卡
- 被動操作
具有一組角色：
- 開發經理（技術主管）
- 開發人員
- 分析師
- 測試員
下一步是確定團隊如何工作。 我們對所有團隊成員進行了敏捷培訓，讓每個人都坐在一個房間裡。 團隊中沒有 PO。 大概做過敏捷轉型的人都明白，向業務解釋一個PO的角色是多麼困難，讓他坐在團隊旁邊，給他權力就更難了。 但我們用我們所擁有的「步入」這些變化。
由於貸款流程和零售業務的其餘部分涉及如此多的應用程序，我們開始思考，誰可能最適合這些角色？ 一個技術堆疊的開發人員，然後您會發現 - 您需要另一種技術堆疊的開發人員！ 現在你已經找到了需要的人，但是員工的願望也是一個重要的事情，強迫一個人在他不喜歡的地方工作是相當困難的。
經過貸款業務流程的工作分析以及與同事的長時間交談，我們終於找到了一個中間立場！ 三個開發團隊就這樣出現了。
接下來是什麼？
人們開始分為想要改變的人和不想改變的人。 每個人都習慣在「他們給我一個問題，我做到了，別管我」的條件下工作，但團隊合作並不意味著這一點。 但我們也解決了這個問題。 總共 8 人中有 150 人在變革期間退出了！
然後有趣的事情開始了。 我們的跨組件團隊開始自我發展。 例如，有一項任務需要您具備 CRM 開發人員領域的技能。 他在團隊中，但他是孤獨的。 還有一位 Oracle 開發人員。 如果您需要解決 CRM 中的 2 或 3 個任務該怎麼辦？ 互相教導！ 這些人開始互相轉移他們的能力，團隊擴大了能力，最大限度地減少了對一位強大專家的依賴（順便說一句，在任何公司中都有知道一切並且不告訴任何人的超人）。
如今，我們已經組建了 13 個開發團隊，負責業務和服務開發的各個領域。 我們繼續敏捷轉型並達到新的水平。 這將需要新的改變。 我們將重新設計團隊和架構，並發展能力。
我們的最終目標：快速回應產品變化，快速為市場帶來新功能，提升銀行服務！
來源： www.habr.com