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 2524 - 04 Sep 2021 Tào lao là gì? Các bí quyết để tránh tào lao trong giao tiếp 1787
- 28 Apr 2023 Mô hình Why, How, What là gì? 1245
- 04 Aug 2021 Đừng sợ đi chậm, chỉ sợ đứng yên 1179
- 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 1112
- 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) 986
- 01 Jul 2023 Phương pháp Shuhari - Làm sao học ít hiểu nhiều? 921
- 01 Aug 2022 "Sponsored Content" là gì? Khác nhau giữa Sponsored Content và Native Advertising? 774
- 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 687
- 01 Feb 2022 Thách thức với doanh nghiệp chuyển đổi số trong thời đại VUCA 676
- 04 Jan 2023 Phát triển phần mềm linh hoạt theo mô hình Big Bang 667
- 15 Aug 2024 Kỹ năng thuyết trình với kỹ năng ABC (Accuracy, Brevity, Clarity) 642
- 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 636
- 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 631
- 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 621
- 15 Apr 2020 Phần mềm BPM là gì? So sánh với ERP và các phần mềm Workflows 535
- 01 Mar 2021 Ý nghĩa và bài học rút ra từ truyện thầy bói xem voi 525
- 01 Apr 2023 Bí quyết đàm phán tạo ra giá trị từ câu chuyện Chia Cam 500
- 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 495
- 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ả 492
- 03 Mar 2020 Giả định (Assumption ) là gì? Tại sao giả định rất quan trọng với dự án? 483
- 09 Dec 2021 Sơ đồ chuỗi giá trị (Value Stream Mapping - VSM) là gì? 469
- 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 466
- 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) 465
- 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ố? 452
- 03 May 2022 Mô hình Hybrid Agile là gì? 451
- 03 Feb 2020 Sản phẩm OEM và ODM là gì? 446
- 14 Jun 2021 8 loại lãng phí doanh nghiệp phải tìm cách loại bỏ 415
- 11 Sep 2024 Mindset, skillset, toolset là gì? 403
- 14 Apr 2019 Product Backlog là gì? Các đặc điểm cơ bản của một Product Backlog 400
- 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) 396
- 11 Oct 2024 "Kham Nhẫn" Trong Kinh Doanh: Sức Mạnh Của Sự Kiên Nhẫn 395
- 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) 394
- 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 393
- 01 Aug 2019 5 nguyên lý khởi nghiệp tinh gọn rút ra từ thực tế 393
- 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 391
- 07 Aug 2019 Câu chuyện thanh gỗ ngắn và bài học kinh doanh cho Doanh nghiệp 385
- 23 Jun 2024 Người trí tuệ không tranh cãi ĐÚNG/SAI 379
- 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)? 378
- 04 Jan 2023 Đánh giá nhân sự theo chuẩn người Nhật 372
- 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 361
- 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 358
- 20 Jul 2021 Quản lý và đánh giá công việc theo quy trình TIGO SmartWork 351
- 02 Aug 2021 Product Owner làm gì trước khi bắt đầu sprint đầu tiên của dự án (Sprint Zero)? 319
- 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)? 297
- 22 Jan 2025 Khi ngư dân không thể ra khơi, họ sửa lưới 294
- 24 Mar 2019 Scrum giống như bà mẹ chồng, giúp bạn nhìn ra các lỗi sai 275
- 11 Sep 2022 Sức mạnh của lời khen 261
- 21 Apr 2020 Bảo trì phần mềm là gì? Phân biệt các loại bảo trì 242
- 07 Jan 2025 Phân biệt Proxy, HMA và VPN 242
- 04 Sep 2023 Giải mã nhóm tính cách (ISTP - Nhà kỹ thuật) 234
- 18 Mar 2018 Dịch vụ Hosting cho Website là gì? Các lời khuyên chọn Hosting tốt nhất 232
- 08 Jan 2022 Yêu cầu thay đổi (Change Request) là gì? Làm thế nào để kiểm soát Change Request? 230
- 17 Aug 2020 Mục tiêu dự án là gì? Làm thế nào để xác định mục tiêu? 216
- 01 Sep 2020 Co-founder là gì? Vai trò của các Co-Founder khi lập nghiệp. 216
- 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ì? 210
- 11 Sep 2022 Từ truyện “Thầy bói xem voi” tới quản trị bằng Tư Duy Hệ Thống 210
- 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? 206
- 10 May 2021 Phát triển Phần mềm Tinh gọn (Lean Software Development) 205
- 08 Mar 2022 Mô hình nguồn mở hoạt động ra sao? 191
- 08 Feb 2021 Quy trình nâng cấp phần mềm quản trị doanh nghiệp TIGO ERP 185
- 15 Sep 2020 Hai câu chuyện về dòng nước - Ao tù hay suối nguồn tươi trẻ? 163
- 01 May 2023 [Tư vấn CNTT] Quản lý ngân sách CNTT cho doanh nghiệp 162
- 08 Mar 2020 Vì sao doanh nghiệp cần phải tạo Web bán hàng? 160
- 14 Dec 2022 Phương pháp kiểm tra Fagan Inspection là gì? 160
- 05 Dec 2022 Hỏi 5 lần (5 WHYs) – Kỹ thuật "đào" tận gốc cốt lõi vấn đề 152
- 01 Apr 2022 Chi phí nhà thầu phụ chiếm bao nhiêu phần trăm gói thầu? 151
- 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 147
- 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? 140
- 17 Feb 2018 Hệ luỵ khi sử dụng Web Hosting từ nhà cung cấp kém chất lượng 138
- 09 Feb 2021 Tầm nhìn là gì? Tí dụ minh họa cụ thể về tầm nhìn 123
- 23 Feb 2023 "Tinh Gọn" là gì? "Tinh Gọn" có thực sự chỉ là cách dịch từ "Lean"? 105
- 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 102
- 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 93
- 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? 55
- 03 Jul 2025 20 "NGHỊCH LÝ" NHƯNG "THUẬN LÝ" TRONG CUỘC SỐNG 41
- 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? 40
- 08 Sep 2025 Tâm Lý Phản Kháng (Reactance): Vì Sao Càng Cấm, Người Ta Càng Muốn Làm? 38
- 19 Sep 2025 Agile vs. Ego: Làm Gì Khi Một Thành Viên Trong Nhóm Nổi Loạn 34
- 16 Apr 2025 Lãnh đạo linh hoạt: Hành động (Bias for Action) hay không hành động (Non-Action)? 34
- 15 Aug 2025 Dự án phần mềm bị trì hoãn và vấn đề "akrasia" 29
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
19082021092841_thumb.png "Tại sao các dự án phần mềm sản xuất trong nước chậm nghiệm thu, ngay cả khi đã hoàn thành đúng tiến độ, thậm chí là vượt xa mong đợi? Bài viết sau đây sẽ cho chúng ta câu trả lời.")
Đọ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
Link copied!
Mới cập nhật