Business analysis cho đội sản phẩm

12 câu rút từ các phần của chuỗi. Trả lời ở đây cũng được tính cho quiz của từng bài.

1. Câu 1/12·Trung cấpKhách hàng nói "làm cho bọn chị một app mobile để giám đốc duyệt hoá đơn". Cách tiếp cận nào phù hợp nhất với quan điểm "yêu cầu là giả thuyết"?

   Ghi nhận đúng như lời khách hàng và bắt đầu estimate, vì khách hàng hiểu việc của họ nhấtTừ chối yêu cầu vì khách hàng đang mô tả giải pháp thay vì vấn đềCoi "app mobile giúp duyệt nhanh hơn" là một giả thuyết, tìm hiểu vấn đề phía sau và kiểm chứng (ví dụ đo xem thời gian chờ nằm ở bước nào) trước khi viết codeLàm nhanh một bản app mobile rồi chờ phản hồi từ khách hàng để biết yêu cầu thật
2. Câu 2/12·Trung cấpVì sao nên bổ sung shadowing (ngồi cạnh người làm việc thật) thay vì chỉ phỏng vấn?

   Vì phỏng vấn tốn thời gian hơn shadowingVì người được phỏng vấn thường cố tình nói sai sự thật để che giấu vấn đềVì shadowing cho ra danh sách yêu cầu đầy đủ nên không cần các kỹ thuật khácVì khi kể lại người ta mô tả phiên bản lý tưởng, còn khi làm trước mặt bạn thì lộ ra workaround, thời gian chờ thật và những ngắt quãng
3. Câu 3/12·Cơ bảnTheo mô hình 3C, phần nào của user story mang lại nhiều giá trị nhất, và vì sao một template As a / I want / so that cầu kỳ vẫn chưa đủ?

   Card, vì template viết càng chi tiết thì càng ít hiểu nhầm giữa PO, dev và testerConversation, vì requirement thật xuất hiện khi PO/BA, dev và tester cùng ngồi lại; template chỉ là cái vỏConfirmation, vì chỉ cần acceptance criteria đủ dài là không cần nói chuyện nữaCard, vì thẻ là thứ duy nhất được lưu lại sau khi story đã vào sprint
4. Câu 4/12·Trung cấpTeam muốn làm hoàn hảo "tìm đơn hàng" (tìm kiếm, bộ lọc, tra cứu cho khách vãng lai) trước, rồi mới làm hoàn tiền. Theo bài, vì sao đây là hướng sai?

   Vì tìm đơn hàng là việc của team backend nên không nên đưa vào story của người dùngVì story quá nhỏ không ước lượng được nên cần chuyển thành spikeVì làm tuần tự từng tính năng luôn chậm hơn làm song song nhiều ngườiVì ship một cột dọc hoàn hảo mà chưa ai hoàn được tiền thì đốt nhiều sprint mà không có gì đưa cho người dùng; nên ship một lát ngang mỏng (walking skeleton) đi trọn hành trình
5. Câu 5/12·Trung cấpMột quy trình tách hai nhánh bằng parallel (AND) gateway nhưng gộp lại bằng exclusive (XOR) gateway. Hệ quả là gì?

   Quy trình treo mãi vì XOR chờ một nhánh không bao giờ tớiKhông có gì xảy ra, vì hai loại gateway tương đương khi gộpMọi bước sau điểm gộp chạy hai lần, ví dụ gửi hai PO cho nhà cung cấpChỉ nhánh nhanh hơn được thực thi, nhánh còn lại bị huỷ
6. Câu 6/12·Trung cấpCông ty cho rằng giám đốc ký chậm là nguyên nhân mua hàng mất hai tuần, và định làm app duyệt trên điện thoại. Phân tích as-is trong bài cho thấy điều gì?

   Phần của giám đốc nhỏ; các khoảng chờ lớn hơn nằm ở vòng làm lại, gom lô của kế toán và email chuyển tiếp bị quên, nên app đó giải quyết sai vấn đềGiám đốc đúng là nút thắt chính nhưng app không giúp được vì ông hay đi công tácMọi bước đều chậm như nhau nên cần tăng tốc từng người làm việcQuy trình trên giấy ISO đã đúng, vấn đề chỉ nằm ở việc nhân viên không tuân thủ
7. Câu 7/12·Cơ bảnTrong Event Storming, điểm khác biệt cốt lõi giữa command và domain event là gì?

   Command do người dùng tạo ra còn event do hệ thống tạo ra, ngoài ra giống nhauEvent là ý định có thể bị từ chối, còn command là sự thật đã xảy raCommand là ý định và có thể bị từ chối, còn event là sự thật đã xảy ra nên không bao giờ bị từ chốiCommand viết ở thì quá khứ để dễ đọc, event viết ở dạng mệnh lệnh
8. Câu 8/12·Trung cấpMột team dev muốn nhảy thẳng vào design level vì "gần code" và chỉ làm một module. Rủi ro chính mà bài nêu là gì?

   Sticky note ở design level không dùng được nếu chưa có chú giải màuHọ có thể thiết kế rất đẹp cho một mô hình nghiệp vụ sai, bỏ sót những quy trình như khám theo gói doanh nghiệp mà big picture sẽ lộ raDesign level chỉ chạy được khi có từ 12 người trở lên tham giaAggregate sẽ bị tách quá nhỏ vì chưa có pivotal event
9. Câu 9/12·Cơ bảnTrong phần mở đầu của PRD, câu nào là một vấn đề (problem) đúng nghĩa thay vì một giải pháp?

   "Chúng ta cần gửi nhắc lịch qua Zalo cho bệnh nhân""Tỷ lệ bệnh nhân không đến với lịch đặt online cao gấp đôi lịch đặt qua điện thoại, và lễ tân mất hai giờ mỗi chiều gọi điện nhắc lịch""Ra mắt tính năng nhắc lịch trước quý sau""Hệ thống phải nhắc lịch nhanh và thân thiện với bệnh nhân"
10. Câu 10/12·Trung cấpVì sao NFR hiệu năng nên viết theo percentile (như p95) thay vì thời gian phản hồi trung bình?

    Vì percentile dễ tính hơn trung bình khi có ít requestVì trung bình không đo được ở server, chỉ percentile mới đo đượcVì p95 luôn thấp hơn trung bình nên dễ đạt SLA hơnVì trung bình giấu đuôi dài: 95% request 100ms và 5% request 4 giây cho trung bình khoảng 300ms trông ổn, nhưng một trong hai mươi người dùng đang chờ 4 giây
11. Câu 11/12·Trung cấpĐịnh nghĩa conversion kiểu "số đơn trong tuần này chia số lượt checkout trong tuần này" gặp vấn đề gì, và cách sửa nào đúng theo bài?

    Không có vấn đề, chỉ cần đổi sang đếm theo session để tử số luôn nhỏ hơn mẫu sốTử số và mẫu số là hai tập người khác nhau; cần gắn cửa sổ thời gian vào thời điểm checkout của chính từng ngườiCần dùng tuần bắt đầu từ Chủ nhật để tử số và mẫu số khớp với lịch của team marketingChỉ cần loại người dùng nội bộ, vì họ là nguyên nhân làm tử số lớn hơn mẫu số
12. Câu 12/12·Trung cấpDashboard dùng occurred_at::date trên timestamptz và connection BI để UTC. Hệ quả với một sàn ở Việt Nam là gì?

    Các đơn từ nửa đêm đến trước 7 giờ sáng giờ Việt Nam bị tính vào ngày hôm trước, làm biểu đồ theo ngày lệch có hệ thốngQuery báo lỗi vì không thể ép timestamptz sang dateChỉ các đơn đặt trong giờ mùa hè mới bị lệch, vì UTC không có DSTSố liệu vẫn đúng vì timestamptz luôn lưu và hiển thị theo giờ địa phương của người đặt hàng