Chốt phạm vi dự án FDE: ba phép thử tách scope creep khỏi discovery

Thử hình dung bạn đang ở tuần thứ ba của một dự án. Agent đọc hóa đơn mà bạn deploy cho khách đã chạy trên dữ liệu thật, và trưởng phòng vận hành bên họ rất hài lòng. Rồi chị hỏi thêm: “Tiện thì cho nó đối chiếu luôn với hợp đồng nhà cung cấp nhé, chắc không mất nhiều đâu.”

Câu hỏi kiểu này quyết định số phận của khá nhiều dự án FDE. Gật đầu thì có khi bạn vừa nhận thêm hai tuần việc không ai trả tiền. Lắc đầu thì có khi bạn vừa đóng lại đúng cánh cửa khách mở ra để bạn hiểu vấn đề của họ sâu hơn.

Chương này dạy cách trả lời câu hỏi đó một cách có căn cứ, thay vì dựa vào cảm giác hay sự ngại ngùng.

Vì sao FDE không thể chỉ đóng băng SOW?

Theo mô tả trên blog của Tandem, một FDE dành khoảng nửa thời gian ngồi với khách để hiểu vấn đề, nửa còn lại để xây giải pháp cho chính khách đó. Với cách làm này, chuyện yêu cầu thay đổi giữa chừng là bình thường, vì chính việc ngồi cạnh khách sinh ra hiểu biết mới.

Cũng vì thế mà cách xử lý quen thuộc của ngành dịch vụ chuyên nghiệp, tức đóng băng SOW và tính phí mọi thay đổi, theo Tandem là không hợp với công việc FDE. Nhưng làm ngược lại cũng nguy hiểm không kém, và cả hai hướng sai đều có hậu quả rất cụ thể.

Nếu gọi mọi thay đổi là “discovery”, dự án với khách đó sẽ phải ôm dần những khối việc không ai định giá, cho đến khi hết biên lợi nhuận và ngày go-live bị lùi. Nếu gọi mọi thay đổi là scope creep, bạn biến khách thành người dùng một sản phẩm chuẩn hóa, trong khi họ chọn bạn chính vì bạn sẽ xây riêng cho họ.

Ba câu hỏi thay cho cảm giác

Tandem đề xuất một bộ phép thử để thay cho câu hỏi “yêu cầu có đổi không”. Ba phép thử dưới đây đủ để xử lý ví dụ trong chương này.

Phép thử mục tiêu hỏi: yêu cầu mới làm rõ kết quả khách đã mua, hay thêm một kết quả mới? Phép thử điều chỉnh hỏi: yêu cầu có làm xê dịch thời gian, chi phí hay nguồn lực mà không có điều chỉnh tương ứng không?

Phép thử ghi chép hỏi: bạn có chỉ ra được cái gì đã được định phạm vi, đã được nói và đã được giao không?

Tandem khuyên chạy các phép thử với mọi yêu cầu tốn hơn một ngày công. Ngưỡng này hợp lý: việc nhỏ hơn cứ làm cho trơn tru, còn việc lớn hơn phải đi qua bộ lọc.

Phạm vi tốt được viết trước ngày đầu tiên

Phép thử ghi chép chỉ có tác dụng khi bạn có thứ để đối chiếu. Vì thế việc chặn scope creep bắt đầu từ lúc viết phạm vi, chứ không phải lúc yêu cầu mới xuất hiện.

Bài viết của TimeTackle nhấn mạnh rằng một SOW tốt phải ghi rành mạch, không nể nang, những gì bạn sẽ không làm. Danh sách ngoài phạm vi thường quan trọng không kém danh sách hạng mục bàn giao. Phạm vi đó nên được các bên liên quan ký duyệt trước khi bắt đầu.

Baytech Consulting bổ sung một mảnh nữa: mỗi tính năng và mỗi cột mốc cần có tiêu chí khách quan để xác nhận là “xong”.

Với dự án hóa đơn ở trên, bạn có thể viết: “Agent trích xuất đúng số tiền, ngày và mã nhà cung cấp trên tập hóa đơn mẫu do khách cung cấp; ngoài phạm vi: đối chiếu với hợp đồng, phê duyệt thanh toán, hóa đơn viết tay.”

Một ví dụ chạy từ đầu đến cuối

Giả sử trong cùng tuần, bạn nhận hai yêu cầu. Yêu cầu A: “Hóa đơn scan bị nghiêng thì agent đọc sai, sửa giúp.” Yêu cầu B: chính câu hỏi về đối chiếu hợp đồng ở đầu bài.

Với yêu cầu A, phép thử mục tiêu cho câu trả lời rõ: hóa đơn scan nghiêng vẫn nằm trong tập hóa đơn khách đưa, nên đây là làm rõ kết quả đã mua. Yêu cầu này có thể tốn vài ngày, nhưng nằm trong kế hoạch đạt tiêu chí “xong” đã ký, nên phép thử điều chỉnh cũng không báo động.

Phép thử ghi chép cũng ổn, vì tài liệu phạm vi nói rõ tập dữ liệu nào. Đây là discovery, cứ làm.

Yêu cầu B thì khác hẳn. Đối chiếu hợp đồng là một kết quả mới, nằm đúng trong danh sách ngoài phạm vi, và sẽ kéo lùi go-live nếu không có thêm thời gian hoặc người. Đây là scope creep, nhưng không có nghĩa là phải từ chối. Nó cần được đưa ra bàn và quyết định một cách công khai.

Quy trình kiểm soát thay đổi mà TimeTackle mô tả yêu cầu phân tích tác động lên thời gian, ngân sách và rủi ro kỹ thuật trước khi quyết định. Baytech thì cho mọi yêu cầu đi qua một biểu mẫu chuẩn và ghi lại kết quả: duyệt, từ chối hoặc hoãn sang giai đoạn sau. Ghép lại, sổ thay đổi của bạn có thể trông như sau:

Trường	Yêu cầu A	Yêu cầu B
Mô tả	Đọc hóa đơn scan nghiêng	Đối chiếu với hợp đồng nhà cung cấp
Phép thử mục tiêu	Làm rõ kết quả đã mua	Thêm kết quả mới
Phép thử điều chỉnh	Nằm trong kế hoạch đạt tiêu chí “xong”	Lùi go-live nếu không thêm nguồn lực
Phép thử ghi chép	Khớp tập dữ liệu đã ký	Có trong danh sách ngoài phạm vi
Tác động	Vài ngày, rủi ro thấp	Thời gian, ngân sách, rủi ro kỹ thuật cần ước lượng riêng
Quyết định	Duyệt, làm ngay	Hoãn sang giai đoạn 2, chờ khách xác nhận

Khi gửi bảng này, bạn không còn nói “không” với chị trưởng phòng. Bạn đang nói “được, đây là cái giá và đây là thời điểm”.

Ghi trong ngày, kể cả chỉ là một tin nhắn

Theo FDE Academy, FDE giỏi biến mọi thay đổi phạm vi đáng kể thành một bản tóm tắt ngắn bằng văn bản ngay trong ngày, kể cả khi chỉ là ghi chú không chính thức.

Một tin nhắn kiểu “Tóm tắt buổi họp chiều nay: phần đối chiếu hợp đồng sẽ để sang giai đoạn 2, bên mình sẽ gửi ước lượng vào thứ Hai, nhờ chị xác nhận” là đủ.

Lý do phải làm ngay nằm ở nợ kỹ thuật. Cũng theo FDE Academy, nợ kỹ thuật thường sinh ra khi phạm vi mở rộng bị âm thầm gánh lấy thay vì được thừa nhận. Dễ hình dung vì sao: khi phần việc thêm không được ai thừa nhận, hạn chót cũ vẫn giữ nguyên, và thứ còn co giãn được thường là chất lượng code.

Khi buộc phải đi đường tắt, hãy viết một câu ngay lúc đó về điều đã bỏ qua và lý do. Ví dụ: “Bỏ qua retry khi API kế toán timeout vì khách cần demo thứ Sáu; cần bổ sung trước go-live.” Một câu như thế cứu người tiếp quản, và đôi khi cứu chính bạn ba tháng sau.

Những lỗi hay gặp

Lỗi phổ biến nhất là chạy phép thử trong đầu mà không ghi ra, nên đến lúc tranh luận thì chẳng có gì để chỉ vào. Lỗi thứ hai là viết phạm vi chỉ có danh sách việc sẽ làm, bỏ trống phần ngoài phạm vi, khiến mọi yêu cầu mới đều có vẻ “chắc là trong phạm vi”.

Lỗi thứ ba là coi mọi thay đổi là kẻ thù. Yêu cầu A trong ví dụ là loại phản hồi giúp sản phẩm tốt lên, và từ chối nó là đánh mất lý do khách thuê FDE. Lỗi cuối cùng là để quyết định treo lơ lửng: mỗi yêu cầu cần đúng một trạng thái là duyệt, từ chối hoặc hoãn.

Luyện kỹ năng này ở đâu, thể hiện thế nào

Bạn không cần đợi có chức danh FDE mới luyện được. Nếu đang làm outsource hay product, mỗi ticket “làm thêm cái này nhé” từ PM hoặc khách đều là bài tập để chạy ba phép thử.

Khi đọc JD FDE hoặc solutions engineer, hãy tìm những dòng nói về làm việc trực tiếp với khách hay quản lý yêu cầu thay đổi; đó là chỗ đáng chuẩn bị sẵn một câu chuyện về kỹ năng này.

Trên CV, thay vì viết “làm việc với khách hàng”, hãy viết một câu có kết quả, chẳng hạn bạn đã tách một yêu cầu phát sinh sang giai đoạn sau và vẫn giữ đúng ngày go-live.

Trong phỏng vấn, kể lại một lần bạn nói “chưa phải bây giờ” với khách mà quan hệ vẫn tốt lên. Câu chuyện đó thuyết phục hơn mọi lời tự nhận mình “giao tiếp tốt”.

Khách sẽ luôn hỏi thêm, và một dự án FDE tốt cũng nên được hỏi thêm. Người làm nghề giỏi không né những câu hỏi đó: họ trả lời nhanh, ghi lại bằng văn bản, và lần nào cũng chỉ ra được kết quả nào khách đã mua.