Bất kỳ Engineering Manager nào từng tìm kiếm một đội ngũ offshore đều đã nghe cùng một lời cảnh báo hàng trăm lần: Giá rẻ đồng nghĩa với chất lượng thấp. Ngân sách hạn hẹp chỉ giúp bạn có một bản demo trông khá ổn, rồi một codebase sụp đổ ngay trong tuần sau khi ra mắt.
Lời cảnh báo đó thường đúng, và tôi tôn trọng nó, bởi phần lớn thời gian, thị trường sẽ trả lại cho bạn đúng thứ bạn bỏ tiền ra mua.
Nhưng phương trình đó chỉ đúng khi giá cả là biến số duy nhất bạn đem ra so sánh.
Tại DevVina, chúng tôi thực hiện một cách tiếp cận khác. Mức giá của chúng tôi thấp hơn đáng kể so với một đội ngũ tại Silicon Valley, và chúng tôi không cố che giấu điều đó. Đó là phần thành thật trong cách chúng tôi giới thiệu dịch vụ.
Điều chúng tôi không chấp nhận là giả định rằng một con số thấp hơn trên hóa đơn nhất thiết phải dẫn đến phần mềm lỗi, code khó đọc hoặc một đội ngũ biến mất lúc sáu giờ tối.
Hai thứ đó — giá cả và chất lượng — thực ra không nhất thiết phải đi cùng nhau.
Và mỗi ngày, chúng tôi dành toàn bộ nỗ lực để chứng minh điều đó.
Cách chúng tôi làm được điều này khá đơn giản, và chính vì đơn giản nên nó hiệu quả.
Không có phép màu nào trong quy trình của chúng tôi. Không có framework độc quyền nào mà chúng tôi giữ kín như một bí mật.
Có một tiêu chuẩn tuyển dụng, một văn hóa code review và một tập hợp các thói quen kỹ thuật mà chúng tôi coi là không thể thỏa hiệp.
Khách hàng không mua những giờ làm việc giá rẻ từ chúng tôi.
Họ mua cùng một mức độ kỷ luật mà họ kỳ vọng ở một đội ngũ nội địa đắt tiền, được cung cấp với một phần nhỏ chi phí — bởi cơ cấu chi phí của chúng tôi khác biệt, chứ không phải vì tiêu chuẩn của chúng tôi thấp hơn.
Hãy bắt đầu từ con người, bởi nếu chọn sai người thì mọi thứ khác đều không còn ý nghĩa.
Chúng tôi phỏng vấn để tìm chiều sâu về chuyên môn, chứ không tìm khả năng đọc thuộc lòng những câu trả lời từ một bộ tài liệu luyện phỏng vấn.
Một ứng viên có thể giải thích tại sao một hệ thống bị lỗi và họ đã thay đổi điều gì sau đó sẽ được đánh giá cao hơn một ứng viên có thể ghi nhớ mọi design pattern trong sách.
Chúng tôi tìm kiếm những kỹ sư từng làm hỏng hệ thống production và dám chịu trách nhiệm xử lý hậu quả.
Những “vết sẹo” kinh nghiệm đó đáng giá hơn bất kỳ chứng chỉ nào.
Quy trình sàng lọc của chúng tôi được thiết kế có chủ đích để tạo áp lực.
Chúng tôi đặt ứng viên trước một hệ thống đang hoạt động và yêu cầu họ phân tích một vấn đề thực tế ngay tại thời điểm đó, trong khi các kỹ sư của chúng tôi quan sát và đặt câu hỏi.
Chúng tôi không quan tâm đến câu trả lời đầu tiên.
Chúng tôi quan tâm đến điều gì xảy ra khi câu trả lời đầu tiên đó sai.
Người đó có giữ được bình tĩnh không?
Họ có đặt đúng câu hỏi không?
Họ có điều chỉnh lại cách nhìn nhận vấn đề không?
Hay họ bị khựng lại và tiếp tục đoán?
Chỉ một quan sát đó đã cho chúng tôi nhiều thông tin hơn cả một giờ hỏi đáp kiến thức lý thuyết.
Kết quả là một đội ngũ nhỏ hơn các công ty outsourcing lớn, nhưng sắc bén hơn ở những điểm thực sự quan trọng.
Chúng tôi thà có mười kỹ sư có thể giữ cho một hệ thống production vận hành ổn định còn hơn có năm mươi người cần được giám sát liên tục.
Sự đánh đổi này đồng nghĩa với việc chúng tôi không thể nhận mọi dự án tìm đến mình.
Năng lực thực sự có giới hạn.
Nhưng những dự án chúng tôi nhận sẽ nhận được sự tham gia của các kỹ sư senior ngay từ tuần đầu tiên, chứ không phải đợi đội ngũ junior đào một cái hố rồi mới có người đến xử lý.
Kiến trúc là nơi các đội ngũ giá rẻ thường bộc lộ điểm yếu.
Cách dễ nhất là nối các service lại với nhau, sao chép một stack từ tutorial và tuyên bố thành công ngay khi luồng sử dụng cơ bản hoạt động.
Nhưng thất bại thực sự sẽ xuất hiện sau đó, dưới hình thức một hệ thống không thể kiểm thử, không thể mở rộng và không thể hiểu nổi đối với kỹ sư tiếp theo tiếp quản nó.
Chúng tôi xem kiến trúc là một quyết định về nợ kỹ thuật, và chúng tôi thành thật về chi phí của từng sự cắt giảm hay thỏa hiệp.
Khi ngồi xuống cùng khách hàng, chúng tôi không đưa cho họ một sơ đồ kiến trúc rồi coi như công việc đã hoàn tất.
Chúng tôi thảo luận trực tiếp về các đánh đổi.
Việc tách hệ thống thành microservice có thể mang lại khả năng triển khai độc lập, nhưng đổi lại là sự phức tạp trong vận hành và một cơn ác mộng khi debug nếu một request phải đi qua năm ranh giới service.
Một monolith có thể trông không đẹp mắt với một số người, nhưng lại có thể là lựa chọn đúng đắn cho một đội ngũ chỉ có bốn người.
Công việc của chúng tôi không phải là khoe một kiến trúc hào nhoáng.
Công việc của chúng tôi là chọn một kiến trúc không bóp nghẹt sản phẩm sau hai năm nữa.
Sự thành thật đó khá hiếm trong ngành này, và đôi khi nó khiến chúng tôi mất hợp đồng.
Chúng tôi từng mất những proposal vì nói với khách hàng rằng kế hoạch đầy tham vọng của họ cần một phiên bản đầu tiên đơn giản hơn, hoặc timeline họ đưa ra quá gấp so với tiêu chuẩn chất lượng mà họ yêu cầu.
Từ bỏ doanh thu chưa bao giờ là một thói quen dễ chịu.
Nhưng mọi dự án mà chúng tôi từ chối đều có thể đã trở thành một ví dụ điển hình cho câu chuyện “tại sao outsourcing giá rẻ lại thất bại”.
Và chúng tôi thà không mang danh tiếng đó chỉ vì muốn có thêm một hóa đơn.
Code review là một nơi khác mà các đội ngũ giá rẻ thường cắt giảm, bởi review tốn thời gian nhưng không tạo ra một tính năng hữu hình.
Chúng tôi xem đó là cuộc họp quan trọng nhất trong tuần.
Mọi pull request đều được ít nhất một kỹ sư không trực tiếp viết code đó đọc và review. Người review được kỳ vọng phải thách thức logic của code, chứ không chỉ kiểm tra format.
Chúng tôi có một nguyên tắc cố định rằng một comment trong code review là một món quà, và người nhận comment không được phép phản ứng phòng thủ.
Phải mất vài tháng để biến nguyên tắc đó thành một phần thực sự của văn hóa.
Nhưng chính nó là lý do codebase của chúng tôi vẫn dễ đọc khi hệ thống ngày càng lớn.
Chúng tôi cũng viết test, và chúng tôi không xin lỗi vì điều đó.
Một khách hàng trả tiền theo giờ có thể nhìn việc viết test như một khoản overhead — thời gian được sử dụng mà không trực tiếp tạo ra tính năng mới.
Chúng tôi nhìn nó như một khoản bảo hiểm.
Một bộ test chạy trong vài phút và phát hiện regression trước khi nó đến tay người dùng chắc chắn rẻ hơn việc phát hiện chính lỗi đó trên production vào một ngày thứ Bảy.
Chúng tôi đã giải thích sự đánh đổi này nhiều lần đến mức không thể đếm nổi.
Và chúng tôi vẫn tiếp tục giải thích, bởi những kỹ sư bỏ qua test để trông có vẻ nhanh chính là những người cuối cùng lại làm mọi thứ chậm hơn.
Documentation cũng được đối xử theo cách tương tự.
Không ai thích viết tài liệu, và đó thường là thứ đầu tiên bị gạt sang một bên khi deadline đến gần.
Chúng tôi xem một hệ thống không có tài liệu là một hệ thống chưa hoàn thiện.
Điều đó không có nghĩa là chúng tôi viết hàng trăm trang văn bản mà chẳng ai đọc.
Nó có nghĩa là code có comment rõ ràng ở những phần logic không hiển nhiên, có runbook cho việc triển khai và khôi phục hệ thống, đồng thời các quyết định kiến trúc đều có lý do được ghi lại để người tiếp theo không phải tự mình reverse-engineer cách chúng tôi đã suy nghĩ.
Các kỹ sư trong tương lai cũng là một stakeholder, dù chúng ta không nhìn thấy họ. Và chúng tôi vẫn xây dựng hệ thống cho họ.
Hãy để tôi nói thẳng về những gì chúng tôi không phải.
Chúng tôi không phải lựa chọn rẻ nhất tại Việt Nam, và chúng tôi cũng không cố trở thành lựa chọn đó.
Nếu điều duy nhất bạn quan tâm là mức giá theo giờ thấp nhất có thể, có những đội ngũ sẽ đưa ra mức giá thấp hơn chúng tôi, và có lẽ bạn nên thuê họ nếu giá là tiêu chí duy nhất của bạn.
Chúng tôi nằm ở phân khúc trung bình và bảo vệ vị trí đó bằng chính chất lượng công việc.
Điều chúng tôi mang lại là một kết quả có thể dự đoán được: code được triển khai, vận hành ổn định và có thể được duy trì bởi một người khác chứ không chỉ người đã viết ra nó.
Chúng tôi cũng thành thật về những tình huống mà mô hình chi phí thấp thực sự gặp khó khăn.
Khi một dự án cần được hỗ trợ 24/7 xuyên qua ba múi giờ, một đội ngũ senior nhỏ sẽ bất lợi so với một tổ chức lớn có lực lượng nhân sự đông đảo.
Khi khách hàng cần tuyển bổ sung một trăm kỹ sư chỉ trong một tháng, chúng tôi không thể làm được điều đó.
Và chúng tôi sẽ nói thẳng điều đó ngay từ đầu thay vì nhận hợp đồng rồi không đáp ứng được.
Biết rõ giới hạn của mình là một phần của sự tự tin mà chúng tôi mang đến cho khách hàng.
Một nhà cung cấp tuyên bố rằng họ có thể làm mọi thứ là một nhà cung cấp chưa từng thực sự vận hành một dự án triển khai đúng nghĩa.
Điều chúng tôi làm tốt nhất là những dự án mà khả năng phán đoán quan trọng hơn số lượng nhân sự.
Một nền tảng có bài toán concurrency phức tạp.
Một dự án migration từ hệ thống legacy, nơi mô hình dữ liệu chứa đầy những bất ngờ.
Một sản phẩm mà phiên bản đầu tiên phải làm đúng ngay từ đầu bởi thị trường sẽ không tha thứ cho một lần ra mắt lỗi.
Trong những tình huống đó, một nhóm nhỏ các kỹ sư senior thực sự hiểu về distributed systems và các giới hạn của database sẽ luôn vượt trội so với một đội ngũ lớn gồm các kỹ sư junior.
Và họ có thể làm điều đó với chi phí chỉ bằng một phần nhỏ so với một công ty phương Tây.
Các kỹ sư trong đội ngũ của chúng tôi có những nền tảng kinh nghiệm thực sự đáng giá.
Một số người trong chúng tôi đã dành nhiều năm làm việc tại các công ty phát triển sản phẩm lớn, nơi chúng tôi học được production-grade thực sự có nghĩa là gì — theo cách khó nhất: trực tiếp on-call khi hệ thống gặp sự cố.
Kinh nghiệm đó không xuất hiện trên bảng báo giá.
Nó xuất hiện khi hệ thống của khách hàng bắt đầu lỗi lúc 3 giờ sáng và kỹ sư trực on-call đã từng gặp chính xác loại lỗi này ở một dự án khác, trong một “cuộc đời” khác, và biết cách xử lý mà không cần mất năm giờ điều tra.
Bạn không thể mua loại khả năng nhận diện vấn đề này với giá rẻ ở bất kỳ đâu.
Và chúng tôi thành thật rằng đó mới chính là thứ khách hàng thực sự đang trả tiền để có được.
Chúng tôi đo lường thành công của mình bằng việc khách hàng phải trải qua ít drama đến mức nào.
Một dự án yên ắng, nơi các lần deployment diễn ra mà không có sự cố và cuộc họp trạng thái hằng tuần kết thúc nhanh vì chẳng có gì phải tranh cãi — đó là một dự án thành công đối với chúng tôi.
Một số đội ngũ muốn trông thật bận rộn và liên tục tạo ra cảm giác cấp bách để khách hàng cảm thấy họ đang nhận được nhiều giá trị.
Chúng tôi thà nhàm chán nhưng đáng tin cậy.
Nếu bạn gần như không bao giờ phải nghĩ đến chúng tôi, điều đó có nghĩa là chúng tôi đã làm tốt công việc của mình.
Giao tiếp là lĩnh vực mà các đội ngũ offshore thường thất bại nhất, và điều đó không liên quan gì đến năng lực.
Nó liên quan đến động lực.
Một đội ngũ sợ phải đưa ra tin xấu sẽ che giấu một deadline đang bị trễ cho đến khi không còn đủ thời gian để cứu vãn.
Chúng tôi xây dựng một văn hóa trong đó việc đưa vấn đề ra ánh sáng sớm được khuyến khích thay vì bị trừng phạt.
Khi một kỹ sư nhận ra rằng ước tính ban đầu của mình là sai, chúng tôi muốn thông tin đó được đưa ra ngay trong ngày, kèm theo các phương án xử lý — chứ không phải một tháng sau cùng với lời xin lỗi.
Bất kỳ Engineering Manager nào đọc đến đây cũng hiểu chính xác hành vi đó hiếm và có giá trị đến mức nào.
Đây là cách chúng tôi nhìn nhận bài toán chi phí một cách thực tế.
Một đội ngũ chất lượng cao ở Bắc Mỹ hoặc Tây Âu sẽ có mức giá cao, phản ánh thị trường nơi họ hoạt động.
Một đội ngũ chất lượng thấp ở bất kỳ quốc gia nào có thể khiến bạn tốn ít tiền hơn lúc đầu, nhưng sau đó sẽ “rút cạn” ngân sách của bạn thông qua việc làm lại, các lần ra mắt bị bỏ lỡ và những chi phí vô hình khi chính các kỹ sư của bạn phải dành thời gian giám sát nhà cung cấp.
Ở đâu đó giữa hai thái cực đó là một đội ngũ tính mức giá hợp lý so với thị trường của họ nhưng tự đặt ra tiêu chuẩn kỹ thuật tương đương với những công ty đắt tiền.
Đó là vị trí chúng tôi lựa chọn.
Và chúng tôi tin đây là giá trị tốt nhất trong ngành — không phải vì chúng tôi tự nói như vậy, mà bởi khách hàng liên tục quay lại để thực hiện dự án thứ hai.
Chúng tôi không yêu cầu bạn phải tin lời chúng tôi.
Hãy đặt những câu hỏi khó.
Hãy hỏi chúng tôi xử lý deadline bị trễ như thế nào.
Hãy hỏi quy trình code review thực sự diễn ra ra sao.
Hãy hỏi chúng tôi kiểm thử như thế nào.
Và hãy hỏi điều gì xảy ra nếu một kỹ sư của chúng tôi rời dự án giữa chừng.
Đó là những câu hỏi phân biệt một đối tác kỹ thuật thực sự với một body shop, và chúng tôi sẵn sàng trả lời tất cả một cách chi tiết.
Một đội ngũ không thể trả lời những câu hỏi đó mà không vòng vo là một đội ngũ bạn không nên thuê, bất kể giá của họ là bao nhiêu.
Mức giá thấp chỉ thực sự là một món hời nếu chất lượng vẫn được đảm bảo.
DevVina được xây dựng dựa trên một niềm tin mạnh mẽ rằng hai điều đó hoàn toàn có thể cùng tồn tại.
Và chúng tôi có những “vết sẹo” kinh nghiệm cùng những khách hàng quay lại để chứng minh điều đó.
Bằng chứng không nằm trong hoạt động marketing của chúng tôi.
Nó nằm trong những hệ thống chúng tôi xây dựng và cách chúng tôi hành xử khi có sự cố xảy ra.
Đó là tiêu chuẩn chúng tôi đặt ra cho chính mình.
Và đó cũng là tiêu chuẩn chúng tôi sẽ áp dụng cho dự án của bạn.
Chúng tôi muốn cho bạn thấy điều đó diễn ra như thế nào trên thực tế.
Hãy cho chúng tôi biết bạn đang xây dựng điều gì, và để chúng tôi cho bạn thấy một đội ngũ senior tinh gọn sẽ tiếp cận dự án đó như thế nào.
#SoftwareEngineering #DevVina #TechLeadership #OffshoreDevelopment #EngineeringExcellence
