Agile hứa hẹn giúp phát triển phần mềm nhanh chóng và mang lại những lợi ích kinh doanh đáng kể. Nhưng nó cũng đòi hỏi mọi người (từ bộ phận CNTT và bộ phận kinh doanh) xây dựng thói quen mới.
Phát triển phần mềm linh hoạt trong phần lớn trường hợp đồng nghĩa với số hóa: các nhà lãnh đạo cấp cao của doanh nghiệp đã nhận ra rằng công ty của họ không thể tận dụng tối đa các công cụ và công nghệ kỹ thuật số nếu không có các quy trình mới, được cải tiến để quản lý các công cụ, công nghệ này. Giá trị của các quy trình này là vô cùng lớn.
Các giám đốc điều hành cấp cao chỉ cần xem xét hai ví dụ gần đây trong ngành ngân hàng để hiểu được những mối đe dọa: ING và Standard Bank của Nam Phi đã kết hợp công nghệ kỹ thuật số và phương thức làm việc Agile vào hoạt động của mình và cả hai đều đang đạt được kết quả tích cực. ING đang phát hành các tính năng phần mềm cho các trang web và web di động của mình trong hai hoặc ba tuần một lần thay vì năm hoặc sáu lần một năm. Kết quả là, chỉ số hài lòng của khách hàng tăng lên đáng kể. Standard Bank đã nâng cao chất lượng của các ứng dụng di động mới bằng cách phát hiện và sửa các lỗi tiềm ẩn sớm hơn trong quy trình phát triển phần mềm—tạo dựng lòng tin tốt hơn với nhân viên và khách hàng trong quy trình.
Một điều có thể ít rõ ràng hơn đối với các giám đốc điều hành cấp cao là vai trò của họ trong việc thúc đẩy các bộ phận kinh doanh và CNTT thoát khỏi hiện trạng và nhận ra những lợi thế của sự thay đổi. Mike Murphy, CTO tại Standard Bank cho biết: “Đây là một trong những thử thách khó khăn nhất. Rất nhiều nhân viên tại ngân hàng cảm thấy thoải mái với cách mọi thứ đã diễn ra. Họ không muốn thay đổi thói quen hàng ngày của mình. Họ chỉ tập trung vào việc hoàn thành công việc”.
Các giám đốc điều hành cấp cao thường có xu hướng cho rằng sau khi họ đặt ra các mục tiêu chuyển đổi số tổng thể, thì việc thực hiện các mục tiêu đó sẽ diễn ra nhanh chóng thông qua một loạt các sáng kiến của bộ phận CNTT. Theo quan điểm của họ, sự linh hoạt chỉ dành cho các kỹ sư R&D và kỹ sư phần mềm. Bộ phận kinh doanh bám chặt vào các phương pháp đã được “chứng minh” là đúng để giao tiếp với bộ phận CNTT—ném các yêu cầu cho đội CNTT và chờ đợi họ xây dựng và chuyển giao thành phẩm. Vì vậy, bộ phận CNTT kết thúc công việc với lượng thông tin rất hạn chế nhận được từ bộ phận kinh doanh, còn bộ phận kinh doanh mất đi cơ hội định hướng phát triển công nghệ hướng đến các mục tiêu mong muốn và tính linh hoạt bị đình trệ.
Phát triển phần mềm linh hoạt không thể chỉ là ưu tiên của bộ phận công nghệ. Các giám đốc điều hành cấp cao cũng phải đưa nó vào agenda của mình, qua đó thể hiện tầm quan trọng của việc tạo ra những thay đổi về văn hóa và công nghệ cần thiết. Sự quan tâm của nhóm lãnh đạo đứng đầu sẽ làm rõ rằng phát triển phần mềm là một quá trình chung. Nó đòi hỏi sự tương tác thường xuyên giữa các nhóm kinh doanh và CNTT, cũng như sự chấp nhận rộng rãi đối với phương pháp thử nghiệm và học hỏi.
Các giám đốc điều hành cấp cao cần tích cực thúc đẩy khái niệm Agile trong các nhóm kinh doanh và công nghệ, đồng thời liên kết trực tiếp các khái niệm đó với kết quả liên quan đến kinh doanh. Nhờ có góc nhìn khác biệt mà Giám đốc công nghệ thông tin (CIO) và các nhà lãnh đạo công nghệ khác— do họ vừa có một chân trong C-suite vừa có một chân trong lĩnh vực công nghệ—có thể giúp các giám đốc điều hành cấp cao thiết lập sáu thói quen làm việc thúc đẩy tinh thần làm chủ của quy trình phát triển phần mềm, cộng tác hàng ngày giữa các bên liên quan trong bộ phận kinh doanh & CNTT và văn hóa học hỏi liên tục.
Trong các cuộc thảo luận tại phòng họp, xưởng sản xuất và mọi nơi khác, các nhà lãnh đạo cấp cao của bộ phận công nghệ và kinh doanh nên nhấn mạnh sáu thói quen sau đây, đây là những thói quen quan trọng để các công ty hiện thực hóa cam kết về sự linh hoạt.
6 thói quen để dẫn dắt Agile dành cho lãnh đạo
Trong một môi trường linh hoạt, một số nhà lãnh đạo bộ phận kinh doanh sẽ được coi như Product Owner – tức là các bên liên quan của bộ phận kinh doanh chịu trách nhiệm chính trong việc định hình sản phẩm. Những nhà lãnh đạo này phải ưu tiên cao nhất cho sự phát triển và thành công của sản phẩm—và họ phải có thời gian để làm việc đó. Điều đó có thể có nghĩa là thay đổi lịch trình và cam kết để Product Owner có thể tham dự các cuộc họp Agile quan trọng: các sự kiện Scrum, Sprint Review (Sơ kết Sprint) và Sprint Planning (Lập kế hoạch Sprint). Ngoài ra, quản lý cấp cao cần điều chỉnh lại các nguồn lực để bộ phận kinh doanh có thể chỉ định Product Owner cho các sáng kiến phát triển phần mềm linh hoạt.
Product Owner không chỉ thiết lập kỳ vọng và tầm nhìn cho sản phẩm mà còn ra quyết định về các tính năng và mục tiêu phát triển với các đồng nghiệp trong bộ phận CNTT. Họ sẽ “sống” trong hai thế giới. Họ phải có một số hiểu biết về công nghệ và cách nó đang chuyển đổi ngành công nghiệp. Họ cũng phải có được sự nhanh nhạy về nhu cầu thị trường và các tính năng của sản phẩm có giá trị nhất đối với người dùng cuối. (Thông thường, đó không phải là vấn đề đối với hầu hết Product Owner xuất phát từ kinh doanh, vì họ tương tác với người dùng cuối thường xuyên hơn so với các nhà quản lý CNTT). Product Owner có thể kết hợp kiến thức thị trường với phản hồi của các kỹ sư về tính khả thi về mặt kỹ thuật để tạo ra một kế hoạch phát triển rõ ràng.
Theo cách tiếp cận phát triển sản phẩm truyền thống, các trưởng bộ phận CNTT sẽ phỏng vấn các trưởng bộ phận kinh doanh một lần để thu thập các yêu cầu kinh doanh—ví dụ: những tính năng mới nào được yêu cầu trong phần mềm hoặc ứng dụng mới và các ứng dụng mới này cần chạy trên nền tảng nào? Các trưởng bộ phận CNTT nắm bắt các yêu cầu này trong các tài liệu đầy biệt ngữ và lần tới khi họ liên hệ với bộ phận kinh doanh, họ sẽ mang theo một mẫu thử gần như hoàn thiện.
Ngược lại, phát triển sản phẩm linh hoạt ít tập trung vào việc tiếp nhận yêu cầu mà tập trung nhiều hơn vào việc chia sẻ thông tin. Bộ phận kinh doanh và CNTT phải cùng nhau phát triển sản phẩm song song hàng ngày, trong một quy trình liên tục. Các nhà lãnh đạo cấp cao của doanh nghiệp có thể thiết lập mức độ cộng tác này bằng cách đầu tư vào các công cụ để gia tăng tương tác—ví dụ: phương tiện trực quan thay vì danh sách các yêu cầu.
Tại một công ty, Product Owner từ một đơn vị kinh doanh và một nhà lãnh đạo công nghệ đã sử dụng các bản phác thảo sketches để trao đổi phản hồi về phần mềm đang được phát triển. Các chuyên gia CNTT đã phác thảo một nguyên mẫu mà Product Owner có thể lướt xem qua từng trang. Product Owner có thể khoanh tròn những gì anh ấy thích hoặc vẽ phiên bản thay thế của các phần mà anh ấy không thích. Nhóm đã cùng nhau tinh chỉnh thiết kế theo cách mà mọi người đều có thể hiểu và đóng góp.
Các nhà lãnh đạo trong C-suite và các trưởng bộ phận kinh doanh có vai trò quan trọng như những người truyền bá cho các sản phẩm phần mềm mà họ đồng phát triển: họ phải yêu cầu các Product Owner từ bộ phận kinh doanh chịu trách nhiệm về việc triển khai thành công bất kỳ bản phát hành mới nào và tác động của nó đối với tình hình kinh doanh. Họ nên khuyến khích các Product Owner và kỹ sư CNTT “phổ cập” cho các đồng nghiệp thuộc bộ phận kinh doanh về lợi ích của phần mềm mới và lý do để áp dụng nó. Các nhóm Agile có thể chia sẻ video giới thiệu khi ra mắt sản phẩm, demo sản phẩm đó tại các cuộc họp và lắng nghe sự thất vọng cũng như ý kiến của đồng nghiệp về sản phẩm đó. Đồng thời, họ nên giải thích rằng thông tin đầu vào này có giá trị—và chứng minh điều đó bằng cách kết hợp những phản hồi đó vào các phiên bản chỉnh sửa của sản phẩm. Sự minh bạch như vậy, được khuyến khích và làm gương từ trên xuống, có thể tạo ra một văn hóa, trong đó mọi người cùng chung tay nỗ lực giải quyết vấn đề, thay vì phàn nàn về CNTT.
Đôi khi, các nhà lãnh đạo cấp cao của doanh nghiệp rất có thể là người dùng sản phẩm mà họ đang định hình. Nhưng thông thường thì không. Để giúp xây dựng phần mềm và sản phẩm thay đổi cách thức hoạt động của một công ty hoặc thu hút khách hàng, Product Owner từ bộ phận kinh doanh phải cam kết kiên định với nhu cầu của người dùng. Các giám đốc điều hành có thể khuyến khích quan điểm này bằng cách đặt ra một số câu hỏi định hướng trong quá trình đánh giá sản phẩm. Người dùng là ai? Họ đang sử dụng sản phẩm như thế nào? Họ chủ yếu làm việc tại văn phòng hay từ xa? Nỗi thất vọng lớn nhất của họ là gì? Các nhóm phát triển phần mềm cũng nên suy nghĩ về những câu hỏi này khi họ thiết kế các công cụ và trải nghiệm để đảm bảo rằng họ đang giải quyết vấn đề của người dùng cuối.
Các giám đốc điều hành cấp cao thường là nhóm không thích rủi ro. Các mô hình phát triển sản phẩm truyền thống nhấn mạnh đến các phiên check-in thường xuyên ở các giai đoạn phát triển khác nhau—một cách tốn nhiều thời gian nhưng toàn diện để đảm bảo rằng các sản phẩm bao gồm tất cả các tính năng mong muốn và không ẩn chứa các lỗi hoặc sai sót khác. Ngược lại, phát triển sản phẩm linh hoạt nhấn mạnh cách tiếp cận thử nghiệm và học hỏi—ví dụ: phát hành một bản MVP (Sản phẩm khả thi tối thiểu) mang lại giá trị cho người dùng cuối trong thời gian ngắn nhưng dự kiến sẽ thay đổi nhanh chóng.
Trong trường hợp này, CIO có thể cần giúp các giám đốc điều hành cấp cao của doanh nghiệp đạt được thỏa thuận với việc phát hành một sản phẩm đủ tốt bằng cách xác định lại kỳ vọng và ngưỡng rủi ro của họ. Ví dụ, một CIO có thể nêu bật những câu chuyện thành công của Agile—các tình huống mà trong đó một công ty đã phát hành một sản phẩm đủ tốt, thay đổi chiến lược giữa chừng để phù hợp với các phản hồi và cuối cùng đưa ra một giải pháp thành công. Ngoài ra, CIO có thể cởi mở về việc chấp nhận các bản phát hành khả thi ở mức tối thiểu—khuyến khích hành vi tương tự trong toàn công ty. Và ít nhất ngay từ ban đầu, các nhà lãnh đạo công nghệ có thể thúc đẩy lịch trình đưa sản phẩm ra thị trường khiến các bộ phận kinh doanh không còn lựa chọn nào khác ngoài việc theo đuổi các sản phẩm đủ tốt.
CIO cũng nên giúp các nhà lãnh đạo cấp cao của doanh nghiệp hiểu rằng ngay cả khi có cách tiếp cận đủ tốt, các nhóm Agile cũng sẽ không cung cấp mọi thứ ngay lập tức. Quá trình này thực sự nghiêm ngặt hơn những gì hầu hết các giám đốc điều hành quan sát. Các nhóm Agile phải làm việc hết mình để thu thập phản hồi nhằm xác định những gì hiệu quả, những gì không và cách thực hiện các cải tiến tăng dần nhằm cải thiện sản phẩm hoặc nâng cao trải nghiệm của khách hàng với sản phẩm. Và họ phải lặp đi lặp lại quá trình này nhiều lần.
Khi các nhóm Scrum nâng cao hiệu suất và kinh nghiệm của họ, chắc chắn họ sẽ va chạm với các nhóm và quy trình chậm hơn ở những bộ phận khác trong tổ chức. Những nhóm chậm hơn này sử dụng các quy trình làm việc cứng nhắc, truyền thống hơn. Để tối đa hóa tác động của các phương pháp Agile, lãnh đạo cấp cao phải xem xét cách thức để chuyển giao bài học từ các nhóm Agile sang các nhóm khác của công ty. Làm việc với CIO và các chuyên gia công nghệ khác, giám đốc điều hành cấp cao có thể xác định các quy trình và sản phẩm quan trọng nhất để mang lại giá trị kinh doanh cho khách hàng và xem xét các nguyên tắc Agile nào sẽ giúp tăng tốc mọi thứ.
Agile đòi hỏi cam kết về thời gian và sự quan tâm, điều này có thể gây khó chịu cho các nhà lãnh đạo doanh nghiệp vốn đã có nhiều ưu tiên. Nhưng với một số định hướng từ CIO và các chuyên gia công nghệ khác trong bộ phận CNTT, các giám đốc điều hành cấp cao có thể có được cái nhìn dễ hiểu hơn về quá trình chuyển đổi từ các quy trình phát triển sản phẩm truyền thống sang quy trình phát triển sản phẩm linh hoạt. Các nhà lãnh đạo cấp cao sẽ hiểu rõ hơn các thuật ngữ kỹ thuật liên quan đến Agile và giúp xác định các công nghệ và bộ kỹ năng cần thiết để vận hành thành công theo mô hình Agile. Có lẽ thậm chí còn quan trọng hơn, các giám đốc điều hành có thể biến bằng chứng mang tính giai thoại thành các chỉ số “cứng” phản ánh cách thức quy trình làm việc Agile tạo ra kết quả kinh doanh tích cực—ví dụ: trải nghiệm khách hàng gắn kết hơn, quy trình nội bộ hợp lý hơn và văn hóa doanh nghiệp hợp tác, phát triển.
Không nên có người đưa ra yêu cầu và người thực thi, không nên có tình trạng “chúng ta với bọn họ” giữa bộ phận kinh doanh và bộ phận công nghệ. Chỉ nên có một nhóm, xây dựng phần mềm sáng tạo giúp thay đổi công việc của những người sử dụng và cho phép kết nối ngày càng gần hơn với khách hàng và đối tác kinh doanh.
Nguồn: mckinsey.com
Tác giả: Santiago Comella-Dorda, Krish Krishnakanthan, Jeff Maurone và Gayatri Shenai
Bài viết liên quan:
