Quy trình làm app mobile

Quy trình làm app mobile gồm 7 bước: khảo sát và đặc tả (1–2 tuần), thiết kế UX/UI (1–2 tuần), chốt kiến trúc và công nghệ (3–5 ngày), lập trình theo từng lô (4–10 tuần), kiểm thử (1–2 tuần), phát hành store (3–7 ngày), bàn giao và bảo trì. Tổng thời gian thực tế cho một app doanh nghiệp là 10–14 tuần, tính từ lúc chốt đặc tả.

Bỏ bước nào cũng phải trả giá: bỏ đặc tả → đổi yêu cầu liên tục; bỏ thiết kế → sửa giao diện sau khi code tốn gấp 5 lần; bỏ kiểm thử → app bị đánh giá 1 sao trên store; bỏ bàn giao tài khoản → mất app khi đổi nhà cung cấp.

Tóm tắt 7 bước

Bước 0 — Chuẩn bị trước khi thuê

Phần lớn dự án app thất bại không phải vì code kém mà vì khách hàng và nhà cung cấp hiểu khác nhau ngay từ đầu. Trước khi ký, bạn nên có:

• Một câu mô tả mục tiêu: "app giúp khách đặt lịch trong 30 giây, giảm 50% cuộc gọi" tốt hơn "app đặt lịch".
• Ai là người dùng: khách hàng cuối, nhân viên, hay cả hai. Mỗi nhóm cần một bộ màn hình khác nhau.
• Danh sách chức năng bắt buộc (5–10 chức năng) và danh sách hoãn lại — danh sách thứ hai quan trọng ngang danh sách thứ nhất.
• Ngân sách và hạn chót thật, kèm mức ưu tiên: nếu phải chọn giữa đúng hạn và đủ tính năng, bạn chọn cái nào?
• Ai trong công ty duyệt sản phẩm. Có một người duy nhất. Nếu ba người cùng duyệt, dự án sẽ chậm gấp ba.

Bước 1 — Khảo sát và viết đặc tả (1–2 tuần)

Đây là bước tạo ra 80% giá trị kiểm soát của toàn dự án. Đầu ra không phải tài liệu dày 60 trang, mà là:

• Danh sách màn hình có đánh số (ví dụ "M07 — Danh sách đơn hàng"), kèm mục đích từng màn hình.
• Luồng người dùng chính (3–5 luồng), viết dạng bước: mở app → đăng nhập → chọn dịch vụ → chọn giờ → thanh toán → xác nhận.
• Phân quyền: ai thấy gì, ai làm được gì.
• Dữ liệu vào/ra: trường nào bắt buộc, định dạng, ai được sửa.
• Tiêu chí nghiệm thu viết dạng kiểm tra được: "đặt lịch xong phải xuất hiện trong danh sách của nhân viên trong vòng 5 giây".
• Ngoài phạm vi: liệt kê rõ những gì bạn nghĩ tới nhưng dự án này không làm.

Lỗi thường gặp ở bước này: viết đặc tả bằng tính từ ("app phải đẹp, mượt") thay vì hành vi kiểm chứng được. Tính từ không nghiệm thu được, nên tranh chấp không có điểm dừng.

Một mẹo hữu ích: vẽ tay từng màn hình lên giấy rồi chụp ảnh làm tài liệu. Ba mươi bức ảnh vẽ tay truyền đạt ý định tốt hơn ba mươi trang chữ.

Bước 2 — Thiết kế UX/UI (1–2 tuần)

Quy trình con:

1. Wireframe (khung xám): sắp xếp thông tin, thứ tự thao tác. Duyệt ở bước này rẻ nhất.
2. Giao diện hoàn chỉnh: màu, chữ, khoảng cách, trạng thái (rỗng, đang tải, lỗi).
3. Design system tối thiểu: bảng màu, cỡ chữ, nút, khoảng cách. Thiếu bước này, mỗi màn hình sẽ đẹp một kiểu.
4. Bản duyệt: bạn ký duyệt trước khi code. Số vòng sửa ghi rõ trong hợp đồng (thường 2–3 vòng).

Với app doanh nghiệp, đừng bỏ qua ba trạng thái dễ quên: dữ liệu rỗng (người dùng mới), đang tải, và mất mạng. Đây là ba trạng thái xuất hiện nhiều nhất trong thực tế nhưng hiếm khi có trong bản thiết kế.

Bước 3 — Kiến trúc và chọn công nghệ (3–5 ngày)

Bước này quyết định chi phí bảo trì 3 năm tới, nên đừng để nó diễn ra ngầm. Cần chốt:

Một nguyên tắc thực dụng: nếu hệ thống hiện có đã có API ổn định thì đừng viết backend mới. Mỗi lần viết lại backend là một lần tạo ra hai nguồn sự thật trái nhau.

Bước 4 — Lập trình theo từng lô (4–10 tuần)

Nhịp làm việc tốt:

• Chu kỳ 1–2 tuần, cuối mỗi chu kỳ có bản cài thử trên máy thật cho bạn dùng. Không chấp nhận "gần xong" bằng lời.
• Ưu tiên luồng dọc: làm xong một chức năng từ giao diện → nghiệp vụ → dữ liệu, thay vì làm hết giao diện rồi mới làm dữ liệu.
• Nhánh ngắn: mỗi thay đổi sống dưới 2–3 ngày để dễ kiểm tra và dễ lùi.
• Môi trường thử riêng để bạn test mà không ảnh hưởng dữ liệu thật.

Điều nên có trong hợp đồng: quyền truy cập kho mã nguồn của bạn ngay từ đầu (read-only cũng được). Đây là cách phòng rủi ro lớn nhất — nhà cung cấp biến mất giữa đường.

Bước 5 — Kiểm thử (1–2 tuần)

App khác web ở chỗ không kiểm soát được thiết bị của người dùng. Vì vậy ma trận kiểm thử phải rộng:

Tiêu chí xuất xưởng thực tế: không còn lỗi mức chặn (crash, mất dữ liệu, sai tiền), lỗi giao diện nhỏ dưới 20 và đã ghi nhận.

Bước 6 — Phát hành store (3–7 ngày)

Chuẩn bị hồ sơ:

• Tài khoản Apple Developer 99 USD/năm và Google Play Console 25 USD — phải đứng tên doanh nghiệp bạn, không đứng tên nhà cung cấp.
• Tên app, mô tả ngắn (80 ký tự), mô tả đầy đủ, từ khoá.
• Ảnh chụp màn hình đúng kích thước cho từng thiết bị (bắt buộc, thiếu là bị từ chối).
• Biểu tượng app, ảnh cover store.
• Chính sách quyền riêng tư có URL công khai; với Google còn cần Data safety form.
• Phân loại độ tuổi, khai báo quyền truy cập (camera, vị trí, thông báo).
• Tài khoản demo cho người duyệt (nếu app yêu cầu đăng nhập) — thiếu là bị từ chối ngay.

Năm lý do bị Apple từ chối phổ biến nhất:

1. Guideline 4.2 — app chỉ là bản bọc website. App cần chức năng riêng (thông báo, offline, camera) mới qua được.
2. Thiếu chính sách quyền riêng tư hoặc chính sách không khớp dữ liệu thực tế thu thập.
3. Mô tả không khớp chức năng — mô tả hứa nhiều hơn app có.
4. Lỗi khi người duyệt dùng thử — thường do không cấp tài khoản demo hoặc dữ liệu trống.
5. Thanh toán nội dung số ngoài hệ thống trong app (phải dùng in-app purchase).

Google duyệt nhanh hơn nhưng chặn mạnh ở phần quyền truy cập và dữ liệu nhạy cảm.

Bước 7 — Bàn giao và bảo trì

Danh sách bàn giao tối thiểu:

• Kho mã nguồn đầy đủ (quyền sở hữu chuyển cho bạn).
• Tài khoản App Store / Google Play, khoá ký app, quyền phát hành.
• Tài liệu kiến trúc, sơ đồ API, hướng dẫn build và phát hành.
• Tài khoản máy chủ, dịch vụ thông báo đẩy, bản đồ, thanh toán.
• Bộ kiểm thử tự động (nếu có) và quyền chạy CI.
• 30 ngày bảo hành lỗi do lập trình.

Bảo trì sau đó thường chia 3 mức: cơ bản (theo dõi lỗi, cập nhật thư viện), tiêu chuẩn (thêm giờ sửa nhỏ mỗi tháng), đồng hành (phát triển tính năng mới).

Thời gian thực tế theo quy mô

Quy tắc kinh nghiệm: thời gian ≈ (số màn hình trung bình × 2,5 ngày) + 3 tuần cho hạ tầng, kiểm thử và phát hành. Con số này khớp với thực tế đa số dự án; các dự án trễ thường do thay đổi phạm vi, không do code chậm.

Ai làm gì trong dự án

Với dự án dưới 200 triệu, đội thường là 3 người kiêm nhiệm. Trên 300 triệu nên có kiểm thử riêng — đây là khoản đầu tư rẻ nhất để tránh đánh giá 1 sao.

Dấu hiệu dự án app sắp trễ

Nhận ra sớm để can thiệp, đừng chờ đến tuần cuối:

1. Hai tuần liền không có bản cài thử trên máy thật.
2. Câu trả lời "đang hoàn thiện" thay cho bản demo.
3. Số màn hình tăng trong khi thời gian giữ nguyên.
4. Không có môi trường thử riêng — bạn phải test trên dữ liệu thật.
5. Lỗi được đóng mà không có bản cài mới để kiểm chứng.
6. Không ai trả lời được "còn bao nhiêu việc" — thiếu bảng công việc.
7. Thay đổi yêu cầu không được ghi lại — nghĩa là nó sẽ không được làm, hoặc làm mà không ai biết.

Checklist nghiệm thu app

Trước khi bấm "nghiệm thu" và trả đợt tiền cuối:

1. Tất cả màn hình trong đặc tả đã có và chạy được.
2. Ba luồng chính chạy trọn vẹn trên máy thật, không cần sự trợ giúp của lập trình viên.
3. Không còn lỗi chặn; danh sách lỗi nhỏ đã ghi nhận và có ngày sửa.
4. Dữ liệu mẫu trống/sai không làm app crash.
5. Mất mạng giữa thao tác không làm mất dữ liệu đã nhập.
6. Đăng nhập, phân quyền, đăng xuất, đổi mật khẩu hoạt động đúng.
7. Thông báo đẩy tới được cả khi app đóng (Android & iOS).
8. App đã có trên store hoặc có bản nộp đang chờ duyệt.
9. Đã nhận mã nguồn + tài liệu build và tự build được một lần.
10. Đã nhận tài khoản store, khoá ký, tài khoản máy chủ.

Điểm 9 và 10 là hai điểm hay bị bỏ qua nhất, và cũng là hai điểm khiến doanh nghiệp mất app về tay nhà cung cấp.

Nhịp làm việc hằng tuần giữa bạn và đội phát triển

Dự án app trễ phần lớn vì nhịp phối hợp, không vì kỹ thuật. Một nhịp làm việc tốt cần đúng 4 thứ:

Cách báo lỗi hiệu quả nhất là theo mẫu 4 dòng: làm gì → thấy gì → mong đợi gì → ảnh chụp. Báo lỗi kiểu "app bị lỗi" khiến đội phát triển mất nửa ngày chỉ để tái hiện.

Điều nên tránh: gửi yêu cầu qua 5 kênh khác nhau (Zalo, email, miệng, cuộc gọi). Mọi yêu cầu không nằm trong danh sách công việc thì coi như chưa tồn tại.

Kiểm thử bảo mật: phần hay bị bỏ qua

Với app có tài khoản người dùng, tối thiểu phải kiểm tra:

• Xác thực: mã OTP hết hạn, giới hạn số lần thử, đăng xuất trên thiết bị khác.
• Lưu trữ trên máy: không lưu token/mật khẩu dạng thô; dùng keychain/keystore.
• Truyền dữ liệu: chỉ HTTPS, chứng chỉ hợp lệ, không tắt kiểm tra chứng chỉ.
• Phân quyền phía máy chủ: không tin quyền do app khai báo; mọi kiểm tra phải làm ở backend.
• Chụp màn hình và clipboard: app có dữ liệu nhạy cảm nên chặn chụp màn hình ở màn hình quan trọng.
• Log: không ghi số điện thoại, số thẻ, mật khẩu vào log.
• Phụ thuộc bên thứ ba: khoá phiên bản, có quy trình cập nhật khi thư viện có lỗ hổng.

Một lỗi phân quyền phía client có thể khiến toàn bộ dữ liệu khách hàng bị lộ. Đây là khoản kiểm thử 5–10 triệu nhưng có thể cứu được hàng trăm triệu tiền xử lý sự cố.

Hai tuần cuối trước khi phát hành: việc gì diễn ra

Nhiều khách hàng tưởng "code xong là xong". Thực tế hai tuần cuối là giai đoạn bận rộn nhất:

Sai lầm phổ biến: chuẩn bị ảnh chụp màn hình và chính sách quyền riêng tư vào ngày cuối, rồi bị từ chối vì thiếu. Hãy làm từ D-10.

Chuyển từ nhà cung cấp cũ sang đội mới

Nếu app của bạn đang do đơn vị khác làm và bạn muốn chuyển, cần thu thập đủ 8 thứ trước khi ký với đội mới:

1. Kho mã nguồn (quyền sở hữu hoặc quyền truy cập ghi trong hợp đồng).
2. Tài khoản App Store / Google Play và quyền phát hành.
3. Khoá ký app (keystore cho Android, chứng chỉ và profile cho iOS).
4. Tài khoản máy chủ, cơ sở dữ liệu, dịch vụ thông báo đẩy.
5. Tài liệu kiến trúc và sơ đồ API.
6. Tài khoản dịch vụ bên thứ ba (thanh toán, bản đồ, SMS).
7. Quy trình build và phiên bản môi trường đang chạy.
8. Danh sách lỗi đang tồn đọng và các thay đổi chưa phát hành.

Thiếu khoá ký Android là tình huống tệ nhất: bạn không thể cập nhật app trên Google Play nữa và phải phát hành như một app mới, mất toàn bộ người dùng hiện có.

Ước lượng công sức: bảng khối lượng tham khảo

Tổng khoảng 100–160 ngày công cho một app doanh nghiệp 15 màn hình. Đây là con số dùng để đối chiếu khi một báo giá cam kết 6 tuần cho phạm vi tương tự — hoặc là họ có sẵn nền tảng, hoặc là phạm vi đang bị hiểu khác.

Mẫu đặc tả một màn hình (dùng lại được)

Đặc tả tốt không cần dài. Mỗi màn hình chỉ cần 8 dòng theo mẫu sau:

M07 — Danh sách đơn hàng
Mục đích: nhân viên xem đơn trong ngày và cập nhật trạng thái
Người dùng: nhân viên chi nhánh (chỉ thấy đơn của chi nhánh mình)
Dữ liệu hiển thị: mã đơn, khách, tổng tiền, trạng thái, giờ tạo
Thao tác: lọc theo trạng thái, tìm theo mã/số điện thoại, mở chi tiết
Trạng thái đặc biệt: đang tải, rỗng, lỗi mạng, hết phiên
Tiêu chí nghiệm thu: mở được dưới 1,5 giây với 500 đơn; bộ lọc giữ nguyên khi quay lại
Không thuộc phạm vi: xuất Excel, in hoá đơn

Cách viết này có ba lợi ích: nhà cung cấp báo giá được chính xác, bạn nghiệm thu được bằng cách đối chiếu, và khi có tranh chấp thì tài liệu là trọng tài.

Với 20 màn hình, bạn có 20 khối như trên — khoảng 5–8 trang. Đây là tài liệu giá trị nhất của toàn dự án, rẻ hơn nhiều so với việc sửa sai sau khi code.

Liên quan

• Chi phí làm app mobile — bảng giá và các khoản chi phí ẩn
• Dịch vụ Thiết kế App Mobile — quy trình và phạm vi của DNT
• Nên làm app hay website trước — quyết định giai đoạn đầu
• Quy trình làm việc — cách DNT giao việc và bàn giao
• Checklist nghiệm thu website — dùng cho phần quản trị web