Làm PO mà chưa từng xử lý task gấp thì xem khiếm khuyết trải nghiệm, vì chỉ cần user còn thức thì vẫn có rủi ro phát sinh issue trên production. Đó là nhóm task “gấp” kiểu chính ngạch, nhưng còn những kiểu tiểu ngạch thì muôn hình vạn trạng, chỉ có thể ứng phó bằng việc liên tục rèn tính dẻo tính não và tính điềm đạm của tác phong.
Chính ngạch
Issue trên production (hay vấn đề phát sinh trong quá trình vận hành sản phẩm) là điều mà tất cả các team đều không mong đối mặt, nhất là với những sản phẩm đã phát triển đến giai đoạn có hàng triệu MAU (user hoạt động hàng tháng). Nhưng bug không chừa một ai, ngay cả những công ty lớn như Facebook, Amazon, Apple, Netflix hay Google (FAANG) cũng từng lao đao vì downtime.
Vậy khi issue xảy ra, PO làm gì? Với incidents (issue lớn và ảnh hưởng đến gần như toàn bộ users), thông thường, Dev sẽ là team phát hiện đầu tiên, nhờ vào hệ thống giám sát (charts, grafana, alerts…). Trong một quy trình lý tưởng, Dev sẽ thông báo cho PO/PM, và từ đó PO/PM trở thành “người phát ngôn” với stakeholder: cập nhật tình hình, mô tả sơ bộ phạm vi ảnh hưởng, ước tính thời gian khắc phục. Với Dev, PO giống như “gatekeeper”: giữ cho team có không gian tập trung fix issue, thay vì bị xao nhãng bởi loạt câu hỏi dồn dập từ nhiều phía.
Còn ở các công ty Py từng làm việc thì thường sẽ có group chung của toàn dự án, nên khi có incident, phía Dev sẽ thông báo ở đây để các teams đều nắm. Không tham gia vào việc truyền thanh, nhưng trách nhiệm của PO vẫn còn đó, vẫn phải theo sát tiến độ fix issue, define những logic cần thiết, make decisions nếu cần trade off gì đó (ví dụ cần off 1 tính năng phụ, thay đổi UX content…). Thật ra, vai trò của PO sẽ càng thể hiện rõ trong các tình huống xử lý sự cố “bình thường” — chẳng hạn như những bug tồn tại lâu nhưng chưa truy được nguyên nhân, hay các “tính năng ẩn” mà user bất ngờ khám phá và gây ảnh hưởng đến performance hoặc trải nghiệm chung…
Vậy PO cần làm gì để ứng phó tốt hơn với production issue? Cách thiết thực và bền nhất vẫn là hiểu rõ về sản phẩm của mình. Không chỉ dừng ở luồng tính năng hay giao diện, mà còn là logic vận hành, các điểm tích hợp, những “nút thắt” dễ gây rủi ro. Khi đã có nền tảng hiểu biết này, PO sẽ bình tĩnh hơn trước mọi tình huống: biết hỏi đúng câu hỏi với Dev, biết giải thích đủ cho stakeholder, và quan trọng hơn hết là không bị cuốn theo cảm giác hoảng loạn khi gặp sự cố. Việc hiểu này là kết quả của cả một quá trình dài, thậm chí có phần thách thức hơn đối với các sản phẩm đã có thâm niên phát triển (ví dụ như hệ thống payment, promotion của các ví điện tử). Nhưng con người sẽ có xu hướng sợ những gì mình chưa biết, thế nên biết càng nhiều càng tốt vẫn luôn là liều vaccine hiệu quả.
Trong những năm qua, cũng có vài đoạn team Py liên tục phải xử lý issues, từ những lần đầu bỡ ngỡ đến kế hoạch hoàn thiện hơn cho những rủi ro không lường trước. Ví dụ giữa những cơn bão, cả team dự án, gồm stakeholder, PO, Dev, cùng ngồi lại để đồng thuận về mức độ ảnh hưởng và phương án tương ứng. Chẳng hạn, nếu ảnh hưởng <50% users và khôi phục trong 4 tiếng thì chỉ cần off một vài entry points để giảm traffic (lượng người dùng truy cập và tính năng), còn nếu ảnh hưởng 100% user và đã qua 4 tiếng nhưng chưa khắc phục được thì off hoàn toàn.
Nhìn chung, xử lý nhóm chính ngạch này cần hiểu biết và kinh nghiệm, nên ngoài cách kiên nhẫn tích lũy thì Py cũng chưa có gợi ý nào đó khả thi hơn.
Tiểu ngạch
Nhóm này thì gần như không có cơ sở để phân chia thành các nhóm nhỏ hơn, nên Py sẽ tóm tắt từ những gì Py quan sát trong mấy năm vừa rồi (từ các công ty/nhóm Py tham gia).
“Gấp” vì sếp, nói chung là sếp muốn làm liền có liền. Những yêu cầu này không chỉ gấp mà đôi khi còn không rõ ràng. Nhiều trường hợp, game sẽ được tăng thêm độ khó nếu PO không phải là người tiếp nhận trực tiếp, vì như việc clear requirement sẽ càng gian nan hơn. Dĩ nhiên, yêu cầu của sếp, không thể không làm, mà hãy làm trong tâm thế “change to change” và hướng đến outcomes cụ thể. Vì nhìn chung, những request gấp từ sếp thường để giải quyết ngay một điểm đau nào đó, nên cố gắng tập trung đúng điểm đau là được. Đồng thời, sếp cần thấy kết quả ngay (có thể để tiếp tục make decisions nào đó) nên việc cần ưu tiên là tốc độ, khoan hãy tính đến ổn định. Khi đã đáp ứng yêu cầu khẩn cấp thì mới đến lúc tìm cách nào đó tối ưu hơn để đảm bảo việc vận hành đường dài. Còn làm thế nào để trong thời gian ngắn đưa ra được solution có thể làm ngay, ít ảnh hưởng đến các luồng đang chạy và hạn chế phát sinh issue thì phụ thuộc nhiều vào mức độ lành nghề của PO.
“Gấp” vì bị “bỏ quên”, thường gặp nhất là ở những công ty có cấu trúc sản phẩm phức tạp, một tính năng có thể liên quan đến nhiều hệ thống khác nhau. PO của các sản phẩm mang tính platform hẳn sẽ cảm thấy quen thuộc với việc này, ví dụ như CRM hay CS Tech nói chung. Thậm chí, tình hình sẽ căng thẳng hơn nếu task “gấp” là blocker duy nhất để release tính năng theo đúng timeline truyền thông. Làm, là điều bắt buộc, và quan trọng hơn là cần làm đến đâu. Lúc này PO sẽ cần define thật rõ SoW sẽ nhận của task gấp đó, tránh overcommit, đồng thời, cần chuẩn bị sẵn các phương án khác cho các use cases chưa kịp làm trong đợt release gần nhất. Hơn nữa, những nội dung này cần trao đổi kỹ với requesters để cùng nhau xử lý task “gấp”.
“Gấp” vì bug, châm (biếm) ngôn ở đây là: bug không tự sinh ra cũng không tự mất đi, chỉ đợi đến sát giờ release mới xuất hiện. Và trong các kiểu “gấp”, chắc loại này là loại dễ phòng ngừa nhất, nhưng cũng đồng thời là loại khó chịu nhất. Những lúc như vậy, PO phải càng lạnh càng tốt, để xác định xem phạm vi ảnh hưởng của con bug này thế nào, phá hoại hết mùa vụ hay chỉ là phần nhỏ của cánh đồng. Vì đôi khi chấp nhận một tính năng vừa đủ để release rồi tiếp tục hoàn thiện vẫn tốt hơn ngâm hết công sức ở môi trường test. Tuy nhiên, tần suất kiểu “gấp” này càng nhiều, càng cho thấy scrum team hoạt động không hiệu quả và cần có nhiều biện pháp hơn để cải thiện năng suất chung, thậm chí đôi khi phải có chế tài cụ thể.
Task “gấp” là sự việc chỉ có thể gặp, không thể cưỡng, cũng giống như nhiều sự “bất như ý” trong cuộc sống. Thế nên, cứ bình thản mà đối diện, xem nó nhưng một nét đặc trưng của nghề, một cái giá bắt buộc phải trả khi chọn làm việc trong thế giới công nghệ. Hoặc nếu bạn muốn biết thêm “khung cảnh” của các teams khi liên tục xử lý issues sẽ như thế nào thì recommend bạn tham khảo qua quyển “Dự án phượng hoàng” của các tác giả Gene Kim, Kevin Behr và George Spafford. Với Py, đây là “bản ghi” chân thực một cách nghệ thuật về những gì diễn ra ở phòng ban Công nghệ thông tin, có tranh cãi, có cảm xúc và có những quyết định phải quyết liệt thực hiện.
Cám ơn bạn đã nán lại cho đến những dòng cuối cùng này.
Chúc bạn nhiều may mắn và bình an.
Anpy
Leave a Reply