Một năm sau khi đóng băng cái blog, mình muốn bắt đầu lại, mình muốn chia sẻ với mọi người bằng những case study thực tế trong quá trình mình làm việc. Việc viết này cũng có nghĩa giúp mình review lại bản thân sau nhiều năm làm “thợ code”…
Tại sao nên đọc bài này?
- Phân vân giữa làm nhanh để ra sản phẩm hay làm chắc để tránh rủi ro? ⚖️
- Thành tựu và bài học từ những lần “đi nhanh” và cách làm tốt hơn. 📚
Để mà nói thì mình là một người rất thích xây dựng sản phẩm từ con số 0 (build 1 product from scratch), và thật may là sau khi ra trường (ngay đợt dịch covid), mình được join ngay vào một dự án giáo dục chưa có hình hài gì cả. Với cái máu thích thể hiện của tuổi trẻ thì mình luôn push bản thân hoàn thành các task khá nhanh, nhưng…
Mọi thứ trở nên lộn xộn khi dự án lớn dần 🌀
Ban đầu, dự án chỉ là những ý tưởng sơ khai để phục vụ việc học remote của học sinh dễ dàng hơn, giáo viên được “trao” nhiều quyền lực hơn trong việc điều hành lớp học. Team mình chạy khá nhanh để release một phiên bản MVP (Minimum Viable Product) trong thời gian ngắn. Những kiến thức ở trường – như viết tài liệu kỹ thuật, thiết kế hệ thống, hay quy trình phát triển chuẩn – gần như bị bỏ qua. Quy trình làm việc lúc đó đơn giản đến mức: ý tưởng → story lớn → task nhỏ → code. 📝
Task thường chỉ có tiêu đề, kiêm luôn phần mô tả, như “Làm chức năng đăng nhập”. Cả team làm việc mà không có quy trình rõ ràng, tài liệu thì hiếm hoi. Mục tiêu duy nhất là: “Ra sản phẩm càng sớm càng tốt.” 🏃♂️
Sau khi release MVP, phản hồi từ khách hàng cho thấy cần cải thiện nhiều. Sau thời gian không có chiến lược mà chỉ cứ tập trung vào implement các feature thật nhanh và thật nhiều. Hệ thống bắt đầu khó bảo trì, codebase trở nên rối rắm và đầy bug 🐞 Điều này thực sự quan trọng vì đến sản phẩm cần gain khách hàng và cần sự “ổn định”. Sản phẩm chỉ ở mức “runable” chứ “useable” thì NO.
Case study của mình: Bài học từ hệ thống bán vé 🛠️
Ngoài dự án chính ở cty, mình từng nhận một đơn hàng thiết kế hệ thống bán vé trong 3 tuần, bao gồm: website bán vé, bảng quản trị (admin), và ứng dụng quét mã QR để duyệt vé vào cổng. Mục tiêu là hoàn thành nhanh để khách hàng có thể sử dụng ngay. Với thời gian gấp rút, mình ưu tiên làm nhanh các thành phần chính. Website và admin được hoàn thành chỉ trong 2 tuần, website cực kì cực kì đơn giản nhưng nó đủ để người dùng mua vé trực tiếp trên web thay vì phải gọi điện qua hotline và phải có người trực. Tuy nhiên, ứng dụng quét QR thì phải đợi tới 3 tuần sau nữa mới được duyệt trên store, dù chức năng chỉ là quét mã QR và tất nhiên vì nó thiếu chức năng nên bị reject, nhưng không ảnh hưởng đến việc bán vé lắm nên vẫn OK😅
Kết quả? Hệ thống chạy ổn vì quá là đơn giản mà, khách hàng bắt đầu thay thế việc đặt vé truyền thống qua hotline bằng việc đặt qua website. Quan trọng hơn, thiết kế ban đầu đủ linh hoạt để có thể mở rộng sau này, như thêm tính năng voucher, phân phối vé cho các đại lý, và có thể bán vé cho nhiều loại show khác nhau…
Bài học rút ra: Làm nhanh nhưng phải có nền tảng vững chắc giải quyết được nhu cầu cốt lõi của khách hàng trước, có tiền trước đã hẹ hẹ. Dù thời gian ngắn, việc ưu tiên các tính năng cốt lõi và thiết kế có khả năng mở rộng giúp tiết kiệm thời gian và tránh rắc rối về sau. 🛤️ Thực ra mình đánh giá nó cũng chỉ dừng ở mức “runable” thôi, tuy nhiên nó giải quyết được vấn đề trước mắt của khách hàng, khả thi trước đã rồi “hoàn hảo” tính sau.
Ngoài lề: Có thể các bạn cũng biết những show như In The Moonlight, Soul of The Forest (hiện tại đã do bên khác phân phối), Dear Ocean, Isle Of Art, HayFest, Skynote (Quốc Thiên), … đều được phân phối vé từ nền tảng mình build cho khách hàng, mỗi chương trình đều có cách hoạt động / phân phối vé khác nhau nhưng hệ thống hiện tại khá dễ scale và đáp ứng được hầu hết các requirement từ chương trình.
Muốn nhanh? Bắt đầu từ cái đơn giản! 🌱
Dựa trên kinh nghiệm từ dự án bán vé và các dự án khác, mình nhận ra rằng: Đừng cố làm mọi thứ hoàn hảo ngay từ đầu. Thay vào đó, hãy làm đơn giản nhưng hiệu quả:
- Xây prototype gọn nhẹ: Chỉ tập trung vào các tính năng cốt lõi, như website bán vé và admin trong dự án của mình, để thử nghiệm ý tưởng. 🧪
- Lấy phản hồi sớm: Đưa sản phẩm đến người dùng nhanh, chỉ thay đổi, update những tính năng thực sự cần thiết 📣 ví dụ như việc admin cần chức năng tặng vé, gửi vé dành cho khách VIP
- Cải thiện dần: Dựa trên phản hồi, nâng cấp từng bước
Quan trọng nhất, nhanh không có nghĩa là ẩu. Một sản phẩm tốt cần sự cân bằng giữa tốc độ và chất lượng. Những lần chạy deadline, như dự án bán vé, đã dạy mình rằng làm nhanh nhưng đúng trọng tâm sẽ giúp sản phẩm vừa ra mắt kịp thời, vừa có tiềm năng mở rộng. 💡
Chất và lượng: Cân bằng là chìa khóa ⚖️
Làm nhanh để ra sản phẩm sớm là lợi thế lớn của startup. Nhưng nếu không có kế hoạch, codebase sẽ nhanh chóng trở nên rối rắm, khó bảo trì, và đầy bug. 🐞 Những đoạn code viết vội trong giai đoạn MVP bắt đầu lộ hạn chế: không thể mở rộng, sửa đổi mất thời gian, và lỗi thì xuất hiện liên tục. 😓 Bài học ở đây: Tốc độ không thể hy sinh chất lượng. Một sản phẩm tốt cần cả hai.
Làm nhanh nhưng đúng trọng tâm 🎯
Trong môi trường startup, tốc độ là yếu tố sống còn. Nhưng làm nhanh không có nghĩa là làm cẩu thả. Sau vài lần “trả giá” vì chạy theo deadline, mình bắt đầu thay đổi cách làm việc:
- Ưu tiên tính năng cốt lõi: Tập trung vào những gì quan trọng nhất thay vì cố làm tất cả. 🔍
- Quy trình tối thiểu: Một luồng làm việc cơ bản – từ ý tưởng, chia task, review code, đến test – giúp team không bị rối. 📋
- Viết code tái sử dụng: Đầu tư vào các module chung để tiết kiệm thời gian về sau. 🔄
- Document ngắn gọn: Một tài liệu mô tả kiến trúc hệ thống hoặc mục đích module sẽ giúp cả team dễ dàng làm việc hơn. 📄
Hi vọng post đầu này mình viết các bạn “non-tech” cũng có thể hiểu được, mình rất tâm huyết với hệ thống bán vé nên chắc sắp tới sẽ viết nhiều hơn về chủ đề này hoặc là “tốc độ”…