Tôi có hai cuốn sách đã dạy tôi về sản phẩm: Inspired của Marty Cagan, và Gestão de Produtos của Joca Torres, người mà tôi còn may mắn được nhận mentoring. Trong nhiều năm, hai cuốn đó là tấm bản đồ của tôi: PM là gì, product designer là gì, kỹ sư là gì, ai làm việc gì. Mỗi vai trò có một đường viền rõ ràng.
Suốt năm vừa qua, khi nhìn đội của mình làm việc với AI ở Prolog, tôi bắt đầu thấy những đường viền đó nhòe đi. Không phải sách sai: mà là cái lớp nơi mỗi vai trò diễn ra đã dâng lên cao hơn.
Ở bài đầu tiên của loạt bài tôi đã kể về nỗi bất an khiến tôi bắt đầu tái thiết tech ở Prolog, và ở bài thứ hai, harness là gì, cái hạ tầng giúp AI tạo ra kết quả. Ở cuối bài đầu tiên tôi có hứa sẽ mở ra một phần cụ thể: công việc của mỗi vị trí thay đổi ra sao khi AI trở thành người xây dựng. Đó là chủ đề ở đây.
Công việc không biến mất, nó dâng lên một lớp
AI không xóa vai trò của mỗi nghề, nó thay đổi cái lớp nơi vai trò đó diễn ra.
Cách hiểu dễ dãi, cái bán nỗi sợ, là “AI sẽ thay thế nghề X”, và đó không phải điều tôi thấy xảy ra. Cái tôi thấy là nội dung của công việc dịch chỗ: cái từng là làm trở thành chỉ đạo và phản biện người làm.
Kỹ sư, người từng viết code, giờ rà soát lại thứ agent đã viết. PM, người từng viết spec, giờ đánh giá bản prototype ra đời từ nó chỉ trong vài giờ. Vẫn là con người đó, chỉ có công cụ trong tay họ là đổi.
Khi quay lại với Cagan và Joca với ý nghĩ đó trong đầu, mọi thứ vỡ ra theo một kiểu khác. Cả hai đều mô tả, một cách cẩn thận, phần thực thi của mỗi vai trò (nhiệm vụ cụ thể, thứ phải bàn giao, cái rời khỏi tay bạn vào cuối ngày), và đó chính xác là thứ AI đang tiếp quản. Cái còn lại cho con người là nửa kia: quyết định điều gì đáng xây, tìm ra lỗ hổng trong thứ đã được xây, có gu để biết cái gì là tốt. Óc phán đoán, không phải phần thực thi.
Vậy nên tôi sẽ làm điều tôi đã làm với chính mình: lấy định nghĩa của từng vai trò trong sách, và hỏi xem AI ăn mất phần nào của nó và phần nào còn lại (và trở nên đắt giá hơn).
Bộ ba, theo các cuốn sách
Trước khi tách ra từng vai trò, cũng đáng nhắc lại cách sách dựng nên đội ngũ. Joca nói thẳng: một sản phẩm thành công phải đáng mong muốn, khả thi và có thể xây được, và điều đó định nghĩa cái mà ông gọi là ba chức năng thiết yếu để tạo ra một sản phẩm thành công: một UX designer, product management và một developer. Bộ ba đó là core team (chương 2). Cagan, trong Inspired, mô tả chính những vai trò đó ở chương mở đầu, “Key Roles and Responsibilities”.
Cả hai đều nhấn mạnh một điểm mà tôi sẽ quay lại ở cuối: đây không phải quan hệ sếp và cấp dưới. Theo lời Joca, product engineering, product management và UX là một đội, không có sự lệ thuộc giữa bất kỳ nhóm nào trong số đó (chương 31), và ở Cagan cùng ý đó xuất hiện dưới dạng PM và engineering là ngang hàng, không vị trí nào lệ thuộc vị trí nào (chương 5). Và khi AI bước vào giữa bộ ba, chính mối quan hệ hợp tác đó là thứ đổi hình dạng nhiều nhất.
Bảng: mỗi nghề trong tech lên cao hơn một lớp. Kỹ thuật từ người sản xuất code thành người phản biện agent; sản phẩm, từ người viết spec thành kiến trúc sư của vòng lặp; thiết kế, từ người sản xuất màn hình thành nhạc trưởng của thí nghiệm; chất lượng, từ người kiểm thử thành người xây dựng sự kiểm chứng.
Vai trò của mỗi nghề trong tech
Cùng một vai trò, cao hơn một lớp
phần thực thi thuộc về agent · óc phán đoán ở lại với bạn: quyết định, phản biện, có gu
Kỹ sư: từ người sản xuất code thành người phản biện agent
Với engineering, thứ quan trọng không còn là bạn sản xuất bao nhiêu code: nó thành việc bạn phản biện tốt đến đâu thứ agent đã sản xuất.
Định nghĩa của Joca giờ đọc lại thấy nhói: product engineering chịu trách nhiệm phát triển sản phẩm và giữ cho nó vận hành, và, xa hơn một chút, engineering xây sản phẩm (chương 31). Xây là động từ. Cagan bổ sung từ phía bên kia, về mối quan hệ với product: product manager định nghĩa giải pháp, nhưng đội engineering mới biết rõ nhất cái gì là khả thi, và họ mới là người rốt cuộc giao ra giải pháp đó (chương 5). Một bên định nghĩa, một bên giao hàng.
Giờ thì việc giao ra phiên bản đầu tiên là của agent. Thứ không đổi, và trở nên đắt giá hơn, là tất cả những gì Cagan gắn vào kỹ sư như một nguồn của đổi mới: kỹ sư biết rõ hơn bất kỳ ai cái gì là khả thi (chương 5). Biết cái gì khả thi, tìm ra lỗ hổng trong kế hoạch agent đề xuất, nhìn ra cái đánh đổi về hiệu năng hay bảo mật mà nó không thấy, quyết định khi nào can thiệp và khi nào để nó chạy. Cái đó mỗi tháng lại nặng ký hơn. Nhớ cú pháp trong đầu, gõ boilerplate bằng tay, lục Stack Overflow, đếm dòng code như một chiếc cúp cá nhân: cái đó nhẹ ký đi.
Ở Prolog tôi đã nói thẳng với đội: sẽ không ai bị đánh giá bằng số dòng code. Ai xưa nay giỏi “tìm lỗ hổng” thì càng có giá, còn ai từng gắn mình với chuyện “sản xuất thật nhiều code thật nhanh” sẽ phải căn chỉnh lại nơi mình đầu tư công sức. Và điều này không làm engineering kém giá trị đi. Giá trị của nó xưa nay vẫn nằm ở chỗ biết cái gì trụ được nhiều hơn là ở chỗ sản xuất nhanh, và giờ điều đó chỉ trở nên rõ ràng.
PM: từ người viết spec thành kiến trúc sư của vòng lặp
PM cảm nhận điều này khi prototype trở nên rẻ: công việc thôi là viết tài liệu và trở thành chọn xem ý tưởng nào đáng với thời gian của đội.
Cagan nói dứt khoát về trái tim của công việc: phải có ai đó khám phá ra giải pháp, sản phẩm, thật sự là gì, bao gồm tính năng, trải nghiệm người dùng và tiêu chí ra mắt. Người đó là product manager, và nhiệm vụ đó là trái tim công việc của họ (chương 1). Joca đưa ra đường viền rộng: product management là chức năng chịu trách nhiệm cho mọi khía cạnh của một sản phẩm phần mềm, trong suốt vòng đời của nó, từ lúc thai nghén đến khi kết thúc (chương 2).
Để ý rằng ở cả hai, từ khóa là khám phá, không phải đặc tả. Cagan có hẳn một chương chỉ để bảo vệ rằng công việc là discovery, không phải “yêu cầu”: phần mềm có hai giai đoạn, tìm ra cái gì cần xây (đúng sản phẩm) và xây nó (xây cho đúng). Giai đoạn đầu là discovery, giai đoạn sau là thực thi (chương 12). Đó xưa nay vẫn là thông điệp của ông. AI chỉ làm nó thành hiện thực theo nghĩa đen.
Bởi vì khi việc build sụp từ hàng tuần xuống còn vài giờ, nút thắt thôi là xây và trở thành quyết định cái gì đáng xây. Cái spec dài duyệt qua hội đồng, cái planning quý đóng khung, cái status report như một thứ phải bàn giao, việc điều phối qua lại giữa engineering và design: tất cả nhẹ ký đi. Cái nặng ký hơn là discovery nhanh (dựng prototype để hiểu, chứ không viết spec để xây), gạn lọc giả thuyết (ý tưởng nào đáng thời gian của đội) và quyết định cái gì không làm, thường xuyên hơn. Vài công ty đã bắt đầu gọi kiểu PM này là “Editor” hay “Architect”. Không phải ít PM đi: mà là một PM khác, người gạn lọc, người quyết định bằng gu, người vạch hướng. Cái từng là trung tâm ở phiên bản cũ, viết spec, mới là cái đã nhẹ đi.
Product designer: từ người sản xuất màn hình thành nhạc trưởng của thí nghiệm
Ở design, đơn vị công việc rời khỏi màn hình và chuyển sang cái hệ thống sản xuất ra màn hình, và product designer bắt đầu chọn xem biến thể nào sống sót.
Ở Joca, định nghĩa của UX là hiểu để thiết kế: UX chịu trách nhiệm hiểu thật sâu người dùng và vấn đề bạn muốn giải cho họ (chương 32). Và cái luồng ông mô tả là nghi thức ai cũng biết: prototype trên giấy, rồi wireframe, rồi visual designer thêm màu và hình vào các màn hình. Cagan cắt vai trò làm hai với cùng lối tư duy: interaction designer phát triển một hiểu biết sâu về người dùng và tạo ra các tác vụ, điều hướng và luồng, đưa cái đó vào wireframe, rồi chuyển cho visual designer, người đắp da đắp thịt cho wireframe (chương 4).
Cái chuỗi đó, hiểu, phác thảo, tinh chỉnh từng màn một, chính là thứ AI rút ngắn. Đơn vị công việc thôi là “cái màn hình” và trở thành “cái hệ thống sinh ra màn hình”. Làm lại cùng một biến thể năm lần trong Figma, đặc tả từng component một, cái handoff pixel-perfect như một nghi lễ: nhẹ ký đi. Dựng prototype ở tốc độ vòng lặp (nhiều phương án song song, vứt những cái dở), định nghĩa hệ thống thị giác thay vì từng màn hình riêng lẻ, và phản biện thị giác nhanh (thấy AI đề xuất một thứ và nhận ra ngay nó sai trước cả khi người dùng nhận ra): nặng ký hơn.
Và ở đây Cagan nói, hồi tận năm 2008, một điều bảo vệ product designer khỏi cái ý nghĩ rằng mình đã thành kẻ bấm nút: công việc của họ chưa bao giờ chỉ là vẽ cho đẹp. Một sản phẩm tốt đòi hỏi một trải nghiệm người dùng tốt, và một trải nghiệm người dùng tốt đòi hỏi sự cộng tác chặt chẽ giữa product management và design (chương 4). AI sinh ra biến thể. Ai quyết định biến thể nào xứng đáng đến tay người dùng thì vẫn là một con người có gu.
QA: từ người kiểm thử thành người xây dựng sự kiểm chứng
QA là trường hợp thú vị nhất, vì đó là vai trò sách gần như không tách riêng, và là cái AI xáo trộn nhiều nhất.
Để ý: trong bộ ba của Joca (designer, PM, developer) và trong các vai trò của Cagan, chất lượng xuất hiện một cách hòa tan, như trách nhiệm của cả đội, chứ không phải một chiếc ghế riêng với phương pháp riêng. Suốt một thời gian dài điều đó hợp lý, giờ thì không còn nữa, và lý do đơn giản: nếu agent xây nhanh mà việc kiểm chứng vẫn thủ công, thì thứ bạn tạo ra chỉ là nợ kỹ thuật ở tốc độ cao.
Vậy nên QA thôi là người chạy từng ca kiểm thử bằng tay và trở thành người thiết kế cái testing harness, hệ thống kiểm thử cái hệ thống: cấu hình AI để viết test cho code do một AI khác viết, phát hiện regression trước cả người dùng, nghĩ xem lỗi thường hay xuất hiện ở đâu. Trên thực tế nó thành một câu hỏi vận hành mà chúng tôi áp dụng: mỗi con bug lọt lưới đều trở thành “lần sau làm sao để phát hiện tự động chuyện này?”. Kiểm thử thủ công một luồng đã biết đến kiệt sức, chạy regression bằng tay mỗi lần release, QA như cánh cổng duy nhất trước khi lên production: nhẹ ký đi. Kiểm chứng như một hệ thống, không phải như một đường chuyền ở cuối băng chuyền.
Đó là vai trò dâng lên nhiều lớp nhất, chính vì nó vốn ít được định nghĩa nhất. Nơi sách không khắc một đường viền, AI đang vẽ một đường viền mới.
Hằng số: thứ sách vốn đã nói là quan trọng nhất
Có một thứ không đổi, và nó ẩn ngay trước mắt trong cả hai cuốn: cái mà họ gọi là điều quan trọng nhất lại chính là thứ AI không làm được.
Joca mở đầu chương về phẩm chất của một PM giỏi không rào đón: quan trọng nhất trong tất cả, không chút nghi ngờ, là sự đồng cảm (chương 4). Không phải một bảng chức năng hay một thứ để bàn giao: đó là khả năng đặt mình vào vị trí của người dùng. Cagan, về phần mình, dành cả cuốn sách để bảo vệ discovery, gu và óc phán đoán hơn là quy trình, và cả hai, mỗi người một kiểu, đều đang nói cùng một điều: thứ tách người giỏi khỏi người trung bình chưa bao giờ là phần cơ học của công việc.
Và phần cơ học chính xác là phần đã chuyển cho agent. Viết spec, vẽ màn hình, viết code, chạy test. Cái ở lại, và trở nên đắt giá hơn, là tư duy phản biện, gu (biết cái gì là tốt), óc phán đoán trong mơ hồ, sự tò mò, sự quan tâm tới người dùng thứ bạn làm ra. Tóm lại trong câu tôi đã dùng với đội: nội dung công việc thay đổi, người làm ra nó thì không.
Sơ đồ hai lớp. Bên trên, thứ ở lại với chúng ta và trở nên đắt giá hơn: gu (biết cái gì là tốt), óc phán đoán trong sự mơ hồ, sự đồng cảm với người dùng, quyết định điều gì không nên làm, thứ mà sách vốn đã nói là quan trọng nhất. Công việc đã lên một lớp. Bên dưới, thứ đã chuyển cho agent: viết spec, vẽ màn hình, viết code, chạy test thủ công.
Ở lại với chúng ta · và trở nên đắt giá hơn
thứ mà sách vốn đã nói là quan trọng nhất
công việc đã lên một lớp
Đã chuyển cho agent
Cái giá điều này sẽ đòi (không sáo rỗng)
Tôi không muốn gói ghém chuyện này cho gọn gàng quá, vì nó không như vậy. Bước chuyển này đòi những cái giá cụ thể, và không cái nào dễ chịu.
Cái đầu tiên là bỏ lại phía sau thói quen của cả một thập kỷ. Ai đã năm, mười năm trong lối cũ đều mang theo những khuôn mẫu đã giúp họ đi đến đây, và chính những khuôn mẫu đó là thứ cản việc thay đổi. Không có đường tắt, và sự khó chịu là điều được dự liệu.
Rồi tới, phản biện AI nhiều ngang với sáng tạo cùng nó: chấp nhận cái gợi ý vừa hiện ra không phải là làm việc; tìm ra lỗ hổng trong kế hoạch nó đề xuất mới là. Thứ xưa nay vẫn đắt (tư duy phản biện, gu, óc phán đoán) trở nên đắt hơn.
Còn có chuyện sai như một đội, không phải như một cá nhân. Chúng tôi không sa thải một kỹ sư vì một con bug trên production, chúng tôi cải thiện việc review, và khi AI làm sai thì cái chúng tôi củng cố là harness. Bug của agent là chuyện quy trình, không phải con người: một cam kết, không phải một khẩu hiệu.
Và cái khó chịu nhất: chấp nhận rằng vài chức năng thay đổi nhiều hơn những chức năng khác. Điều đó gây khó chịu cho ai đến giờ đổi thay ít, và không thể giả vờ rằng mọi thứ vẫn như nhau. Cái làm được là đưa nó vào một cuộc trò chuyện cởi mở.
Và để không nghe như một kẻ đã tới đích: Prolog vẫn còn ở giai đoạn đầu của chuyện này. Chúng tôi vẫn ở AI-assisted, với mức tăng 10 đến 20%, chưa phải AI-first ở mức 5x hay 10x. Tôi đang kể một hướng đi mà chúng tôi đang xây, có đúng có sai, không phải một chiến thắng.
Điều tôi rút ra từ chuyện này
Sách không sai. Chúng mô tả phần thực thi của mỗi vai trò với một độ chính xác mà tới giờ tôi mới thật sự hiểu (viết spec, vẽ màn hình, xây sản phẩm, chạy test), và phần thực thi đó giờ thuộc về agent. Và cái còn lại cho con người là phần kia, phán đoán, phản biện, có gu, quan tâm tới người dùng, mà, quay lại với Cagan và Joca, chính là thứ họ nói là quan trọng nhất ngay từ trang đầu.
Có lẽ đó mới là phần hay: công việc mà AI lấy khỏi tay chúng ta là phần lặp đi lặp lại nhất, còn cái nó để lại là phần xưa nay vẫn khó nhất, và thú vị nhất. Tôi sẽ tiếp tục kể chuyện đi tới đâu.
Nguồn
- Marty Cagan, Inspired: How to Create Products Customers Love (ấn bản đầu, 2008). Các định nghĩa về vai trò lấy từ chương 1 (Key Roles and Responsibilities), 4 (Product Management vs. Design), 5 (Product Management vs. Engineering) và 12 (Product Discovery).
- Joca Torres, Gestão de produtos: Como aumentar as chances de sucesso do seu software (Casa do Código). Các định nghĩa lấy từ chương 2 (Product management phần mềm là gì?), 4 (Những phẩm chất chính của một product manager), 31 (Product engineering và product management) và 32 (UX và product management).
- Cách đọc về việc vai trò dâng lên một lớp bổ trợ cho loạt bài: OpenAI, Harness Engineering, và Peter Pang, CTO của CREAO.