Câu chuyện nghề thật · không phải sales pitch A real delivery story · not a sales pitch 実体験のストーリー · 営業トークではありません

Một dự án · Bốn năm · Một team scale 7 → 31

MEO Dashboard — 4 năm xây một team delivery cho thị trường Nhật

Tôi không kể bạn nghe số liệu doanh thu của khách. Tôi kể những quyết định mà một BrSE — một Delivery Manager thật sự phải ra mỗi tuần để giữ team không vỡ, giữ chất lượng không trượt, và giữ niềm tin của khách Nhật suốt 4 năm liên tiếp gia hạn hợp đồng.

GMO TECH MEO platform #1 Nhật Bản 2022/10 — nay BrSE → Delivery Manager

Tóm tắt dự án (Executive Summary)

Bài toán (Context): Tiếp quản team 7 người thiếu quy trình chuẩn, bus factor = 1, trượt tiến độ liên tục, nhiều "bottleneck" kỹ thuật.
Giải pháp (Action): Tái cấu trúc theo hướng Delivery Manager: áp dụng flow phân tích 5 bước, validate spec 2 lần, và trở thành Hub knowledge sharing thay vì chỉ code.
Kết quả (Impact): Scale team lên 31 người, tối ưu System Architecture giúp giảm 90% bug production, tỷ lệ on-schedule đạt 100% trong 4 năm liên tiếp.

Tóm tắt 4 năm — trong 5 dòng

Team

7 người

→ 31 người

Bug PROD

10–15 / tháng

→ 1–2 / tháng

Delivery

Trượt thường xuyên

→ 100% on-schedule

Knowledge

Bus factor = 1

→ Shared team-wide

Khủng hoảng

Một core feature bị Google block

→ Giải pháp ổn định 6 tháng+

01 Bối cảnh

Tôi đã tiếp nhận bài toán này ở trạng thái nào?

Tháng 10/2022. Tôi vào với vai trò BrSE. Team chỉ 7 người.

Sản phẩm đã chạy production rồi, nhưng "lỏm" — hầu hết tính năng chạy chưa thật smooth. Performance tệ, trang load chậm, rất dễ mất khách. Lúc đó team mới chỉ giải quyết một group tính năng nhỏ: gom cửa hàng theo brand/area, edit và đăng bài hàng loạt cho Google Business Profile.

Nhưng vấn đề lớn nhất không phải kỹ thuật. Vấn đề lớn nhất là cách team làm việc:

Làm task ở đâu, bug ở đó. Ở đâu cũng có vấn đề.
Người làm task A không hiểu task B. Người làm task B không hiểu task C.
Bus factor = 1. Một người nghỉ là task đó delay. Khách hàng mắng ngay.
Không có daily MTG. Report bằng văn bản. Cuối tuần họp một lần mà cũng không giải quyết được gì.
Knowledge nằm trong đầu từng người, không được chia sẻ.

Đó là điểm xuất phát.

02 Bước ngoặt

Khi tôi nhận full 1.0 effort cho dự án này

Sau giai đoạn đầu vừa làm vừa quan sát, tôi nhận full 1.0 công số cho MEO. Đó là lúc tôi quyết định: không thể tiếp tục patch từng task. Phải thay đổi cách team làm việc trước, rồi mới nói chuyện chất lượng sản phẩm.

Tôi không tin vào việc áp một framework cứng — Scrum sách vở, SAFe, v.v. Tôi chọn hybrid Agile + Waterfall — giữ tính dự đoán của Waterfall cho khách Nhật, nhưng đưa MVP-first thinking và iteration của Agile vào trong team.

Cụ thể, tôi đã làm 6 thứ. Mỗi thứ là một quyết định, không phải "best practice copy-paste".

03 Decisions log

Sáu quyết định đã ra trong 4 năm

Không phải milestone marketing. Đây là những lúc tôi phải chọn — và những lý do thật phía sau lựa chọn đó.

Đổi từ "bồ câu đưa thư" sang flow phân tích 5 bước

Khách nói gì, team quotes lại. Dev làm máy móc theo spec. Đúng spec → release. Lên PROD → tính năng không giải quyết pain point thật của user → khách phải sửa → team rework → lặp lại.

Quyết định

Tạo flow xử lý requirement 5 bước, mọi req mới đều phải đi qua:

Nhận yêu cầu từ khách hàng

Phân tích 4 chiều: User, Client, Dev, QC

Brainstorm tìm giải pháp ngon-bổ-rẻ

Thống nhất align nội bộ & propose

Khách duyệt mới bắt đầu dev

Hindsight

Đây là quyết định quan trọng nhất 4 năm. Nó không phải process — nó là một thái độ: team không còn là robot, mà là partner kỹ thuật của khách. Bug rate sau này giảm mạnh chính là nhờ đây.

Spec validate 2 lần — trước dev và sau hoàn thành

Spec từ JP qua, dev VN làm, release, lỗi. Hỏi tại sao? — "Dev làm đúng spec mà." Câu trả lời này đúng nhưng vô dụng.

Quyết định

Mọi spec đều validate 2 lần, tôi là người chịu trách nhiệm review:

Lần 1 (trước khi dev bắt đầu): Verify dưới góc nhìn user + khách hàng. Có giải quyết pain point không? Có thiếu case không?
Lần 2 (sau khi hoàn thành): Verify dưới góc nhìn đội triển khai (dev, QC). Task này có cần thiết không? Có hướng nào tốt hơn không? Có nên đề xuất khách bỏ một phần?

Hindsight

Nguyên tắc này sinh ra từ những lần thức trắng sửa lại tính năng đã release. Tôi đã gắn nó vào DNA của mỗi sprint suốt 4 năm. Rework do hiểu sai spec gần như biến mất.

Định nghĩa lại "Done"

"Done" = dev xong + QC pass + release.

Quyết định

"Done" = trả lời được 3 câu hỏi:

Vì sao khách nhờ tính năng này?
Output có giải quyết được pain point đó không?
Còn sót bug nào không?

Nếu câu 1 không trả lời được — tôi đẩy ngược lại analyst. Không cho dev bắt đầu.

Hindsight

Đây là chỗ phân biệt "executor" với "consultant". Executor đo bằng output. Consultant đo bằng outcome.

Tôi tự đứng ra làm hub knowledge sharing

Mỗi người giữ kiến thức trong đầu. Knowledge không lưu thông. Bus factor = 1.

Quyết định

Tôi tổ chức MTG, tự đi hearing kiến thức của từng người, rồi share lại cho cả team. Bắt mọi người note lại:

Phạm vi ảnh hưởng của task
Nội dung đã phân tích
Decision đã chốt

Để tất cả các bên có một cái nhìn chung.

Hindsight

Nghe đơn giản nhưng làm 4 năm liền là chuyện khác. Đây là lý do team scale lên 31 mà chất lượng không vỡ — knowledge không phụ thuộc cá nhân.

Training hàng tuần — mind-set trước, technical sau

Bối cảnh

Team scale nhanh. Junior nhiều. Nếu không train, mỗi người sẽ tự định nghĩa "tốt" theo cách riêng.

Quyết định

Mỗi tuần một buổi training (2024 → 2025/6). Tôi tự soạn tài liệu. Nội dung đi theo thứ tự:

Mind-set làm việc — gốc rễ, dạy đầu tiên
Phân tích yêu cầu — nguyên nhân, giải pháp
Vì sao MEO cần tính năng X — góc nhìn business
Vì sao user trả tiền cho hệ thống — góc nhìn doanh thu
Vì sao user push release nhanh — góc nhìn áp lực vận hành của khách

Format mỗi buổi: tài liệu chuẩn bị sẵn → trao đổi 2 chiều → không phải one-way lecture. Từ 2025/6 trở đi, team đã cứng, training giảm tần suất.

Hindsight

Training mind-set quan trọng gấp 10 lần training technical. Technical Google được. Mind-set không.

Hire theo mind-set, không hire theo technical

Bối cảnh

Áp lực scale lên. Cám dỗ là hire ai có CV đẹp, kinh nghiệm dài.

Quyết định

Mind-set là gate đầu tiên. Bảo thủ mind-set → auto reject từ đầu. Technical chỉ là gate thứ hai. Junior được nhận nếu mind-set phù hợp, dù technical chưa đủ.

Onboarding 3–6 tháng. Mentor có thưởng tiền hàng tháng để mentor cho mentee đến chuẩn. Chỉ khi mentee đạt chuẩn mới được vào làm task khách.

Hindsight

Tỉ lệ junior pass onboarding là 100%. Không phải vì onboarding dễ — mà vì gate mind-set đã loại sẵn từ vòng phỏng vấn.

04 Khủng hoảng

Đêm Google chặn crawl

Đây là chương tôi nhớ rõ nhất trong 4 năm.

Một ngày, Google chặn không cho crawl kết quả khi nhập keyword.

Đây là tính năng lõi.

Mất nó là mất sản phẩm.

Team lao vào điều tra.

48 tiếng liên tục.

Kỹ thuật A — không work.

Kỹ thuật Z — không work.

AI đề xuất — thử rồi.

Hướng từ cộng đồng dev — thử rồi.

Những giả thuyết obvious nhất — thử hết rồi.

Không có gì work.

Ai cũng kiệt sức.

Cảm giác give up bắt đầu lan ra trong team — không ai nói ra, nhưng tôi đọc được điều đó qua khoảng lặng dài hơn ở các cuộc họp sync.

Tôi không làm điều mà sách vở leadership hay khuyên.

Tôi không ép team tìm hướng khác.

Tôi không thúc đẩy bằng pep talk.

Pep talk khi team đã kiệt sức = thêm áp lực, không thêm idea.

Tôi làm một việc rất cụ thể, gần như buồn tẻ:

Ngồi xuống. Mở tất cả note, log, thử nghiệm thất bại của team. Sắp xếp lại theo trình tự luồng xử lý.

Đọc từng dòng. Đọc lại lần hai. Đọc lại lần ba.

Và tôi nhận ra một chỗ team chưa thực sự điều tra.

Nó nằm giữa luồng xử lý.

Không ai dừng lại ở đó — vì ai cũng cho rằng nó thuộc về phần trước hoặc phần sau.

Đó là blind spot của team. Một điểm mà chỉ người đứng ngoài luồng, nhìn toàn cảnh, mới thấy được.

"Ánh sáng đã có. Mình thử hướng này."

Team đi tiếp.

Vài đêm sau — giải pháp work.

Kết quả: Tính năng đã chạy ổn định liên tục từ 2025/09 đến nay (2026/05). Hơn 6 tháng không sự cố.

Hôm nay tôi nhìn quanh thị trường — đối thủ vẫn đang vật lộn tìm giải pháp. Chúng tôi đã đi trước họ ít nhất 8 tháng.

(Giải pháp cụ thể — tôi xin giấu. Nó là tài sản của khách.)

Bài học của riêng tôi từ đêm đó

Khi team đã kiệt sức, đừng ép họ động não thêm.

Hãy lấy việc động não về phía mình.

Lúc đó vai trò của leader không phải push — mà là quan sát toàn cảnh khi mọi người đang chìm trong chi tiết.

05 Sai lầm

Sai lầm tôi đã ra — và đã học được gì

Tôi không kể câu chuyện này để trang trí cho sự khiêm tốn.

Bối cảnh: Có một giai đoạn task quá nhiều. Tôi bị dí. Khách hàng cũng bị user dí ngược lại nên cũng rối. Tôi rơi vào trạng thái "khách nói gì làm nấy" — chính cái thái độ mà tôi vẫn dạy team phải tránh.

Tôi quên đặt mình vào view của end-user. Tôi tin rằng khách đã suy nghĩ kỹ.

Kết quả: Release xong, output không như mong muốn. Team phải thức trắng mấy đêm để sửa lại.

Bài học: Khách không phải lúc nào cũng đại diện đúng cho user. Pain point thật sự đôi khi nằm sâu hơn 1 lớp so với cái khách đang yêu cầu. Trách nhiệm của BrSE là đào sâu thêm 1 lớp đó — kể cả khi đang bị dí.

Từ đó, mỗi req tôi luôn dừng lại 1 nhịp — hỏi 3 câu:

User cuối là ai?
Họ đang đau cái gì thật sự?
Tính năng này giải được pain point đó — hay chỉ giải triệu chứng bề mặt?

06 Niềm tin

Vì sao hợp đồng được gia hạn liên tiếp 4 năm

Tôi đã suy nghĩ rất nhiều về câu hỏi này. Sau 4 năm, tôi nhận ra một điều: ở năm đầu, khách đánh giá team qua tốc độ — feature làm nhanh hay chậm. Nhưng từ năm thứ hai trở đi, thước đo của khách đã đổi. Cái họ đánh giá không còn là tốc độ nữa, mà là 3 thứ rất khác:

Team có nhìn thấy rủi ro trước khi nó xảy ra không?

Tức là proactive raise concern khi đọc spec, chứ không phải làm xong rồi mới báo lỗi.

Team có hiểu business pressure phía sau mỗi requirement không?

Tức là khi khách push gấp, mình hiểu vì sao họ push — và đôi khi đề xuất hướng khác giúp họ giải pressure tốt hơn.

Khi khủng hoảng xảy ra, team có giữ được sự ổn định không?

Đêm Google chặn crawl là test case rõ nhất.

Đó là thứ đã giữ hợp đồng được gia hạn liên tiếp suốt 4 năm — không phải khuyến mãi, không phải giảm giá, không phải nỗ lực sales.
Đó là niềm tin, được xây bằng từng quyết định nhỏ trong từng sprint.

07 Số liệu nội bộ

Những con số tôi có thể nói

Tôi không show doanh thu của khách. Đó là số của họ. Nhưng đây là những gì thuộc về team tôi, tôi có quyền nói:

Chỉ số nội bộ	Trước (2022)	Nay (2026)
Quy mô team MEO	7 người	31 người (+12 BrSE)
Bug PROD mỗi tháng	10–15	1–2
On-schedule delivery	Trượt thường xuyên	100%
Junior pass onboarding	—	100%
Rework do hiểu sai spec	Cao (không đo)	Gần như bằng 0
Hợp đồng	—	Gia hạn liên tiếp 4 năm
Crawl feature uptime sau giải pháp mới	—	6 tháng+ ổn định

Số liệu sản phẩm (cửa hàng trả phí, doanh thu khách...) đã được public qua GMO Group Award 2025 — anh/chị có thể tìm thấy ở trang chủ của tôi.

Nếu anh/chị đã đọc đến đây

Cảm ơn — và một lời mời không pitch

Không sales pitch. Không template. Chỉ là góc nhìn thực chiến từ một người đã đi qua giai đoạn đó. Cứ kết nối để cùng giao lưu.

Kết nối & trao đổi Xem quy trình 6 bước

Cởi mở giao lưu · Chia sẻ chuyên môn · Không cam kết ràng buộc