Cuốn sách “Khởi nghiệp tinh gọn” hướng dẫn nhiều điều bổ ích trong quá trình khởi nghiệp. Ngay trong tiêu đề đã nói rằng khởi nghiệp thì nên tinh gọn, đừng màu mè hoành tráng,… Một số tinh thần của cuốn sách này là:

• Tiết kiệm chi phí tối đa khi làm sản phẩm vì nếu sản phẩm thất bại thì vẫn còn tiền để làm lại
• Tập trung vào làm sản phẩm, đừng quan tâm đến những cái râu ria như văn phòng hoành tráng, chức danh lãnh đạo
• Sớm đưa ra sản phẩm prototype cho khách hàng trải nghiệm và đánh giá, đừng đợi đến khi hoàn hảo vì rất lâu
• Việc đánh giá của khách hàng quan trọng hơn ý kiến của team founder vì làm sản phẩm để bán cho khách chứ không phải để tự dùng
• Điều chỉnh kế hoạch là việc phải làm liên tục, kế hoạch đưa ra ban đầu cho dù nghe có vẻ hoàn hảo nhưng ra thực tế sẽ khác
• …

Những lời khuyên này phù hợp với người/đội ngũ làm ra sản phẩm mới chưa từng có trên thị trường. Trải qua nhiều dự án về sản xuất phần mềm mới theo yêu cầu của quý khách chúng tôi rút ra được 1 số kinh nghiệm. Nay chúng tôi chia sẻ để có góc nhìn chung về phương pháp để thực hiện thành công dự án phần mềm.

Quy trình ngược: viết phần mềm prototype rồi mới làm bản design chức năng sau

Quy trình trước giờ là lập 1 kế hoạch & chức năng hoàn chỉnh cho phần mềm, từ đó lập trình theo. Khi làm xong các chức năng theo bản mô tả là nghiệm thu, cách này có 1 số nhược điểm sau:

• Nếu có chức năng sai do hiểu sai ý người dùng thì rất lâu mới phát hiện & sửa cũng lâu
• Muốn bổ sung chức năng lại phải đi theo quy trình: phân tích -> thiết kế -> báo giá -> lập trình -> chuyển giao. Quy trình này khá chậm & tốn nhiều chi phí
• Ước lượng chi phí dựa theo bản mô tả => phát sinh nhỏ vẫn thêm tiền.

Thực tế thì 100% phần mềm đều phát sinh & điều chỉnh, việc đội chi phí sẽ làm cho phần mềm dang dở và bỏ phí tiền đã làm trước đó. Đạt được 80-90% nhưng vẫn không dùng được vì bất tiện hoặc đòi hỏi phải thêm thao tác bên ngoài.

“Quy trình ngược” của chúng tôi sẽ là viết bản mô tả ngắn gọn, sau đó viết phần mềm với chức năng chính để thảo luận. Sau khi đã có khung sườn thì chốt phương án, tính năng và lập trình các chức năng phụ, cuối cùng mới là viết các chức năng thực hiện vào bản thiết kế cuối cùng.

“Quy trình ngược” sẽ giúp cho phần mềm linh hoạt, dễ điều chỉnh vì bám sát thực tế chứ không bám theo bản design.

Áp dụng tinh thần Agile

Tinh thần Agile trong phần mềm nói rằng: sớm đưa bản mẫu cho khách hàng để đánh giá, thông thường là 2 tuần sẽ gửi 1 phiên bản mới. Chúng tôi đang áp dụng tinh thần đó, thậm chí đôi khi còn nhanh hơn.

Trong thực tế những dự án đã qua thì việc triển khai sớm để khách hàng đánh giá thực hiện theo các quy tắc sau:

• Khi có lỗi thì cứ thông báo, không cần đợi nhiều rồi báo luôn 1 lượt. VD phần mềm có 5 bug, đừng đợi 5 bug mới báo mà báo từ bug 1, vì khi đó mới xảy ra bug thứ 2,3,4,5..
• Sau khi bàn giao phiên bản mới thì khách hàng test tính năng & cty lập trình sẽ viết tính năng khác
• Tạo kênh kết nối từ người dùng trực tiếp đến cty lập trình, giảm bớt khâu trung gian để tránh tam sao thất bổn
• …

Kết luận

Phần mềm là sản phẩm dễ thất bại, theo nhiều nghiên cứu thì tỷ lệ rất cao từ 80-95% là thất bại (tùy theo định nghĩa thế nào là thất bại). Do đó việc quan trọng là phải có sự linh hoạt cao giữa 2 bên: khách hàng và cty lập trình để phần mềm đáp ứng được người dùng.

Với kinh nghiệm làm nhiều sản phẩm thành công, áp dụng hàng ngày cho các cty doanh nghiệp khách hàng thì chúng tôi có thể giúp quý khách có được những sản phẩm hữu dụng, đáp ứng được công việc của mình.