Phát triển offshore  Drupal: Chất lượng được đảm bảo bằng “quy trình”, không phải bằng may mắn

Một khách hàng từng chia sẻ với chúng tôi rằng họ rất lo lắng khi triển khai offsore development. Lý do xuất phát từ trải nghiệm trước đây: “Đã gửi tài liệu đặc tả nhưng sản phẩm nhận lại lại khác với những gì mong đợi.” . Tuy nhiên, khi phân tích nguyên nhân, vấn đề không nằm ở năng lực của kỹ sư. Nguyên nhân thực sự là do không tồn tại một quy trình giúp phát hiện và làm rõ những điểm mơ hồ trong tài liệu đặc tả trước khi bắt đầu phát triển. Thất bại trong offshore development, trong nhiều trường hợp, không phải là vấn đề của “con người” mà là vấn đề của “quy trình.”
Trong bài viết này, chúng tôi sẽ chia sẻ toàn bộ mô hình tổ chức, workflow và quy trình đảm bảo chất lượng mà đội ngũ Drupal của chúng tôi đang áp dụng trong thực tế.
—
Điều gì quyết định thành công hay thất bại của một dự án Drupal offshore?
Trước tiên, hãy nhìn vào những nguyên nhân khiến một dự án offshore không đạt kết quả như mong đợi. Trong thực tế, phần lớn vấn đề thường xuất phát từ bốn nguyên nhân sau:
⁃ Không có quy trình rà soát và làm rõ những điểm chưa rõ trong tài liệu đặc tả -> đội ngũ phát triển phải suy đoán khi thực hiện và dẫn đến việc mất từ 2–3 tuần để sửa đổi sau đó.
⁃ Không có quy trình escalation cho các câu hỏi -> các thắc mắc không được trao đổi kịp thời, dự án tiếp tục triển khai và cuối cùng phải sửa đổi toàn bộ sau khi hoàn thành.
⁃ Tiêu chí kiểm thử phụ thuộc vào đánh giá chủ quan của từng cá nhân -> bài kiểm thử vẫn đạt nhưng hệ thống gặp lỗi khi triển khai lên production.
Tiêu chuẩn thiết kế và review phụ thuộc vào từng người -> khi thay đổi nhân sự, chất lượng sản phẩm cũng thay đổi theo.
Không một vấn đề nào trong số đó có thể được giải quyết chỉ bằng cách tuyển dụng những kỹ sư giỏi hơn. Đây là những vấn đề của quy trình và cần được giải quyết bằng quy trình.
Đồng thời, Drupal thực tế là một CMS rất phù hợp với mô hình phát triển phân tán (distributed development). Một phần lớn chức năng của Drupal được xây dựng thông qua cấu hình thay vì code. Các cấu hình này có thể được quản lý phiên bản và đồng bộ giữa các môi trường bằng Configuration Management, tương tự như source code. Nhờ đó, những tình huống kiểu: “Trên môi trường này chạy được nhưng sang môi trường khác thì không”, ít khi xảy ra hơn so với nhiều nền tảng khác.

4 cơ chế đảm bảo chất lượng
① Chuẩn hóa tài liệu thiết kế và tiêu chí kiểm thử:
Chúng tôi xây dựng các mẫu tài liệu và danh sách tiêu chí kiểm thử theo chuẩn nội bộ. Nhờ đó, dù người phụ trách có thay đổi thì mức độ chi tiết và chất lượng của sản phẩm đầu ra vẫn được duy trì đồng nhất, đồng thời hạn chế sự phụ thuộc vào cá nhân.
② Review bởi bộ phận Đảm bảo Chất lượng (QA) độc lập:
Một bộ phận QA độc lập với nhóm phát triển sẽ thực hiện việc phân tích nguyên nhân và kiểm tra lỗi dưới góc nhìn khách quan. Cách làm này giúp tránh tình trạng lập trình viên tự review chính phần code do mình viết.

③ Các hạng mục kiểm tra chuyên biệt dành cho Drupal:
Bên cạnh các tiêu chí kiểm tra thông thường trong phát triển web, chúng tôi bổ sung thêm các bước xác nhận dành riêng cho Drupal, bao gồm việc có hay không việc core hack (chỉnh sửa trực tiếp Drupal Core), Việc mở rộng chức năng có được thực hiện đúng thông qua hook hoặc plugin hay không, thiết lập phân quyền có phù hợp hay không, có bỏ sót cache tag hay không, Các module đang sử dụng có thuộc phạm vi được hỗ trợ bởi Security Advisory (SA) hay không. Trong số đó, hạng mục cuối cùng đặc biệt quan trọng. Những module không thuộc chương trình Security Advisory sẽ không nhận được hỗ trợ chính thức khi phát hiện lỗ hổng bảo mật. Vì vậy, chúng tôi luôn kiểm tra tiêu chí này trước khi quyết định sử dụng module.

④ Loại bỏ chênh lệch môi trường bằng quản lý phiên bản cấu hình:
Thông qua Configuration Management của Drupal, các thiết lập như Content Type, Field, View… được export dưới dạng YAML và quản lý bằng Git.
Cách tiếp cận này giúp phát hiện các trường hợp: “Ai đó đã thay đổi cấu hình trực tiếp trên môi trường production.”
Đồng thời loại bỏ khác biệt về cấu hình giữa môi trường phát triển tại Việt Nam và Nhật Bản.

Những rủi ro cần lưu ý
Dưới đây là những điểm chúng tôi cho rằng cần trao đổi thẳng thắn khi doanh nghiệp cân nhắc mô hình offshore development.
⁃ Việc chênh lệch múi giờ nhỏ chỉ là điều kiện cần, chứ không phải là đảm bảo cho chất lượng. Nhật Bản và Việt Nam chỉ lệch nhau 2 giờ, nhưng nếu không có quy trình phù hợp thì dù khoảng cách có gần đến đâu, dự án vẫn có thể thất bại.
⁃ Khi một nhà cung cấp nói rằng “có automated test”, bạn cần tìm hiểu cụ thể nội dung của nó. Việc automated test chỉ bao phủ các luồng nghiệp vụ chính hay bao phủ toàn diện toàn hệ thống sẽ tạo ra sự khác biệt rất lớn. Chỉ nhìn vào tên công cụ là không đủ để đánh giá.
⁃ Sự phụ thuộc vào cá nhân không phải là vấn đề riêng của offshore development. Cách duy nhất để hạn chế rủi ro này là chuẩn hóa quy trình. Việc “có một người rất giỏi” đồng thời cũng đi kèm với rủi ro khi người đó không còn tham gia dự án.
⁃ Core hack thường không gây vấn đề ngay khi bàn giao hệ thống, nhưng sẽ trở thành rủi ro lớn sau vài năm vận hành. Hệ thống có thể hoạt động bình thường tại thời điểm bàn giao, nhưng nếu Drupal Core đã bị chỉnh sửa trực tiếp thì các bản cập nhật sau này gần như không thể áp dụng được. Vì vậy, đây là một hạng mục nên được thống nhất là điều cấm ngay từ giai đoạn lựa chọn nhà cung cấp.

Xu hướng thị trường Nhật Bản
Tại Nhật Bản, việc sử dụng offshore development đang ngày càng mở rộng do tình trạng thiếu hụt nguồn lực phát triển phần mềm.
⁃ Trong lĩnh vực đảm bảo chất lượng (QA), việc thiếu tự động hóa vẫn liên tục được nhắc đến như một thách thức lớn, đồng thời tình trạng thiếu hụt nhân sự chuyên môn cũng ngày càng nghiêm trọng.
⁃ Việt Nam có lợi thế là chỉ chênh lệch 2 giờ so với Nhật Bản và thời gian làm việc của hai bên gần như trùng nhau. Điều này giúp việc “đặt câu hỏi và nhận được câu trả lời ngay trong ngày” diễn ra thuận lợi hơn so với nhiều địa điểm offshore khác.
⁃ Những nền tảng như Drupal, nơi cấu hình có thể được quản lý như mã nguồn (code), giúp giảm thiểu rủi ro do khác biệt môi trường trong mô hình phát triển phân tán một cách có hệ thống.

Cơ cấu phát triển Drupal thực tế tại TTV
Đội ngũ Drupal của chúng tôi là một tổ chức chuyên trách, đồng thời phụ trách nhiều dự án cho cả thị trường Nhật Bản và các thị trường quốc tế.
Các lĩnh vực đã triển khai bao gồm eCommerce, website doanh nghiệp, healthcare và hệ thống quản lý hospitality. Đến nay, chúng tôi đã tham gia xây dựng mới và bảo trì hơn 10 website Drupal, đồng thời hỗ trợ nâng cấp đến phiên bản mới nhất là Drupal 11.

■Vai trò và phạm vi trách nhiệm
Mỗi vị trí trong đội ngũ đều được xác định rõ phạm vi trách nhiệm. Điều này giúp hạn chế sự phụ thuộc vào cá nhân và duy trì chất lượng ngay cả khi có sự thay đổi nhân sự.

■Các điểm chính trong quy trình triển khai
Việc phân chia vai trò được áp dụng trong thực tế theo cách sau:
BrSE rà soát trước các điểm mơ hồ trong đặc tả – Trước khi bắt đầu phát triển, các nội dung có thể gây nhiều cách hiểu khác nhau sẽ được xác nhận với phía Nhật Bản nhằm tránh việc triển khai dựa trên suy đoán và phát sinh sửa đổi về sau.
QA độc lập kiểm tra sự tồn tại của core hack trước khi release – Một nhóm QA độc lập với đội phát triển sẽ xác nhận xem có bất kỳ implementation nào có thể gây cản trở cho các bản cập nhật trong tương lai hay không.
Thiết kế theo nguyên tắc tránh core hack ngay từ đầu – Thay vì phát hiện và sửa lỗi ở bước QA, đội phát triển chủ động thiết kế theo hướng không tạo ra core hack ngay từ giai đoạn implementation.

■Kết quả
Nhờ mô hình này, các dự án có thể được triển khai mà không phát sinh những đợt sửa đổi lớn, đồng thời nhiều khách hàng tiếp tục sử dụng dịch vụ bảo trì và vận hành sau khi hệ thống đi vào hoạt động. Triết lý của chúng tôi là: đảm bảo chất lượng bằng quy trình không chỉ mang lại một lần bàn giao thành công, mà còn tạo nền tảng cho mối quan hệ hợp tác lâu dài với khách hàng.

Kết luận
Chủ đề chính của bài viết này là: “Chất lượng được đảm bảo bằng quy trình, không phải bằng năng lực của một cá nhân.”
⁃ Nguyên nhân dẫn đến thất bại trong offshore development thường không nằm ở năng lực của kỹ sư mà ở việc thiếu một quy trình triển khai phù hợp.
⁃ Tại TTV, chúng tôi đảm bảo chất lượng thông qua bốn cơ chế: chuẩn hóa tài liệu và quy trình, QA độc lập, các hạng mục kiểm tra chuyên biệt dành cho Drupal và quản lý phiên bản cấu hình.
⁃ Nhật Bản và Việt Nam chỉ chênh lệch nhau 2 giờ, giúp quá trình trao đổi câu hỏi và phản hồi thường có thể hoàn thành trong cùng một ngày làm việc.
⁃ Drupal là một CMS phù hợp với mô hình phát triển phân tán, bởi các cấu hình có thể được quản lý như mã nguồn thông qua Configuration Management. Điều này giúp giảm đáng kể rủi ro do khác biệt môi trường phát triển.
Chúng tôi cung cấp dịch vụ Drupal offshore development và mô hình phát triển theo đội ngũ chuyên trách (Lab Model).
Khách hàng có thể trao đổi với chúng tôi ngay cả khi chỉ muốn tìm hiểu về cơ cấu tổ chức, quy trình triển khai hoặc xem các mẫu tài liệu thiết kế thực tế.

Nguồn tham khảo
transcosmos technology Vietnam Services
Drupal Configuration Management Documentation
Drupal.org User Profile