"Nếu bạn không cảm thấy xấu hổ về phiên bản đầu tiên của sản phẩm mình, bạn đã ra mắt quá muộn." — Reid Hoffman Tại Splits, chúng tôi tuân theo cách tiếp cận này để xây dựng phần mềm: làm cho nó hoạt động → làm cho nó đúng → làm cho nó nhanh. Thứ tự là rất quan trọng. Đây là những gì chúng tôi đã học được khi giao hàng ở mỗi giai đoạn:

Làm cho nó hoạt động = nguyên mẫu chức năng. Nó nên thô sơ. Nó nên không hoàn hảo. Đưa nó đến tay người dùng nhanh chóng. Cách chúng ta xác định phạm vi MVP: 1) Liệt kê mọi thứ mà chúng ta nghĩ có thể quan trọng hoặc liên quan đến dự án. 2) Điều gì là *tối thiểu tuyệt đối* từ danh sách này mà chúng ta có thể hoàn thành và có một nguyên mẫu chức năng?

Làm cho nó đúng = sửa tất cả những phần bị hỏng. Bước vào giai đoạn này với những tín hiệu rõ ràng từ thị trường: phản hồi nhất quán, sự sử dụng ngày càng tăng mặc dù có những thiếu sót rõ ràng. Bây giờ bạn đã kiếm được quyền đầu tư nhiều nguồn lực hơn.

Làm cho nó nhanh = tối ưu hóa hiệu suất. Thật lòng mà nói, chúng tôi vẫn đang học hỏi về giai đoạn này. Hầu hết các đội hiện đang ở chế độ "làm cho đúng" 🤷‍♂️ Nhưng đây là nguồn cảm hứng thúc đẩy chúng tôi:

Tại sao cách tiếp cận này hiệu quả: Sắp xếp là chiến lược. Những gì bạn học hôm nay sẽ hình thành những gì bạn xây dựng vào ngày mai. Bỏ qua và bạn sẽ không có thông tin cần thiết để giải quyết vấn đề một cách chính xác. Hành động tạo ra thông tin. Nhưng hành động *có chủ đích* tạo ra thông tin *hữu ích hơn*.

Cái bẫy là cố gắng làm cho mọi thứ đúng trong khi bạn đang cố gắng làm cho nó hoạt động. KHÔNG. "Hãy cho phép bản thân bạn gửi đi một cái gì đó mà bạn biết là không đúng." — @wminshew