Có lần mình họp với một nhóm làm sản phẩm nội bộ. Họ dành gần hai tiếng tranh luận cái nút nằm bên trái hay bên phải, trong khi sếp họ chỉ quan tâm một câu: "Tháng sau doanh thu có tăng không?". Nhóm đó làm rất chăm, nhưng chăm cho thứ không ai cần.
Topic 52 trong The Pragmatic Programmer nói thẳng về chuyện này. Tip 96: Delight Users, Don't Just Deliver Code.
Delight khách hàng, không chỉ giao code
Điểm mấu chốt: giao phần mềm chạy được, đúng hạn, không bug — vẫn chưa đủ để làm người dùng vui.
Lý do rất đơn giản: người dùng không quan tâm tới code. Họ có bài toán kinh doanh cần giải, trong khuôn khổ mục tiêu và ngân sách của họ. Kỳ vọng của họ nằm ở tầng nghiệp vụ, không ở tầng phần mềm.
Tệ hơn, kỳ vọng đó thường không có trong bất kỳ tài liệu đặc tả nào. Sách nói rõ: đặc tả team nhận được sẽ còn dang dở cho tới khi team lặp qua nó với khách vài lần. Ngồi đọc spec rồi đoán giá trị thật đằng sau nó là không được.
Câu hỏi gỡ được nút thắt
Sách đưa một câu hỏi duy nhất để moi ra kỳ vọng ẩn:
Một tháng (hay một năm, hay bất cứ mốc nào) sau khi dự án xong, anh/chị biết được là chúng ta đã thành công bằng cách nào?
Câu trả lời có thể làm mình bất ngờ. Dự án cải thiện gợi ý sản phẩm có thể bị đánh giá bằng tỉ lệ giữ chân khách. Dự án gộp hai database có thể bị đánh giá bằng chất lượng dữ liệu, hoặc đơn giản là tiết kiệm bao nhiêu tiền. Mấy thứ đó không nằm trong dòng nào của backlog.
Moi được kỳ vọng về giá trị rồi mới có cái bám khi ra quyết định. Sách gợi ý bốn việc:
- Cả team phải hiểu rõ kỳ vọng đó, không chỉ riêng PM.
- Khi chọn đường đi, chọn hướng nào tiến gần hơn tới kỳ vọng đó.
- Phân tích lại yêu cầu người dùng dưới ánh sáng của kỳ vọng.
- Tiếp tục nghĩ về kỳ vọng đó suốt dự án, vì hiểu biết nghiệp vụ sẽ tăng dần.
Cái gạch đầu dòng thứ ba mới đáng nói. Sách nhận xét thẳng: rất nhiều "yêu cầu" team nhận được thực chất chỉ là phỏng đoán về việc công nghệ làm được gì — một kế hoạch triển khai nghiệp dư khoác áo đặc tả. Đừng ngại đề xuất thay đổi yêu cầu, miễn chứng minh được nó đưa dự án gần hơn tới mục tiêu.
Ảnh: fauxels — Pexels
Tại sao khó áp dụng
Khó nhất là mình thường không được ngồi cùng người trả tiền. Giữa mình và người thật sự đánh giá thành công có thể là PM, là BA, là trưởng phòng. Hỏi câu "tháng sau anh biết thành công bằng cách nào" là bị hỏi ngược: "Ơ, anh lo phần kỹ thuật thôi mà?"
Khó nữa: kỳ vọng về giá trị thay đổi. Hôm nay khách nói quan trọng nhất là tiết kiệm chi phí, ba tháng sau họ đổi sang giữ chân khách. Vẽ nó thành tài liệu đóng băng rồi quên là coi như công cốc.
Cách mình xử lý: biến câu hỏi đó thành thói quen ở đầu mỗi buổi demo, mỗi lần review sprint. Không phải tài liệu cứng, mà là câu hỏi định kỳ. Ai trả lời lệch nhịp thì mình biết mục tiêu vừa dịch chuyển.
Ảnh: Lukas — Pexels
Bài học rút ra
- Giao đúng hạn không làm ai vui. Giải được bài toán nghiệp vụ của họ mới làm họ vui.
- Câu hỏi mạnh nhất để moi kỳ vọng thật: "Một tháng sau dự án xong, anh/chị biết thành công bằng cách nào?"
- Đừng tin đặc tả là yêu cầu thật. Nhiều khi đó chỉ là phỏng đoán công nghệ khoác áo kế hoạch triển khai.
- Làm việc xuyên nhiều bộ phận nên lập trình viên thường thấy cách nối các mảnh doanh nghiệp mà từng phòng ban riêng lẻ không thấy.
- Ký tên vào việc mình làm (Tip 97 — Sign Your Work), nhưng giữ code chung với sự tôn trọng, không phải lòng tham đất.
Sách chốt một câu mình rất thích: dù chức danh là Software Developer hay Software Engineer, tên thật của nghề này là Problem Solver. Mình không viết code, mình giải bài toán.
Nghĩ lại chuyện cái nút bên trái hay bên phải ở đầu bài — nếu ai đó hỏi câu kia sớm hơn, chắc buổi họp đã ngắn hơn nhiều.
Dự án gần nhất mình làm, một tháng sau khi bàn giao, người dùng đánh giá thành công bằng gì — mình có thật sự biết không?