Tư duy sản phẩm cho kỹ sư Cloud Native: Biến kỹ thuật thành giá trị kinh doanh

Tư duy sản phẩm cho kỹ sư Cloud Native: Biến kỹ thuật thành giá trị kinh doanh

Trong bối cảnh công nghệ hiện đại, đặc biệt là lĩnh vực Cloud Native và Platform Engineering, các kỹ sư thường đối mặt với áp lực phải chứng minh giá trị của công việc mình làm ra ngoài việc chỉ duy trì hệ thống hoạt động trơn tru. Stéphane Di Cesare (Senior Platform Engineer tại DKB) và Cat Morris (Staff Product Manager tại Syntasso) đã có một bài chia sẻ sâu sắc về cách áp dụng tư duy sản phẩm (product thinking) để chuyển đổi tư duy từ "trung tâm chi phí" (cost center) sang "động lực giá trị" (value driver).

Product Thinking for Cloud Native Engineers

Tại sao kỹ sư cần tư duy sản phẩm?

Trước đây, bộ phận IT thường được xem là nơi chỉ tạo ra chi phí, ví dụ như cài đặt máy in hay quản lý hạ tầng. Tuy nhiên, ngày nay IT là yếu tố then chốt tạo ra giá trị cho doanh nghiệp. Vấn đề là nhiều kỹ sư vẫn bị mắc kẹt trong tư duy tập trung vào giải pháp kỹ thuật (solution) thay vì tập trung vào giá trị mang lại cho người dùng.

Một ví dụ điển hình là việc quản lý cụm Kubernetes bằng Excel. Dù kỹ thuật rất thú vị và "ngầu", nhưng nếu người dùng cuối không thấy giá trị thực sự hoặc giải pháp đó không giải quyết được nỗi đau của họ, thì đó là sự lãng phí nguồn lực.

Nguyên tắc cốt lõi của tư duy sản phẩm là:

• Kết quả (Outcome) quan trọng hơn Sản lượng (Output): Đừng chỉ đo lường số lượng ticket Jira bạn đóng hay số dòng code viết ra. Hãy tập trung vào tác động thực tế mà công việc của bạn mang lại cho người dùng và doanh nghiệp.
• Sản phẩm (Product) quan trọng hơn Dự án (Project): Dự án có điểm kết thúc, nhưng sản phẩm có vòng đời. Bạn cần cân nhắc đến việc bảo trì, vận hành và phát triển lâu dài, ngay cả với những đoạn script nhỏ.

Xác định vấn đề trước khi tìm giải pháp

Một trong những sai lầm phổ biến nhất mà các kỹ sư hay mắc phải là lao thẳng vào việc xây dựng giải pháp mà không hiểu rõ vấn đề. Cat Morris chia sẻ một câu chuyện "đau lòng" về thời gian cô làm Product Owner cho một đội nhóm platform. Đội ngũ của cô đã dành 3 tháng để di chuyển các pipeline từ Jenkins sang Azure DevOps chỉ vì Jenkins "quá cũ". Kết quả là họ đã tốn rất nhiều công sức, chi phí vận hành tăng lên, nhưng trải nghiệm người dùng hầu như không thay đổi. Người dùng vẫn chỉ nhấn nút và nhận kết quả, không có giá trị kinh doanh nào được tạo ra.

Để tránh tình trạng này, các tác giả đề xuất mô hình "Double Diamond" (Kim cương kép):

1. Khám phá và Định nghĩa (Problem Space): Tập trung vào việc tìm hiểu vấn đề thực sự. Đừng vội nghĩ về cách giải quyết.
2. Giải pháp và Phát triển (Solution Space): Chỉ bắt đầu xây dựng khi đã hiểu rõ vấn đề.

Thay vì di chuyển pipeline, nếu đội ngũ của Cat Morris dành thời gian khám phá vấn đề, họ có thể đã nhận ra những nỗi đau thực sự như: quá trình onboarding khách hàng mới mất quá nhiều thời gian, việc mở rộng quy mô (scaling) khi có đợt traffic lớn phải làm thủ công, hoặc hạ tầng cũ sắp hết hạn bảo hành. Những vấn đề này mới thực sự tạo ra giá trị nếu được giải quyết.

Thấu hiểu người dùng và xây dựng sự thấu cảm

Để áp dụng tư duy sản phẩm hiệu quả, kỹ sư cần hiểu rõ ai là người dùng của mình. Đối với một nền tảng nội bộ (internal platform), người dùng không chỉ là các lập trình viên (builders). Có 4 nhóm người dùng chính cần cân nhắc:

• Người xây dựng (Builders): Các đội ngũ phát triển ứng dụng sử dụng platform.
• Người hỗ trợ (Enablers): Những người giúp others sử dụng platform, giúp platform phát triển.
• Người xem (Viewers): Các bộ phận như Tài chính (Finance) hoặc Quản lý cần nhìn thấy chi phí và hiệu quả hoạt động.
• Người kiểm soát (Regulators): Các bộ phận kiểm toán, tuân thủ. Đối với một ngân hàng như DKB, việc giúp các kiểm toán viên dễ dàng truy xuất thông tin là một giá trị cực lớn.

Một kỹ thuật tuyệt vời để xây dựng sự thấu cảm là Shadowing (Quan sát công việc). Hãy ngồi cạnh người dùng và quan sát họ làm việc mà không can thiệp. Bạn sẽ thấy họ gặp khó khăn ở đâu, họ phải làm những thao tác thủ công nào, hoặc họ tìm cách lách luật (workaround) ra sao. Lưu ý quan trọng: Đừng biến buổi shadowing thành buổi hỗ trợ kỹ thuật. Hãy quan sát để học hỏi, không phải để sửa lỗi ngay lập tức.

Chọn số liệu đo lường đúng đắn

Việc đo lường là bắt buộc để chứng minh giá trị, nhưng hãy chọn đúng chỉ số. Đừng chỉ đếm số lượng deployment. Hãy tập trung vào các chỉ số phản ánh trải nghiệm của nhà phát triển (Developer Experience - DevEx):

• Flow (Dòng chảy): Mức độ mà kỹ sư có thể tập trung mà không bị gián đoạn.
• Cognitive Load (Quá tải nhận thức): Giảm bớt lượng thông tin kỹ thuật phức tạp mà dev phải nắm giữ (ví dụ: không bắt dev phải là chuyên gia Jenkins).
• Feedback Loops (Vòng lặp phản hồi): Tốc độ nhận được kết quả sau khi thay đổi code.

Đối với platform engineering, có thể cân nhắc 4 khía cạnh: Tốc độ (Speed), An toàn (Safety), Hiệu quả (Efficiency) và Khả năng mở rộng (Scalability). Ví dụ: Thời gian trung bình để thêm một dịch vụ mới vào platform (Mean time to add a service).

Áp dụng tư duy sản phẩm vào vai trò của bạn

Kỹ sư không cần phải là Product Manager mới có thể áp dụng tư duy này. Dưới đây là những hành động cụ thể bạn có thể làm ngay:

1. Luôn hỏi "Tại sao?": Hãy giống như một đứa trẻ tò mò. Khi được yêu cầu xây dựng tính năng X, hãy hỏi tại sao lại cần X, nó giải quyết vấn đề gì, và tại sao vấn đề đó lại quan trọng lúc này.
2. Đọc các cập nhật kinh doanh: Hiểu mục tiêu của công ty. Họ đang muốn giảm chi phí vận hành, tăng tốc độ ra thị trường, hay mở rộng sang vùng địa lý mới? Điều này giúp bạn định hướng công việc kỹ thuật sao cho phù hợp với chiến lược chung.
3. Triển khai công cụ đo lường (Instrumentation): Xây dựng các dashboard để chứng minh giá trị. Cho thấy bạn đã giúp đội ngũ đi nhanh hơn bao nhiêu, tiết kiệm được bao nhiêu tiền, hoặc giảm thiểu rủi ro ra sao.

Tư duy sản phẩm không chỉ giúp bạn xây dựng phần mềm tốt hơn mà còn giúp bạn phát triển sự nghiệp. Bằng cách tập trung vào giá trị kinh doanh và thấu hiểu người dùng, bạn sẽ chuyển mình từ một người chỉ viết code thành một đối tác chiến lược không thể thiếu của tổ chức.