Requirement là gì

Requirement là một đòi hỏi về khả năng đáp ứng bằng giải pháp (solution) để giải quyết vấn đề hoặc đạt được mục tiêu. Các yêu cầu thường được phát triển trong quá trình bắt đầu dự án. Dự án hiểu đơn giản là các sản phẩm dịch vụ duy nhất. Vì vậy không thể mang yêu cầu của dự án này sang áp dụng cho dự án kia. Đó là lý do vì sao cần phải xây dựng yêu cầu cho từng dự án riêng biệt.

Requirement là gì

Theo định nghĩa một yêu cầu là:

  • Một điều kiện hoặc khả năng cần thiết của các bên liên quan để giải quyết vấn đề hoặc đạt được mục tiêu.
  • Một điều kiện hoặc khả năng phải được đáp ứng hoặc sở hữu bởi một giải pháp hoặc thành phần giải pháp để đáp ứng hợp đồng, tiêu chuẩn, đặc điểm kỹ thuật hoặc các tài liệu áp đặt chính thức khác.
  • Một tài liệu đại diện cho một điều kiện hoặc khả năng như trong (1) hoặc (2).

Như vậy yêu cầu không chỉ đến từ những nhà tài trợ với vài câu hỏi, hay từ những tập tài liệu. Yêu cầu đến từ rất nhiều nguồn như những người liên quan (stakeholder), tài liệu (document), hệ thống (systems)… Do đó bài toán đặt ra là làm sao có thể khám bá được yêu cầu của những người liên quan?

Làm sao khám phá được Requirement

Để có thể khám phá được yêu cầu bạn cần phải xác định những những nguồn yêu cầu và người liên quan. Từ đó bạn lập chiến lược tiếp xúc và tiếp cận để phát triển và khai thác tối đa thông tin từ những nguồn yêu cầu này.

Các hoạt động trước khi tiến hành khám phá yêu cầu

Xác định nguồn yêu cầu

Mục đích của việc này nhằm đưa ra các danh sách về các tài liệu, hệ thống, con người có liên quan đến dữ liệu đầu vào ban đầu trong dự án. Đây là một danh sách quan trọng vì nếu bỏ qua nó chúng ta có thể bỏ sót các vấn đề của dự án mà chưa tính toán trước hoặc có thể dính dáng cả tới vấn đề pháp lý…

Hãy tưởng tượng rằng nguồn yêu cầu giống như thành phần của một công thức, bạn có thể vẫn làm ra được một chiếc bánh từ việc không bỏ đường vào bánh. Nhưng nó thực sự không còn vị cực ngon như mong muốn nữa.

Chiến thuật cho nguồn yêu cầu

Hãy bắt đầu từ một danh sách nhỏ, sau đó phát triển nó lớn dần lên. Ví dụ bạn có thể bắt đầu bằng cách chỉ liệt kê tên bộ phận, phòng ban trước và sau đó bạn có thể mở rộng thêm bằng cách tìm thêm những thành viên của phòng ban đó vào sau. Sau khi thảo luận cùng trưởng ban của phòng ban đó thì bạn có thể lựa chọn những người phù hợp và có quan điểm tốt nhất về dự án.

Dưới đây là một số ví dụ về các nguồn yêu cầu:

Stakeholder Source

Những nhà tài trợ luôn được lựa chọn là những stakeholder đầu tiên trong nguồn về stakeholder. Tuy nhiên, còn rất nhiều những stakeholder quan trọng khác nữa. Vậy làm sao để tìm ra họ? Họ là những người sẽ trả lời cho các câu hỏi sau:

  • Ai là người sử dụng giải pháp này?
  • Ai là người vận hành giải pháp này?
  • Còn ai sẽ tham gia vào dự án này nữa?
  • Ai đang bị ảnh hưởng bởi những vấn đề chưa có giải pháp ngày hôm nay?
  • Ai sẽ ảnh hưởng bởi giải pháp của dự án trong tương lai?
  • Ai là stakeholder của chương trình lớn hơn mà dự án này chỉ là một phần?
  • Ai là stakeholder của cả những dự án khác nữa?

Để trả lời những câu hỏi trên bạn phải đi hỏi xung quanh bạn, hỏi sếp, hỏi quản lý dự án, hỏi những nhà phân tích kinh doanh khác… Bằng cách đặt câu hỏi với mọi người, bạn sẽ có được rất nhiều thông tin về stakeholder.

Document resources

Các nguồn tài liệu thường phụ thuộc vào nguồn stakeholder. Những thông tin cơ bản thường được đưa vào tài liệu để làm thông tin đầu vào khi bắt đầu dự án. Chúng không mang được những thông tin chất lượng cao như nguồn stakeholders. Tuy nhiên đây là một điểm khởi đầu tốt. Bằng cách thu thập tất cả tài liệu từ các stakeholders như tài liệu yêu cầu chức năng, tài liệu yêu cầu thị trường, tài liệu yêu cầu về sản phẩm… Không có cách nào khác, bạn phải đọc hết tất cả những tài liệu đó.

System resources

Đây cũng là một loại tài liệu phụ so với nguồn stakeholders. Tránh sa đà vào loại nguồn này quá nhiều ngay từ đầu vì sẽ rất mất thời gian và thường chưa hiểu hết ngay được những gì đang diễn ra. Nhưng chúng lại thực sự rất hữu ích khi bắt đầu trong trường hợp bạn thiết kế một hệ thống “vĩnh cửu” cần sự đầu tư rất lớn. Thông thường loại nguồn này được dùng khi không ai biết và cũng không có tài liệu nào mô tả đầy đủ cách thức hoạt động của hệ thống. Hoặc đôi khi bạn cần nó để xác nhận lại những gì mà các stakeholder đã nói khi có xung đột xảy ra…

Loại nguồn này còn hữu ích trong trường hợp kiểm tra hệ thống bên ngoài. Giả sử một stakeholder nói với bạn rằng: chúng tôi muốn có một chức năng tìm kiếm X và chúng tôi thích những gì đối thủ của chúng tôi làm với X, Y, Z… Lúc đó bạn sẽ dùng nó để kiểm tra các loại X, Y, Z kia là cái gì.

Phân loại Stakeholder

Các stakeholder không giống nhau, họ đảm nhận vai trò và trách nhiệm trong dự án khác nhau nên cần được đối xử khác nhau. Nhưng có những dự án có tới hàng trăm stakeholders, chúng ta không thể lần lượt đáp ứng nhu cầu của từng người được. Đó là lý do chúng ta đưa ra khái niệm Stakeholder Classes.

Vậy Các lớp stakeholder được chia theo những tiêu chí gì?

Thương thì sẽ dựa vào nhóm phát sinh theo nhu cầu (ad hoc groupings) của một số người có các nét đặc trưng giống nhau để chia thành các lớp stakeholder như sau:

  • Khách hàng
  • Senior manager
  • Project team

Tại sao phải làm điều này ? Để chắc chắn rằng các bên liên quan được phân loại đầy đủ theo mức độ quan trọng đối với dự án và được đối xử một cách thích hợp. Vì bản thân mỗi người có ý nghĩa để sử dụng trong mỗi kịch bản khác nhau.

Một số mô hình giúp phân loại stakeholder.

Model 1: Wiegers

Mô hình này đặc biệt liên quan đến người dùng của một hệ thống phần mềm, có thể dễ dàng mở rộng hoặc sửa đổi để xử lý người dùng.

  • Favored: Những người dùng quan trọng nhất của hệ thống là những người sẽ chú ý rất nhiều vào hệ thống và hệ thống thiết kế ra để phục vụ họ. Làm thế nào để xác định được những người ủng hộ? Trả lời dựa trên một số đặc điểm sau để đi tìm họ:
  • Functions Used: Là những người sẽ sử dụng các chức năng mà dự án thiết kế
  • Access privileges: Những người dùng khác nhau có đặc quyền truy cập khác nhau. Điều này thường thấy khi chia theo dạng Admin và user.
  • Task performed: Nếu có các use cases ít quan trọng hơn cho một hệ thống, có thể giảm tầm quan trọng của các stakeholder trong các trường hợp đó về kinh nghiệm hoặc chuyên môn khi xếp vào class.
  • Experience/Expertise: Đây có thể là kinh nghiệm hoặc chuyên môn trong hệ thống hoặc công việc của họ. Ví dụ, tập trung vào các yêu cầu của dự án để thu thập những người dùng có kinh nghiệm cao, sau đó kiểm tra các kinh nghiệm đó trên những người dùng ít kinh nghiệm hơn để xem các chức năng đó dễ hiểu như thế nào.
  • Frequency of Use: Đối xử với người dùng khác nhau tùy thuộc vào tần suất họ sử dụng hệ thống khác nhau.

Model 2: RACI

RACI là một phương pháp hai chiều để phân loại các cá nhân các bên liên quan chứ không phải các nhóm. Nó được gọi là ma trận RACI.

Mô hình này liệt kê danh sách các stakeholder bên trái cùng các yêu cầu chức năng đang diễn

Model 3: Power Interest

Đây cũng là mô hình hai chiều, nó được sử dụng chủ yếu để bạn sắp xếp độ yêu tiên với các stakeholder và giúp bạn tìm cách để giao tiếp với họ

Các phương pháp phát triển yêu cầu

Phương pháp phỏng vấn trực tiếp 1-on-1

Phương pháp phổ biến nhất là lắng nghe yêu cầu của các bên liên quan theo phong cách phỏng vấn 1-1. Đây là một phương pháp tốt cho việc bắt đầu giai đoạn phân tích khi bạn đang cố gắng tìm hiểu và xử lý các vấn đề, nhu cầu của tổ chức, dự án.

Phương pháp phỏng vấn 1-1 để phát triển yêu cầu

Phương pháp này khuyên dùng với: nhà tài trợ, các chuyên gia, các stakeholder kinh nghiệm.

Nó cũng hay được dùng khi mà có các chủ đề gây tranh cãi, hiểu nhầm.

Nhược điểm của phương pháp này là nó sẽ kéo bạn vào vô vàn cuộc họp nếu dự án có nhiều stakeholders. Hơn nữa, bạn có thể sẽ bỏ lỡ một số góc nhìn về tinh thần nhóm và sự tương tác của các stakeholder khi họ ở bên nhau

Kỹ năng phỏng vấn là một kỹ năng cơ bản của một BA. Cần lưu ý 3 điều trong kỹ năng này là: chuẩn bị (preparing), lắng nghe (listening) và nói chuyện (speaking).

Preparing cần làm gì?
  • Tìm hiểu trước về người mà bạn sẽ phỏng vấn
  • Lập bản kế hoạch cho buổi phỏng vấn
  • Thử thực hành một số các biểu cảm, dáng điệu, thái độ của bạn
Lắng nghe thì làm gì?

Để trở thành một người phỏng vấn tốt thì kỹ năng lắng nghe phải thực sự được tăng cường phát huy trong các buổi phỏng vấn.

Một số tips dành cho những người mới bắt đầu như:

  • Cố gắng hiểu quá trình suy nghĩ của người được phỏng vấn trong lúc nói chuyện như: làm sao họ có thể tin được dự án này, làm thế nào họ xem nó như một giải pháp cho các vấn đề của họ… Tuy điều này được coi là rất khó nhưng nó lại mang lại tỉ lệ thành công cho buổi phỏng vấn rất cao.
  • Giữ tập trung vào người được phỏng vấn
  • Thể hiện phù hợp với năng lượng của người được phỏng vấn
  • Tôn trọng thời gian của họ
Kỹ năng nói chuyện như nào?

Một số hướng dẫn để bạn có thể rèn luyện kỹ năng này:

  • Đừng tiến hành một cuộc phỏng vấn. Hãy coi đây là một buổi nói chuyện. Nếu cả hai cùng thoải mái thì buổi nói chuyện sẽ có nhiều thảo luận hơn.
  • Luôn đặt câu hỏi mở
  • Đặc biệt chú ý thông tin bạn không hỏi mà họ tự đưa
  • Để họ có thời gian suy nghĩ câu trả lời
  • Cố gắng dùng chung ngôn ngữ với người được phỏng vấn
  • Bắt đầu với bức tranh toàn cảnh, rồi mới bẻ nhỏ câu hỏi để đi vào chi tiết sau.

Phương pháp Quan sát

Để thực hiện kỹ năng này, một số tip cho bạn như sau:

Quan sát một người hay một nhóm người thực hiện các công việc, nhiệm vụ của họ để hiểu rằng: họ đang làm gì, họ làm như thế nào và tại sao họ phải làm thế.

Sẽ là rất khác khi bạn nghe họ tả rằng họ nghĩ những việc họ đang làm là gì với thực tế đang diễn ra. Bạn sẽ học được rất nhiều thứ ở chỗ này.

Các kịch bản thường thấy trong việc quan sát là:

  • Quan sát ai đó thực hiện một nhiệm vụ của họ trong hệ thống
  • Quan sát việc họ thực hiện một bước trong tiến trình
  • Quan sát cách họ tương tác với những người còn lại trong hệ thống khi đang thực hiện nhiệm vụ của mình

Các tips để tiến hành việc quan sát:

  • Thực hiện một cách thoải mái. Hiểu là chúng ta ở đây là cùng nhau học và hiểu dự án.
  • Chú ý ghi lại từng bước họ đã làm
  • Xác nhận lại những gì bạn đã học được. Đặt các câu hỏi để chắc chắn rằng bạn đã hiểu đúng những gì bạn thấy.
  • Quan sát và hiểu tại sao họ phải dừng lại chỗ đó?
  • Biểu hiện khuôn mặt của họ ra sao khi thực hiện đến bước này?
  • Nhiều người cùng thực hiện một nhiệm vụ thì kết quả từng người như nào?

Việc quan sát có kết quả tốt sẽ có những câu hỏi mang tính chi tiết, hoặc hỏi về ngoại lệ của tiến trình. Ví dụ kiểu câu hỏi: bạn sẽ xử lý như nào nếu dữ liệu báo cáo hàng ngày của bạn bị trống? Tôi hiểu rằng bạn dừng ở đây vì đợi cô abc đẩy thêm một trường dữ liệu xyz sang để bạn hoàn thành báo cáo?

Phương pháp phỏng vấn nhóm - Group interview

Đây là một phương pháp nhằm dẫn dắt một nhóm người cùng thảo luận để hoàn thành mục tiêu đã đề ra.

Những hoạt động gì cần có khi sử dụng phương pháp này

1. Leading

  • Leading là khả năng định hướng buổi interview và giữ cho những người tham gia cùng thảo luận theo hướng đó.
  • Tôn trọng lẫn nhau: dù người tham gia có những ý kiến, quan điểm khác nhau thì luôn cần phải đảm bảo nhóm được duy trì sự tôn trọng lẫn nhau để phù hợp với quan điểm đa dạng mà mọi người tham gia nhất thiết phải có.

2. Hoàn thành mục tiêu

Luôn nhớ mục tiêu của buổi phỏng vấn là gì. Có thể là

  • Tập hợp các nhà tài trợ dự án và cách nhìn của họ về dự án
  • Học cách mà những Product Analytics chuẩn bị báo cáo của họ
  • Thu thập các vấn đề quản lý sản phẩm với quy trình chính xác.
  • Thu thập thông tin phản hồi chi tiết về giao diện người dùng hệ thống
  • Brainstorming về cách khắc phục những vấn đề để hợp lý hóa quy trình.
Những cân nhắc lập kế hoạch để phỏng vấn nhóm

Trả lời những câu hỏi sau để bổ sung vào bản kế hoạch cho buổi phỏng vấn:

  • Người tham gia:
  • Ai là người thực sự cần thiết được thêm vào buổi họp
  • Tối thiểu những người nào thì mới đạt được mục tiêu
  • Ai là người giúp bạn take note trong khi bạn đang dẫn buổi thảo luận
  • Thời lượng buổi họp
  • Có bao nhiêu chủ đề trong buổi họp này: nếu quá nhiều topic thì phải tính tới thời gian nghỉ giữa chừng để tránh quá tải với người tham gia.
  • Độ phức tạp của mỗi topic là như nào: những topic phức tạp thì sẽ có thời gian thảo luận dài hơn những topic đơn giản, dễ hiểu
  • Mỗi topic chỉ nên kéo dài tới bao lâu: Thời gian này chính là kỳ vọng để bạn có thể hiểu chính xác các yêu cầu của topic đó.
  • Số người tham gia là bao nhiêu

Ví dụ về cách tính độ dài buổi họp

Mục tiêu

  • Lấy phản hồi của các PM trên một quy trình báo cáo có sẵn -> What works, what doesn’t work?
  • Lấy những ý tưởng của họ về một quy trình tốt nhất có thể

Bước 1: Chọn người tham gia

Dựa trên sự quen thuộc của quy trình

  • 1 chuyên gia về quy trình
  • 1 người có chuyên môn trung bình
  • 1 người mới vào làm việc

Bước 2: Plan về buổi họp

  • Giả định số thời gian mà mỗi người tham gia sẽ thảo luận

Tổng thời gian có thể lên tới 58 phút. Vì vậy cần có buổi nghỉ giữa giờ để người tham gia không bị mệt mỏi, mất tập trung. Họ cần thời gian để nạp lại năng lượng. Một buổi họp lý tưởng thường diễn ra từ 30 -> 60 phút.

  • Location
  • Cuộc họp trực diện là cách hiệu quả nhất để lấy các requirements
  • Phòng họp phải thoải mái và đủ chỗ cho những người tham gia, họp remote phải có đủ slot cho người tham gia.
  • Materials
  • Lên kế hoạch về những thứ sẽ cần dùng trong buổi họp: màn chiếu, bảng trắng, bút viết, xóa bảng, giấy note…
  • Remote thì là tool remote, các chức năng cần có của tools
  • Agenda
  • Luôn luôn thông báo Agenda trước mỗi buổi họp
  • Tổ chức buổi thảo luận mà tạo cảm hứng cho người tham gia: Cách tổ chức tốt có thể đi qua một quy trình logic hoặc đi hết một list các use cases.
Quản lý cuộc thảo luận

Đây một thách thức với các BA và không dễ để hoàn thiện kỹ năng này. BA sẽ cần học và rút kinh nghiệm nó sau mỗi cuộc thảo luận.

Các chú ý trong việc quản lý buổi thảo luận

  • Các các hỏi được đưa ra giống nhau dù bạn đang có 1 người tham gia hay 20 người tham gia. Nên đang giữ cho người tham gia trả lời kết thúc mở càng nhiều càng tốt và khiến cho họ thực hiện phần lớn cuộc nói chuyện.
  • Giám sát người tham gia. Phải chắc chắn sẽ ai cũng tham gia góp phần để buổi họp diễn ra. Nếu không, hãy tạo câu hỏi và lắng nghe phần trả lời của những người không tham gia để tìm hiểu nguyên nhân và cách khắc phục.
  • Giữ mọi người trong topic. Tránh sa đà sang những phần thảo luận ngoài topic.
  • Quản lý thời gian thông qua công cụ time-boxing. Thiết lập thời gian cố định cho một topic. Ví dụ 10 phút/1 topic. Hết 10 phút thì có thể hướng mọi người sang chủ đề tiếp theo
  • Theo dõi lịch sắp xếp của buổi họp để tránh bỏ sót chủ đề chưa thảo luận. Nếu không đủ thời gian để bao quát hết các topic thì cần hẹn lịch một buổi họp khác để thảo luận thêm

Phương pháp Brainstorming

Theo Wikipedia:

Brainstorm là một phương pháp dùng để phát triển nhiều giải đáp sáng tạo cho một vấn đề. Phương pháp này hoạt động bằng cách nêu các ý tưởng tập trung trên vấn đề, từ đó, rút ra rất nhiều đáp án căn bản cho nó.

Để buổi brainstorming diễn ra hiệu quả, cần lưu ý một số vấn đề sau:

Lên kế hoạch cho buổi Brainstorming

Việc lên kế hoạch cho buổi Brainstorming rất quan trọng. Bạn cần tính toán, chuẩn bị trước một số đề mục sau:

  • Ai sẽ là người tham gia: Chỉ nên mời những người thực sự sẽ góp phần và việc xây dựng buổi brainstorm hiệu quả. Những người sau thì sẽ không cần có mặt:
  • Quá hiếu chiến, luôn chỉ trích và phân định thắng thua
  • Những người chỉ chờ đợi vào năng lượng của người khác để làm việc, không chủ động
  • Ngoài ra cũng cần phải suy nghĩ kỹ về việc có mời những người cấp rất cao trong tổ chức tới dự không vì thường sẽ khiến những người tham gia khác rè trừng, không dám đưa ra ý tưởng… khiến buổi họp không thực sự hiệu quả.
  • Địa điểm sẽ diễn ra buổi Brainstorming: Đây cũng là một điều quan trọng trong khâu lên kế hoạch. Hãy lưu ý một địa điểm thật sự có nhiều không gian và thoải mái để hỗ trợ người tham gia có thể nghĩ ra nhiều ý tưởng.
  • Nguyên vật liệu: Buổi brainstorming thường sẽ dùng rất nhiều bút để viết. sổ tay, giấy node, bảng trắng, xóa bảng… Bạn cần tính toán và chuẩn bị đủ với số lượng người tham ra phiên làm việc này
Khởi động những người tham gia

Khi bắt đầu phiên làm việc, cần chú ý 2 điều: :

  • Thứ nhất: Hãy bắt đầu bằng một tông giọng thực sự cởi mở, vui vẻ để những người tham gia có thể thực sự thư giãn nhất có thể. Bạn có thể thử một số game giải trí để không khí trở lên dễ chịu trước khi bắt đầu.
  • Thứ hai: Chia sẻ với mọi người các quy định của buổi brainstorming. Những buổi như này thường có rất nhiều quy định, nhưng tóm tắt lại thì thường thì có 5 quy định chính sau:
  • Không phán xét: Những người tham gia về cơ bản không được phép phán xét lẫn nhau và họ không được phép phán xét ngay cả chính họ.
  • Không nhận xét: Những người tham gia không nhận xét về ý tưởng của những người khác. Ví dụ: không được nói: ồ, cái này không thể nào chạy được đâu. Hoặc ngay cả việc khen: ôi, đây đúng là một ý tưởng cực kỳ hay" cũng không được phép.
  • Không sửa: Nếu có ý tưởng, bạn viết luôn xuống. Bạn không nên ngồi thêm để suy nghĩ về việc sửa nó cho hợp lý …
  • Không thực thi: Người tham gia không được phép nghĩ đến việc triển khai ý tưởng này như thế nào, thực thi nó ra sao trong lúc đưa ra ý tưởng… Chúng ta đang trong giai đoạn lấy ý tưởng nên không cho phép lo lắng về việc làm thế nào để thực hiện nó.
  • Không lo lắng: Người tham gia không cần lo lắng về viết ra những ý tưởng sẽ bị đồng nghiệp đánh giá là ngu dốt, là điên rồ, không hiểu biết.
Các hoạt động cơ học trong phiên làm việc

Trong suốt phiên làm việc, bạn cần tập trung vào việc tạo điều kiện cho nhóm hoạt động tốt nhất có thể. Một số hoạt động sau phải lưu ý:

  • Sử dụng Time-box: Điều này có nghĩa là bạn thiết lập một khoảng thời gian cho việc đưa ra ý tưởng (ví dụ 10 phút), một khoảng thời gian để tập trung nhìn lại ý tưởng (ví dụ 20 phút)… Luôn bấm bắt đầu để đồng hồ chạy và tắt khi đồng hồ kêu.
  • Ghi lại các ý tưởng: Đầu tiên bạn phải thu thập các ý tưởng lại với nhau rồi đưa lên bảng. Sau đó ghi lại vào một nơi. Thường dùng giấy note cho người tham ra viết lên ý tưởng sẽ giúp khâu này trở lên nhanh chóng và hiệu quả hơn. Khi tập trung ý tưởng, bạn chỉ việc dán giấy note lên bảng rồi phân loại ý tưởng bằng cách bóc ra dán lại. Thu thập các giấy notes sau buổi họp để xem lại.
Đánh giá ý tưởng

Sau khi tập trung tất cả các ý tưởng thì sẽ tiến hành khâu đánh giá. Đây là khâu cực kỳ quan trọng để mọi người trình bày ý tưởng của mình. Những người hay phê phán, chỉ trích nên được kiềm chế trong khâu này.

Một số điều cần lưu ý ở đây:

  • Về phương thức:
  • Cách 1: Cho phép mọi người bình chọn ra [x] ý tưởng trong tất cả các ý tưởng có vẻ hứa hẹn nhất để tiếp tục khâu đánh giá sâu sau đó. Điều này rất dân chủ và công bằng cho tất cả ý tưởng
  • Cách 2: Lần lượt đi qua từng ý tưởng, lưu ý phân tích các điểm có lợi và không có lợi của ý tưởng. Điều này đặc biệt hiệu quả trong trường hợp có ít ý tưởng được đưa ra.
  • Luôn nhớ rằng “Nếu có một ý tưởng đáng để làm thì chúng ta có thể phải tìm ra cách để làm nó”. Thông thường mọi người dễ từ bỏ những ý tưởng hay nhưng khó thực hiện trước khi họ tìm ra cách làm được chúng.
Nhìn nhận lại buổi brainstorming đã diễn ra như thế nào

Sau phiên làm việc với nhiều câu hỏi phải động não đối với những người tham gia, bạn cần nhìn nhận một mình hoặc với vài người tham gia để trả lời một số câu hỏi:

  • Mọi người có thoải mái, vui vẻ không? Nếu không, có thử cách khác để buổi họp diễn ra tích cực hơn không.
  • Bạn đã kết thúc mỗi câu hỏi với rất nhiều ý tưởng, đó đã thực sự là những kết quả chúng ta mong đợi chưa?
  • Tất cả mọi người đều tham gia chứ? Thái độ của họ trước và sau khi kết thúc phiên làm việc như thế nào?
  • Không khí buổi họp như thế nào? Làm sao để cải thiện nó tốt hơn?

Phương pháp JRP and JAD Sessions

Đến đây, chúng ta đang tiếp cận 2 phương phát rất thú vị, không chỉ thu thập các yêu cầu mà còn tổng hợp chúng thành tài liệu luôn. Chúng được gọi là JRP hoặc JAD. Chúng cung cấp cơ hội để có thể lấy thông tin đầu vào từ một lượng các stakeholder trong cùng một thời điểm và ghi chúng lại thành một tài liệu thực sự. Có thể hiểu dùng phương pháp này để ra được mục tiêu dạng high-level cùng với tài liệu về các yêu cầu này sau khi ra khỏi phòng họp.

JRP hay JAD thực chất là gì?

JRP (Joint Requirement Planning)JAD (Joint Application Design)Một nhóm có cấu trúc caoMột nhóm có cấu trúc caoTập hợp các stakeholders cùng nhauTập hợp các stakeholder cùng nhau (nghiêng về mặt kỹ thuật)Xác định yêu cầuXác định design ứng dụng (prototype)Làm thành tài liệu cho các yêu cầu đóCó được tài liệu về thiết kế

Chúng ta có thể chạy phiên làm việc JRP trước để tập hợp các yêu cầu và lấy tài liệu về chúng. Sau đó sẽ chạy phiên làm việc JAD để phát triển thiết kế sản phẩm hoặc ứng dụng.

Chuẩn bị

Sự chuẩn bị tốt sẽ chiếm gần một nửa thành công của phiên làm việc với JRP/JAD. Đó là các công việc mà người tổ chức sẽ thực hiện cho những người tham gia.

Thông thường người tổ chức có rất nhiều thứ phải chuẩn bị từ nửa ngày đến cả một tuần. Họ sẽ lên lịch trước đó khoảng vài tuần.

  • Đầu tiên là cần xác định mục tiêu của phiên làm việc một cách cụ thể. Nó có thể là một danh sách các yêu cầu chức năng và không chức năng của doanh nghiệp. Hoặc nó có thể là một danh sách các use cases được thiết kế chi tiết cho từng trường hợp. Hay nó có thể là một tập các prototypes được thiết kế.
  • Thứ hai, người tổ chức sắp xếp những người tham dự. Vì các phương thức này cần phân loại người tham dự một cách cụ thể. Kể cả việc sắp xếp cho người hướng dẫn (facilitator) ở vị trí nào.
  • Thứ ba, sắp xếp 2 BA tham dự để nắm rõ vấn đề và tránh thiếu sót
  • Thứ tư, sắp xếp những người tham gia: Người tham gia ở đây hầu hết là những người có chức năng dạng cross-function và là đại diện cho các bên liên quan của dự án.
Người tổ chức cần phải làm gì

Người tổ chức sau khi xác định được những người tham gia, họ cần phải:

  • Sắp xếp vị trí cho người tham gia
  • Chuẩn bị tài liệu cho buổi họp
Người tham gia cần phải làm gì
  • Đọc tất cả các tài liệu đã được phát trước buổi họp
  • Chuẩn bị các thông tin đầu vào ( kể cả từ những người liên quan mà họ đại diện)
  • Sẵn sàng để nói về các yêu cầu (đại diện lớp những người liên quan của họ)

Ví dụ: Tôi là đại diện của bên quản lý sản phẩm trên website được mời tới buổi họp. Tôi sẽ đọc hết tài liệu mà được gửi tới trước buổi họp để hiểu sâu sắc rằng nhu cầu dự án tôi tham gia sẽ ảnh hưởng tới trang web của tôi như thế nào. Tôi sẽ nói chuyện với những người quản lý khác là đồng nghiệp của tôi để cung cấp cho họ những thông tin của dự án và lắng nghe, thu thập yêu cầu từ phía họ. Tôi đang cố gắng đảm bảo rằng quan điểm của tôi là đại diện không chỉ cho tôi mà còn của lớp các bên liên quan mà tôi đại diện.

Vị trí tổ chức ở đâu

Nên tổ chức gặp mặt trực tiếp là tốt nhất để (tránh bị mất tập trung và người tham gia bỏ dở giữa chừng)

Đây là một ví dụ về việc sắp xếp vị trí cho người tham gia trong buổi họp này:

F - Người hướng dẫn điều phối cuộc họp

L - 2 BA (không thay thế cho nhau vì Họ ngồi ở hai đầu đối diện của chiếc bàn nên sẽ cho họ những quan điểm khác nhau về căn phòng giữa hai người họ. Họ có thể quan sát được ánh mắt, điệu bộ của bất kỳ người tham gia nào khi họ nói)

P - Những người tham gia

Parking Lot: là nơi để đặt các câu hỏi, các giả định, các vấn đề quan trong khi diễn ra buổi họp

Screen: là nơi để trình chiếu hầu hết thời gian về bản nháp mà mọi người đang thực hiện.

Thực hiện buổi họp
Người hướng dẫn (F)

Ngay khi bắt đầu:

  • Thiết lập nguyên tắc và chắc chắn mọi người trong phiên làm việc đều tuân theo
  • Thiết lập mục tiêu của buổi họp
  • Khuyến khích mọi người hợp tác, thảo luận cởi mở cả những vấn đề bất đồng quan điểm trong buổi họp

Trong cuộc họp:

  • Điều phối dự án theo một hướng tiếp cận từ trên xuống dưới:
  • Mục tiêu của dự án -> Các yêu kinh doanh -> Các yêu khác
  • Hoặc: Mục tiêu của dự án -> các yêu cầu kinh doanh -> use cases

Người điều phối phải tích cực làm việc để giữ cho mọi người tập trung đúng mục tiêu, tránh việc lan man sang những yêu cầu khác không liên quan tới dự án.

Vai trò của BA

Người đầu tiên: ngồi gần bục giảng, quản lý những gì được hiển thị trên màn hình. Họ chính là người

  • Ghi lại tất cả các yêu cầu.
  • Giao việc cho BA thứ 2

Người thứ 2:

  • Xử lý các công việc được ủy quyền từ BA thứ nhất
  • Sở hữu những danh sách những công việc cần phải hoàn thành trong buổi họp. Họ chịu trách nhiệm các hạng mục công việc, bằng cách này hay cách khác phải được giải quyết.
  • Theo dõi chất lượng của các yêu cầu
Vai trò của người tham gia
  • Đóng góp phần lớn các yêu cầu cho buổi họp
  • Trình bày đại diện các yêu cầu cho lớp người liên quan của họ
  • Lên tiếng, nếu họ thấy vấn đề và cần giải quyết các vấn đề đó luôn trong buổi họp
Các công việc sau phiên họp
  • Làm sạch các tài liệu: Tài liệu ban đầu có thể chứa đầy đủ các vấn đề ở dạng dữ liệu thô -> cần làm sạch dữ liệu để trình bày tốt hơn.
  • Tăng cường chất lượng yêu cầu: Việc dọn dẹp nên bắt đầu bằng việc tăng cường phân tích các yêu cầu về chất lượng đầu tiên
  • Dàn xếp các mâu thuẫn: Điều này đảm bảo các yêu cầu không mâu thuẫn với nhau
  • Xác định các lý do cho từng yêu cầu
  • Chỉ định truy xuất nguồn gốc với các yêu cầu: (ví dụ: Nếu bạn có yêu cầu thì chúng nên xuất phát từ yêu cầu kinh doanh, không thì sẽ được phân loại vào mục văn hóa…)
  • Rà soát tất cả các giả định, các vấn đề đã được giải quyết trước khi gửi tài liệu này đi.
  • Phân phát tài liệu tới tất cả các stakeholders để xác nhận lần cuối với những gì đã được thay đổi trong tài liệu
Kết thúc

Đây là một phương pháp tốn rất nhiều công sức nhưng cũng mang lại hiệu quả rất lớn nếu thực hiện chính xác vì được sự hợp tác của tất cả các stakeholders.

Tuy nhiên một câu hỏi lớn đặt ra là: Bạn có được trang bị để tạo điều kiện cho việc thực hiện phương pháp JRP và JAD không? Từ những gì thảo luận phía trên, nó không quá khó như bạn nghĩ, bạn hoàn toàn có thể thực hiện nó. Với phương pháp này cần một số kỹ năng như:

  • Thực sự tự tin: Kiểm soát các bên liên quan và điều hành cả quá trình một cách chặt chẽ
  • Sử dụng quen thuộc các quy trình
  • Kỹ năng tạo điều kiện nhóm vững chắc
  • Có tầm nhìn cho các yêu cầu sản phẩm (Bạn phải có khả năng hình dung tài liệu cuối cùng đó sẽ trông như thế nào và sau đó liên tục dẫn dắt nhóm để phát triển sản phẩm đó)
Nếu bạn là một IT Business Analyst, ưa thích làm sản phẩm quốc tế trong lĩnh vực bán lẻ - thương mại điện tử! Tham gia Tuyển dụng Business Analyst, môi trường làm việc từ xa, địa điểm tự do, quản lý linh hoạt theo Agile.

Hãy đăng ký nhận tin để là người đầu tiên đọc bài viết mới nhất từ chúng tôi nhé

Posted 
Jul 4, 2020
 in 
Business
 category

Bài viết khác từ

Business

category

View All