Buổi 5 — Làm việc với engineer mà không cần biết code
Nỗi lo phổ biến nhất của người chuyển từ marketing: "Tôi không biết kỹ thuật, liệu team có coi trọng không?" Câu trả lời: họ coi trọng PM hiểu chi phí, không phải PM viết được code.
Bạn cần hiểu gì, thật sự
Cái gì rẻ và cái gì đắt. Đổi màu nút thì rẻ. Đổi cách dữ liệu được lưu thì đắt. Thêm một trường vào form thì rẻ; thêm một trường phải đồng bộ với hệ thống bên ngoài thì đắt gấp nhiều lần. Hiểu được thứ tự độ lớn này là đủ để ra quyết định tốt.
Vì sao "chỉ thêm một tí" lại lâu. Thường vì nợ kỹ thuật: phần code đó được viết vội cho một mục đích khác, và mỗi thay đổi phải cẩn thận để không làm hỏng chỗ khác. Không phải engineer làm chậm — họ đang trả lãi cho quyết định cũ.
Bốn khái niệm nên nắm: API (hai hệ thống nói chuyện với nhau theo quy tắc), cơ sở dữ liệu (dữ liệu nào đang có, dữ liệu nào chưa từng được thu thập), môi trường (dev/staging/production — nơi thử an toàn trước khi ảnh hưởng người thật), và nợ kỹ thuật.
Riêng khái niệm thứ hai cứu bạn khỏi rất nhiều yêu cầu bất khả thi: rất nhiều báo cáo không làm được không phải vì khó tính toán, mà vì dữ liệu đó chưa bao giờ được lưu.
Cách đặt câu hỏi để không bị hớ
Thay vì hỏi "cái này làm được không" (câu trả lời luôn là được, chỉ là mất bao lâu), hãy hỏi:
- "Phần nào của việc này tốn công nhất?"
- "Có cách nào đạt 80% giá trị với 20% công sức không?"
- "Nếu bỏ yêu cầu X thì rẻ đi bao nhiêu?"
Điều khiến engineer tin tưởng một PM
Không phải kiến thức kỹ thuật. Mà là:
Không đổi ý giữa sprint mà không giải thích. Đổi ý là bình thường; đổi ý không kèm lý do làm mất niềm tin.
Mang theo bằng chứng. "Tôi nghĩ nên làm X" yếu hơn nhiều so với "12 khách hàng đã tự làm thủ công việc này, đây là ghi âm".
Bảo vệ team khỏi yêu cầu chen ngang. Đây là việc PM làm mà engineer nhìn thấy và ghi nhớ.
Thừa nhận khi không biết. PM giả vờ hiểu kỹ thuật bị phát hiện trong vòng một tuần.
Lợi thế bất ngờ của người từ marketing
Bạn giỏi giải thích. Rất nhiều engineer làm việc tốt hơn hẳn khi hiểu vì sao một tính năng quan trọng với người dùng — và phần lớn PM không giải thích được điều đó một cách sinh động. Bạn thì có.
Bài tập
Ngồi cùng một engineer và nhờ họ giải thích đường đi của dữ liệu cho một tính năng bạn quen thuộc: người dùng bấm nút, rồi chuyện gì xảy ra tới khi màn hình cập nhật. Vẽ lại bằng ngôn ngữ của bạn và nhờ họ sửa.
<!--les-append-->
Bảng chi phí thô — đủ để ra quyết định tốt
Bạn không cần biết code. Bạn cần biết thứ tự độ lớn:
| Loại thay đổi | Chi phí tương đối | Vì sao |
|---|---|---|
| Đổi chữ, màu, vị trí | Rẻ | Chỉ giao diện |
| Thêm trường vào form (chỉ lưu) | Rẻ | Thêm một cột |
| Thêm trường phải đồng bộ hệ thống ngoài | Đắt gấp nhiều lần | Cần xử lý lỗi, thử lại, đối soát |
| Đổi cách dữ liệu được lưu | Rất đắt | Phải chuyển dữ liệu cũ, không hỏng gì |
| Thêm báo cáo từ dữ liệu đã có | Trung bình | |
| Thêm báo cáo cần dữ liệu chưa thu | Đắt — và dữ liệu quá khứ không có | Phải cài đo lường trước, chờ tích luỹ |
Vì sao "chỉ thêm một tí" lại lâu
Thường không phải vì engineer làm chậm. Ba nguyên nhân thật:
- Nợ kỹ thuật — phần code đó viết vội cho mục đích khác; mỗi thay đổi phải cẩn thận để không làm hỏng chỗ khác
- Phần không nhìn thấy — một tính năng nhỏ vẫn cần xử lý lỗi, kiểm thử, quyền truy cập, ghi nhật ký
- Phụ thuộc — cần dữ liệu hoặc dịch vụ từ đội khác
Ba câu hỏi làm bạn được coi trọng
- "Cái gì trong yêu cầu này làm nó đắt lên nhiều nhất?" — thường có một chi tiết chiếm phần lớn chi phí, và bỏ nó đi không mất gì
- "Có cách nào rẻ hơn đạt cùng mục tiêu không?" — engineer thường có ý tưởng nhưng không được hỏi
- "Nếu làm phiên bản đơn giản nhất trước thì trông thế nào?"
Làm ngay
Trong buổi làm rõ việc tiếp theo, hỏi câu thứ nhất cho mọi yêu cầu. Ghi lại câu trả lời. Sau ba lần, bạn sẽ có bảng chi phí riêng cho sản phẩm của mình — chính xác hơn bảng chung ở trên. <!--/les-append-->