--- title: "Dựng mockup trên chính hệ thống thay vì vẽ ngoài" url: "https://bahub.vn/khoa-hoc/erp-cho-ba/dung-mockup-tren-he-thong-thay-vi-ve-ngoai" author: "Võ Văn Trí" published: "2026-09-10" updated: "2026-11-02" source: "bahub.vn" license: "Được dùng lại, trích dẫn và đưa cho AI đọc, với điều kiện ghi rõ nguồn bahub.vn kèm link bài gốc." --- # Dựng mockup trên chính hệ thống thay vì vẽ ngoài > Quy trình lấy xác nhận giao diện bằng bản dựng trên hệ thống thật: dựng tới đâu là đủ, chạy buổi xác nhận ra sao, và xử lý bản dựng sau khi chốt. - Nguồn: https://bahub.vn/khoa-hoc/erp-cho-ba/dung-mockup-tren-he-thong-thay-vi-ve-ngoai - Tác giả: Võ Văn Trí - Khoá học: ERP cho Business Analyst (mục lục: https://bahub.vn/khoa-hoc/erp-cho-ba.md) - Chương: Tùy biến và phân quyền Màn hình hồ sơ nhà thầu phụ được vẽ bằng một công cụ thiết kế, xuất ra ảnh, gửi cho khách qua email, và khách trả lời đúng một chữ: ok. Sáu tuần sau, tới buổi kiểm thử, người phụ trách bên khách mở đúng màn hình đó lên và nói nó không giống cái đã duyệt. Trong bản vẽ, ô tỉnh thành là một ô để gõ chữ, còn trên hệ thống thật nó là trường chỉ chọn được trong danh mục có sẵn, mà danh mục đó không có mấy tên viết tắt nhân viên họ vẫn dùng. > Bản vẽ là một hình ảnh, còn hệ thống thật là một cấu trúc dữ liệu có ràng buộc, và giữa hai thứ đó luôn có một khoảng trống mà không bên nào nhìn thấy vào lúc ký duyệt. ## Chỗ bản vẽ ngoài rơi khỏi thực tế Khoảng trống đó nằm ở chính bản chất của việc vẽ, và nó có ba lớp. **Lớp thứ nhất là ràng buộc dữ liệu.** Một ô vuông trên bản vẽ không cho biết nó là trường chữ hay trường ngày, có bắt buộc nhập không, trỏ tới danh mục nào, nên khách thấy một chỗ để điền còn đội phát triển thì phải tự đoán. **Lớp thứ hai là phần mặc định của nền tảng.** Bạn vẽ một màn hình trắng chỉ có những trường mình định thêm nên khách hiểu rằng màn hình chỉ có bấy nhiêu, trong khi màn hình thật còn có khối trao đổi, dãy nút ở trên và cả một tập trường mặc định mà bạn coi là hiển nhiên. **Lớp thứ ba nguy hiểm hơn cả**: bản vẽ cho phép bạn vẽ ra thứ hệ thống không làm được, và khi khách đã nhìn thấy rồi thì việc rút lại luôn khó, bởi trong đầu họ đó là thứ đã được hứa chứ không phải một phác thảo. Bản dựng trên chính hệ thống không có ba lớp đó, còn chuyện nó nhanh và chính xác hơn về mặt kỹ thuật thì tôi đã nói ở bài về [nguyên tắc 100% code](https://bahub.vn/khoa-hoc/erp-cho-ba/nguyen-tac-100-phan-tram-code). Điều cần nói ở bài này là **có bản dựng rồi không có nghĩa là bạn đã lấy được xác nhận**. ## Điều kiện để dùng được cách này Trước hết phải chốt một điều kiện, vì không thỏa nó thì toàn bộ phần sau không áp dụng được. Công cụ kéo thả của Odoo, tức Studio, thuộc bản Enterprise và không có trong Community, nên nếu khách hàng của bạn chạy Community thì bạn không dựng được màn hình mới theo cách này. Ngay cả khi có Enterprise thì việc cài Studio còn chạm tới gói thuê bao, bởi một database đang ở gói Standard sẽ bị chuyển lên gói Custom khi cài nó. Hệ quả về gói, chuyện ai được bật công cụ này và cách quản trị đi kèm đã có bài riêng về [Studio sau lúc bấm cài](https://bahub.vn/khoa-hoc/erp-cho-ba/he-qua-van-hanh-cua-viec-chon-studio), còn chuyện chọn bản nào thì thuộc bài về [Community và Enterprise](https://bahub.vn/khoa-hoc/erp-cho-ba/odoo-community-hay-enterprise). Với khách dùng Community, hãy dựng bằng chính những màn hình tiêu chuẩn đã có, còn trường thêm mới thì mô tả bằng bảng chứ đừng vẽ ra một màn hình không tồn tại. Dù dùng cách nào thì cũng nhớ một ranh giới: **bản dựng nằm trên bản thử, không nằm trên bản sẽ chạy thật**. ![Bản dựng nằm trên bản thử, không nằm trên bản sẽ chạy thật](https://bahub.vn/uploads/2026/11/1793631551999-v1znar-dung-mockup-tren-he-thong-thay-vi-ve-ngoai-1.webp "Bản dựng nằm trên bản thử, không nằm trên bản sẽ chạy thật") ## Mức dựng vừa đủ Câu hỏi thực tế nhất là dựng tới đâu thì dừng, bởi dựng thiếu thì khách không hình dung được, còn dựng thừa thì bạn đang làm sản phẩm chứ không phải bản nháp. Tiêu chí tôi dùng là người sẽ ngồi nhập liệu hằng ngày nhìn vào màn hình đó và trả lời được ba câu: * trường này nhập cái gì * có bắt buộc không * và nhập xong thì thông tin chạy đi đâu **Trả lời được thì dừng.** Một bản dựng vừa đủ gồm các thao tác sau: * Kéo đúng những trường sẽ thêm mới, đặt đúng nhãn hiển thị * Chọn đúng kiểu dữ liệu, khai đủ giá trị cho trường lựa chọn * Đặt đúng trường bắt buộc và điều kiện ẩn hiện nếu có * Trỏ đúng đối tượng dữ liệu cho trường quan hệ * Nhập một bản ghi mẫu bằng dữ liệu thật xin từ khách * Chụp lại màn hình ngay khi dựng xong Ngược lại, những thứ không dựng ở bước này gồm logic tính toán, tự động hóa, phân quyền, mẫu in và dữ liệu nhiều bản ghi, bởi đưa chúng vào lúc này chỉ làm buổi họp lệch sang những chuyện chưa tới lượt. Dòng về bản ghi mẫu đáng chú ý nhất. **Nhập bằng tên khách hàng thật và mã hàng thật thì người xem lập tức nhận ra chỗ không khớp**, còn nhập bằng dữ liệu bịa thì buổi họp trôi qua êm đẹp và chỗ không khớp chỉ hiện ra vào lúc kiểm thử. Còn một dấu hiệu nữa đáng để ý: nếu một màn hình dựng quá nửa buổi mà chưa xong thì vấn đề thường nằm ở chỗ yêu cầu phía sau nó chưa rõ, và lúc đó việc cần làm là quay lại làm rõ yêu cầu chứ không phải kéo thêm trường. ## Buổi lấy xác nhận giao diện Cần phân biệt buổi này với buổi demo giải pháp. Buổi demo trả lời câu hệ thống có giải được bài toán nghiệp vụ không, còn buổi này chỉ trả lời câu màn hình có đúng thứ người ta sẽ nhập mỗi ngày không; cách dựng hệ thống demo và cách chốt lựa chọn trong buổi đó thì tôi đã nói ở bài [đi từ một dòng GAP tới giải pháp khách chốt được](https://bahub.vn/khoa-hoc/erp-cho-ba/tu-gap-toi-giai-phap-khach-chot). Buổi này chỉ cần hai loại người, nhưng thiếu một loại là hỏng. **Loại thứ nhất là người sẽ trực tiếp nhập liệu**, vì họ biết trong công việc thật có dữ liệu nào chưa sẵn lúc nhập. **Loại thứ hai là người có thẩm quyền xác nhận**, bởi ý kiến của nhân viên chưa phải là yêu cầu đã chốt. Trong buổi, điểm quan trọng nhất là **bạn đừng cầm chuột**. Hãy giao máy cho người nhập liệu và đề nghị họ tạo một bản ghi thật từ đầu tới cuối, còn bạn ngồi ghi lại những chỗ họ dừng lại, hỏi lại, hoặc gõ vào một trường rồi xóa đi. > Chính những chỗ ngập ngừng đó là thứ bạn cần, và chúng không xuất hiện nếu người thao tác là bạn. ![Giao chuột cho người nhập liệu và ghi lại từng chỗ họ ngập ngừng](https://bahub.vn/uploads/2026/11/1793631552517-t9fx17-dung-mockup-tren-he-thong-thay-vi-ve-ngoai-2.webp "Giao chuột cho người nhập liệu và ghi lại từng chỗ họ ngập ngừng") Bên cạnh đó, hãy hỏi thẳng một câu ở mỗi trường bắt buộc: **nếu lúc nhập mà chưa có thông tin này thì anh chị làm thế nào**. Công việc thật luôn có lần chứng từ về trước còn thông tin về sau, nên một trường bắt buộc đặt sai chỗ sẽ khiến người dùng nhập bừa cho qua màn hình, tạo ra dữ liệu rác mà sau này chính bạn phải đi dọn. ## Ghi lại kết quả buổi Đây là chỗ nhiều người hỏng, bởi **bản dựng trông đầy đủ tới mức người ta nghĩ nó đã là tài liệu, nhưng nó không phải**. Bản dựng còn thay đổi, và thay đổi âm thầm, không để lại dấu vết ai đổi gì lúc nào. Đồng thời đội phát triển và người viết kịch bản kiểm thử đọc tài liệu chứ không đọc màn hình, trong khi thứ quan trọng nhất của một màn hình lại là thứ ảnh chụp không mang theo được, chẳng hạn trường nào bắt buộc và trường quan hệ trỏ tới đâu. Do đó ngay sau buổi, **ảnh chụp phải được đưa vào mục giao diện của tài liệu giải pháp kèm bảng mô tả từng thành phần**; cách đánh số thành phần trên ảnh và bộ cột của bảng thì đã có bài riêng về [bảng GUI element](https://bahub.vn/khoa-hoc/erp-cho-ba/bang-gui-element-mo-ta-truong-du-lieu). Buổi họp còn cần một biên bản riêng, ngắn thôi nhưng phải đủ năm thứ: * ngày họp * danh sách người dự * những thay đổi được yêu cầu tại chỗ * tên người xác nhận * và thời hạn phản hồi Gửi qua email cho cả hai bên và đừng quên đặt thời hạn, bởi biên bản không có thời hạn thì nằm im trong hộp thư cho tới lúc có người cần lấy ra làm bằng chứng. Đặc biệt, **hãy ghi rõ ảnh chụp thuộc lần dựng nào và ngày nào**. Bản dựng còn sửa vài lần trước khi chốt, và nếu ảnh không có mốc thời gian thì tới lúc tranh luận đã duyệt cái gì, hai bên sẽ nói về hai màn hình khác nhau mà không biết. ## Hiểu lầm nguy hiểm nhất > Rủi ro lớn nhất không nằm ở kỹ thuật mà nằm ở chỗ khách xem xong tưởng hệ thống đã gần xong. Hiểu lầm đó rất tự nhiên, bởi thứ họ vừa nhìn thấy không phải một bản vẽ mà là một màn hình thật, bấm được, nhập được, lưu được. Từ đó tới chỗ người phụ trách bên khách báo cáo lên cấp trên rằng hệ thống đã chạy chỉ là một bước ngắn, và hệ quả luôn quay lại phía bạn: * kỳ vọng về thời gian bị rút ngắn * mọi tiến độ sau đó đều bị nhìn như chậm trễ * và tới lúc kiểm thử mà phát sinh lỗi thì phản ứng sẽ nặng hơn bình thường. Cách phòng gồm ba việc. * Trước khi mở màn hình, **nói đúng một câu rằng đây là bản dựng để thống nhất giao diện** và phần bên dưới chưa có logic nào chạy. * Trong lúc dựng, **cố ý bỏ những thứ tạo cảm giác hoàn chỉnh**: không cấu hình mẫu in, không tạo hàng loạt bản ghi, không đặt tên môi trường nghe như bản chính thức. * Và sau buổi, **gửi ảnh chứ đừng gửi đường dẫn để khách tự bấm**, bởi người bấm một mình sẽ tự kết luận về những thứ chưa được dựng. Nếu khách nhất định muốn tự thao tác thêm thì hãy mở một môi trường riêng và nói rõ dữ liệu trong đó sẽ bị xóa. ![Bản dựng trông như hệ thống thật nên khách dễ tưởng đã gần xong](https://bahub.vn/uploads/2026/11/1793631553213-s0495j-dung-mockup-tren-he-thong-thay-vi-ve-ngoai-3.webp "Bản dựng trông như hệ thống thật nên khách dễ tưởng đã gần xong") ## Số phận của bản dựng sau khi chốt Chốt xong thì bản dựng phải đi về đâu đó, bởi bỏ mặc là tạo rác trong hệ thống của khách, và có ba trường hợp cần phân biệt. **Trường hợp thứ nhất là dự án làm hoàn toàn bằng Studio.** Khi đó bản dựng được giữ lại và trở thành sản phẩm, nhưng phải dùng chức năng Export của Studio để xuất phần tùy chỉnh ra một file nén dạng module rồi nhập vào môi trường khác cùng phiên bản, thay vì dựng lại thủ công. **Trường hợp thứ hai là dự án có phần phải viết code**, và đây là trường hợp phải dứt khoát. **Bản dựng bị xóa khỏi môi trường sẽ dùng về sau**, còn thứ giữ lại là ảnh chụp cùng bảng trường, tức nó chuyển hóa thành một yêu cầu gửi cho developer. Lý do phải xóa nằm ở cơ chế xung đột giữa trường tạo bằng Studio và code, vốn là chủ đề của một bài khác, nên ở đây chỉ cần nhớ thứ nguy hiểm nhất là để trường đó tồn tại rồi một developer thấy có sẵn nên dùng luôn. Khi bàn giao, hãy ghi rõ tên kỹ thuật mong muốn của từng trường, bởi trường dựng bằng Studio mặc định mang tiền tố `x_studio_` và tên đó không nên xuất hiện trong code. Nếu tên đã lỡ đặt sai thì vẫn còn đường sửa qua phần cài đặt kỹ thuật ở chế độ nhà phát triển, nhưng đường đó có giá của nó: * phải gỡ trường khỏi mọi dạng xem đang dùng nó trước * mỗi lần chỉ đổi được một trường * tên mới vẫn phải giữ tiền tố `x_` của trường tùy chỉnh * và kiểu dữ liệu thì không đổi được nên muốn đổi kiểu là phải xóa đi tạo lại **Rẻ nhất vẫn là đặt đúng ngay từ lúc dựng.** **Trường hợp thứ ba là khách xem xong rồi bỏ yêu cầu**, và lúc này bạn vẫn phải dọn. Cần lưu ý rằng một đối tượng dữ liệu mới tạo bằng Studio thì dọn khó hơn nhiều so với một trường, bởi lúc tạo hệ thống sinh kèm cả loạt trường mặc định, dạng xem, menu và hành động để nó hoạt động, và muốn gỡ thì phải vào phần cài đặt kỹ thuật dọn từng thứ một, có trường hợp dọn xong vẫn bị chặn; đây là loại thao tác gần như không quay đầu được và đã có bài riêng nói kỹ. Do đó hãy ưu tiên kéo thêm trường lên màn hình sẵn có, còn nếu buộc phải tạo đối tượng dữ liệu mới chỉ để khách xem thì làm trên một database dùng một lần rồi bỏ. ## Chỗ cách này không dùng được Cách làm nào cũng có vùng nó không giúp được gì. **Bản dựng chỉ có tác dụng với những yêu cầu mà giá trị nằm trên màn hình**, tức chuyện nhập gì, nhìn thấy gì, bấm ở đâu. Với yêu cầu mà giá trị nằm trong logic, chẳng hạn quy tắc tính giá theo bậc, thì dựng giao diện xong khách vẫn không hình dung thêm được gì, và loại đó phải xác nhận bằng ví dụ số liệu chạy thử. Tương tự, một quy trình đi qua nhiều bộ phận thì bản dựng không thay được lưu đồ. Và ngay cả khi bản dựng phát huy hết tác dụng, vẫn còn một chi tiết nhỏ quyết định chất lượng của cả phần tùy biến về sau: **nhãn hiển thị nên được đặt bằng tiếng Anh trước rồi mới dịch**, bởi [cơ chế dịch của Odoo](https://bahub.vn/khoa-hoc/erp-cho-ba/viet-hoa-odoo-mot-key-nhieu-noi) là một câu chuyện riêng đủ dài để nói ở một bài khác. --- Nguồn: https://bahub.vn/khoa-hoc/erp-cho-ba/dung-mockup-tren-he-thong-thay-vi-ve-ngoai — Được dùng lại, trích dẫn và đưa cho AI đọc, với điều kiện ghi rõ nguồn bahub.vn kèm link bài gốc.