DUY: “Thuyết phục” nên hiểu theo nghĩa là “chủ động tìm hiểu”, developer cũng có trách nhiệm phải chủ động hiểu nhu cầu của khách hàng (thông qua trợ giúp của BA), và tư vấn những giải pháp thích hợp nếu cần thiết. Để hiểu được vấn đề và mong muốn của khách hàng, một trong những cách tiếp cận là thu thập phản hồi của khách hàng sớm và thường xuyên về tính năng chúng ta đang xây dựng (thông qua wireframe, mockup, workflow, user stories, v.v..). BA thường đảm nhận vai trò này, và làm việc chung vói nhóm phát triển. Nếu gặp phải chức năng nào đó lớn, với kinh nghiệm của Duy, BA có thể chia nhỏ scope ra, thành từng user stories nhỏ hơn cho nhiều Sprints. Như vậy developer và những bên liên quan có thể có chung cái nhìn về kết quả dễ dàng hơn (giống như làm 1 đại lộ thì sẽ được thi công thành nhiều phân đoạn và được bàn giao khi mỗi phân đoạn hoàn thành)."

 

LINH: “Có lẽ nhiều BA sẽ chọn cách giải quyết: “Okay, developers thấy không thuyết phục nhưng khách hàng muốn như vậy, và chúng ta phải làm theo” – Tiếp cận này chưa đủ thuyết phục, và đây không hẳn là giải pháp, đây là một sự áp đặt. Với tình huống này, theo Linh, BA nên chủ động tìm hiểu và so sánh các ứng dụng trên thị trường có chức năng tương tự, và sau đó quay lại chia sẻ và thảo luận với development team. Làm như vậy, nghĩa là chúng ta đang tìm kiếm sự đồng thuận và tiếng nói chung giữa 2 bên để có được kết quả tốt hơn. Bên cạnh đó, các bạn BA lại có thêm một kiến thức mới đấy! Một khía cạnh khác, biết đâu trong quá trình tìm hiểu kỹ hơn đó, BA sẽ nhận ra điều mà developer thấy không thuyết phục là chính xác? Cũng từ đó chúng ta sẽ có cách giải quyết khác và cùng tư vấn cho khách hàng.”

 

 

“Lỗi không thuộc về cá nhân nào cả, lỗi là của cả team. Dự án có vấn đề là do team có vấn đề.

 

Trong tình huống này, tất cả team member nên ngồi lại với nhau, không phải để quy trách nhiệm cho ai, mà để tìm cách giải quyết. Quan trọng là cùng nhau triển khai dự án thành công và đáp ứng nhu cầu của khách hàng.

 

Theo kinh nghiệm của mình, nếu đúng là do bên mình hiểu sai vấn đề, chúng ta nên thẳng thắng nhận lỗi, sau đó những người key members của dự án nên làm việc trực tiếp với khách hàng, đưa ra kế hoạch thời gian cụ thể để sửa chữa những lỗi đó.

 

Trường hợp không may nhất là rơi ngay vào bản release cuối cùng, trước khi bàn giao chính thức toàn bộ cho khách hàng… Lúc này nên nghĩ đến bản vá lỗi, đương nhiên mọi vấn đề cần có sự tham gia và quyết định từ phía khách hang. Triển khai bản vá lỗi cũng là giải pháp mà nhiều tập đoàn lớn vẫn áp dụng. Không có gì là hoàn hảo và trọn vẹn ngay từ đầu được!”

 

“Mình chưa có kinh nghiệm trong tình huống này. Tuy nhiên, trong các dự án Duy đã tham gia, một trong những quy tắc nhóm của Duy luôn làm theo là: các user stories sẽ được bàn giao ngay khi hoàn thành để khách hàng xem ngay, để cho mình có thời gian chỉnh sửa nếu cần.

 

Duy cũng thấy vấn đề này thường xảy ra ở những dự án dạng phải nâng cấp một hệ thống cũ lên công nghệ mới. Và các nhóm dự án đó vô hình đi vào lối mòn: thời gian cho BA làm việc (phân tích, nghiên cứu, thảo luận, v.v..) khá ngắn trong khi tiến độ thi công tính năng lại cần phải nhanh chóng."

“Tình huống này làm Duy nhớ đến một sai lầm mà developer hay mắc phải khi làm outsourcing: YAGNI (You aren’t gonna need it) và hiệu ứng quả cầu tuyết. Trong quá trình thi công một tính năng nào đó, để ngăn ngừa những thay đổi không lường trước mà có khả năng ảnh hưởng đến tiến độ: bất kì thay đổi nào cũng phải được thông báo ngay trước khi bắt tay thực hiện.

 

Chuyện thực tế Duy từng mắc phải: khi làm việc trên một form đăng ký cho một website quản lý hệ thống bệnh viện (khách hàng Mỹ), mình đã thêm trường Year vào phần giao diện nhập ngày tháng. Nhưng cuối cùng khách hàng không muốn có nó vì trường Year làm chậm thời gian nhập dữ liệu của họ.”

 

LINH: “Có thể có ba trường hợp:

 

1. Developer nói requirements không khả thi về mặt kỹ thuật. Trong trường hợp này, BA nên chủ động nghiên cứu về hướng tiếp cận kỹ thuật cho yêu cầu đó, không cần quá chi tiết nhưng BA nên biết chắc rằng có phải yêu cầu đó “không thật sự khả thi”. Đây cũng là một cách để BA nâng cao kiến thức của mình.

 

2. BA đưa requirement nằm trong giới hạn kỹ thuật: BA cùng với developer nên cùng nhau tìm hiểu và đề xuất giải pháp – thoả mãn cả về yêu cầu khách hàng và vấn đề kỹ thuật.

 

3. Nếu vượt ngoài tầm kiểm soát của BA: Hãy để bên thứ 3 tham gia cùng giải quyết vấn đề. Ví dụ như chia sẻ điều này cho người quản lý dự án chẳng hạn.”

 

 

DUY: “Theo cá nhân mình, bản mô tả tính năng (trên bất kì định dạng nào như word, wireframe, video…) ở mức độ chi tiết và chất lượng tốt khi nhóm phát triển có thể đưa ra ước lượng thời gian hoàn thành (một cách tự tin). Nếu có quá nhiều thắc mắc sau khi developer đọc bản mô tả, thì tức là nó cần chi tiết hơn nữa.”

 

LINH: “Developer đọc hiểu và code đúng (đương nhiên sẽ có bug, nhưng là bug về technical chứ không phải bug vì hiểu sai yêu cầu khách hàng). QC có thể tạo ra test case bao phủ hết được các phân luồng trong yêu cầu khách hàng. Nếu có tranh cãi về mức độ chi tiết của thông tin, hãy tổ chức một buổi meeting, duyệt qua toàn bộ tài liệu, từ tổng quát đến từng phần chi tiết. Đoạn nào developer còn khúc mắc, BA bổ sung. Qua việc làm đó, team sẽ tránh được những trường hợp phát sinh. Bên cạnh đó, BA sẽ có thêm kinh nghiệm, biết cách tiếp cận và cải thiện sau này.”

 

 

LINH: “Một là do kỹ năng BA chưa đủ cứng. Nếu cách approach và mức độ mô tả của BA đủ bao quát hết trường hợp, sẽ không xảy ra nhiều thay đổi yêu cầu trong quá trình phát triển sản phẩm. Vấn đề này, hãy nói chuyện với leader của bạn và tìm ra cách để hoàn thiện mình hơn. Hai là do từ phía khách hàng, BA có trách nhiệm thống nhất rõ với khách hàng, hiểu rõ lý do thay đổi và cập nhật, sau đó giải thích với development team.

 

Trong một dự án lớn, thời gian phát triển khoảng 5,6 tháng, mình thấy trên 30% thay đổi sẽ đến từ phía khách hàng, nếu cao hơn thì có lẽ khách hàng cũng đang có vấn đề từ phía họ.”

 

DUY: “Nếu một chức năng trong quá trính phân tích (chưa thi công), mà không được các bên dành nhiều thời gian để xem xét / kiểm tra kỹ lưỡng, thì những trường hợp phát sinh khi thi công và change request là chuyện đương nhiên. Theo mình, một chức năng nhỏ (khoảng 4 man-day) thường cần khoảng 3 vòng review (một vòng = gửi và nhận feedback)."

 

 

Có thể những kiến thức này bạn đã biết, và cả những tình huống bạn chưa từng trải qua… Bạn có cùng quan điểm với những giải pháp, cách lý luận giống như các speakers ngày hôm nay?

 

Trong cuộc đối thoại, developer có chính kiến của riêng mình, BA có cách giải quyết theo họ là hợp lý. Làm việc trong cùng một team, chắc chắn không thể tránh khỏi “chiến tranh”.

 

Kết quả của cuộc chiến, chúng ta sẽ có gì?

 

>> Một sản phẩm đáp ứng được tất cả yêu cầu và thoả thuận ban đầu với khách hàng.

 

>> Khi đến tay end-user, họ cảm thấy hài lòng khi sử dụng và đánh giá tốt, cùng những comment tích cực.

 

Vậy bạn biết ai là người chiến thắng rồi đấy!