Dev làm task. Product engineer hỏi tại sao task này tồn tại

Có một kiểu sprint planning rất phổ biến: PM mở ticket lên, đọc description, assign cho dev, dev gật đầu, estimate, done. Hỏi dev đó hôm nay làm gì, họ sẽ trả lời: “Mình đang làm ticket HMS-342 — thêm filter theo ngày vào màn hình appointment list.”

Hỏi tại sao filter đó cần tồn tại? Họ nhìn lại ticket. Không có gì ngoài dòng “Add date filter to appointment list screen.” Họ nhún vai: “PM bảo làm thì làm thôi.”

Đây là developer. Không sai. Nhưng đây không phải product engineer.

Sự khác biệt không nằm ở kinh nghiệm

Mình không nói đây là chuyện khác biệt về kinh nghiệm. Mình đã thấy người có 5 năm kinh nghiệm vẫn làm việc theo kiểu nhận ticket → implement → close. Và mình cũng thấy người mới ra trường đã có thói quen hỏi “feature này solve được vấn đề gì của user?” trước khi viết dòng code đầu tiên.

Sự khác biệt nằm ở cách họ định nghĩa công việc của mình.

Dev thuần túy định nghĩa công việc theo task: “Mình cần implement cái này.” Product engineer định nghĩa công việc theo outcome: “Cái này được implement để đạt được điều gì?”

Nghe có vẻ philosophical. Nhưng hệ quả của sự khác biệt đó rất cụ thể.

Tại sao câu hỏi “tại sao” quan trọng đến vậy

HMS có một lần mình nhớ mãi. Ticket yêu cầu thêm khả năng export danh sách bệnh nhân ra Excel. Estimate vài ngày, implement straightforward. Trước khi làm, ai đó hỏi: “Export này dùng để làm gì?”

Câu trả lời: admin cần gửi báo cáo hàng tháng cho ban giám đốc.

Câu hỏi tiếp theo: “Họ cần format gì trong báo cáo đó?”

Câu trả lời: tổng số lượt khám theo bác sĩ, theo khoa, tỷ lệ hoàn thành appointment.

Đó không phải là export danh sách bệnh nhân. Đó là report tổng hợp có aggregate data. Implement theo ticket gốc sẽ tạo ra một feature mà user phải tự tính tay trong Excel sau khi export — tức là giải đúng ticket, sai vấn đề.

Câu hỏi “tại sao” không mất nhiều thời gian. Nó tiết kiệm rất nhiều thời gian.

Hỏi không phải để cản trở, mà để build đúng thứ

Có một nỗi sợ phổ biến: hỏi nhiều quá thì PM nghĩ mình khó tính, không hợp tác. Nỗi sợ này không hẳn vô lý — cách hỏi quan trọng không kém gì nội dung câu hỏi.

Hỏi kiểu này nghe như đang challenge: “Tại sao cần làm feature này? Nó có thực sự cần thiết không?”

Hỏi kiểu này nghe như đang partner: “Bạn có thể share thêm về use case cụ thể không? Mình muốn chắc là mình implement đúng theo cách sẽ solve được vấn đề đó.”

Cùng một intent, nhưng người nhận nghe khác hoàn toàn. Product engineer giỏi không hỏi để phán xét — họ hỏi để hiểu context đủ sâu để implement tốt hơn.

Và khi họ hiểu context, họ có thêm thứ quan trọng: khả năng push back đúng chỗ. Không phải push back vì không muốn làm, mà push back vì thấy một cách approach khác có thể đạt được outcome tốt hơn với ít effort hơn.

Context thay đổi implementation decision

Cùng một feature, context khác nhau dẫn đến implementation khác nhau hoàn toàn.

Ví dụ: thêm sort theo tên bác sĩ vào danh sách appointment.

Nếu đây là feature cho receptionist — người dùng daily, list thường có 20-30 records — sort phía client là đủ, không cần touch backend.

Nếu đây là feature cho báo cáo admin — list có thể có hàng nghìn records, cần paginate — sort phải xuống database.

Nếu đây là feature mà user thực sự cần tìm appointment của một bác sĩ cụ thể — thì cái họ cần không phải sort, mà là search/filter theo tên bác sĩ.

Không hỏi context → implement một trong ba → may thì đúng, xui thì làm lại.

Takeaway

Trước khi estimate bất kỳ ticket nào, hãy tự hỏi: “Mình hiểu vấn đề mà feature này đang giải quyết chưa, hay mình chỉ đang hiểu implementation mà người khác đã quyết định?” Hai thứ đó khác nhau — và biết cái nào bạn đang thiếu là bước đầu tiên để chuyển từ dev làm task thành engineer giải vấn đề.

Bài tiếp theo: User không quan tâm code của bạn — họ quan tâm trải nghiệm