AI giúp dev làm nhanh hơn, rồi PM trở thành người cả team phải chờ

Giả sử chiều thứ Ba, dev báo phần việc dự kiến đến cuối tuần mới xong đã có thể đem đi review. Nhờ AI hỗ trợ, team làm nhanh hơn dự tính.

PM chưa kịp vui thì nhận được câu hỏi: “Xong phần này rồi bọn mình làm gì tiếp?”

Backlog vẫn còn nhiều việc. Có yêu cầu từ sales, có tính năng khách hàng đã hỏi vài lần, có cả ý tưởng PM muốn thử từ lâu. Nhưng hỏi việc nào nên bắt đầu ngay thì chưa trả lời được. Phải đến thứ Sáu PM mới có lịch trao đổi với khách hàng, còn scope thì vẫn đang bàn.

PM bèn dùng AI soạn nháp PRD, bổ sung user stories rồi gửi cho dev. Tài liệu ra nhanh thật. Nhưng đến câu “vì sao mình ưu tiên tính năng này?”, PM vẫn phải quay lại những câu hỏi chưa giải quyết từ đầu.

Mình muốn bàn về đúng tình huống ấy: khi dev làm nhanh hơn, PM cần đổi cách làm việc thế nào để team có thể tiếp tục mà không phải chốt vội những việc còn chưa hiểu rõ?

Chapter 01

Lịch cũ không theo kịp tốc độ mới

Trong ví dụ này, trước đây PM có thể tranh thủ lúc dev đang làm tính năng hiện tại để chuẩn bị tính năng tiếp theo: nói chuyện với khách hàng, xem dữ liệu, trao đổi với designer rồi chốt scope cùng dev.

Khi dev xong sớm hơn mà những việc còn lại vẫn diễn ra theo lịch cũ, khoảng thời gian chuẩn bị ấy bị ngắn lại. PM phải trả lời sớm hơn, dù cuộc hẹn với khách hàng chưa diễn ra và dữ liệu cần xem chưa có thêm.

AI có thể giúp rút ngắn một số đoạn: tổng hợp ghi chú, soạn tài liệu, dựng prototype. Nhưng nếu khách hàng chỉ rảnh vào thứ Sáu, việc tạo được prototype từ thứ Ba chưa giúp chúng mình biết họ sẽ dùng nó ra sao.

Vì vậy, trước khi yêu cầu PM làm nhanh hơn, cần xem team đang chờ ở đâu.

Nếu đã biết cần làm gì mà tài liệu chưa xong, PM có thể dùng AI hỗ trợ viết nháp rồi kiểm tra lại. Nếu chưa rõ có nên làm tính năng đó hay không, thêm chi tiết vào PRD chưa đủ để bắt đầu.

Lấy một việc cụ thể trong backlog của team: gửi báo cáo tự động qua email mỗi tuần. Khách hàng đang dùng phần mềm quản lý công việc và phản ánh rằng việc chuẩn bị báo cáo khá mất thời gian.

Từ yêu cầu ấy, chúng mình có thể viết ngay một danh sách chức năng: chọn người nhận, chọn lịch gửi, chọn định dạng file. Nhưng vẫn còn một câu cần hỏi: khách hàng đang mất thời gian ở bước nào?

Nếu họ chỉ cần tải file rồi chuyển nguyên file cho đồng nghiệp, gửi tự động có thể giúp ích. Nếu họ phải dành cả buổi chỉnh lại dữ liệu trước khi gửi, email tự động chỉ đưa đến cho họ một file vẫn cần sửa.

Với tính năng này, câu trả lời có thể thay đổi cả scope. Chốt trước rồi hỏi sau có nghĩa là team chấp nhận khả năng phải làm lại, dù bản đầu tiên được viết rất nhanh.

Chapter 02

Hỏi sớm hơn, và hỏi đúng phần đang vướng

Nếu tính năng báo cáo có khả năng được làm tiếp, PM nên bắt đầu tìm hiểu khi dev còn đang làm việc hiện tại. Chờ đến lúc cần đưa nó vào sprint mới đặt lịch với khách hàng thì rất dễ rơi vào cảnh đầu bài.

Điều đó không có nghĩa PM phải viết sẵn requirements cho vài tháng. Với mình, chuẩn bị trước có thể bắt đầu bằng một việc nhỏ hơn nhiều: xác định điều chưa biết nào sẽ ảnh hưởng đến lựa chọn của team, rồi tìm cách trả lời nó.

Với báo cáo hằng tuần, PM có thể nhờ khách hàng chia sẻ một file họ đã dùng gần đây và chỉ lại những bước phải làm trước khi gửi. Nếu chưa hẹn được, có thể xem lại yêu cầu hỗ trợ hoặc hỏi sales xem họ đã ghi nhận được phần nào. Những nguồn này có thể cung cấp manh mối, dù vẫn cần kiểm tra lại với người trực tiếp làm báo cáo.

Cuộc trao đổi cũng sẽ cụ thể hơn khi bắt đầu từ một file đã dùng thật. PM có thể hỏi vì sao khách hàng thêm cột này, xóa dòng kia, hoặc phải mở một công cụ khác để lấy thêm dữ liệu. Các thao tác ấy giúp team hiểu phần việc cần cải thiện.

Designer và dev nên cùng xem những thông tin đó. Chẳng hạn, designer có thể tìm hiểu cách sắp xếp báo cáo cho dễ dùng, còn dev kiểm tra dữ liệu cần thiết đã có trong hệ thống chưa. Nếu mọi việc đều phải qua PM hỏi, diễn giải rồi chuyển tiếp, PM vẫn sẽ bị quá tải dù viết tài liệu nhanh đến đâu.

Từ đây, team mới chọn cách thử phù hợp.

Nếu còn chưa rõ khách hàng cần những gì trong báo cáo, có thể dùng một file mẫu để trao đổi trước. Nếu đã hiểu nhu cầu và muốn kiểm tra chuyện gửi đúng lịch, một bản chạy giới hạn cho nhóm khách hàng đồng ý dùng thử có thể hữu ích hơn.

Trước khi bắt tay làm, team nên thống nhất muốn biết thêm điều gì qua lần thử này. Như vậy, sau khi có feedback, chúng mình mới biết nên sửa, làm tiếp hay dừng lại.

Chapter 03

Vậy chiều thứ Ba ấy, team làm gì?

Dù chuẩn bị sớm hơn, vẫn sẽ có lúc dev xong việc mà PM chưa có câu trả lời. Khách hàng có thể dời lịch, hoặc những người đã trao đổi lại có nhu cầu khác nhau khiến team cần tìm hiểu thêm.

Mình nghĩ lúc này PM cần nói rõ phần đang thiếu và cùng team thống nhất cách xử lý.

Trong ví dụ trên, thay vì chỉ báo “tính năng này chưa research xong”, PM có thể giải thích:

“Mình chưa biết khách hàng cần nhận file tự động hay cần sửa nội dung báo cáo. Chốt gửi email ngay thì có khả năng mình giải quyết nhầm bước. Thứ Sáu mình có lịch xem cách họ làm. Trước đó, mình và designer sẽ chuẩn bị file mẫu, nhờ dev kiểm tra giúp dữ liệu nào hiện đã lấy được.”

Thông tin ấy giúp dev biết vì sao chưa thể bắt đầu toàn bộ tính năng, đồng thời thấy phần nào có thể tham gia ngay. Việc kiểm tra dữ liệu cũng cần giới hạn, tránh biến thành một dự án xây sẵn hệ thống báo cáo khi nhu cầu còn chưa rõ.

Nếu không cần cả team tham gia, những người còn lại có thể chuyển sang công việc khác đã có lý do rõ ràng để ưu tiên. Nhưng PM cũng cần chấp nhận rằng không phải lúc nào sẽ có một tính năng mới sẵn sàng chỉ vì dev vừa xong việc.

Với những thay đổi nhỏ, dễ sửa lại và đã có bằng chứng tương đối rõ, team có thể thống nhất thử sớm rồi theo dõi. Nếu việc thử kéo theo nhiều công sức tích hợp, yêu cầu khách hàng thay đổi quy trình, hoặc khó thu hồi sau khi phát hành, cần tìm hiểu kỹ hơn trước khi cam kết.

Mức độ chắc chắn cần có phụ thuộc vào hậu quả nếu quyết định sai. Chúng mình khó áp dụng cùng một cách duyệt cho việc đổi vị trí nút tải báo cáo và việc tự động gửi dữ liệu đến nhiều người nhận.

Khi đã phát hành bản thử, lịch theo dõi cũng phải bám vào cách khách hàng làm việc. Nếu họ chỉ tổng hợp báo cáo vào thứ Sáu, team cần chờ đến lúc ấy để xem phần việc còn lại có bớt đi hay không. Trong thời gian đó, có thể tiếp tục những việc khác, nhưng chưa nên kết luận thành công chỉ vì email đã gửi được.

Đó cũng là điều PM cần trao đổi lại với người quản lý: phần triển khai có thể xong sớm, còn thời điểm đánh giá hiệu quả phụ thuộc vào lúc khách hàng thực sự sử dụng.

Lời nhắn

Nếu dev trong team đang làm nhanh hơn trước, PM sẽ cần điều chỉnh lịch tìm hiểu nhu cầu, cách chốt scope và cách phối hợp với mọi người. Giữ nguyên nhịp cũ rồi cố viết tài liệu nhanh hơn rất dễ khiến mình luôn ở trạng thái chạy theo.

Một việc có thể thử ngay là nhìn vào tính năng nhiều khả năng sẽ được làm tiếp. Có câu hỏi nào mà nếu khách hàng trả lời khác với dự đoán, team sẽ phải đổi hướng không? Nếu có, hãy bắt đầu tìm câu trả lời từ bây giờ, rủ cả designer và dev tham gia khi cần.

Đến lần tiếp theo dev hỏi “xong phần này rồi làm gì?”, PM sẽ có cơ sở để cùng team chọn việc tiếp theo, thay vì vội biến một ý tưởng trong backlog thành lời hứa phải giao.