Sản phẩm ngày càng nhiều, quản lý sản phẩm ngày càng ít đi
(kitemaker.co)- Tranh luận về việc nên có bao nhiêu PM trong đội ngũ sản phẩm đã trở nên sôi nổi hơn sau đợt tái cơ cấu tổ chức quản lý sản phẩm của Airbnb và các trường hợp startup tăng trưởng mà không cần PM
- Khi số lượng PM tăng lên, có thể hình thành một cấu trúc mà thời gian bị dành cho quản lý dự án và cập nhật lộ trình nhiều hơn là tạo ra kết quả kinh doanh cho sản phẩm
- Trong các đội có designer và engineer giàu kinh nghiệm, công việc PM không nhất thiết phải là vai trò toàn thời gian, và mô hình 1 PM cho mỗi đội cũng cần được xem xét lại tùy bối cảnh
- Thời điểm tuyển PM đầu tiên là khi nhà sáng lập khó còn có thể tham gia vào mọi quyết định sản phẩm quan trọng, thường là ở quy mô 50–100 người và khoảng 3–5 đội sản phẩm
- Chỉ tăng số lượng PM không tự động biến tổ chức thành tổ chức lấy sản phẩm làm trung tâm, mà ngược lại còn có thể làm suy yếu trách nhiệm với sản phẩm mà designer và engineer nên có
Cấu trúc giảm PM và mở rộng trách nhiệm sản phẩm
- Thảo luận về số lượng PM cần thiết trở nên sôi động hơn sau các bài viết nói về đợt tái cơ cấu tổ chức quản lý sản phẩm của Airbnb và những startup tăng trưởng mà không cần PM
- Ở nhiều công ty, PM thường dành cả ngày cho các công việc như quản lý dự án và cập nhật lộ trình, thay vì tối ưu sản phẩm cho phù hợp với mục tiêu kinh doanh
- Nói chung, số PM nên ít hơn số đội sản phẩm, và mô hình mỗi đội có 1 PM cần được xem xét lại tùy vào sản phẩm và tình hình đội ngũ
- Nếu công việc sản phẩm nhiều và đội còn non kinh nghiệm, có thể cần một PM chuyên trách cho từng đội
- Với các đội có engineer và designer nhiều kinh nghiệm, vai trò PM có thể không cần là toàn thời gian, hoặc thậm chí không nên là toàn thời gian
- Thời điểm phù hợp để startup tuyển PM đầu tiên là khi nhà sáng lập không còn dễ dàng tham gia vào mọi quyết định sản phẩm quan trọng
- Mốc tham khảo thường là khi tổ chức có 50–100 người và có 3–5 đội sản phẩm
- Chiến lược sản phẩm tổng thể cần phải đã rõ ràng, và PM nên tham gia vào định hướng và ra quyết định ở cấp độ thấp hơn dựa trên chiến lược đó
- PM đầu tiên phù hợp hơn nên là senior PM thay vì junior PM hay CPO
- Ứng viên đó có thể đảm nhận vai trò CPO khi tổ chức phát triển, nhưng trên thực tế nhà sáng lập vẫn cần tiếp tục đóng vai trò người chịu trách nhiệm sản phẩm
Cách thực hành để xây dựng đội ngũ lấy sản phẩm làm trung tâm
- Trách nhiệm sản phẩm không nên dồn vào một mình PM; thiết kế và kỹ thuật cũng phải trực tiếp hiểu người dùng và bối cảnh sản phẩm
- Designer và engineer nên tích cực tham gia định hình sản phẩm và dẫn dắt các thảo luận chi tiết về sản phẩm
- PM không nên trở thành người duy nhất làm UX, wireframe, theo dõi tiến độ, điều phối standup hay tự mình viết PRD/đặc tả
- Trọng tâm của PM là diễn đạt tầm nhìn sản phẩm, chọn đúng vấn đề cần giải quyết, giữ đúng hướng sản phẩm và căn chỉnh với yêu cầu kinh doanh
- Bài “Guide to product development” của Michael Seibel được liên hệ như một ví dụ triển khai cách làm này tại Social Cam
- Cả đội cần chủ động chia sẻ bối cảnh và cơ sở đưa ra phán đoán
- Thiết kế và kỹ thuật cũng phải có thể tiếp cận phản hồi người dùng
- Giải quyết vấn đề không nên xoay quanh PM, mà phải là sự cộng tác giữa sản phẩm, thiết kế và kỹ thuật
- Có thể tóm tắt các cách thực hành để xây dựng một đội ngũ định hướng sản phẩm thành bốn điểm
- Bắt đầu cùng nhau: trước khi viết ticket hay đặc tả, trước khi chốt giải pháp, thiết kế·kỹ thuật·sản phẩm/nhà sáng lập cùng thảo luận để thống nhất cách triển khai và kế hoạch
- Đưa mọi người tiếp xúc với người dùng: trực tiếp tham gia nghiên cứu người dùng và kiểm thử tính khả dụng, hoặc dùng livestream video hay công cụ như Lookback để quan sát cách người dùng sử dụng sản phẩm
- Cẩn trọng với cách quản lý đội: nếu đo hiệu quả bằng số ticket đóng hay story point, đội sẽ vận hành để xử lý ticket thay vì tạo ra sản phẩm tốt
- Không dùng công cụ PM: nếu phản hồi người dùng, insight, dữ liệu, đặc tả và lộ trình bị nhốt trong các công cụ PM riêng biệt, cả đội sẽ khó tiếp cận được bối cảnh sản phẩm đầy đủ
- Phát triển sản phẩm về bản chất là việc khó dự đoán, và điều quan trọng hơn bản thân việc phát hành là phát hành đúng thứ có tác động đến doanh nghiệp
- Ở các công ty lớn lấy sản phẩm làm trung tâm, PM rất quan trọng, nhưng số PM cần thiết thường dễ bị đánh giá quá cao, và việc tăng số lượng PM không đồng nghĩa với việc mức độ tập trung vào sản phẩm cũng tăng lên
1 bình luận
Ý kiến trên Hacker News
Với tư cách là quản lý kỹ thuật hoặc trưởng một tổ chức chức năng, tôi đã làm việc với các product manager khá lâu, và cũng từng tạm thời đóng vai trò PM cho sản phẩm nội bộ tại một công ty công nghệ tầm trung.
Tôi cho rằng quản lý sản phẩm thuộc nhóm những mảng quan trọng nhất mà một công ty làm. Nhưng công việc này thật sự khó, và PM càng thiếu năng lực thì càng dễ rời xa phần cốt lõi đó, rồi trôi sang vi quản lý đội ngũ kỹ thuật dưới danh nghĩa “dẫn dắt”, hoặc sa vào chính trị nội bộ.
Ở những tổ chức mà kỹ thuật và sản phẩm được chia thành hai tuyến chỉ huy riêng, vấn đề này rất khó xử lý; có đẩy vấn đề lên cấp trên thì băng thông ở đó tự nhiên cũng rất hạn chế. Từ góc nhìn của EM, những PM như vậy thường làm khổ các kỹ sư giỏi nhất, và cuối cùng dẫn đến việc họ rời đi.
Hiện tại tôi nghĩ cách tốt nhất là đặt một PM kiểu mini-CEO vào từng đội, và nếu họ không đủ vững về kỹ thuật thì ghép họ với một mini-CTO. Như vậy sẽ giảm đáng kể khoảng trống cho chính trị chen vào, và tăng nhiều không gian cho tinh thần làm việc nhóm.
Những đội thành công nhất mà tôi từng ở không có vai trò sản phẩm chuyên trách, và mọi quyết định đều do các lập trình viên đưa ra.
Giờ tôi nghĩ tốt nhất là dọn cả những người phi kỹ thuật lẫn những người nửa vời về kỹ thuật ra khỏi đường đi của lập trình viên, để họ có thể xây dựng trong yên ổn.
Thứ tôi thấy là mọi người trình bày lựa chọn của mình và cố giành sự ủng hộ. Tôi chưa từng thấy thứ chính trị mà người ta hay phàn nàn. Có lẽ tôi may mắn.
Chính trị có nghĩa là một người về mặt kỹ thuật thì sai nhưng lập luận thuyết phục hơn sao? “Chính trị” là gì? Hay là tôi vẫn chưa ở cấp đủ cao, dù đã là senior principal?
Bài viết này và nhiều người cố phân tích chủ đề này đang bỏ lỡ một yếu tố cốt lõi: động lực khuyến khích.
Nhiều lập trình viên đam mê bản thân công nghệ hơn: viết code, giải quyết vấn đề kỹ thuật phức tạp, tạo ra giải pháp hiệu quả. Các phần thưởng chính thức như thăng chức, thưởng, ghi nhận cũng thường gắn với thành tựu kỹ thuật.
Nếu một lập trình viên dành 40 giờ cho nghiên cứu khách hàng, có thể họ sẽ không được ghi nhận hay tưởng thưởng chính thức ngang với một thành tựu kỹ thuật như phát triển một giải pháp xác thực mới có ích cho cả đội.
Muốn thay đổi động lực này thì không thể chỉ dừng ở việc khuyên lập trình viên dành thêm thời gian cho quản lý sản phẩm. Cần có thay đổi mang tính hệ thống về việc tổ chức coi trọng điều gì và tưởng thưởng ra sao.
Nếu chuyển cấu trúc khuyến khích từ lấy kỹ thuật làm trung tâm sang lấy người dùng làm trung tâm, vai trò của quản lý cấp trung và cấp cao sẽ bị ảnh hưởng lớn. Sự thay đổi đó làm lung lay nền tảng vai trò và trách nhiệm của họ, và có thể dẫn tới mất quyền kiểm soát cũng như ảnh hưởng.
Vì vậy những thay đổi như vậy rất có khả năng gặp sự kháng cự âm thầm nhưng mạnh mẽ từ quản lý cấp trung và cấp cao. Họ thường có sức mạnh chính trị đáng kể và quyền lợi đã được thiết lập trong tổ chức.
Mọi nghề thủ công đều được học vào khoảnh khắc chạm với thực tế. Một đạo diễn có thể xem bộ phim trong phòng dựng cả nghìn lần, nhưng lần đầu xem cùng khán giả thật sẽ dạy họ nhiều hơn cả nghìn giờ đó.
Một thợ mộc có thể hài lòng khi làm đồ nội thất suốt cả tuần, nhưng khoảnh khắc thật sự đến khi món đồ đó được đặt trong phòng của khách hàng. Phần mềm cũng vậy.
Muốn kỹ sư phần mềm quan tâm đến người dùng, họ phải nhận phản hồi trực tiếp về điều gì hoạt động tốt và điều gì tệ hại, và nếu có thể thì phải tận mắt chứng kiến.
Một kỹ sư phần mềm đúng nghĩa sẽ có một mức tự hào nhất định về việc làm tốt công việc. Nếu niềm tự hào đó chỉ gắn với code, lịch sử commit và các khái niệm trừu tượng khác, mà hoàn toàn không chạm tới việc nó phục vụ người dùng thực tốt đến đâu, thì ngay từ đầu làm sao họ bắt đầu quan tâm được?
Gần như không liên quan đến bài viết, nhưng xu hướng dùng ảnh AI làm ảnh đại diện cho bài blog dạo này thật sự khiến tôi phát điên.
Nếu khi viết bài bạn không nghĩ ra được một ảnh đại diện rõ ràng, thì mong đừng lãng phí băng thông của tôi để tải về giấc mơ nhảm của máy tính.
Tôi ủng hộ ảnh AI vì nó là một công cụ rất có giá trị. Nhưng nếu dùng ảnh AI làm hình ảnh duy nhất trên trang, thì thật sự phải có lý do xứng đáng, chứ không phải chỉ để lấp chỗ trống.
Đặc biệt là khi bạn còn không curate nổi cho đúng số ngón tay của tất cả mọi người trong ảnh được tạo ra.
Hình ảnh nhằm truyền tải một cảm giác nào đó. Nó biến các khái niệm trừu tượng trong bài thành thứ có thể chạm vào hơn một chút.
Trước đây tôi tìm ảnh trên Internet phù hợp với mục đích đó để dùng. Giờ tôi có thể tự tạo bằng DALL-E, và thường là tốt hơn nhiều.
Hình ảnh này phải bổ trợ cho bài viết. Cũng như văn bản của bài viết cố truyền tải thông tin, cảm giác và khái niệm, hình ảnh cũng nên làm một phần việc đó.
Không ai muốn nhìn một bức tranh kiểu thung lũng kỳ lạ, với những người thuộc đủ các nhóm chủng tộc chính đứng thành vòng tròn và cười với nhau một cách kỳ quặc.
Trào lưu tranh minh họa doanh nghiệp kỳ quái, vô hồn kiểu này đã bắt đầu từ trước khi ảnh tạo bằng AI bùng nổ phổ biến.
Có lẽ là vì một niềm tin nào đó về tối ưu hóa công cụ tìm kiếm.
Đồng thời họ chỉ cần trông đẹp là được.
Nhưng ở đây có một điểm hơi buồn cười. Template blog yêu cầu một vùng ảnh, nên người ta vô thức nhét thứ gì đó vào. Nếu việc đó quá khó thì họ tìm một ảnh stock nhạt nhẽo; nếu cả việc đó cũng khó thì họ cố ý tạo ra một ảnh stock nhạt nhẽo.
Rác AI không cảm hứng, không gu có vẻ sắp phủ kín mọi thứ.
Phần lớn vấn đề của PM nằm ở chỗ họ không làm công việc bám sát thực địa. Một PM giỏi phải liên tục nối liền khoảng cách giữa engineering và người dùng
Phải lặp lại vòng lặp phản hồi này
Nhưng đa số lại nghĩ rằng họ có thể chỉ làm việc trong thế giới tài liệu, sản xuất ra các tài liệu roadmap rồi cố duy trì sự đồng thuận của các bên liên quan bằng vô số buổi check-in và nhắc nhở. Rốt cuộc, họ đang làm công việc của “project manager”
Từ thu thập yêu cầu, xử lý người dùng nổi giận vì bug, họp trạng thái hằng tuần, cho tới truyền đạt tin xấu liên quan đến ưu tiên, tất cả đều được đẩy cho senior developer hoặc tech lead. Anh ta còn bỏ qua phần lớn các nghi thức Agile với lý do là người bận rộn. Anh ta chưa từng viết hay sửa JIRA ticket, và nói rằng đó là việc tổ chức kỹ thuật phải quản lý. Hai nhóm kỹ thuật khác cũng bị PM theo đúng kiểu như vậy
Các tech lead và senior developer biết ngay từ tuần đầu tiên rằng PM đó không ổn, nhưng anh ta trụ lại lâu hơn tất cả chúng tôi và chỉ rời đi sau 4 năm vì cắt giảm nhân sự
Ban quản lý sa vào sự sùng bái Agile rất dễ bị những người như vậy mê hoặc, và họ có thể làm cả tổ chức đi chệch hướng trong nhiều năm. Về lý thuyết, bên liên quan của PM là người dùng, nhưng trên thực tế, công việc lại trở thành đánh bóng cái tôi của các lãnh đạo cấp cao đã thuê mình
Có thể hình thành một vòng lặp khép kín tự củng cố giữa lãnh đạo cấp cao, consultant Agile và PM
Trong cả hai trường hợp, đó đều là sản phẩm không có sức cạnh tranh, và thường có khả năng cứ tồn tại như vậy cho đến khi bị dừng. Vậy mà công ty vẫn đặt PM và PO, dựng lên một cấu trúc kiểu SCRUM, và hành xử như thể đang làm ra một sản phẩm cách mạng. Bao gồm cả các việc khẩn cấp và áp lực kết quả
Trong những môi trường như vậy, PM và PO thường không mấy quan tâm đến việc làm ra sản phẩm tốt hay sản phẩm dùng được, mà tập trung vào chính trị để leo thang thăng tiến nội bộ
Dù có tạo ra một sản phẩm rời rạc trông như bước đi ngẫu nhiên về mặt tính năng và cải tiến, họ vẫn kéo dự án theo hướng khiến bản thân trông tốt trong mắt ban lãnh đạo hoặc khách hàng
Tôi không đủ lớn tuổi để biết họ đã làm thế nào trong thập niên 60, 70, 80, nhưng tôi đoán khi đó không có SCRUM/PM/PO. Diễn ngôn bi quan rằng năng suất đã chậm lại đáng kể so với các thập kỷ trước và ngày nay phần lớn chúng ta đang dựa vào những thứ đã được tạo ra trong quá khứ khá khớp với nhận thức của tôi
Gần đây tôi đang mentor các PM khác. Cũng có roadmap được chia sẻ rộng rãi, nhưng thật sự có rất nhiều tài liệu và spreadsheet được tạo ra mà ngoài tôi ra không ai xem lại. Tôi có cảm giác chúng được làm ra để cho thấy là đang làm việc, và tôi đang cố phá bỏ thói quen đó
Lý do tôi ủng hộ mạnh mẽ quản lý sản phẩm kỹ thuật là vì, nếu đơn giản hóa vấn đề, tôi cho rằng một số PM bị kẹt ở mức trừu tượng quá cao. Vì không thể nói chuyện với nhóm mỗi ngày về các chi tiết kỹ thuật, cuối cùng họ mắc kẹt trong một vùng xám kỳ lạ giữa project management và product management
Bản thân chuyện đó thì không sao, nhưng nếu có hội chứng HIPPO của những người muốn đưa ra quyết định sản phẩm, bạn sẽ phải dành phần lớn thời gian để phòng thủ phía sau và quản lý ngược lên trên
PM bị chỉ trích rất nhiều, đôi khi là chính đáng, nhưng cuối cùng họ thường phải làm chính trị nội bộ để khiến công việc chạy được
PM xuất sắc không chỉ tạo ra tầm nhìn hay kế hoạch, mà còn dẫn dắt cả thực thi và lặp lại. Kế hoạch chỉ chiếm 20% toàn bộ
Product manager giỏi nhất mà tôi từng làm việc cùng đơn giản là một người cực kỳ xuất sắc, hiểu độ phức tạp của triển khai, thậm chí có khả năng tự làm nếu cần, đồng thời cũng hiểu nhu cầu kinh doanh
Người đó không phải engineering manager nhưng vẫn tạo thêm giá trị cho công ty
Đáng tiếc là phần lớn product manager chỉ là người ngồi ở vị trí đó. Họ là người gác cổng nhận công trạng hoặc trách nhiệm, và thường gần như không có lợi ích của chính mình bị đặt cược
Nhìn chung, tôi cho rằng nếu có một tổ chức quản lý sản phẩm riêng thì tức là đang làm sai
Những sản phẩm tốt nhất và thành công nhất mà tôi từng tham gia đều là những sản phẩm mà chính những người triển khai thực sự nắm quyền sở hữu sản phẩm. Đó là những người như engineer, designer, đội customer success
Với tư cách engineer, tôi thích được vào vòng trực hỗ trợ, vì nó khép lại khoảng cách trừu tượng giữa công việc của tôi và những con người thật đang dùng nó từng giây
Tôi cũng từng làm việc với một vài PM hiếm hoi tạo ra giá trị ròng dương, và trong mọi trường hợp đó, họ đều là những người cũng có thể đã trở thành engineer khá tốt
Lý do chính là nếu PM, hoặc người trong nhóm đảm nhận vai trò đó, báo cáo theo cùng một hệ thống quản lý engineering, thì mọi việc cuối cùng sẽ nghiêng về nhu cầu của engineering
Ngay cả những công việc tính năng thật sự cần thiết và có khả năng cao thúc đẩy business tiến lên cũng cuối cùng bị đẩy xuống ưu tiên thấp hơn, vì technical debt hay công việc hạ tầng luôn bằng cách nào đó đang chặn mọi người. Đôi khi đó thực sự có thể là lựa chọn đúng, nhưng để đưa ra những quyết định như vậy cần có sự căng kéo giữa hai tổ chức có vị thế ngang nhau. Khi nó trở thành một phần của engineering, điều đó thường không diễn ra tốt
Tất nhiên, thực tế đáng buồn trong ngành của chúng ta là tổ chức PM riêng, với lý do sở hữu “điều tốt cho business”, thường có quyền lực lớn hơn tổ chức engineering. Nếu thêm vào đó là các PM biết tuân theo quy trình hay framework nhưng không thực sự hiểu sản phẩm hoặc người dùng của mình, thì nó trở thành ác mộng
Tôi nghĩ theo tỷ lệ
Tỷ lệ giữa kỹ sư frontend và kỹ sư backend là bao nhiêu? Tỷ lệ giữa engineering manager và individual contributor là bao nhiêu? Tỷ lệ giữa technical writer và tổng số kỹ sư là bao nhiêu? Tỷ lệ giữa product manager và tổng số kỹ sư là bao nhiêu?
Và cần tinh chỉnh các tỷ lệ này để tối đa hóa tác động, đồng thời giảm thiểu sự can thiệp và quản lý vi mô
Con số thực tế của các tỷ lệ này sẽ khác nhau tùy tổ chức, nhưng nếu nhận thấy có sự can thiệp, hoặc phần “làm như thế nào” không xuất phát đủ từ chính các kỹ sư, thì cần thay đổi tỷ lệ
Phải tăng số kỹ sư trên mỗi people manager hoặc product manager, để họ không thể chen vào theo kiểu đó, buộc họ phải ưu tiên hóa việc cần tham gia, rút khỏi các phạm vi vi mô và trả lại cho kỹ sư quyền tự chủ về cách làm
QA, kỹ sư junior, kỹ sư senior, architect, nhân sự HR, phó chủ tịch, nhân viên bán hàng cũng vậy
Tôi đã làm product management hơn 20 năm và đồng ý với phần lớn những gì nói ở đây. Tỷ lệ rất quan trọng
CPO rất dễ xây dựng đế chế với cả một đội quân PM dưới quyền. Tổ chức sẽ rơi vào tình trạng các PM sở hữu những mảnh nhỏ của trải nghiệm khách hàng, như một trang đơn lẻ, tối ưu tỷ lệ nhấp nút nhưng không đóng góp có ý nghĩa vào chiến lược hay tầm nhìn sản phẩm
Rất khó để trở thành product manager khi không sở hữu một sản phẩm
PM cần tập trung vào mục tiêu kinh doanh nhiều hơn rất nhiều so với hiện nay. Giải quyết vấn đề của người dùng là cần thiết nhưng chưa đủ. Việc giải quyết vấn đề đó cũng phải chuyển hóa thành giá trị cho công ty
Để làm được điều này, các đối tác engineering và UX có product sense mạnh là điều thiết yếu
Tệ hơn nữa là các developer “dễ thay thế” đến từ công ty outsource. Giờ thì phải cách ly việc phát triển khỏi khách hàng bằng thêm nhiều tầng quản lý
Một cách tuyệt vời để tăng GDP
Ví dụ nếu xử lý những thứ như ERP, Oracle Fusion Apps, WorkDay, SAP, thì một PM không thể sở hữu toàn bộ sản phẩm. Thay vào đó họ sẽ phụ trách nhiều chức năng, mỗi chức năng tự thân đã phức tạp, và do đặc thù ERP thường còn bao gồm tích hợp với nhiều sản phẩm khác
Dù vậy, tôi đồng ý với định hướng lớn rằng PM phải sở hữu một thứ gì đó có ý nghĩa
Với tư cách developer và development manager, những product manager tốt nhất tôi từng làm việc cùng hầu như không can thiệp vào “làm như thế nào”
Tất nhiên họ có thể tạo ticket ở mức epic trong backlog, nhưng ở các tầng thấp hơn thế, họ tin rằng bạn và những người phụ trách dự án có thể hoàn thành công việc
Vấn đề là tổ chức phải hỗ trợ điều đó. Ở hầu hết công ty, việc nhận được nhiều sự chú ý nhất không phải là việc xoay quanh tầm nhìn hay tăng trưởng, mà là việc ồn ào nhất
Và những việc như vậy thường xung đột trực tiếp với hướng mà product lead hoặc manager mong muốn
PM không hiểu “làm như thế nào”, tức PM không biết sản phẩm của mình hoạt động ra sao, là tệ nhất
Những PM tốt nhất tôi từng làm việc cùng đều có nền tảng kỹ thuật
Khi mọi người cố bước vào lãnh địa của người khác, kết cục luôn là thảm họa. Cả hai chiều đều vậy. Kỹ sư suy nghĩ quá nhiều theo góc nhìn “làm như thế nào?” nên kém ở “tại sao?” và “cái gì?”, còn product manager cũng nên lùi khỏi “làm như thế nào?” trừ khi điều đó nhằm làm rõ “cái gì?” hoặc “tại sao?”
Cần có sự cân bằng. PM/PO cũng cần hiểu biết cơ bản. Không thể là người dùng máy tính còn chật vật
Ngay cả PM giỏi cũng có thể bị trói buộc khá nhiều nếu xung quanh có quá nhiều PM tầm thường
Khi làm việc với nhiều công ty Fortune 500, tôi đã thấy rất nhiều văn hóa hỏng
Ở những nơi đó, PM giải quyết phần lớn vấn đề bằng công cụ duy nhất họ có: cuộc họp. Cơ chế khuyến khích thăng chức được thiết kế sao cho cuộc họp càng lớn thì họ càng trông giống người quan trọng
Tôi đã tham gia hàng trăm giờ họp cross-functional team, trong đó người thực sự làm việc chỉ có 1–2 người, thường là PM nói suốt, còn 10–20 người tắt tiếng rồi cuối cùng chỉ phê duyệt như thể để chứng minh mình có tồn tại
Kết quả là đội ngũ kỹ sư mất động lực, không còn thời gian làm công việc kỹ thuật thực sự, và bị yêu cầu đưa ra ước lượng hoặc cam kết ngay tại chỗ mà không có điều tra hay hiểu biết về code
Tôi cũng từng thấy PM bác bỏ thiết kế kỹ thuật chỉ vì không thích các con số hoặc “point”, khiến các kỹ sư phải định dạng lại cùng một ý tưởng thành “ticket” khác để thỏa mãn gu thẩm mỹ khó hiểu của PM
Do thiếu hiểu biết và các nghi thức phô diễn trạng thái vô nghĩa, toàn bộ dự án bị chậm trễ và đi chệch hướng
Ngược lại, tôi cũng từng làm việc với những PM xuất sắc; họ bảo vệ đội khỏi những chuyện nhảm nhí như vậy và giúp tập trung vào các mục tiêu đúng. Những người như thế rất quý giá, còn nhóm kia thì gây hại tương ứng
Không phụ thuộc vào số lượng PM, đây là câu chuyện về kiểu PM mà tôi muốn làm việc cùng
Tôi đã làm ở bốn công ty trong ngành, có kinh nghiệm từ startup dưới 40 người cho đến JP Morgan Chase
Tôi bác bỏ quan niệm rằng người “có kỹ thuật” thông minh hơn người “không có kỹ thuật”. Thực ra, là một kỹ sư, tôi thường sa vào chi tiết và bỏ lỡ bức tranh toàn cảnh, và nhiều khi cần PM kéo tôi ra khỏi đó
Tuy nhiên, theo kinh nghiệm của tôi, với tư cách kỹ sư, PM dễ làm việc cùng nhất là người đã từng có dù chỉ một chút tiếp xúc thực tế với code
Không cần phải quá ghê gớm. Chỉ cần từng làm website bằng HTML và CSS từ lâu, từng viết truy vấn SQL tạm thời, hoặc từng học một lớp Python trong chương trình thạc sĩ là đủ
Chỉ cần có điều gì đó giúp PM hiểu rằng việc viết code không phải là một môn khoa học chính xác, cũng không hoàn toàn là phép màu
Những PM như vậy sẽ đứng ra bảo vệ các kỹ sư làm việc cùng họ, hoặc ít nhất cố gắng cân bằng giữa yêu cầu kinh doanh và thực tế kỹ thuật
Những người trở thành PM mà hoàn toàn không có tiếp xúc với kỹ thuật thường có xu hướng “thiên về kinh doanh” hơn; ở một thời điểm nhất định, doanh nghiệp có thể cần đúng điều đó, nhưng không phải lúc nào cũng vậy. Là kỹ sư, tôi muốn làm việc với người hiểu góc nhìn của mình tốt hơn
Hoàn toàn không cay cú đâu nhé :p