Từ “BPM” sang “DM”: Từ ngày 1/9, chúng tôi thay đổi tên gọi của vai trò

Từ ngày 1 tháng 9 năm 2026, tên vị trí được sử dụng trong báo giá, đề xuất và hợp đồng sẽ được đổi từ BPM (Bridge Project Manager) sang DM (Delivery Manager).

Đơn giá và điều kiện hợp đồng không thay đổi. Người phụ trách các dự án hiện tại cũng không bị thay thế. Điều thay đổi là tên gọi và phạm vi trách nhiệm mà vai trò đó đảm nhận.

Lần thứ ba thay đổi tên vị trí

Đây là lần thứ ba chúng tôi thay đổi tên của vị trí này.

Lần đầu tiên là vào năm 2008, khi VFA được thành lập. Khi đó, giữa khách hàng Nhật Bản và đội ngũ phát triển tại Việt Nam có nhiều vai trò trung gian: Bridge SE, IT Communicator, Tester, Developer. Công việc được chia nhỏ theo từng công đoạn và mỗi công đoạn có một người phụ trách. Mười tám năm trước, đây là cách làm phổ biến trong phát triển phần mềm theo mô hình nhận ủy thác.

Phân công chuyên môn có ưu điểm. Phạm vi phụ trách của mỗi người hẹp hơn nên việc tuyển dụng và đào tạo cũng dễ hơn. Tuy nhiên, càng có nhiều người đứng giữa, trách nhiệm đối với từng quyết định càng trở nên không rõ ràng. Khi có sự khác biệt trong cách hiểu đặc tả, sẽ mất thời gian để xác định đó là vấn đề dịch thuật hay vấn đề thiết kế. Quan trọng hơn, người chịu trách nhiệm về kết quả của toàn bộ dự án thường chỉ có ở phía khách hàng.

Vì vậy, VFA đã hợp nhất các vai trò trung gian thành một vai trò duy nhất. Tên gọi thứ hai của vai trò này là BPM.

Bridge Project Manager không phải là một chức danh phổ biến trên thị trường. Đây là tên gọi do VFA tự xây dựng trong nội bộ. Chúng tôi muốn đặt một người không chỉ chịu trách nhiệm về “bridge” — tức dịch thuật và điều phối — mà còn chịu trách nhiệm cho chính tiến độ của dự án. Đó là ý nghĩa mà chúng tôi muốn gửi gắm vào tên gọi này.

Lần này, chúng tôi sẽ ngừng sử dụng tên BPM.

Tại sao lại thay đổi một lần nữa?

Lý do lớn nhất là cách khách hàng quyết định “sẽ xây dựng cái gì” đã thay đổi.

Trước đây, phát triển phần mềm thường dựa trên giả định rằng câu trả lời đúng đã tồn tại ngay từ đầu. Khách hàng hoàn thiện yêu cầu và bàn giao dưới dạng đặc tả. Công việc của chúng tôi là hiện thực hóa chúng nhanh chóng và không có lỗi. Mục tiêu không thay đổi. Vì vậy, nhiệm vụ của người đứng giữa chỉ cần là “truyền đạt chính xác”.

Ngày nay, giả định đó không còn đúng nữa.

Không có một nguyên nhân duy nhất. Thị trường thay đổi nhanh hơn, khiến chính vòng đời của kế hoạch kinh doanh cũng ngắn lại. Trong vài tháng phát triển, đối thủ, quy định và cơ cấu nội bộ của khách hàng đều có thể thay đổi. Với khách hàng, phát triển nội bộ đã trở thành một lựa chọn thực tế. Công nghệ xung quanh phát triển phần mềm, bao gồm AI, cũng thay đổi theo chu kỳ chỉ vài tháng. Không yếu tố nào trong số này là nguyên nhân quyết định duy nhất, nhưng khi chúng cộng lại, cách làm “vừa xây dựng vừa tìm ra câu trả lời đúng” ngày càng trở thành lựa chọn khó tránh khỏi.

So với trước đây, chúng tôi thấy ngày càng nhiều dự án bắt đầu trong trạng thái mà ngay ở buổi họp đầu tiên, việc “nên xây dựng cái gì” vẫn chưa được xác định rõ. Khi chính kế hoạch kinh doanh vẫn đang thay đổi thì điều đó là tự nhiên. Trạng thái từng có thể bị xem là “chậm trong khâu định nghĩa yêu cầu” giờ đây không còn hiếm khi trở thành điểm xuất phát của dự án.

Khi mục tiêu thay đổi, công việc của người đứng giữa cũng phải thay đổi. Dịch thuật, biên bản họp, chuyển tiếp tiến độ — phần lớn những công việc bridge như vậy hiện có thể được thay thế bằng công cụ.

Thay vào đó, hai trách nhiệm ngày càng quan trọng hơn.

Một là quyết định không xây dựng cái gì.
Hai là đảm bảo những gì đã quyết định sẽ được delivery đến cùng.

Từ “bridge” chỉ hợp lý khi giả định rằng câu trả lời đúng đã tồn tại ở phía bên kia và chỉ cần được chuyển tiếp. Khi giả định đó không còn, tên gọi này cũng không còn diễn tả đúng vai trò nữa.

DM là người làm gì?

Vai trò bridge là người chuyển thông tin. DM là người nhận trách nhiệm về kết quả.

DM có ba trách nhiệm chính.

Thứ nhất là quyết định ưu tiên. Trong khoảng thời gian hữu hạn, DM cùng khách hàng quyết định nên xây dựng gì và điều gì nên để lại sau.

Thứ hai là hoàn thành delivery. Trách nhiệm không dừng ở việc “xây dựng xong đúng theo đặc tả”, mà kéo dài đến khi sản phẩm được release và thực sự được sử dụng.

Thứ ba là đưa rủi ro lên sớm. Khi vấn đề còn nhỏ, DM phải chủ động đưa ra với khách hàng. Chúng tôi đưa tiêu chí “không trì hoãn tin xấu” vào tiêu chí đánh giá DM.

Điều này không có nghĩa là “BPM trước đây chỉ làm công việc trung chuyển”. Chúng tôi đã có nhiều thành viên hiểu sâu đặc tả, nắm cả bối cảnh kinh doanh của khách hàng và chủ động dẫn dắt phát triển.

DM không phải là việc phát minh ra một công việc mới. Đây là việc đặt lại tên để biến cách làm đó thành tiêu chuẩn của tổ chức.

Chúng tôi đổi tên để chấm dứt tình trạng chỉ dựa vào quyền chủ động của một số cá nhân xuất sắc.

Từ PM đến COE

Chỉ DM là chức danh được đổi tên. Tuy nhiên, định nghĩa vai trò của tất cả các vị trí đều đã được rà soát lại.

• PM: Phụ trách giai đoạn từ 0 đến 1. PM làm việc trực tiếp với khách hàng, xác định vấn đề thực sự cần giải quyết và đưa ra đề xuất.
• DM: Phụ trách giai đoạn từ 1 đến 10. DM vận hành chu kỳ release và cải tiến, đồng thời chịu trách nhiệm hoàn thành delivery.
• Developer: Không phải vai trò chỉ phụ trách implementation. Developer hiểu vì sao sản phẩm được xây dựng, cộng tác với AI và chịu trách nhiệm phán đoán để kiểm tra, nghiệm thu những gì được tạo ra.
• PMO: Kiểm tra việc tuân thủ tiêu chuẩn vượt ra ngoài phạm vi từng dự án riêng lẻ, đồng thời dùng dữ liệu để phát hiện sớm dấu hiệu của sự cố.
• COE: Xây dựng nền tảng kỹ thuật cho năng suất và đảm bảo chất lượng, sau đó phân phối cho toàn bộ team. COE cũng tiếp nhận và giải quyết những bài toán kỹ thuật có độ khó cao mà một dự án riêng lẻ không thể xử lý triệt để.

Ba vai trò đầu là lớp trực tiếp vận hành dự án. Hai vai trò sau là lớp hỗ trợ.

Cả PM và DM đều làm việc trực tiếp với khách hàng. Không phải mô hình DM chỉ ở bên trong công ty và mọi trao đổi đều phải thông qua PM.

Báo giá và cách triển khai

Trước đây, VFA thường liệt kê toàn bộ chức năng và báo giá một lần cho tất cả. Không chỉ những chức năng khách hàng nói là cần, mà cả những thứ chúng tôi nghĩ “nên có” hay “về lý tưởng thì phải có” cũng được thêm vào với thiện ý.

Kết quả là có những trường hợp báo giá của chúng tôi có thể trông cao hơn các công ty khác.

Hiện nay, chúng tôi chia thành ba giai đoạn.

1. PoC: Vừa làm prototype thực tế, vừa xác định chính xác nên xây dựng điều gì.
2. MVP: Giới hạn ở những chức năng tối thiểu để sản phẩm có thể tồn tại, sau đó release trước.
3. Iteration: Tiếp tục cải tiến trong khi sắp xếp lại mức độ ưu tiên theo chu kỳ từ hai tuần đến một tháng.

Điều này không có nghĩa là chúng tôi thêm một công đoạn mới. Chúng tôi chỉ chia những gì trước đây gộp trong một lần release thành ba giai đoạn.

Nếu xây dựng cùng một thứ, chỉ vì chia thành ba giai đoạn không có nghĩa thời gian sẽ kéo dài hoặc chi phí sẽ tăng. Ngược lại, sau khi nhìn thấy một thứ thực sự chạy được rồi mới quyết định phần còn lại, có thể sẽ xuất hiện những chức năng không còn cần phải xây dựng.

Vì không cố định mọi thứ ngay từ đầu, thời gian đến lần release đầu tiên đã nhanh hơn đáng kể so với trước đây.

Thời gian và chi phí đến lần release đầu tiên vẫn được chúng tôi đưa ra dựa trên yêu cầu hiện có tại thời điểm đó. Đây là thông tin cần thiết để khách hàng ra quyết định đặt hàng, nên chúng tôi không để phần này mơ hồ.

Báo giá của VFA không chỉ cộng chi phí phát triển ban đầu. Chúng tôi báo giá theo một cơ cấu xuyên suốt từ PoC, release MVP đến bảo trì và cải tiến sau đó.

Sau khi người dùng tại hiện trường hoặc end user bắt đầu sử dụng sản phẩm, những yêu cầu mới sẽ xuất hiện. Báo giá của chúng tôi bao gồm cả cách đội ngũ tiếp tục phản hồi những yêu cầu đó.

Vì vậy, phạm vi của nó khác với báo giá chỉ dành cho giai đoạn phát triển ban đầu.

Mức độ ưu tiên chắc chắn sẽ thay đổi. Không có gì đảm bảo rằng danh sách chức năng được quyết định khi bắt đầu vẫn là phương án tối ưu sau sáu tháng.

Một báo giá yêu cầu quyết định toàn bộ thứ cần xây ngay từ đầu không thể phản ánh những thay đổi đó. Vì vậy, chúng tôi sử dụng mô hình cho phép sắp xếp lại thứ tự ưu tiên trong quá trình phát triển như tiêu chuẩn.

Mục tiêu không phải là tăng số lượng chức năng.

Nếu thêm một thứ, liệu có thể bỏ một thứ khác hay không?

Cùng khách hàng suy nghĩ về điều đó là một phần công việc của DM.

Xung đột giữa tốc độ và chất lượng

Release nhanh và không làm hỏng sản phẩm. Hai điều này vốn có xu hướng xung đột với nhau.

Làm nhanh thì chất lượng có thể giảm. Cố bảo vệ chất lượng thì tiến độ có thể chậm lại. Nếu cố gắng dung hòa hai việc này chỉ bằng nỗ lực của đội ngũ tại hiện trường, sớm muộn ở đâu đó hệ thống cũng sẽ vỡ. Con người sẽ mệt mỏi và quá tải.

Vì vậy, VFA quyết định đảm bảo điều này bằng chính hệ thống. Nền tảng này được chúng tôi gọi nội bộ là AI Foundation.

Trên thực tế, đây là các plugin và rule set độc quyền của VFA được nạp sẵn vào IDE mà developer sử dụng.

Nó tích hợp cơ chế kiểm soát AI agent, ảo hóa và cô lập môi trường, security audit, v.v. Ở khu vực có rủi ro thấp, team có thể chạy hết tốc độ. Ở khu vực có rủi ro cao, hệ thống sẽ tự động “đạp phanh”.

Về cơ bản, đó là tất cả những gì nó làm.

Nếu chỉ ghi quy tắc trong tài liệu, đến một lúc nào đó sẽ không còn ai đọc. Vì vậy, chúng tôi nhúng các quy tắc trực tiếp vào môi trường thực thi để cách làm an toàn trở thành mặc định.

Nền tảng được cấu thành từ bốn lớp, từ Layer 1 đến Layer 4, và được áp dụng theo bốn mức độ tương ứng với rủi ro mà dự án phải chịu.

Phạm vi bao gồm:

• an toàn của môi trường xử lý thông tin mật,
• review chất lượng và lỗ hổng của code được tạo ra,
• ngăn regression bằng automated test.

Phần mềm càng gần với thị trường, mức yêu cầu càng nghiêm ngặt.

Audit cũng không phải là thao tác thủ công trên Excel. Quá trình này được tự động hóa trên GitHub, và report cho biết dự án nào đang vận hành ở cấp độ nào.

Về testing, tình hình đã thay đổi trong vài năm gần đây.

Trước đây, do giới hạn về thời gian và ngân sách, có nhiều dự án buộc phải từ bỏ lượng test code mà chúng tôi thực sự muốn viết.

Giờ đây, khi có thể sử dụng AI, chúng tôi có thể triển khai được lượng test đó.

Khả năng liên tục sửa đổi mà không làm hỏng hệ thống phụ thuộc rất lớn vào điểm này.

Nền tảng này vẫn chưa hoàn thiện. Chúng tôi đang tiếp tục phát triển nó trong quá trình vận hành.

Ảnh hưởng đối với khách hàng

• Thay đổi cách ghi chức danh: Từ các báo giá, đề xuất và hợp đồng phát hành vào hoặc sau ngày 1 tháng 9 năm 2026, ký hiệu BPM sẽ được thay bằng DM.
• Đơn giá và điều kiện hợp đồng: Không thay đổi.
• Người phụ trách: Người phụ trách các dự án hiện tại không thay đổi. Chỉ tên gọi được thay đổi.
• Cách triển khai: Việc điều chỉnh workflow theo định nghĩa vai trò mới sẽ được trao đổi riêng theo từng dự án. Không phải mọi thứ sẽ đồng loạt chuyển đổi ngay trong ngày 1 tháng 9.

Lời cuối

Chỉ đổi tên thì rất dễ. Điều khó hơn là đào tạo được những con người có thể hành động đúng với ý nghĩa của cái tên đó.

Dù vậy, chúng tôi vẫn quyết định bắt đầu từ việc đổi tên, bởi vì tên gọi có thể định hình phạm vi của công việc.

Chừng nào một người vẫn được gọi là “bridge”, cả bản thân họ và những người xung quanh sẽ có xu hướng nhìn họ như một đường truyền thông tin. Đôi khi khách hàng cũng vậy.

Trong thực tế, chúng tôi có những người có khả năng tiến sâu hơn rất nhiều vào dự án, nhưng chính tên gọi cũ lại vô tình kéo họ trở lại.

Tên gọi DM được chọn để loại bỏ lực kéo đó.

Trong mỗi dự án khách hàng giao cho chúng tôi, sẽ có một người chịu trách nhiệm rõ ràng, có tên và có gương mặt, đứng ra nhận trách nhiệm về kết quả.

Điều đó sẽ không thay đổi.

Nếu có bất kỳ câu hỏi nào, vui lòng liên hệ với nhân viên sales phụ trách hoặc PMO.

Câu hỏi thường gặp

Q. Đơn giá có thay đổi không?
A. Không. Chúng tôi không điều chỉnh giá chỉ vì thay đổi tên vai trò.

Q. Người đang phụ trách dự án hiện tại có thay đổi không?
A. Không. Những thành viên trước đây phụ trách với vai trò BPM sẽ tiếp tục phụ trách cùng dự án với chức danh DM.

Q. Có cần ký lại hợp đồng không?
A. Không. Đối với hợp đồng hiện tại, chúng tôi sẽ không yêu cầu ký lại chỉ vì thay đổi tên chức danh. Các tài liệu mới được tạo từ ngày 1 tháng 9 trở đi sẽ lần lượt chuyển sang tên mới.

Q. Cách triển khai dự án có thay đổi đột ngột từ tháng 9 không?
A. Không. Định nghĩa vai trò sẽ chuyển đổi chính thức từ ngày 1 tháng 9, nhưng cách làm thực tế sẽ được chuyển tiếp thông qua trao đổi riêng với từng dự án.

Q. Điều này có nghĩa VFA sẽ không còn phát triển offshore nữa phải không?
A. Không. Trung tâm phát triển của chúng tôi vẫn ở Việt Nam. Điều thay đổi là cách chúng tôi làm việc: từ mô hình nhận “câu trả lời đúng” rồi xây dựng, sang mô hình cùng khách hàng tìm ra câu trả lời đúng.