Emergent đưa bạn tới một ứng dụng đã triển khai nhanh hơn bất cứ thứ gì khác trên trang này. Rủi ro không nằm ở ngày đầu — mà ở tuần thứ hai, khi phản hồi thật đầu tiên xuất hiện và mọi thay đổi đều tốn credit vì phần nền chưa bao giờ được quyết định một cách có chủ đích.
Đây là trình tự tránh điều đó, dùng Emergent (8.1) làm cỗ máy dựng.
Bước 0 — xác định bạn đang kiểm chứng điều gì
MVP tồn tại để trả lời một câu hỏi. Hãy viết câu hỏi đó ra trước khi viết đặc tả: người ta có đăng ký không, có đi hết luồng này không, có trả tiền không.
Điều này quyết định thứ bạn có thể yên tâm bỏ ra ngoài, và đó là đòn bẩy lớn nhất lên chi phí. Mọi tính năng không phục vụ câu hỏi đều là credit tiêu cho thứ bạn sẽ vứt đi.
Bước 1 — viết đặc tả, kèm cả ranh giới
Mô tả ứng dụng bằng ngôn ngữ bình thường, nhưng ghi rõ cả phần phủ định: nó không cần gì, trường hợp nào được phép hỏng xấu xí, cái gì tạm thời làm thủ công.
Đặc tả mơ hồ là nguyên nhân chính của việc làm lại, và làm lại là chỗ credit đi mất. Một trang đặc tả rõ ràng rẻ hơn ba vòng sửa, và đó là khác biệt giữa một bản dựng dự đoán được với một hoá đơn bất ngờ.
Hãy đưa cả mô hình dữ liệu vào. Quyết các thực thể và quan hệ ngay từ đầu giúp tránh nhóm thay đổi muộn đắt nhất, vì sửa schema sẽ lan ra mọi thứ đã sinh ra trước đó.
Bước 2 — dựng theo lát cắt, không phải một yêu cầu duy nhất
Hãy yêu cầu một lát cắt dọc hẹp trước: một luồng, từ đầu tới cuối, với xác thực thật và lưu trữ thật. Đưa nó lên chạy được rồi mới mở rộng.
Cách này cho bạn tín hiệu sớm về việc kiến trúc được sinh ra có sống chung được không, ở thời điểm mà đổi hướng còn rẻ. Một yêu cầu lớn duy nhất sinh ra cả ứng dụng cũng đồng thời sinh ra cả một ứng dụng bạn chưa hề review.
Bước 3 — export sang GitHub ngay khi nó chạy
Emergent tích hợp GitHub và bạn có thể host code ở đâu tuỳ ý. Hãy dùng điều đó sớm chứ đừng để tới cuối.
Hai lý do. Thứ nhất là quyền sở hữu: MVP của bạn không còn phụ thuộc vào thiện chí của một nền tảng. Thứ hai là kinh tế: khi code đã nằm trong repo, lập trình viên sửa một lỗi nhỏ tốn thời gian của họ chứ không tốn credit, mà lỗi nhỏ thì giai đoạn này lúc nào cũng có.
Bước 4 — định trước điểm bàn giao
Hãy viết ra điều kiện mà từ đó thứ này thôi là dự án Emergent và trở thành một codebase bình thường — khách hàng trả tiền đầu tiên, một mốc số người dùng, thời điểm nó giữ dữ liệu mà mất đi thì bạn xấu hổ.
Các đội không định trước điều này thường phát hiện ra nó muộn, và thường là trong lúc đang có sự cố. Chuyển giao có kế hoạch thì rẻ hơn nhiều.
Bước 5 — review code được sinh ra trước khi nó trở nên quan trọng
Hãy để ai đó đọc nó khi rủi ro còn thấp. Bạn tìm những thứ gây đau về sau: cách xử lý khoá bí mật, xác thực có thật không, mô hình dữ liệu có sống nổi qua tính năng tiếp theo không.
Bạn không cần phải thích đoạn code đó. Bạn cần biết mình đang có gì, vì "chưa ai đọc cái này" là vị thế rất tệ khi lần đầu nó hỏng.