Nguyên Châu
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 delivery

SaaS B2B Nhật — 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.

Khách hàng Nhật Nền tảng SaaS B2B 2022/10 — nay BrSE → Delivery Manager
Tóm tắt dự án (Executive Summary)
  • Bài toán (Context): Tiếp quản một team nhỏ 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, tối ưu System Architecture kéo bug production từ 10–15 lỗi/tháng xuống 1–2 lỗi/tháng, và 4 năm liên tiếp không release nào trượt ngày đã cam kết.
Tóm tắt 4 năm — trong 3 dòng
Bug PROD
10–15 / tháng
→ 1–2 / tháng
Delivery
Trượt thường xuyên
→ 100% release đúng hẹn
Knowledge
Bus factor = 1
→ Shared team-wide
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 còn nhỏ.

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 được một nhóm tính năng nhỏ.

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 dự án. Đó 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 đó.

01

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

Trướ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:

1
Nhận yêu cầu từ khách hàng
2
Phân tích 4 chiều: User, Client, Dev, QC
3
Brainstorm tìm giải pháp ngon-bổ-rẻ
4
Thống nhất align nội bộ & propose
5
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.

02

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

Trước

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:

  1. 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?
  2. 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.

03

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

Trước

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

Quyết định

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

  1. Vì sao khách nhờ tính năng này?
  2. Output có giải quyết được pain point đó không?
  3. 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.

04

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

Trước

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 mà chất lượng không vỡ — knowledge không phụ thuộc cá nhân.

05

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ự:

  1. Mind-set làm việc — gốc rễ, dạy đầu tiên
  2. Phân tích yêu cầu — nguyên nhân, giải pháp
  3. Vì sao sản phẩm cần tính năng X — góc nhìn business
  4. Vì sao user trả tiền cho hệ thống — góc nhìn doanh thu
  5. 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.

06

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 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:
  1. User cuối là ai?
  2. Họ đang đau cái gì thật sự?
  3. Tính năng này giải được pain point đó — hay chỉ giải triệu chứng bề mặt?
05 Niềm tin

Vì sao khách đánh giá team bằng niềm tin

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à 2 thứ rất khác:

1

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.

2

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

Tức là khi khách push gấp, tôi 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.

Đó là thứ giữ được sự hợp tác 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.

06 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)
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
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

Bài viết này không tiết lộ chi tiết kỹ thuật, kiến trúc, hoặc số liệu kinh doanh của khách hàng. Tất cả nội dung được trình bày dưới góc nhìn người quản lý team nội bộ, và đã được rà soát đối chiếu với các thông tin đã được công bố công khai.