Thuê làm app 100 triệu nhưng 6 tháng không xong: Bài học quản lý dự án
Câu chuyện này quen thuộc đến mức đau lòng: bạn thuê một đội ngũ phát triển app, ký hợp đồng 100 triệu VND, timeline 3 tháng. Tháng thứ 3 — “gần xong rồi anh, cần thêm 2 tuần”. Tháng thứ 4 — “phát sinh thêm tính năng, cần thêm 30 triệu”. Tháng thứ 6 — app vẫn đầy bug, bạn đã đốt 150 triệu, và cảm giác như đang ném tiền qua cửa sổ.
Dự án app thất bại không phải hiếm — theo thống kê, 70% dự án phần mềm trên thế giới không hoàn thành đúng timeline và budget. Tại Việt Nam, con số có thể còn cao hơn.
Bài viết này phân tích nguyên nhân gốc rễ và đưa ra 7 bước cụ thể giúp bạn tránh lặp lại sai lầm này.
1. Tại sao dự án app thất bại?
1.1. Nguyên nhân từ phía khách hàng (chủ doanh nghiệp)
Yêu cầu không rõ ràng:
- “Tôi muốn app giống Grab nhưng đơn giản hơn” — “đơn giản hơn” nghĩa là gì?
- Không có tài liệu mô tả tính năng chi tiết
- Thay đổi yêu cầu liên tục trong quá trình phát triển
- Thêm tính năng mới mà không chấp nhận tăng chi phí/timeline
Kỳ vọng không thực tế:
- “App cần làm xong trong 1 tháng”
- “Ngân sách 30 triệu nhưng muốn tính năng của app 200 triệu”
- “App phải giống hệt Shopee”
Không tham gia vào dự án:
- Giao hết cho developer rồi “biến mất” 2-3 tháng
- Không review sản phẩm theo từng giai đoạn
- Không cung cấp content, hình ảnh, thông tin cần thiết kịp thời
1.2. Nguyên nhân từ phía developer/agency
Nhận dự án vượt quá năng lực:
- Team 2 người nhận dự án cần 5 người
- Không có kinh nghiệm với loại app khách yêu cầu
- Không có designer — developer tự thiết kế UI
Báo giá thấp để “lấy deal”:
- Biết dự án cần 150 triệu nhưng báo 80 triệu để thắng
- Khi làm phát sinh → xin thêm tiền hoặc cắt giảm chất lượng
Quản lý dự án kém:
- Không có project manager
- Không có timeline rõ ràng
- Không update tiến độ cho khách
- Không có quy trình test
1.3. Nguyên nhân từ cả hai phía
Scope creep (phạm vi dự án phình to):
Đây là “kẻ giết dự án” số 1. Bắt đầu với 10 tính năng, kết thúc với 30 tính năng. Mỗi tính năng “nhỏ” thêm 5-10 ngày phát triển.
| Tính năng gốc | ”Thêm nho nhỏ” | Thời gian thêm | Chi phí thêm |
|---|---|---|---|
| Đăng ký/Đăng nhập | + Đăng nhập bằng Zalo, Apple | 3-5 ngày | 5-8 triệu |
| Chat cơ bản | + Gửi hình, voice, video call | 10-15 ngày | 15-25 triệu |
| Thanh toán | + Ví điện tử, trả góp | 5-8 ngày | 8-12 triệu |
| Thông báo | + Notification tuỳ chỉnh, scheduled | 3-5 ngày | 5-8 triệu |
| Report cơ bản | + Dashboard realtime, export Excel | 5-8 ngày | 8-15 triệu |
| Tổng scope creep | 26-41 ngày | 41-68 triệu |
2. Timeline thực tế vs kỳ vọng
Kỳ vọng của khách hàng
| Phase | Kỳ vọng | Thực tế |
|---|---|---|
| Phân tích yêu cầu | 2-3 ngày | 1-2 tuần |
| Thiết kế UI/UX | 1 tuần | 2-4 tuần |
| Lập trình | 4-6 tuần | 8-16 tuần |
| Testing | 2-3 ngày | 2-4 tuần |
| Launch | 1 ngày | 1-2 tuần |
| Tổng | 6-8 tuần | 14-28 tuần |
Tại sao lập trình luôn lâu hơn estimate?
The Planning Fallacy: Con người có xu hướng đánh giá thấp thời gian cần thiết cho bất kỳ công việc nào. Developer cũng không ngoại lệ.
Quy tắc ngón tay cái:
- Developer nói “1 tuần” → thực tế 2 tuần
- Developer nói “đơn giản” → thực tế trung bình
- Developer nói “phức tạp” → thực tế rất phức tạp
Lý do cụ thể:
- Edge cases (trường hợp ngoại lệ) chiếm 80% effort
- Bug fixing tốn 30-40% tổng thời gian
- Integration với bên thứ ba luôn có vấn đề
- Chờ feedback từ khách hàng
- Team member nghỉ ốm, nghỉ phép
3. Dấu hiệu dự án sắp thất bại
Nhận biết sớm để can thiệp:
Dấu hiệu từ developer
- Không demo sản phẩm sau 2-3 tuần: Nếu sau 2-3 tuần không có gì để show, dự án có vấn đề
- “Gần xong rồi” kéo dài: Gần xong nhưng 90% → 95% → 98% → mãi không 100%
- Lý do delay liên tục thay đổi: Lúc do server, lúc do API, lúc do thiết kế
- Không cho xem code hoặc staging: Có thể chưa bắt đầu code
- Đội ngũ thay đổi: Developer chính nghỉ việc, người mới phải học lại
Dấu hiệu từ quy trình
- Không có tài liệu: Không có SRS, wireframe, hoặc project plan
- Communication kém: Hỏi 3 ngày mới trả lời
- Không có weekly update: Bạn phải chủ động hỏi mới biết tiến độ
- Không có demo/sprint review: Không ai show sản phẩm đang phát triển
4. 7 bước quản lý dự án app hiệu quả
Bước 1: Document yêu cầu chi tiết trước khi bắt đầu
Tài liệu cần có:
- User Stories: “Là khách hàng, tôi muốn [tính năng] để [lợi ích]”
- Wireframe hoặc mockup (có thể dùng Balsamiq, Figma miễn phí)
- Danh sách tính năng chia theo priority (Must-have / Nice-to-have / Future)
- Acceptance criteria: thế nào là “xong”?
Chi phí cho phase này: 5 - 15 triệu VND (thuê BA hoặc PM) ROI: Tiết kiệm 30-50% chi phí dự án tổng thể
Bước 2: Chọn đúng đối tác phát triển
Checklist đánh giá agency:
- Portfolio: Đã làm app tương tự chưa? (xin link App Store/Play Store)
- Team size: Đủ người cho dự án không? (tối thiểu 3: designer + developer + tester)
- Process: Có quy trình rõ ràng không? Dùng Agile hay Waterfall?
- Communication: Response time bao lâu? Dùng tool gì?
- References: Có thể liên hệ khách hàng cũ không?
- Maintenance: Sau launch hỗ trợ thế nào?
Bước 3: Ký hợp đồng rõ ràng
Hợp đồng PHẢI có:
- Scope chi tiết (danh sách tính năng kèm mô tả)
- Timeline theo milestones cụ thể
- Thanh toán theo milestones (không trả 100% trước)
- Quy trình xử lý change request (CR)
- Điều khoản delay/penalty
- Quyền sở hữu source code
- Warranty period sau bàn giao
- Exit clause nếu dự án không như ý
Phương thức thanh toán khuyến nghị:
- 20% khi ký hợp đồng
- 20% sau khi hoàn thành design
- 30% sau khi hoàn thành development
- 20% sau khi testing xong
- 10% sau 1 tháng vận hành ổn định
Bước 4: Áp dụng Agile/Scrum
Chia dự án thành sprints 2 tuần. Mỗi sprint:
- Planning: Đầu sprint, chọn tính năng làm trong 2 tuần
- Daily standup: Update ngắn 15 phút mỗi ngày (hoặc 3 lần/tuần)
- Demo: Cuối sprint, developer demo những gì đã làm
- Review: Bạn review, feedback, approve hoặc yêu cầu sửa
Lợi ích: Mỗi 2 tuần bạn thấy sản phẩm tiến triển. Phát hiện vấn đề sớm, không đợi đến tháng thứ 6 mới biết.
Bước 5: Dùng tool quản lý dự án
| Tool | Miễn phí | Phù hợp cho |
|---|---|---|
| Trello | Có | Dự án nhỏ, đơn giản |
| Notion | Có | Documentation + task management |
| Jira | Có (10 users) | Dự án lớn, Agile |
| Linear | Có (nhỏ) | Startup, modern UI |
| Asana | Có | Project management tổng quát |
Yêu cầu agency sử dụng tool và cho bạn quyền truy cập để theo dõi tiến độ.
Bước 6: Test liên tục, không đợi cuối
- Mỗi sprint: Test tính năng vừa hoàn thành
- Alpha testing: Team nội bộ test toàn bộ app
- Beta testing: 10-20 users thật test trước launch
- UAT (User Acceptance Testing): Bạn (khách hàng) test và ký xác nhận
Đừng bao giờ nhận bàn giao mà chưa test. Yêu cầu developer sửa hết bug critical trước khi thanh toán đợt cuối.
Bước 7: Plan cho sau launch
Dự án app KHÔNG kết thúc khi launch. Cần budget cho:
- Bug fixes 30 ngày đầu (warranty period)
- Server monitoring
- Analytics setup và tracking
- Feature updates dựa trên user feedback
- OS compatibility updates
5. Khi dự án đã “đi sai hướng” — làm gì?
Option 1: Cứu dự án hiện tại
Khi nào nên cứu:
- Đã hoàn thành trên 60%
- Chất lượng code chấp nhận được
- Vấn đề chính là communication, không phải năng lực
Cách cứu:
- Họp “reset” với developer: đồng ý scope cuối cùng, timeline mới
- Thuê PM bên ngoài giám sát (5-10 triệu/tháng)
- Ký phụ lục hợp đồng với scope và timeline mới
- Weekly demo bắt buộc
Option 2: Chuyển đối tác (khi dự án dưới 40%)
Khi nào nên chuyển:
- Code quality tệ (đánh giá bởi bên thứ ba)
- Developer không responsive
- Đã delay quá 2x timeline ban đầu
- Chi phí phát sinh vượt 50% ban đầu
Cách chuyển:
- Yêu cầu bàn giao source code hiện tại (theo hợp đồng)
- Thuê agency mới audit code
- Quyết định: tiếp tục từ code cũ hoặc làm lại từ đầu
- Thường làm lại từ đầu tốt hơn nếu code cũ tệ
Option 3: Cut losses (dừng dự án)
Khi nào nên dừng:
- Business model đã thay đổi, app không còn cần thiết
- Thị trường đã có giải pháp tốt hơn
- Chi phí tiếp tục vượt quá giá trị app mang lại
Dừng dự án không phải thất bại — tiếp tục đốt tiền vào dự án không khả thi mới là thất bại.
6. So sánh: Dự án thất bại vs Dự án thành công
| Yếu tố | Dự án THẤT BẠI | Dự án THÀNH CÔNG |
|---|---|---|
| Yêu cầu | Mơ hồ, thay đổi liên tục | Document rõ ràng, change request có quy trình |
| Timeline | ”Cố gắng nhanh nhất” | Milestone cụ thể, realistic |
| Budget | Trả hết trước | Trả theo milestone |
| Communication | Hỏi mới trả lời | Weekly update, daily standup |
| Demo | Cuối dự án | Mỗi 2 tuần |
| Testing | Cuối dự án | Liên tục |
| Scope | ”Thêm nho nhỏ” liên tục | Locked scope, CR có đánh giá |
| CEO involvement | ”Giao rồi biến” | Review mỗi sprint |
7. Chi phí “cứu” dự án thất bại
| Tình huống | Chi phí cứu | So với làm mới |
|---|---|---|
| Code tốt, thiếu management | 10 - 20 triệu (PM + completion) | Rẻ hơn 50-70% |
| Code trung bình, thiếu design | 20 - 40 triệu (redesign + fix) | Rẻ hơn 30-50% |
| Code tệ, cần refactor | 40 - 80 triệu (refactor + fix) | Gần bằng làm mới |
| Code rất tệ | Làm lại từ đầu | Tốn thêm 100% |
FAQ — Câu hỏi thường gặp
Q1: Làm sao biết agency có đang “lừa” mình không?
Dấu hiệu cần cảnh giác: (1) Không cho xem source code, (2) Không có demo mỗi 2 tuần, (3) Lý do delay mỗi lần khác nhau, (4) Không cho liên hệ developer trực tiếp. Yêu cầu quyền truy cập repo (GitHub/GitLab) và project board (Jira/Trello) từ đầu.
Q2: Có nên thuê thêm người giám sát dự án (bên thứ ba)?
Rất nên nếu bạn không có kinh nghiệm quản lý dự án IT. Chi phí PM bên ngoài: 5-15 triệu/tháng. Tiết kiệm được: 30-50% chi phí phát sinh do miscommunication và scope creep.
Q3: App đã launch nhưng đầy bug, phải làm gì?
(1) Liệt kê tất cả bug theo mức độ nghiêm trọng (Critical → Major → Minor). (2) Yêu cầu developer fix theo hợp đồng warranty. (3) Nếu warranty hết, thuê developer mới fix với chi phí thấp hơn. (4) Cân nhắc viết lại nếu bug quá nhiều.
Kết luận
Dự án app thất bại không phải lỗi của riêng developer hay riêng khách hàng — mà thường là lỗi của cả hai. Chìa khoá thành công nằm ở:
- Yêu cầu rõ ràng từ đầu
- Đối tác đúng năng lực
- Hợp đồng chặt bảo vệ cả hai bên
- Demo liên tục mỗi 2 tuần
- CEO tham gia review thường xuyên
Nếu bạn đang chuẩn bị phát triển app, hoặc đang trong dự án gặp khó khăn, liên hệ Trinh Digital để được tư vấn quy trình phát triển app chuyên nghiệp. Chúng tôi áp dụng Agile Scrum với sprint review mỗi 2 tuần — bạn luôn thấy sản phẩm tiến triển.