Khi còn sinh viên khi mới biết lập trình thì chắc mình cũng như các bạn sẽ nghĩ ngay đến việc làm 1 sản phẩm như app, game, trang web. Thông thường thì game hay app thì cũng làm dừng ở mức cho 1 số lượng người nhất định, còn web chủ yếu là tin tức,view là nhiều, hoặc cùng lắm là web quản lý với CRUD. Chỉ cần biết lập trình, sử dụng framework là có thể làm sản phẩm được rồi.

Sau khi đi làm vài năm và tham gia nhiều dự án ở thị trường Nhật thì mình có suy nghĩ rộng hơn về đối tượng người dùng và những cách mà người Nhật dùng để áp dụng với nhiều khách hàng khác nhau với nhiều yêu cầu khác nhau. Thông thường thì công ty phát triển product sẽ làm ra 1 phần mềm, hệ thống common nhất. Ở dưới đây mình có liệt kê 1 số pattern mà mình gặp phải trong quá trình làm việc.Do cũng chỉ một KH nên có thể chưa đầy đủ.

I. Khi mỗi khách hàng là 1 URL với mã khách hàng riêng

Ví dụ như công ty bạn có 1 sản phẩm là webbanhang(WEB bán hàng) nhưng lại bán cho nhiều cửa hàng khác nhau. Mỗi cửa hàng lại muốn phân biệt bằng 1 mã code riêng. Chẳng hạn như webbanhang/FPT,webbanhang/VTL….Khi mà dùng theo kiểu này thì sẽ rút ngắn được vấn đề config domain.

Thì bên Nhật họ thường dùng khái niệm テナント管理, cái này chắc bạn nào làm intra-mart thì sẽ gặp.

II.Một item nhưng mỗi khách hàng lại muốn hiển thị khác nhau

Đối  với các công ty Nhật thì thông thường sẽ dùng properties. File properties gồm có key và value, lấy value bằng hàm java, hoặc js. Có cơ chế để ghi đè các file properties theo từng khách hàng lên file properites common.

VD:
#properties để hiện thị button 問い合わせ(1: hiển thị, 0: không hiển thị, default là không hiển thị)
toiawase_display_prop=0
Có khách hàng A có file properties với nội dung bên dưới: (1: được hiển thị)
toiawase_display_prop=1

Nhưng đối với cách làm này thì khi cần sửa properties thì phải build lại toàn bộ project, tốn thời gian deploy. Nên tốt nhất vẫn nên quản lý ở DB, chỉ dùng đối với những properties ít thay đổi.
Tham khảo như ở đây :
https://qiita.com/motoki1990/items/2b643ea854624b09712c

III.Mỗi khách hàng dùng 1 schema khác nhau, khi thay đổi DB phải áp dụng hàng loạt

Làm 1 sản phẩm mà bán cho hàng trăm khách hàng thì đúng là tiện vì nó đồng bộ source code, Database. Khi gặp 1 lỗi thì có thể triển khai ngang cho toàn bộ chắc tenant.
Nếu dùng tool để sửa database trực tiếp thì sẽ gặp nhiều rủi ro,và tốn khả nhiều thời gian do mỗi tenant là 1 schema. Nên họ thường dùng khái niệm DBscript, chạy theo cấu trúc sql plus.

Có thể dùng để đối ứng các tình huống sau:

1.Thêm 1 item vào table
2.Update dữ liệu của table
3.Select dữ liệu để xuất ra file csv
4.Cấp quyền (GRANT), hoặc tạo SYNONYM, PACKAGE-> RECOMPILE…

IV.Mỗi khách hàng là 1 bộ menu khác nhau

Vì 1 sản phẩm sẽ có nhiều chức năng, thường người bán sẽ phân rã ra chức năng độc lập để bán cho người dùng. Ví dụ như chức năng Mail, Schedule, Workflow. Có trường hợp khách hàng A chỉ dùng Mail và Schedule, khách hàng B chỉ dùng Schedule và Workflow.

Nên để tiện setting menu thì cần phải có chức năng quản lý, thiết lập menu tùy theo yêu cầu enduser, kèm đó là cấp quyền truy cập menu theo role, authentication….

V.Test trước những kịch bản có thể xảy ra

Thường các hệ thống chạy tự động (Batch) thì phải test trước 6 tháng , hoặc 1 năm so với thời điểm hiện tại.
Ví dụ như 1 công ty xử lý hợp đồng điện thoại, internet theo kiểu KH sẽ điền form trực tiếp, và có 1 hệ thống batch sẽ đọc nội dung của khách hàng,  và hoàn thành hợp đồng. Vì hợp đồng kiểu này sẽ cần phải setup và qua nhiều bước nên đa phần cuối ngày batch sẽ chạy. Hoặc như các giao dịch ngân hàng, vé tàu điện cũng dùng batch.

Mà dùng batch thì sẽ phụ thuộc vào yếu tố như ngày giờ, và độ ổn định server, và các tình huống khác: chạy batch theo giờ, ngày, tháng (1 tháng chạy 1 lần), nên để đảm bảo batch chạy ngon thì người ta sẽ thuê 1 đội để test trước, bằng cách viết testcase , tạo data và đưa vào cho batch chạy.

VI.Đối ứng câu hỏi của End user

Khi làm sản phẩm cho enduser dùng và sau khi release thì hệ thống không thể chạy trơn tru ngay lập tức, và sẽ có những vấn đề phát sinh ngoài guidline đã gửi cho enduser.
Với số lượng người dùng lên đến trăm ngàn thì số lượng câu hỏi (問い合わせ) sẽ rất nhiều. Nếu không có chiến lược đối ứng, hoặc dùng hệ thống chuyên dụng của bên thứ 3 thì hầu như không thể kiểm soát nổi.

Các công ty lớn thì hầu hết có call center, nhưng để quản lý hiệu quả, và đối ứng nhanh thì cần phải có hệ thống quản lý câu hỏi.

1 số hệ thống quản lý :

https://freshdesk.com/jp/compare/inquiry-management-tool/