Trong sự nghiệp công nghệ của mình, tôi đã dành phần lớn thời gian để thực hiện các quy trình chuyển đổi từ phương pháp Waterfall sang phát triển Agile với Kanban hoặc Scrum.

Hầu hết thời gian và nỗ lực đã được dành cho việc tìm ra phương pháp tối ưu hơn. Tùy thuộc vào khả năng của nhóm, Kanban thích hợp với việc tự quản lý, còn Scrum lại phù hợp hơn với nhóm ít kinh nghiệm. 90% các nhóm của tôi đã từng thực hiện đều theo quy trình Kanban. Tôi có thể dễ dàng chê bai một người, và biểu dương người khác trong nhóm, đồng thời mở lại những cuộc tranh luận cũ xem điều gì là tốt nhất. Nhưng với một CTO, tôi tin rằng điều đó thực sự không quan trọng.

Với các nhóm phát triển, CTO chỉ quan tâm đến việc chuyển giao sản phẩm. Đảm bảo rằng các tính năng mới được đưa ra và mọi lỗi đều được sửa. Cho dù bạn có chuyển giao sản phẩm liên tục hay cố định vào những thời điểm cụ thể, thì các nhóm khác trong doanh nghiệp của bạn cũng cần phải biết về những gì đã được và không được chuyển giao, cũng như những gì sắp diễn ra. Và điều quan trọng hơn là CTO cần giao tiếp liên tục, nhưng với nhiều hệ thống và quy trình Agile đều này không dễ dàng. 

Ví dụ, Jira rất tuyệt ở cấp độ vi mô, nhưng lại rất tệ trong việc truyền đạt lộ trình và chiến lược về một sản phẩm cho cả nhóm hay cho cả công ty. (Gần đây đã có một số cải thiện nhưng vẫn còn rời rạc).

Mục đích của việc theo dõi lộ trình là cho phép phần còn lại của doanh nghiệp chuẩn bị phối hợp với chức năng mới trong tương lai, với marketing và bán hàng để chuẩn bị chiến dịch kinh doanh và sử dụng nó chặt chẽ. Điều này rõ ràng rất quan trọng và CTO cần biết từ các Scrum Master về tình trạng công việc và liệu có bất kỳ vấn đề nào sắp tới có thể gây ra hậu quả xấu cho sản phẩm và dự án hay không.

Che giấu các vấn đề và trì hoãn công việc là đặc biệt phổ biến, có thể khiến dự án bị trì hoãn vào phút cuối tạo ra sự bối rối và mất lòng tin ở tất cả các cấp của nhóm phát triển và với các bộ phận khác của công ty.

Mối quan hệ tốt nhất là mọi người đều minh bạch triệt để trong công việc, đặc biệt là khi làm việc trong một nhóm công nghệ hiệu suất cao. Nếu các Scrum Master trung thực (và nếu CTO đã xây dựng một nhóm không phụ thuộc vào các siêu sao, điều đó sẽ giúp ích!) thì CTO cần phải đáp lại họ bằng định hướng rõ ràng về chiến lược kinh doanh rộng hơn và các lộ trình phù hợp với chiến lược đó ra sao. Sau đó, CTO sẽ cần cung cấp cho các Scrum Master thời hạn yêu cầu và cung cấp nguồn lực cho họ.

Làm điều này như thế nào trong thực tế?

Một công ty phần mềm kinh doanh SaaS dựa trên số tiền thu về hàng tháng, rất quan tâm về việc khách hàng rời bỏ họ. Giả sử sản phẩm phần mềm rất tốt nhưng không cần thiết. Điều này có thể được giải quyết bởi dịch vụ khách hàng tốt bằng cách phân loại xác định những khách hàng có khả năng rời đi. Và xem xét điều chỉnh một số yếu tố:

• Thêm chức năng mới 
• Làm cho nó trở nên hấp dẫn theo cách nó được tích hợp trong văn hóa của khách hàng bao gồm phần mềm kế toán và CRM 
• Thay đổi giá 
• Thay đổi thời gian đăng ký – chẳng hạn chuyển từ hàng tháng sang hàng năm

Một số giải pháp này có thể được giải quyết bằng cách phát triển nhưng hãy tập trung vào phần ba và cách chuyển đổi nó trong thực tế. Tích hợp nó với các hệ thống khác và trở thành một phần của quy trình mang lại giá trị quan trọng cho khách hàng. 

Do đó, nếu khách hàng muốn rời đi, nhóm sẽ phải thay đổi lại toàn bộ quy trình. Quay lại lộ trình – Tích hợp với hệ thống X nào đó. Đối với một Scrum master và nhóm không được đào tạo, đây có thể chỉ là một phần chức năng khác, có khả năng bị coi là vô nghĩa. Nhưng nếu một CTO giải thích ý nghĩa đằng sau chức năng thì các nhóm có thể đưa ra quyết định sáng suốt hơn.

Trong trường hợp này, họ có thể quyết định xây dựng một khung cho chức năng ngay lập tức, để việc tích hợp với các hệ thống khác có thể xảy ra dễ dàng hơn trong tương lai. CTO cần giải thích chiến lược và lộ trình, theo cách giúp các Scrum Master và nhóm cảm thấy muốn tham gia, có năng lượng hơn là việc chỉ như những con rô-bốt đang thực thi.

CTO phải thay mặt cho nhóm công nghệ giao tiếp với các nhân viên kinh doanh, và sẽ rất cần sự cởi mở và trung thực từ các Scrum Master để đảm bảo điều này được thực hiện một cách hiệu quả nhất. Tiềm năng của sự nghiệp công nghệ của Scrum Master được tối đa hóa và chuyển giao từ Scrum Master sang CTO, và họ cần hiểu ngược lại, CTO cần gì từ mình?

Theo CTO Academy