Quản lý sản phẩm kỹ thuật số chiến lược: Tối đa hóa ROI (Return on Investment – Lợi nhuận trên đầu tư)
Trong lĩnh vực quản lý sản phẩm, một trong những nguyên tắc quan trọng và cơ bản nhất chính là tối đa hóa lợi nhuận trên đầu tư (ROI) cho những nỗ lực nghiên cứu và phát triển (R&D) mà chúng ta bỏ ra. Là một doanh nghiệp mang tính lợi nhuận, mục tiêu chính của chúng ta phải là tối đa hóa lợi nhuận. Điều này đòi hỏi chúng ta phải ưu tiên những hoạt động R&D có khả năng hỗ trợ tối đa cho mục tiêu này. Trong hầu hết các công ty, ngân sách R&D thường được phân bổ dựa trên một tỷ lệ phần trăm của doanh thu và mục tiêu là đạt được lợi nhuận từ khoản đầu tư này. Việc ưu tiên những nỗ lực R&D hỗ trợ cho mục tiêu này là trọng tâm của quản lý sản phẩm.
Điều này quá rõ ràng đến nỗi việc viết về nó gần như trở nên khó khăn. Vậy tại sao tôi vẫn chọn viết về nó? Kinh nghiệm của tôi với nhiều công ty cho thấy quản lý sản phẩm ở nhiều khía cạnh trở thành nạn nhân của hàng loạt các nghĩa vụ khác nhau, những việc cần phải làm và những yêu cầu bắt buộc đến mức hầu như không còn chỗ cho việc phát triển chức năng mới nào có ít nhất một số tiềm năng để tác động đến doanh thu.
Có ba lý do chính khiến các công ty rơi vào bẫy ưu tiên các nỗ lực R&D không hỗ trợ cho nguyên tắc đầu tiên này của quản lý sản phẩm: sự tùy chỉnh (customization), nợ kỹ thuật (technical debt) và thiếu tự động hóa, đặc biệt là trong việc kiểm thử (testing). Chúng ta sẽ cùng nhau đi sâu hơn vào từng lý do này.
Đầu tiên, việc tùy chỉnh (customization) là một mô hình phổ biến tại nhiều công ty. Quá trình thảo luận với khách hàng tiềm năng diễn ra tốt đẹp và chúng ta có thể ký kết hợp đồng nếu chấp nhận triển khai một số điều chỉnh hoặc tính năng đặc biệt theo yêu cầu của khách hàng. Ban quản lý công ty đồng ý và yêu cầu bộ phận nghiên cứu và phát triển (R&D) thực hiện điều này. Thông thường, việc này được giải quyết bằng cách tạo nhánh từ cơ sở mã nguồn và cung cấp một phiên bản đặc biệt cho khách hàng.
Khoản đầu tư ban đầu để tạo ra phiên bản đặc biệt này thường khá hạn chế. Tuy nhiên, thách thức xuất hiện khi số lượng khách hàng yêu cầu tùy chỉnh riêng tăng lên, làm tăng nhanh số lượng nhánh mã nguồn. Hơn nữa, khách hàng thường yêu cầu thêm các tùy chỉnh theo thời gian và do chúng ta đã đồng ý từ ban đầu, họ kỳ vọng chúng ta sẽ tiếp tục đáp ứng yêu cầu của họ. Vì vậy, những gì bắt đầu như một nhánh nhỏ trong một phần nhỏ của cơ sở mã nguồn ngày càng phát triển theo thời gian.
Hậu quả nhanh chóng trở nên rõ ràng: bất kỳ thay đổi nào ảnh hưởng đến nhiều nhánh đều yêu cầu thay đổi trên tất cả các nhánh. Vì có sự tùy chỉnh, việc này không chỉ đơn giản là sao chép mà còn đòi hỏi phải kiểm tra kỹ lưỡng ảnh hưởng của thay đổi trong mỗi nhánh cụ thể. Mọi lỗi được phát hiện cũng cần phải được xử lý theo cách tương tự. Cuối cùng, không phải là không thể kinh doanh theo cách này, nhưng nó đòi hỏi nỗ lực cực kỳ lớn, làm giảm dần thời gian có sẵn cho việc thêm vào các chức năng mới tạo ra giá trị.
Lĩnh vực thứ hai cần quan tâm chính là nợ kỹ thuật (technical debt). Đặc biệt ở phía kinh doanh của các công ty, sự hiểu biết về nhu cầu đầu tư vào quản lý nợ kỹ thuật thường khá hạn chế. Điều này có thể dễ dàng dẫn đến tình trạng tái cấu trúc và trả nợ kỹ thuật luôn bị hoãn lại đến một thời điểm sau và tất cả nguồn lực đều được phân bổ để xây dựng chức năng mới và khắc phục sự cố của khách hàng.
Nợ kỹ thuật (technical debt) là một khái niệm trong ngành phát triển phần mềm, mô tả hiện tượng khi các lập trình viên chọn giải pháp nhanh chóng, tạm thời thay vì giải pháp tốt nhất và bền vững hơn. Mục đích ban đầu thường là đẩy nhanh tiến độ phát triển hoặc đáp ứng các yêu cầu ngắn hạn. Tuy nhiên, như một khoản nợ tài chính, nếu không được trả lại kịp thời, nợ kỹ thuật có thể tích tụ và gây ra nhiều vấn đề lớn hơn.
Ảnh hưởng của Nợ Kỹ Thuật:
- Tăng Chi Phí Phát Triển: Giống như việc trả lãi cho nợ tài chính, nợ kỹ thuật tạo ra gánh nặng bổ sung trong quá trình phát triển. Các giải pháp tạm thời cần được sửa chữa hoặc thay thế, điều này đòi hỏi thời gian và nguồn lực.
- Giảm Năng Suất: Khi nợ kỹ thuật tăng lên, việc thêm chức năng mới hoặc sửa lỗi trở nên phức tạp và tốn kém hơn. Mã nguồn khó hiểu và duy trì hơn, làm giảm hiệu suất làm việc của các nhà phát triển.
- Tăng Rủi Ro Bảo Mật và Lỗi Phần Mềm: Các giải pháp tạm thời có thể không được thiết kế với các biện pháp bảo mật chặt chẽ, tăng nguy cơ lỗ hổng bảo mật. Ngoài ra, mã nguồn “đường tắt” thường dễ phát sinh lỗi hơn.
- Hạn Chế Khả Năng Mở Rộng: Nợ kỹ thuật có thể hạn chế khả năng mở rộng và cải tiến của sản phẩm. Hệ thống trở nên cứng nhắc và khó thích ứng với yêu cầu mới hoặc công nghệ tiên tiến.
- Ảnh hưởng đến Chất Lượng Sản Phẩm: Cuối cùng, sản phẩm có thể trở nên kém ổn định và khó sử dụng, ảnh hưởng đến trải nghiệm người dùng cuối và uy tín của sản phẩm.
Quản lý nợ kỹ thuật đòi hỏi sự cân nhắc và lập kế hoạch cẩn thận, cũng như sự hiểu biết rõ ràng về các hệ lụy của việc chấp nhận giải pháp tạm thời và lợi ích lâu dài của việc đầu tư vào các giải pháp bền vững hơn.
Quản lý sản phẩm chủ yếu tập trung vào việc lựa chọn những chức năng chưa tồn tại trong sản phẩm hiện tại. Điều này có nghĩa là chúng ta đang dự đoán ảnh hưởng đối với người dùng, nhưng không chắc chắn rằng ảnh hưởng mong đợi thực sự được đạt được. Để đảm bảo rằng chúng ta chỉ xây dựng những chức năng thực sự mang lại giá trị đáng kể, một cơ chế hiệu quả là xây dựng các phần nhỏ của chức năng, triển khai từng phần và đo lường ảnh hưởng của từng phần để xác định liệu giả thuyết của chúng ta có chính xác hay không. Tuy nhiên, điều này chỉ hoạt động khi chúng ta có chu kỳ phản hồi ngắn, cho phép chúng ta nhanh chóng thu thập phản hồi và đưa ra quyết định. Đây là một trong những lý do chính đằng sau sự phát triển của DevOps, nhưng nhiều công ty không tận dụng được cơ chế này.
Cơ chế thứ hai liên quan đến việc xác định rõ ràng chức năng nào trong sản phẩm được coi là phân biệt, tức là tạo ra doanh thu từ khách hàng, và chức năng nào là hàng hóa, tức là cần thiết cho sản phẩm hoạt động nhưng không tạo ra doanh số và doanh thu. Khi chúng ta rõ ràng về điều này, chúng ta có thể dễ dàng từ chối các yêu cầu thay đổi đối với chức năng hàng hóa và ưu tiên mở rộng và thay đổi chức năng phân biệt. Như tôi đã thảo luận cách đây vài năm, nghiên cứu của chúng tôi cho thấy 80-90% tất cả nguồn lực R&D được chi tiêu vào chức năng hàng hóa. Điều này tất nhiên là xa rời tối ưu nếu mục tiêu của chúng ta là tối đa hóa ROI trên R&D.
Nguyên tắc đầu tiên của quản lý sản phẩm là tối đa hóa lợi nhuận trên đầu tư vào R&D. Mặc dù điều này rất rõ ràng theo lý thuyết, thực tế cho thấy nhiều công ty vẫn đang gặp khó khăn với điều này. Nguyên nhân bao gồm việc tùy chỉnh không phù hợp, tích tụ nợ kỹ thuật và thiếu tự động hóa. Hai cơ chế hỗ trợ trong việc thực hiện nguyên tắc đầu tiên bao gồm chu kỳ phản hồi nhanh và xác định rõ ràng chức năng phân biệt so với hàng hóa. Như Kris Gale đã nói, giá trị nằm ở những gì được sử dụng, không phải ở những gì được xây dựng.
Don’t hesitate to contact Thanh for advice on automation solutions for CAD / CAM / CAE / PLM / ERP / IT systems exclusively for SMEs.
Luu Phan Thanh (Tyler) Solutions Consultant at PLM Ecosystem Mobile +84 976 099 099
Web www.plmes.io Email tyler.luu@plmes.io