Bước vào bất kỳ trung tâm công nghệ nào ở Noida, bạn sẽ thấy hàng tá agency hứa hẹn các giải pháp web trọn gói (end-to-end). Các bản thuyết trình dự án của họ trông rất ấn tượng. Đội ngũ bán hàng của họ nghe rất tự tin. Nhưng khi đi sâu vào chi tiết, một mô típ quen thuộc sẽ lộ diện. Danh mục dự án (portfolio) khiến bạn kinh ngạc với những giao diện mượt mà có thể đang che giấu một đội ngũ thậm chí không thể viết nổi một câu truy vấn cơ sở dữ liệu. Hoặc một đơn vị đang khoe khoang về Laravel và Node.js có thể mang lại một trải nghiệm người dùng chẳng khác gì một bảng tính từ năm 2003. Khách hàng thường chỉ phát hiện ra sự sai lệch này sau khi hợp đồng đã ký, tiền đặt cọc đã mất, và dự án đã đi chệch hướng. Khi đó, mọi thiệt hại đã rồi.

Bạn có thể tránh được mớ hỗn độn này. Mọi thứ bắt đầu từ việc hiểu rằng thiết kế web (web design) và phát triển web (web development) không phải là cùng một chuyên môn, và việc thuê một bên nhầm lẫn giữa hai khái niệm này là con đường nhanh nhất dẫn đến lãng phí ngân sách.

Khoảng cách giữa Pixel và Thực tế triển khai

Thiết kế web tập trung vào việc một trang web trông như thế nào và mang lại cảm giác ra sao. Một nhà thiết kế sẽ suy nghĩ về phân cấp thị giác, khoảng trắng, tâm lý học màu sắc và lộ trình mà người dùng đi từ trang đích (landing page) đến bước thanh toán hoặc biểu mẫu liên hệ. Họ làm việc trên các công cụ như Figma hoặc Adobe XD. Sản phẩm cuối cùng là một bộ các màn hình tĩnh hoặc một bản mẫu (prototype) có thể nhấp vào được. Nó cho bạn thấy tầm nhìn. Nó không thu thập dữ liệu biểu mẫu, không xử lý thanh toán, cũng không phục vụ hàng ngàn khách truy cập cùng lúc. Nó là một bản thiết kế kỹ thuật, không phải là một tòa nhà hoàn thiện.

Phát triển web là giai đoạn kỹ thuật. Một lập trình viên sẽ lấy những bản thiết kế đó và viết mã HTML, CSS và JavaScript để hiển thị trên trình duyệt. Nếu dự án yêu cầu, họ cũng sẽ xây dựng logic backend, cấu hình máy chủ, thiết kế sơ đồ cơ sở dữ liệu (database schema) và tích hợp các dịch vụ bên thứ ba như cổng thanh toán, API vận chuyển hoặc các nhà cung cấp xác thực. Kết quả đầu ra là một URL trực tiếp có thể hoạt động thực sự.

Hai thế giới này nói những ngôn ngữ khác nhau. Một nhà thiết kế lo lắng liệu một nút bấm có tạo cảm giác dễ tiếp cận hay không. Một lập trình viên lo lắng liệu chính nút bấm đó có kích hoạt một lệnh gọi API chính xác trong điều kiện độ trễ mạng hay không. Cả hai mối quan tâm đều quan trọng. Nhưng một agency nếu chỉ nói được một ngôn ngữ sẽ để lại một nửa công việc còn dang dở.

Ảo tưởng về "Dịch vụ trọn gói"

Thị trường agency ở Noida rất đông đúc. Sự cạnh tranh vô cùng khốc liệt. Vì vậy, các công ty thường mặc nhiên tuyên bố họ làm được mọi thứ, từ thiết kế đến triển khai. Thực tế thường không cân xứng. Một đơn vị có thể có ba nhà thiết kế hình ảnh tài năng nhưng chỉ có một lập trình viên sơ cấp làm việc bán thời gian. Hoặc ngược lại: những kỹ sư lỗi lạc nhưng lại coi typography (nghệ thuật chữ) là yếu tố phụ. Cả hai sự mất cân bằng này đều không phục vụ tốt cho khách hàng.

Rủi ro không chỉ nằm ở thẩm mỹ. Một đội ngũ thiên về thiết kế có thể tạo ra những bản mockup tuyệt đẹp nhưng lại là cơn ác mộng khi xây dựng giao diện đáp ứng (responsive). Một đội ngũ thiên về phát triển có thể đắp một template admin đại trà lên sản phẩm của bạn và gọi đó là thiết kế thương hiệu. Sự mất kết nối này chỉ trở nên rõ ràng trong quá trình kiểm thử chấp nhận người dùng (UAT), khi bạn nhận ra trang web trông chẳng giống chút nào với ý tưởng đã được phê duyệt, hoặc ý tưởng đó ngay từ đầu đã không khả thi về mặt kỹ thuật.

Ba câu hỏi giúp bạn nhìn thấu sự thật

Trước khi ký bất cứ thứ gì, hãy sử dụng những câu hỏi này để kiểm tra xem một agency có thực sự am hiểu cả hai lĩnh vực hay không.

Hãy cho tôi xem ba trang web mà các bạn vừa thiết kế vừa xây dựng. Đừng chấp nhận những ví dụ mà họ chỉ đảm nhận một phần. Nếu có thể, hãy yêu cầu xem các file Figma và kho lưu trữ Git trực tiếp. Hãy hỏi cách họ xử lý một thay đổi về thiết kế trong quá trình phát triển. Nếu họ lúng túng, rất có thể họ đang thuê ngoài (outsource) một bên của quy trình hoặc đang phóng đại vai trò của mình.

Ai sẽ sở hữu quyền quản trị CMS sau khi ra mắt? Câu hỏi này nghe có vẻ hiển nhiên nhưng thường bị bỏ qua trong sự hào hứng khi trang web lên sóng. Bạn cần có thông tin đăng nhập, tài liệu hướng dẫn và quyền kiểm soát hệ thống quản trị nội dung ngay từ ngày đầu tiên. Một số agency sử dụng các thiết lập độc quyền nhằm khóa bạn vào dịch vụ lưu trữ của họ hoặc tính phí cho mỗi lần cập nhật nội dung nhỏ nhất. Hãy xác lập quyền sở hữu ngay từ đầu.

Quy trình để thêm một loại trang mới sau tám tháng là gì? Câu hỏi này sẽ tiết lộ trang web được xây dựng có tính toán về kiến trúc hay không. Một mã nguồn thiếu linh hoạt (brittle codebase) sẽ đòi hỏi sự can thiệp của lập trình viên cho mọi thay đổi cấu trúc nhỏ nhất. Một trang web được xây dựng tốt sẽ cho phép đội ngũ marketing của bạn linh hoạt tạo ra các bố cục trang đích mới thông qua CMS mà không cần phải gửi yêu cầu hỗ trợ (ticket). Nếu agency tỏ ra bối rối trước câu hỏi này, quy trình phát triển của họ có lẽ chỉ dừng lại ở lúc ra mắt, chứ không phải là khả năng bảo trì lâu dài.

Điểm mù của CMS

Đây chính là nơi mà hầu hết các dự án âm thầm thất bại sau khi ra mắt.

Khách hàng thường quá chú trọng vào phần hero section của trang chủ mà quên mất quy trình làm việc hàng ngày. Sáu tuần sau khi ra mắt, đội ngũ bán hàng của bạn muốn cập nhật giá. Quản lý nội dung cần đăng một bài nghiên cứu tình huống (case study). Trưởng phòng nhân sự muốn đăng ba vị trí tuyển dụng mới. Nếu việc thực hiện bất kỳ điều nào trong số này đều yêu cầu gửi yêu cầu hỗ trợ (support ticket) và chờ đợi hai ngày làm việc để lập trình viên chỉnh sửa một mẫu PHP, thì website của bạn đã trở thành một nút thắt cổ chai.

Đó là lý do tại sao chiến lược ưu tiên CMS (CMS-first strategy) lại quan trọng. Hệ thống quản trị nội dung nên là một phần của cuộc thảo luận ngay từ cuộc gọi tìm hiểu đầu tiên, chứ không phải là một thứ được gắn thêm vào một cách khiên cưỡng vào phút cuối. Đội ngũ của bạn phải có thể chỉnh sửa văn bản, thay đổi hình ảnh và xuất bản các trang mới mà không cần chạm vào mã nguồn. Nếu agency không hỏi bạn ai sẽ là người quản lý nội dung sau khi ra mắt, nghĩa là họ chưa thực sự nghĩ đến thực tế vận hành của bạn.

Khi hai đội ngũ trở thành con số không

Một số doanh nghiệp cố gắng giải quyết sự chia tách giữa thiết kế và phát triển bằng cách thuê các nhà cung cấp riêng biệt. Họ thuê một studio thiết kế ở Delhi để lo phần giao diện và trải nghiệm (look and feel), sau đó bàn giao các tệp cho một đơn vị phát triển ở Noida để xây dựng. Trên lý thuyết, mọi người đều có chuyên môn riêng. Nhưng trên thực tế, các lỗi sai lệch trong quá trình chuyển giao sẽ nhân lên gấp bội.

Các màn hình tĩnh không giải thích được hành vi phản hồi (responsive behavior). Một bản mockup không chỉ rõ điều gì sẽ xảy ra khi tìm kiếm không trả về kết quả nào. Nó không mô tả các trạng thái di chuột (hover states), khung tải dữ liệu (loading skeletons), thông báo lỗi hay các trạng thái trống (empty states). Lập trình viên buộc phải đoán ý đồ. Và thường thì họ đoán sai. Sau đó, nhà thiết kế xem xét trang staging và tuyên bố nó bị lỗi. Lập trình viên phản bác rằng bản thiết kế chưa hoàn thiện. Khách hàng phải trả tiền cho việc làm lại, trong khi hai đội ngũ lãng phí hàng tuần trời để tranh cãi qua các luồng Slack và chuỗi email.

Cái giá phải trả không chỉ là tài chính. Đó còn là đà phát triển. Các đợt ra mắt sản phẩm bị trì trệ. Lịch trình marketing bị đình trệ. Các đối thủ cạnh tranh tiến xa hơn trong khi đội ngũ của bạn phải đi vá những lỗ hổng lẽ ra không bao giờ nên tồn tại.

Cái giá thực sự của việc bàn giao

Nếu bạn là một freelancer đang đọc bài viết này, tất cả những điều trên không hề là lý thuyết. Có lẽ bạn đã từng phải tiếp quản những "đống đổ nát" như vậy. Bạn đã từng mở tệp Figma của khách hàng và chỉ thấy hai mươi artboard mà không có điểm ngắt (breakpoints) cho di động. Bạn đã từng nhìn chằm chằm vào một backend nơi mọi trường nội dung đều được viết cứng (hardcoded) vì lập trình viên trước đó chưa bao giờ gặp nhà thiết kế. Bạn đã từng báo giá một bản sửa lỗi trong hai ngày nhưng rồi phát hiện ra rằng nó đòi hỏi phải xây dựng lại toàn bộ cấu trúc nội dung.

Việc lấp đầy những khoảng cách này rất tốn kém vì chúng không bao giờ chỉ thuần túy là vấn đề kỹ thuật. Chúng là những thất bại trong giao tiếp được "đóng băng" vào trong mã nguồn.

Bài học rút ra

Một website không phải là một cái logo. Nó là một hệ thống sống kết nối doanh nghiệp của bạn với khách hàng thông qua cả hình ảnh lẫn cơ sở hạ tầng. Trước khi thuê bất kỳ agency nào, hãy biết rõ bạn thực sự đang mua một nửa nào của phương trình đó. Hãy kiểm tra quy trình của họ, yêu cầu bằng chứng về trách nhiệm quản lý từ đầu đến cuối (end-to-end ownership), và từ chối việc bỏ qua CMS cho đến khi lễ cắt băng khánh thành kết thúc. Dự án có thể vượt qua ngày ra mắt là dự án đã được lập kế hoạch cho cả ngày Thứ Ba tám tháng sau đó, khi bạn cần thay đổi một mức giá mà không cần phải gọi cho bất kỳ ai.