Không biết code có làm Product Owner được không?

Không biết code có làm Product Owner được không?

Bạn vừa chuyển từ vận hành sang làm Product Owner (PO) cho ứng dụng bán hàng của một cửa hàng giả định. Trong buổi refinement đầu tiên, bạn đưa ra một yêu cầu từ bộ phận chăm sóc khách hàng: cho khách thêm ô ghi chú khi đặt đơn. Bạn nghĩ việc này chỉ mất một buổi chiều. Bạn dev phụ trách nói: “Cái này khoảng 8 điểm.”

Bạn buột miệng: “Thêm một ô thôi mà anh, sao nhiều vậy?” Phòng họp im lặng vài giây. Không ai giải thích thêm, và bạn ra về với cảm giác vừa nói sai điều gì đó mà không biết là gì.

Đây là tình huống minh họa. Câu trả lời ngắn cho câu hỏi ở tiêu đề là: được. Bạn không cần viết code để làm PO. Nhưng bạn cần đủ hiểu biết kỹ thuật để hỏi “8 điểm gồm những phần nào” thay vì “sao nhiều vậy”. Hai câu nghe gần giống nhau, nhưng một câu mở ra cuộc trao đổi, câu kia đóng nó lại.

Bài này nói về phần hiểu biết đó: những khái niệm nên nắm, vì sao một thay đổi “nhỏ thôi” có thể không nhỏ, vì sao ước lượng luôn có phần chưa chắc, và cách hỏi để dev thấy bạn đang cùng giải bài toán chứ không phải đang soi họ.

Vì sao làm việc với dev khó khi không biết code?

Khó không phải vì bạn kém. Có ba lý do dễ gặp, và gọi tên được chúng giúp bạn biết phải bù vào chỗ nào.

• Bạn chỉ thấy phần nổi. Bạn nhìn thấy màn hình, còn dev nhìn thấy dữ liệu, các hệ thống nối với nhau và những chỗ code cũ dễ vỡ. Cùng một thay đổi, hai người thấy hai kích thước khác nhau.
• Hai bên nói hai thứ tiếng. Bạn nói bằng người dùng và kết quả kinh doanh, dev nói bằng API, bảng dữ liệu và môi trường. Không ai sai, nhưng nếu không có từ chung thì cuộc họp dễ thành hai người nói song song.
• Bạn không biết mình nên đứng ở đâu. Có người mới ngại hỏi vì sợ bị coi là không hiểu gì. Có người lại đi quá tay, bảo dev nên làm thế nào. Cả hai đều làm hỏng quan hệ làm việc.

Scrum Guide 2020 vạch ranh giới khá rõ. Developers là những người trong Scrum Team cam kết tạo ra Increment dùng được mỗi Sprint. Từ này không chỉ là người viết code: tester hay designer làm ra sản phẩm cũng là Developers. Scrum Guide nói việc biến một hạng mục backlog thành Increment thế nào là do Developers tự quyết, và chính những người sẽ làm việc là người chịu trách nhiệm ước lượng kích thước.

Còn PO chịu trách nhiệm tối đa hóa giá trị của sản phẩm và giữ cho Product Backlog minh bạch, dễ thấy và được hiểu. Nghĩa là phần của bạn là “làm gì, cho ai, vì sao, trước hay sau”. Phần “làm thế nào” là của Developers. Hiểu biết kỹ thuật không phải để bạn giành phần đó, mà để hai phần khớp được với nhau.

PO cần hiểu kỹ thuật đến mức nào?

Ở mức khái niệm là đủ để bắt đầu. Bạn cần biết mỗi thứ là gì và nó ảnh hưởng tới chi phí, thời gian, rủi ro ra sao. Bạn không cần biết cách viết nó. Bảng dưới gồm mười từ bạn dễ nghe trong tuần đầu, giải thích bằng lời thường.

Nếu bạn muốn tự xem số liệu thay vì chờ người khác kéo giúp, bài SQL cho người mới bắt đầu là bước tiếp theo hợp lý. Biết đọc một bảng dữ liệu giúp câu hỏi “dữ liệu cũ xử lý thế nào” trở nên cụ thể hơn nhiều.

• SQL cho Product Owner mới bắt đầu

Vì sao thay đổi “nhỏ thôi” có thể không nhỏ?

Quay lại ô ghi chú. Trên màn hình, đó là một ô nhập chữ. Bên dưới, nó có thể chạm tới rất nhiều chỗ:

• Database cần thêm chỗ lưu ghi chú, và phải quyết với các đơn cũ thì để trống hay làm gì.
• API đặt đơn phải nhận thêm dữ liệu mới, kiểm tra độ dài, chặn ký tự lạ.
• Ứng dụng di động bản cũ trên máy khách chưa cập nhật vẫn gửi đơn theo kiểu cũ, nên hệ thống phải chịu được cả hai kiểu.
• Nhân viên kho cần thấy ghi chú ở màn hình quản trị, có thể cả trên phiếu in kèm hàng.
• Nếu phiếu in do đơn vị vận chuyển tạo, việc thêm ghi chú phụ thuộc vào việc họ có nhận thêm trường mới hay không.

Ngoài ra còn nợ kỹ thuật. Martin Fowler mô tả nó bằng hình ảnh khoản vay: những chỗ chưa gọn trong hệ thống khiến mỗi tính năng mới tốn thêm công, phần tốn thêm đó giống như tiền lãi. Nếu phần đặt đơn đang có nợ, một thay đổi trông nhỏ vẫn phải trả lãi. Fowler cũng gợi ý trả dần nợ ở những phần code hay phải sửa, vì đó là nơi lãi bị trả nhiều nhất.

Vì vậy, khi một con số làm bạn bất ngờ, đừng xem đó là dấu hiệu dev làm chậm. Xem đó là tín hiệu có phần chìm bạn chưa thấy, và hỏi để thấy nó.

Vì sao ước lượng của dev không chắc chắn?

Mountain Goat Software giải thích story point là con số cho công sức, trong đó độ phức tạp, rủi ro và phần chưa chắc phải được gộp vào một thước đo. Một việc làm nhiều lần rồi và một việc phải nối với hệ thống chưa ai đụng tới có thể ra cùng một con số, nhưng độ chắc chắn rất khác.

Có những điều chỉ lộ ra khi bắt tay làm: một hàm cũ không ai nhớ ai viết, một bên thứ ba trả lời chậm, một trường hợp dữ liệu lạ. Đó là lý do ước lượng là dự đoán để lập kế hoạch, không phải lời hứa. Ép dev giảm con số không làm việc nhỏ đi. Nó chỉ làm kế hoạch kém trung thực hơn.

Việc của bạn không phải là cãi con số, mà là hiểu nó gồm những gì, phần nào chắc, phần nào chưa, và có cách nào để giảm phần chưa chắc trước khi cam kết với người khác.

Cách làm việc với dev khi không biết code: bốn bước

Một cách làm dễ áp dụng là đi qua bốn bước dưới đây với mỗi hạng mục quan trọng. Nhiều phần của việc này diễn ra trong refinement, nơi team chia nhỏ và làm rõ các hạng mục backlog trước khi đưa vào Sprint.

Bước 1: mang vấn đề, không mang giải pháp. Thay vì “thêm ô ghi chú”, hãy nói “khách cần dặn kho những điều như giao giờ hành chính, và hiện họ đang gọi tổng đài để dặn”. Khi dev biết vấn đề, họ có thể đề xuất cách rẻ hơn mà bạn không nghĩ tới. Bạn vẫn có thể kể giải pháp người yêu cầu đề xuất, miễn là nói rõ đó là một phương án, không phải yêu cầu cứng.

Bước 2: hỏi để hiểu, không để quyết thay. Câu hỏi tốt giúp bạn thấy phần chìm: con số gồm những phần nào, phần nào chưa chắc nhất, có gì phụ thuộc vào bên ngoài, ảnh hưởng tới dữ liệu cũ ra sao. Tránh câu hỏi đã chứa sẵn cách làm, kiểu “sao không thêm một cột là xong”.

Bước 3: cùng chọn đánh đổi. Khi đã thấy phần chìm, hỏi xem có bản nhỏ hơn nào vẫn giải được vấn đề chính không. Developers nói chi phí và rủi ro của từng phương án. Bạn quyết phương án nào có giá trị hơn và xếp thứ tự. Khi mang các phương án tới stakeholder, nói rõ chi phí của từng cái.

Bước 4: chốt rồi để team làm. Ghi lại quyết định ngay trong hạng mục backlog. Sau đó bảo vệ thời gian tập trung của team: gom câu hỏi vào một tin nhắn hoặc một khung giờ thay vì nhắn lẻ suốt ngày, và không hỏi “xong chưa” mỗi vài giờ. Khi có yêu cầu mới chen vào giữa chừng, đừng chuyển thẳng cho dev mà xử lý theo cách trong bài về yêu cầu thay đổi giữa Sprint. Đây là gợi ý của bài viết, không phải quy định của Scrum.

• Backlog refinement hiệu quả
• Yêu cầu thay đổi giữa Sprint

Nên hỏi dev những câu gì?

Cách nói quyết định khá nhiều. Bảng dưới đặt những câu dễ buột miệng cạnh những câu mở ra trao đổi.

Ngoài ra, đây là những câu đáng giữ sẵn cho mọi cuộc trao đổi kỹ thuật:

• Có bản nhỏ hơn nào vẫn giải được phần chính của vấn đề không?
• Việc này phụ thuộc vào hệ thống hay đội nào khác?
• Dữ liệu cũ sẽ ra sao sau thay đổi này?
• Nếu có lỗi sau khi ra mắt, mình phát hiện và quay lại bản cũ thế nào?
• Có nợ kỹ thuật nào ở khu vực này đáng xử lý cùng lúc không, và nó tốn thêm bao nhiêu?
• Bạn cần gì từ mình để làm rõ phần chưa chắc: dữ liệu, quyết định, hay một người để hỏi?

Ví dụ: hỏi về một ước lượng 8 điểm

Quay lại ô ghi chú. Đây là cuộc trao đổi minh họa, diễn ra lại theo bốn bước ở trên.

Để ý những gì PO không làm. PO không cãi con số 8, không gợi ý cách lưu dữ liệu, không hứa ngày với ai trước khi hỏi. PO chỉ hỏi con số gồm gì, phần nào chưa chắc, và đề xuất một bản nhỏ hơn bám vào vấn đề gốc. Ước lượng 3 điểm vẫn là con số của dev.

Khi trả lời bộ phận chăm sóc khách hàng, PO nêu hai phương án kèm chi phí. Làm đủ cả phiếu in: khoảng 8 điểm, còn phụ thuộc bên vận chuyển chưa có câu trả lời. Làm bản màn hình quản trị trước: khoảng 3 điểm, đổi lại nhân viên kho phải mở màn hình để đọc ghi chú thay vì đọc trên phiếu. Bên yêu cầu chọn được khi thấy rõ cái giá của mỗi lựa chọn.

Mẫu câu hỏi cho một buổi trao đổi kỹ thuật

Bạn copy mẫu dưới vào ghi chú cuộc họp hoặc phần mô tả của hạng mục backlog. Không cần hỏi đủ mọi câu. Chọn những câu hợp với việc đang bàn.

TRƯỚC BUỔI TRAO ĐỔI
[ ] Vấn đề viết được trong một câu: ai gặp chuyện gì, hiện đang xoay xở thế nào.
[ ] Kết quả cần đạt: làm xong thì điều gì thay đổi.
[ ] Giải pháp người yêu cầu đề xuất (nếu có) ghi là một phương án, không phải yêu cầu cứng.
[ ] Hạn chót thật (nếu có) và lý do.

TRONG BUỔI TRAO ĐỔI
[ ] Thay đổi này chạm tới những phần nào của hệ thống?
[ ] Ước lượng gồm những phần nào? Phần nào chưa chắc nhất?
[ ] Có phụ thuộc vào hệ thống, đội hay bên ngoài nào không?
[ ] Dữ liệu cũ sẽ ra sao?
[ ] Có bản nhỏ hơn nào vẫn giải được phần chính của vấn đề? Bản đó tốn khoảng bao nhiêu?
[ ] Có nợ kỹ thuật nào ở đây đáng xử lý cùng lúc? Tốn thêm bao nhiêu?
[ ] Nếu lỗi sau khi ra mắt, phát hiện và quay lại bản cũ thế nào?
[ ] Cần làm rõ gì trước khi chốt? Ai làm, xong khi nào?

SAU BUỔI TRAO ĐỔI
[ ] Ghi phương án đã chọn và phần chưa làm lần này vào hạng mục backlog.
[ ] Ghi chi phí của từng phương án để báo lại bên yêu cầu.
[ ] Gom câu hỏi còn lại vào một tin nhắn, không nhắn lẻ.

Câu “cần làm rõ gì trước khi chốt” là câu dễ bị bỏ qua. Nếu không hỏi, phần chưa chắc vẫn nằm đó và lộ ra giữa Sprint, đúng lúc khó xoay xở nhất.

Lỗi người mới dễ mắc khi làm việc với dev

• Nói “nhỏ thôi mà”. Bạn đang đánh giá kích thước một việc mà bạn chỉ thấy phần nổi. Hỏi con số gồm gì thay vì phán nó to hay nhỏ.
• Bảo dev cách làm. Đề xuất “thêm một cột” hay “dùng lại màn hình kia” là bước vào phần của Developers. Mô tả vấn đề và kết quả, để họ chọn cách.
• Coi ước lượng là cam kết. Hứa ngày với stakeholder dựa trên con số đầu tiên, rồi ép team theo. Nói rõ với stakeholder đâu là dự đoán, đâu là phần chưa chắc.
• Gật đầu khi không hiểu. Giả vờ hiểu một thuật ngữ thì lần sau bạn vẫn không hỏi được câu đúng. Nói thẳng “em chưa rõ phần này, anh giải thích giúp em ở mức khái niệm nhé” là bình thường.
• Giấu bối cảnh kinh doanh. Chỉ đưa yêu cầu mà không nói vì sao làm dev mất cơ hội đề xuất cách tốt hơn.
• Nhắn lẻ cả ngày. Mỗi tin nhắn cắt ngang một khoảng tập trung. Gom câu hỏi lại, trừ khi thật sự gấp.
• Coi nợ kỹ thuật là việc riêng của dev. Nợ làm chậm chính những tính năng bạn muốn ra. Hỏi nó tốn bao nhiêu và đặt việc trả nợ lên bàn cân ưu tiên cùng những việc khác.

Tóm tắt

• Không biết code vẫn làm PO được. Bạn cần đủ hiểu biết kỹ thuật ở mức khái niệm để hỏi đúng câu và hiểu câu trả lời.
• PO lo làm gì, cho ai, vì sao và thứ tự ưu tiên. Developers quyết cách làm và ước lượng kích thước.
• Một thay đổi “nhỏ thôi” có thể chạm tới database, API, app bản cũ, bên thứ ba và nợ kỹ thuật. Hỏi để thấy phần chìm.
• Ước lượng là dự đoán gộp cả rủi ro và phần chưa biết. Giảm phạm vi thay vì ép con số.
• Bốn bước: mang vấn đề, hỏi để hiểu, cùng chọn đánh đổi kèm chi phí, chốt rồi bảo vệ giờ tập trung của team.

Mình đang soạn thêm các tình huống PO khác theo cùng khung này, kèm mẫu dùng ngay. Nếu bạn muốn nhận khi có bài mới, đăng ký bản tin bên dưới.

• Nhận bài mới qua email

Câu hỏi thường gặp

Không biết code có làm Product Owner được không?

Được. Scrum Guide giao việc quyết cách biến một hạng mục backlog thành sản phẩm cho Developers, còn PO lo giá trị và thứ tự ưu tiên. Điều PO cần là đủ hiểu biết kỹ thuật để hỏi đúng câu và hiểu câu trả lời.

PO cần biết những khái niệm kỹ thuật nào?

Ở mức khái niệm là đủ để bắt đầu: frontend, backend, API, database, môi trường thử nghiệm, deploy, nợ kỹ thuật và ước lượng. Bạn cần hiểu chúng ảnh hưởng thế nào tới chi phí và rủi ro, không cần biết cách viết chúng.

Vì sao dev không ước lượng chính xác được?

Vì ước lượng gộp cả khối lượng việc, độ phức tạp, rủi ro và những điều chưa biết vào một con số. Phần chưa biết chỉ lộ ra khi bắt tay làm, nên ước lượng là dự đoán để lập kế hoạch, không phải lời hứa.

Nguồn kiểm tra

• Scrum Guide 2020: Developers, Sprint Planning, Product Backlog
• Martin Fowler: Technical Debt
• Mountain Goat Software: What Are Story Points?

Bài liên quan

• PO, PM và BA khác nhau thế nào? Đọc JD để biết vai trò thật: Phân biệt PO, PM và BA theo trách nhiệm thật, cách ranh giới thay đổi theo từng loại công ty ở Việt Nam, và cách đọc tin tuyển dụng để biết vị trí đó thực chất là gì.
• 30 ngày đầu làm Product Owner: mỗi tuần nên làm gì?: Kế hoạch bốn tuần cho PO mới: nghe và vẽ bản đồ, hiểu người dùng và số liệu, nhận một phần backlog nhỏ, rồi ra quyết định đầu tiên và chốt kỳ vọng với quản lý.
• Chuyển từ BA, QA, dev sang Product Owner: cần học thêm gì?: Thế mạnh nào của BA, QA và dev mang sang PO được, điểm mù nào cần để ý, và cách tích kinh nghiệm PO ngay trong công việc hiện tại.
• Câu hỏi phỏng vấn Product Owner: trả lời bằng tình huống: Các nhóm câu hỏi khi phỏng vấn vị trí PO, cách trả lời bằng một tình huống cụ thể, cách xử lý câu không biết và những câu nên hỏi lại nhà tuyển dụng.