Vì sao người làm sản phẩm cần quan tâm
Trong nhiều công ty, "chiến lược kỹ thuật" được hiểu là chuyện của CTO: chọn ngôn ngữ lập trình, chọn nhà cung cấp cloud, vẽ sơ đồ kiến trúc. Người làm sản phẩm đứng ngoài, nhận về một con số ước lượng và một câu "phần này khó lắm".
Cách hiểu đó bỏ sót điều quan trọng nhất. Chiến lược kỹ thuật thực chất là một loạt lựa chọn về cách dùng năng lực kỹ thuật có hạn trong một đến ba năm: hệ thống nào được đầu tư, khoản nợ nào được giữ lại, phần nào tự xây, phần nào đi mua, đội nào sở hữu phần nào. Mỗi lựa chọn mở ra hoặc đóng lại những gì sản phẩm có thể làm. Một quyết định "để sau hẵng tách hệ thống thanh toán" hôm nay có thể là lý do roadmap của bạn chậm ba tháng vào năm sau.
Nói gọn: chiến lược sản phẩm trả lời cược vào đâu, chiến lược kỹ thuật trả lời có đủ sức để cược không, và cược bằng cách nào. Tách hai thứ này ra thì cả hai đều yếu.
Ba lý do nó không thể chỉ là việc của CTO
1. Năng lực kỹ thuật là ngân sách chung. Mỗi tuần kỹ sư dành cho việc tách hệ thống là một tuần không làm tính năng. Người chia ngân sách này mà không hiểu giá trị của từng tính năng thì đang quyết định với một nửa dữ liệu.
2. Phần lớn đánh đổi kỹ thuật là đánh đổi kinh doanh. "Có nên dùng dịch vụ bên ngoài cho phần định tuyến không" phụ thuộc vào việc định tuyến có phải lợi thế cạnh tranh không, khối lượng đơn sẽ tăng bao nhiêu, khách hàng chịu được độ trễ đến đâu. Đó là những câu hỏi sản phẩm.
3. Không ai bảo vệ được khoản đầu tư mình không hiểu. Khi CEO hỏi "sao quý này ít tính năng mới vậy", người phải trả lời thường là Head of Product. Nếu bạn không hiểu vì sao đội dành 20% công sức cho nợ kỹ thuật, khoản đầu tư đó sẽ bị cắt ở cuộc họp đầu tiên có áp lực doanh số.
Ai mang gì vào bàn
Điều này không có nghĩa PM giành quyền của CTO. Phân vai rõ giúp hai bên quyết nhanh hơn:
| Quyết định | Kỹ thuật mang vào | Sản phẩm mang vào | Ai chốt |
|---|---|---|---|
| Chia công sức giữa tính năng và nợ | Lãi của từng khoản nợ, rủi ro sự cố | Giá trị và thời điểm của từng tính năng | Head of Product và CTO cùng ký |
| Tự xây hay mua | Chi phí xây, chi phí vận hành, rủi ro tích hợp | Mức độ khác biệt, tốc độ cần ra thị trường | CTO, có đồng thuận của sản phẩm |
| Ranh giới hệ thống và đội | Phụ thuộc giữa các hệ thống | Hành trình khách hàng, ranh giới sản phẩm | CTO cùng lãnh đạo sản phẩm |
| Di trú hệ thống cũ | Các giai đoạn, tiêu chí kỹ thuật | Thời điểm ít rủi ro, thứ tự nhóm khách | Cùng chốt, có tiêu chí dừng |
| Rủi ro trong roadmap | Xác suất và kịch bản | Tác động lên cam kết với khách | Head of Product, dựa trên dữ liệu kỹ thuật |
Ví dụ xuyên suốt: ChởNhanh (giả định)
Để các bài sau cụ thể và có số, ta theo một công ty giả định từ đầu đến cuối.
ChởNhanh là nền tảng giao hàng nội thành cho shop bán online ở Hà Nội và TP.HCM. Lời hứa với shop: giao trong 2 giờ trong nội thành.
| Chỉ số | Giá trị hiện tại |
|---|---|
| Đơn mỗi ngày | 45.000 |
| Đơn thu hộ (COD) | 60%, tức 27.000 đơn/ngày |
| Shop đang hoạt động | 12.000 |
| Tài xế | 3.500 |
| Kỹ sư | 60, chia thành 8 đội |
| Mục tiêu cuối năm sau | 120.000 đơn/ngày |
| Cao điểm cuối năm | Gấp 3 ngày thường, tức 135.000 đơn/ngày |
Để tính toán, ta quy ước: 1 tuần-kỹ sư là một kỹ sư làm một tuần, chi phí đầy đủ khoảng 12 triệu đồng. Một quý có 12 tuần làm việc, nên 60 kỹ sư cho 720 tuần-kỹ sư mỗi quý.
Những người bạn sẽ gặp lại:
- Mai — Head of Product
- anh Đạt — CTO
- Hưng — Engineering Manager đội Điều phối
- Trang — PM cao cấp, phụ trách đối soát COD
- chị Lan — CEO
Ba dấu hiệu chiến lược kỹ thuật đang vắng mặt
- Ước lượng tăng dần mà không ai giải thích được. Một tính năng cỡ trung năm ngoái mất 3 tuần, năm nay mất 6 tuần. Đó thường là lãi của nợ kỹ thuật đang cộng dồn.
- Nợ chỉ được trả khi có sự cố. Không có ngân sách định trước, nên chỉ sự cố mới đủ sức giành thời gian.
- Roadmap sản phẩm và kế hoạch kỹ thuật không nhắc đến nhau. Khi đội kỹ thuật lên kế hoạch di trú mà roadmap không biết, một trong hai sẽ trượt.
Bạn cần biết gì, và không cần biết gì
Bạn không cần viết code. Nhưng bạn cần đủ vốn từ để hỏi đúng câu: hệ thống nguyên khối và các dịch vụ tách rời khác nhau thế nào, API là gì và vì sao hợp đồng API quan trọng, cơ sở dữ liệu dùng chung tạo ra phụ thuộc ra sao. Nếu còn mơ hồ, xem System Architecture Basics, API & Technical Literacy và Technical Architecture trước khi sang bài 2.
Lộ trình khoá học:
- Bài 2 và 3: nợ kỹ thuật như một khoản vay, và cách xếp nó cạnh tính năng
- Bài 4 và 5: tự xây hay mua, và khi nào đầu tư vào nền tảng dùng chung
- Bài 6 và 7: ranh giới hệ thống theo đội, và di trú hệ thống cũ
- Bài 8 và 9: rủi ro trong roadmap, và bản chiến lược kỹ thuật một trang
Làm ngay
Lấy roadmap quý tới của sản phẩm bạn. Với mỗi hạng mục lớn, ghi một dòng: hạng mục này dựa vào hệ thống nào, hệ thống đó đang khoẻ hay yếu, và ai trong đội kỹ thuật hiểu nó rõ nhất. Rồi hẹn 30 phút với tech lead hoặc Engineering Manager và hỏi đúng một câu: "Nếu chỉ được sửa một thứ để quý sau đội chạy nhanh hơn, anh/chị sửa gì?" Ghi lại câu trả lời — bạn sẽ dùng nó ở bài 2 và bài 3.