Đôi khi 1 ngàn câu nói không bằng 1 tấm hình. Não người có vẻ ưu ái hơn đối với việc xử lý hình ảnh so với xử lý ngôn ngữ. 20 trang giấy của 1 chuyên đề phức tạp có thể được gói gọn vào 1 vài hình ảnh minh họa.
Làm BA, bạn sẽ phải đối mặt với rất nhiều stakeholder với nhiều background khác nhau. Người thì làm kỹ thuật, người thì chỉ chuyên bán hàng, người thì làm sổ sách kế toán. Bạn cần tạo ra 1 thứ ngôn ngữ phổ thông nhất với tất cả người đọc của mình. Và các sơ đồ, mô hình, bảng biểu là 1 thứ hình ảnh biết nói. Thống nhất các ý tưởng trên 1 trang giấy. Dễ dàng trong quá trình confirm, mô tả bức tranh tổng thể.
Ok, giờ thì bắt đầu. Hãy chọn 1 ví dụ xuyên suốt cho bài viết này để các bạn dễ hình dung: Project xây dựng 1 website bán hàng.
1. System context diagram – SCD
Lược đồ ngữ cảnh hệ thống – hay SCD, là sơ đồ có mức độ tổng quát cao nhất trong các sơ đồ được trình bày dưới đây.
SCD giúp gì?
Thường thì chiêu này sẽ dùng ở đầu mỗi tài liệu lớn, hoặc ở đầu 1 phân mục phức tạp. Vai trò của nó giống như 1 cái mục lục, giúp người đọc hình dung họ sắp đọc cái gì, và chúng nó liên kết với nhau như thế nào trong một bức tranh lớn.
Hãy tưởng tượng bạn đi du lịch ở 1 khu rừng xa lạ và bị lạc đường. SCD sẽ giống 1 cái địa đồ. Nhìn vào bạn sẽ biết được:
Các hướng đông, tây, nam, bắc và các cột mốc địa lý quan trọng (dòng suối, ngọn núi…);
Bạn đang đứng ở đâu giữa khu rừng này 1 cách tương đối;
Bạn nên đi theo hướng nào để mò ra khỏi khu rừng.
Lược đồ ngữ cảnh cũng vậy, nó là 1 cái bản đồ tổng quát cho bất kỳ ai đang lặn ngụp trong hệ thống. Nhìn vào đây bạn sẽ thấy được luồng thông tin (ở mức tổng thể) chảy ra và vào hệ thống như thế nào. Bạn sẽ không thấy được tính năng hay mô tả tính năng gì quy trình gì trong này hết.
Cách vẽ SCD
Phạm vi
1 SCD cho toàn hệ thống, hay chỉ cho 1 hệ thống con.
Chọn phạm vi phù hợp với tài liệu bạn đang viết. Ví dụ:
Tài liệu BRD tổng quan cho toàn dự án Xây dựng website X. Khi đó phạm vi system là System của website X.
Hoặc bạn viết tài liệu riêng cho phần CMS (trang quản lý nội dung) thôi thì phạm vi systemt lúc này là CMS System
Và bạn sẽ có input cho bước tiếp theo.
Đối tượng dữ liệu
Trung tâm
Đã xác định được phạm vi thì ngay lập tức bạn xác định được cục nằm ở trung tâm sơ đồ. Đó chính là ngữ cảnh hệ thống.
Chỉ có 1 cục đó thôi. Ở ví dụ này gọi chung là system luôn, gộp hết Website + CMS lại.
Đối tượng dữ liệu:
Hình dung xem đối tượng nào cung cấp dữ liệu đi vàosystem
Và system cung cấp dữ liệu ra cho đối tượng nào.
Dòng chảy dữ liệu
Từ đối tượng đã xác định, tiếp tục hình dung:
Họ sẽ đổ dữ liệu vào hệ thống qua hành động nào: Vẽ mũi tên từ Đối tượng → Hệ thống. Ghi tên hành động đó (Động từ + Danh từ).
System cung cấp dữ liệu gì cho họ: Vẽ mũi tên Hệ thống → Đối tượng. Ghi tên dữ liệu đó (Danh từ)
Rồi, tô màu và sắp xếp lại cho các khối. Cap màn hình lại và dán vào tài liệu thôi.
Đọc tiếp phần sau cho loại diagram thứ 2 ở đây nhé
1 BA mới thường sẽ gặp vấn đề với việc lấy yêu cầu khi tham gia những dự án đầu tiên mà không được hướng dẫn bởi 1 leader. 1 ví dụ như sau:
Ở công ty em không có 1 quy trình lấy requirement chính thức nào cả. Em toàn phải đi lượm lặt requirement từ các buổi họp của 1 ai đó: 1 buổi brainstorm, 1 buổi design review hay buổi break down funtion… Mà thường các buổi họp đó cũng ngắn ngủn, thường gói gọn trong 1 tiếng đồng hồ, em muốn đặt thêm mấy câu hỏi để làm rõ requirement cũng không được. Cũng chẳng có ai confirm requirement một cách chính thức. Đến cuối cùng thì không thấy được bức tranh tổng thể và các requirement cũng không được ghi lại đầy đủ, đúng đắn.
1. Làm rõ vai trò của bạn trong dự án
Gốc rễ của vấn đề này là bạn thiếu hình dung được vai trò của mình trong dự án, có thể bạn chưa vạch ra được 1 BA Plan cụ thể khi tiếp nhận dự án ở những ngày đầu tiên. Hãy đảm bảo thực hiện việc đó.
Chẳng phải vai trò của BA là lấy requirement, viết doc, rồi chuyển giao thành Fuctional spec sao. Thực ra không có 1 vai trò cố định cho BA với tất cả các dự án. Mỗi dự án có thể sẽ yêu cầu mức tham gia của bạn ở mức độ khác nhau. Việc của bạn là xác định rõ phạm vi đó. BA không nắm được vai trò của mình trong dự án sẽ có xu hướng deliver những thứ mà stakeholder không thật sự cần và đầy thiếu sót.
Hãy làm việc với những người sau để có được thông tin cần thiết về vai trò của mình:
Business stakeholder
PM hoặc manager
BA lead (nếu có)
Dev team
Để có thể biết được mình đóng vai trò gì, output mình cần tạo ra là gì, bạn cần phải chịu trách nhiệm cho những nhiệm vụ nào. Từ đó, bạn có thể có được BA Plan, làm theo kế hoạch để tránh sự lạc lối xuyên suốt dự án.
2. Chủ động trong quy trình lấy requirement
Requirement là thứ input bạn cực kỳ thèm thuồng, vậy thì bạn phải cực kỳ chủ động tìm kiếm nó. Đừng gò ép vô những quy trình của team hay của công ty. Đừng chen chúc vào các buổi họp eo hẹp thời gian của 1 ai đó để lần mò requirement. Hãy chủ động setup, book meeting, gửi mail cho stakeholder để mời meeting khi bạn thực sự cần. Chuẩn bị cho các buổi họp đó thật kỹ lưỡng để có thể có 1 buổi họp thật hiệu quả và tập trung.
Nắm quyền chủ động kiểm soát các thông tin và chủ đề thảo luận trong buổi họp. Chuẩn bị sẵn những câu hỏi, để chắc chắn lấy được thông tin mà bạn cần.
Hãy chắc chắn rằng bạn tập trung vào 1 vài vấn đề cụ thể. Nếu stakeholder bắt đầu lệch hướng, hãy nói rằng “Em sẽ setup 1 buổi meeting nữa để thảo luận về vấn đề này”. Hãy đảm bảo buổi họp đầu tiên sẽ thực sự năng suất.
3. Validate và review requirement
Đừng quên làm động tác quan trọng này. 1 vài câu hỏi và vài buổi lấy requirement chắc chắn không thể đủ. Nếu bạn dựa hoàn toàn vào đó thì đảm bảo là sẽ thiếu đầu thiếu đuôi. Hãy tổng hợp thông tin đã có, thông tin chưa có thì có thể meeting để lấy tiếp hoặc giả định 1 cách cẩn thận. Và đem mớ thông tin ấy tổng hợp thành document và đưa cho stakeholder validate 1 lần nữa.
Đó không cần là 1 buổi mài đít 5 tiếng trong phòng họp, review 50 trang document. Việc đó sẽ làm stakeholder kiệt sức và né tránh việc ngồi với bạn trong tương lai. Đôi khi cách này sẽ giúp ích, nhưng nó không phải là cách làm hiệu quả nhất.
Bạn có thể dùng các công cụ như: review Wireframe, workflow, sơ đồ use case… Bất cứ cách nào dùng để capture requirement và mô hình hóa một cách ngắn gọn cách hiểu của bạn đối với những vấn đề đang nói tới. Chỉ cần stakeholder sơ lược qua tài liệu mà bạn tạo ra và validate thông tin trong đó thì xem như việc phân tích đã hoàn thành
Đó là lúc bạn nhận được câu trả lời “ Đúng rồi, nhưng mà…” từ stakeholder, người sẽ cho bạn thêm những requirement mới mà bạn đã bỏ lỡ
Bạn có thể sẽ gặp chút ráng cự từ stakeholder, họ chỉ cho bạn 1 thời gian rất ngắn ngủi trên lịch trình của họ, sau đó hy vọng BA tạo ra 1 document requirement rõ ràng từ không khí. Hãy giải thích giá trị của bạn một cách rõ ràng. Việc làm rõ vai trò của mình ở bước 2 cũng là 1 cách để stakeholder hiểu được đây là những việc bạn phải làm để hoàn thành vai trò mà họ kỳ vọng bạn mang lại cho dự án.
Khi mới vào nghề, chúng ta có xu hướng bắt đầu từ các kỹ thuật BA, học cách viết các tài liệu và làm sao để lấy yêu cầu. Bạn gặp may nếu ở công ty của mình cádfasdfó 1 quy trình chuẩn, 1 người leader luôn nói cho bạn biết phải làm gì.
Bạn không biết lý do tại sao mình làm việc này ở thời điểm này. Bởi vì bạn không có 1 cái nhìn toàn cảnh về những gì BA phải làm – 1 bộ khung công việc của BA, aliền với vòng đời của dự án.
Giai đoạn 1: Định hướng
Đây là bắt đầu bước vào 1 dự án mới hoàn toàn hoặc đã được bắt đầu trước đó. Chúng ta sẽ có rất nhiều câu hỏi mơ hồ trong đầu kiểu: Dự án này là gì? Tại sao cần làm dự án này? Đó là những câu hỏi tổng quan đầu tiên và việc của bạn là tìm 1 câu trả lời rõ ràng.
Đừng vội đi vào chi tiết quá sớm. Bạn muốn bắt tay ngay vào tìm vấn đề và làm giải pháp ngay từ ngày đầu tham gia dự án. Nhưng điều đó rất dễ khiến mọi thứ chệch hướng hoàn toàn.
Đây là thời điểm để bạn tìm hiểu về những điểm còn mù mờ trong dự án, những thứ mà “bạn không biết là mình không biết”.
Những câu hỏi bạn cần trả lời và việc cần làm trong giai đoạn này:
Dự án này là gì? Mục tiêu lớn nhất của nó là gì?
Vai trò của bạn trong dự án là gì? Bạn cần tạo ra những output nào để đáp ứng nhu cầu của stakeholder.
Các stakeholder chủ chốt là ai? Bạn sẽ tiếp cận họ như thế nào để lấy business goal và xác định scope của dự án?
Nắm được tình hình dự án cho đến thời điểm hiện tại. Tránh việc làm lại những thứ đã được làm rồi.
Hiểu được những thứ hệ thống đang có và những gì hệ thống làm được
Bạn có thể vượt qua giai đoạn này nhanh chóng bằng cách phương pháp gợi ý sau:
Trân trọng những buổi brief mà stakeholder, PM hoặc PO dành cho bạn, cố gắng khai thác và hỏi càng nhiều càng tốt.
Nhanh chóng xác định được stakeholder chủ chốt và tạo kết nối tốt với họ. Tận dụng việc trao đổi thông tin với họ cả trong các buổi họp chính thức và các cuộc trò chuyện không chính thức (1 buổi ăn trưa hay chầu cafe).
Đọc tài liệu: lục tìm, hỏi xin tất cả tài liệu có sẵn của dự án để hiểu hơn về dự án. Tất nhiên, hãy cẩn thận những tài liệu outdate và không còn sát với thực tế.
Giai đoạn 2: Xác định nhu cầu business
Khi đã có được những thấu hiểu cơ bản về dự án. Bước tiếp theo đó là xác định Business Goal. Đây là loại input quan trọng nhất để đảm bảo dự án không lệch hướng trong tất cả giai đoạn tiếp theo.
Technical team có thể đảm bảo việc sản phẩm cho ra đáp ứng được Product Backlog. Nhưng BA sẽ là người chịu trách nhiệm đặt vào backlog những tính năng, những story giúp giải quyết Business Goal. Đó chính là kim chỉ nam của dự án.
Những gì cần làm trong giai đoạn này:
Xác định Goal theo từng cấp độ:
Business: Cấp độ cao nhất, là vấn đề/nhu cầu cốt lõi mà dự án phải giải quyết hoặc đạt được. Thường được đưa ra bởi các stakeholder có quyền quyết định cao nhất trong dự án.
User: Những mục tiêu cụ thể hơn cần đạt để hoàn thành Business goal. Thường đưa ra bởi những người sẽ trực tiếp sử dụng sản phẩm mà dự án tạo ra.
Function and Non-function: Những yêu cầu sơ lược hơn về mặt tính năng hoặc phi tính năng mà hệ thống cần đảm bảo. Thường đối với những dự án mà client là những tổ chức lớn, chuyên nghiệp. Ngoài việc dự án đáp ứng các business goal và user goal thì còn có thêm các tiêu chí mà sản phẩm phải đảm bảo khi bàn giao.
Bạn có thể bắt đầu tạo tài liệu BRD từ những nhu cầu này.
Luôn confirm lại cách hiểu của bạn với stakeholder để chắc chắn không hiểu sai. Đây là 1 input rất quan trọng.
Giai đoạn 3: Xác định phạm vi thay đổi
Một phạm vi dự án đã được thông qua bởi các stakeholder là thứ giúp cho bạn và team “an tâm” suốt dự án.
Phạm vi nghĩa là định ra biên giới giữa cái “Phải làm” và cái “Không làm”. Tất nhiên việc tuyệt đối rõ ràng như trắng và đen là bất khả thi. Sẽ luôn có 1 vùng xám “Nên làm” hoặc “Có thể sẽ làm”. Nhưng việc có một hình dung về quy mô dự án sẽ giúp team không đi quá xa khỏi vòng tròn này.
Những gì cần phải làm trong giai đoạn này:
Bắt đầu tìm hướng tiếp cận giải pháp cho các vấn đề/nhu cầu. Đánh giá xem quy trình và công nghệ sẽ phải thay đổi như thế nào về mặt bản chất để đáp ứng Business Goal.
Tạo ra những bản phác thảo về phạm vi dự án và liên tục trình bày cho stakeholder chủ chốt cả phía business và phía technical – cho đến khi họ sẵn sàng để ký và thông qua Scope Statement.
Giai đoạn 4: Lập kế hoạch BA chi tiết
Một kế hoạch BA chi tiết xác định các kết quả cụ thể mà BA cần tạo ra cùng với một ước tính thời gian hoàn thành. Dự án sẽ cần output gì từ bạn để có thể làm rõ yêu cầu từ business và công việc tiếp theo cần thực hiện.
Nhiệm vụ của giai đoạn này:
Chọn được các format output phù hợp để làm rõ requirement. Việc lựa chọn phụ thuộc vào phạm vi dự án đã định nghĩa ở bước 3, dự án chạy theo kiểu waterfall hay agile, nhu cầu của technical team và các yếu tố khác của dự án.
Xác định được danh sách cụ thể các kết quả BA cần đạt và những stakeholder sẽ tham gia và hỗ trợ quá trình thực hiện. (template excel cho BA Plan)
Xác định thời gian thực hiện mỗi task.
Nếu không dành thời gian ra để tự lập 1 kế hoạch thực tế và đáng tin cậy thì sẽ có hàng tá kỳ vọng từ stakeholder được gán cho bạn. Thường là những kỳ vọng bất khả thi vì họ không đánh giá đầy đủ được tính phức tạp đến từ nhu cầu.
Giai đoạn 5: Viết detail requirement
Bắt đầu từ giai đoạn này, BA sẽ liên tục giao tiếp với các stakeholder để elicite requirement về các tính năng hoặc quy trình cần thay đổi. Mục đích là viết ra các tài liệu mô tả chi tiết requirement. Đây là output trực tiếp nhất mà team technical cần để phát triển tính năng.
Requirement cần đạt được các yếu tố: cụ thể, đầy đủ và chính xác. Requirement không đầy đủ sẽ dẫn đến việc team triển khai ngụp lặn trong mơ hồ và chắc chắn ảnh hưởng kết quả đầu ra.
Những gì cần làm ở giai đoạn này:
Thực hiện liên tục việc Elicite stakeholder, có được thông tin cần thiết để thực hiện thay đổi.
Phân tích các thông tin thu thập được và chuyển hóa nó thành các tài liệu chi tiết cần cho dự án
Xác nhận các tài liệu đã có với business stakeholder và technical stakeholder để bổ sung những thiếu sót nếu có.
Mức độ hiệu quả mà tài liệu do BA tạo ra sẽ nói lên mức độ hiệu quả của BA đó. Những tài liệu hữu hiệu có giá trị đẩy dự án tiến về phía trước nhanh chóng.
Chú ý đến việc làm rõ những thứ mơ hồ, cắt gọn những gì phức tạp. Hướng tới những cột mốc nhỏ và hoàn thành 1 cách liên tục.
Giai đoạn 6: Hỗ trợ technical team
Giai đoạn 6 yêu cầu BA có sự tham gia vào quá trình team phát triển sản phẩm thực hiện dựa trên requirement đã có.
Những gì cần thực hiện
BA review các bản thiết kế cho giải pháp, đảm bảo giải pháp đó đang đi đúng hướng requirement đã mô tả. Ngoài ra, có thể gợi ý thêm giải pháp giúp đáp ứng những nhu cầu mở rộng của dự án mà không làm tăng phạm vi kỹ thuật.
Cập nhập, chia nhỏ hoặc đóng gói các tài liệu requirement chi tiết để phù hợp hơn trong quá trình phát triển.
Tương tác với chuyên viên kiểm soát chất lượng (QA) để đảm bảo là họ hiểu đúng hướng về requirement. Có thể review qua test plan và test case để đảm bảo đã hiểu rõ nhu cầu.
Sẵn sàng trả lời khi có ai đó đặt câu hỏi trong suốt quá trình thiết kế giải pháp, lập trình, test của dự án.
Quản lý các yêu cầu thay đổi, đảm bảo các stakeholder liên quan đều tham gia vào quá trình quyết định thay đổi và tiếp cận với tài liệu mới nhất.
Nếu có thể, BA sẽ là người lead các buổi UAT (User Acceptance Testing) để đảm bảo sản phẩm đáp ứng nhu cầu business.
Giai đoạn 7: Hỗ trợ business triển khai giải pháp
Sau khi team technical của bạn đã tạo ra 1 sản phẩm xịn sò, đáp ứng mọi nhu cầu business rồi. Nhưng business user không sử dụng sản phẩm đó đúng cách và quay trở lại quy trình, thói quen làm việc cũ. Như vậy sẽ gây lãng phí nguồn lực và không giải quyết được nhu cầu business ban đầu.
BA sẽ phải tham gia luôn vào công đoạn cuối cùng của dự án để hỗ trợ business:
BA cần phân tích và xác định rõ business process sẽ phải thay đổi như thế nào để đáp ứng sự thay đổi mà project đã tạo ra.
Hướng dẫn, huấn luyện end-user để chắc chắn họ nắm luồng mới và các thủ tục cần thiết. Hoặc nếu có chuyên viên training riêng biệt thì BA sẽ phối hợp với bộ phận này để tạo ra các tài liệu và chương trình huấn luyện phù hợp.
Những bước ở trên đây là để đảm bảo tất cả các business user sẵn sàng tiếp nhận sự thay đổi được tạo ra bởi dự án
Giai đoạn 8: Đánh giá giá trị giải pháp
Tất cả mọi công đoạn chi tiết của dự án đã hoàn thành, kỳ vọng business đã được thảo luận, những vấn đề cả lớn lẫn nhỏ đã được giải quyết, các mối quan hệ đã được xây dựng, thay đổi đã được quản lý, kỹ thuật đã triển khai, người dùng đã được huấn luyện để sử dụng.
Hàng đống công việc và tập trung vào kết quả đầu ra có thể khiến cho chúng ta mất đi cái nhìn tổng thể. Liệu chúng ta đã và đang đi đúng hướng chứ? Giải pháp mà chúng ta tạo ra có đáp ứng được những kỳ vọng business như đã dự kiến?
Nhiệm vụ chính của giai đoạn này là:
Đánh giá tiến độ thực sự của dự án dựa trên mục tiêu business để thấy được những kỳ vọng nào đã được đáp ứng.
Trao đổi kết quả tiến độ với project team
Đề xuất thêm các giải pháp cho những vấn đề mới phát sinh trong quá trình thực hiện project.
Áp dụng Framework vào dự án của bạn
Đa số BA thường không có 1 khung sườn cụ thể vì dường như mỗi dự án lại đòi hỏi 1 nhiệm vụ và quy trình làm việc khác nhau. Việc không có framework khiến bạn phải luôn nghĩ về việc mình phải làm gì tiếp theo, phải tự “bịa” ra một nhiệm vụ mà bạn cho là phù hợp.
Với 1 Framework gợi ý như trên, bạn sẽ có 1 chỉ dẫn sơ lược nhất về những gì cần thực hiện xuyên suốt 1 dự án công nghệ.
Bạn hoàn toàn có thể thay đổi và áp dụng 1 cách linh hoạt Framework trên để thật sự match với quy trình làm việc của mình.
Khi bạn tham gia 1 dự án kể từ lúc nó bắt đầu. Có rất nhiều việc để làm với vai trò BA. Bạn nhận yêu cầu từ PM nhà bạn bảo rằng đây là ưu tiên số 1 bây giờ. Đọc qua 1 hồi file brief mà user gửi và…chẳng hiểu gì hết.
Bạn đang setup việc gặp stakeholder để hỏi 1000 câu hỏi vì sao và chuẩn bị cho các bước tiếp theo. Bỗng nhiên PM ghé qua hỏi 2 câu rất chí mạng: “Em nghĩ tầm bao lâu thì xong phân tích? Khoảng 1 tuần không?”. Sếp neo luôn cái mốc này và cho rằng có vẻ như là đủ để hoàn thành việc phân tích trong thời gian này. Tự nhiên bạn sẽ cảm thấy nhức nhức cái đầu, tim đập loạn xạ, hơi thở bắt đầu gấp gáp hơn. Nhưng tạm thời để cái estimate đó sang 1 bên đã. Hãy hít một hơi thật sâu và … câu giờ.
Cả bạn và PM đều biết rằng, đây là 1 dự án hoàn toàn mới, người dùng mới, hệ thống mới. Sẽ chẳng thể cam kết 1 con số hợp lý nào cả cho đến khi chúng ta hiểu rõ hơn về dự án. Ít nhât, bạn sẽ cần hiểu rõ phạm vi dự án và team kỳ vọng bạn phân tích và deliver ở mức độ chi tiết như thế nào. Đây là 1 lý do hợp lý để kéo thêm thời gian, mà từ đó bạn có cơ hội xử lý các bước tiếp theo.
Hiểu rõ hơn về stakeholder
Hãy chắc chắn rằng bạn biết rõ tất cả các stakeholder mà bạn cần phải “va chạm” trong dự án. Biết được cách mà họ làm việc với BA trong những dự án trước đó. Hỏi họ những câu hỏi cơ bản về dự án để hình dung được họ nắm sâu cỡ nào về phạm vi vấn đề cần giải quyết
Hiểu rõ về business objective
Sau khi xác định được Stakeholder, hãy tiếp cận người chịu trách nhiệm chính về mục tiêu kinh doanh.
Stakeholder này muốn đạt được gì từ dự án này. Đây là tầng nhu cầu cao nhất mà BA cần phải đạt được để có cái nhìn tổng quan. Khách hàng muốn tăng doanh số lên 5%, tăng khách hàng tiềm năng lên 20%, tăng tỷ lệ chuyển đổi lên 30%… Hãy tìm hiểu xem, stakeholder nào sẽ cho bạn được những thông tin ở tầng business object này
Sau khi thu thập những thông tin này từ những stakeholder khác nhau thì hãy xác nhận lại với PM 1 lần nữa để chắc chắn những bạn đang đi đúng hướng
Thảo luận với Tech lead
Thảo luận với tech lead của dự án, có thể là 1 buổi ăn trưa hoặc 1 chầu cafe để tạo lập quan hệ. Hãy hỏi thăm cách mà team dev làm việc cùng BA trong những dự án trước đó, thăm dò thử xem mức độ chi tiết, chuyên sâu về kỹ thuật của tài liệu mà họ cần ở mức nào. Từ đó hình dung được khối lượng output BA phải chuyển giao.
Bạn có thể trao đổi về 1 số vấn đề cần phải làm với techlead. Họ có thể đưa ra 1 vài giải pháp khả dĩ, chỉ ra 1 số điểm bất khả thi hoặc nút cổ chai có thể làm kéo dài thời gian dự án.
Đến thời điểm này, bạn vẫn chưa đủ để có thể đưa ra ước lượng hoàn chỉnh, nhưng đừng lo, bạn đang đưa dự án tiến về phía trước và đã rất gần rồi
Thảo luận về giải pháp
Sau tất cả những bước trên, bạn đã có trong tay 1 số giải pháp phù hợp. Hãy sắp xếp 1 cuộc họp với stakeholder chịu trách nhiệm chính của dự án, thảo luận về các điểm mạnh và hạn chế của từng giải pháp. Kết quả cuối cùng đó là stakeholder đưa ra lựa chọn cho giải pháp cuối cùng. Từ đây, bạn đã có đầy đủ những thứ cần thiết để lên 1 bản nháp cho tài liệu Phạm vi dự án.
Bạn đã có cho mình các câu trả lời cho
Stakeholder của bạn là ai
Business objective (mục tiêu và vấn đề business cần giải quyết)
Team dev gợi ý giải pháp nào
Team dev cần các tài liệu nào để triển khai
Stakeholder lựa chọn giải pháp như thế nào.
Phạm vi dự án chốt ở mức nào.
Khá là đầy đủ tài nguyên để bạn biết được tiếp theo cần làm gì và cần làm trong bao lâu. Hãy lựa chọn đầu việc, sắp xếp thứ tự ưu tiên, ước lượng thời gian và xếp chúng vào 1 bảng tính như ví dụ dưới đây để có được 1 BA timeline cơ bản.
ID
Deliverable name
Estimate Effort
Start date
End date
Status
Who involved
Assumptions
Sau khi đưa ra được 1 BA timeline, những việc tiếp theo đã trở nên rất rõ ràng và cụ thể hơn. Bạn đã có cơ sở để làm việc với stakeholder, 1 con số được chống lưng bởi tất cả những research mà bạn có thể đã mất 3-4 ngày để thực hiện. Không còn 1 sự ước đoán mơ hồ, mông lung có thể khiến tim bạn nhảy ra khỏi lồng ngực khi có gì đó bất trắc xuất hiện nữa.
Đối với BA, sau khi lấy được requirement từ stakeholder, việc quan trọng tiếp theo chính là ghi nhận các requirement đó thành 1 tài liệu để giao tiếp với stakeholder và team development.
Có nhiều cách thức để làm việc đó và trong bài viết này tôi sẽ nói về User story 1 trong những cách thức được ưa chuộng nhất đối với các dự án Agile ngày nay.
User story là gì?
Đó không phải là 1 tính năng, user story là 1 đơn vị nhỏ nhất của nhu cầu được nêu ra với góc nhìn của người dùng. Diễn đạt 1 cách đơn giản kết quả đầu ra mà 1 người dùng cụ thể mong muốn để thỏa mãn 1 nhu cầu nào đó.
> Đăng nhập vào hệ thống bằng tài khoản mạng xã hội. → Tên của 1 tính năng, cho thấy Góc nhìn hệ thống
> Là khách hàng, tôi muốn đăng nhập bằng tài khoản Google để có thể truy cập nhanh chóng. → Tên của 1 user story, cho thấy Góc nhìn người dùng
User story không xoay quanh 1 tính năng, 1 giao diện hay 1 luồng business. Để thỏa mãn 1 User story có thể cần sự kết hợp của nhiều tính năng, nhiều màn hình, nhưng cũng có thể chỉ là 1 phần nhỏ được tách ra từ 1 luồng chính.
Cốt lõi của user story chính là việc đặt người dùng làm trung tâm của mọi thứ. Người dùng cần gì từ hệ thống chứ không phải là hệ thống có thể cung cấp được gì cho người dùng. Đó cũng chính là thứ mà các nguyên tắc Agile luôn hướng tới – User first
1 tập hợp gồm nhiều user story được gọi là epic. Thật ra một epic cũng có thể xem như là 1 user story, nhưng khác biệt ở chỗ mức độ bao quát của epic cao hơn và phức tạp hơn, cho nên cần phải break down ra thành những user story nhỏ để dễ dàng thực hiện.
Một todo list (danh sách task) có thể giữ cho team tập trung vào các đầu việc cần phải hoàn thành, còn 1 bộ user story sẽ định hướng team tập trung giải quyết các vấn đề của người dùng thực tế. Sau khi hoàn thành 1 user story, đó chính là thỏa mãn 1 nhu cầu của user, chứ không phải là ghép thêm 1 mảnh ghép để tạo thành hệ thống.
Cấu trúc của 1 user story
1 user story gồm 2 phần chính
Mở bài: Tóm tắt user story
Thân bài: Chi tiết user story
Mở bài
Phần mở bài của user story thường được phát biểu dưới dạng một câu ngắn gọn theo cú pháp dưới đây:
Là <loại user>, tôi muốn <nhu cầu>, để<lý do>.
Ví dụ:
Là thủ quỹ, tôi muốn ghi lại 1 khoản chi tiêu trong nhóm để có thể tính toán thu chi sau này.
Là trưởng nhóm, tôi muốn xem báo cáo chi tiêu của nhóm trong 1 tuần vừa qua.
Chỉ bằng 1 câu ngắn gọn, đã có thể dễ dàng hình dung được nhu cầu này một cách rõ ràng:
Loại user: Ai? Chúng ta giải quyết vấn đề này cho ai? Cần phải đặt bản thân vào vị trí của người này, người này là ai và họ có vai trò gì. BA cần đồng cảm sâu sắc cách họ nghĩ và cách họ cảm nhận, từ đó hiểu rõ ngữ cảnh của yêu cầu.
Nhu cầu: Làm gì?Mô tả cái mà user kỳ vọng, kết quả cuối cùng mà user muốn đạt được.
Lý do: Tại sao? Nhìn thấy rõ đâu business problem nào sẽ giải quyết được sau khi hoàn thành story này. Kỳ vọng này của user có khớp với bức tranh toàn cảnh dự án hay không?
Thân bài
Phần thân bài của user story được gọi là Acceptance Criteria – những điều kiện để được gọi là hoàn thành.
Một user story hoàn thành nghĩa là output phải đáp ứng đủ các điều kiện mà acceptance criteria đề ra.
Ví dụ:
Là người tìm việc, tôi muốn lọc danh sách công việc trong một khu vực nhất định.
Thì acceptance criteria cho user story này có thể là:
Hệ thống hiển thị danh sách các khu vực gồm: Hồ Chí Minh, Hà Nội, Khác.
User chỉ được chọn 1 khu vực để lọc
Hệ thống trả ra danh sách công việc còn hiệu lực thuộc khu vực user đã chọn
Hệ thống phân trang các kết quả trả ra, 10 kết quả/trang
…
Việc liệt kê ra các acceptance criteria là cơ sở để triển khai xây dựng các tính năng và phục vụ việc test sau này. Việc định nghĩa kết quả càng rõ thì sẽ càng dễ dàng trong quá trình phát triển sau này. Hãy nhớ viết các acceptance criteria một cáchrõ ràng mạch lạc.
Bạn có thể thấy, acceptance criteria chính là những rule, logic để hoàn thiện hơn cho user story đơn giản được mô tả ở mở bài. Đây chính là 1 input quan trọng để team phát triển và testing
Bên cạnh acceptance criteria, đôi lúc những user story phức tạp đòi hỏi phải có sự hỗ trợ của sơ đồ workflow, mockup để dễ hình dung được hơn cách mà user và hệ thống tương tác với nhau để cho ra output như mong muốn.
Nếu user story quá lớn và phức tạp để có thể xong trong 1 sprint, hãy cân nhắc chia ra thành nhiều user story nhỏ hơn với những output cụ thể hơn:
1 user story tốt cần:
Bám sát nhu cầu thực tế của user
Định nghĩa được rõ ràng kết quả muốn đạt được.
Dễ dàng có thể test được
Dễ dàng để ước lượng thời gian thực hiện
Lưu ý
User story là một công cụ hữu hiệu để có thể đào sâu vào chi tiết của các tính năng. Việc viết user story cho thật tốt sẽ mất rất nhiều thời gian và nỗ lực. Đôi khi, quá tập trung vào chi tiết cũng có thể khiến bạn mất đi cái nhìn toàn cảnh của dự án. Cho nên, hãy cân bằng giữa tư duy chi tiết và tư duy tổng quát. Nhìn rộng hơn để thấy được bức tranh lớn hơn. Từ đó biết được đâu là chỗ cần đầu tư nhiều thời gian và sáng tạo.
Đối với BA, công việc quan trọng nhất chính là lấy được nhiều requirement nhất của user, càng nhiều, càng thầm kín càng tốt. Và một trong những thuật ngữ đẹp đẽ được dùng cho công việc này đó là Requirement Elicitation. Hay Việt hóa là: khơi gợi, đào bới, moi móc nhu cầu từ user.
Nói tóm lại, đó là quá trình để ông BA đi cạ nhau với user, với người nắm giữ và phát sinh mọi nhu cầu cho dự án, từ đó moi được từ miệng user những thông tin giá trị, cái họ cần, cái họ kỳ vọng, làm cơ sở hình thành nên Scope của dự án(phạm vi) và tạo ra requirement chi tiết cho team phát triển làm.
Thường thì quá trình này hay được gán với những buổi workshop dài đằng đẵng, mời đủ kiểu stake holder, từ giám đốc đến nhân viên vệ sinh, làm thành 1 đại hội, 1 festival lấy requirement kéo dài từ sáng sớm đến chiều tối. Nhưng thực ra trong đa số trường hợp quá trình này bao gồm nhiều những session nhỏ kết hợp với nhau, mỗi lần chỉ có sự tham gia của 1 vài stakeholder nhất định. Đòi hỏi BA phải vận dụng linh hoạt tùy tình huống.
Dưới đây tôi sẽ chia sẻ 5 kỹ thuật moi móc requirement từ stakeholder để bạn có thể áp dụng tùy hoàn cảnh.
Top 5 kỹ thuật moi móc requirement
1. Quan sát
Kỹ thuật đầu tiên đó là soi mói bằng mắt thường. Hãy ngồi bên cạnh user nếu bạn được tiếp cận với họ, hoặc cũng có thể qua 1 phần mềm share màn hình online nào đó.
Ngồi ngay ngắn và xem user làm việc thực tế. Bạn có thể yêu cầu họ vừa làm, vừa giải thích các bước mà họ đang thực hiện. Ví dụ như: Tôi phải làm gì để tạo 1 sản phẩm mới, hoặc các bước nào tôi cần làm để hủy 1 đơn hàng.
Nhìn 1 cách trực tiếp vào quy trình làm việc hiện tại của user và đặt những câu hỏi tại sao. Đừng sợ rằng bạn sẽ hỏi “Ngu”. Hãy luôn hỏi lý do tại sao họ bấm vào nút đó, họ nghĩ gì trong đầu khi làm thế. Cố gắng thấu hiểu được logic công việc và làm rõ các logic đó bằng câu hỏi.
Câu hỏi ngu duy nhất là câu hỏi mà bạn không hỏi.
Hãy đặt ra 1 vài tình huống giả định khác ngoài “happy case” mà user đang trình diễn. Nếu tôi không bấm vào nút này mà bấm vào bên ngoài thì sao, nếu tài liệu nặng hơn mức cho phép thì sẽ thế nào.
2. Sử dụng sơ đồ, nguyên mẫu
Phương pháp thứ hai tôi muốn chia sẻ với bạn là Sử dụng nguyên mẫu để xác định với user những thứ họ cần.
Đây là một cách tuyệt vời để nói chuyện với user và làm rõ requirement nhanh chóng. Hãy mô tả lại cách bạn hiểu business logic của họ thông qua
Sơ đồ workflow: khi cần mô tả lại 1 quy trình phức tạp gồm 1 hoặc nhiều đối tượng tham gia
1 bản wireframe: khi cần mô tả luồng thao tác và các component hiển thị trên 1 màn hình thiết bị.
1 sơ đồ mối quan hệ thực thể (ERD): khi cần mô tả mối quan hệ giữa các đối tượng tồn tại trong hệ thống và 1 vài thuộc tính cơ bản của chúng
Từ những mô hình này, bạn có thể trực quan hóa toàn bộ business hoặc 1 số khía cạnh cần làm rõ. Tiếp theo là cho phép user feedback lại dựa trên cái bạn đã vẽ. Cách này có thể giúp bạn khám phá ra những thông tin bất ngờ, những kỳ vọng lạ lẫm mà trước nay bạn không nghĩ tới.
Bạn có thể làm một bản nháp đơn giản của những mô hình trên, tùy theo nhu cầu mô tả và mức độ thành thạo của user.
3. Phỏng vấn theo bộ câu hỏi chuẩn bị trước
Kỹ thuật thứ 3 là phỏng vấn theo check list. Liệt kê danh sách những câu hỏi mà bạn cần làm rõ. Gửi trước danh sách này cho stakeholder để họ có thời gian xem xét và chuẩn bị.
Để thực hiện phỏng vấn, bạn sẽ cần meeting với stakeholder, và cuộc họp sẽ sử dụng danh sách câu hỏi này như agenda. Các stakeholder chịu trách nhiệm sẽ trả lời câu hỏi của bạn theo thứ tự.
Việc tạo ra 1 danh sách câu hỏi và cho stakeholder có thời gian để chuẩn bị sẽ giúp bạn có được những câu trả lời rõ ràng hơn nhiều so với hỏi một cách ngẫu nhiên.
Tất nhiên, hãy giới hạn thời gian buổi họp, đặt câu hỏi có trọng tâm để tránh người trả lời lan man sang các khía cạnh khác.
4. Đọc tài liệu
Khi bạn tham gia vào một dự án thuộc 1 domain lạ lẫm, bạn cần dành thời gian để hỏi xin và đọc các tài liệu liên quan để có 1 nền tảng cơ bản. Các tổ chức, công ty, dự án thường có những tài liệu đã tồn tại trước
Cách này không đòi hỏi phải tương tác với stakeholder, chỉ cần đọc và đọc. Rồi từ những thứ đọc được, bạn tạo ra các sơ đồ, nguyên mẫu, tạo check list câu hỏi, giúp cho việc quan sát trở nên cụ thể và rõ ràng hơn.
Cách này có thể tiết kiệm rất nhiều thời gian của bạn và của stakeholder khỏi những cuộc họp lê thê. Nếu stakeholder của bạn là cực kỳ bận rộn, khó để tiếp cận thì hãy ưu tiên phương pháp này để có sự chuẩn bị tốt nhất trước khi book 1 buổi họp quý giá.
Nhưng lưu ý nhé, việc đọc tài liệu luôn là phương pháp tham khảo để tiếp tục thực hiện các phương pháp khác. Bạn sẽ không muốn dính vô cảnh đọc trúng 1 tài liệu đã out date từ đời nào, quy trình quy chuẩn đã khác xa với thực tế vận hành thì lúc đó xem như xu cà na.
Luôn nhớ verify lại với user về những gì bạn đọc được và cách mà bạn hiểu về tài liệu đó. Đừng vội đưa ra kết luận hay đúc kết một giả định sai lầm.
5 Khảo sát và dùng bảng câu hỏi
Bây giờ là kỹ thuật cuối cùng trong những kỹ thuật Elicite Requirement. Đây là cách thức tuyệt vời đề tương tác, lấy thông tin từ những stakeholder bạn không có cơ hội tiếp xúc trực tiếp nhiều.
Tạo ra 1 bảng khảo sát là cách để thu thập được thông tin một cách khách quan hơn. Trong đa số trường hợp, người ta sẵn sàng chia sẻ nhiều câu hỏi mang tính cá nhân hơn khi viết vào 1 bảng khảo sát thay vì trả lời trực tiếp. Nhưng ngược lại, phương pháp này cũng có nhược điểm là thông tin ghi nhận được thỉnh thoảng sẽ không rõ ràng, có để diễn giải khi không có ngữ cảnh cụ thể.
Hãy kết hợp các kỹ thuật
Hãy chọn cho mình kỹ thuật phù hợp nhất tùy theo tình huống và dự án cụ thể một cách thông minh. Mỗi kỹ thuật đều có điểm mạnh và điểm yếu, 1 BA giỏi sẽ biết lựa cơm gắp mắm, chọn đúng tool cho đúng mục đích. Đó là sơ lược những kỹ thuật lấy yêu cầu mà tôi biết. Chia sẻ thêm nếu bạn có thêm kỹ thuật nào khác nhé.
Là một BA, khi viết 1 requirement, hãy đảm bảo viết 1 cách rõ ràng sáng sủa nhất.
Requirement rõ ràng giúp người đọc dễ hiểu đúng requirement, tránh làm sai và lãng phí nguồn lực. Bạn bất lực khi nhận ra 1 từ ngữ nào đó khiến dev team hiểu lầm, và rồi đi tong cả 1 tính năng. Việc này là 1 trong những cơn ác mộng của BA. Khi nghe brief thì dev gật gật hiểu rồi, nhưng là nói 1 đằng hiểu 1 nẻo. Dev vẫn cần document để có “giấy trắng mực đen”. Nhưng mà mặt chữ thì có khi mỗi người đọc rồi hiểu 1 kiểu. Ngữ pháp Việt Nam nó lạ lắm, sơ sẩy 1 cái là có thể lật ngược ý nghĩa lại liền. Việc viết rõ như từ điển, câu cú gãy gọn để tránh bị “lật kèo” là bí quyết sống còn.
Đỡ mất công review tới lui và xác nhận nhiều lầm. Một requirement khó hiểu sẽ dẫn đến việc hỏi đi hỏi lại, mãi không chốt được.
Những requirement mạch lạc giúp ông BA sáng dạ hơn. Khi đặt vấn đề 1 cách tường minh, những câu hỏi mấu chốt sẽ xuất hiện. Dễ dàng hiểu được bức tranh toàn cảnh và khai thác những thông tin “xịn” từ PO. Từ đó nâng cao giá trị của ông BA trong team phát triển.
Dưới đây là 3 mẹo để viết 1 requirement “rõ như ban ngày”:
Không dùng câu bị động
Khi viết requirement, hãy dùng câu khẳng định, đủ chủ ngữ vị ngữ.
Thế nào là câu bị động:
Bài viết được lưu ở portal
Bài viết được hiển thị lên trang chủ
Từ “được”, “bị” thể hiện câu đang dùng là câu bị động. Chúng ta có xu hướng dùng câu bị động khi thiếu thông tin, điều này rất rủi ro. Trong 2 ví dụ trên, requirement mô tả hành động nhưng thiếu đi thông tin về chủ thể thực hiện hành động. Điều này dẫn đến 2 khả năng: 1 là người đọc sẽ hỏi lại để có thêm thông tin, 2 là họ sẽ giả định theo cách hiểu của chính họ (khả năng 2 này rất chí mạng nếu người đọc giả định sai).
Thế nên 1 cấu trúc câu khẳng định sẽ đảm bảo đầy đủ ý nghĩa.
Admin nhập liệu lưu bài viết ở portal
Hệ thống hiển thị bài viết trên trang chủ
Bằng cách thêm vào ai hoặc cái gì thực hiện hành động, requirement đã trở nên dễ hiểu gấp 100 lần.
Không dùng tá lả thuật ngữ
1 cách nữa để khiến mớ tài liệu requirement trở thành nồi cám heo đó là: Thuật ngữ
Cùng 1 định nghĩa nhưng ông BA mỗi lúc lại gọi 1 kiểu khác nhau. Lúc thì gọi là “Admin” lúc thì gọi là “Quản trị viên”. Rồi người đọc confuse đến nỗi muốn khóc vì không chắc 2 từ đó có phải là một không.
Nếu xét 1 cách dễ tính hơn thì có thể 1 nhóm người đọc đã quen với domain bạn đang làm, có thể đọc 1 hiểu 10 thì cũng không thành vấn đề. Nhưng nếu team bạn tuyển thêm dev, mở rộng quy mô, làm tài liệu cho end-user hoặc transfer kiến thức cho 1 ông BA mới vào thay cho bạn. Mà họ lại là tấm chiếu mới trong domain đó thì sẽ bắt đầu sấp mặt. 1 vạn câu hỏi vì sao sẽ xuất hiện, đè bẹp bạn và đồng bọn.
Mỗi khi thấy xuất hiện những thuật ngữ lạ khi giao tiếp trong dự án, hãy nói lên vấn đề đó để cả team ghi nhớ và bổ sung vào Glossary.
Không dùng từ nối, câu phức
Sử dụng những câu đơn, chỉ chứa 1 mệnh đề. Không nên xào chẻ 1 câu bằng cách ghép nhiều câu nhỏ lại. Nó rất đẹp trong văn học nhưng lại rất nhức đầu khi đọc requirement.
Dấu hiệu của 1 câu phức đó là bạn sử dụng những từ như: “và”, “hoặc”, “trước khi”, “sau khi”
Ví dụ: Admin nhập liệu nhập nội dung bài viết và xem bản review trước khi lưu.
Một requirement như vầy có thể được xem là rõ ràng mạch lạc không? Trong cùng 1 câu này, sử dụng rất nhiều động từ. Tuy rằng câu được viết ở thể chủ động nhưng nó hàm chứa 3 requirement cùng 1 lúc.
Admin nhập liệu nhập nội dung bài viết
Admin nhập liệu xem bản review bài viết
Admin nhập liệu lưu bài viết
Đừng viết một cách bản năng khi sử dụng quá nhiều từ nối. Hãy rạch ròi ra để nhìn thấy được cụ thể phải làm những gì. Đôi khi chỉ ba từ “trước khi lưu” mà bạn để lẫn lộn nó trong 1 câu phức tạp cũng sẽ đẻ ra một đống việc phải làm.
Thực hành
Hãy lấy ra bất cứ tài liệu requirement nào bạn đang có, do chính bạn viết hay một ai đó viết. Áp dụng 3 checklist vừa nêu bên trên để kiểm tra xem mình đang dính lỗi này nhiều như thế nào.
Sau này, mỗi khi thấy bản thân hay đồng nghiệp mắc phải thói quen tương tự thì hãy thảo luận để cùng nhau viết requirement một cách rõ ràng hơn nhé.
