Làm thế nào, trong điều kiện kiến ​​trúc rác rưởi và thiếu kỹ năng Scrum, chúng tôi đã tạo ra các nhóm đa thành phần

Hi!

Tên tôi là Alexander và tôi lãnh đạo bộ phận phát triển CNTT tại UBRD!

Vào năm 2017, chúng tôi, trung tâm phát triển dịch vụ công nghệ thông tin tại UBRD, nhận ra rằng đã đến lúc phải thay đổi toàn cầu, hay nói đúng hơn là chuyển đổi linh hoạt. Trong điều kiện phát triển kinh doanh chuyên sâu và tốc độ cạnh tranh nhanh chóng trên thị trường tài chính, hai năm là khoảng thời gian đầy ấn tượng. Vì vậy, đã đến lúc tổng kết dự án.

Điều khó khăn nhất là thay đổi suy nghĩ và dần thay đổi văn hóa trong tổ chức, nơi mà người ta thường nghĩ: “Ai sẽ là ông chủ trong đội này?”, “Sếp biết rõ hơn chúng ta cần làm gì,” “ Chúng tôi đã làm việc ở đây được 10 năm và hiểu rõ khách hàng của mình hơn.” , chúng tôi biết họ cần gì.”

Chuyển đổi linh hoạt chỉ có thể xảy ra khi chính con người thay đổi.
Tôi sẽ nêu bật những nỗi sợ hãi chính sau đây khiến con người không thể thay đổi:

  • Sợ mất điện và “dây đeo vai”;
  • Sợ trở nên không cần thiết đối với công ty.

Bắt tay vào con đường chuyển đổi, chúng tôi đã lựa chọn những “thỏ giàu kinh nghiệm” đầu tiên - nhân viên của bộ phận bán lẻ. Bước đầu tiên là thiết kế lại cấu trúc CNTT kém hiệu quả. Sau khi đưa ra ý tưởng mục tiêu cho cấu trúc, chúng tôi bắt đầu thành lập các nhóm phát triển.

Làm thế nào, trong điều kiện kiến ​​trúc rác rưởi và thiếu kỹ năng Scrum, chúng tôi đã tạo ra các nhóm đa thành phần

Nói một cách nhẹ nhàng, kiến ​​trúc trong ngân hàng của chúng tôi, giống như nhiều ngân hàng khác, là “rác rưởi”. Một số lượng lớn các ứng dụng và thành phần được kết nối nguyên khối với nhau bằng liên kết DB, có bus ESB nhưng nó không hoàn thành mục đích đã định. Ngoài ra còn có một số ABS.

Làm thế nào, trong điều kiện kiến ​​trúc rác rưởi và thiếu kỹ năng Scrum, chúng tôi đã tạo ra các nhóm đa thành phần

Trước khi thành lập các nhóm Scrum, câu hỏi được đặt ra là: “Nhóm nên tập hợp những gì?” Tất nhiên, ý tưởng rằng có một sản phẩm trong lon đã được truyền tải nhưng nằm ngoài tầm với. Sau nhiều suy nghĩ, chúng tôi quyết định rằng nhóm nên tập trung lại theo một hướng hoặc một phân khúc. Ví dụ: “Tín dụng nhóm”, chuyên phát triển hoạt động cho vay. Sau khi quyết định về vấn đề này, chúng tôi bắt đầu đưa ra mục tiêu bao gồm các vai trò và tập hợp các năng lực cần thiết để phát triển hiệu quả lĩnh vực này. Giống như nhiều công ty khác, chúng tôi đã tính đến tất cả các vai trò ngoại trừ Scrum Master - vào thời điểm đó gần như không thể giải thích cho CIO vai trò của người tuyệt vời này là gì.

Kết quả là, sau khi giải thích sự cần thiết phải thành lập các nhóm phát triển, chúng tôi đã thành lập ba nhóm:

  1. Cho vay
  2. Thẻ
  3. Hoạt động thụ động

Với một tập hợp các vai trò:

  1. Giám đốc phát triển (Trưởng nhóm công nghệ)
  2. Nhà phát triển
  3. Chuyên viên phân tích
  4. Kiểm thử

Bước tiếp theo là xác định xem nhóm sẽ làm việc như thế nào. Chúng tôi đã tiến hành đào tạo về tính linh hoạt cho tất cả các thành viên trong nhóm và xếp mọi người vào một phòng. Không có PO nào trong các đội. Có lẽ tất cả những người đã thực hiện chuyển đổi linh hoạt đều hiểu việc giải thích vai trò của PO cho doanh nghiệp khó như thế nào và thậm chí còn khó hơn khi đặt anh ta ngồi cạnh nhóm và trao quyền cho anh ta. Nhưng chúng tôi đã “bước” vào những thay đổi này bằng những gì mình có.

Với rất nhiều ứng dụng liên quan đến quy trình cho vay và phần còn lại của hoạt động kinh doanh bán lẻ, chúng tôi bắt đầu suy nghĩ, ai có thể là người phù hợp với vai trò này? Một nhà phát triển của một nhóm công nghệ, sau đó bạn nhìn - và bạn cần một nhà phát triển của một nhóm công nghệ khác! Và bây giờ bạn đã tìm được những người cần thiết, nhưng mong muốn của nhân viên cũng là một điều quan trọng, và việc ép một người phải làm việc ở nơi mà họ không thích là điều khá khó khăn.

Sau khi phân tích công việc của quy trình kinh doanh cho vay và trò chuyện lâu dài với đồng nghiệp, cuối cùng chúng tôi đã tìm được điểm trung gian! Đây là cách ba nhóm phát triển xuất hiện.

Làm thế nào, trong điều kiện kiến ​​trúc rác rưởi và thiếu kỹ năng Scrum, chúng tôi đã tạo ra các nhóm đa thành phần

Cái gì tiếp theo?

Mọi người bắt đầu chia thành những người muốn thay đổi và những người không. Mọi người đều quen làm việc trong điều kiện “họ giao cho tôi một vấn đề, tôi đã làm được, để tôi yên”, nhưng làm việc nhóm không bao hàm điều này. Nhưng chúng tôi cũng đã giải quyết được vấn đề này. Tổng cộng, 8 trong số 150 người đã bỏ cuộc trong quá trình thay đổi!

Sau đó cuộc vui bắt đầu. Các nhóm đa thành phần của chúng tôi bắt đầu tự phát triển. Ví dụ: có một nhiệm vụ mà bạn cần phải có kỹ năng trong lĩnh vực nhà phát triển CRM. Anh ấy ở trong đội, nhưng anh ấy chỉ có một mình. Ngoài ra còn có một nhà phát triển Oracle. Phải làm gì nếu bạn cần giải quyết 2 hoặc 3 nhiệm vụ trong CRM? Hãy dạy nhau! Các chàng trai bắt đầu chuyển giao năng lực của mình cho nhau và nhóm đã mở rộng khả năng của mình, giảm thiểu sự phụ thuộc vào một chuyên gia mạnh (nhân tiện, ở bất kỳ công ty nào cũng có những siêu nhân biết mọi thứ và không nói cho ai biết).

Hôm nay chúng tôi đã tập hợp được 13 nhóm phát triển cho tất cả các lĩnh vực phát triển kinh doanh và dịch vụ. Chúng tôi tiếp tục chuyển đổi linh hoạt và đạt đến một cấp độ mới. Điều này sẽ yêu cầu những thay đổi mới. Chúng tôi sẽ thiết kế lại đội ngũ và cơ cấu, đồng thời phát triển năng lực.

Mục tiêu cuối cùng của chúng tôi: nhanh chóng đáp ứng những thay đổi của sản phẩm, nhanh chóng đưa các tính năng mới ra thị trường và cải thiện dịch vụ của ngân hàng!

Nguồn: www.habr.com

Thêm một lời nhận xét