Mở đầu — vì sao bài này quan trọng
Có một hiểu lầm phổ biến mà gần như mọi PM mới chuyển sang vai trò Technical PM đều mắc phải: họ nghĩ rằng "technical decision-making" nghĩa là họ phải tự mình chọn database, chọn ngôn ngữ lập trình, hay quyết định kiến trúc microservices hay monolith. Rồi họ hoảng loạn, vì rõ ràng họ không đủ giỏi kỹ thuật để đưa ra những quyết định đó tốt hơn một senior engineer.
Tin tốt là: bạn không cần làm điều đó. Và thực tế, nếu bạn cố làm, bạn sẽ phá hỏng team.
Vai trò của bạn trong các quyết định kỹ thuật không phải là người đưa ra quyết định. Vai trò của bạn là người đảm bảo rằng quyết định ĐÚNG được đưa ra — đúng người tham gia, đúng thông tin được đặt lên bàn, đúng tiêu chí đánh giá, và đúng ngữ cảnh kinh doanh được kết nối vào. Engineer giỏi về "cái này khả thi không và tốn bao nhiêu công sức". Bạn giỏi về "cái này có đáng làm không, đánh đổi cái gì, và nó phục vụ ai".
Đây là một trong những kỹ năng phân biệt rõ nhất giữa một PM kỹ thuật xuất sắc và một PM chỉ biết viết user story. Khi bạn làm chủ được nghệ thuật điều phối quyết định kỹ thuật, bạn trở thành người mà cả CTO lẫn từng kỹ sư đều muốn có trong phòng họp. Khi bạn làm sai, bạn hoặc trở thành "PM micro-manage không hiểu gì cũng đòi quyết", hoặc trở thành "PM bù nhìn gật đầu mọi thứ engineer nói". Bài học hôm nay sẽ giúp bạn tránh cả hai cái bẫy đó.
Khái niệm cốt lõi
Bốn nhiệm vụ thật sự của PM trong một quyết định kỹ thuật
Hãy ghi nhớ khung này, vì nó là xương sống của cả bài. Trong bất kỳ quyết định kỹ thuật quan trọng nào, công việc của bạn gồm bốn phần:
- Cung cấp bối cảnh kinh doanh (business context). Engineer không thể chọn đúng nếu họ không biết: tính năng này phục vụ bao nhiêu người dùng, mức độ ưu tiên là gì, deadline thị trường ra sao, và đâu là ràng buộc không thể nhân nhượng. Một quyết định "tốt về mặt kỹ thuật" nhưng trễ ba tháng so với đối thủ có thể là một quyết định tồi về mặt kinh doanh.
- Đảm bảo các phương án được nêu ra rõ ràng (surface the options). Engineer giỏi thường có sẵn 2-3 cách làm trong đầu nhưng chỉ trình bày một. Việc của bạn là hỏi: "Còn cách nào khác không? Nếu ta có gấp đôi thời gian thì sao? Nếu chỉ có một nửa thì sao?". Bạn buộc các phương án phải hiện ra ánh sáng.
- Làm rõ các đánh đổi (trade-offs). Mọi quyết định kỹ thuật đều là đánh đổi: nhanh hơn nhưng tốn tiền hơn, đơn giản hơn nhưng khó mở rộng hơn, an toàn hơn nhưng chậm hơn. Bạn là người dịch các đánh đổi kỹ thuật này thành ngôn ngữ tác động kinh doanh để mọi người cùng hiểu cái giá phải trả.
- Đảm bảo quyết định được ghi lại và truyền đạt (document & communicate). Sáu tháng sau, khi có người mới vào team hỏi "tại sao ta dùng cái này?", phải có câu trả lời. Quyết định không được ghi lại là quyết định sẽ bị lật lại vô tận.
Phân biệt: One-way door và Two-way door
Đây là khái niệm Jeff Bezos phổ biến và cực kỳ hữu ích. Hãy phân loại mọi quyết định thành hai loại:
- Two-way door (cửa hai chiều): quyết định có thể đảo ngược với chi phí thấp. Nếu sai, bạn quay lại và sửa. Ví dụ: chọn một thư viện UI, đặt tên một API endpoint nội bộ, chọn màu cho nút bấm. Với loại này, đừng phân tích quá nhiều. Tốc độ quan trọng hơn sự hoàn hảo. Hãy để team quyết nhanh và đi tiếp.
- One-way door (cửa một chiều): quyết định khó hoặc cực kỳ tốn kém để đảo ngược. Ví dụ: chọn cơ sở dữ liệu lõi, thiết kế schema dữ liệu khách hàng, chọn nhà cung cấp cloud, hay quyết định cấu trúc API công khai mà hàng nghìn khách hàng sẽ tích hợp. Với loại này, bạn chậm lại, kéo đúng người vào, yêu cầu phân tích kỹ, và ghi lại cẩn thận.
Công cụ vàng: Architecture Decision Record (ADR)
ADR là một tài liệu ngắn (thường nửa trang đến một trang) ghi lại một quyết định kỹ thuật quan trọng. Cấu trúc kinh điển gồm: Context (bối cảnh, vấn đề cần giải), Options considered (các phương án đã cân nhắc và đánh đổi của từng cái), Decision (quyết định cuối cùng), và Consequences (hệ quả, cả tốt lẫn xấu, mà ta chấp nhận). Là PM, bạn không cần viết phần kỹ thuật sâu, nhưng bạn nên là người thúc đẩy việc ADR tồn tại và đảm bảo phần "bối cảnh kinh doanh" và "hệ quả" được viết rõ ràng.
Decision matrix — biến cảm tính thành định lượng
Khi có nhiều phương án và nhiều tiêu chí, một bảng ma trận quyết định giúp cuộc tranh luận thoát khỏi "tôi thấy cái này hay hơn". Bạn liệt kê các tiêu chí (chi phí, thời gian, độ rủi ro, khả năng mở rộng, trải nghiệm dev...), gán trọng số cho từng tiêu chí dựa trên bối cảnh kinh doanh, rồi cho điểm từng phương án. Bảng này không tự đưa ra quyết định thay bạn, nhưng nó phơi bày giả định và buộc mọi người tranh luận về trọng số thay vì cãi nhau cảm tính.
Tình huống thực tế
Tình huống 1 — Tiki và bài toán "tự xây hay dùng dịch vụ tìm kiếm"
Hãy tưởng tượng một sàn thương mại điện tử lớn ở Việt Nam, gọi là sàn X (lấy cảm hứng từ các sàn như Tiki, Shopee). Team kỹ thuật cần nâng cấp hệ thống tìm kiếm sản phẩm. Tech Lead trình bày một phương án duy nhất: "Tụi em sẽ tự xây search engine trên Elasticsearch, kiểm soát hoàn toàn ranking, mất khoảng bốn tháng cho ba kỹ sư."
Một PM non kinh nghiệm sẽ gật đầu vì nghe rất hợp lý. Nhưng PM kỹ thuật giỏi sẽ làm bốn việc. Đầu tiên, cung cấp bối cảnh: "Mục tiêu quý này của ta là tăng tỷ lệ chuyển đổi từ tìm kiếm thêm 8%, và mùa sale 11/11 còn ba tháng nữa." Thứ hai, ép phương án hiện ra: "Ngoài tự xây, còn cách nào? Dùng dịch vụ search-as-a-service như Algolia hay một giải pháp managed thì sao?". Tech Lead thừa nhận có, nhưng "tốn phí hằng tháng và bị khóa vào vendor". Thứ ba, làm rõ đánh đổi: tự xây mất bốn tháng — tức là lỡ luôn mùa sale lớn nhất năm; dùng managed service ra mắt trong ba tuần nhưng tốn khoảng 200 triệu/năm và khó tùy biến ranking sâu.
Khi đặt cạnh nhau, đánh đổi trở nên rõ ràng theo cách kinh doanh: lỡ mùa 11/11 có thể mất doanh thu hàng chục tỷ, lớn hơn nhiều so với chi phí license. Quyết định cuối: dùng managed service cho mùa sale này (two-way door — có thể thay sau), song song lên kế hoạch tự xây cho năm sau nếu khối lượng đủ lớn để hoàn vốn.
Bài học rút ra: PM không chọn Elasticsearch hay Algolia. PM đảm bảo cả hai phương án được đặt lên bàn và đánh đổi được dịch sang ngôn ngữ tiền bạc và thời gian thị trường. Nếu không có PM, team đã âm thầm tự xây và lỡ mất quý quan trọng nhất.
Tình huống 2 — Một startup fintech và quyết định schema "một chiều"
Một startup ví điện tử ở Đông Nam Á (giả định, quy mô khoảng 200 nghìn người dùng) cần thiết kế cấu trúc dữ liệu giao dịch. Engineer đề xuất gộp tất cả loại giao dịch — nạp tiền, rút tiền, chuyển khoản, hoàn tiền — vào một bảng duy nhất với cột "type" để phân biệt, vì "làm vậy nhanh, đỡ phải join nhiều bảng."
Nghe có vẻ là chuyện kỹ thuật thuần túy mà PM không nên xen vào. Nhưng PM kỹ thuật giỏi nhận ra đây là one-way door: một khi hàng triệu giao dịch đã ghi vào cấu trúc này, việc đổi schema sau này gần như bất khả thi mà không downtime và rủi ro sai lệch số dư.
PM không phán quyết về thiết kế bảng. Thay vào đó, cô ấy mang bối cảnh tương lai vào phòng: "Sáu tháng tới ta sẽ làm tính năng cho vay và phải báo cáo cho Ngân hàng Nhà nước. Liệu cấu trúc này có tách bạch được luồng tiền theo yêu cầu compliance không? Nếu kiểm toán hỏi 'cho tôi toàn bộ giao dịch hoàn tiền của user này trong 2024', truy vấn có dễ không?". Câu hỏi này khiến team dừng lại, nhận ra rủi ro tuân thủ, và họ chủ động tách bảng theo loại nghiệp vụ. Quyết định được ghi vào một ADR, kèm phần hệ quả: "Chấp nhận join phức tạp hơn để đổi lấy khả năng audit và mở rộng nghiệp vụ tài chính."
Bài học rút ra: Giá trị của PM không nằm ở việc biết thiết kế database, mà ở việc nhận diện đây là cửa một chiều và bơm vào những ràng buộc kinh doanh tương lai mà engineer không có tầm nhìn để thấy.
Tình huống 3 — Cái bẫy "PM quyết thay engineer" ở một công ty SaaS
Một công ty SaaS có PM tên Minh, vốn xuất thân là lập trình viên. Trong một cuộc họp về việc chọn message queue, Minh tuyên bố: "Dùng Kafka đi, tôi đọc thấy ai cũng dùng Kafka." Team triển khai Kafka. Ba tháng sau, hóa ra hệ thống của họ chỉ xử lý vài nghìn message/ngày — Kafka là con dao mổ trâu giết gà, tốn chi phí vận hành khổng lồ và không ai trong team đủ kinh nghiệm bảo trì. Một hàng đợi đơn giản hơn nhiều đã thừa sức làm việc.
Sai lầm của Minh không phải là chọn sai công nghệ. Sai lầm là anh đã giành lấy quyết định không thuộc về mình. Anh dùng "thẩm quyền PM" để áp đặt một lựa chọn kỹ thuật, làm engineer mất tiếng nói và mất luôn cảm giác sở hữu (ownership). Khi mọi thứ hỏng, không ai cảm thấy có trách nhiệm sửa, vì "đó là quyết định của Minh."
Bài học rút ra: Khi PM lấn sân quyết định kỹ thuật thuần túy, hai điều tệ xảy ra cùng lúc: quyết định thường tệ hơn (vì PM thiếu chiều sâu), và tinh thần sở hữu của engineer bị phá hủy. Việc của bạn là hỏi đúng câu hỏi để team tự đi đến quyết định tốt, không phải đưa ra câu trả lời.
Hướng dẫn từng bước
Khi đối mặt với một quyết định kỹ thuật cần bạn tham gia điều phối, hãy đi theo quy trình sau:
- Phân loại cửa. Hỏi ngay: đây là one-way door hay two-way door? Nếu là cửa hai chiều và rủi ro thấp, hãy nói rõ "cái này ta quyết nhanh, sai thì sửa" và để engineer chủ động. Đừng tốn năng lượng quá mức.
- Đặt bối cảnh kinh doanh lên bàn trước tiên. Trước khi bàn giải pháp, hãy phát biểu rõ: vấn đề người dùng là gì, ràng buộc thời gian/ngân sách, mục tiêu nào không thể nhân nhượng. Đây là phần chỉ bạn cung cấp được.
- Yêu cầu ít nhất hai phương án. Một câu hỏi thần kỳ: "Đây là phương án duy nhất, hay là phương án em thích nhất?". Nếu team chỉ có một lựa chọn, hãy ép họ nghĩ ra ít nhất một phương án thay thế để có cái mà so sánh.
- Buộc trade-off hiện ra bằng ngôn ngữ kinh doanh. Với mỗi phương án, hỏi: tốn bao lâu, tốn bao nhiêu tiền, rủi ro lớn nhất là gì, nó khóa ta vào điều gì trong tương lai. Rồi dịch sang tác động: trễ deadline nào, mất khách hàng nào, nợ kỹ thuật bao nhiêu.
- Lập decision matrix nếu có từ ba phương án trở lên. Liệt kê tiêu chí, gán trọng số theo bối cảnh, cho điểm. Tranh luận về trọng số, không tranh luận cảm tính.
- Để người có thẩm quyền kỹ thuật chốt. Với quyết định kỹ thuật thuần túy, hãy để Tech Lead chốt. Bạn là người điều phối và phản biện, không phải người gõ búa.
- Ghi lại bằng ADR và truyền đạt. Đảm bảo có một tài liệu ngắn ghi context, options, decision, consequences. Chia sẻ cho cả những người không dự họp.
Lỗi thường gặp & mẹo
Lỗi 1 — Giành quyết định kỹ thuật không thuộc về mình. Như tình huống của Minh. Mẹo: trước khi đưa ra ý kiến kỹ thuật, tự hỏi "mình đang cung cấp bối cảnh, hay đang áp đặt giải pháp?". Nếu là cái sau, hãy biến nó thành một câu hỏi thay vì một mệnh lệnh.
Lỗi 2 — Đối xử với mọi quyết định như nhau. Phân tích quá kỹ cái không quan trọng, và quá hời hợt cái quan trọng. Mẹo: luôn phân loại one-way/two-way door ngay từ đầu.
Lỗi 3 — Chấp nhận phương án đầu tiên engineer đưa ra. Engineer thường trình bày phương án quen thuộc nhất, không phải tối ưu nhất. Mẹo: luôn hỏi "còn cách nào khác?" — chỉ riêng câu này đã nâng chất lượng quyết định lên đáng kể.
Lỗi 4 — Không ghi lại quyết định. Sáu tháng sau không ai nhớ vì sao, và team lật lại cuộc tranh luận cũ. Mẹo: ADR là rẻ tiền nhất nhưng tiết kiệm nhất; nửa trang giấy cứu hàng giờ tranh cãi sau này.
Lỗi 5 — Để cuộc họp sa lầy vì không ai có thẩm quyền chốt. Mẹo: trước cuộc họp quyết định, xác định rõ ai là "decider". Một mô hình hữu ích là phân vai: ai quyết, ai góp ý, ai chỉ cần được thông báo.
Mẹo nâng cao — "Disagree and commit". Đôi khi bạn không đồng ý với quyết định cuối cùng, nhưng nó không phải one-way door và bạn không phải người có thẩm quyền kỹ thuật. Hãy nêu rõ quan điểm phản biện một lần, rồi cam kết ủng hộ hết mình. Phá hoại ngầm một quyết định đã chốt là cách nhanh nhất để mất uy tín với team kỹ thuật.
Bài tập thực hành
Bài tập 1 — Phân loại cửa. Lấy năm quyết định kỹ thuật gần nhất trong dự án của bạn (hoặc một dự án giả định). Phân loại từng cái là one-way door hay two-way door. Với mỗi cái, viết một câu giải thích chi phí đảo ngược. Bạn sẽ ngạc nhiên khi nhận ra mình từng dành thời gian sai chỗ.
Bài tập 2 — Viết một ADR. Chọn một quyết định kỹ thuật mà team bạn từng đưa ra nhưng không ghi lại. Viết một ADR hồi cố cho nó: Context, Options considered, Decision, Consequences. Tập trung làm thật rõ phần bối cảnh kinh doanh và hệ quả — đó là phần bạn đóng góp được nhiều nhất.
Bài tập 3 — Lập decision matrix. Hãy lấy tình huống "tự xây hay dùng managed service" cho một tính năng bất kỳ. Liệt kê 4-5 tiêu chí, gán trọng số (tổng 100%) dựa trên một bối cảnh kinh doanh bạn tự đặt ra, rồi cho điểm hai phương án. Quan sát xem việc thay đổi trọng số làm kết quả lật ngược như thế nào — đó chính là lý do bối cảnh kinh doanh quyết định tất cả.
Bài tập 4 — Luyện câu hỏi. Viết ra năm câu hỏi mở bạn có thể dùng để giúp team tự đi đến quyết định tốt mà không cần bạn áp đặt. Ví dụ mẫu: "Nếu ta phải ra mắt trong hai tuần, em sẽ làm khác đi thế nào?".
Tóm tắt
Vai trò của bạn trong các quyết định kỹ thuật không phải là người gõ búa — mà là người đảm bảo quyết định đúng được đưa ra. Bốn nhiệm vụ cốt lõi: cung cấp bối cảnh kinh doanh, ép các phương án hiện ra, làm rõ đánh đổi bằng ngôn ngữ kinh doanh, và ghi lại quyết định.
Hãy luôn phân loại one-way door (chậm lại, cẩn trọng) và two-way door (quyết nhanh, sai thì sửa) để dồn năng lượng đúng chỗ. Dùng ADR để ghi lại và decision matrix để định lượng khi cần. Tránh hai cái bẫy lớn nhất: giành quyết định không thuộc về mình (phá hủy ownership của engineer) và gật đầu thụ động (bỏ lỡ vai trò phản biện của bạn).
Khi bạn làm chủ kỹ năng này, bạn không còn là PM "ngoài lề kỹ thuật" — bạn trở thành chất xúc tác giúp cả team đưa ra những quyết định tốt hơn cả khi không có bạn. Đó chính là dấu ấn của một Technical PM thực thụ.