Khi Product và Engineering "Lệch Pha": Cách Giảm Ma Sát Trước Khi Mọi Thứ Bị Đóng Băng
Last updated: August 01, 2025 Xem trên toàn màn hình
Recommended for you
- 04 Mar 2020
Kinh nghiệm lập dự toán chi phí dự án phần mềm theo phương pháp Man-Month 2315 - 04 Sep 2021 Tào lao là gì? Các bí quyết để tránh tào lao trong giao tiếp 1514
- 04 Aug 2021 Đừng sợ đi chậm, chỉ sợ đứng yên 993
- 28 Apr 2023 Mô hình Why, How, What là gì? 973
- 07 Aug 2024 Kỷ nguyên VUCA và TUNA – Cơ hội phát triển và chuyển đổi mạnh mẽ nhờ cuộc cách mạng 4.0 866
- 16 Mar 2022 [INFOGRAPHIC] 32 Thiên kiến nhận thức làm sai lệch quyết định của bạn (Phần I) 815
- 01 Jul 2023 Phương pháp Shuhari - Làm sao học ít hiểu nhiều? 743
- 01 Aug 2022 "Sponsored Content" là gì? Khác nhau giữa Sponsored Content và Native Advertising? 632
- 04 Jan 2023 Phát triển phần mềm linh hoạt theo mô hình Big Bang 585
- 15 Aug 2024 Kỹ năng thuyết trình với kỹ năng ABC (Accuracy, Brevity, Clarity) 582
- 01 Feb 2022 Thách thức với doanh nghiệp chuyển đổi số trong thời đại VUCA 576
- 18 May 2021 Cây cầu hiện đại vô dụng nhất thế giới và câu chuyện cái kết của thay đổi yêu cầu 518
- 24 Mar 2021 Hiệu ứng Dunning-Kruger – Ảo tưởng sức mạnh về năng lực của bản thân 518
- 29 Sep 2022 Từ chuyện người ăn xin và chiếc cần câu cá, điều gì là quan trọng nhất: Kiến thức, kỹ năng hay thái độ với cuộc sống 480
- 29 Jul 2020 Câu chuyện mài chiếc rìu trước khi chặt cây: Bài học từ tổng thống vĩ đại nhất của nước Mỹ - Abraham Lincoln 465
- 03 Mar 2020 Giả định (Assumption ) là gì? Tại sao giả định rất quan trọng với dự án? 424
- 01 Mar 2021 Ý nghĩa và bài học rút ra từ truyện thầy bói xem voi 417
- 12 Apr 2023 Phương pháp 6 chiếc mũ tư duy là gì? Vận dụng trong điều hành cuộc họp hiệu quả 411
- 09 Dec 2021 Sơ đồ chuỗi giá trị (Value Stream Mapping - VSM) là gì? 411
- 03 May 2022 Mô hình Hybrid Agile là gì? 409
- 15 Apr 2020 Phần mềm BPM là gì? So sánh với ERP và các phần mềm Workflows 401
- 16 Mar 2022 [INFOGRAPHIC] 32 thiên kiến nhận thức làm sai lệch quyết định của bạn (Phần II) 389
- 03 Feb 2020 Sản phẩm OEM và ODM là gì? 383
- 14 Jun 2021 8 loại lãng phí doanh nghiệp phải tìm cách loại bỏ 381
- 18 Mar 2021 Kỹ thuật ước lượng dự án phần mềm linh hoạt dựa vào Story Point - phương pháp T-Shirt Sizing 380
- 01 Aug 2019 5 nguyên lý khởi nghiệp tinh gọn rút ra từ thực tế 360
- 01 Apr 2023 Bí quyết đàm phán tạo ra giá trị từ câu chuyện Chia Cam 360
- 01 May 2022 Có thể xác định vị trí địa lý của địa chỉ IP với độ chính xác đến từng địa chỉ con phố? 352
- 07 Aug 2019 Câu chuyện thanh gỗ ngắn và bài học kinh doanh cho Doanh nghiệp 342
- 11 Oct 2024 "Kham Nhẫn" Trong Kinh Doanh: Sức Mạnh Của Sự Kiên Nhẫn 340
- 10 Jul 2021 Chuyên gia chia sẻ các nguyên tắc tư duy sáng tạo hệ thống với tên gọi Systematic Inventive Thinking (SIT) 333
- 08 Nov 2022 16 phong cách làm việc của người Nhật Bản mà Việt Nam cần học hỏi 329
- 02 Aug 2023 Tổng hợp một số project tham khảo khi xây dựng các ứng dụng theo mô hình Microservices 328
- 14 Aug 2022 Khác biệt giữa tiêu chí hoàn thành DOD (Definition of Done) với tiêu chí nghiệm thu (Acceptance Criteria) 312
- 20 Jul 2021 Quản lý và đánh giá công việc theo quy trình TIGO SmartWork 311
- 12 May 2021 Các yêu cầu thay đổi (Change Requests) - nỗi ám ảnh của team dự án phần mềm 309
- 02 Aug 2021 Product Owner làm gì trước khi bắt đầu sprint đầu tiên của dự án (Sprint Zero)? 306
- 11 Sep 2024 Mindset, skillset, toolset là gì? 299
- 01 Aug 2023 Phân tích yêu cầu phần mềm sẽ nhìn vào thực trạng (AS-IS) hay tương lai (TO-BE)? 292
- 04 Jan 2023 Đánh giá nhân sự theo chuẩn người Nhật 276
- 12 May 2020 Quy trình sản xuất Tinh Gọn và áp dụng mô hình 5S của Nhật Bản 273
- 28 Jun 2024 Tại sao các kỹ sư IT giỏi nhất lại là những người theo thuyết bất khả tri về công nghệ (technology agnostics)? 256
- 11 Sep 2022 Sức mạnh của lời khen 241
- 14 Apr 2019 Product Backlog là gì? Các đặc điểm cơ bản của một Product Backlog 237
- 22 Jan 2025 Khi ngư dân không thể ra khơi, họ sửa lưới 236
- 02 Mar 2018 Tại sao ví Scrum như dòng điện xoay chiều? 232
- 04 Sep 2023 Giải mã nhóm tính cách (ISTP - Nhà kỹ thuật) 213
- 03 Oct 2021 Khác biệt giữa thiết kế phần mềm và thiết kế công trình xây dựng 209
- 17 Aug 2020 Mục tiêu dự án là gì? Làm thế nào để xác định mục tiêu? 201
- 23 Jun 2024 Người trí tuệ không tranh cãi ĐÚNG/SAI 198
- 08 Jan 2022 Yêu cầu thay đổi (Change Request) là gì? Làm thế nào để kiểm soát Change Request? 191
- 14 May 2024 Chiến lược răng lược là gì? Làm thế nào để tận dụng chiến lược răng lược trong kinh doanh? 184
- 12 Sep 2021 Túi càn khôn của lập trình viên Agile cần trang bị những gì? 180
- 07 Jan 2025 Phân biệt Proxy, HMA và VPN 178
- 11 Sep 2022 Từ truyện “Thầy bói xem voi” tới quản trị bằng Tư Duy Hệ Thống 178
- 10 May 2021 Phát triển Phần mềm Tinh gọn (Lean Software Development) 175
- 08 Mar 2022 Mô hình nguồn mở hoạt động ra sao? 169
- 08 Feb 2021 Quy trình nâng cấp phần mềm quản trị doanh nghiệp TIGO ERP 162
- 24 Mar 2019 Scrum giống như bà mẹ chồng, giúp bạn nhìn ra các lỗi sai 154
- 14 Dec 2022 Phương pháp kiểm tra Fagan Inspection là gì? 152
- 01 Sep 2020 Co-founder là gì? Vai trò của các Co-Founder khi lập nghiệp. 151
- 08 Mar 2020 Vì sao doanh nghiệp cần phải tạo Web bán hàng? 149
- 01 May 2023 [Tư vấn CNTT] Quản lý ngân sách CNTT cho doanh nghiệp 145
- 01 Apr 2022 Chi phí nhà thầu phụ chiếm bao nhiêu phần trăm gói thầu? 142
- 21 Apr 2020 Bảo trì phần mềm là gì? Phân biệt các loại bảo trì 140
- 19 Aug 2020 Lift & Shift - Phương pháp tối ưu dịch chuyển hệ thống phần mềm qua đám mây 139
- 15 Sep 2020 Hai câu chuyện về dòng nước - Ao tù hay suối nguồn tươi trẻ? 127
- 05 Dec 2022 Hỏi 5 lần (5 WHYs) – Kỹ thuật "đào" tận gốc cốt lõi vấn đề 126
- 17 Feb 2018 Hệ luỵ khi sử dụng Web Hosting từ nhà cung cấp kém chất lượng 123
- 18 Mar 2018 Dịch vụ Hosting cho Website là gì? Các lời khuyên chọn Hosting tốt nhất 116
- 09 Feb 2021 Tầm nhìn là gì? Tí dụ minh họa cụ thể về tầm nhìn 112
- 25 Apr 2018 Bảo hộ bản quyền phần mềm dưới khía cạnh sở hữu trí tuệ như thế nào? 96
- 10 Aug 2020 Bạn có biết quy tắc thất bại nhanh: Fail early, fail often, fail cheap, but always fail forward 90
- 22 Jul 2020 Quản lý dự án phần mềm trong thực tế và câu chuyện thành công của InfoSys 86
- 23 Feb 2023 "Tinh Gọn" là gì? "Tinh Gọn" có thực sự chỉ là cách dịch từ "Lean"? 66
- 11 Mar 2025 Thiên hướng Hành động (Bias for Action) và Thiên hướng Quy trình (Bias for Process) tác động tiêu cực tới "đổi mới và sáng tạo" như thế nào? 49
- 02 Apr 2025 Anti-Hiring Là Gì? Tại sao các doanh nhân tinh gọn lại nói “KHÔNG” với tuyển dụng? 34
- 03 Jul 2025 20 "NGHỊCH LÝ" NHƯNG "THUẬN LÝ" TRONG CUỘC SỐNG 30
- 16 Apr 2025 Lãnh đạo linh hoạt: Hành động (Bias for Action) hay không hành động (Non-Action)? 25
Chúng ta thường nghe rằng tiến độ giao hàng (delivery) chậm lại, các ước tính (estimates) trở nên kém chính xác, và cả đội cứ loanh quanh với những vấn đề cũ mà không có kết thúc rõ ràng. Về cơ bản, điều này xảy ra do ma sát (friction) giữa bộ phận product và engineering.
Hãy để chúng tôi hướng dẫn bạn cách giảm thiểu ma sát này, trước khi nó dẫn đến thi công bị trì hoãn (stalled execution), trách nhiệm bị phân mảnh (fragmented ownership), và sự tin tưởng từ hai phía dần biến mất.
“Ma Sát” Giữa Product và Engineering Thực Sự Là Gì?
Hãy nhìn kỹ: có phải đà tiến triển (momentum) đột ngột giảm sút, có sự xung đột trong ưu tiên sprint, hoặc nhiều lần viết lại cùng xoay quanh một tính năng (feature ticket)? Nếu câu trả lời là có, thì ma sát giữa product và engineering đã xuất hiện.
Nhưng chính xác thì ma sát đại diện cho điều gì? Đó là khi cả hai bên cùng chuyển động, nhưng không theo cùng một nhịp. Ma sát xuất hiện qua các biểu hiện như:
- Mục tiêu liên tục thay đổi mà không có sự kết thúc rõ ràng
- Các quyết định đánh đổi (trade-offs) được đưa ra trong từng silo riêng biệt
- Năng lượng dự án bị hướng sai
- Không có từ vựng chung trong các cuộc họp
- Trách nhiệm bị rải rác tại các điểm quyết định
Hãy dừng lại và tự hỏi: nếu việc ra mắt tính năng giống như kéo co, nếu các ước tính được kèm theo sự bực bội, nếu các buổi retrospective cứ lặp đi lặp lại — thì vâng, ma sát là có thật và cần được giải quyết.
Vì Sao Có Ma Sát Giữa Product và Engineering?
- Product theo đuổi các kết quả như mức độ chấp nhận của người dùng (user adoption) hay tăng doanh thu đột biến, nên việc ra mắt nhanh thường bị xem là thành công—cho đến khi engineering phải đối mặt với hàng loạt lỗi phát sinh do bỏ sót các trường hợp biên (edge cases).
- Engineering thì bảo vệ sự ổn định hệ thống và khả năng mở rộng dài hạn (scalability), nhưng sự thận trọng đó thường bị xem là cản trở khi product muốn đẩy nhanh ra thị trường.
- Sprint bắt đầu với ranh giới rõ ràng, nhưng phản hồi giữa chừng lại khiến tính năng phát triển thêm mà mốc thời gian thì không đổi.
- Product thường cho rằng kỹ thuật sẽ “tự xử lý được,” nhưng nếu không có cuộc thảo luận rõ ràng về đánh đổi, engineering sẽ phải viết lại toàn bộ dưới áp lực.
- Các vòng phản hồi (feedback loops) diễn ra bị động, khiến product phản ứng với các yêu cầu mới, còn engineering phải vá code vốn không được thiết kế để xoay nhanh.
- Quyết định được phân tán cho quá nhiều vai trò, làm mờ trách nhiệm và khiến việc triển khai quan trọng bị đình trệ vì không có ai chịu trách nhiệm cuối cùng.
- Các khái niệm như “MVP” hay “sẵn sàng ra mắt” được hiểu khác nhau, khiến mỗi bên nghĩ rằng những thứ rất khác nhau đã “xong.”
Cách Giảm Ma Sát Giữa Product và Engineering
1. Rõ ràng về trách nhiệm giảm ma sát
Lãnh đạo cần tạo điều kiện, nhưng các team phải duy trì hàng ngày. Trách nhiệm phải rõ ràng từ cả hai phía. Nếu một bên phải gánh hết, sự mất cân bằng sẽ trở thành mầm mống cho sự bất mãn. Chia sẻ trách nhiệm (shared accountability) là cách ngăn điều đó.
2. Lập lộ trình (roadmap) cân bằng giữa tốc độ và khả thi
Product cần căn cứ vào tín hiệu từ khách hàng, còn engineering phải chuyển hóa nó thành giải pháp bền vững. Cả hai tiếng nói cần có mặt ngay từ khâu lên kế hoạch.
3. Tạo ra thói quen làm việc rõ ràng
Thiết lập ít nhất 2 cuộc họp định kỳ mỗi tuần giữa các trưởng nhóm product và engineering để:
- Xử lý các đánh đổi
- Xác nhận các thay đổi
- Ra quyết định
- Sau đó, công bố hành động cụ thể, tránh hiểu lầm ngầm.
4. Dùng chung công cụ
Dùng một bảng dự án (project board) chung để:
- Theo dõi blocker
- Kiểm tra ticket
- Ghi lại phản hồi
Các công cụ như Figma, Miro, hoặc Confluence nên được dùng chung. Thậm chí ảnh chụp bảng trắng từ cuộc họp cũng có thể lưu lại ý quan trọng.
5. Thống nhất ngôn ngữ hợp tác
Thay vì cập nhật mơ hồ, hãy trình bày rõ ràng:
- Product cần giải thích tại sao người dùng cần điều đó.
- Engineering cần giải thích như thế nào về giới hạn kỹ thuật.
Tất cả phải dựa trên dữ liệu, không phải cảm tính.
6. Cùng theo dõi kết quả
Dùng chung các OKR, cùng theo dõi:
- Thời gian hoàn thành (cycle time)
- Tỷ lệ tính năng được dùng (feature adoption)
- Tỷ lệ lỗi (defect ratios)
Điều này giúp định nghĩa thành công chung và tránh kỳ vọng lệch lạc.
7. Thử hoán đổi vai trò ngắn hạn
Cho product manager tham gia các buổi debug, và cho engineer tham gia gọi điện với khách hàng. Trải nghiệm thực tế sẽ tạo ra sự đồng cảm hơn bất kỳ slide nào.
“Căng Thẳng Lành Mạnh” Có Phải Chỉ Là Huyền Thoại?
Nhiều công ty công nghệ hiện đại gọi đó là “healthy tension” như một cách hợp lý hóa. Họ cho rằng nó giữ các nhóm sắc bén và cân bằng giữa nhu cầu kinh doanh và độ sâu kỹ thuật.
Nhưng trong thực tế, “căng thẳng” này có thực sự lành mạnh, hay đang bào mòn dần sự đồng thuận giữa product và engineering?
- Hubert Palan (CEO của Productboard) từng nói trên podcast Engineering Leadership rằng: kỹ sư tốt nhất là người mang góc nhìn kinh doanh vào cuộc thảo luận kỹ thuật. Khi kỹ thuật gắn liền với chiến lược cạnh tranh, sự “căng thẳng” không biến mất mà trở thành chia sẻ quyền sở hữu.
- Vinay Patel (OIC Advisors) thì phản biện rằng: “healthy tension” chỉ là huyền thoại khi vòng phản hồi bị ngắt và phần thưởng lệch nhau. Căng thẳng ban đầu dễ dàng trượt thành quyết định riêng lẻ, giao hàng sai lệch và đổ lỗi lẫn nhau.
- Thoughtworks’ scale-up framework (2023) cũng cảnh báo: nếu không có mô hình cộng tác cụ thể, “căng thẳng” chỉ là một cách lãng mạn hóa sự hỗn loạn.
Tóm lại: “Healthy tension” chỉ thực sự lành mạnh khi có đủ 3 điều kiện:
- Ngôn ngữ và mục tiêu chung định hướng các quyết định
- Ranh giới trách nhiệm rõ ràng, không đẩy bóng qua lại
- Đồng bộ chiến lược thường xuyên, tránh làm việc ở hai “đường ray” song song
Nếu không, căng thẳng sẽ hóa thành rạn nứt văn hóa, tạo ra silo đội ngũ và phá vỡ tốc độ, tinh thần, lẫn giá trị sản phẩm.
Kết Luận
Ma sát luôn xuất hiện khi product thúc đẩy kết quả, còn engineering bảo vệ tính khả thi. Sự tiến bộ chỉ diễn ra suôn sẻ nếu cả hai bên rõ ràng, đồng thuận và có trách nhiệm chung. Nếu không, niềm tin phai nhạt, đà phát triển sẽ gãy gánh.
Khám phá thêm các chủ đề sau
Đọc thêm: Hướng dẫn hợp tác viết bài (guest blogging)
Các chủ đề được quan tâm nhiều nhất
CHIA SẺ BÀI VIẾT
