"Sao các bạn không báo cáo cho chúng tôi về bug này? Đây là lỗi nghiêm trọng, chức năng hoàn toàn chưa chạy được!
Đáng ra các bạn nên báo cáo cho chúng tôi trước, sẽ không tốn thời gian của tất cả mọi người đang ngồi đây. Tôi cũng sẽ báo lên kịp với cấp trên của mình về tiến độ dự án....."
Giọng khách hàng thể hiện sự thất vọng sau một buổi demo thất bại toàn tập. Buổi demo đã kết thúc, cuộc họp khẩn cấp giải trình lý do demo thất bại cũng đã xong từ lâu. Còn mình, vẫn ngồi bần thần ra sau đấy, nhấm nháp cảm giác của sự thất bại.........
Hello, lại là mình, Thương đây.
Hôm nay blog của mình quay trở lại với bài viết chủ đề demo sản phẩm. Demo, viết đầy đủ là demonstration, là bước được thực hiện sau khi đội phát triển hoàn thành xây dựng được một danh sách chức năng. Đây là bước mà dự án sẽ chạy thử phần mềm trong cuộc họp với khách hàng, để thấy được yêu cầu của khách hàng đã được đưa lên hệ thống như thế nào.
Tuỳ từng dự án, người thực hiện Demo có thể là tester, dev, PM hay BA. Trong một dự án, mình được đảm nhiệm task Demo này, đây là quãng thời gian mình thực hiện demo liên tục, cứ 2 tuần cho 1 buổi demo sản phẩm và 1 buổi internal demo, mỗi buổi kéo dài 2 tiếng.
Trong dự án khác nữa, mình cũng có cơ hội được tham dự demo, với tư cách là khách hàng, hiểu cảm giác khi được tiếp nhận nội dung demo sẽ thế nào. Bởi vậy bài viết này ra đời nhằm tổng hợp lại kinh nghiệm qua những buổi demo, có những buổi thành công và có những buổi thất bại (như đoạn mở đầu nè) mà mình đã trải qua.
Hãy cùng đi qua 5 điểm cần lưu ý khi thực hiện demo sản phẩm nhé!
1. Chuẩn bị kỹ demo scenario: Đây là bước giúp bạn định hình những gì sẽ thực hiện trong buổi demo. Demo scenario cần bao gồm các flow chính, đảm bảo thể hiện được mục đích business của chức năng. Nếu tài liệu về chức năng khách hàng gửi đến có mục Acceptance Criteria, có thể căn cứ mục này để viết demo scenario.
Tại thời điểm demo, khách hàng vẫn chưa được tiếp xúc với hệ thống vừa xây dựng, do vậy, để khách hàng có thể hiểu và dễ dàng tiếp nhận nội dung demo, BA cần viết demo scenario theo hướng nghiệp vụ business khách hàng, và cho khách hàng thấy nghiệp vụ đó đang được đáp ứng trên hệ thống ra sao. Các dữ liệu được dùng cho demo cũng cần mang tính thực tế và quen thuộc với khách hàng.
2. Nhờ tester verify hệ thống trước: Thời gian kể từ lúc dev hoàn thành chức năng đến lúc sẵn sàng demo sẽ là quãng thời gian bận rộn của tester và BA. Các chức năng này sẽ được tester kiểm thử đi kiểm thử lại để đảm bảo hoạt động đúng như yêu cầu.
BA có thể hoàn thành demo scenario và nhờ tester chạy trước trong quá trình kiểm thử. Nhờ vậy, tester đã kiểm tra trước và đảm bảo các chức năng chạy tốt trước khi BA bắt đầu thực hiện test. Thời gian test của BA sẽ giảm xuống rất nhiều.
Việc nhờ test verify hệ thống trước này cần thảo luận trước với đội dự án nhằm đảm bảo tester có effort để thực hiện.
3. Hãy chắc chắn main flow chạy ổn định trước khi demo: Có một lời nguyền thế này: các chức năng dev làm xong luôn chạy ok, đến tay tester verify phát hiện lỗi đã fix, BA đã test lại cũng ok nốt, nhưng cứ đúng lúc demo kiểu gì cũng .... die.
Ở case mở đầu bài, mình từng demo thất bại, nguyên nhân là function khi test có chạy ok, nhưng cũng có lúc có bug (lỗi). Nhưng bug này khá ảo ma, chỉ nhìn thấy 1 lần duy nhất, sau đó test lại không còn bug nữa, nên mình ok, cho qua, đến lúc demo thì bạn bug lại chạy đến chơi. Thế là thôi xong.
Trong trường hợp này, cần báo lại ngay cho PM, về khả năng có thể xảy ra bug, để PM quyết định có thông báo cho khách hàng có demo nữa hay không nhé.
4. Tập trung vào những điểm đã đạt được trong buổi demo: Tại thời điểm demo khách hàng, việc có bug là điều không tránh khỏi (tất nhiên những bug này cần đủ nhỏ để không block luồng). Là BA, cũng không thể che giấu bug trước khách hàng khi chạy demo.
Tuy nhiên, để khách hàng có cảm giác tốt về sản phẩm mà dự án làm ra, cũng như để đội phát triển cảm thấy thoải mái sau những nỗ lực tạo sản phẩm, BA nên tập trung để thể hiện cho khách hàng thấy những điểm mà hệ thống đã đạt được. Hệ thống đã đáp ứng được nhu cầu của khách hàng ra sao, chức năng đã có thể chạy và xử lý các case cần thiết ra sao.
Đồng thời, nếu minh bạch thông tin là điều bắt buộc trong dự án, hãy liệt kê những bug còn tồn đọng để khách hàng biết và nhớ nhắc đến những bug này là bug nhỏ, không ảnh hưởng đến chức năng chính của hệ thống. Và việc liệt kê này cần làm sau khi đã thể hiện hệ thống đang chạy tốt các chức năng.
5. Tìm người support trong buổi demo sản phẩm: Trong buổi demo, BA sẽ giao tiếp chính với khách hàng, thường các buổi demo cũng diễn ra ra online, do vậy, màn hình máy tính của BA sẽ được chia sẻ với khách hàng.
BA sẽ không được mở ra màn hình chat của đội dự án, sẽ không biết tình hình các bug phát sinh trong demo đã được fix chưa, hay có thông tin nào đặc biệt, cần lưu ý trong lúc demo hay không. Do vậy, cần có người support trong buổi demo, người này sẽ tiếp nhận các thông tin trong buổi demo, làm việc với đội dev, test và phản hồi lại trước khách hàng.
Ví dụ, khách hàng muốn test một case chưa được đề cập trong demo scenario. BA sẽ tiếp tục demo theo scenario có sẵn và hẹn khách hàng demo case đó sau. Trong thời gian này, người support sẽ giúp kiểm tra xem case đó đã chạy ổn chưa để báo BA demo luôn hay đợi đến buổi sau.
Tổng hợp dừng lại đây rồi. Ai có thêm kinh nghiệm về demo thì comment cho mình biết nhé!
P/s: Đăng ký nhận ngay postcard BABOK tóm tắt về các task của BA dưới đây nhé:
Đáng ra các bạn nên báo cáo cho chúng tôi trước, sẽ không tốn thời gian của tất cả mọi người đang ngồi đây. Tôi cũng sẽ báo lên kịp với cấp trên của mình về tiến độ dự án....."
Giọng khách hàng thể hiện sự thất vọng sau một buổi demo thất bại toàn tập. Buổi demo đã kết thúc, cuộc họp khẩn cấp giải trình lý do demo thất bại cũng đã xong từ lâu. Còn mình, vẫn ngồi bần thần ra sau đấy, nhấm nháp cảm giác của sự thất bại.........
Hello, lại là mình, Thương đây.
Hôm nay blog của mình quay trở lại với bài viết chủ đề demo sản phẩm. Demo, viết đầy đủ là demonstration, là bước được thực hiện sau khi đội phát triển hoàn thành xây dựng được một danh sách chức năng. Đây là bước mà dự án sẽ chạy thử phần mềm trong cuộc họp với khách hàng, để thấy được yêu cầu của khách hàng đã được đưa lên hệ thống như thế nào.
Tuỳ từng dự án, người thực hiện Demo có thể là tester, dev, PM hay BA. Trong một dự án, mình được đảm nhiệm task Demo này, đây là quãng thời gian mình thực hiện demo liên tục, cứ 2 tuần cho 1 buổi demo sản phẩm và 1 buổi internal demo, mỗi buổi kéo dài 2 tiếng.
Trong dự án khác nữa, mình cũng có cơ hội được tham dự demo, với tư cách là khách hàng, hiểu cảm giác khi được tiếp nhận nội dung demo sẽ thế nào. Bởi vậy bài viết này ra đời nhằm tổng hợp lại kinh nghiệm qua những buổi demo, có những buổi thành công và có những buổi thất bại (như đoạn mở đầu nè) mà mình đã trải qua.
Hãy cùng đi qua 5 điểm cần lưu ý khi thực hiện demo sản phẩm nhé!
1. Chuẩn bị kỹ demo scenario: Đây là bước giúp bạn định hình những gì sẽ thực hiện trong buổi demo. Demo scenario cần bao gồm các flow chính, đảm bảo thể hiện được mục đích business của chức năng. Nếu tài liệu về chức năng khách hàng gửi đến có mục Acceptance Criteria, có thể căn cứ mục này để viết demo scenario.
Tại thời điểm demo, khách hàng vẫn chưa được tiếp xúc với hệ thống vừa xây dựng, do vậy, để khách hàng có thể hiểu và dễ dàng tiếp nhận nội dung demo, BA cần viết demo scenario theo hướng nghiệp vụ business khách hàng, và cho khách hàng thấy nghiệp vụ đó đang được đáp ứng trên hệ thống ra sao. Các dữ liệu được dùng cho demo cũng cần mang tính thực tế và quen thuộc với khách hàng.
2. Nhờ tester verify hệ thống trước: Thời gian kể từ lúc dev hoàn thành chức năng đến lúc sẵn sàng demo sẽ là quãng thời gian bận rộn của tester và BA. Các chức năng này sẽ được tester kiểm thử đi kiểm thử lại để đảm bảo hoạt động đúng như yêu cầu.
BA có thể hoàn thành demo scenario và nhờ tester chạy trước trong quá trình kiểm thử. Nhờ vậy, tester đã kiểm tra trước và đảm bảo các chức năng chạy tốt trước khi BA bắt đầu thực hiện test. Thời gian test của BA sẽ giảm xuống rất nhiều.
Việc nhờ test verify hệ thống trước này cần thảo luận trước với đội dự án nhằm đảm bảo tester có effort để thực hiện.
3. Hãy chắc chắn main flow chạy ổn định trước khi demo: Có một lời nguyền thế này: các chức năng dev làm xong luôn chạy ok, đến tay tester verify phát hiện lỗi đã fix, BA đã test lại cũng ok nốt, nhưng cứ đúng lúc demo kiểu gì cũng .... die.
Ở case mở đầu bài, mình từng demo thất bại, nguyên nhân là function khi test có chạy ok, nhưng cũng có lúc có bug (lỗi). Nhưng bug này khá ảo ma, chỉ nhìn thấy 1 lần duy nhất, sau đó test lại không còn bug nữa, nên mình ok, cho qua, đến lúc demo thì bạn bug lại chạy đến chơi. Thế là thôi xong.
Trong trường hợp này, cần báo lại ngay cho PM, về khả năng có thể xảy ra bug, để PM quyết định có thông báo cho khách hàng có demo nữa hay không nhé.
4. Tập trung vào những điểm đã đạt được trong buổi demo: Tại thời điểm demo khách hàng, việc có bug là điều không tránh khỏi (tất nhiên những bug này cần đủ nhỏ để không block luồng). Là BA, cũng không thể che giấu bug trước khách hàng khi chạy demo.
Tuy nhiên, để khách hàng có cảm giác tốt về sản phẩm mà dự án làm ra, cũng như để đội phát triển cảm thấy thoải mái sau những nỗ lực tạo sản phẩm, BA nên tập trung để thể hiện cho khách hàng thấy những điểm mà hệ thống đã đạt được. Hệ thống đã đáp ứng được nhu cầu của khách hàng ra sao, chức năng đã có thể chạy và xử lý các case cần thiết ra sao.
Đồng thời, nếu minh bạch thông tin là điều bắt buộc trong dự án, hãy liệt kê những bug còn tồn đọng để khách hàng biết và nhớ nhắc đến những bug này là bug nhỏ, không ảnh hưởng đến chức năng chính của hệ thống. Và việc liệt kê này cần làm sau khi đã thể hiện hệ thống đang chạy tốt các chức năng.
5. Tìm người support trong buổi demo sản phẩm: Trong buổi demo, BA sẽ giao tiếp chính với khách hàng, thường các buổi demo cũng diễn ra ra online, do vậy, màn hình máy tính của BA sẽ được chia sẻ với khách hàng.
BA sẽ không được mở ra màn hình chat của đội dự án, sẽ không biết tình hình các bug phát sinh trong demo đã được fix chưa, hay có thông tin nào đặc biệt, cần lưu ý trong lúc demo hay không. Do vậy, cần có người support trong buổi demo, người này sẽ tiếp nhận các thông tin trong buổi demo, làm việc với đội dev, test và phản hồi lại trước khách hàng.
Ví dụ, khách hàng muốn test một case chưa được đề cập trong demo scenario. BA sẽ tiếp tục demo theo scenario có sẵn và hẹn khách hàng demo case đó sau. Trong thời gian này, người support sẽ giúp kiểm tra xem case đó đã chạy ổn chưa để báo BA demo luôn hay đợi đến buổi sau.
Tổng hợp dừng lại đây rồi. Ai có thêm kinh nghiệm về demo thì comment cho mình biết nhé!
P/s: Đăng ký nhận ngay postcard BABOK tóm tắt về các task của BA dưới đây nhé: