Mốc phát triển và buổi kickoff — sáu thứ phải chốt trước dòng code đầu tiên

Ra mắt bắt đầu ở buổi kickoff, không phải ở tuần cuối

Nhiều đội nghĩ về ra mắt vào hai tuần cuối: lúc đó mới hỏi support đã biết chưa, đo lường đã có chưa, có cần báo đối tác không. Đến lúc đó, mỗi câu trả lời "chưa" là một lần trễ hạn hoặc một lần ra mắt thiếu.

Lý do đơn giản: phần lớn những thứ quyết định một lần ra mắt có thành công không — mục tiêu, phạm vi, hạng ra mắt, rủi ro phụ thuộc, cách đo — đều phải được quyết trước khi xây, vì chúng thay đổi việc xây. Một sự kiện đo lường cần được code cùng tính năng. Một rủi ro đối tác cần được xử lý trước khi đối tác trở thành điểm nghẽn. Buổi kickoff là nơi chốt những thứ đó.

Các mốc của một chu kỳ phát triển

Trước khi nói kickoff, cần thấy nó nằm ở đâu. Một tính năng đáng kể thường đi qua các mốc sau, mỗi mốc là một cuộc review có người quyết:

Pre-mortem (bài 5) thường chạy ngay sau solution review và trước kickoff, để kickoff có sẵn danh sách rủi ro chính.

Sáu thứ phải chốt ở kickoff

1. Mục tiêu và chỉ số thành công — bằng số, trước khi xây

"Tăng tương tác" không phải mục tiêu. Mục tiêu là một con số với một mốc thời gian. Ở Sạp Số, Linh chốt:

• Chỉ số chính: tỉ lệ tiệm đặt lại trong 14 ngày tăng từ 61% lên 66% trong nhóm được bật tính năng, sau 6 tuần
• Chỉ số phụ: giá trị trung bình mỗi đơn tăng ít nhất 8%
• Chỉ số bảo vệ (không được xấu đi): tỉ lệ đơn bị nhà phân phối huỷ không vượt 3%

Vì sao phải chốt trước? Vì sau khi ra mắt, mọi con số đều có thể được kể thành thành công. Mục tiêu đặt trước là thứ duy nhất ngăn readout biến thành bài thuyết trình đẹp.

2. Phạm vi — và cả danh sách không làm

Danh sách không làm quan trọng ngang danh sách làm, vì đó là nơi tranh luận sau này sẽ nổ ra. Linh ghi rõ: bản đầu không có gợi ý theo mùa, không cho sửa giỏ hàng gợi ý trước khi bấm (chỉ xoá từng món), không hỗ trợ tiệm dùng hai nhà phân phối cùng lúc.

3. Hạng ra mắt

Đây là quyết định quyết định khối lượng chuẩn bị. Bài 3 đi sâu; ở kickoff chỉ cần chốt một con số. "Nhập hàng nhanh" là hạng 1 vì nó thay đổi cách tạo đơn — luồng tạo ra doanh thu — và ảnh hưởng tới nhà phân phối.

4. Ngày và các nấc

Không chỉ một ngày "ra mắt", mà các mốc: code xong, bắt đầu rollout nội bộ, 5%, 100%, ngày launch truyền thông. Ghi kèm điều kiện để đi tiếp, không chỉ ngày.

5. Người sở hữu từng mảng

Mỗi mảng ngoài code cần một tên người, không phải tên phòng ban:

6. Rủi ro lớn nhất và ai theo dõi

Từ pre-mortem, mang ba đến năm rủi ro lớn nhất vào kickoff, mỗi rủi ro có chủ và tripwire. Ở Sạp Số, rủi ro số một là: nhà phân phối không xử lý kịp lượng đơn tăng đột ngột vào sáng thứ Hai. Chủ: Tuấn.

Chạy buổi kickoff thế nào

Kickoff không phải buổi thuyết trình của PM. Mục đích là phát hiện chỗ mọi người hiểu khác nhau, khi việc sửa còn rẻ.

Phần "hỏi ngược" là phần có giá trị nhất. Khi Hà nói lại "phần của tôi là test giỏ gợi ý trên điện thoại của chủ tiệm", Quân phát hiện Hà đang nghĩ tới các máy đời mới, trong khi 30% chủ tiệm dùng máy Android 4–5 năm tuổi. Phát hiện ở phút 30 của kickoff rẻ hơn rất nhiều so với phát hiện ở tuần 7.

Xem thêm kỹ năng Product Review & Kickoff Facilitation cho cách điều phối các buổi review khác trong chu kỳ.

Sau kickoff: một trang, không phải một biên bản

Đầu ra của kickoff nên vừa một trang: sáu mục ở trên, mỗi mục vài dòng. Ghim nó ở kênh chat của dự án. Mỗi khi có tranh luận về phạm vi hay ngày, quay về trang này. Nếu cần đổi, đổi công khai và ghi lý do — đừng để trang kickoff âm thầm lỗi thời.

Làm ngay

Với tính năng bạn đang làm, viết trang kickoff một trang gồm đủ sáu mục: mục tiêu bằng số (chính, phụ, bảo vệ), phạm vi kèm ba thứ không làm, hạng ra mắt dự kiến, các mốc kèm điều kiện, người sở hữu từng mảng (tên người), và ba rủi ro lớn nhất có chủ. Mục nào bạn không điền được là mục cần được chốt trong tuần này — ghi tên người bạn cần hỏi bên cạnh.