Ma sát giữa product và kỹ thuật khiến tiến độ chậm, teamwork kém hiệu quả, cần cải thiện giao tiếp và trách nhiệm chung.

Khi Product và Engineering "Lệch Pha": Cách Giảm Ma Sát Trước Khi Mọi Thứ Bị Đóng Băng

Published on: August 01, 2025
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 2260
04 Sep 2021 Tào lao là gì? Các bí quyết để tránh tào lao trong giao tiếp 1430
04 Aug 2021 Đừng sợ đi chậm, chỉ sợ đứng yên 924
28 Apr 2023 Mô hình Why, How, What là gì? 901
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 774
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) 768
01 Jul 2023 Phương pháp Shuhari - Làm sao học ít hiểu nhiều? 698
01 Aug 2022 "Sponsored Content" là gì? Khác nhau giữa Sponsored Content và Native Advertising? 580
04 Jan 2023 Phát triển phần mềm linh hoạt theo mô hình Big Bang 566
15 Aug 2024 Kỹ năng thuyết trình với kỹ năng ABC (Accuracy, Brevity, Clarity) 563
01 Feb 2022 Thách thức với doanh nghiệp chuyển đổi số trong thời đại VUCA 556
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 495
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 490
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 459
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 423
03 Mar 2020 Giả định (Assumption ) là gì? Tại sao giả định rất quan trọng với dự án? 412
03 May 2022 Mô hình Hybrid Agile là gì? 402
09 Dec 2021 Sơ đồ chuỗi giá trị (Value Stream Mapping - VSM) là gì? 387
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) 379
14 Jun 2021 8 loại lãng phí doanh nghiệp phải tìm cách loại bỏ 378
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ả 376
03 Feb 2020 Sản phẩm OEM và ODM là gì? 365
15 Apr 2020 Phần mềm BPM là gì? So sánh với ERP và các phần mềm Workflows 364
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 360
01 Aug 2019 5 nguyên lý khởi nghiệp tinh gọn rút ra từ thực tế 351
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ố? 338
01 Apr 2023 Bí quyết đàm phán tạo ra giá trị từ câu chuyện Chia Cam 338
07 Aug 2019 Câu chuyện thanh gỗ ngắn và bài học kinh doanh cho Doanh nghiệp 336
11 Oct 2024 "Kham Nhẫn" Trong Kinh Doanh: Sức Mạnh Của Sự Kiên Nhẫn 329
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 319
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 316
20 Jul 2021 Quản lý và đánh giá công việc theo quy trình TIGO SmartWork 307
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 301
02 Aug 2021 Product Owner làm gì trước khi bắt đầu sprint đầu tiên của dự án (Sprint Zero)? 299
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) 292
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) 281
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)? 280
11 Sep 2024 Mindset, skillset, toolset là gì? 271
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 268
04 Jan 2023 Đánh giá nhân sự theo chuẩn người Nhật 254
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)? 249
11 Sep 2022 Sức mạnh của lời khen 236
22 Jan 2025 Khi ngư dân không thể ra khơi, họ sửa lưới 219
02 Mar 2018 Tại sao ví Scrum như dòng điện xoay chiều? 218
14 Apr 2019 Product Backlog là gì? Các đặc điểm cơ bản của một Product Backlog 214
04 Sep 2023 Giải mã nhóm tính cách (ISTP - Nhà kỹ thuật) 203
17 Aug 2020 Mục tiêu dự án là gì? Làm thế nào để xác định mục tiêu? 197
23 Jun 2024 Người trí tuệ không tranh cãi ĐÚNG/SAI 191
08 Jan 2022 Yêu cầu thay đổi (Change Request) là gì? Làm thế nào để kiểm soát Change Request? 183
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 182
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? 180
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ì? 179
11 Sep 2022 Từ truyện “Thầy bói xem voi” tới quản trị bằng Tư Duy Hệ Thống 171
10 May 2021 Phát triển Phần mềm Tinh gọn (Lean Software Development) 169
07 Jan 2025 Phân biệt Proxy, HMA và VPN 163
08 Mar 2022 Mô hình nguồn mở hoạt động ra sao? 163
08 Feb 2021 Quy trình nâng cấp phần mềm quản trị doanh nghiệp TIGO ERP 158
14 Dec 2022 Phương pháp kiểm tra Fagan Inspection là gì? 150
08 Mar 2020 Vì sao doanh nghiệp cần phải tạo Web bán hàng? 148
01 Sep 2020 Co-founder là gì? Vai trò của các Co-Founder khi lập nghiệp. 148
24 Mar 2019 Scrum giống như bà mẹ chồng, giúp bạn nhìn ra các lỗi sai 147
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? 139
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
17 Feb 2018 Hệ luỵ khi sử dụng Web Hosting từ nhà cung cấp kém chất lượng 123
21 Apr 2020 Bảo trì phần mềm là gì? Phân biệt các loại bảo trì 123
05 Dec 2022 Hỏi 5 lần (5 WHYs) – Kỹ thuật "đào" tận gốc cốt lõi vấn đề 120
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
15 Sep 2020 Hai câu chuyện về dòng nước - Ao tù hay suối nguồn tươi trẻ? 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
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 85
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 74
23 Feb 2023 "Tinh Gọn" là gì? "Tinh Gọn" có thực sự chỉ là cách dịch từ "Lean"? 49
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? 33
03 Jul 2025 20 "NGHỊCH LÝ" NHƯNG "THUẬN LÝ" TRONG CUỘC SỐNG 30
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? 25
16 Apr 2025 Lãnh đạo linh hoạt: Hành động (Bias for Action) hay không hành động (Non-Action)? 20

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.

A A A A

[{"displaySettingInfo":"[{\"isFullLayout\":false,\"layoutWidthRatio\":\"\",\"showBlogMetadata\":true,\"showAds\":true,\"showQuickNoticeBar\":true,\"includeSuggestedAndRelatedBlogs\":true,\"enableLazyLoad\":true,\"quoteStyle\":\"1\",\"bigHeadingFontStyle\":\"1\",\"postPictureFrameStyle\":\"1\",\"isFaqLayout\":false,\"isIncludedCaption\":false,\"faqLayoutTheme\":\"1\",\"isSliderLayout\":false}]"},{"articleSourceInfo":"[{\"sourceName\":\"How to Reduce Friction Between Product and Engineering Teams?\",\"sourceValue\":\"https://en.tigosolutions.com/how-to-reduce-friction-between-product-and-engineering-teams\"}]"},{"privacyInfo":"[{\"isOutsideVietnam\":false}]"},{"tocInfo":"[{\"isEnabledTOC\":true,\"isAutoNumbering\":false,\"isShowKeyHeadingWithIcon\":false}]"},{"bannerInfo":"[{\"isBannerBrightnessAdjust\":false,\"bannerBrightnessLevel\":\"\",\"isRandomBannerDisplay\":true}]"},{"termSettingInfo":"[{\"showTermsOnPage\":true,\"displaySequentialTermNumber\":true}]"}]

Nguồn

{content}