- Nhiều công ty bị chậm tốc độ phát triển vì vướng vào các quy trình phức tạp hoặc yêu cầu dài dòng, nhưng điều thực sự quan trọng là nhanh chóng tạo ra ‘đúng sản phẩm’
- Nếu loại bỏ những yếu tố không cần thiết trong quá trình phát triển sản phẩm, tốc độ phát triển có thể tăng lên rất nhiều. Việc tạo ra đúng sản phẩm về bản chất là một quá trình nhanh
- Những thứ làm chậm tốc độ của đội ngũ sản phẩm là các yếu tố không cần thiết như quy trình, khoảng cách giữa người ra quyết định và người thực thi, các bản đặc tả quá mức
[Các nguyên tắc cho Product Velocity]
1. Cần ‘làm ít hơn’
- Thông thường tồn tại sự đánh đổi giữa tốc độ và chất lượng
- Phần lớn công ty xác định yêu cầu và thời hạn, rồi xem chất lượng là đầu ra; còn chúng tôi làm ngược lại: đặt ra tiêu chuẩn chất lượng trước và suy nghĩ xem có thể phát hành gì trong vòng 60 ngày
- Điều quan trọng không phải là cố đáp ứng mọi yêu cầu, mà là nhanh chóng hoàn thành những thứ quan trọng
- Loại bỏ bớt yêu cầu và chỉ làm những việc cần thiết có thể nâng cao cả tốc độ lẫn chất lượng
- Elon Musk cũng đề xuất cách tiếp cận tương tự khi nói rằng: “trước hết hãy làm cho các yêu cầu bớt ngu ngốc đi”
2. ‘Chế độ ngốc nghếch’ thường khá hiệu quả
- Lấy ‘midwit meme’ làm ví dụ: người thông minh và kẻ ngốc thường đồng ý với một lời giải đơn giản, trong khi người tầm tầm lại tạo ra vấn đề phức tạp không cần thiết.
- Chúng tôi thường tiếp cận vấn đề bằng ‘chế độ ngốc nghếch’, cố tìm giải pháp đơn giản thay vì nghĩ quá phức tạp.
- Khi mắc sai lầm, đa phần là vì đã suy nghĩ quá nhiều; cách đơn giản thường hiệu quả hơn
- Tự hỏi “nếu mình là kẻ ngốc thì mình sẽ làm thế nào?” thường giúp đi tới một giải pháp có thể thực thi
3. Không phải mọi vấn đề đều quan trọng
- Chỉ có một số ít vấn đề là thực sự rất quan trọng. Những vấn đề quan trọng như bảo mật thì nhất định phải giải quyết, nhưng không cần giải quyết tất cả mọi vấn đề.
- Ví dụ, UI trên di động không tốt, nhưng vì khách hàng hầu như không dùng di động nên chúng tôi không cải thiện nó.
- Những vấn đề mà khách hàng không quá bận tâm như vậy có thể bị bỏ qua.
4. Cứ thế mà làm
- Chúng tôi không có quy trình cho phát triển sản phẩm. Không làm mockup Figma, PRD, design system, Agile, OKR, product roadmap rõ ràng, A/B testing hay growth hacking
- Vì khách hàng là kỹ sư, chúng tôi kỳ vọng các kỹ sư của mình có thể xử lý luôn sản phẩm, thiết kế và những việc tương tự
- Chúng tôi thích cách nhanh chóng làm ra sản phẩm rồi quan sát phản ứng của khách hàng
5. Chỉ viết lại khi cần
- Các công ty thường nghĩ rằng càng trì hoãn technical debt lâu thì càng có thể đi nhanh hơn, nhưng chúng tôi không ngại thực hiện những đợt viết lại quy mô lớn khi cần
- Đôi khi con đường nhanh nhất để làm ra thứ đúng đắn là làm ra thứ sai, nhận ra nó sai, rồi thay thế bằng thứ đúng
- Nếu việc xóa technical debt có vẻ hữu ích, chúng tôi sẽ làm vậy
6. Nếu có thể thì thuê ngoài
- Nếu có thể, chúng tôi mua giải pháp từ vendor bên ngoài thay vì tự làm trong nội bộ. Ví dụ, chúng tôi tạo SDK thông qua một công ty tên là Fern
- Tất nhiên, sử dụng nhà cung cấp đòi hỏi chi phí ban đầu đáng kể và hạn chế mức độ tự do, nhưng nhìn chung đó là lựa chọn đúng
- Tài nguyên kỹ thuật của chúng tôi rất hạn chế và đắt đỏ; một tuần làm việc của kỹ sư tốn khoảng 5.000 USD. Nếu tính cả chi phí cơ hội, giá trị đó còn cao hơn nhiều
- Số thứ thực sự đáng để tự xây là tương đối ít
7. Không tuyển dụng
- Chúng tôi không kỳ vọng rằng tăng nhân sự sẽ làm tăng sản lượng của đội. Tuyển dụng thì chậm và khó, còn onboarding và quản lý con người lại tiêu tốn thời gian
- Đặc biệt khó để đưa về những người giỏi có thể đóng góp mà không cần nhiều hỗ trợ
- Vì vậy, dù có đủ nguồn lực để xây một đội ngũ kỹ sư lớn, chúng tôi vẫn cố gắng hết sức để giữ quy mô nhỏ. Điều đó khiến cuộc sống dễ dàng hơn rất nhiều
Suy nghĩ kết lại
- Chúng tôi nhận ra, ở mức độ mà trước đây mình chưa từng hiểu, rằng phát triển sản phẩm không nên mất nhiều thời gian đến thế
- Nếu biết khách hàng cần gì, có một đội ngũ mạnh và loại bỏ các yếu tố không cần thiết gây xao nhãng, bạn có thể phát triển sản phẩm với tốc độ rất cao
10 bình luận
Tôi cũng lại vào xem đây. Hẹn gặp lại lần sau.
Đọc đi đọc lại vẫn thấy hay.
?? Thật lý tưởng một cách đáng kinh ngạc.
Chi phí quản lý việc thuê ngoài và cả nguồn lực phải bỏ vào đó hẳn cũng không hề nhỏ... nhưng nhìn chung thì đây vẫn là một lời khuyên rất tuyệt vời.
Người ta luôn nói hãy dùng thuê ngoài. Nhưng dường như hiếm khi thấy ai nói rằng khi dùng thuê ngoài thì cần phải làm thế nào.
Nếu chỉ chuyển một bản phác thảo đơn giản mà không có bức tranh dịch vụ rõ ràng, thì người ta lại không nhận ra rằng sẽ nhận về những thứ còn tệ hơn cả tưởng tượng....
???: Hãy làm cho nó nhanh, nhưng đừng theo kiểu agile.
Tôi nghĩ điều đó khả thi khi sản phẩm đã rõ ràng
Khi những gì cần làm đã rõ ràng thì cảm giác như không cần thêm thiết kế nào vượt quá mức đó
"Trước hết, hãy làm cho các yêu cầu bớt ngớ ngẩn hơn"
Nếu một ngày nào đó bên gia công biến mất... không bắt máy thì hu hu
Dù là phát triển nội bộ đi nữa, nếu đến một ngày mọi người đều nghỉ việc hết thì tình huống chẳng phải cũng sẽ tương tự sao..?