Thế nào là 1 business analyst có agile mindset?

Trong đội nhóm hoặc tổ chức agile, vai trò và hành vi của người làm business analyst có agile mindset sẽ ra sao?

‍

Câu chuyện về vai trò của tư duy BA tại một tổ chức Agile như Magestore

Gần đây mình có tìm hiểu về vai trò của BA trong tổ chức Agile. Và tự reflect lại và nghiệm ra 1 số điều.

Mình vốn không phải được tuyển vào công ty như 1 BA nhưng trong quá trình làm việc té ra, mình lại cần rất nhiều các kỹ thuật của BA để phân tích và đưa ra giải pháp.

Mình nghĩ tại doanh nghiệp, mỗi vị trí chúng ta đều đang sử dụng (dù ít dù nhiều) những tư duy, kỹ năng để phân tích tình hình, nhu cầu của doanh nghiệp. Từ đó, chúng ta đưa ra các phương án cụ thể nhằm giải quyết vấn đề. Do đó, nếu nghĩ rộng ra thì ai cũng đang làm BA trong các mảng kiến thức (domain knowledge) khác nhau.

Tại công ty mình - là một công ty công nghệ, và áp dụng Agile trên quy mô toàn công ty, có thể bạn không được tuyển với chức danh vị trí là BA nhưng các tư duy và kỹ năng của BA thì bạn vẫn cần học hỏi và chạm tới. Có đợt anh CEO còn phát động phong trào toàn dân làm BA với cách hiểu ở đây BA là những người phân tích yêu cầu và đưa ra giải pháp giải quyết vấn đề, chứ không phải bám vào một cái nhãn được gán cho từng người cụ thể. Nếu tư duy như vậy thì mình cũng cảm thấy học BA là có ích cho sự phát triển về lâu về dài của mình.

Nhân đây mình sẽ chia sẻ luôn những quan điểm về vai trò của BA trong tổ chức và đội nhóm Agile mà mình hiểu và thu lượm được để mọi người cùng tham khảo. Nếu bạn đã đọc bài viết về Agile mindset là gì hay người có tư duy và sống với giá trị Agile sẽ biểu hiện như thế nào rồi thì sẽ càng hiểu hơn chủ đề mà mình đang đề cập.

Vai trò của BA trong tổ chức và đội nhóm Agile

Một trong những điểm chính của triết lý Agile, được nói đến trong Agile Manifesto là Valuable software over comprehensive documentation (Sản phẩm có giá trị thì quan trọng hơn là tài liệu hoàn chỉnh, và đầy đủ).

>> Đọc để hiểu Agile manifesto là gì và ý nghĩa của Agile manifesto

Khi một dự án sử dụng cách tiếp cận Agile, hoặc sử dụng các Agile framework cho quản trị dự án, nghĩa là dự án đó đang coi trọng việc chuyển giao sản phẩm có giá trị và ý nghĩa đến tay khách hàng. Sản phẩm có thể được bàn giao sớm và nhanh chóng nhưng nếu nó không mang lại bất kỳ giá trị sử dụng nào thì cũng là tốn công vô ích. Và tất nhiên, để có sản phẩm hữu ích cho người dùng chúng ta cần phải có vai trò của BA bước vào.

Họ được coi là người nhìn nhận và bảo vệ các giá trị hướng tới khách hàng được tạo ra trong suốt vòng đời của dự án. Bằng cách dấy lên các cuộc hội thoại, bàn thảo có ý nghĩa, chứ không phải là tạo ra các tài liệu hoàn chỉnh. Các cuộc hội thoại được khởi động và điều phối nhằm giúp thiết lập ưu tiên và đưa ra các quyết định trong dự án.

Một BA sẽ phân tích các chủ đề ưu tiên của Product Owner, và bẻ nhỏ một sản phẩm lớn thành các mảnh nhỏ hơn. Mỗi mảnh đó lại có giá trị đối với khách hàng và đủ nhỏ để team có thể estimate thời lượng hoàn thành một cách chính xác. BA cần là người thấu hiểu các stakeholders, và điều phối thảo luận nhằm thống nhất về cách hiểu chung giữa những cá nhân có background đa dạng trong dự án.

Trong các dự án Agile, thì Agile BA chính là người có vai trò chủ đạo trong việc điều phối các cuộc hội thoại về giá trị được chuyển giao tới tay khách hàng.

Bạn có thể đặt câu hỏi: Liệu chúng ta có cần phải document, tài liệu hóa mọi thứ?

Có nhiều BA mà hiện tại hầu hết công việc của họ là viết và đóng gói các tài liệu về Business Requirement, hay làm hợp đồng với khách hàng cho thật chi tiết. Nhưng theo xu hướng hiện nay, trọng tâm của một BA, đặc biệt khi dùng cách tiếp cận agile (từ đây mình gọi là Agile BA) không phải là việc viết lại, document lại mọi thứ để chuyển giao đi. Mà trọng tâm là làm cho các cuộc thảo luận diễn ra để đội phát triển giải pháp có được một cách hiểu thống nhất về thứ mà họ đang xây dựng cho khách hàng. Hiểu theo cách này không có nghĩa là tài liệu sẽ không cần thiết nữa. Mà mục đích viết ra tài liệu sẽ thay đổi cách chúng ta làm chúng.

Agile documentation là thứ sẽ phục vụ team của bạn như là một cái ngòi kích hoạt các cuộc thảo luận, hoặc một bản ghi nhớ của các cuộc hội thoại đó. Agile BA ở đó là để giúp Product Owner ra quyết định dễ dàng hơn. Bằng việc đặt trọng tâm vào tư duy và kỹ thuật cộng tác, giao tiếp, tương tác, điều phối, Agile BA sẽ giúp công việc của đội nhóm và tổ chức được hoàn thành và mang lại giá trị cho khách hàng. Không chỉ nhìn vào các công việc đang trong quá trình thực thi (work-in-progress), người làm BA sẽ còn nhìn vào công việc tương lai cần hoàn thành. Agile BA còn là người sẽ nhìn vào bức tranh lớn hơn để vạch ra hướng đi cho các giải pháp chuyển giao tới khách hàng.

Dưới đây là các hoạt động của BA trong Agile team, được trích từ 1 bản báo cáo phân tích về Agile Analysis năm 2019 của Ba-squared.com. Có thể thấy rất nhiều các hoạt động của BA là nói chuyện với người dùng, thảo luận, điều phối các cuộc họp của đội nhóm làm sản phẩm. Trong đó 5 hoạt động mà các BA tham gia vào nhiều nhất là:

1. Viết User stories
2. Viết Acceptance Criteria (Tiêu chí nghiệm thu)
3. Nói chuyện với người dùng về mục tiêu và nhu cầu
4. Viết Requirement Specs (Đặc tả yêu cầu)
5. Trả lời câu hỏi với tư cách là người dùng

Bản đồ nhiệt dưới đây mô tả các hoạt động mà BA tham gia trong một Agile team, và mối tương quan với kết quả mà team đó chuyển giao.

• Màu vàng thể hiện mối quan hệ trung lập
• Màu vàng nâu và màu đỏ thể hiện mối quan hệ chặt chẽ hơn với sự thành công của công việc

Từ bản đồ nhiệt này, bạn sẽ phát hiện thấy một số hoạt động sẽ giúp bạn góp phần nhiều hơn vào thành công của sản phẩm chuyển giao tới người dùng. Bạn có thường xuyên tập trung vào các hoạt động tô màu đỏ?

Chúng có mang lại những lợi ích cho team của bạn như rút ngắn thời gian đưa sản phẩm ra thị trường, tạo ra giá trị cần thiết và liên quan, tạo ra sản phẩm chất lượng cao hơn, mang về tỷ lệ khách hàng hài lòng cao hơn, nhiều đổi mới sáng tạo, giảm chi phí?

Biểu hiện của business analyst có Agile mindset

Khi 1 BA lựa chọn sống với những giá trị và nguyên tắc của Agile, thực chất họ cũng đã chuyển đổi từ mindset làm việc truyền thống sang Agile mindset. Khi có Agile mindset, họ sẽ thực hiện các hành động thực sự tạo ra giá trị cho team và cải thiện chất lượng của sản phẩm đầu ra.

Có thể đi sâu vào 2 tình huống thường thấy để nhìn nhận về hành vi của người BA có Agile mindset.

1. Thay đổi bất ngờ về yêu cầu

Khi stakeholder thêm vào 1 yêu cầu trong Sprint hiện tại đang diễn ra (Sprint được hiểu là 1 khoảng thời gian xác định, từ 1 ->vài tuần để sản xuất được 1 phần nhỏ có khả năng chuyển giao được cho khách hàng). Yêu cầu đó rất nhỏ nhưng lại rất quan trọng, và hiện tại họ muốn đưa vào Sprint này để làm ngay, dù team bạn chưa lên kế hoạch từ đầu để phát triển cái đó. 1 Agile BA sẽ phản ứng ra sao?

Họ sẽ mời Product Owner (PO) và cả Scrum Master hoặc Leader của đội phát triển giải pháp vào cuộc gặp mặt với stakeholder trên. Product Owner sẽ xác định ưu tiên còn người Leader của đội phát triển sẽ xác định ảnh hưởng của việc thay đổi này đối với công việc hiện tại của team, và tiến độ hoàn thành các phần khác đã được lên kế hoạch. Quyết định cuối cùng được đưa ra bởi PO và cả team, để chốt xem liệu họ có làm theo yêu cầu của stakeholder đó hay không. Làm sao để gây ít ảnh hưởng đến mục tiêu chung của sprint hoặc thiết lập lại các ưu tiên trong Product Backlog. Nếu coi yêu cầu mới nhận là ưu tiên, sẽ có những nhiệm vụ cần được chuyển sang Sprint tiếp theo để hoàn thành.

‍

2. Yêu cầu chưa rõ ràng

Khi developer nhìn vào 1 user story và cảm thấy chưa rõ ràng, anh này cần một tài liệu mô tả chi tiết hơn trước khi bắt tay vào phát triển tính năng.

Một Agile BA sẽ làm gì?

Là Agile BA, cô ấy mời leader của đội phát triển và developer đó vào cùng gặp mặt nhằm hiểu hơn về những khó khăn hay quan ngại của developer. Thay vì đi làm đúng theo mong muốn của developer và lủi thủi đi soạn 1 bộ tài liệu mô tả chi tiết, Agile BA sẽ gặp mặt nói chuyện trực tiếp luôn. Cô ấy sẽ đảm bảo rằng các đặc tả yêu cầu của mình rõ ràng hơn bằng cách vẽ các sơ đồ và nói chuyện với developer đó qua từng bước thiết kế và mô tả ý định, giá trị đối với nhu cầu của người dùng. Rồi có thể nhanh chóng chụp lại ngay bức hình vẽ sơ đồ mô tả, hoặc tạo 1 sơ đồ, mock up nhằm giúp developer ghi nhớ cuộc nói chuyện trên. Đồng thời cũng bày tỏ kỳ vọng rằng developer sẽ cần gửi lại sản phẩm theo đúng yêu cầu trong 1 hoặc vài Sprint để cô ấy đưa ra feedback sớm.

Tóm lại mặc định là gặp nói chuyện trực tiếp thì tốt hơn nhắn tin hoặc email trả lời dài dòng. Đứng dậy khỏi chỗ và trò chuyện với mọi người. Nếu không gặp mặt được thì gọi video.

Nói chuyện tương tác thì mới sáng tỏ vấn đề.

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.

-----

Nguồn tham khảo:

1. Khóa học Key agile mindsets of business analysts của Angela Wick
2. State of Agile Analysis Report 2019 của BA-SQUARED.

‍