Chuyển đổi số: Bạn thực sự đang trả tiền cho điều gì?

Hai năm, bốn nhà cung cấp, và một roadmap liên tục bị trì hoãn.

Đó là cách hầu hết những câu chuyện về chuyển đổi số bắt đầu. Nhưng câu chuyện của bạn không nhất thiết phải kết thúc như vậy.

Hầu như CTO nào tôi từng trao đổi cũng đã trải qua một phiên bản tương tự.

Ban đầu, mọi thứ rất rõ ràng: hiện đại hóa hệ thống lõi, thay thế monolith cũ bằng một nền tảng dễ bảo trì hơn, rút ngắn thời gian từ ý tưởng đến khi đưa sản phẩm vào production.

Sau đó, ngân sách bắt đầu phình to, timeline kéo dài gấp đôi, và đội ngũ từng cam kết cung cấp các kỹ sư senior âm thầm chuyển phần việc cho những developer junior đang vừa làm vừa học trên chính codebase của bạn.

Sáu tháng trôi qua, bạn không còn thực sự trả tiền cho tiến độ nữa.

Bạn đang trả tiền cho đường cong học tập của đội ngũ.

Có một câu hỏi hiếm khi được đặt ra một cách thẳng thắn:

Chi phí thực sự để hoàn thành dự án này là bao nhiêu, và với số tiền đó, bạn thực sự đang mua thứ gì?

Hãy cùng nhìn vào ba lựa chọn mà phần lớn doanh nghiệp thường cân nhắc. Bởi vì bài toán thực sự không nằm ở mức giá mỗi giờ.

Nó nằm ở câu hỏi: Ai là người gánh rủi ro?

Lựa chọn 1: Xây dựng đội ngũ in-house

Trên lý thuyết, đây là phương án khá lý tưởng.

Bạn kiểm soát văn hóa, thứ tự ưu tiên và roadmap. Không ai phải giải thích domain của doanh nghiệp cho một bên thứ ba hết lần này đến lần khác.

Nhưng một platform engineer senior có thể tiêu tốn một khoản chi phí nhân sự đáng kể. Và chi phí thực sự không chỉ nằm trên bảng lương.

Nó còn nằm ở khoảng thời gian vị trí bị bỏ trống giữa các lần tuyển dụng, hàng tháng trời dành cho việc tìm kiếm nhân sự, hay một kỹ sư rời đi ngay sau khi tài liệu kiến trúc vừa hoàn thành vì một đối thủ đưa ra mức lương cao hơn 20%.

Xây dựng đội ngũ in-house đồng nghĩa với việc doanh nghiệp phải tự gánh toàn bộ chi phí tuyển dụng, onboarding, duy trì nhân sự, cũng như những khoảng thời gian đội ngũ bị chững lại khi những người giỏi nhất phải chờ đợi các quyết định chỉ có bạn mới có thể đưa ra.

Bạn vẫn phải trả lương cho họ, bất kể pipeline công việc đang đầy hay trống.

Lựa chọn 2: Thuê một agency lớn

Các agency lớn mang đến hình ảnh chuyên nghiệp, những case study ấn tượng và một sales deck được trình bày rất đẹp.

Nhưng họ cũng mang theo một mô hình kinh tế riêng.

Biên lợi nhuận của họ phải chi trả cho account manager, sales team và cả một hệ thống quản lý nhiều tầng vốn thường khuyến khích việc bán thêm scope hơn là hoàn thành dự án nhanh hơn.

Bạn không phải khách hàng duy nhất của họ.

Và rất hiếm khi bạn là khách hàng quan trọng nhất.

Khi xảy ra xung đột giữa account lớn nhất của họ và dự án của bạn, bạn có thể đoán được ngay bên nào sẽ nhận được sự ưu tiên từ những nhân sự senior nhất.

Những người xây dựng proposal cho bạn không phải là những người trực tiếp triển khai dự án.

Và những người triển khai dự án lại có thể được luân chuyển chỉ sau vài tháng.

Cuối cùng, bạn trả mức giá enterprise cho một đội ngũ delivery mà bên dưới lớp vỏ thương hiệu đôi khi vẫn chủ yếu là những developer junior.

Lựa chọn 3: Mô hình DevVina

Đây chính là cách chúng tôi làm tại DevVina.

Và mọi thứ bắt đầu từ một giả định khác:

Công việc nên được định giá dựa trên kết quả và mức độ ownership, thay vì số giờ làm việc của bao nhiêu người.

Chúng tôi xây dựng những đội ngũ nhỏ, với tỷ lệ senior cao, làm việc sát với sản phẩm của bạn.

Bạn được làm việc trực tiếp với những người thực sự đưa ra quyết định về codebase của mình, thay vì phải đi qua một chuỗi handoff giữa nhiều tầng nhân sự.

Vì cấu trúc chi phí của chúng tôi khác với các mô hình truyền thống, chúng tôi có thể cung cấp sự tham gia trực tiếp của các kỹ sư senior với một mức chi phí khiến bộ phận tài chính phải dừng lại và kiểm tra lại phép tính.

Lý do không phải vì chúng tôi trả cho nhân sự ít hơn.

Mà bởi chúng tôi không phải gánh một bộ máy sales luôn tìm cách bán cho bạn dự án tiếp theo trước khi dự án hiện tại hoàn thành.

Và chúng tôi cũng muốn nói thẳng về sự đánh đổi

Bởi vì bất kỳ lựa chọn nào cũng có trade-off.

Làm việc với một đối tác như chúng tôi đồng nghĩa với việc bạn sẽ từ bỏ một phần quyền kiểm soát hàng ngày mà bạn có khi toàn bộ đội ngũ nằm trong nội bộ công ty.

Bạn không thể bước xuống hành lang và tùy ý ngắt lời một developer ngay giữa lúc họ đang tập trung suy nghĩ.

Khoảng cách đó cần được quản lý bằng những quy trình giao tiếp tốt:

• Backlog rõ ràng.
• Standup trung thực.
• Lịch demo đều đặn.
• Cơ chế giao tiếp minh bạch để duy trì sự tin tưởng.

Nếu tổ chức của bạn chưa sẵn sàng cho mức độ minh bạch như vậy, không có mô hình vendor nào có thể cứu được dự án.

Nhưng có một điều mà những con số thường không thể hiện

Khi bạn tính toán tổng chi phí thực tế (fully loaded cost) của một đội ngũ in-house, bao gồm chi phí tuyển dụng, phúc lợi, công cụ, chi phí quản lý và thời gian nhàn rỗi giữa các đợt phát triển tính năng, thì đội ngũ in-house hiếm khi thực sự rẻ hơn một đối tác được vận hành tốt.

Và khi so sánh với chi phí thực tế của một agency lớn, nơi bạn bị tính phí cho từng cuộc họp, từng vòng chỉnh sửa và từng phần scope phát sinh, khoảng cách này còn trở nên lớn hơn.

Nhưng chi phí không phải là thước đo duy nhất.

Tốc độ quan trọng. Và trách nhiệm cũng quan trọng.

Tốc độ và accountability

Với đội ngũ in-house, tốc độ phụ thuộc vào khả năng tuyển dụng nhanh đến đâu.

Và khi thị trường nhân sự khan hiếm, điều đó hiếm khi đủ nhanh.

Agency thường rất nhanh ở giai đoạn đầu, khi sales team còn có động lực thúc đẩy dự án.

Nhưng họ có thể chậm lại ở giai đoạn giữa, khi dự án của bạn phải cạnh tranh với hàng chục dự án khác để giành cùng một nguồn lực delivery.

Một đối tác chuyên trách có động lực hoàn toàn khác.

Chúng tôi đánh giá uy tín của mình dựa trên việc roadmap của khách hàng có thực sự tiến lên hay không.

Bởi vì công việc lặp lại và referral là cách chúng tôi phát triển.

Sự đồng nhất về lợi ích này tạo ra những thay đổi trong cách hành xử mà một bản Statement of Work đơn thuần không thể tạo ra.

Điều gì xảy ra khi requirements thay đổi?

Và chúng luôn thay đổi.

Một hợp đồng fixed-bid quá cứng nhắc sẽ khiến cả hai bên đều gặp bất lợi.

Trong khi đó, mô hình time-and-materials thuần túy lại khiến khách hàng chịu rủi ro nếu đội ngũ triển khai chậm.

Chúng tôi cố gắng đứng ở giữa hai mô hình này.

Mô hình của chúng tôi gắn việc lập kế hoạch với các ưu tiên thực tế của khách hàng, đồng thời cho phép scope có thể điều chỉnh mà không khiến ngân sách tăng mất kiểm soát.

Đó không phải là một câu nói marketing.

Đó là một quyết định mang tính cấu trúc về cách chúng tôi xây dựng đội ngũ và cách chúng tôi giao tiếp với khách hàng.

Seniority – điều ai cũng nói, nhưng không phải ai cũng thực hiện

Hãy nói thẳng về vấn đề seniority, bởi đây là điều được rất nhiều vendor nhắc đến nhưng lại là thứ ít được thể hiện nhất trong quá trình triển khai thực tế.

Mọi vendor đều nói rằng họ sẽ cung cấp senior engineer.

Điểm khác biệt nằm ở câu hỏi:

Lời cam kết đó có còn đúng khi hóa đơn đầu tiên được gửi đến hay không?

Chúng tôi chủ động giữ đội ngũ nhỏ và giàu kinh nghiệm.

Bởi một đội ngũ nhỏ gồm những người có kinh nghiệm thường có thể đưa sản phẩm vào production nhanh hơn một đội ngũ lớn với nhiều cấp độ khác nhau.

Và chi phí thực tế có thể thấp hơn bạn nghĩ.

Ít người hơn đồng nghĩa với:

• Ít handoff hơn.
• Ít hiểu nhầm hơn.
• Ít cuộc họp cần thiết để giữ mọi người cùng hướng.
• Ít tầng giao tiếp.
• Quyết định nhanh hơn.

Kinh tế học của software đôi khi khá ngược đời theo cách đó.

Thêm người vào một dự án đang chậm có thể khiến dự án chậm hơn.

Và thêm developer junior vào một hệ thống phức tạp có thể khiến hệ thống trở nên mong manh hơn.

Chúng tôi đã nhìn thấy mô hình này nhiều lần

Chúng tôi từng làm việc với những CTO tìm đến sau khi một nỗ lực phát triển in-house bị đình trệ.

Chúng tôi cũng từng làm việc với những chủ doanh nghiệp đã mất niềm tin sau khi một agency hứa hẹn quá nhiều nhưng không thể đáp ứng.

Và mô hình thường lặp lại.

Vấn đề chưa bao giờ thực sự nằm ở công nghệ.

Vấn đề nằm ở cấu trúc bao quanh công nghệ.

Ai là người sở hữu các quyết định?

Ai gánh rủi ro khi có vấn đề xảy ra?

Và ai có động lực để hoàn thành dự án, thay vì tìm cách kéo dài dự án?

Trải nghiệm hợp tác thực tế sẽ như thế nào?

Tôi muốn nói về điều này một cách thực tế, bởi phiên bản trong brochure chưa bao giờ là phiên bản hữu ích nhất.

Mọi thứ bắt đầu bằng một cuộc trao đổi, nơi chúng tôi có thể phản biện bạn nhiều không kém số lần chúng tôi đồng ý với bạn.

Nếu kế hoạch của bạn không hợp lý, chúng tôi sẽ nói điều đó trước khi nhận tiền, chứ không phải sau đó.

Chúng tôi bắt đầu bằng một phần công việc nhỏ, được xác định rõ ràng.

Mục tiêu là để bạn có thể đánh giá:

• Chất lượng code.
• Chất lượng giao tiếp.
• Cách đội ngũ xử lý vấn đề.
• Cách chúng tôi phối hợp với team của bạn.

...trước khi bạn quyết định cam kết với một chương trình lớn hơn.

Bởi một kế hoạch lớn đến đâu cũng không có ý nghĩa nếu hai tuần đầu tiên đã khiến bạn cảm thấy có điều gì đó không ổn.

Một đội ngũ thực sự coi sản phẩm của bạn là của chính họ

Khi dự án bắt đầu, bạn có một đội ngũ đối xử với sản phẩm của bạn như thể đó là sản phẩm của chính họ.

Điều đó có nghĩa là:

• Chủ động cảnh báo rủi ro ngay từ đầu thay vì che giấu chúng.
• Đặt những câu hỏi khó về scope thay vì âm thầm xây dựng sai thứ bạn cần.
• Thẳng thắn nói với bạn khi một tính năng bạn rất thích thực ra không đáng để đánh đổi bằng mức độ phức tạp mà nó tạo ra.

Những advisor chỉ nói với bạn những gì bạn muốn nghe không thực sự là advisor.

Họ chỉ là order taker.

Và về lâu dài, order taker là một lựa chọn rất đắt.

Sự thật về chuyển đổi số

Sự thật là chuyển đổi số hiếm khi thất bại vì công nghệ.

Nó thất bại vì bài toán kinh tế của sự tập trung và nguồn lực.

Dự án của bạn cần những người thực sự quan tâm đến nó, đủ senior để giải quyết những vấn đề khó, đồng thời có một mức chi phí đủ hợp lý để bạn có thể duy trì nỗ lực cho đến cuối cùng — thay vì phải dừng giữa chừng khi ngân sách cạn kiệt.

Đó chính là khoảng trống mà chúng tôi xây dựng DevVina để giải quyết.

Không phải lựa chọn rẻ nhất trên thị trường.

Cũng không phải lựa chọn hào nhoáng nhất.

Mà là một phương án cân bằng hợp lý — thứ mà nhiều người cho rằng không tồn tại, bởi họ đã từng trải qua một trong hai thái cực.

In-house có thể quá đắt và quá chậm để mở rộng.

Agency lớn có thể quá tốn kém và thiếu tập trung.

Chúng tôi xây dựng một mô hình đặt roadmap của bạn làm trọng tâm, với cấu trúc chi phí giúp bạn không phải lựa chọn giữa chất lượng và một ngân sách hợp lý.

Hãy bắt đầu bằng vấn đề, không phải giải pháp

Nếu những điều trên khiến bạn thấy quen thuộc, bước tiếp theo rất đơn giản.

Hãy gửi cho chúng tôi một vài thông tin về vấn đề bạn đang cố gắng giải quyết, thay vì giải pháp mà bạn nghĩ mình cần.

Chúng tôi sẽ thẳng thắn cho bạn biết liệu DevVina có phải là đối tác phù hợp hay không.

Và nếu không phù hợp, chúng tôi sẽ giới thiệu cho bạn một hướng đi khác.

Đó là lời cam kết chúng tôi có thể đưa ra bởi mô hình kinh doanh của chúng tôi được xây dựng dựa trên niềm tin, chứ không phải việc phải chốt bằng được một hợp đồng.

Bạn đã dành đủ thời gian để quản lý vendor.

Và cũng đã chi đủ tiền cho những tiến độ không thực sự mang lại kết quả lâu dài.

Có một lựa chọn khác:

Một đội ngũ hoạt động như phần mở rộng của chính team bạn, với một mức chi phí đủ hợp lý để bạn có thể hoàn thành những gì mình đã bắt đầu.

Hãy cho chúng tôi biết vấn đề bạn đang muốn giải quyết.

Chúng tôi sẽ đưa ra đánh giá thẳng thắn về mức độ phù hợp — ngay cả khi điều đó có nghĩa là khuyên bạn tìm một đối tác khác.

#DigitalTransformation #SoftwareDevelopment #CTOInsights #DevVina

Liên hệ trực tiếp với chúng tôi tại DevVina hoặc gửi vấn đề bạn đang gặp phải cho đội ngũ của chúng tôi để nhận được câu trả lời thẳng thắn về scope, timeline và ngân sách.