Mở đầu — vì sao bài này quan trọng
Hãy tưởng tượng bạn đang là PM tại một công ty fintech ở TP.HCM. Trong một sprint, đội bạn đang xây tính năng cho phép người dùng "đặt lịch chuyển tiền tự động hàng tháng". Trong PRD bạn gọi nó là "Recurring Payment". Designer thì đặt tên Figma frame là "Auto Transfer". Engineer đặt tên branch là feature/scheduled-tx. Data analyst thì track event subscription_created. Đến khi launch, marketing đặt tên là "Chuyển tiền định kỳ". Và sáu tháng sau, khi có người hỏi "tính năng auto-pay của mình hoạt động ra sao?", không ai trong team chắc chắn họ đang nói về cùng một thứ.
Đó chính là cái giá của việc không có naming convention. Tên gọi nghe có vẻ là chuyện nhỏ — "đặt sao chẳng được, miễn hiểu là xong". Nhưng trong thực tế làm sản phẩm, tên gọi là giao diện ngôn ngữ giữa con người với con người. Một feature, một button, một event được đặt tên cẩu thả sẽ rò rỉ chi phí ra khắp nơi: PM mất thời gian giải thích lại, engineer hiểu nhầm scope, data team không phân tích nổi vì event trùng lặp, support không biết khách đang nói về tính năng nào, và team mới vào không đọc nổi codebase.
Naming convention không phải là sự cầu kỳ. Nó là một dạng đầu tư vào khả năng giao tiếp của tổ chức. Trong Spec và PRD, đây là phần ít được dạy nhất nhưng lại quyết định liệu tài liệu của bạn có "sống" được lâu hay không. Bài này sẽ giúp bạn xây một bộ quy ước đặt tên rõ ràng cho ba lớp quan trọng nhất mà PM phải đụng đến: feature, button (UI element), và event (analytics).
Khái niệm cốt lõi
Hai loại tên cho mỗi feature: codename và tên chính thức
Đây là điểm mấu chốt mà nhiều PM Việt Nam bỏ qua. Một feature lớn thường cần hai tên gọi phục vụ hai mục đích khác nhau:
Internal codename (tên nội bộ / mật danh): Đây là tên vui, dễ nhớ, dùng trong nội bộ team khi tính năng còn đang phát triển và chưa chốt tên cuối cùng. Ví dụ: "Project Stellar", "Operation Phoenix", "Dự án Sao Hôm". Codename có vài lợi ích thực dụng:
- Dễ nhớ và tạo cảm giác gắn kết: Gọi "Project Stellar" nghe hứng khởi hơn nhiều so với "dự án cải tiến luồng thanh toán quý 3".
- Trung lập với tên thương mại: Vì tên marketing thường được chốt rất muộn (đôi khi sau cả khi code xong), codename giúp team có một cái tên ổn định để gọi nhau ngay từ ngày đầu, mà không phải đổi đi đổi lại.
- Bảo mật: Khi nói chuyện ở quán cà phê hay trong email, "Stellar" không tiết lộ gì cho đối thủ. Apple, Google đều dùng codename (Android version từng đặt tên bánh kẹo: Cupcake, Donut, KitKat) một phần vì lý do này.
Quy tắc vàng: codename không bao giờ rò rỉ ra ngoài giao diện người dùng hay tài liệu marketing. Trong PRD, bạn nên ghi rõ cả hai và mối quan hệ giữa chúng, ví dụ một dòng ở đầu doc: "Codename: Stellar | Tên ra mắt (dự kiến): Live Shopping".
Tên button và UI element: mô tả hành động, không mô tả vị trí
Khi đặt tên cho các thành phần giao diện trong Spec, nguyên tắc là tên phải phản ánh hành động hoặc ý nghĩa, không phải vị trí hay hình thức. "Nút màu xanh ở góc dưới" là cách đặt tên tệ — vì đến khi designer đổi màu hoặc đổi vị trí, cả Spec trở nên sai. Thay vào đó: btn_checkout, btn_add_to_cart, link_forgot_password.
Một số quy ước phổ biến cho UI element:
- Tiền tố loại (prefix):
btn_(button),link_,input_,modal_,toast_,card_. Tiền tố giúp người đọc biết ngay đó là loại element gì. - Tên mô tả hành động: dùng động từ + đối tượng:
btn_save_draft,btn_publish_post,btn_invite_member. - Nhất quán động từ: chọn một từ và dùng xuyên suốt. Đừng lúc thì "Delete", lúc "Remove", lúc "Trash" cho cùng một hành động.
Tên event analytics: cấu trúc, thì, và ngữ pháp nhất quán
Event analytics là nơi naming convention quan trọng nhất nhưng cũng dễ loạn nhất, vì event do nhiều người đặt qua nhiều năm. Một bộ quy ước tốt thường gồm:
- Cấu trúc
object_action: Đặt danh từ (object) trước, động từ (action) sau, ở thì quá khứ:checkout_completed,video_played,cart_item_added. Lý do đặt object trước: khi sắp xếp theo bảng chữ cái, tất cả event của cùng một đối tượng nằm gần nhau (checkout_started,checkout_completed,checkout_failed). - Thì quá khứ cho action: Event ghi lại việc đã xảy ra, nên dùng quá khứ:
signed_up,purchased,shared. Tránhsignup(danh từ mơ hồ) haysigning_up(đang diễn ra). - snake_case hoặc một quy ước duy nhất: Chọn
snake_case(gạch dưới) HOẶCcamelCaseHOẶCTitle Caserồi giữ nguyên. Việc trộn lẫn là nguyên nhân số một gây event trùng (Checkout Completedvàcheckout_completedbị tính là hai event khác nhau). - Property (thuộc tính) cũng cần convention:
plan_type,payment_method,item_count— đặt tên thuộc tính theo cùng style với event.
Tình huống thực tế
Ví dụ 1 — Tiki và bài học event analytics trùng lặp
Giả định một bối cảnh sát thực tế ở một sàn thương mại điện tử lớn như Tiki. Trong giai đoạn tăng trưởng nhanh, ba squad khác nhau (Checkout, Search, Personalization) cùng track event người dùng nhấn nút mua. Squad Checkout đặt order_placed, squad Search đặt Purchase, squad Personalization đặt buy_clicked.
Hậu quả: khi ban lãnh đạo hỏi "tháng này có bao nhiêu đơn được đặt qua app?", data team phải ngồi gộp ba event lại bằng tay, và phát hiện chúng có định nghĩa hơi khác nhau (một cái track lúc nhấn nút, một cái track lúc thanh toán thành công). Con số chênh nhau tới 12%. Một báo cáo gửi lên CEO bị sai vì lẫn lộn giữa "nhấn nút mua" và "đặt hàng thành công".
Giải pháp họ áp dụng: lập một Event Tracking Plan tập trung (thường là một Google Sheet hoặc công cụ như Avo/Amplitude Govern), quy định mọi event mới phải theo cấu trúc object_action ở thì quá khứ, và phải được data team duyệt trước khi gắn. Event chuẩn trở thành order_completed (đặt hàng thành công) và checkout_button_clicked (nhấn nút) — tách bạch rõ ràng.
Bài học: Naming convention cho event không phải là việc làm đẹp; nó trực tiếp ảnh hưởng đến độ chính xác của số liệu ra quyết định. Một sàn TMĐT track sai 12% đơn hàng là một sai số đủ lớn để định hướng sai cả chiến lược.
Ví dụ 2 — Codename "Stellar" và tên ra mắt "Live Shopping"
Một startup social commerce ở Đông Nam Á (tạm gọi ShopLive) muốn xây tính năng livestream bán hàng tích hợp giỏ hàng trực tiếp. Ngay từ kickoff, PM đặt codename "Project Stellar". Trong suốt 4 tháng phát triển, mọi tài liệu, kênh Slack #proj-stellar, branch stellar/*, và Jira epic đều dùng tên này. Team gọi nhau "Stellar tới đâu rồi?" rất tự nhiên.
Đến gần ngày ra mắt, marketing chốt tên customer-facing là "Live Shopping" sau khi kiểm tra trademark và test với người dùng. PM viết một dòng ánh xạ ở đầu PRD: "Codename: Stellar → Public name: Live Shopping (chốt ngày 12/3)". Quan trọng hơn, PM lập một checklist rà soát mọi nơi tên xuất hiện với người dùng: nhãn nút, push notification, email, App Store description — đảm bảo không chỗ nào còn chữ "Stellar".
Nhưng một lỗi nhỏ vẫn lọt: một analytics event được đặt là stellar_session_started và đã đẩy lên production. Đổi tên event sau khi đã có dữ liệu là cực kỳ phiền (phá vỡ dashboard, mất tính liên tục dữ liệu). Họ buộc phải giữ tên stellar_* trong hệ thống data mãi mãi, dù sản phẩm tên là Live Shopping — một di sản khó hiểu cho người mới.
Bài học: Codename rất hữu ích cho giao tiếp nội bộ, nhưng phải có ranh giới rõ. UI và marketing thì đổi tên dễ; còn event analytics và data schema thì gần như không đổi được sau khi lên production. Vì vậy ngay cả tên event nội bộ cũng nên trung lập, không bám vào codename dễ chết.
Ví dụ 3 — MoMo và sự nhất quán động từ trên UI
Giả định ở một ví điện tử như MoMo, trong cùng một luồng quản lý thẻ, các màn hình khác nhau dùng từ khác nhau cho cùng một hành động xóa: màn này ghi "Xóa thẻ", màn kia "Gỡ liên kết", popup xác nhận lại ghi "Hủy thẻ". Người dùng bối rối: "Gỡ liên kết" có giống "Xóa" không, hay nó chỉ tạm ngắt? Support nhận nhiều ticket hỏi về điều này.
Đội design system vào cuộc, lập một bảng từ vựng UI (UI vocabulary / content style guide): quy định mỗi khái niệm chỉ có một từ. "Xóa" dùng cho hành động xóa vĩnh viễn; "Gỡ liên kết" chỉ dùng riêng cho việc ngắt kết nối tài khoản ngân hàng (một khái niệm thật sự khác). Trong Spec, button được đặt tên kỹ thuật btn_remove_card và nhãn hiển thị chuẩn hóa là "Xóa thẻ" ở mọi nơi.
Bài học: Naming convention không chỉ là tên kỹ thuật trong code; nó còn là từ ngữ người dùng nhìn thấy. Một khái niệm — một từ. Sự nhất quán trong từ ngữ UI làm giảm tải nhận thức cho người dùng và giảm ticket cho support.
Hướng dẫn từng bước
Đây là quy trình bạn có thể áp dụng ngay khi viết phần naming trong Spec/PRD:
Bước 1 — Đặt codename ngay khi kickoff. Ngay khi feature có epic, chọn một codename trung lập, dễ nhớ, không trùng với feature đang chạy. Ghi vào đầu PRD. Quy ước một "họ" tên cho dễ quản lý (ví dụ: tất cả dự án 2026 đặt theo tên các vì sao, hoặc các con sông Việt Nam).
Bước 2 — Ghi rõ ánh xạ codename → tên chính thức. Trong PRD, dành một dòng hoặc một ô bảng: Codename | Public name (dự kiến/đã chốt) | Ngày chốt. Cập nhật ngay khi marketing chốt tên.
Bước 3 — Định nghĩa convention cho UI element. Quyết định prefix (btn_, link_, modal_...), quy tắc động từ + đối tượng, và case (snake_case là phổ biến cho tên kỹ thuật). Liệt kê các element chính trong Spec với cả tên kỹ thuật lẫn nhãn hiển thị.
Bước 4 — Định nghĩa convention cho event. Chốt cấu trúc object_action, thì quá khứ, một kiểu case duy nhất. Lập bảng event: event_name | khi nào trigger | thuộc tính kèm theo. (Phần chi tiết về cách viết Analytics Event Spec sẽ được học sâu hơn ở bài riêng — ở đây ta chỉ tập trung phần quy ước đặt tên.)
Bước 5 — Lập từ vựng UI (một khái niệm — một từ). Liệt kê các động từ hành động chính (Lưu/Save, Xóa/Delete, Chia sẻ/Share...) và chốt một từ duy nhất cho mỗi khái niệm, dùng cho cả tiếng Việt lẫn tiếng Anh nếu sản phẩm song ngữ.
Bước 6 — Đưa convention vào nơi mọi người thấy. Một bảng quy ước nằm trong tài liệu mà không ai đọc thì vô dụng. Đưa nó vào template PRD, vào design system, vào Event Tracking Plan tập trung, và lý tưởng là có người "gác cổng" (data lead hoặc design lead) duyệt tên mới.
Lỗi thường gặp & mẹo
Lỗi 1 — Để codename rò rỉ ra giao diện người dùng. Khách hàng thấy chữ "Stellar" trên nút bấm sẽ chẳng hiểu gì. Mẹo: trước khi launch, search toàn bộ codename trong code, copy, push notification, email template.
Lỗi 2 — Đổi tên event sau khi đã lên production. Việc này phá vỡ dashboard và làm đứt gãy dữ liệu lịch sử. Mẹo: đặt tên event nội bộ trung lập (đừng bám codename), và suy nghĩ kỹ trước khi gắn event — vì nó gần như vĩnh viễn.
Lỗi 3 — Trộn lẫn case và thì. Checkout Completed, checkout_completed, checkoutCompleted bị tính là ba event khác nhau. Mẹo: viết convention bằng một dòng rõ ràng và để công cụ (Amplitude, Mixpanel governance) tự cảnh báo khi sai.
Lỗi 4 — Đặt tên theo vị trí/màu sắc. "Nút xanh bên phải" sẽ sai ngay khi UI đổi. Mẹo: luôn đặt tên theo hành động/ý nghĩa.
Lỗi 5 — Nhiều từ cho một khái niệm. Delete/Remove/Trash lẫn lộn gây rối cho cả user lẫn dev. Mẹo: lập từ vựng "một khái niệm — một từ".
Lỗi 6 — Đặt tên quá viết tắt/khó hiểu. btn_cm_sub_v2_final không ai đoán được nghĩa. Mẹo: ưu tiên rõ ràng hơn ngắn gọn; tên dài mà hiểu được vẫn tốt hơn tên ngắn bí ẩn.
Mẹo chung: Một bộ naming convention tốt nên ngắn — vừa một trang. Nếu nó dài quá, không ai nhớ và không ai tuân theo.
Bài tập thực hành
Hãy lấy một feature thật mà bạn đang hoặc sắp làm (nếu chưa có, dùng đề bài giả định: "tính năng chia sẻ giỏ hàng cho bạn bè cùng mua chung" trên một app TMĐT).
- Đặt codename: Chọn một codename trung lập theo một "họ" tên (ví dụ: tên các loài chim). Viết một dòng ánh xạ
Codename → Public name (dự kiến).
- Đặt tên 5 UI element chính: Theo convention
prefix_verb_object, đặt tên kỹ thuật và nhãn hiển thị cho 5 nút/element quan trọng nhất của luồng (ví dụ: nút tạo giỏ chung, nút mời bạn, nút xác nhận...).
- Đặt tên 6 event analytics: Theo cấu trúc
object_actionthì quá khứ, snake_case. Với mỗi event ghi rõ "trigger khi nào" và 1–2 thuộc tính kèm theo.
- Lập từ vựng UI nhỏ: Liệt kê 4 động từ hành động trong feature của bạn và chốt một từ duy nhất (cả Việt lẫn Anh) cho mỗi khái niệm.
- Tự rà lỗi: Đọc lại 4 phần trên và kiểm tra: có chỗ nào trộn case không? có động từ nào dùng hai từ khác nhau không? codename có lọt vào tên event không?
Tóm tắt
Naming convention là một khoản đầu tư rẻ tiền nhưng sinh lời lớn cho khả năng giao tiếp của cả tổ chức. Ba điểm cốt lõi cần nhớ:
- Feature cần hai tên: codename nội bộ (vui, ổn định, dùng từ ngày đầu) và tên chính thức hướng khách hàng (chốt muộn, kiểm tra pháp lý). Luôn ghi rõ ánh xạ giữa hai tên trong PRD, và không bao giờ để codename rò rỉ ra UI hay marketing.
- Button/UI element đặt tên theo hành động + đối tượng với prefix loại, không theo vị trí/màu sắc; và giữ một khái niệm — một từ trong từ vựng UI.
- Event analytics dùng cấu trúc
object_actionở thì quá khứ với một kiểu case duy nhất; và nhớ rằng tên event gần như vĩnh viễn sau khi lên production, nên đừng bám codename dễ chết.