Checklist thuê công ty làm app mobile

Cách dùng checklist thuê công ty làm app mobile

Checklist thuê công ty làm app mobile nên được dùng trước buổi lấy báo giá, trong lúc so sánh đề xuất và trước khi ký nghiệm thu. Mục tiêu không phải tìm đội hứa nhiều tính năng nhất, mà xác định đơn vị nào hiểu bài toán, chỉ ra giả định và để doanh nghiệp giữ quyền kiểm soát sản phẩm sau khi dự án kết thúc.

Trước tiên, ghi lại một đến ba hành trình tạo giá trị nhất: ai dùng app, họ muốn hoàn thành việc gì, dữ liệu đến từ đâu và kết quả nào chứng minh app có ích. Sau đó yêu cầu mọi nhà cung cấp phản hồi trên cùng phạm vi, cùng giả định và cùng bộ tiêu chí nghiệm thu. Báo giá chỉ có thể so sánh khi đầu vào tương đương.

Friday Works khuyến nghị chấm từng đề xuất theo sáu nhóm: hiểu bài toán, phạm vi kỹ thuật, quyền sở hữu, phương pháp kiểm thử, khả năng vận hành và tổng chi phí. Một bản demo đẹp nhưng không nói rõ backend, tài khoản store hay bàn giao không phải là đề xuất đầy đủ.

• ✓Viết rõ người dùng chính, vấn đề, hành trình quan trọng và chỉ số thành công.
• ✓Gửi cùng một brief và danh sách câu hỏi cho mọi đơn vị.
• ✓Yêu cầu tách phần chắc chắn, phần giả định và phần cần discovery.
• ✓So sánh tổng chi phí sở hữu, không chỉ giá làm phiên bản đầu.

Nhà cung cấp tốt không chỉ bàn giao một file cài đặt; họ giúp doanh nghiệp giữ được quyền vận hành, phát hành và tiếp tục phát triển sản phẩm.

Chốt phạm vi bằng luồng và tiêu chí nghiệm thu

Danh sách màn hình không đủ để định nghĩa một ứng dụng. Mỗi luồng cần nêu điểm bắt đầu, dữ liệu đầu vào, quyền truy cập, trạng thái thành công, lỗi có thể xảy ra và hệ thống phía sau bị tác động. Một luồng đặt hàng, chẳng hạn, có thể liên quan đăng nhập, tồn kho, thanh toán, vận chuyển, thông báo, dashboard và đối soát.

Tiêu chí nghiệm thu phải quan sát được. Thay vì ghi “app chạy nhanh”, hãy chốt thiết bị và phiên bản hệ điều hành được hỗ trợ, dữ liệu thử, điều kiện mạng, hành vi khi API lỗi và ngưỡng phản hồi cho những luồng quan trọng. Thay vì “tích hợp CRM”, hãy nêu trường dữ liệu, quy tắc chống trùng, retry, nhật ký lỗi và người xử lý ngoại lệ.

Discovery tốt có thể làm giảm hoặc thay đổi phạm vi ban đầu. Đây không phải dấu hiệu nhà cung cấp né báo giá; đó là cách tách điều đã biết khỏi rủi ro cần xác minh. Nếu mọi thứ được báo giá cố định ngay từ một mô tả mơ hồ, phần thiếu thường quay lại dưới dạng change request hoặc nợ vận hành.

• ✓Sơ đồ luồng người dùng, vai trò và trạng thái dữ liệu.
• ✓Danh sách iOS/Android, thiết bị, kích thước màn hình và phiên bản tối thiểu.
• ✓Backend, dashboard, API, thông báo, thanh toán và tích hợp nằm trong hay ngoài phạm vi.
• ✓Acceptance test có dữ liệu, kết quả mong đợi và người phê duyệt.

Giữ quyền sở hữu tài khoản, mã nguồn và dữ liệu

Doanh nghiệp nên tạo tài khoản Apple Developer và Google Play Console của chính tổ chức rồi mời đội phát triển bằng vai trò phù hợp. Apple quy định Account Holder có các quyền đặc biệt như ký thỏa thuận pháp lý và quản lý tư cách thành viên; Google cũng khuyến nghị chủ tài khoản thêm từng người dùng thay vì chia sẻ tài khoản. Chuyển app hoặc chuyển chủ sở hữu có thể thực hiện trong một số trường hợp, nhưng đi kèm điều kiện và quy trình nên không phải phương án mặc định tốt hơn việc sở hữu ngay từ đầu.

Kho mã nguồn, cloud, tên miền, dịch vụ gửi thông báo, analytics, crash reporting và tài khoản thanh toán cũng cần có owner phía doanh nghiệp. Nhà cung cấp được cấp quyền cần thiết, không giữ tài khoản gốc hoặc mật khẩu dùng chung. Khi kết thúc, doanh nghiệp có thể thu hồi quyền mà không làm gián đoạn sản phẩm.

Hợp đồng cần liệt kê rõ phần nào được bàn giao, quyền sử dụng hoặc quyền sở hữu áp dụng ra sao, thư viện nào là mã nguồn mở hay dịch vụ trả phí và dữ liệu có thể xuất ở định dạng nào. Không mặc định câu “bàn giao source code” đã bao gồm thiết kế, hạ tầng, pipeline, khóa ký, tài liệu và quyền dùng mọi thành phần bên thứ ba.

• ✓Apple Developer/App Store Connect và Google Play Console đứng tên doanh nghiệp khi đủ điều kiện.
• ✓Repository nằm trong tổ chức Git do khách hàng kiểm soát; bật MFA và phân quyền theo vai trò.
• ✓Cloud, database, analytics, crash reporting, domain và tài khoản thanh toán có owner nội bộ.
• ✓Hợp đồng liệt kê source, design file, tài liệu, cấu hình, license và dữ liệu bàn giao.

Đánh giá năng lực qua bằng chứng và cách làm

Case study hữu ích phải gần với rủi ro của dự án, không nhất thiết cùng ngành. Nếu app cần hoạt động offline, hãy hỏi cách đội xử lý đồng bộ và xung đột. Nếu có thanh toán hoặc dữ liệu nhạy cảm, hãy hỏi về mô hình quyền, log, kiểm thử và quy trình sửa lỗi. Nếu tích hợp thiết bị, hãy yêu cầu mô tả thiết bị và phiên bản đã kiểm thử.

Trong buổi kỹ thuật, để nhà cung cấp giải thích một luồng end-to-end từ màn hình đến API, database, hệ thống thứ ba, log và cảnh báo. Một câu trả lời tốt nêu cả failure mode: chuyện gì xảy ra khi mạng mất, request chạy hai lần, token hết hạn, thông báo không gửi được hoặc store từ chối bản phát hành.

Đừng yêu cầu số liệu hoặc tên khách hàng mà nhà cung cấp không được phép công khai. Thay vào đó, xem artefact đã ẩn dữ liệu nhạy cảm: ví dụ acceptance criteria, test matrix, release checklist, mẫu báo cáo lỗi, kiến trúc và tài liệu bàn giao. Những bằng chứng này phản ánh khả năng triển khai rõ hơn danh sách công nghệ dài.

• ✓Kinh nghiệm liên quan đến rủi ro, tích hợp hoặc mô hình vận hành của dự án.
• ✓Có thể giải thích kiến trúc và trade-off bằng ngôn ngữ kinh doanh.
• ✓Có test matrix, quy trình release, quản lý lỗi và cách quan sát production.
• ✓Không cam kết tuyệt đối khi chưa khảo sát dữ liệu và hệ thống hiện có.

Kiểm thử bản beta trên thiết bị và điều kiện thật

Bản beta phải đến tay người dùng nội bộ đủ sớm để sửa hành trình, không chỉ dùng cho buổi nghiệm thu cuối. TestFlight cho phép phân phối và thu phản hồi bản beta iOS; Android có các kênh kiểm thử tương ứng trong Play Console. Hãy chốt ai tạo nhóm tester, ai đọc phản hồi, cách ưu tiên lỗi và build nào là ứng viên phát hành.

Google khuyến nghị luôn thử ứng dụng Android trên thiết bị thật trước khi phát hành. Test matrix nên bao gồm thiết bị phổ biến của khách hàng, màn hình nhỏ và lớn, phiên bản hệ điều hành tối thiểu, mạng yếu hoặc mất mạng, đổi quyền camera/vị trí/thông báo, đăng nhập lại, nâng cấp từ phiên bản cũ và hành vi khi backend lỗi.

Kiểm thử không dừng ở việc bấm đúng luồng. Cần quan sát crash, thời gian phản hồi, mức dùng dữ liệu, pin nếu có tác vụ nền, accessibility của hành động chính, dữ liệu analytics và tính đúng của thông báo. Mọi lỗi chặn release phải có owner, mức độ, bằng chứng sửa và kết quả retest.

• ✓Có nhóm beta đại diện cho vai trò và loại thiết bị thật.
• ✓Kiểm tra fresh install, update, logout/login và khôi phục phiên.
• ✓Kiểm tra mạng chậm, offline, retry, request trùng và lỗi hệ thống thứ ba.
• ✓Chỉ nghiệm thu lỗi đã retest trên đúng build và thiết bị liên quan.

Chốt phát hành store, khóa ký và trách nhiệm vận hành

Một app chưa hoàn thành chỉ vì đã build được file cài đặt. Kế hoạch release phải bao gồm bundle identifier hoặc package name, signing, privacy disclosure, nội dung trang store, ảnh chụp, tài khoản demo cho review, chính sách quyền truy cập và người phản hồi nếu Apple hoặc Google yêu cầu chỉnh sửa.

Android yêu cầu ứng dụng được ký để phát hành và cập nhật; với Play App Signing, upload key và app signing key có vai trò khác nhau. Doanh nghiệp cần biết khóa nào do Google quản lý, khóa upload được cất ở đâu, ai có quyền release và quy trình reset/rotate khi có sự cố. Trên hệ sinh thái Apple, tài khoản và certificate cũng là tài sản nhạy cảm, không nên chia sẻ credential chung.

Sau khi ra mắt, hãy chốt người theo dõi crash, API, queue, thông báo, đánh giá store và chi phí cloud. Định nghĩa severity, thời gian phản hồi và kênh liên lạc cho sự cố. “Bảo hành” không thay thế vận hành: lỗi trong phạm vi bàn giao, thay đổi chính sách store, thay đổi API bên thứ ba và yêu cầu tính năng mới là các nhóm khác nhau.

• ✓Checklist metadata, privacy, permission, screenshot, review note và demo account.
• ✓Phân quyền release, lưu khóa an toàn và không chia sẻ tài khoản gốc.
• ✓Có rollback hoặc phương án dừng rollout khi build mới gây lỗi.
• ✓Dashboard theo dõi crash, API, tác vụ nền, phiên bản và chi phí vận hành.

Đọc hợp đồng, báo giá và bảo hành như một hệ thống

Báo giá cần tách discovery, UX/UI, mobile app, backend, dashboard, tích hợp, dữ liệu, QA, phí store, hạ tầng và hỗ trợ sau phát hành. Nếu một hạng mục “đã bao gồm”, hãy yêu cầu đầu ra và giới hạn. Điều này giúp nhận biết phần việc thực sự bị bỏ trống thay vì chỉ so con số cuối.

Lịch thanh toán nên bám vào milestone có artefact và acceptance criteria, không chỉ ngày trên lịch. Quy trình change request phải cho biết ai có quyền yêu cầu, cách ước lượng tác động, ảnh hưởng timeline và điều gì xảy ra nếu hai bên chưa thống nhất. Giữ một backlog quyết định để tránh các yêu cầu qua chat biến thành phạm vi ngầm.

Điều khoản bảo hành phải nêu ngày bắt đầu, loại lỗi thuộc phạm vi, môi trường được hỗ trợ, cách báo lỗi, mức độ ưu tiên và tiêu chí đóng lỗi. Gói bảo trì sau bảo hành cần tách sửa lỗi, cập nhật hệ điều hành/thư viện, giám sát, sao lưu, hỗ trợ người dùng và phát triển tính năng để doanh nghiệp dự toán đúng tổng chi phí.

• ✓Milestone gắn với build, tài liệu, test evidence và phê duyệt.
• ✓Quy trình change request và đơn giá/cách ước lượng được viết rõ.
• ✓Phân biệt bug, thay đổi nền tảng, yêu cầu mới và sự cố vận hành.
• ✓Nêu chi phí dự kiến cho store, cloud, dịch vụ thứ ba và bảo trì.

Bàn giao để doanh nghiệp có thể tiếp tục mà không bị khóa

Buổi bàn giao tốt chứng minh một người kỹ thuật khác có thể lấy source, cấu hình môi trường, chạy test, tạo build và phát hành bằng tài khoản doanh nghiệp. Nếu chỉ nhà cung cấp cũ làm được vì thiếu secret, tài liệu hoặc quyền truy cập, sản phẩm chưa thật sự được bàn giao.

Bộ bàn giao tối thiểu thường gồm repository và lịch sử cần thiết, file thiết kế, tài liệu kiến trúc, API và data model, danh sách dịch vụ bên thứ ba, hướng dẫn môi trường, CI/CD, backup/restore, runbook sự cố, tài khoản và ma trận quyền. Secret không nên nằm trong tài liệu tĩnh; cần chuyển qua công cụ quản lý bí mật rồi thu hồi quyền không còn dùng.

Friday Works thường kết thúc một giai đoạn bằng walkthrough kỹ thuật, release rehearsal và danh sách vấn đề còn mở. Với dự án mới, chúng tôi cũng đề xuất chốt quyền sở hữu và exit plan ngay từ discovery. Đây là lúc tốt nhất để tránh phụ thuộc nhà cung cấp mà không làm chậm tiến độ.

• ✓Doanh nghiệp đăng nhập được mọi tài khoản chủ sở hữu và biết cách cấp/thu hồi quyền.
• ✓Một máy hoặc pipeline sạch có thể tạo build từ source đã bàn giao.
• ✓Backup đã được thử khôi phục; dữ liệu có thể xuất theo định dạng đã thống nhất.
• ✓Có danh sách nợ kỹ thuật, lỗi còn mở, license, chi phí và ngày gia hạn.
• ✓Quyền nhà cung cấp được rà soát và thu hồi sau thời gian chuyển tiếp.