Product Management
Đăng nhập
ESC

Nhập từ khóa để tìm kiếm

↑↓ Di chuyển
Enter Mở
ESC Đóng

Ra mắt chưa phải là xong — vì sao phải đánh giá từng tính năng

Đã đọc 0/7 mục · còn khoảng 4 phút
Cách chúng tôi ghi nhận

Một mục được tính là đã đọc khi nó nằm giữa màn hình đủ lâu so với độ dài của nó (bảng và sơ đồ tính một nửa), bạn vẫn đang cuộn hoặc bấm phím, và bạn đã thấy tới cuối mục. Lướt nhanh hoặc để tab mở không được tính. Chúng tôi chỉ lưu thời gian đọc từng mục — không lưu gì khác.

Ngày ra mắt là ngày bắt đầu đo

Hãy nhớ lại tính năng gần nhất đội bạn ra mắt. Có buổi demo, có tin nhắn chúc mừng trong nhóm chat, ticket được chuyển sang "Done", và tuần sau cả đội đã bắt tay vào việc tiếp theo. Bây giờ thử trả lời ba câu hỏi bằng số, không dùng cảm giác:

  • Tính năng đó dành cho bao nhiêu người dùng?
  • Trong số đó, bao nhiêu phần trăm đã thực sự dùng nó?
  • Trong số đã dùng, bao nhiêu người vẫn còn dùng sau hai tháng?
Nếu bạn không trả lời được, bạn không đơn độc. Ở rất nhiều đội, vòng đời của tính năng kết thúc đúng vào ngày phát hành. Lý do không phải ai đó lười, mà vì mọi động lực trong tổ chức đều chĩa vào việc làm ra thứ mới: lộ trình đo bằng số tính năng giao đúng hạn, buổi review quý khen những gì mới xuất hiện, và không ai được thưởng vì đã quay lại nhìn một thứ cũ.

Hệ quả là một tính năng sau ra mắt trở thành một khoản đầu tư không ai biết lãi hay lỗ, nhưng vẫn đều đặn tốn tiền mỗi tháng.

Một tính năng chưa được đánh giá tốn những gì

Chi phí xây dựng chỉ là phần nhìn thấy. Phần còn lại kéo dài suốt đời tính năng:

Loại chi phíNó xuất hiện ở đâuVì sao dễ bị bỏ qua
Kiểm thử hồi quyMỗi lần phát hành, QA phải kiểm cả tính năng nàyĐược tính chung vào "thời gian test"
Hỗ trợ khách hàngTicket, cuộc gọi, hướng dẫnĐội CS chịu, đội sản phẩm không thấy
Độ phức tạp giao diệnThêm một nút, một mục menu cho tất cả mọi ngườiKhông ai đo được sự rối
Onboarding kỹ sư mớiThêm một khối code phải hiểuChi phí trải dài, không có hoá đơn
Chi phí cơ hộiĐội không làm việc khác vì đang vá tính năng nàyVô hình theo định nghĩa
Khi không đánh giá, bạn không bao giờ biết khoản chi này có xứng đáng không. Tệ hơn, bạn lặp lại cùng một kiểu đặt cược sai ở tính năng tiếp theo, vì không có bài học nào được rút ra.

Đánh giá để làm gì: ba mục đích

Đánh giá tính năng không phải để chấm điểm đội hay tìm người có lỗi. Nó phục vụ ba mục đích rất thực dụng:

  • Ra quyết định cho chính tính năng đó: giữ nguyên, cải tiến, định vị lại cho nhóm khác, hay khai tử. Bài 7 đi sâu vào bốn lựa chọn này.
  • Phân bổ lại nguồn lực: một tính năng có giá trị thật nhưng ít người biết thường là cơ hội rẻ hơn mọi ý tưởng mới trong backlog.
  • Học để ước tính tốt hơn: sau năm, sáu lần so sánh "dự kiến" với "thực tế", đội biết mình thường lạc quan bao nhiêu. Đó là thứ làm các đề xuất sau trở nên đáng tin với lãnh đạo.

Công ty đi cùng khoá học: Tiệm Số (giả định)

Để các con số trong chín bài nối được với nhau, khoá học dùng một công ty giả định từ đầu đến cuối. Tiệm Số là ứng dụng quản lý bán hàng cho tiệm tạp hoá, cửa hàng mỹ phẩm và shop nhỏ ở Việt Nam, có khoảng 48.000 tiệm hoạt động mỗi tháng, thu phí qua gói Pro. Chị Hạnh là PM phụ trách mảng vận hành tiệm; anh Tùng là BA làm việc với dữ liệu.

Trong sáu tháng qua, đội ra mắt sáu tính năng:

Tính năngRa mắtMô tả ngắn
Nhắc nợ qua Zalo4 tháng trướcGhi sổ nợ khách và gửi tin nhắc trả nợ
Báo cáo lãi lỗ cuối ngày5 tháng trướcTự tổng hợp doanh thu, giá vốn, lãi trong ngày
Gợi ý đặt hàng nhà cung cấp4 tháng trướcĐề xuất số lượng nhập theo tốc độ bán
In tem mã vạch6 tháng trướcTạo và in tem cho hàng tự đóng gói
Khách thân thiết5 tháng trướcTích điểm theo số điện thoại khách
Chốt đơn livestream3 tháng trướcNhận đơn từ bình luận livestream Facebook
Giám đốc hỏi chị Hạnh một câu đơn giản: "Quý sau mình dồn người vào đâu?" Cả khoá học là hành trình trả lời câu hỏi đó cho đúng.

Ai làm việc này: PM, PO hay BA

Vai tròPhần việc chính
PMĐặt mục tiêu trước ra mắt, chủ trì đánh giá, đề xuất quyết định, viết Feature Impact Review
POĐưa việc đo đếm vào backlog, thực thi cải tiến hoặc kế hoạch khai tử theo sprint
BAĐịnh nghĩa sự kiện cần ghi nhận, kiểm tra dữ liệu, dựng bảng giữ chân và scorecard
Ở đội nhỏ, một người có thể làm cả ba. Điều quan trọng là phải có một người chịu trách nhiệm cho việc đánh giá diễn ra, nếu không nó sẽ trôi mãi.

Lịch đánh giá một tính năng

Thời điểmViệc cần làm
Trước ra mắtViết định nghĩa đối tượng và mục tiêu cho bốn lăng kính vào PRD
Tuần 1–2Kiểm tra sự kiện đã ghi đúng, số liệu khớp với thực tế
Tuần 6–12Đánh giá đầy đủ, ra quyết định, viết Feature Impact Review
Hằng quýĐưa mọi tính năng vào chung một scorecard để so sánh
Vì sao mục tiêu phải viết trước ra mắt? Vì viết sau khi đã thấy số, kết quả nào cũng có thể được gọi là "khá ổn". Mục tiêu viết trước là cách duy nhất để đánh giá trung thực với chính mình.

Nếu muốn xem toàn cảnh kỹ năng mà khoá học này dạy, đọc kỹ năng đánh giá tác động tính năng.

Làm ngay

Liệt kê mọi tính năng đội bạn ra mắt trong sáu tháng qua thành một bảng giống bảng của Tiệm Số. Thêm một cột: "Có ai đánh giá chưa?". Đếm số dòng ghi "chưa". Con số đó là điểm xuất phát của bạn, và bạn sẽ dùng chính bảng này trong các bài sau.

Học xong bài này rồi? Tạo tài khoản miễn phí để lưu lại — lần sau vào là biết ngay đang dở ở đâu, và học hết khóa thì có chứng chỉ. Lưu tiến độ của tôi