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à 4 nguyên tắc để lấy yêu cầu một cách hiệu quả 😎

“Dân chơi” ở đây chính là mình – từ số kinh nghiệm ít ỏi mình rút ra được, từ nhiều anh chị senior khác xung quanh mình chỉ dạy, cũng như tham khảo các bậc tiền bối trên mạng.

Nhưng trước khi tham khảo 4 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!!!

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 questionaire 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 được 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 không cover hết được.
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ỉ ai đã từng trải qua những thực tế như vậy, thì mới có thể nhìn nhận ra được những vấn đề tiềm tàng, từ đó 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 qua ít nhất 1 dự án từ đầu đến cuối rồi, thì mới mong lấy yêu cầu một cách ổn nhất.

Dân chơi lấy yêu cầu với 4 nguyên tắc sau - Thinhnotes.com

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

Một vấn đề khác nữa đế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ó hai lý do: một là do cách mình truyền đạt dở, hai là do cách mình truyền đạt mình dở. Lạ lùng vậy đó :))

Mình gặp trường hợp này cùng nhiều. Và trong các trường hợp, khi nói không được thì mình phải… vẽ.

You know what I mean, muahahaha

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 hành động 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 😎

Cái này mình sẽ nói rõ hơn bên dưới nhé.

Ô 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, từ đó lấy yêu cầu một cách hiệu quả hơn, anh em cùng tham khảo 4 nguyên tắc dưới đây nhé.

2. Bốn nguyên tắc lấy yêu cầu

2.1. Luôn chuẩn bị

Nguyên tắc đầu tiên phải luôn là: 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 :3

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 các buổi workshop lấy yêu cầu, anh em cần làm những gì?

 

Bảng questionaire

Đầu tiên, anh em cần phải chuẩn bị được 1 cái bảng questionaire.

Mỗi dự án, mỗi khách hàng khác nhau là một cái bảng questionaire 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). Thường khách hàng sẽ có RFP 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, với Presales hoặc PM. Để hiểu rõ paint point của họ và những thứ họ mong muốn, thì mới có thể làm các câu hỏi trong bảng questionaire được.

Ô kê, vậy thì chuẩn bị questionaire như thế nào?

  • Cột đầu tiên 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 Questionaire 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 để output 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 >> PM 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ấy yêu cầu 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 questionaire như sau: phân loại bảng questionaire 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 Questionaire, để 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, hehe)

Và nhớ bám sát mục tiêu

Nên nhớ đối với các buổi workshop này, mục tiêu cao cả nhất là phải moi móc được những thông tin 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 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 thôi. 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 hóa 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

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.

Câu hỏi mình muốn làm rõ ở đây 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à koan đỡ chán, vì mắt họ có cái để xem, đỡ buồn ngủ.
  • Thu hút ánh nhìn, và 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 dễ dàng.

2.3. Tỉnh táo khi lắng nghe

Dĩ nhiên BA không phải là một “thư ký” chỉ chuyên ghi ghi chép chép và 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ì sẽ không ít lần xảy ra conflict thông tin giữa các bên với nhau. Anh em phải xem xét xem thử là: 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 hay 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.

2.4. Nghe một cách chủ động

Khi anh em không hiểu một vấn đề >> mình sẽ phát sinh ra những câu hỏi. Nhưng thường thì mình đã giả định câu trả lời cho các câu hỏi ấy rồi.

Tâm lý con người thường là.

Khi mình hỏi người khác một vấn đề, mình chỉ trông chờ họ trả lời đúng như câu trả lời giả định của mình. Nếu họ làm ngược lại, thì 96,69% là mình cho họ sai. Bản thân mình không thích điều này!

Ví dụ.

Anh em rủ thằng bạn đi ăn bánh canh ở một quán ruột, phải nói là ngon số dách.

Vô ăn, mình hỏi nó một câu: “Ngon không mậy?”. Thì lúc này, có phải mình chỉ trông chờ nó: gật đầu lia lịa rồi nói ngon thôi đúng không?

câu trả lời giả định của mình chắc chắn phải là ngon. Nó mà trả lời dở ẹc thì mình thấy ghét vô cùng. Vì đó không phải là điều mình trông chờ.

BA lấy yêu cầu cũng vậy.

Mình có thiên hướng chờ khách hàng trả lời theo đúng ý mình đang giả định trong đầu, à há.

Nếu khách hàng trả lời không đúng ý mình giả định, thì thôi rồi, sẽ là một nùi rối rắm hiện lên trong đầu.

Tin mình đi, theo bản năng tự nhiên của con người, lúc đó anh em sẽ tập trung mãi vào câu trả lời của họ. Cố gắng ngồi rặng não để phân tích, suy xét nhằm mục đích hiểu được tường tận câu trả lời của khách hàng.

Và khi đó, chắc chắn mình sẽ bị miss rất nhiều thông tin mà khách hàng trả lời tiếp sau đó. Đây là điều chắc chắn!

Để giải quyết vấn đề này: Biên bản họp – Minutes of Meeting. 

Nhưng tốt nhất nên có 1 thư ký riêng ghi biên bản họp. Trong các buổi workshop lấy yêu cầu, BA đừng nên ghi MoM, mà chỉ nên tập trung note theo ý riêng của mình vào Questionaire thôi.

Đẹp thì xin khách hàng ghi âm, thậm chí quay video lại buổi workshop hôm đó, để về nhà còn có cái phân tích lại.

Tuy nhiên, còn 1 cách rất hay mình tham khảo được từ trang ReqExpert. Tạm gọi là: phân loại câu trả lời.

Tức là trong cái bảng Questionaire, anh em thay cho mình cột Answer, bằng 2 cột: Left Answer Right Answer.

  • Với những câu trả lời khớp với giả định của mình, khớp với những suy nghĩ ngay từ đầu của mình, và mình cho rằng nó đúng thì mình ghi vào cột bên trái: Left Answer.
  • Ngược lại, với những câu trả lời khác với giả định của mình, những câu trả lời theo mình là mới, mình không ngờ tới, hoặc thậm chí còn nghi ngờ tính đúng đắn của nó, thì mình ghi vào cột bên phải: Right Answer.

Xong. Điều này giúp anh em bắt kịp những câu trả lời và giải thích tiếp theo của khách hàng. Nhưng vẫn kịp thời phân loại được:

  • Đâu là theo những gì mình hiểu, mình giả sử.
  • Đâu là những thông tin mới, mình chưa nghĩ tới bao giờ.

Khi đó, nó sẽ giúp anh em hệ thống lại mọi thứ rất rõ ràng, phải nói là rất rõ ràng. Tiếp theo mình cứ từ từ giải quyết những thứ lăn tăn phát sinh thôi 🙂

 

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, nghe vô chữ được chữ mất.

Mà nhờ có vậy mình mới lãnh khá nhiều hậu quả, 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 4 phương pháp trên 😎

Bái bai và hẹn gặp lại.

 

Anh em tham khảo thêm tại: reqexperts.com/resources/requirements-articles/articles-3-mistakes-a-ba-should-avoid/