Sự Cho và Nhận: 6 Cách Kỹ Sư và Quản Lý Sản Phẩm Có Thể Hỗ Trợ Lẫn Nhau

Hãy quên đi tất cả những gì bạn đã nghe về sự cạnh tranh giữa kỹ sư và quản lý sản phẩm - đó là một mô hình cần được chấm dứt. Thế giới công nghệ ngày nay phát triển quá nhanh, và con đường duy nhất phía trước là sự hợp tác lấy và cho. Bài viết này tiết lộ sáu cách mà kỹ sư và PM có thể tránh va chạm và tập trung vào sứ mệnh.

1. PMs: Chia sẻ Bức tranh lớn; Kỹ sư: Chia sẻ Ràng buộc Kỹ thuật

Cho: PM có thể giúp kỹ sư bằng cách cung cấp một sự hiểu biết rõ ràng về mục tiêu kinh doanh và nhu cầu của khách hàng đằng sau một dự án. Điều này giúp kỹ sư hiểu tại sao một tính năng cụ thể hoặc thời hạn lại quan trọng. Chia sẻ ngữ cảnh sớm cho phép kỹ sư điều chỉnh công việc của họ với các mục tiêu rộng lớn hơn.

Lấy: Ngược lại, kỹ sư nên truyền đạt một cách mở cửa về các ràng buộc và phức tạp kỹ thuật liên quan đến một dự án. Nếu một tính năng dường như nhỏ sẽ yêu cầu thay đổi lớn ở phía backend, giải thích điều này ngay từ đầu giúp PM đưa ra quyết định tốt hơn về ưu tiên và lịch trình.

Ví dụ: Một PM giải thích rằng một tính năng là chìa khóa để giành được một khách hàng lớn hoặc đối mặt với một mối đe dọa cạnh tranh, điều này giúp kỹ sư ưu tiên nó. Tương tự, khi một kỹ sư chia sẻ rằng một tính năng sẽ mất thêm thời gian do vấn đề về khả năng mở rộng, PM có thể điều chỉnh kỳ vọng.

Tài nguyên

Dành cho PMs: "Quản lý Sản phẩm trong Thực hành" của Matt LeMay – Một hướng dẫn toàn diện để hiểu và giao tiếp mục tiêu sản phẩm.

Where the World Designs Electronics

Break down silos and enhance collaboration across all aspects of electronics development

Find Out More

Dành cho Kỹ sư: "Người Lập trình Thực dụng" của Andrew Hunt và David Thomas – Một cuốn sách nhấn mạnh về giao tiếp và quyết định kỹ thuật trong quá trình phát triển.

2. PMs: Tránh Quản lý Chi tiết; Kỹ sư: Tham gia vào Quá trình Ý tưởng

Cho: Quản lý sản phẩm nên tránh mong muốn kiểm soát mọi chi tiết của việc thực hiện sản phẩm. Tin tưởng kỹ sư xử lý các khía cạnh kỹ thuật và cho họ không gian để giải quyết vấn đề theo cách của họ. Quản lý quá mức có thể làm giảm sự sáng tạo và dẫn đến sự không tham gia.

Nhận: Kỹ sư nên chủ động trong quá trình đưa ra ý tưởng. Đừng chờ được yêu cầu—đề xuất ý kiến và ý tưởng về cách cải thiện sản phẩm. Nhiều kỹ sư có cái nhìn quý giá có thể nâng cao chức năng, hiệu suất, hoặc thiết kế của sản phẩm. Chủ động cho thấy bạn quan tâm đến thành công của sản phẩm không chỉ là viết mã.

Ví dụ: Một PM đề cập đến mục tiêu kinh doanh và yêu cầu đầu vào thay vì nói với kỹ sư cách triển khai tính năng. Trong khi đó, kỹ sư chủ động đề xuất giải pháp kỹ thuật và đóng góp vào các phiên brainstorm.

Tài nguyên

Design Better, Together

Experience flexible controls for team management and project visibility.

Explore Solutions

Dành cho PMs: "Empowered" của Marty Cagan và Chris Jones – Cuốn sách này khám phá cách trao quyền cho các nhóm để họ tự chủ trong việc thực hiện sản phẩm.

Dành cho Kỹ sư: "Creative Confidence" của Tom Kelley và David Kelley – Một nguồn lực tuyệt vời cho các kỹ sư muốn đóng góp sáng tạo vào ý tưởng sản phẩm.

3. PMs: Hãy Tặng Khen Ngợi Rộng Rãi; Kỹ sư: Hỗ trợ Quyết định Sản phẩm Một cách Công khai

Cho: Một phàn nàn phổ biến từ các kỹ sư là PMs thường nhận công cho thành công của dự án vì họ thường là người trình bày nó với ban lãnh đạo. PMs có thể giúp xây dựng niềm tin bằng cách chia sẻ công lao với đội ngũ kỹ sư và tạo cơ hội cho kỹ sư trình bày công việc của họ.

Nhận: Ngược lại, các kỹ sư có thể hỗ trợ quyết định của PMs khi trình bày với các đội khác hoặc các bên liên quan. Ngay cả khi bạn không đồng ý với một số khía cạnh, việc ủng hộ công khai các quyết định sản phẩm thể hiện sự đoàn kết và nuôi dưỡng văn hóa hợp tác.

Ví dụ: Sau một lần ra mắt thành công, một PM mời các kỹ sư trình bày về những thành tựu kỹ thuật. Ngược lại, các kỹ sư công khai hỗ trợ quyết định sản phẩm của PMs trong các cuộc họp với các bên liên quan.

Tài nguyên

Dành cho PMs: "Radical Candor" của Kim Scott – Một cuốn sách cung cấp cái nhìn sâu sắc về việc xây dựng mối quan hệ mạnh mẽ và tặng khen ngợi khi cần thiết.

Dành cho Kỹ sư: "Cuộc trò chuyện quan trọng" của Al Switzler, Joseph Grenny và Ron McMillan – Học cách thực hiện các cuộc trò chuyện hiệu quả, hỗ trợ với đồng nghiệp và lãnh đạo.

4. PMs: Hãy mở cửa với các cuộc thảo luận về Nợ kỹ thuật; Kỹ sư: Hãy thực tế về Khung thời gian

Cho: PMs có thể giúp kỹ sư bằng cách sẵn lòng thảo luận về nợ kỹ thuật và bảo trì. Việc ưu tiên các tính năng mới có thể hấp dẫn, nhưng việc bỏ qua nền tảng kỹ thuật có thể dẫn đến những vấn đề lớn hơn. Dành thời gian cho việc tái cấu trúc mã cần thiết hoặc cải thiện cơ sở hạ tầng cho thấy sự hiểu biết về sức khỏe sản phẩm lâu dài.

Nhận: Kỹ sư cũng nên thực tế về thời gian mọi thứ sẽ mất. Nếu bạn đưa ra ước lượng quá thận trọng, PMs có thể cảm thấy bị áp lực để đẩy lùi khung thời gian. Cung cấp khung thời gian chính xác và thông báo sớm về sự chậm trễ giúp PMs lên kế hoạch hiệu quả.

Ví dụ: Kỹ sư truyền đạt rủi ro của nợ kỹ thuật và PMs dành thời gian cho việc tái cấu trúc, trong khi kỹ sư cung cấp ước lượng thời gian thực tế để quản lý kỳ vọng.

Tài nguyên

Dành cho PMs: "Nợ Kỹ thuật 101" của ThoughtWorks – Một bài giới thiệu tuyệt vời về việc hiểu nợ kỹ thuật và cách quản lý nó.

Dành cho Kỹ sư: "Dự án Phoenix" của Gene Kim, Kevin Behr và George Spafford – Một tiểu thuyết minh họa tác động của việc cân bằng giữa nợ kỹ thuật và ưu tiên kinh doanh.

5. PMs: Kết nối Kỹ sư với Phản hồi từ Khách hàng; Kỹ sư: Tôn trọng Ưu tiên Kinh doanh

Cho: PMs có thể giúp kỹ sư bằng cách chia sẻ trực tiếp phản hồi từ khách hàng. Kỹ sư thường cảm thấy gắn bó hơn với sản phẩm khi họ nghe về cách khách hàng sử dụng nó, những vấn đề họ đang đối mặt, và những tính năng họ yêu thích.

Nhận: Đổi lại, kỹ sư nên tôn trọng các ưu tiên kinh doanh mà PMs đang cân nhắc. Mặc dù việc ra mắt một tính năng không hoàn hảo có thể gây khó chịu, nhưng đôi khi việc đó có thể rất quan trọng để duy trì tính cạnh tranh.

Ví dụ: Một PM mời kỹ sư tham gia vào các phiên phản hồi từ khách hàng, và kỹ sư hiểu được tầm quan trọng của việc ra mắt một số tính năng nhất định, ngay cả khi họ cảm thấy một số khía cạnh cần được hoàn thiện hơn.

Tài nguyên:

Dành cho PMs: "Sách hướng dẫn Sản phẩm Lean" của Dan Olsen – Một hướng dẫn thực tế để hiểu phản hồi từ khách hàng và chuyển đổi nó thành các chiến lược phát triển sản phẩm có thể thực hiện được.

Dành cho Kỹ sư: "The Mythical Man-Month" của Frederick P. Brooks – Cuốn sách kinh điển này đề cập đến những thách thức về thời gian phát triển phần mềm và kỳ vọng kinh doanh.

6. PMs: Đặt Mục Tiêu Rõ Ràng, Khả Thi; Kỹ sư: Hướng Tới Giải Pháp

Đưa ra: Một trong những điều quý giá nhất mà một PM có thể làm cho kỹ sư là đặt ra mục tiêu rõ ràng và khả thi. Yêu cầu mơ hồ hoặc ưu tiên thay đổi liên tục có thể gây ra sự bực bội. Bằng cách xác định rõ ràng thành công là gì và tuân thủ những tham số đó, PMs có thể giúp kỹ sư tập trung và làm việc hiệu quả.

Nhận: Kỹ sư nên tiếp cận vấn đề với tư duy hướng tới giải pháp. Thay vì liệt kê lý do tại sao một việc không thể được thực hiện, hãy đề xuất các phương án thay thế hoặc giải pháp tạm thời. Mang tính xây dựng giúp PM và nhóm tiến lên mà không bị mắc kẹt bởi những trở ngại kỹ thuật.

Ví dụ: Một PM cung cấp các chỉ số thành công rõ ràng cho dự án, trong khi kỹ sư đưa ra giải pháp thực tế khi gặp ràng buộc kỹ thuật.

Tài nguyên

Dành cho PMs: "Measure What Matters" của John Doerr – Học cách đặt mục tiêu rõ ràng và kết quả khóa đo lường được (OKRs) phù hợp với nỗ lực của nhóm bạn.

Dành cho Kỹ sư: "Thiết kế Ứng dụng Dữ liệu Lớn" của Martin Kleppmann – Một nguồn tài nguyên kỹ thuật giúp kỹ sư suy nghĩ về việc xây dựng các hệ thống có khả năng mở rộng, đáng tin cậy trong khi cân nhắc yêu cầu sản phẩm.

Ví dụ Thực tế: Thuật toán 5 Bước của Elon Musk để Cắt giảm Bộ máy Quản lý Nội bộ

Elon Musk nổi tiếng với phong cách quản lý táo bạo tại Tesla và SpaceX. Trong nỗ lực cắt giảm bộ máy quản lý nội bộ, Musk đã phát triển một thuật toán năm bước, được chi tiết trong cuốn tiểu sử gần đây của ông bởi Walter Isaacson, cung cấp một khung công tác có thể thực hiện để tinh gọn quy trình.

1. Đặt câu hỏi về Mọi Yêu cầu: Musk khuyên nên thách thức mọi yêu cầu, kể cả khi nó đến từ một "người thông minh." Gắn tên cho mỗi yêu cầu, và liên tục hỏi liệu nó có thực sự cần thiết không. Nếu không, hãy loại bỏ nó.
2. Xóa bất kỳ Phần nào của Quy trình bạn có thể: Musk nhấn mạnh rằng sự đơn giản là chìa khóa. Xóa bỏ các bước không cần thiết—đi xa hơn bạn nghĩ bạn nên làm. Nếu bạn không cần phải thêm lại ít nhất 10%, bạn chưa xóa đủ.
3. Đơn giản hóa và Tối ưu hóa: Chỉ sau khi loại bỏ các bước không cần thiết, bạn mới nên đơn giản hóa và tối ưu hóa những gì còn lại. Tránh sai lầm khi tinh gọn các quy trình không nên tồn tại ngay từ đầu.
4. Tăng Tốc Chu Kỳ Thời Gian: Một khi quy trình đã được tối ưu, hãy tập trung vào việc tăng tốc độ thực hiện. Musk cảnh báo về việc lãng phí thời gian tăng tốc các phần của quy trình mà thực ra là thừa thãi hoặc không cần thiết.
5. Tự Động Hóa Cuối Cùng: Bước cuối cùng của Musk là tự động hóa, nhưng chỉ sau khi đã kỹ lưỡng xem xét, loại bỏ, và đơn giản hóa quy trình. Tự động hóa quá sớm có thể dẫn đến sự phức tạp không cần thiết.

Phương pháp của Musk có thể là một ví dụ mạnh mẽ về cách các PM và kỹ sư có thể cùng nhau thách thức những bất cập, tối ưu hóa quy trình làm việc, và tối đa hóa năng suất. Bằng cách liên tục đặt câu hỏi về các giả định và đơn giản hóa quy trình, các đội phát triển sản phẩm có thể giảm đáng kể các trở ngại nội bộ và tăng cường sự hợp tác.

Ít Stress, Nhiều Đam Mê

Như Simon Sinek đã khôn ngoan nói, "Làm việc chăm chỉ cho điều chúng ta không quan tâm gọi là stress; làm việc chăm chỉ cho điều chúng ta yêu thích gọi là đam mê." Điều này cũng áp dụng cho mối quan hệ giữa kỹ sư và PM. Khi họ cùng nhau làm việc với sự tôn trọng và đam mê lẫn nhau, những điều tuyệt vời sẽ xảy ra. Hãy để tinh thần cho và nhận này thúc đẩy sản phẩm tiếp theo của đội nhóm bạn.