Các nhóm sản phẩm đã gặp khó khăn trong việc tạo ra ý định. AI khiến họ nghĩ rằng có thể bỏ qua bước này.

Các nhóm sản phẩm đã gặp khó khăn trong việc tạo ra ý định. AI khiến họ nghĩ rằng họ có thể bỏ qua điều đó. Tìm kiếm Trang chủ Lưu trữ & Tìm kiếm Duyệt theo thẻ Đăng nhập Đăng ký Trang chủ Bài viết Các nhóm sản phẩm đã gặp khó khăn trong việc tạo ra ý định. AI khiến họ nghĩ rằng họ có thể bỏ qua điều đó. Các nhóm sản phẩm đã gặp khó khăn trong việc tạo ra ý định. AI khiến họ nghĩ rằng họ có thể bỏ qua điều đó. Đừng nhầm lẫn việc bàn giao sản phẩm với vạch đích. Đó chỉ là khởi đầu của cuộc đua. Pavel Samsonov Ngày 7/6/2026 Quy trình thiết kế. Yêu nó, ghét nó – bạn có một giờ để nghe tôi nói về nó. Hoặc 45 phút, tùy thuộc vào tốc độ bạn nghe podcast. Tôi không phán xét (bằng lời nói). Design Overtime: Quy trình thiết kế chưa chết – chỉ là cảm giác như vậy Guy Segal và Pavel Samsonov thách thức tuyên bố lặp đi lặp lại rằng quy trình thiết kế đã chết – lập luận rằng đối với nhiều người, nó chưa bao giờ thực sự tồn tại ngay từ đầu. Quy trình hiệu quả không phải là một danh sách kiểm tra tuần tự, mà là một khuôn khổ ra quyết định cho phép bạn nói "không" mà không làm rạn nứt mối quan hệ với các bên liên quan. RSS.com Tập Design Overtime này không phải là điều kiện tiên quyết cho số Picnic hôm nay, nhưng nó đề cập đến một chủ đề quan trọng mà tôi muốn mở rộng hôm nay. Tốc độ luôn là một mặt hàng Gần như là một điều sáo rỗng khi điều duy nhất các giám đốc điều hành muốn từ các nhà quản lý sản phẩm là tốc độ bàn giao tính năng nhanh hơn. Vì vậy, thật mới mẻ khi thấy một giám đốc điều hành cấp C hỏi: ❝ Trong nhiều năm, mọi người đều bị ám ảnh bởi tốc độ bàn giao. Làm thế nào để chúng ta chạy Scrum tốt hơn. Làm thế nào để chúng ta viết các câu chuyện người dùng chặt chẽ hơn. Làm thế nào để chúng ta bàn giao nhiều phiếu hơn mỗi sprint. Hầu như không ai đặt câu hỏi quan trọng: liệu tất cả những điều này có thực sự hữu ích cho khách hàng không? Martin Michalik, Các nhà quản lý sản phẩm đang đầu tư vào những kỹ năng sai lầm. Lại nữa. Quan trọng là, Michalik nhận ra rằng chúng ta đang đạt được tiến bộ trong việc khắc phục điều này, cho đến khi AI xuất hiện. Đột nhiên, các nhóm có một cái cớ để tránh làm bất cứ điều gì khó khăn. Các nhóm thiết kế được cho biết “chúng tôi không cần kiến trúc thông tin vì AI có thể làm được.” Và các nhóm sản phẩm được cho biết, “chúng tôi không cần phải sửa quy trình của mình nữa vì giờ đây chúng tôi có thể bàn giao rất nhanh.” Và điều này giống như một bước tiến lớn. Bởi vì các nhóm đó đang gặp khó khăn với quy trình ở cấp độ cơ bản nhất. Quên “đầu ra so với kết quả” – nhiều nhóm đang gặp khó khăn trong việc kết nối các sản phẩm bàn giao khác nhau của họ thành một đầu ra duy nhất có thể thực sự đến được sản phẩm. Thật là một luồng gió mới khi nhảy thẳng đến “mọi người đều viết mã.” Thật giải phóng khi yêu cầu Claude thay đổi và thấy chúng hiển thị trực tiếp. Chỉ có một vấn đề nhỏ với điều đó: mã chưa bao giờ thực sự là mục tiêu. Các nhóm này đã đặt đầu ra làm mục tiêu của họ trong một thời gian dài đến nỗi họ quên mất mục đích của đầu ra ngay từ đầu. Bước duy nhất họ có thể tưởng tượng sau “bàn giao sản phẩm” là “quay lại danh sách tồn đọng và bàn giao một sản phẩm khác.” Và sự thiếu trí tưởng tượng này là do họ chưa bao giờ giải quyết vấn đề trung tâm mà định nghĩa quy trình nhằm mục đích khắc phục: định nghĩa ý định đằng sau công việc. ❝ Mã là một mã hóa của ý định. Cũng như bất kỳ loại hướng dẫn nào, sự ngắn gọn là sức mạnh. Jason McIntosh Nhóm chưa bao giờ gặp vấn đề trong việc đưa mã nguồn vào sản xuất (prod). Thực tế, không có nhóm nào gặp phải. Các tổ chức kỹ thuật phần mềm tuyển dụng lập trình viên dựa trên khả năng đưa mã nguồn vào sản xuất. Điều còn thiếu là ý định. Trí tuệ nhân tạo (AI) cho phép mọi người bỏ qua việc hình thành ý định – một điều kiện tiên quyết khi làm việc với một hoặc nhiều đồng nghiệp – và để mỗi người tự mình trở thành nhà thiết kế, lập trình viên và quản lý sản phẩm (PM). Chức năng bắt buộc của việc giải thích một cách thuyết phục lý do chúng ta thực hiện công việc đó là điều chúng ta có được "miễn phí" với một chu trình phát triển sản phẩm thực sự. Giờ đây, mọi người đều có thể tạo ra hàng vạn bát cháo yến mạch. "Bỏ qua quy trình" là sự sai lệch ý định ở cấp độ hệ thống. Là một hệ quả của quy trình "bạn có thể làm mọi thứ", tất cả những suy nghĩ từng dẫn đến chiến lược giờ đây đã lỗi thời. Mục đích của một tài liệu chiến lược là gì khi các nhà phát triển của bạn đang triển khai một tính năng mỗi giờ dựa trên một ý tưởng hay ho mà họ có được trong bữa trưa? Và chúng ta làm gì với công việc vô nghĩa? Chúng ta giao phó nó cho AI. Giờ đây, một tài liệu chiến lược tổng hợp đang được đưa vào một tài liệu yêu cầu sản phẩm (PRD) tổng hợp, sau đó là kết quả nghiên cứu người dùng tổng hợp, thiết kế tổng hợp, mã nguồn tổng hợp và triển khai tổng hợp. Với tốc độ của AI, không có "con người trong vòng lặp" nào có thể dành thời gian đọc bất kỳ điều gì trong số này mà không bị coi là một trở ngại. Vấn đề là đến cuối quy trình làm việc đó (ngay cả khi ý tưởng ban đầu xuất phát từ một nhu cầu thực sự nào đó – điều này hoàn toàn không được đảm bảo) thì ý định đằng sau công việc đã bị sai lệch một cách vô vọng: ❝ Ngay cả các mô hình tiên tiến nhất cũng làm sai lệch trung bình 25% nội dung tài liệu vào cuối các quy trình làm việc dài, với các mô hình khác thất bại nghiêm trọng hơn…. mức độ suy giảm trầm trọng hơn do kích thước tài liệu, thời lượng tương tác hoặc sự hiện diện của các tệp gây nhiễu. Philippe Laban, Tobias Schnabel, Jennifer Neville, LLMs Corrupt Your Documents When You Delegate Thật đáng tiếc nếu chúng ta đã "dân chủ hóa" công việc này và mỗi người trong công ty đã tạo ra hàng trang tài liệu nghiên cứu và chiến lược mâu thuẫn. Điều đó sẽ làm trầm trọng thêm mức độ suy giảm, vì vậy đây chắc chắn là điều mà các tổ chức đang nỗ lực ngăn chặn. Haha, chỉ đùa thôi. Thay vào đó, họ đang đổ lỗi cho các nhà thiết kế vì không phải là "những người có tư duy hệ thống". Sự thật là không phải lỗi của thiết kế khi các hệ thống bị hỏng, và không phải nhiệm vụ của chúng ta để sửa chữa chúng: ❝ Chúng ta cố gắng tự mình đảm nhận toàn bộ hệ thống. Điều đó có vẻ anh hùng, và phim ảnh cùng thần thoại khiến nó có vẻ thực tế, nhưng khi bạn làm việc chống lại một hệ thống, nó giống như bơi ngược dòng trong một con sông mạnh mẽ. … Nơi bạn làm việc khó có thể xứng đáng với sự hy sinh này. Scott Berkun, Make the system work for you (trích từ Why Design Is Hard) Scott đưa ra rất nhiều lời khuyên hữu ích trong bài viết đó về cách làm cho hệ thống hoạt động vì bạn. Nhưng với việc ngành công nghiệp ngày càng làm suy yếu các hệ thống của mình vì tốc độ không có ý định, đừng ngạc nhiên nếu bạn phải bắt đầu tự xây dựng lại hệ thống đó.