Nhật Bản: Tàu chạy cực tốt nhưng đặt vé online lại là cơn ác mộng

Hệ thống đường sắt Nhật Bản được cả thế giới ngưỡng mộ về độ chính xác và tốc độ, nhưng hành trình đặt vé trực tuyến lại khiến nhiều du khách nước ngoài bối rối. Một kỹ sư phần mềm đã chia sẻ trải nghiệm thực tế của mình, qua đó hé lộ mối liên hệ thú vị giữa cấu trúc tổ chức doanh nghiệp và thiết kế phần mềm.

Yahoo Nhật Bản mang phong cách giao diện những năm 90

Khi "kỳ quan kỹ thuật" đi kèm "cơn đau đầu" giao diện

Tác giả bài viết kể lại lần đầu đặt vé tàu tại Nhật: anh phải nhờ đến ChatGPT để hiểu hết các trường thông tin và ô chọn trên biểu mẫu. Một dòng ghi chú khiến anh bối rối: "Khi lên tàu, bạn sẽ cần vé cơ bản hoặc thẻ IC như Suica bên cạnh vé tàu Super (Limited) Express." Anh tự hỏi: đang mua vé tàu online, tại sao lại cần thêm một loại phí khác?

Câu trả lời nằm ở cấu trúc vận hành đặc thù: mạng lưới JR được chia thành sáu công ty hành khách khu vực gồm JR Hokkaido, JR East, JR West, JR Central, JR Shikoku và JR Kyushu. Mỗi công ty có nền tảng đặt vé riêng, phạm vi phủ chồng lấn và quy định khác nhau. Cuối cùng, chính người dùng phải tự xác định nên dùng nền tảng nào cho hành trình của mình.

Giao diện đặt vé tàu của JR-West với nhiều luồng và loại vé khác nhau

Định luật Conway lộ diện trong trải nghiệm người dùng

Trải nghiệm ức chế nhất mà tác giả gặp phải: sau khi xác nhận đặt vé, hệ thống thông báo phải dùng thẻ tín dụng vật lý để lấy vé tại ga. Vì đã dùng thẻ ảo, anh buộc phải hủy đặt chỗ, chịu phí 560 yên mỗi người rồi đặt lại bằng thẻ vật lý.

Vậy có phải giao diện Nhật Bản kém? Tác giả không nghĩ vậy. Ông cho rằng một phần khác biệt đến từ yếu tố văn hóa: ưu tiên sự quen thuộc hơn cái mới, tránh sai sót, thích sự chắc chắn, chú trọng tiểu tiết và ngại thay đổi. Giao diện Yahoo! Nhật Bản kiểu thập niên 90 vẫn tồn tại theo tinh thần "nếu chưa hỏng thì đừng sửa".

Tuy nhiên, có một nguyên nhân sâu xa hơn: cách tổ chức nội bộ doanh nghiệp định hình phần mềm mà họ xây dựng — định luật Conway (Conway's Law). Định luật này thường được bàn đến trong kiến trúc phần mềm, khi hệ thống phản ánh cấu trúc giao tiếp của các nhóm phát triển. Nhưng tác động của nó không dừng ở tầng backend: người dùng hỏi vé từ A đến B, còn hệ thống lại hỏi công ty đường sắt nào vận hành tuyến đó. Đây là ví dụ điển hình cho việc cấu trúc tổ chức "rò rỉ" vào trải nghiệm người dùng.

"Tôi hiểu vì sao cấu trúc tổ chức ảnh hưởng đến kiến trúc phần mềm. Nhưng liệu người dùng có phải hiểu cách một công ty được tổ chức chỉ để sử dụng phần mềm của họ? Tôi không nghĩ vậy."

Bài học cho nhà phát triển Việt Nam

Câu chuyện này mang lại bài học đáng suy ngẫm cho các đội ngũ sản phẩm tại Việt Nam. Khi xây dựng nền tảng đặt vé tàu, xe hay bất kỳ dịch vụ công nào, việc để cấu trúc nội bộ chi phối giao diện người dùng thường tạo ra ma sát không cần thiết. Người dùng chỉ quan tâm đến hành trình từ A đến B, không phải công ty nào đứng sau từng chặng.

Một số kinh nghiệm có thể rút ra:

• Ẩn sự phức tạp tổ chức khỏi người dùng: hệ thống nên tự định tuyến yêu cầu tới đơn vị vận hành phù hợp thay vì bắt người dùng tự chọn.

• Đơn giản hóa mô hình giá và loại vé trên giao diện, đồng thời minh bạch các khoản phí ngay từ đầu.

• Thiết kế luồng thanh toán linh hoạt, hỗ trợ cả thẻ ảo lẫn thẻ vật lý, tránh gây thiệt hại cho người dùng.

• Đặt trải nghiệm xuyên suốt lên trên ranh giới phòng ban, vì người dùng cảm nhận sản phẩm như một chỉnh thể chứ không thấy các phòng ban riêng lẻ.

Sự khác biệt văn hóa và di sản phần mềm có thể giải thích phần nào giao diện của Nhật Bản, nhưng việc để người dùng gánh chịu hậu quả của cấu trúc tổ chức nội bộ rõ ràng là điều các nhà phát triển ở bất kỳ quốc gia nào cũng nên tránh.