Bạn bắt đầu tìm hiểu nguyên nhân tại sao sản phẩm của team lại không có kết quả khả quan như vậy. Có hàng tá câu hỏi bạn có thể đặt ra vào lúc này:
- Phải chăng do phần mềm có lỗi ? - bạn và team đi tìm lỗi và fix chúng
- Phải chăng do đưa phần mềm lên store này không hiệu quả ? - bạn và team đi tìm những store khác.
- Phải chăng do phần mềm chưa đủ tính năng mà user cần ?
- Phải chăng giải pháp mà phần mềm đưa ra chưa đủ tốt ?
- .................
Tất cả đều có thể xảy ra, bạn có thể mắc lỗi ở bất kì đâu, từ khâu ý tưởng đến thiết kế - đến triển khai - đến việc đưa ra thị trường.
Một điều rất hiển nhiên đó là khi bạn mắc lỗi càng ở những khâu đầu tiên trong quá trình phát triển sản phẩm, bạn càng phải trả giá đắt. Nếu bạn mắc lỗi ở khâu đưa ra thị trường, bạn chỉ cần thay đổi chiến lược phân phối. Nhưng nếu bạn sai ở phần thiết kế sản phẩm, bạn có thể phải làm lại mọi thứ từ đầu.
Do vậy càng phát hiện sớm lỗi/ sai phạm ở những giai đoạn sớm của quá trình phát triển sản phẩm phần mềm càng giúp cho sản phẩm tăng cơ hội thành công và giảm thiểu chi phí phát sinh.
Vậy vấn đề đặt ra là cần có một phương pháp triển khai nào đó để giảm thiểu nguy cơ mắc lỗi ở mọi giai đoạn của quá trình phát triển sản phẩm phần mềm.
Design Sprint là một phương pháp triển khai giúp ta làm được việc đó.
Desing Sprint là một quy trình ứng dụng trong phát triển phần mềm để giúp cho việc đánh giá và tránh gặp phải lỗi/ sai lầm ở giai đoạn sau trong quá trình phát triển sản phẩm phần mềm. Mỗi sprint bao gồm 5 ngày để:
- Understand : hiểu vấn đề. Vấn đề về mục tiêu kinh doanh, mục tiêu của sản phẩm, nhu cầu của người sử dụng (tìm hiểu về thị trường).
- Diverge : Đưa ra mọi giải pháp khả dĩ mà có thể đáp ứng nhu cầu của người sử dụng.
- Decide: Lựa chọn một giải pháp/ ý tưởng để thực hiện.
- Prototype: Xây dựng bản mẫu để đánh giá
- Validate: Đánh giá sản phẩm, ý tưởng, giải pháp. Lắng nghe ý kiến từ những người sử dụng thật sự, từ những chuyên gia, hoặc từ các thành viên trong team.
Thông thường sẽ rất khó để có thể áp dụng được phương pháp này vì thời gian yêu cầu rất chặt chẽ và thường khá gấp, tuy nhiên tùy vào tổ chức/ team mà có thể áp dụng phương pháp này bằng việc đặt sprint lớn hơn, không phải 5 ngày mà có thể là 10 ngày , 15 ngày,.....
Kết:
Nếu bạn đang có một ý tưởng muốn triển khai thành một sản phẩm phần mềm hoàn chỉnh và đặc biệt nếu bạn là một lập trình viên thì phương pháp này sẽ rất hữu ích cho bạn giúp bạn tránh các lỗi ở những giai đoạn đầu tiên của sản phẩm. Bạn sẽ tăng cơ hội đưa ra sản phẩm tốt, phù hợp với nhu cầu của người sử dụng hơn.
Đặc biệt với các lập trình viên, thông thường sẽ tập trung vào việc coding sản phẩm nhiều hơn nên dễ gặp vấn đề với nhu cầu thực tế của người dùng, giải pháp chưa thật sự phù hợp,.... Với phương pháp này các bạn có thể sẽ đánh trọng số tốt hơn, đều hơn vào tất cả các khâu trong quá trình xây dựng sản phẩm, tạo ra một sản phẩm tốt hơn, phù hợp với thực tiễn hơn và tăng cơ hội thành công hơn.
0 Comments:
Post a Comment