Lấy yêu cầu nghe thì đơn giản, cứ đến ngồi hỏi rồi ghi lại là xong, nhưng làm thật rồi mới thấy nó dễ biến thành ác mộng thế nào, và mấy nguyên tắc dưới đây là những thứ mình đúc ra từ chính các vết sẹo của mình ở dự án ERP/MES.
hai trở ngại lớn#
Cái bẫy đầu tiên là kinh nghiệm. Thiếu kinh nghiệm thì mình chỉ khai thác được phần nổi của tảng băng, còn phần chìm thì nằm ở mấy chỗ khách hay quên kể như các trường hợp ngoại lệ (business cases), các rủi ro kỹ thuật kiểu tích hợp hệ thống hay chuyển đổi dữ liệu, và phức tạp nhất là yếu tố con người. Cái này không có đường tắt, phải trầy vi tróc vảy qua ít nhất một dự án trọn vẹn mới mong thuần thục. Theo mình, nếu chỉ cầm bảng câu hỏi mẫu đi hỏi thì bạn sẽ chỉ nhận về đúng phần nổi đó, còn nếu người cần hỏi lại né tránh thì xem thêm cách làm khi stakeholder không hợp tác.
Trở ngại thứ hai là lúc lời nói bất lực, mình diễn đạt một đằng, ý trong đầu một nẻo, thế là đối tác hiểu sai. Cách của mình là vẽ, vẽ mọi lúc mọi nơi, trên bảng trắng, giấy nháp, PowerPoint, Excel, cái gì vẽ được thì vẽ.
nguyên tắc 1: luôn chuẩn bị#
Fail to prepare là prepare to fail, câu này cũ nhưng chưa bao giờ sai.
Thứ đầu tiên cần chuẩn bị là bảng câu hỏi, và nó phải được tùy biến cho từng khách hàng chứ đừng dùng template chung. Nguyên liệu thường là RFP (hồ sơ mời thầu) hoặc UR (yêu cầu người dùng), mà mấy tài liệu này thường mông lung lắm nên càng cần câu hỏi để làm rõ, còn nếu không có RFP thì phải ngồi với Sales hoặc PM để nắm pain point của khách. Bảng câu hỏi mình hay dùng có bốn cột: số thứ tự, câu hỏi, câu trả lời ghi nhận, và người hay bộ phận chịu trách nhiệm trả lời. Làm xong thì nhờ một anh chị senior trong team review để lấp lỗ hổng kiến thức. Các kỹ thuật hỏi cụ thể hơn mình gom trong bộ kỹ năng khai phá nhu cầu thật.
Thứ hai là chọn đúng người. Workshop nên tối giản, chỉ mời người liên quan trực tiếp, nói chuyện kho thì mời thủ kho, nói chuyện sản xuất thì mời quản đốc, rồi gửi khách một lịch chi tiết ngày nào, giờ nào, cần gặp ai. Mục đích là đừng làm khách mệt, vì khách mệt thì trả lời qua loa, requirement tệ, và dự án fail từ đó.
Thứ ba là biết mình muốn mang gì về trước khi bước vào phòng họp, quy trình Sales, cách làm hợp đồng hay sơ đồ tổ chức, có mục tiêu rồi mới chọn được cách moi tin cho đúng. Và giai đoạn này là để moi tin, đừng sa đà vào tư vấn quá sớm. Mình đến để nghe họ nói, chứ không phải để dạy họ làm.
nguyên tắc 2: khi cần là phải show#
Nói anh không hiểu thì show hình cho anh xem, màn hình phần mềm, mockup, sơ đồ, diagram, cái gì cũng được. Có hình thì người nghe đỡ buồn ngủ vì mắt có cái để nhìn, cả phòng về cùng một góc nhìn thay vì ông nói gà bà hiểu vịt, và thảo luận cũng dễ hơn vì chỉ thẳng vào từng ký hiệu, từng bước. Thực hành thì đơn giản thôi, đứng dậy, cầm bút lông, vừa vẽ lên bảng vừa nói “hàng về thì ông Kho nhận, rồi đẩy sang ông Kế toán…”, khách xác nhận đúng sai chỉ trong 5 giây, hiệu quả gấp trăm lần nói suông.
nguyên tắc 3: tỉnh táo khi lắng nghe#
BA không phải máy ghi âm hay thư ký, nên khi nghe thì đầu phải nhảy số liên tục. Cùng một câu hỏi, hỏi ông A và ông B có ra cùng đáp án không, lệch là có chuyện. Câu trả lời cho vấn đề A có chỗ nào mâu thuẫn với quy trình B nghe hôm trước không, có thì phải đào sâu. Cứ hỏi, phân tích, tổng hợp, rồi mới vẽ ra được bức tranh tổng thể cho chính xác, và đừng quên kiểm tra chéo với team nhà, Dev hay Tech lead, xem giải pháp có khả thi không. Sơ suất vớ nhầm thông tin sai là tèo ngay.
mấy vết sẹo#
Mình từng sai nhiều vì thiếu chuẩn bị, và chính mấy vết sẹo đó mới thành ra các nguyên tắc ở trên. Họp lấy yêu cầu không đáng sợ đến thế, miễn là nắm được nguyên tắc và lúc nào cũng sẵn sàng sửa sai.
Bài đăng lần đầu trên quanlamba.wordpress.com.
