Chi phí vận hành ẩn trong hoạt động outsourcing
Hãy thử nghĩ xem điều gì thực sự đang chiếm lấy phần lớn thời gian trong một tuần của bạn.
Bạn viết một bản đặc tả (spec), rồi phải trả lời mười câu hỏi để làm rõ yêu cầu. Bạn liên tục theo dõi tiến độ. Bạn review một phần công việc không đúng với những gì mình yêu cầu, vì vậy lại phải viết lại brief và tiếp tục chờ đợi.
Bạn phải điều phối múi giờ, quyền truy cập công cụ và các điều khoản thanh toán.
Đến khi một tính năng được đưa vào production, bạn nhận ra mình đã dành nhiều thời gian trong lịch làm việc của chính mình cho việc điều phối hơn cả thời gian developer dành để xây dựng tính năng đó.
Phần chi phí này không xuất hiện trên hóa đơn.
Và chính vì thế, nó mới gây tổn thất lớn.
Bạn lập ngân sách dựa trên mức giá theo giờ hoặc báo giá cố định, nhưng gần như không ai tính đến sự tập trung và thời gian của founder.
Trong khi đó, sự tập trung lại là tài nguyên khan hiếm nhất mà một startup có.
Operational overhead thực sự nằm ở đâu?
Khi chúng tôi tại DevVina nói về việc giảm operational overhead, chúng tôi không nói đến việc giảm vài đô la trong bảng giá.
Chúng tôi đang nói đến những công việc không bao giờ xuất hiện trên timesheet:
- Trao đổi qua lại.
- Giải thích lại cùng một vấn đề.
- Điều chỉnh lại scope.
- Liên tục theo sát và nhắc nhở đội ngũ.
Outsourcing về bản chất phải giúp bạn loại bỏ những gánh nặng này.
Nhưng quá thường xuyên, nó chỉ đơn giản là chuyển gánh nặng đó từ vị trí này sang vị trí khác.
Giải pháp không phải là tìm một nhà cung cấp rẻ hơn.
Giải pháp là một quy trình bàn giao và phối hợp tốt hơn.
Hãy để tôi chỉ ra cụ thể overhead thực sự ẩn ở đâu, bởi phần lớn nó nằm trong khoảng cách giữa điều bạn muốn truyền đạt và những gì bạn thực sự viết ra.
1. Specification – Đặc tả yêu cầu
Một requirement mơ hồ chính là một cỗ máy tạo ra những cuộc họp follow-up.
Nếu đội ngũ phải đoán xem bạn thực sự muốn gì, họ sẽ đặt câu hỏi.
Và mỗi câu hỏi như vậy đều khiến bạn phải context switch.
Những đội ngũ vận hành tinh gọn không nhất thiết phải viết những tài liệu dài hơn.
Họ viết những tài liệu sắc nét hơn, với acceptance criteria rõ ràng và một hoặc hai edge case quan trọng – những trường hợp rất dễ khiến hệ thống gặp lỗi.
Một đối tác tốt sẽ phản biện một yêu cầu chưa rõ ràng trước khi bắt đầu coding, chứ không phải sau khi code đã được viết.
Sự phản biện đó có thể tạo cảm giác như một sự cản trở ở thời điểm ban đầu.
Nhưng thực tế, nó không phải friction.
Đó là dạng feedback rẻ nhất mà bạn có thể nhận được.
Bởi nó xảy ra trước khi một dòng code nào được viết.
2. Communication cadence – Nhịp độ giao tiếp
Daily standup nghe có vẻ rất năng suất.
Nhưng trong phần lớn trường hợp, chúng không thực sự tạo ra nhiều giá trị tương ứng với thời gian bỏ ra.
Đó là một loại meeting tax mà bạn phải trả chỉ để nghe ai đó nói:
“Vẫn đang bị block bởi X.”
...trong ngày thứ ba liên tiếp.
Điều thực sự giúp giảm overhead là:
- Các bản cập nhật asynchronous.
- Được gửi vào một thời điểm cố định.
- Có quy tắc rõ ràng rằng mọi blocker phải được escalate ngay trong ngày.
Bạn nên có khả năng rời khỏi máy tính trong một buổi chiều và khi quay lại, bạn chỉ cần đọc một bản tóm tắt bằng văn bản để biết chuyện gì đã xảy ra.
Không phải mở một inbox đầy missed calls và tin nhắn chưa xử lý.
Mục tiêu là làm cho tiến độ trở nên rõ ràng mà không biến inbox của bạn thành project tracker.
3. Scope discipline – Kiểm soát phạm vi
Scope creep thường được nhìn nhận như lỗi của khách hàng.
Và đôi khi đúng là như vậy.
Nhưng cũng không ít trường hợp scope creep xuất phát từ chính developer, khi họ tự xây dựng thêm một số thứ vì nghĩ rằng nó sẽ hữu ích.
Helpful không có nghĩa là miễn phí.
Mỗi feature không được yêu cầu đều là:
- Code bạn không yêu cầu.
- Chi phí bạn không lập ngân sách.
- Và một phần hệ thống mà bạn sẽ phải bảo trì trong suốt vòng đời sản phẩm.
Một mô hình hợp tác có operational overhead thấp cần có một quy trình thay đổi cố tình được thiết kế để trở nên... nhàm chán.
Yêu cầu mới phải được:
- Ghi nhận.
- Đánh giá chi phí.
- Lên lịch triển khai.
Thay vì âm thầm được đưa vào sprint hiện tại.
Trong trường hợp này:
Nhàm chán chính là một tính năng.
4. Handover – Bàn giao sau khi hoàn thành
Rất nhiều dự án không thực sự kết thúc khi được delivery.
Chúng chết dần sau khi bàn giao, bởi không ai thực sự chịu trách nhiệm cho quá trình chuyển tiếp.
Documentation nằm trong một shared drive mà chẳng ai đọc.
Credentials nằm rải rác ở nhiều nơi.
Người xây dựng hệ thống đã rời đi.
Và người tiếp theo phải reverse-engineer lại toàn bộ hệ thống để hiểu nó hoạt động như thế nào.
Một quy trình handover sạch sẽ, với documentation dễ đọc và một buổi bàn giao ngắn, có thể giúp đội ngũ tương lai tiết kiệm hàng tuần làm việc.
Rất dễ bỏ qua bước này khi ngân sách đã cạn.
Nhưng bỏ qua nó chính là cách bạn trả cho cùng một chi phí hai lần về sau.
Outsourcing tốt sẽ giảm overhead. Outsourcing tệ sẽ tạo ra một loại overhead mới.
Đây là phần chúng tôi muốn nói một cách thẳng thắn.
Outsourcing được thực hiện tốt sẽ loại bỏ operational overhead.
Nhưng outsourcing được thực hiện kém sẽ tạo ra một loại overhead hoàn toàn mới.
Sự đánh đổi là có thật.
Và giả vờ rằng nó không tồn tại sẽ chẳng giúp ích cho bất kỳ ai.
Một đội ngũ remote không thể đọc được suy nghĩ của bạn.
Và không có quy trình nào có thể giải quyết hoàn toàn vấn đề đó.
Bạn vẫn luôn phải đầu tư một khoảng thời gian ban đầu để định hướng cho đội ngũ.
Bạn cũng luôn phải chịu một phần chi phí để chuyển tải bối cảnh kinh doanh của mình đến những người đang xây dựng sản phẩm cho bạn.
Điều mà một đối tác tốt có thể làm là thu nhỏ chi phí này xuống một mức nhỏ và có thể dự đoán được, thay vì để nó tăng lên theo từng sprint.
Luôn có một giai đoạn làm quen
Cũng cần thừa nhận rằng sẽ luôn tồn tại một khoảng thời gian điều chỉnh.
Lần hợp tác đầu tiên với bất kỳ đội ngũ mới nào đều có một learning curve.
Những shorthand mà team nội bộ của bạn sử dụng, những đặc thù của sản phẩm, mức độ chấp nhận sự chưa hoàn hảo của bạn — không có thứ nào trong số đó tự động được chuyển giao sang một đội ngũ mới.
Một số founder có thể cảm thấy những tuần đầu tiên thậm chí còn chậm hơn so với việc tự triển khai in-house.
Điều đó hoàn toàn bình thường.
Giá trị thực sự xuất hiện về sau, khi gánh nặng quản lý hàng tuần vẫn giữ nguyên trong khi roadmap của bạn tiếp tục mở rộng.
Không phải mọi thứ đều nên outsource
Bạn cũng nên giữ lại một số phần việc trong nội bộ.
Nếu lợi thế cạnh tranh cốt lõi của doanh nghiệp nằm ở một phần mềm mà bạn sẽ liên tục cải tiến mỗi ngày trong nhiều năm, thì đó có thể không phải là thứ nên giao cho bên ngoài.
Mô hình outsourcing tốt nhất không phải là mô hình đưa mọi thứ ra bên ngoài.
Mà là mô hình đưa những phần việc được xác định rõ ràng và có tính độc lập cao ra bên ngoài.
Nhờ đó, đội ngũ nội bộ có thể tập trung vào phần khiến doanh nghiệp của bạn khó bị sao chép.
Biết được ranh giới đó quan trọng không kém việc biết mình nên chọn vendor nào.
Hãy xem outsourcing như một quyết định về sản phẩm
Qua quá trình làm việc với các startup và SME, chúng tôi nhận thấy những founder làm outsourcing hiệu quả thường xem mối quan hệ này như một product decision, chứ không phải một procurement decision.
Họ không đơn giản chọn một nhà cung cấp rồi hy vọng mọi thứ sẽ ổn.
Ngay từ đầu, họ xác định rõ operating model:
- Ai có quyền phê duyệt thay đổi?
- Quy trình escalation như thế nào?
- Khi nào một công việc được xem là “done”?
- Bao lâu đội ngũ cập nhật một lần?
- Cập nhật dưới hình thức nào?
Họ viết những quy tắc đó xuống.
Và yêu cầu cả hai bên cùng tuân thủ.
Nhiều process hơn nhưng ít overhead hơn
Nghe có vẻ như bạn đang thêm process chứ không phải giảm process.
Trong ngắn hạn, đúng là như vậy.
Nhưng trong trung hạn, chính điều đó cho phép bạn không phải liên tục suy nghĩ về đội ngũ đang outsource.
Và đó mới chính là mục tiêu.
Những founder phàn nàn về operational overhead khi outsourcing thường là những người đã bỏ qua bước thiết lập operating model ngay từ đầu.
Sau đó họ phải dành toàn bộ dự án để ứng biến và xử lý từng vấn đề phát sinh.
Bắt đầu với một engagement nhỏ
Một điều khác cũng rất hiệu quả là đánh giá quy mô của engagement đầu tiên một cách thực tế.
Một proof of concept nhỏ, với scope chặt chẽ, có thể cho bạn biết nhiều hơn về cách một team giao tiếp so với bất kỳ portfolio review nào.
Đây là cách ít rủi ro để kiểm tra:
- Họ có đặt đúng câu hỏi không?
- Họ có phát hiện và cảnh báo vấn đề sớm không?
- Các bản cập nhật của họ có thực sự cung cấp thông tin bạn cần không?
Nếu phần việc đầu tiên diễn ra suôn sẻ, bạn có thể tự tin mở rộng scope cho những phần tiếp theo.
Nếu không, ít nhất bạn cũng đã phát hiện ra vấn đề với một chi phí thấp.
Dù kết quả thế nào, bạn vẫn tốn ít overhead hơn rất nhiều so với việc cam kết một hợp đồng kéo dài một năm với một đối tác chưa từng làm việc cùng.
Đừng chỉ nhìn vào giá. Hãy nhìn vào thứ bạn thực sự đang trả tiền để nhận được.
Bạn cũng cần xem xét mình đang trả tiền cho điều gì, chứ không chỉ xem mình đang trả bao nhiêu.
Một mức hourly rate cao hơn một chút nhưng đi kèm:
- Một đầu mối liên hệ rõ ràng.
- Báo cáo hàng tuần bằng văn bản.
- Quy trình thay đổi hoạt động hiệu quả.
...thường có thể rẻ hơn về tổng thể so với một mức giá hấp dẫn nhưng biến bạn thành de facto project manager.
Hãy cộng số giờ bạn phải bỏ ra với giá trị thời gian của chính bạn.
Thông thường, phép tính sẽ tự đưa ra câu trả lời.
Thời gian của bạn không miễn phí.
Và mỗi giờ bạn dành để “chăn” một vendor là một giờ bạn không dành cho khách hàng hoặc sản phẩm.
Không cần một công cụ hay methodology đặc biệt
Không điều gì trong số này yêu cầu một công cụ cụ thể hay một methodology cụ thể.
Điều cần thiết là:
Một sự thống nhất về nơi operational overhead đang phát sinh, và sự sẵn sàng thiết kế lại quy trình để loại bỏ nó.
Những đội ngũ vận hành tinh gọn không nhất thiết có dashboard đẹp hơn.
Họ có:
- Những thỏa thuận rõ ràng hơn.
- Ít cuộc họp hơn.
- Nhưng mỗi cuộc họp đều có chất lượng cao hơn.
Nếu outsourcing khiến bạn cảm thấy như đang có thêm một công việc thứ hai
Nếu mô hình outsourcing hiện tại khiến bạn cảm thấy mình đang có thêm một công việc thứ hai chỉ để quản lý vendor, thì đó là một vấn đề có thể giải quyết.
Nó không phải một trạng thái cố định.
Câu trả lời hiếm khi là làm việc chăm chỉ hơn để điều phối.
Câu trả lời là thay đổi cấu trúc để có ít thứ cần phải điều phối hơn.
Hãy bắt đầu từ dự án tiếp theo, dù quy mô nhỏ đến đâu.
Trước khi viết code, hãy xác định quy trình xử lý thay đổi.
Trước khi sprint đầu tiên bắt đầu, hãy quyết định bạn muốn nhận update như thế nào.
Trước khi delivery, hãy xác định rõ ai là người chịu trách nhiệm cho handover.
Bốn quyết định đó sẽ giúp giảm operational overhead nhiều hơn bất kỳ khoản discount nào bạn có thể thương lượng.
Đó chính là mô hình outsourcing mà DevVina hướng tới
Đây chính là mô hình outsourcing mà chúng tôi xây dựng tại DevVina.
Và đó cũng là lý do chúng tôi đưa operating model lên bàn ngay từ cuộc trò chuyện đầu tiên.
Giảm “coordination tax”, và chi phí thực sự của việc phát triển phần mềm cũng giảm theo — ở loại tiền tệ duy nhất thực sự quan trọng: thời gian và sự tập trung của bạn.
Nếu khối lượng quản lý bạn phải bỏ ra đang lớn hơn cả ngân sách dành cho development, hãy chia sẻ với chúng tôi lần handoff gần nhất của bạn đã diễn ra như thế nào.
Chúng tôi sẽ chỉ ra cho bạn operational overhead đã thất thoát ở đâu.
#outsourcing #startuplife #devvina #softwaredevelopment
