Dân chơi lấy yêu cầu với 3 nguyên tắc sau
Dân chơi lấy yêu cầu với 3 nguyên tắc sau
Hello anh em. Tiếp nối với bài viết lần trước – nói về những điều nên tránh khi làm BA. Ở bài này, mình sẽ nói về điều ngược lại: những điều nên làm, rất nên làm, và thậm chí là không thể thiếu khi lấy yêu cầu.
Nói cách khác nguy hiểm hơn, nội dung bài này sẽ là 3 nguyên tắc để lấy yêu cầu một cách hiệu quả 
“Dân chơi” ở đây là mình – từ số kinh nghiệm ít ỏi mình rút ra được, từ nhiều anh chị kỳ cựu xung quanh mình chỉ dạy, và cũng như tham khảo từ các bậc tiền bối trên mạng.
Nhưng trước khi tham khảo 3 nguyên tắc chủ chốt này, mình sẽ nói qua về 2 khó khăn mà theo mình là “oái ăm nhất” khi lấy yêu cầu nhé.
Ô kê lét gâuuuuu!!!
Nội dung [Hide]
- 1. Những khó khăn khi lấy yêu cầu
- 1.1. Kinh nghiệm
- 1.2. Khả năng diễn đạt
- 2. Ba nguyên tắc khi lấy yêu cầu
- 2.1. Luôn chuẩn bị
- 2.2. Trực quan khi cần
- 2.3. Tỉnh táo khi lắng nghe
- 3. Tự bốc phốt
1. Những khó khăn khi lấy yêu cầu
1.1. Kinh nghiệm
Bá tánh đồn rằng: Lấy yêu cầu là một “bộ môn nghệ thuật” đòi hỏi yếu tố kinh nghiệm cao và có thể xem người lấy yêu cầu như một người nghệ sĩ 
Nghe hơi chém gió một chút nhưng anh em cứ thử tưởng tượng thế này cho dễ hiểu.
Anh em được giao nhiệm vụ vận chuyển 5 tấn gỗ lậu từ Lào Cai đi Cam pu chia.
Ô kê, nhiệm vụ đã rõ ràng. Câu hỏi tiếp theo: những yếu tố nào có thể tác động, làm chuyến đi của mình bị fail?
À, kinh nghiệm là ở chỗ này.
Với người đã có kinh nghiệm chạy tuyến đường này, họ biết rõ: chỗ nào có công an, chỗ nào đường xấu, chỗ nào đường đẹp, chỗ nào có thể dừng xe nghỉ trưa, ăn tối. Và hàng tỉ thứ khác được xét vô diện “kinh nghiệm”, mà chỉ những ai đã đi chuyến này rồi mới có được 
Đây đều là những rủi ro tiềm tàng có trong chuyến đi.
Nếu không để ý, hoặc chưa từng biết, nó có thể làm chuyến hàng của mình bị delay, bị hư hỏng, bị cướp, bị công an thổi, bị abc xyz, vâng vâng…
Lấy yêu cầu trong phần mềm cũng vậy!
Nếu anh em chưa từng làm 1 dự án nào, thì hầu như là rất khó để lấy yêu cầu 1-cách-ổn-nhất. “Ổn” ở đây tức là đủ để team nhà hiểu được các vấn đề của khách hàng và thiết kế được giải pháp.
Nếu không có yếu tố kinh nghiệm, mà chỉ follow theo những questionnaire sẵn có, thì hầu như những gì mình khai thác được từ khách hàng chỉ là 30% bề nổi của tảng băng.
Và dĩ nhiên, 30% là không đủ để ăn nhậu gì hết.
70% còn lại ở đâu?
70% còn lại đến từ những business case khác có thể xảy ra, mà mình chưa cover được hết.
70% đó cũng có thể đến từ những vấn đề kỹ thuật tiềm tàng như việc tích hợp, migrate data…
Hoặc phức tạp hơn, 70% đó đến từ yếu tố con người, cả từ phía khách hàng, lẫn team nhà. Mà chỉ những ai, đã trải qua thực tế oái ăm như vậy, thì mới có thể nhìn nhận ra được các vấn đề tiềm tàng >> để làm rõ ngay từ đầu, thì sau này dự án mới chạy trơn tru được.
Nói tóm lại, phải làm ít nhất một dự án từ đầu chí cuối rồi, thì mới mong lấy yêu cầu một cách ổn nhất được…
Kinh nghiệm tuy là vấn đề không nhỏ, nhưng không phải không có cách giải quyết. Xem tiếp phần dưới nhé anh em!
1.2. Khả năng diễn đạt
Vấn đề thứ hai đến từ khía cạnh giao tiếp.
Sẽ rất dễ để anh em rơi vào trường hợp: Mình muốn nói A, nhưng méo hiểu sao không diễn tả được. Muốn nói A, nhưng người ta toàn hiểu A’, hoặc A+.
Điều này có ba lý do: một là do cách mình truyền đạt dở, hai là do cách mình truyền đạt dở, và ba cũng là do cách truyền đạt của mình dở. Lạ lùng vậy đó :))
Cá nhân mình cũng gặp trường hợp này nhiều. Và trong các trường hợp, khi nói không được thì mình phải… vẽ.
Thực hành vẽ mọi lúc mọi nơi nhé anh em
Vẽ là một trong 11 phương pháp moi móc thông tin được sử dụng phổ biến mà mình có đề cập. Và nó cực kỳ lợi hại.
Anh sếp mình là chuyên gia vẽ hình.
Nói cái gì mà khó hiểu là ổng động thủ ngay. Nếu chỗ đó không có bảng, không có bút, thì ổng dùng Power Point, Excel. Nói chung là đụng đâu vẽ nấy. Vậy mới đỉnh kout
(Phần này mình sẽ nói rõ hơn bên dưới).
…
Ô kê, chung quy lại thì đa phần chúng ta sẽ gặp phải 2 trở ngại “nổi cộm” trên khi lấy yêu cầu.
- Thiếu kinh nghiệm
- Và cách diễn đạt chưa hiệu quả
Để giải quyết được 2 vấn đề trên ==> lấy yêu cầu một cách hiệu quả hơn ==> anh em đọc ngay 3 nguyên tắc dưới đây nhé.
2. Ba nguyên tắc khi lấy yêu cầu
2.1. Luôn chuẩn bị
Nguyên tắc đầu tiên: CHUẨN BỊ THẬT TỐT.
FAIL PREPARE = PREPARE FAIL.
Giờ, anh em hãy thử nhớ lại, có phải meeting mình toàn thò đâu vô cho có. Rồi khi vô meeting, mới bắt đầu mở cái này, mở cái kia ra xem, rồi thảo luận. Chứ chả bao giờ chuẩn bị trước hết đúng không.
Cái này là bình thường khi họp nội bộ với nhau. Cao lắm sẽ gây tốn thời gian và họp không hiệu quả.
Nhưng hậu quả sẽ rất vô chừng nếu mình đi lấy yêu cầu mà vẫn giữ nguyên cách làm việc như này.
Vậy để chuẩn bị cho workshop lấy yêu cầu, anh em cần làm những gì?
Bảng questionnaire
Đầu tiên, anh em cần phải chuẩn bị được 1 cái bảng questionnaire.
Mỗi dự án, mỗi khách hàng khác nhau là một cái bảng questionnaire khác nhau. Không cái nào giống cái nào.
Anh em phải chuẩn bị các câu hỏi dựa trên tài liệu RFP mà khách hàng gửi (Request For Proposal) hoặc khi vô dự án rồi thì là UR (User Requirement). Thường khách hàng sẽ có RFP hoặc UR cho mình. Trong đó nó sẽ liệt kê những vấn đề của khách hàng, cái họ cần và cái họ muốn.
Mình cần list down ra những câu hỏi cần làm rõ với khách hàng, dựa trên cái RFP vô cùng sơ khởi và mông lung này.
Tuy nhiên nếu khách hàng không có RFP, hoặc anh em không join dự án ngay từ đầu giai đoạn sales, thì bắt buộc anh em phải làm việc trước thật rõ ràng với Sales hoặc PM. Để hiểu rõ paint point của họ và những thứ họ mong muốn, thì mới có thể xây bảng questionnaire các thứ cần hỏi được.
Ô kê, vậy thì chuẩn bị questionnaire như thế nào?
- Cột thứ 1 là số thứ tự
- Cột thứ 2 là câu hỏi
- Cột thứ 3 là câu trả lời (ghi nhận được)
- Cột cuối cùng là người/ team mà mình nghĩ là có câu trả lời chính xác nhất.
Nó sẽ kiểu kiểu như sau.
Sau đó, hãy đem bảng Questionnaire này đi nhờ những Senior trong team xem qua một lần.
Tận dụng kinh nghiệm của họ, để mang vào buổi workshop của mình.
Bài toán kinh nghiệm phần nào được giải quyết ở chỗ này.
Sàn lọc đối tượng tham dự
Workshop lấy yêu cầu thì nên tối giản người tham dự. Mục đích buổi đó liên quan đến module gì, chức năng gì, thì cần người của bộ phận đó tham dự thôi.
Do đó, anh em cần chuẩn bị một cái lịch thật chi tiết để gửi cho khách hàng: À, ngày đó tui sẽ workshop với chị này bộ phận A, anh kia bộ phận B.
Hoặc là workshop với bộ phận C cho chức năng C, thì tui muốn vừa có cả Manager, vừa có cả Admin, vừa có cả nhân viên thị trường để kết quả thu được là đa chiều nhất.
Tránh làm tốn thời gian của khách hàng là điều mình rất rất rất cần chú ý.
Vì sao?
Vì khi khách hàng tốn thời gian >> họ uể oải >> chán nản >> ngáp ngắn ngáp dài >> BA khai thác kém hiệu quả >> chất lượng output thấp >> BA nản >> requirement tệ >> dự án failed >> PM chửi >> Dev chửi >> BA die!
Xác định mục tiêu rõ ràng
Anh em cần xác định được mục tiêu của các buổi workshop là gì. Càng cụ thể càng tốt. Ví dụ:
- Hiểu được cách đội Sales vận hành, theo các trường hợp thực tế có thể xảy ra.
- Hiểu được cách họ làm 1 cái contract cho khách hàng
- Hiểu được sếp của bộ phận sản xuất hằng ngày đang theo dõi chất lượng hoạt động như thế nào.
- Xác định được cấu trúc, sơ đồ tổ chức, bộ máy hoạt động….
Khi đã có mục đích rõ ràng, anh em mới bắt tay vô chọn các phương pháp moi móc thông tin phù hợp mà mình có nói ở trên.
Tiếp đến, mình sẽ “upgrade” bảng questionnaire như sau: phân loại bảng questionnaire này theo những vấn-đề-quan-trọng-mà-mình-đang-mông-lung-cực-kỳ.
Mình từng làm project cho một công ty dịch vụ. Cái cốt lõi, chính yếu nhất của nó là cần theo dõi và quản lý được quá trình thương thảo hợp đồng với khách hàng.
Mà phải nói là cái hợp đồng của nó kinh khủng, rồng rắn má ơi, đọc muốn lòiii con mắt @@ Thì đó chính là điểm quan trọng nhất mình cần phải khai thác cho bằng được.
Và mình dành hẳn 2 trang A4 để note vào những câu hỏi, những giả định và các trường hợp có thể xảy ra vào Questionnaire, để dành hỏi khách hàng, nhằm làm rõ vấn đề này.
(à, giả định trong trường hợp này rất nên xài nhé anh em, chứ không như trường hợp này)
Và nhớ bám sát mục tiêu
Đối với các buổi workshop kiểu này thì mục tiêu cao cả nhất vẫn là moi móc được những thứ mình cần.
Tức là từ thông tin có sẵn (chưa được phát biểu, hoặc đã được phát biểu ra), mình chỉ moi móc nó ra và document lại.
Tránh trường hợp ngồi bàn với khách hàng về business của họ. Mình nói tránh thôi, chứ không phải không được.
Bản chất của nghề BA là mang lại giải pháp cho khách hàng mà. Họ không biết thì mình tư vấn. Nhưng mấu chốt là những buổi workshop lấy yêu cầu không phải là buổi để tư vấn. Anh em không nên tập trung quá sâu vào chuyện tư vấn giải pháp cho họ.
Đáng lý ra, giải pháp tổng quan phải được xong ngay từ giai đoạn sales, khi team hoa tiêu đi câu dự án về rồi.
Khi khách hàng chưa đủ sẵn sàng, hoặc thậm chí có phần hơi lúng túng khi anh em đặt câu hỏi, thì đó là dấu hiệu cho thấy: chính họ cũng chưa hệ thống lại được bài toán của họ.
Khi đó anh em phải thật sự tỉnh táo, tránh sa lầy quá nhiều vào việc gỡ rối bài toán của họ. Mà trong khi nhiệm vụ chính của mình tới buổi workshop này không phải zậy.
2.2. Trực quan khi cần
Nguyên tắc thứ hai khi lấy yêu cầu là anh em sẽ dùng tới những-thứ-rất-chi-là-trực-quan. Nó cũng là một trong nhiều kỹ năng cần thiết của BA.
Trực quan là khi tui nói anh không hiểu thì tui sẽ show ra cho anh xem mất hồn chơiii.
Show thì có thể show màn hình phần mềm, show mockup hoặc show sơ đồ, diagram.
Theo đó, câu hỏi mình muốn làm rõ là: “Vì sao nó hiệu quả?”
Đầu tiên là các sơ đồ. Khi anh em show cho người ta 1 cái sơ đồ, nó sẽ mang lại những tác dụng sau:
- Làm cho pà con đỡ chán, vì mắt họ có cái để xem, đỡ buồn ngủ.
- Thu hút ánh nhìn, sự tập trung của họ lên màn hình >> chờ mình giải thích
- Mọi người được gom chung về 1 góc nhìn >> rất dễ để thống nhất 1 vấn đề khi các bên có cùng góc nhìn.
- Thảo luận dễ hơn, vì trên diagram đã có ký hiệu (1 người nói là mọi người biết đang nói tới đâu, cục số mấy, quy trình gì, ký hiệu ra sao…)
- Và sau cùng vẫn là quan trọng nhất, giúp mọi người hình dung vấn đề một cách rõ nét, không còn mịt mờ như trước nữa.
Khi đã đạt được những điều trên, anh em sẽ lấy được sự confirm từ khách hàng một cách nhanh hơn, hiệu quả hơn.
Chỗ nào cần làm rõ, anh em cứ trình bày bằng hình vẽ, highlight mạnh tay, rồi trình bày cách hiểu của mình. Đúng hay sai, 5 giây sau là khách hàng confirm liền.
Hiệu quả vô cùng.
Anh em chỉ việc đứng dậy >> cầm bút lông >> phác thảo sơ quy trình trên bảng >> vẽ tới đâu, nói tới đó >> nói để người ta hiểu-được-cách-hiểu-của-mình. Thì khi đó chốt vấn đề vô cùng nhanh chóng.
Chứ mà ngồi nói qua nói lại chắc tới sáng mai cũng chưa xong cái mở bài :))
Cách này có một điểm cực hay là nó là HÀNH ĐỘNG. Tức là nó sẽ thu hút mọi người hơn, tạo một chút không khí khác biệt. Và hai bên có thể cùng tương tác, vẽ vời, thảo luận với nhau một cách dễ dàng.
2.3. Tỉnh táo khi lắng nghe
Nguyên tắc thứ ba đó là: phải luôn tỉnh táo khi lấy yêu cầu.
Dĩ nhiên BA không phải là một “thư ký” chỉ chuyên ghi ghi chép chép, deliver thông tin giữa các bên.
Ở trên mình đã chuẩn bị và có sự trực quan cần thiết khi trình bày. Vậy thì trong quá trình lấy yêu cầu, mình phải lắng nghe thật sự kỹ càng câu trả lời của các Stakeholder.
Vì chắc chắn, sẽ không ít lần có sự bất hợp lý thông tin giữa các bên với nhau.
Anh em phải xem xét thử xem: một câu hỏi, được hỏi nhiều người, thì mình có nhận được cùng 1 câu trả lời không? Hay nhận được nhiều câu trả lời hoàn toàn khác nhau…
Có thể mỗi người ở mỗi vị trí, bộ phận khác nhau, nên góc nhìn của mỗi người có thể khác nhau. Nhưng về bản chất: chân lý là chân lý. Cái gì đúng, thì nó chỉ có 1 kết quả là đúng là thôi, còn cách giải thích thì có thể có nhiều.
Ngoài ra, anh em phải chú ý xem thử câu trả lời của người đó, có dẫn mình tới một vấn đề nào khác nữa hay không. Thường thực tế nó sẽ như thế này:
- Mình chưa hiểu vấn đề A, mình hỏi câu 1, 2, 3. Khách hàng trả lời x, y, z.
- Mình chưa hiểu vấn đề B, mình hỏi câu 3, 4, 5. Khách hàng trả lời g, h, o.
Nhưng vô hình dung, câu trả lời “h” lại làm mình thấy có 1 điều gì đó, hơi vô lý ở vấn đề A. Thế là mình lại phải hỏi tiếp câu 6, 7, 8 cho vấn đề A’. Và nhận được câu trả lời q, w, e.
Cứ tiếp tục như thế, sau khi hỏi >> PHÂN TÍCH >> ghi nhận, mình tổng hợp lại các ý sẽ nhìn ra được bức tranh tổng quan của khách hàng một cách chính xác nhất.
Ngoài ra, anh em cũng nên chú ý đến team nhà. Nhiều khi ở nhà nói 1 đằng, mà ra ngoài gặp khách hàng nói 1 nẻo là hẻo lắm. Thông tin với BA là cực kỳ quan trọng, sơ suất vớ nhầm thông tin sai là tèo ngay.
Bonus anh em tấm hình xem chơi.
Nguồn ảnh từ modernanalyst.com, có bổ sung chữ tiếng Việt giữa hình.
3. Tự bốc phốt
Chém gió nãy giờ quá trời quá đất chứ thật ra mình cũng chả bao giờ chuẩn bị kỹ càng hết, chưa một lần chuẩn bị các buổi meeting cho ra hồn. Đã vậy cũng ít khi giữ được sự tỉnh táo khi lắng nghe, vô nghe chữ được chữ mất.
Mà nhờ có vậy mình mới lãnh đạn khá nhiều, chua có, chát có, nên giờ mình mới nhìn nhận và đút kết được đôi điều, muốn chia sẻ với anh em.
Hi vọng anh em sẽ tìm thấy chút tia hi vong le lói gì đó sau bài viết này. Và đặc biệt là không quá bi quan, hay nghĩ workshop lấy yêu cầu là một cái gì đó ghê gớm, dữ dội lắm. Dăm ba cái ruồi bu kiến đậu ấy mà, muỗi hết :))
Chúc anh em gặp nhiều may mắn với 3 phương pháp trên
.
.
.
À mà còn 1 nguyên tắc cũng liên quan đến bài này, đó là Nguyên tắc não trái – não phải khi lấy yêu cầu, anh em xem thêm tham khảo nhé.
Bái baiii, gặp lại ở các note sau nhé anh em!
Nguồn: thinhnotes.com
