Khách đòi cả ba thứ, FDE nên kéo cần gạt phạm vi trước

Trong sổ tay FDE của PostHog có một câu ngắn nhưng chứa cả một cách làm nghề: hãy giữ phạm vi nhỏ, vì nới rộng một phạm vi chặt bao giờ cũng rẻ hơn gỡ lại một phạm vi đã lỏng.

Đọc lướt thì tưởng đó là lời khuyên quản lý dự án quen thuộc. Thật ra nó trả lời câu hỏi khó nhất ở site khách hàng: khi khách muốn tất cả, bạn nhường ở chỗ nào?

Khách hàng hiếm khi nói “chúng tôi chấp nhận chậm” hay “làm sơ sơ cũng được”. Họ muốn đủ tính năng, giao sớm và chạy ổn. Người làm FDE nào cũng phải đánh đổi giữa ba thứ đó, nhưng cái khác nhau là bạn đánh đổi có chủ đích hay để nó tự xảy ra.

Với developer Việt Nam đang muốn chuyển sang FDE, sức căng ấy sẽ đến ngay trong tuần đầu ở site khách. Ba cần gạt nằm trước mặt bạn, nhưng cái nên kéo trước là phạm vi. Kéo nó thế nào để không mất lòng khách mới là kỹ năng cần luyện.

Ba cần gạt, nên kéo cái nào trước?

Mô hình tam giác dự án quen thuộc với dân quản lý dự án. Wikipedia mô tả một điểm then chốt của nó: chất lượng công việc bị ràng buộc bởi ngân sách, thời hạn và phạm vi tính năng. Chất lượng không phải một cái núm riêng để vặn. Nó là hệ quả của ba thứ kia.

Ở site khách, các ràng buộc ấy phần lớn đến từ phía khách. Ben Griswold cho rằng công việc FDE bị giới hạn bởi lịch trình, stack công nghệ và môi trường của chính khách hàng, và kết thúc bằng việc trao lại quyền sở hữu cho họ.

Thời hạn vì thế gần như là dữ kiện đầu vào. Bạn hiếm khi tự quyết được ngày ra mắt nội bộ của khách, cũng không đổi được hạ tầng họ đang chạy.

Chất lượng thì có sàn. Griswold viết rằng mục tiêu là chuyển giao năng lực, không phải tạo ra sự phụ thuộc lâu dài. Một hệ thống làm vội, khách không tự vận hành được, là thất bại ngay cả khi giao đúng hạn.

Vì thế phạm vi là cần gạt FDE nên kéo đầu tiên. Thời hạn hay nguồn lực vẫn có thể đổi, nhưng đó là thứ phải thương lượng với khách, còn phạm vi là thứ bạn chủ động đề xuất thu hẹp hoặc mở rộng mỗi ngày.

Cần gạt	Ai thực sự nắm	Kéo sai thì sao	FDE nên làm gì
Thời hạn	Khách: lịch trình, stack, môi trường của họ	Ép nhanh hơn mà giữ nguyên phạm vi thì chất lượng trả giá	Ghi vào brief từ đầu, chỉ lùi khi khách đồng ý đổi lấy phạm vi
Chất lượng	Không ai nắm trực tiếp; nó bị ràng buộc bởi ngân sách, thời hạn, phạm vi	Hạ sàn thì khách không nhận lại được quyền sở hữu	Chốt mức tối thiểu trong định nghĩa “xong”
Phạm vi	FDE và khách cùng thương lượng, liên tục	Phình ra mà không đổi thời gian hay nguồn lực là scope creep	Kéo trước: giữ nhỏ, kiểm tra từng yêu cầu, mở rộng có ghi chép

Phạm vi nhỏ không có nghĩa là làm ít

PostHog yêu cầu mỗi engagement phải có ba thứ trước khi giao việc: một kết quả đo được, một thời hạn ước lượng, và một định nghĩa chung về “xong”, viết trong một brief ngắn. Ba dòng đó chính là tam giác dự án được ghi ra giấy. Kết quả là phạm vi, thời hạn là tốc độ, còn định nghĩa “xong” là sàn chất lượng.

Sổ tay ấy còn nói thẳng hơn: xây nhiều hơn những gì câu hỏi cần không phải là chu đáo, mà là lãng phí. Nếu bạn quen làm thêm vài thứ ngoài yêu cầu cho khách vui, câu này đáng chép lại. Mỗi tính năng thêm vào ngoài brief đều ăn vào thời gian đã chốt hoặc kéo chất lượng xuống dưới sàn.

PostHog cũng đưa ra một bộ lọc tinh tế: giải pháp có thể chỉ dành riêng cho một khách, nhưng những phát hiện hữu ích thì không nên bị giữ lại ở đó.

Khi cân nhắc nhận thêm một phần việc, bạn có thể hỏi: phần này chỉ phục vụ khách này, hay sẽ dạy cho công ty điều gì đó dùng lại được? Phần việc thuộc loại sau đáng để mở rộng hơn.

Khám phá hay phình việc: hai câu hỏi đáng nhớ

Khó ở chỗ FDE không thể đóng băng yêu cầu như một hợp đồng phạm vi kiểu cũ. Tandem nhận xét rằng nghề này buộc người làm phải liên tục thu thập yêu cầu và hiệu chỉnh cùng khách hàng. Yêu cầu thay đổi là chuyện bình thường. Vấn đề là thay đổi đó thuộc loại nào.

Tandem định nghĩa scope creep là phạm vi lớn lên mà thời gian, chi phí hay nguồn lực không thay đổi tương ứng. Định nghĩa này đúng với logic cần gạt: phạm vi được phép lớn, miễn là một cạnh khác của tam giác được điều chỉnh theo. Thứ gây hại là phần phạm vi tăng thêm mà không ai chịu trả giá.

Trong bốn phép thử Tandem đưa ra, có hai câu hỏi dùng được ngay. Câu thứ nhất: yêu cầu này làm rõ kết quả khách đã mua, hay thêm một kết quả mới?

Câu thứ hai: bạn có chỉ ra được phạm vi nào đã chốt, điều gì đã nói và thứ gì đã giao không? Câu đầu phân loại yêu cầu. Câu sau quyết định bạn có đủ bằng chứng để thương lượng hay không.

Thử áp vào một ca cụ thể

Thử hình dung một ca giả định. Bạn được giao bốn tuần để xây cho một công ty bán lẻ một pipeline cảnh báo hàng sắp hết, áp dụng ở 10 cửa hàng thí điểm. Brief ba dòng, được khách xác nhận ngay tuần đầu, có thể viết như sau:

Kết quả: giảm số lần hết hàng ở 10 cửa hàng thí điểm.

Thời hạn: bốn tuần.

Xong khi: cảnh báo chạy hằng ngày trên dữ liệu thật của 10 cửa hàng, và đội vận hành bên khách tự xử lý được.

Đến tuần thứ hai, quản lý vận hành bên khách xin thêm hai việc: phân ngưỡng cảnh báo theo mùa, và một dashboard doanh thu cho ban giám đốc.

Áp phép thử đầu tiên. Ngưỡng theo mùa làm rõ đúng kết quả đã mua, vì nó giúp cảnh báo chính xác hơn, nên đó là khám phá và hợp lý để đưa vào. Dashboard doanh thu là một kết quả mới. Nhận nó mà không lùi hạn hay thêm người thì đúng là định nghĩa scope creep của Tandem.

Phép thử thứ hai cho bạn công cụ để nói “chưa” mà không mất lòng. Bạn mở brief ra và trả lời khách bằng một câu: “Ngưỡng theo mùa nằm trong kết quả đã chốt nên bên em làm luôn; dashboard doanh thu là kết quả mới, anh chọn giúp: để sang giai đoạn sau, hay làm ngay và lùi hạn thêm một tuần?”

Để ý rằng lựa chọn thứ hai chính là kéo cần gạt thời hạn, và điều đó hoàn toàn hợp lệ vì khách là người quyết. Cuộc trao đổi chuyển từ “anh không muốn giúp” sang “chúng ta chọn đánh đổi nào”.

Khi cần gạt bị kẹt

Mô hình này có giới hạn, và Wikipedia cũng ghi nhận điều đó: trên thực tế, không phải lúc nào cũng đánh đổi được giữa các ràng buộc. Có những phạm vi không thể cắt. Nếu khách cần tích hợp với hệ thống thanh toán thì tích hợp đó là lõi, bỏ đi thì không còn gì để giao.

Khi đó lời khuyên giữ phạm vi nhỏ chuyển thành việc cắt cho đúng chỗ. Cái được thu hẹp là số trường hợp biên xử lý trong đợt đầu, số màn hình, số báo cáo, chứ không phải phần lõi tạo ra kết quả.

Nếu đến phần lõi cũng không vừa thời hạn, đó là tín hiệu phải báo sớm cho khách để thương lượng lại thời gian hoặc nguồn lực, không phải tín hiệu để hạ sàn chất lượng.

Griswold cũng nhắc một điều dễ quên: FDE giao trong vài tuần thứ mà đội sản phẩm giao trong vài quý, nhưng khác biệt không nằm ở tốc độ. Nó nằm ở chỗ khớp với ràng buộc của đúng một khách hàng. Cắt phạm vi để chạy nhanh hơn mà sản phẩm không khớp với môi trường của khách thì bạn đã kéo nhầm cần gạt.

Developer Việt Nam nên luyện gì

Nếu bạn từng làm outsourcing, có thể bạn đã quen với change request. Nhưng nếu ở dự án hiện tại việc thương lượng những yêu cầu đó vẫn do người khác lo, đó là khoảng trống nên chủ động lấp. Vì việc hiệu chỉnh yêu cầu với khách diễn ra liên tục, FDE khó tránh được chuyện tự mình đứng ở chỗ đánh đổi.

Khi đọc JD, hãy để ý các cụm như “scoping”, “trade-offs”, “definition of done” hay “customer discovery”. Chúng gợi ý công ty kỳ vọng bạn tự chốt phạm vi chứ không chỉ thực thi. Trong buổi phỏng vấn, chuẩn bị sẵn một câu chuyện có thật về lần bạn đã nói “chưa” với một yêu cầu, và bạn đổi lại được gì.

Trong CV, thay dòng “phát triển module báo cáo” bằng dòng cho thấy bạn đã đánh đổi thế nào: phạm vi nào đã hoãn, thời hạn nào đã giữ, chất lượng nào không bị hạ. Đừng cố chứng minh mình làm được tất cả. Hãy cho thấy bạn biết thứ gì nên gác lại, và giải thích được với khách vì sao.