Tìm hiểu cách một ứng dụng Tiếp nhận Dự án và Yêu cầu Nhân sự có thể thu thập nhu cầu, định tuyến phê duyệt, ghép kỹ năng và ghi lại quyết định phân công một cách rõ ràng.
Một ứng dụng Tiếp nhận Dự án và Yêu cầu Nhân sự khắc phục vấn đề mà hầu hết đội ngũ đều biết rõ. Công việc mới bắt đầu bằng email, thông tin bị sao chép vào bảng tính, quyết định diễn ra trong chat, và không ai hoàn toàn chắc phiên bản nào là đúng.
Cách làm đó có thể ổn với vài yêu cầu. Nó sụp khi khối lượng tăng. Một quản lý yêu cầu một lập trình viên cho tháng tới, nhưng bỏ sót mục tiêu dự án, ngày mục tiêu, ngân sách, mức độ khẩn cấp hoặc kỹ năng cần thiết. Nhóm nhân sự phải theo dõi các chi tiết cơ bản trước khi xem xét yêu cầu. Khi câu trả lời quay lại, yêu cầu có thể đã khác trên ba nơi.
Một ví dụ đơn giản cho thấy vấn đề. Một trưởng phòng sales yêu cầu hai người cho dự án cổng khách hàng. Một tin nhắn nói công việc frontend, tin khác nói thay đổi API, và một dòng trên bảng tính chỉ ghi "khẩn cấp." Khi quản lý tài nguyên xem, họ vẫn không biết cần một lập trình viên full-stack, hai chuyên gia hay thuê hợp đồng ngắn hạn.
Sự mơ hồ về quyền sở hữu càng làm tình hình tệ hơn. Nếu không ai biết ai duyệt scope, ai xác nhận số nhân sự, và ai phê duyệt phân công, yêu cầu sẽ kẹt giữa các đội. Mọi người hỏi cùng một câu ở nhiều nơi. Ứng viên tốt vẫn không được phân công vì đường ra quyết định mơ hồ.
Ứng dụng nên cho mỗi yêu cầu một "nhà" và một con đường tiêu chuẩn. Trong thực tế, điều đó có nghĩa là một nơi nộp yêu cầu, một bộ thông tin bắt buộc trước khi bắt đầu duyệt, một trạng thái hiển thị, và một hồ sơ mọi quyết định hay thay đổi phân công.
Với luồng tiếp nhận có cấu trúc, các đội ngừng đoán mò. Họ thấy được cần gì, ai sở hữu bước tiếp theo và vì sao ai đó được phân công hay không. Nếu bạn xây trên nền tảng no-code như AppMaster, mục tiêu không chỉ là thu thập yêu cầu. Mục tiêu là làm cho toàn bộ quy trình dễ theo dõi, quản lý và cải thiện.
Một biểu mẫu tốt nên trả lời ba câu hỏi ngay lập tức: công việc gì cần làm, khi nào cần diễn ra, và loại người như thế nào là cần thiết.
Bắt đầu với những thông tin cơ bản định danh yêu cầu. Yêu cầu tên dự án, người chịu trách nhiệm và một mục tiêu kinh doanh ngắn gọn bằng ngôn ngữ thông thường. "Triển khai cổng khách hàng cho yêu cầu hỗ trợ" hữu ích hơn nhiều so với "cần hệ thống mới."
Ngày tháng quan trọng, nhưng chỉ khi có bối cảnh. Thu thập ngày bắt đầu dự kiến, hạn chót mục tiêu và mức độ công việc kỳ vọng. Có thể đơn giản như bán thời gian hay toàn thời gian, ngắn hạn hay kéo dài, hoặc ước lượng bằng tuần hoặc tháng.
Làm cho nhu cầu nhân sự cụ thể. Thay vì một ô văn bản lớn, hỏi rõ vai trò nào cần và số người cho từng vai trò. Yêu cầu 1 backend developer, 1 QA specialist và 1 designer thì rõ ràng. Yêu cầu "một đội nhỏ" thì không.
Kỹ năng cũng nên có cấu trúc, không nên chôn trong phần bình luận. Ghi lại kỹ năng bắt buộc, công cụ ưu tiên và mức kinh nghiệm cần thiết. Nên tách kỹ năng bắt buộc và kỹ năng ưu tiên, vì quyết định phân công sau này sẽ dễ hơn nhiều.
Với hầu hết đội, biểu mẫu nên bao phủ những phần sau:
Các giới hạn về mặt kinh doanh nên hiển thị từ đầu. Bao gồm phạm vi ngân sách, mức độ ưu tiên và người có quyền phê duyệt. Nếu thiếu những thông tin đó, đội thường mất thời gian xem xét các yêu cầu không thể thực hiện.
Để chỗ cho một ghi chú ngắn về rủi ro hoặc hạn chế đặc biệt. Một dự án có thể phụ thuộc vào hạn chót của khách hàng, đánh giá tuân thủ hoặc một chuyên gia nội bộ chỉ có hai ngày một tuần.
Giữ biểu mẫu ngắn nhưng nghiêm ngặt. Dùng dropdown, trường bắt buộc và lựa chọn đơn giản bất cứ khi nào có thể. Dành văn bản mở cho những chi tiết thực sự cần giải thích.
Một luồng tiếp nhận tốt chuyển mỗi yêu cầu đến điểm quyết định tiếp theo mà không cần đuổi hỏi thủ công. Người phù hợp duyệt vào thời điểm phù hợp, với đủ chi tiết để quyết định nhanh.
Luồng bắt đầu khi ai đó nộp yêu cầu. Ứng dụng nên kiểm tra một vài trường cốt lõi như đội, loại dự án, mức ưu tiên, phạm vi ngân sách và ngày bắt đầu yêu cầu. Những trường đó giúp định tuyến yêu cầu tới người duyệt đúng thay vì đổ mọi thứ vào một hàng đợi chung.
Hầu hết đội nên bắt đầu với quy tắc định tuyến đơn giản. Yêu cầu theo phòng ban có thể đến trưởng nhóm tương ứng. Yêu cầu ngân sách cao hơn có thể đến quản lý hoặc bộ phận tài chính. Yêu cầu khẩn cấp có con đường nhanh hơn với thời hạn xét duyệt rõ ràng. Yêu cầu thiếu thông tin nên trả về cho người tạo kèm nhận xét.
Sau lần duyệt đầu, thêm bước kiểm tra kỹ năng và năng lực. Đây là nơi quyết định nhân sự cải thiện. Trưởng nhóm hoặc quản lý nguồn lực cần xác nhận hai điều: đội có kỹ năng cần thiết không, và những người đó có thời gian trống không? Ai đó có hồ sơ hoàn hảo nhưng đã kín lịch sáu tuần tới thì không khả dụng.
Giữ bước này có cấu trúc. Người duyệt nên chọn kết quả rõ ràng như đã phê duyệt, từ chối hoặc yêu cầu thay đổi. Nếu cần thay đổi, yêu cầu nên trả về kèm nhận xét và giữ đầy đủ lịch sử để không ai mất bối cảnh.
Khi được phê duyệt, yêu cầu nên chuyển thẳng vào theo dõi phân công. Lúc đó không còn là ý tưởng nữa. Nó trở thành mục nhân sự đang hoạt động với chủ sở hữu tên rõ ràng, trạng thái, ngày mục tiêu và hồ sơ về lý do chọn người nào đó.
Đây là nơi nhiều đội thất bại. Đã phê duyệt nhưng không ai chắc ai thực sự làm công việc. Một bàn giao rõ ràng sẽ khắc phục điều đó.
Trong AppMaster, loại luồng này phù hợp với quy trình nghiệp vụ trực quan có định tuyến theo quy tắc và cập nhật trạng thái tự động từ khi nộp tới khi phân công.
Cách đơn giản nhất để xây ứng dụng là xác định con đường trước, sau đó xây biểu mẫu, quyền truy cập và cảnh báo xung quanh con đường đó.
Bắt đầu với các trạng thái. Giữ ngắn và dễ hiểu: Draft, Submitted, Under Review, Approved, Staffing in Progress, Assigned và Closed. Nếu một yêu cầu cần quay lại để chỉnh sửa, thêm một trạng thái như Changes Needed thay vì tạo quá nhiều nhánh phụ.
Rồi xây quy trình theo thứ tự đơn giản. Trước tiên, vẽ sơ đồ luồng trên giấy. Xác định nơi yêu cầu bắt đầu, ai duyệt, ai phê duyệt và ai thực hiện phân công cuối cùng. Tiếp theo, tạo các trường biểu mẫu và đánh dấu những trường nào bắt buộc trước khi nộp. Sau đó, thêm quy tắc định tuyến để yêu cầu khẩn cấp hay ưu tiên cao không đi cùng đường với yêu cầu tiêu chuẩn. Rồi đặt quyền theo vai trò và hoàn thiện với thông báo ở mỗi bước bàn giao.
Quyền truy cập nên rõ ràng. Người tạo cần tạo yêu cầu và xem trạng thái của chính họ. Người duyệt cần bình luận và trả lại để chỉnh sửa. Người phê duyệt cần quyền phê duyệt hoặc từ chối. Trưởng nhóm nhân sự cần phân công và xác nhận phân bổ. Admin quản lý vai trò, quy tắc và thông báo.
Giữ phê duyệt nhẹ nhàng. Nếu quá nhiều người phải ký, yêu cầu sẽ nằm im. Với nhiều đội, một người duyệt và một người phê duyệt thường đủ trước khi bắt đầu phân công.
Mục tiêu chính là đơn giản: mỗi yêu cầu luôn có một chủ sở hữu, một trạng thái hiện tại và một bước tiếp theo rõ ràng.
Phân công tốt bắt đầu từ dữ liệu sạch. Nếu kỹ năng rải rác trong hồ sơ, tin nhắn chat và bảng tính, quyết định chậm và thiếu đồng nhất. Giữ một hồ sơ cho mỗi nhân viên và dùng cùng cấu trúc cho mọi người.
Với hầu hết đội, hồ sơ đó nên bao gồm vai trò, kỹ năng chính, mức kỹ năng, tình trạng sẵn có hiện tại, vị trí hoặc múi giờ, và bất kỳ giới hạn nào như giờ bán thời gian hoặc ngày kết thúc hợp đồng.
Yêu cầu cũng nên rõ ràng. Tách yêu cầu thành must-have và preferences. Một yêu cầu cần developer React có thể bắt đầu trong tuần tới không nên trộn lẫn với sở thích mềm hơn như kinh nghiệm ngành y tế trước đó.
Một bản ghi ghép đơn giản thường cần các trường sau:
Đánh giá kỹ năng nên nhất quán. Dùng thang đơn giản như beginner, working, strong, expert hoặc thang 1 đến 5. Tránh mô tả tự do. Một quản lý gọi là "advanced" có thể khác nhiều so với người khác.
Tình trạng sẵn sàng quan trọng ngang kỹ năng. Ứng viên hoàn hảo nhưng đã kín lịch không phải là lựa chọn thực tế cho yêu cầu khẩn cấp. Vị trí cũng quan trọng khi công việc cần trùng múi giờ, ngôn ngữ hoặc truy cập onsite.
Để giúp quản lý quyết định nhanh, hiển thị các ứng viên cạnh nhau. Góc nhìn nên trả lời vài câu cơ bản: họ có đáp ứng kỹ năng bắt buộc không, họ mạnh đến mức nào, họ có sẵn sàng không, họ ở đâu, và vì sao họ được gợi ý?
Phần lý do ghép thường bị bỏ qua. Giữ lý do chọn hiển thị trong hồ sơ ngay cả sau khi phân công. Một ghi chú ngắn như "Được chọn vì kỹ năng SQL và kinh nghiệm workflow hỗ trợ khớp yêu cầu, có sẵn 30 giờ/tuần" sẽ tiết kiệm thời gian sau này khi ai đó hỏi vì sao chọn người đó.
Nếu bạn xây trong AppMaster, giữ yêu cầu, hồ sơ nhân viên và bản ghi kỹ năng là cấu trúc dữ liệu riêng biệt sẽ giúp lọc, so sánh và theo dõi phân công dễ duy trì khi đội lớn lên.
Một ví dụ thực tế giúp hình dung rõ hơn.
Trưởng nhóm cần một cổng khách hàng mới để khách hàng đăng nhập, xem cập nhật và gửi yêu cầu đến đội dịch vụ. Họ mở biểu mẫu và nhập tên dự án, khách hàng, ngày ra mắt mục tiêu, mục tiêu kinh doanh và khối lượng công việc dự kiến. Trong phần nhân sự, họ yêu cầu ba vai trò: một chuyên gia backend, một designer và một tester.
Yêu cầu cũng ghi lại kỹ năng cho từng vai trò. Vai trò backend cần công việc API và database. Designer cần kinh nghiệm với dashboard đơn giản hướng đến khách hàng. Tester cần viết test case tốt và kiểm thử hồi quy. Điều đó làm cho yêu cầu hữu dụng hơn nhiều so với một dòng ghi số nhân sự.
Sau khi nộp, quy trình định tuyến yêu cầu đến tài chính và delivery. Tài chính kiểm tra nỗ lực dự kiến có phù hợp với ngân sách không. Delivery kiểm tra thời gian và phạm vi có tương thích với năng lực hiện tại không. Nếu một trong hai đội có lo ngại, yêu cầu trả về kèm ghi chú thay vì biến mất trong chuỗi email dài.
Khi cả hai phê duyệt xong, quản lý xem các nhân sự có sẵn phù hợp kỹ năng. Họ không chỉ tìm ai rảnh. Họ so sánh tính sẵn sàng, phân công hiện tại, ngày có thể bắt đầu và mức phù hợp kỹ năng của từng người.
Một ứng viên backend có thể sẵn sàng từ thứ Hai tới nhưng chỉ bán thời gian. Người khác có thể bắt đầu muộn hơn nhưng có kinh nghiệm database mạnh hơn. Designer có thể phù hợp nhưng không sẵn trong tuần đầu, nên quản lý ghi nhận khoảng trống tạm thời hoặc kế hoạch điều chỉnh.
Phân công cuối cùng được lưu trong hồ sơ yêu cầu. Nó hiển thị ai được phân công, khi nào họ bắt đầu, ai phê duyệt lựa chọn và bất kỳ ghi chú về đánh đổi hoặc phương án dự phòng. Điều đó cho mọi người một nơi duy nhất để kiểm tra quyết định mới nhất.
Hầu hết quy trình tiếp nhận thất bại vì những lý do đơn giản. Biểu mẫu lỏng lẻo, bàn giao không rõ, hoặc không ai biết vì sao người này được chọn thay người kia.
Một vài sai lầm gây rối nhiều nhất. Một là yêu cầu quá nhiều thông tin tùy chọn. Khi nửa biểu mẫu là tùy chọn, mọi người bỏ qua phần quan trọng và nộp các yêu cầu mơ hồ như "cần developer sớm." Một sai lầm khác là để quyền sở hữu mơ hồ. Nếu không ai chịu trách nhiệm duyệt hay xem xét nhân sự, yêu cầu dừng lại vì mỗi đội nghĩ đội khác sẽ xử lý.
Kỹ năng viết dưới dạng văn bản tự do là vấn đề phổ biến khác. Một người ghi "React," người khác ghi "frontend," người kia ghi "JS UI work." Sau này, tìm kiếm và ghép nối trở nên rối. Tương tự khi quyết định phân công chỉ sống trong chat. Ai đó nói "cho việc này cho Sam," nhưng app không bao giờ ghi ai quyết định, khi nào và vì sao.
Tên trạng thái cũng quan trọng hơn bạn nghĩ. Nếu "In Review" với một đội nghĩa là xem ngân sách còn với đội khác nghĩa là phê duyệt cuối cùng, nhầm lẫn chắc chắn xảy ra.
Một ví dụ nhỏ cho thấy điều này đi sai hướng. Một giám đốc sales nộp yêu cầu "hỗ trợ app" mà không rõ ưu tiên, hạn chót hay kỹ năng cần. Trưởng nhóm nhân sự hỏi thêm trong chat, một quản lý phê duyệt bằng miệng, và phân công cuối cùng diễn ra trong cuộc họp. Một tuần sau, không ai đồng ý liệu yêu cầu đã được phê duyệt, đã phân công hay vẫn đang chờ.
Giải pháp thường đơn giản. Giữ các trường bắt buộc chặt chẽ, dùng danh sách kỹ năng chuẩn, chỉ định một chủ sở hữu ở mỗi điểm quyết định và ghi lại mọi phê duyệt cùng phân công trong app.
Chính cấu trúc làm cho mọi thứ đáng tin cậy hơn. Trường rõ ràng, trạng thái cố định và quyết định được ghi lại khiến quy trình dễ quản lý và tin cậy hơn.
Trước khi ra mắt, thử quy trình theo cách một đội thực sự sẽ dùng vào sáng thứ Hai bận rộn. Nếu mọi người phải đoán phải điền gì, ai phê duyệt hay yêu cầu đang ở đâu, app sẽ làm chậm công việc thay vì giúp đỡ.
Một kiểm tra cuối cùng tốt là: liệu một yêu cầu có thể đi từ nộp tới phân công mà không cần tin nhắn phụ, bảng tính thêm hay theo dõi thủ công không?
Xác nhận vài điều cơ bản trước khi lên sóng:
Tầm nhìn trạng thái quan trọng ngang biểu mẫu. Tuyển dụng viên, trưởng nhóm, quản lý dự án và người tạo yêu cầu đều nên thấy giai đoạn hiện tại mà không phải mò qua email.
Một dòng trạng thái ngắn thường hiệu quả nhất: Submitted, Under Review, Approved, Matching in Progress, Assigned hoặc Closed. Nếu yêu cầu bị chặn, lý do cũng nên hiển thị.
Chạy một ca kiểm tra thực tế trước khi ra mắt. Ví dụ, nộp yêu cầu cho một mobile developer có kinh nghiệm Kotlin, ngày bắt đầu trong hai tuần, cần phê duyệt quản lý. Rồi kiểm tra xem app ghi đúng kỹ năng, định tuyến đúng người duyệt, ghi nhận quyết định cuối cùng và hiển thị trạng thái mới cho mọi người liên quan.
Bắt đầu nhỏ. Chọn một đội, một đường phê duyệt và một danh sách ngắn các loại yêu cầu phổ biến như dự án khách hàng mới, công việc hỗ trợ nội bộ, hoặc thay thế khẩn cấp.
Phiên bản đầu nên làm tốt một việc: thu thập yêu cầu, gửi tới người duyệt phù hợp và hiển thị quyết định đã được đưa ra. Nếu cố gắng xử lý mọi trường hợp ngay ngày đầu, app sẽ khó kiểm thử và dễ bị bỏ qua.
Giai đoạn thí điểm hai đến bốn tuần thường đủ để lộ ra chỗ nào quy trình ổn và chỗ nào mọi người vẫn quay về email hoặc chat. Điều quan trọng không phải app có bao nhiêu trường, mà là liệu quy trình có rõ ràng và nhanh hơn không.
Theo dõi vài con số đơn giản ban đầu: thời gian từ nộp tới lần duyệt đầu, tần suất yêu cầu bị trả lại vì thiếu thông tin, bao nhiêu quyết định nhân sự cần làm lại, loại yêu cầu nào tốn thời gian phân công nhất, và tần suất quản lý bỏ qua quy trình.
Những số đó chỉ ra điểm ma sát thực sự. Nếu chậm trước khi bắt đầu duyệt, biểu mẫu có thể quá mơ hồ. Nếu phân công liên tục thay đổi, dữ liệu kỹ năng có thể quá sơ sài hoặc không nhất quán.
Sau vài chu kỳ, siết chặt biểu mẫu và quy tắc định tuyến. Loại bỏ trường không ai dùng. Thêm trường bắt buộc chỉ ở những chỗ thông tin thiếu gây ra trì trệ thực sự. Nếu một loại yêu cầu cần đường đi khác, cho nó một đường thay vì ép mọi trường hợp qua cùng một quy trình.
Rồi xây phiên bản hai với phản hồi từ người tạo, người duyệt và trưởng nhóm. Mỗi nhóm nhìn thấy vấn đề khác nhau. Người tạo có thể nói họ bị hỏi chi tiết mà họ chưa biết. Người duyệt có thể cần mức độ ưu tiên rõ ràng hơn. Trưởng nhóm muốn cái nhìn nhanh về kỹ năng cần, ngày bắt đầu và năng lực hiện tại trước khi phê duyệt.
Nếu bạn muốn xây quy trình mà không nhiều mã, AppMaster phù hợp vì bạn có thể tạo biểu mẫu, logic nghiệp vụ và màn hình theo dõi trong một chỗ, rồi mở rộng thành backend, web app hoặc mobile app khi quy trình rõ ràng hơn.
Bước tốt nhất tiếp theo là ra mắt nhỏ, vòng phản hồi ngắn và cải thiện từng bước một.
Ứng dụng tiếp nhận dự án và yêu cầu nhân sự thực sự làm gì?Nó cho mỗi yêu cầu một nơi bắt đầu, một luồng duyệt tiêu chuẩn và một hồ sơ về quyết định nhân sự cuối cùng. Điều này thay thế email, chat và bảng tính rải rác bằng một quy trình rõ ràng để mọi người có thể theo dõi.
Mẫu yêu cầu nên thu thập thông tin gì trước tiên?Bắt đầu với tên dự án, người chịu trách nhiệm, mục tiêu kinh doanh, ngày bắt đầu, hạn chót dự kiến, phạm vi ngân sách, mức ưu tiên và người có thẩm quyền phê duyệt. Sau đó ghi rõ vai trò cần thiết, số lượng cho từng vai trò, kỹ năng bắt buộc, công cụ ưu tiên và khối lượng công việc dự kiến để người duyệt có thể quyết định mà không phải truy hỏi thêm.
Luồng tiếp nhận nên dùng những trạng thái nào?Giữ đơn giản. Một luồng ngắn như Draft, Submitted, Under Review, Approved, Staffing in Progress, Assigned và Closed thường là đủ. Nếu cần chỉnh sửa nhiều, thêm trạng thái Changes Needed thay vì tạo quá nhiều nhánh phụ.
Ai nên duyệt và phê duyệt một yêu cầu nhân sự?Trong hầu hết trường hợp, dùng một người duyệt và một người phê duyệt, sau đó chuyển yêu cầu cho trưởng nhóm nhân sự để phân công. Quá nhiều bước phê duyệt sẽ làm chậm và tạo ra mơ hồ về trách nhiệm.
Nên xử lý các yêu cầu không đầy đủ như thế nào?Gửi trả lại cho người tạo yêu cầu kèm nhận xét và giữ toàn bộ lịch sử trong cùng một hồ sơ. Như vậy yêu cầu không bị mất và mọi người có thể thấy những gì đã thay đổi và vì sao.
Chúng ta nên theo dõi kỹ năng nhân viên cho mục đích nhân sự như thế nào?Lưu kỹ năng ở định dạng tiêu chuẩn, không để dưới dạng văn bản tự do. Dùng tên kỹ năng cố định, thang đánh giá đơn giản và các trường rõ ràng cho tình trạng sẵn sàng, múi giờ và vai trò để việc ghép giữ được nhất quán.
Điều gì làm cho một người phù hợp với một yêu cầu?Một lựa chọn phù hợp phải đáp ứng cả khía cạnh năng lực và thời điểm. Người đó cần có các kỹ năng bắt buộc, sẵn sàng khi công việc bắt đầu và phù hợp về vị trí hoặc khối lượng công việc. Một ghi chú ngắn giải thích vì sao họ được chọn sẽ hữu ích sau này.
Làm sao để tránh tình trạng yêu cầu bị kẹt giữa các đội?Cho mỗi yêu cầu một người chịu trách nhiệm hiện tại, một trạng thái hiển thị và một bước tiếp theo rõ ràng. Đa số trì trệ đến từ bàn giao mơ hồ, biểu mẫu không rõ ràng hoặc phê duyệt xảy ra ngoài app.
Trước khi triển khai ứng dụng cần kiểm tra gì?Chạy một bài kiểm tra thực tế từ lúc nộp đến khi phân công. Kiểm tra các trường bắt buộc rõ ràng, định tuyến gửi yêu cầu tới đúng người, các phê duyệt được ghi nhận và mọi người đều thấy trạng thái mới nhất mà không phải hỏi qua chat hay email.
Tại sao nên xây quy trình này trên AppMaster?AppMaster là lựa chọn thực tế nếu bạn muốn tạo biểu mẫu, luồng công việc và màn hình theo dõi mà không cần nhiều mã. Bạn có thể thiết lập cấu trúc dữ liệu, logic định tuyến và cập nhật trạng thái trong một chỗ, rồi mở rộng thành backend, web app hoặc mobile app khi quy trình rõ ràng hơn.
10 thg 3, 2026
8 phút
08 thg 3, 20268 phút
07 thg 3, 202610 phútThử nghiệm với AppMaster với gói miễn phí.
Khi bạn sẵn sàng, bạn có thể chọn đăng ký phù hợp.
