Discovery và Kickoff: tài liệu khởi đầu dự án đúng

Khoảnh khắc duy nhất quyết định một dự án sẽ ship hay sẽ trôi chính là kickoff. Nếu làm tốt, team sẽ bước vào tuần đầu tiên với cùng một ngữ cảnh và một scope đã được cam kết. Nếu làm tệ, mỗi tuần của dự án sẽ trả giá cho việc quyền sở hữu không rõ ràng. Chương này giới thiệu các câu hỏi của discovery, kickoff doc, và buổi họp 90 phút biến cái này thành cái kia.

Khi nào kickoff chính thức bắt đầu mang lại giá trị?

Có ba tín hiệu chính.

Dự án dài hơn 4 tuần. Dưới mức đó, một thread Slack đã đủ để bắt được điểm khởi đầu; nhưng vượt qua đó, bạn cần một doc đủ vững để sống sót qua bất ngờ đầu tiên.

Team không cùng nhau khởi đầu. Khi một số engineer đã tham gia discovery từ trước còn những người khác chỉ vào lúc bắt đầu, kickoff doc là cách duy nhất để chuyển ngữ cảnh đã thiếu sang cho họ.

Cam kết với nhiều stakeholder. Khi sales, legal, marketing, hoặc khách hàng bên ngoài sẽ đánh giá kết quả, bạn cần có một bản ghi viết về những gì các bên đã đồng ý. Trí nhớ con người không khớp với nhau; chỉ có tài liệu mới khớp.

Nếu bạn chỉ có 2 engineer xây một tool nội bộ để tự dùng, hãy bỏ qua kickoff và ship.

Cái giá khi bỏ kickoff là gì?

Có ba kiểu lỗi thường gặp.

Hội chứng xây-sai-thứ. Team tưởng đang xây A; sponsor lại tưởng B. Đến tuần thứ sáu, buổi demo làm lộ ra khoảng cách giữa hai bên. Mất thêm ba tuần để làm lại.

Stakeholder bất ngờ. Legal đến vào tuần thứ 6 với một yêu cầu bắt buộc phải có. Hai tuần công việc không nằm trong kế hoạch bị thêm vào.

Scope trôi từ tuần một. Khi không có scope viết ra giấy, mọi câu "có thể tiện thể..." sẽ được gộp vào trong im lặng. Đến tháng thứ hai, dự án đã to gấp đôi so với ban đầu.

Kickoff doc tối thiểu trông thế nào?

Đây là mẫu cho một dự án 6 tuần với team 5 người:

# Kickoff: {{ Tên dự án }}

## Vì sao bây giờ
Chúng ta làm dự án này vì {{ tín hiệu thị trường, đau khách, hay
quyết định chiến lược }}. Cụ thể, {{ outcome đo được mong: tăng
X Y%, giảm churn Z%, ship trước đối thủ }}.

## Thành công nhìn như
Vào {{ ngày }}, {{ trạng thái user thấy cụ thể }}, đo bằng
{{ metric và target }}.

## In scope
- {{ Capability 1 — cụ thể, demo được }}
- {{ Capability 2 }}
- {{ Capability 3 }}

## Out of scope (hoãn)
- {{ Cái rõ ràng không làm vòng này, kèm lý do }}
- {{ Item phase tương lai }}

## Vai trò (RACI cho quyết định lớn)
| Vai trò | Người | RACI cho đổi scope |
|---------|-------|--------------------|
| Sponsor | {{ tên }} | A |
| Tech Lead / PM | {{ tên }} | R |
| Engineer | {{ tên }} | R |
| Design | {{ tên }} | C |
| Legal review | {{ tên }} | C (một lần tuần 4) |

## Top 3 rủi ro
1. {{ Rủi ro + giảm thiểu + owner }}
2. {{ Rủi ro + giảm thiểu + owner }}
3. {{ Rủi ro + giảm thiểu + owner }}

## Hạn quyết định
{{ Ngày phải cam kết hoặc huỷ }}. Đến ngày đó, doc này tạm thời.

## Thời gian trial
Doc kickoff này coi như draft trong một tuần. Comment, không
đồng thuận, làm rõ scope hoan nghênh đến {{ ngày }}. Sau {{ ngày
}}, đổi scope theo quy trình change-request trong
[chương stakeholder](/tech-pm/stakeholders-and-comms).

Mệnh đề "thời gian trial" là vũ khí bí mật của template này. Nó cho team một tuần để đẩy lùi mà không có cảm giác đang thách thức sponsor một cách công khai. Phần lớn các điểm cần làm rõ hữu ích nhất sẽ xuất hiện trong cửa sổ này.

Agenda họp kickoff 90 phút trông thế nào?

# Agenda Họp Kickoff — 90 phút

00:00 - 00:10  Sponsor: vì sao dự án này tồn tại (10 phút)
00:10 - 00:25  Đi qua in-scope và tiêu chí thành công (15 phút)
00:25 - 00:40  Đi qua out-of-scope và lý do (15 phút)
00:40 - 01:00  Vòng tròn: mỗi engineer flag quan ngại (20 phút)
01:00 - 01:15  Top 3 rủi ro: chốt owner và giảm thiểu đầu (15 phút)
01:15 - 01:25  Hạn quyết định + thời gian trial giải thích (10 phút)
01:25 - 01:30  Xác nhận họp kế + status sẽ báo ra sao (5 phút)

Phần bị bỏ qua nhiều nhất chính là vòng tròn cho engineer nói. Những engineer đã xem doc nhưng không được nêu quan ngại một cách công khai sẽ lộ ra sau dưới dạng kháng cự ngầm. Hai phút cho mỗi người ngay từ đầu sẽ ngăn được điều đó.

Kickoff scale lên đa team như thế nào?

flowchart TB
    Discovery[Discovery 1-2 tuần] --> ProgKickoff[Kickoff chương trình<br/>90 phút, mọi team]
    ProgKickoff --> TeamA[Kickoff Team A<br/>90 phút]
    ProgKickoff --> TeamB[Kickoff Team B<br/>90 phút]
    ProgKickoff --> TeamC[Kickoff Team C<br/>90 phút]
    TeamA --> Plan[Planning mỗi team]
    TeamB --> Plan
    TeamC --> Plan

Cuộc kickoff cấp chương trình đặt ra "vì sao bây giờ" ở mức cao và phân rã scope cho từng team. Sau đó mỗi team chạy kickoff riêng để cam kết phần slice mà họ sở hữu. Doc kickoff ở cấp chương trình sống ở mức chương trình; còn doc kickoff team thì sống trong repo của từng team. Hai loại doc này tham chiếu lẫn nhau.

Kickoff có thể tạo ra những lỗi nào?

• Kickoff thành kịch. Doc dài lê thê không ai đọc, được trình bày suốt một giờ, rồi đem archive. Cách phòng: giữ doc dưới 1 trang; cho mọi người đọc thầm trong 5 phút đầu cuộc họp; cuộc họp dùng để thảo luận chứ không phải để đọc.
• Sponsor nói một mình. Sponsor nói tới 60 trên 90 phút. Cách phòng: cap thời gian sponsor ở 10 phút; phần còn lại là thảo luận team.
• Không có hạn quyết định. Doc tạo cảm giác mở vô tận; team không cam kết được. Cách phòng: mỗi kickoff đều phải có một ngày cụ thể để doc chuyển từ draft sang trạng thái đã cam kết.
• Bỏ qua phần out-of-scope. Khi chỉ liệt kê in-scope, ngầm hiểu là "mọi thứ khác có thể nằm trong scope". Hãy luôn viết phần out-of-scope một cách rõ ràng.

Khi nào kickoff là quá liều?

Có hai trường hợp.

Hot fix hay ứng phó sự cố. Khi mọi thứ đang cháy (xem chương incident), việc chạy kịch kickoff là phản ứng sai. Hãy triage, fix, rồi post-mortem.

Việc continuous-flow. Một team platform nhận luồng ticket đều đặn không cần kickoff cho từng ticket. Charter của team và bảng Kanban là tương đương với một kickoff vĩnh viễn.

Kickoff đáng 90 phút khi dự án có scope rõ ràng, có team, và có deadline. Dưới mức đó, các artifact nhẹ hơn vẫn chạy được.

Đi tiếp từ đây như thế nào?

Chương tiếp theo: planning và roadmap - biến kickoff doc thành một plan có phase mà team có thể thực thi. Sau đó, sprint execution sẽ nói về nhịp tuần ở bên trong plan đó.