Tôi sẽ chia sẻ 2 case study mà tôi học hỏi được nhiều nhất. Trong case study này có rất nhiều thách thức, rất nhiều khó khăn mà tôi hy vọng là sau khi nghe những case study này thì mọi người có thể rút ra được những bài học cho riêng mình. Rất hy vọng sẽ mang lại nhiều giá trị cho mọi người.
Ngành ngân hàng là ngành rất đặc thù, và đặc biệt là mình được tiếp cận với một ngân hàng có yếu tố nhà nước vì thế có rất nhiều khó khăn, ràng buộc khi triển khai Agile vào dự án. Trong phần trình bày của anh Đới mọi người cũng đã thấy là ngành ngân hàng là ngành đi sau về chuyển đổi Agile, có rất nhiều rào cản. Trong bài trình bày này mọi người sẽ thấy những câu chuyện rất là đời thường, gần gũi.
Đây là dự án phát triển hệ thống quản lý cho đội ngũ sale bảo hiểm của ngân hàng. Đặc thù của ngành bảo hiểm sẽ có hai loại. Thứ nhất là hệ thống kênh Banca là kênh mà đối tượng là nhân viên ngân hàng bán trực tiếp cho khách hàng đang giao dịch tại ngân hàng, thứ hai là hệ thống kênh Agency gồm các cộng tác viên bán bảo hiểm trên 64 tỉnh thành khắp cả nước. Riêng ngân hàng này thì đội ngũ cộng tác viên khoảng 20 nghìn người. Thời điểm mà mình tiếp nhận dự án thì tình trạng rất là khủng khiếp, ở thời điểm đấy thì mọi thứ đều ngổn ngang.
Có đến 50% tính năng sản phẩm không fit với nhu cầu kinh doanh, nguyên nhân là do team làm sản phẩm bị trượt deadline, mà thông thường các chiến dịch bán hàng thường rất là ngắn chỉ khoảng từ 1-2 tháng, khi ra chậm sản phẩm sẽ không đáp ứng được nhu cầu của bên kinh doanh.
Team này rất lớn, gồm 40 người chia làm 4 team nhỏ. Nhưng câu chuyện này là câu chuyện trong ngân hàng, một team làm sản phẩm công nghệ trong ngân hàng gặp rất nhiều khó khăn khi phải cộng tác liên phòng ban. Team dự án trực thuộc khối IT, phải đáp ứng nhu cầu cho hai khối kinh doanh là Banca và Agency. Trong khối IT ngoài team phát triển còn rất nhiều phòng ban khác bên Core Banking, IT Digital … Team phát triển là team outsourcing ở ngoài vì thế họ không thể cộng tác được với các phòng ban khác trong khối IT ngân hàng. Đặc biệt là khi tích hợp với hệ thống Core gặp lỗi rất nhiều do đặc thù phần Core phải bảo mật. Hay là khi có vấn đề phải cộng tác với các phòng ban khác thì không biết phải gặp ai, tìm ai để xử lý. Có khi là mất từ 1 tuần đến cả tháng cho một vấn đề rất nhỏ, đối với mình thì là vấn đề quan trọng nhưng đối với người ta thì không, người ta thích thì trả lời, không thích thì không trả lời.
Mô hình team dự án phát triển hệ thống quản lý cho đội ngũ sale bảo hiểm của Ngân hàng
Thực ra thì nhìn theo góc nhìn lạc quan thì có một điểm rất là tốt, ở tình trạng như thế này thì team rất là dễ thay đổi, mình không cần phải dùng quá nhiều kỹ thuật để đưa Agile và các kỹ thuật mới vào, mọi người rất sẵn sàng để thay đổi vì tình trạng hiện tại rất là tồi tệ rồi.
Việc đầu tiên mình làm là mình sẽ khám phá xem vấn đề của team ở đâu. Bởi vì là nếu chúng ta không giải quyết đúng vấn đề, chúng ta cứ đi giải quyết vấn đề bề mặt thì không bao giờ hết được.
Mình phải sang ngồi trực tiếp bên ngân hàng đó, mình ngồi và mình vẽ lại toàn bộ các stakeholder của dự án. Ngoài khối kinh doanh là Banca, Agency thì còn rất nhiều bên khác thuộc khối IT mà mình phải làm việc cùng. Riêng bên IT đã có rất nhiều phòng ban như BA, Dev Core, IT Digital, nguyên phần bên phải mình bắt buộc phải cộng tác thì công việc mới trôi được. Phải nắm được đầu mối là ai để khi có vấn đề mình có thể tìm người để xử lý được. Vậy việc đầu tiên là vẽ ra sơ đồ.
Việc thứ hai là sắp xếp lại độ ưu tiên của các stakeholder. Thông thường chúng ta chỉ quan tâm đến các stakeholder chính thôi là những người quyết định chính đến việc dự án thành công hay thất bại. Ví dụ như sponsor, banca, agency chắc chắn là khách hàng của mình rồi.
Nhưng mà ngoài ra còn có các stakeholder khác rất quan trọng ví dụ đội rất quan tâm đến dự án, họ được thụ hưởng từ dự án như đội vận hành (OP), hay đội IT Governance hỗ trợ mình về mặt nguồn lực, thì những đội ấy mình có thể nhờ họ hỗ trợ được rất dễ dàng. Việc của mình là phải thông tin thường xuyên cho họ.
Còn một đội khác cực kỳ quan trọng là đội không quan tâm đến dự án của mình, nhưng lại có sức mạnh ra quyết định, mình không chuyển giao dự án được nếu như không được đội này thông qua. Đặc biệt trong ngân hàng có hội đồng gọi là hội đồng CAB họ sẽ phê duyệt tất cả những yêu cầu golive sản phẩm, tức là phải trình qua hội đồng CAB, hội đồng thông qua mới được golive sản phẩm. Hội đồng này cực kỳ bá đạo, có thể từ chối một cách rất cảm tính, không cần lý do. Mình đã có những phiên phải bảo vệ trước hội đồng CAB suốt 3 tiếng đồng hồ, còn hơn cả bảo vệ luận văn tốt nghiệp. Ngoài ra có một phòng gọi là phòng An ninh thông tin (ANTT), bất cứ khi nào golive đội ANTT sẽ quét lỗi bảo mật, và cứ ra bất kỳ lỗi bảo mật nào thì sẽ mất thêm ít nhất 1 tuần để sửa và quét lại. Có rất nhiều lần ANTT quét mà lần này ra lỗi này, lần sau quét lại ra lỗi khác, họ quét rất nhiều kiểu, họ chẳng quan tâm đến dự án, cứ đúng quy trình quy định họ làm. Và mình thì bắt buộc phải tuân theo vì đây là quy định trong ngân hàng. Hay là đội Core Banking, tất cả những cái liên quan đến Core là đội phát triển người ta không nắm được, nhưng khi tích hợp vào có lỗi thì đội phát triển phải chịu trách nhiệm, phải phân tích đúng nguyên nhân của Core thì họ mới sửa. Hay là đội IT infrastructure là đội xây dựng hạ tầng ở dưới, mình muốn golive thì phải thông qua đội này. Những đội này là những đội mà bắt buộc mình phải làm hài lòng họ, nếu như mình không làm hài lòng họ thì chắc chắn là mình không golive và đưa sản phẩm lên được. Gặp tình trạng như vậy nên cái team làm sản phẩm này mỗi một lần golive thường mất từ 2-3 tháng, và nếu fail thì phải mất từ 4-5 tháng. Trong 4 tháng đầu tiên năm 2022 không golive được 1 lần nào cả, 40 người trong 4 tháng không ra được phần tăng trưởng nào cả. Đến mức mà sponsor lúc đó phải nhảy dựng lên rồi, nếu không golive được nữa thì sẽ giải tán dự án. Nó rất là căng thẳng, team rất stress, mọi vấn đề đều đổ lên đầu team mà team lại không biết tìm ai để giải quyết. Thực ra đây là câu chuyện rất hay gặp trong ngành ngân hàng.
Thế thì câu chuyện là mình phải quản lý stakeholder thật tốt, mình phải định nghĩa được các stakeholder của mình, người nào mình cần chăm sóc, người nào mình cần làm hài lòng, người nào mình cần thông tin, đấy là điều rất quan trọng.
Bảng biểu quản lý các Stakeholder
Và đây là điều cốt lõi giải quyết được đề, đó là form lại cái đội có thể gọi là Scrum of Scrum, có thể gọi là SWAT tên gì cũng được nhưng là cái đội mà bao gồm những người có thể giải quyết được vấn đề cho team, giải quyết được khó khăn cho team mà nằm ngoài khả năng của team. Trong đội này gom lại, mình nhờ quyền lực của người sponsor gom lại thì bao gồm Product Owner của banca, PO của Agency, BA Core, SA là kiến trúc hệ thống, Dev Core. Thực ra khi phân tích thì có một số nguyên nhân như sau. Thứ nhất là việc tích hợp với Core gặp lỗi nhiều, thì cần có một người đại diện về nghiệp vụ, một người đại diện về kỹ thuật của Core để cùng xử lý. Thứ hai là về mặt yêu cầu kinh doanh thì có PO của 2 kênh Banca, Agency sẽ hỗ trợ. Thứ ba là cần một SA kiến trúc về mặt hệ thống, vì trước đây team cứ làm vô tội vạ chả có kiến trúc gì cả, team trước khi thực hiện thì thông qua SA để chốt giải pháp. Chỉ cần đội như vậy thôi thì gần như các vấn đề đều được giải quyết, kết quả là 8 tháng cuối năm giải quyết được toàn bộ công việc của năm 2022. Mọi người hay nói về Scrum, người Scrum Master làm gì ạ? Giải quyết khó khăn và bảo vệ team đúng không? Nghe thì dễ nhưng đến lúc thực tế như thế nào thì phải trải nghiệm thực tế mới biết được, đặc biệt trong ngân hàng trải nghiệm rất là rõ, bảo vệ team làm sao để team yên tâm làm việc, mắng chỉ mắng đến mình thôi, và thứ hai là giải quyết tất cả mọi khó khăn của team thì team mới chạy được.
Bước thứ 2 là làm đúng việc, thì từ trước đến nay về cơ bản là team chỉ nhận yêu cầu một chiều, và khi nhận yêu cầu thì đội ra yêu cầu chỉ ra một lần thôi, không có tương tác gì cả dẫn đến là hầu hết thì sản phẩm mang ra không sử dụng được.
Câu chuyện ở đây là phải xây dựng Roadmap với đội kinh doanh, xuất phát từ OKR của từng khối từ đó bẻ ra các chiến dịch kinh doanh theo từng tháng và có độ ưu tiên để đảm bảo mình không làm dàn trải, mình tập trung nguồn lực vào các OKR chính, cái nào mà không phục vụ cho OKR thì mình gạt hết. Làm phải có mục tiêu, phải có ưu tiên và chúng ta thống nhất OKR này là quan trọng thì cứ tập trung vào OKR mà làm, không liên quan thì bỏ qua, thế là lúc bấy giờ mình có quyền mình gạt đi. Còn trước đây là bảo gì làm nấy, làm rất nhiều và lỗi rất nhiều.
Kết quả
Bài học rút ra
Thực ra mỗi ngành có đặc thù riêng, ngành ngân hàng thì stakeholder rất phức tạp, còn ngành phần mềm thì stakeholder đơn giản hơn, nhưng sẽ thiên về kỹ thuật . Qua đây mình sẽ giới thiệu cho mọi người một số kỹ thuật, để mọi người có thể quản lý dự án tốt hơn với vai trò Scrum Master
Dự án này là dự án làm với khách hàng Nhật Bản, họ có một website đã sử dụng 30 năm rồi, và đến thời điểm hiện tại họ không thể phát triển thêm tính năng vì không có tài liệu mô tả, cũng như ngôn ngữ sử dụng đã quá cũ rồi không còn hỗ trợ nữa. Yêu cầu của khách hàng rất đơn giản là họ muốn làm lại website giống với website cũ nhưng bằng ngôn ngữ mới để có thể phát triển thêm tính năng, không có tài liệu gì cả muốn biết thì lên website tự tìm hiểu. Sợ nhất là những yêu cầu chỉ có 1 dòng như thế này. Team này ban đầu không có người, thường nỗi đau của đội ITO là về nguồn lực, nguồn lực vừa thiếu lại vừa yếu. Và team này cũng không ngoại lệ, dự án bắt đầu chậm 2 tuần do không có người, tức là từ 9 tuần rút xuống còn 7 tuần để hoàn thành. Dự án này là dự án hạn chót cố định rất thách thức, thường chúng ta nói chuyện áp dụng Agile cho các dự án không có hạn chốt cố định nhưng đây là một case study áp dụng cho dự án hạn chót cố định, mọi người sẽ thấy nó hơi khác.
Cơ bản vì yêu cầu không rõ ràng nên là kết hợp hai phương pháp Waterfall và Agile, Waterfall ở thời điểm đầu để làm rõ yêu cầu. Có một bạn ngồi với khách hàng ở thời điểm đầu, vẽ ra 40 cái màn hình để xác nhận với khách hàng, không cần một yêu cầu chi tiết nhưng ít nhất là phải có danh sách các màn hình sau đó mới bắt đầu thực hiện theo Agile.
Phương pháp kết hợp mô hình Agile và Waterfall
Khi thực hiện chia thành các phân đoạn, và mỗi phân đoạn thực hiện theo đúng mô hình Lean Startup bao gồm: xây dựng, đo đạc xong rồi cải tiến. Độ dài sprint 1 tuần, mỗi tuần đều thực hiện xây dựng, đo đạc và cải tiến.
Đầu tiên là xây dựng product backlog, sử dụng Jira để quản lý product backlog, sắp xếp độ ưu tiên theo từng màn hình.
Team này có điểm đặc biệt là sử dụng bảng vật lý để làm sprint backlog, bảng vật lý rất là hay trong việc trực quan công việc, tiến độ công việc ai cũng nhìn thấy được, sếp đi qua cũng nhìn thấy và vô hình chung trở thành áp lực để team cải tiến. Bảng công việc bao gồm bảng Kanban và biểu đồ burndown rất quan trọng, và các action retrospective để team có thể tiện thực hiện theo.
Đây là 2 burndown của sprint 3 và sprint 5. Burndown sprint 3 rất chậm nhưng đến sprint 5 thì khối lượng công việc gấp rưỡi sprint 3, nhưng team vẫn bám sát được kế hoạch. Bởi vì công việc bị dồn về cuối do những sprint đầu team không hoàn thành, mà deadline đã fix rồi, nên các sprint sau khối lượng công việc bị dồn lại. Câu chuyện ở đây là đương nhiên ban đầu team sẽ làm chậm, do team phải mất công tìm hiểu, mất công học và nghiên cứu nhưng khi làm Agile đúng thì không phải là mình áp dụng quy trình Scrum hay Kanban mà phải xem là sprint sau tốc độ có nhanh hơn sprint trước hay không, nó có tốt hay không có phải cải tiến gì không.
Năng suất của team tăng lên theo thời gian do team thực hiện việc cải tiến rất là tốt. Đây có đưa ra một số hoạt động cải tiến, ban đầu thì team chưa thống nhất được hết về mặt quy trình cách làm nhưng càng về sau team càng ăn ý với nhau, thống nhất được cách phát triển như nào, review như nào, thực hiện ra sao qua từng sprint.
Và đây là kết quả năng suất đo bằng function point, sprint 5 có năng suất gấp đôi so với năng suất trung bình ở sprint 1 và 2. Năng suất tăng rất nhanh và ổn định
Đúng theo mô hình Tuckman, team trải qua các giai đoạn hình thành, sóng gió, ổn định, hiệu suất cao. Ở sprint 1 hình thành, sprint 2,3 sóng gió có một bạn phải ra đi và có hai bạn mới vào, team bất ổn vì thay đổi nhân sự. Team đạt độ ổn định ở sprint 4, và hiệu suất cao ở sprint 5, 6. Năng suất team tăng ổn định, và đây là dấu hiệu cho thấy đang áp dụng Agile đúng, để đánh giá cần nhìn vào kết quả cuối chuyển giao cho khách hàng.
Hiệu quả làm việc khi triển khai Agile trong dự án theo mô hình Tuckman
Chất lượng thì rất ổn, tất cả các chỉ số chất lượng đều đảm bảo. Trước đây waterfall thì mình chuyển giao một lần thôi, nhưng làm Agile thì mình chuyển giao sản phẩm sớm cho khách hàng, từ đó khách hàng có thể phản hồi sớm và điều này khiến khách hàng rất hài lòng. Khách hàng trả về 6 lỗi thôi, ngoài ra có 23 CR (change request – yêu cầu sửa đổi) và họ rất sẵn sàng trả thêm tiền để làm các CR này.
Và đây là chỉ số rất quan trọng trong ngành ITO, đây là chỉ số quản lý nguồn lực Effort Efficiency. Với ngành ITO thì chỉ số EE trên 90% thì chứng tỏ là quản lý nguồn lực tốt, dự án này tuy là bắt đầu chậm 2 tuần chỉ có 7 tuần để thực hiện công việc của 9 tuần nhưng chỉ số nguồn lực đạt 99%
Một số bài học rút ra, đó là mọi người có thể kết hợp nhiều phương pháp không nhất định chỉ có Scrum, Kanban. Có thể giai đoạn đầu làm Waterfall, giai đoạn sau làm Scrum. Ngoài ra có một số bài học như:
Tác giả: Nguyễn Minh Phúc – Trưởng phòng Giảng huấn, Học viện Agile
Bài viết liên quan:
