The Product-Minded Engineer: cuốn sách của Drew Hoskins dạy FDE thiết kế cho người dùng thật của khách

“Chẩn đoán có thể là giao diện quan trọng nhất của sản phẩm.” Câu này không nằm trong chương nói về UX. Nó nằm trong chương 3 của The Product-Minded Engineer, chương bàn về lỗi và cảnh báo, trong cuốn sách Drew Hoskins viết cho O’Reilly Media.

Với một FDE, câu đó chạm đúng vào việc hằng ngày ở chỗ khách. Bạn nhận yêu cầu từ người mua: thêm bước export, nối agent vào ERP.

Nhưng thử hình dung người phải sống với hệ thống mỗi sáng: nhân viên vận hành, kế toán viên hay điều phối viên. Nhiều khi họ không ngồi trong buổi họp chốt yêu cầu, và rất có thể họ chạm vào một thông báo lỗi trước khi kịp hiểu tính năng mới làm được gì.

Cuốn sách nhắm đúng vào khoảng trống đó: làm ra thứ người dùng của khách thật sự cần, không dừng ở thứ đã được ghi trong ticket.

Người viết đã đứng ở cả hai phía

Gergely Orosz giới thiệu Hoskins trên The Pragmatic Engineer là người từng làm kỹ sư phần mềm và hiện làm product manager. Orosz đăng trích đoạn chương 3 và nhận xét rằng, với ông, Hoskins có vẻ là người lý tưởng để viết một cuốn sách như vậy. Chính Hoskins kể rằng ông mất khoảng 18 tháng để viết, bắt đầu từ ngay hôm sau khi gia nhập Temporal.

Các nhà sách ghi hai tiêu đề phụ khác nhau, backstory.london ghi “Building the Right Solutions for Your Users” còn Helion ghi “Building Impactful Software for Your Users”, nhưng đó vẫn là cùng một cuốn sách.

Sách chia thành bốn phần: Develop, Deliver, Discover, Define. Luận điểm xuyên suốt khá thẳng: ngoài tay nghề kỹ thuật, kỹ sư cần đồng cảm sâu hơn với người dùng. Mục tiêu đi kèm là đưa tư duy sản phẩm vào chính các tác vụ kỹ thuật và biết thu phản hồi có giá trị từ người dùng.

Nên đọc theo thứ tự nào?

Nếu bạn đang chuyển từ backend hay platform sang FDE, đây là cuốn nên đọc sớm: luận điểm chính của sách, rằng kỹ sư cần đồng cảm sâu hơn với người dùng, cũng là thứ bạn phải tự mang theo khi làm việc trực tiếp với khách. Nếu bạn đã làm PM lâu năm, có thể phần lớn nội dung sẽ quen.

Thứ tự hợp lý là đọc trích đoạn chương 3 trên The Pragmatic Engineer trước, vì nó cho bạn thứ dùng được ngay ngày mai. Tiếp theo là chương 6, “Understanding Your Target Audience”, và chương 7, “Discovering Your Product Through Simulation”. Hai chương này gần với customer discovery nhất. Sau đó mới quay lại đọc từ đầu.

Ý thứ nhất: lỗi là một giao diện

Lời khuyên cụ thể nhất trong trích đoạn là ném lỗi từ lớp ngoài cùng của API hoặc ứng dụng, nơi bạn còn nắm được kịch bản người dùng đang thực hiện. Lý do là ở lớp trong cùng, code chỉ biết một khóa bị thiếu, chứ không biết người dùng đang cố làm gì.

Thử hình dung một pipeline import hóa đơn bạn dựng cho khách. Hàm parse ở sâu bên trong báo KeyError: 'invoice_id', và kế toán viên chỉ còn cách gọi bạn.

Nếu bắt lỗi đó ở lớp ngoài, thông báo có thể thành: “Không import được file hóa đơn tháng 9: dòng 412 thiếu cột invoice_id, hãy kiểm tra mẫu export từ ERP”.

Đến lúc đó người dùng tự sửa được, và bạn khỏi phải nhận một cuộc gọi lúc nửa đêm.

Ý thứ hai: mô phỏng trước khi người dùng chạm vào

Một mục tiêu sách đặt ra là mô phỏng và dự đoán cách người dùng tương tác để sản phẩm dễ dùng hơn, và chương 7 dành trọn cho việc khám phá sản phẩm qua mô phỏng. Với FDE, đây là bài tập rẻ nhất có thể làm trước một buổi demo.

Giả sử bạn sắp bàn giao một agent tra cứu hợp đồng. Thay vì chạy lại đúng các câu hỏi mẫu, hãy nhập vai một chuyên viên pháp chế đang vội.

Họ gõ tên viết tắt của đối tác, dán nguyên một đoạn email vào ô hỏi, rồi hỏi tiếp mà không nhắc lại ngữ cảnh. Mỗi lần bạn phải dừng lại để đoán, bạn đã tìm ra một lỗi trước khi khách tìm ra nó.

Ý thứ ba: tư duy sản phẩm nằm trong ticket

Sách đặt mục tiêu lồng tư duy sản phẩm vào chính các tác vụ kỹ thuật hằng ngày, chứ không tách nó thành một việc riêng. Điều này hợp với FDE, vì bạn hiếm khi được giao riêng một việc tên là “nghiên cứu người dùng”.

Cách áp dụng đơn giản nhất: mỗi khi viết một cảnh báo hay chọn giá trị mặc định cho cấu hình ở chỗ khách, hãy tự hỏi người dùng cuối sẽ đọc và hiểu nó thế nào. Câu hỏi ấy tốn vài phút, nhưng thường tiết kiệm cho bạn cả một buổi giải thích.

Đây cũng là chỗ bạn nên thể hiện trong CV. Một dòng như “viết lại lớp xử lý lỗi của pipeline import để người dùng phía khách tự xử lý được các lỗi dữ liệu thường gặp” cho nhà tuyển dụng thấy bạn hiểu người dùng cuối.

Câu “đã làm việc với stakeholder” thì không nói được điều đó. Khi phỏng vấn, hãy chuẩn bị sẵn một ví dụ tương tự, kể rõ người dùng gặp gì trước khi bạn sửa và mọi thứ thay đổi ra sao sau đó.

Nếu chỉ đọc một chương, hãy đọc chương về lỗi. Lần tới khi một thông báo lỗi khiến khách phải gọi cho bạn, bạn sẽ biết sửa ở lớp nào.