Làm "24 giờ mỗi ngày" giữa Hà Nội và Kraków mà tính năng vẫn chậm hơn: thiết kế bàn giao follow-the-sun cho đội phân tán

Tình huống minh hoạ

Tình huống và số liệu dưới đây là giả định, dùng để minh hoạ.

Một công ty phần mềm có đội phát triển 7 người ở Hà Nội và đội 5 người ở Kraków (Ba Lan), cùng làm nền tảng quản lý kho cho một khách hàng bán lẻ. Mùa hè, Kraków chậm hơn Hà Nội 5 giờ. Giám đốc điều hành đề xuất: "Hà Nội làm xong buổi chiều thì Kraków làm tiếp, sáng hôm sau Hà Nội nhận lại — mỗi ngày ta có gần 13 giờ phát triển thay vì 8." Mô hình này được gọi là follow-the-sun (FTS): công việc được một địa điểm sở hữu và đẩy tiến độ, cuối ngày bàn giao cho địa điểm ở múi giờ kế tiếp.

Sau ba tuần áp dụng, bảng theo dõi cho thấy điều ngược lại:

• Thời gian chu kỳ (cycle time) trung bình của một hạng mục tăng từ 4,2 lên 5,1 ngày.
• 40% các lần bàn giao có ít nhất một câu hỏi "treo" — người nhận không hiểu trạng thái, phải chờ người giao trả lời vào sáng hôm sau.
• Hai lần, Kraków sửa lại đúng đoạn mã mà Hà Nội đã sửa theo hướng khác, vì ghi chú bàn giao chỉ có một dòng "đang xử lý lỗi đồng bộ tồn kho".
• Thành viên hai bên bắt đầu dùng cụm "việc thừa kế" để nói về hạng mục nhận từ phía kia, với thái độ không mấy thiện cảm.

PM được yêu cầu "hoặc làm cho FTS chạy, hoặc chứng minh nó không phù hợp".

Phân tích theo PMBOK® Guide

Follow-the-sun là một lựa chọn về cách tổ chức đội, không phải mặc định

Nghiên cứu của Carmel, Espinosa và Dubinsky (Journal of Management Information Systems, 2010) nhận xét FTS hấp dẫn về lý thuyết nhưng có rất ít trường hợp thành công được ghi nhận trong thực tế, chính vì nó khó triển khai. Kết luận then chốt: thời gian dự án chỉ giảm khi phần tiết kiệm được nhờ ít phối hợp trong nội bộ địa điểm và năng suất cá nhân lớn hơn phần chi phí phối hợp giữa các địa điểm tăng thêm. Nói cách khác, mỗi lần bàn giao là một "khoản thuế" — nếu thuế cao hơn lợi ích của giờ làm thêm thì FTS làm chậm dự án.

Trong PMBOK® Guide ấn bản 7, lĩnh vực hiệu suất Đội ngũ (Team) và Cách tiếp cận phát triển & vòng đời (Development Approach and Life Cycle) đều nhấn mạnh việc thiết kế cách làm việc phù hợp với bối cảnh (tailoring). Ấn bản 6 xếp việc này vào Plan Resource Management (9.1) — xác định cách đội được tổ chức — và Manage Communications (10.2).

Vì sao bàn giao thất bại

Phân tích các lần bàn giao lỗi, PM thấy ba nguyên nhân gốc:

1. Hạng mục quá lớn và mơ hồ: một câu chuyện người dùng 5 ngày bị chia đôi giữa chừng, người nhận không biết "xong" ở đâu.