Feature
Một nhóm chức năng có thể mô tả bằng ngôn ngữ người dùng và mang lại giá trị đo được, nằm giữa epic và user story về kích cỡ. Đơn vị mà stakeholder thật sự nói chuyện hằng ngày.
Định nghĩa
Khi khách hàng gọi điện, họ không nói "cho tôi thêm ba user story". Họ nói "tôi muốn tài xế chụp ảnh khi giao hàng". Cái vừa được nói ra đó chính là một feature: một nhóm chức năng đủ lớn để có tên gọi riêng, đủ nhỏ để làm xong trong một hoặc vài sprint, và mô tả được bằng ngôn ngữ người dùng chứ không phải ngôn ngữ database.
Feature là đơn vị mà cả stakeholder lẫn team đều gọi được cùng một tên. Đó là lý do nó nằm trên roadmap chứ không phải story.
Mô tả một feature cần những gì
SAFe định nghĩa feature khá chặt và phần này đáng học kể cả khi bạn không dùng SAFe. Một feature nên có:
- Tên gọi ngắn mà người ngoài team đọc hiểu ngay.
- Giả thuyết lợi ích (benefit hypothesis). Làm cái này thì kỳ vọng số nào thay đổi, thay đổi bao nhiêu. Ví dụ: giảm khiếu nại giao sai địa chỉ từ 120 vụ mỗi tháng xuống dưới 40.
- Acceptance criteria ở mức feature. Không đi vào chi tiết từng màn hình, chỉ nêu điều kiện coi là hoàn tất.
- Ước lượng thô để xếp vào kế hoạch quý.
Cái mục thứ hai là thứ hay bị bỏ nhất, và cũng là thứ giúp bạn từ chối được feature vô nghĩa. Khi ai đó không trả lời nổi "làm xong thì cái gì tốt lên", feature ấy chưa sẵn sàng để bàn tiếp.
So sánh Feature, Function và Capability
| Khái niệm | Nhìn từ góc | Ví dụ |
|---|---|---|
| Capability | Năng lực của hệ thống ở mức cao, thường trải nhiều hệ thống | Quản lý toàn bộ vòng đời đơn giao hàng |
| Feature | Người dùng, có giá trị đo được | Tài xế chụp ảnh bằng chứng giao hàng |
| Function | Kỹ thuật, một hành vi cụ thể của hệ thống | Nén ảnh xuống dưới 500KB trước khi upload |
Trong tiếng Việt đi làm, ba từ này bị dùng lẫn lộn thoải mái. Không cần đi sửa cách nói của mọi người. Chỉ cần khi viết tài liệu thì giữ một mức nhất quán, đừng để trong cùng một bảng vừa có "Quản lý đơn hàng" vừa có "Nén ảnh trước khi upload".
Ví dụ thực tế
Feature "chụp ảnh bằng chứng giao hàng" vào backlog của một công ty giao hàng chặng cuối kèm đúng một dòng giả thuyết: kéo tranh chấp "tôi không nhận được hàng" từ 87 vụ mỗi tháng xuống dưới 30. Mỗi vụ hiện ngốn trung bình 25 phút của bộ phận chăm sóc khách hàng, chưa tính tiền đền.
Feature này chẻ ra khoảng 6 story: chụp ảnh trong app tài xế, nén và upload khi mạng yếu, lưu ảnh kèm toạ độ và thời gian, cho tổng đài tra cứu ảnh theo mã đơn, giới hạn dung lượng lưu trữ 90 ngày, và một story cấu hình bật tắt theo khu vực.
Story cuối cùng nghe thừa, nhưng chính nó cứu team. Khi triển khai thí điểm ở hai quận, băng thông vùng ngoại thành làm app treo, và bên vận hành chỉ cần tắt tính năng cho vùng đó thay vì rollback cả bản build.
Feature creep và cách chặn
Feature creep là hiện tượng danh sách tính năng cứ dài thêm mà không ai bỏ bớt. Nó hiếm khi đến từ một quyết định lớn, thường là mười quyết định nhỏ kiểu "thêm cái filter này nữa cho tiện".
Ba cái chốt chặn dùng được:
- Bắt buộc điền giả thuyết lợi ích cho mọi feature trước khi đưa lên roadmap. Riêng bước này lọc được kha khá.
- Đặt trần số feature cho mỗi quý. Muốn thêm cái mới thì phải chỉ ra cái nào bị đẩy ra.
- Rà lại sau 3 tháng release. Kéo số liệu sử dụng, feature nào dưới 2% người dùng chạm tới thì đưa ra bàn: cải tiến, hay gỡ đi.
Bước 3 gần như không công ty nào làm, và đó là lý do sản phẩm nào sống lâu cũng có một đống màn hình không ai mở.
Câu hay bị hỏi phỏng vấn
"Khách yêu cầu một feature mà bạn thấy vô ích thì xử lý sao?" Đừng trả lời là sẽ thuyết phục khách bỏ. Cách an toàn hơn: hỏi ngược lại vấn đề đứng sau yêu cầu đó, ai đang gặp, tần suất bao nhiêu, hiện họ xoay xở kiểu gì. Rất nhiều lần vấn đề là thật nhưng giải pháp khách nghĩ ra thì không phải cách rẻ nhất. Và cũng có lần bạn phát hiện mình mới là người thiếu thông tin.
