Outline

• Dev sẽ nói câu này trong tình huống nào?
• Tại sao họ nói vậy, gốc rễ vấn đề, có nguyên nhân nào xuất phát từ BA hay không.
• Có hiểu lầm nào có thể xảy ra không
• Có thể giải quyết không? Giải quyết như thế nào?
• Mindset để tiếp cận việc này là gì
• Có thường xảy ra không, BA có cần deal với nó không.
• Làm sao để việc này không lặp lại thường xuyên trong tương lai.

Viết

Là BA việc của bạn là thu thập requirement của khách hàng 1 cách chính xác, đầy đủ nhất. Sau đó đề xuất những giải pháp phù hợp với requirement đó.

Sau chuỗi ngày dài dằng dặc lấy requirement. Bạn đã define được 1 giải pháp đơn giản, hiệu quả, hoàn hảo cho những vấn đề của business.

Và khi bạn chuẩn bị present nó với technical team để bắt đầu triển khai thì một câu nói sét đánh ngang tai xuất hiện: “Cái này không làm được đâu em!” hoặc “muốn làm cái này chắc phải cả tháng” trong khi ngân sách chỉ gói gọn trong 1 tuần.

Vậy BA sẽ làm gì trong tình huống này. Bạn có thể mặc kệ? Kiểm soát thời hạn không phải thẩm quyền và trách nhiệm của bạn, nếu không đồng thuận được với dev về hướng xử lý, bạn có thể đá trái banh qua cho PM. Miễn là requirement đã đúng và đủ.

Nhưng không! Bản năng bao đồng của BA không cho phép bạn làm điều đó. Bạn sẽ muốn nhúng tay vào để giải quyết vấn đề này.

Vì 1 BA giỏi không đơn giản chỉ là người define requirement giỏi, mà là người tạo ra sự thay đổi và giải quyết vấn đề.

Đầu tiên, hãy hít thở. Lấy 1 hơi thật sâu và thư giãn. Những tình huống như vầy có thể nhanh chóng dẫn tới căng thẳng, tim đập nhanh và đổ mồ hôi hột. Đừng mắc sai lầm này. Cứ giữ bình tĩnh và nghĩ xem, bạn muốn giải quyết những vấn đề business đã được define đúng không.

Nguyên nhân gốc rễ là gì?

Đây là việc thường xảy ra và BA sẽ phải deal với điều đó. Giờ nghĩ xem, tại sao team phát triển rất dễ dàng để phủ định hoặc kháng cự với đề xuất của BA.

Có thể đề xuất của bạn đủ tốt và đủ rõ ràng để có thể thực hiện. Nhưng vấn đề là bạn đã không lấy ý kiến của dev team ở những giai đoạn đầu dự án. Bạn cần lôi dev team vào làm giải pháp càng sớm càng tốt.

Đôi lúc BA quá hào hứng với ý tưởng và giải pháp của mình và cố gắng dọn sẵn mọi thứ trên bàn. Khi đó tính thử thách của vấn đề hầu như biến mất, không còn sự thú vị khi giải quyết 1 bài toán khó nữa. Nếu bạn là họ, có thể bạn cũng cảm thấy muốn kháng cự.

Lập trình viên là những người làm việc độc lập và có tinh thần vượt khó. Hãy đưa bài toán cho họ và đề xuất ý tưởng của bạn.

Làm sao để xử lý

Okay, bạn đã hình dung được lý do tại sao gặp phải sự chống đối từ dev team, giờ hãy nghĩ cách giải quyết. Chỉ có 2 hướng thôi:

• Thuyết phục team phát triển chấp nhận giải pháp của bạn
• Thay đổi thành 1 giải pháp mới

Đầu tiên, hãy cho họ biết là bạn cũng muốn nghe những ý kiến của họ về đề xuất đang có sẵn. Khuyến khích họ đặt ra những câu hỏi phản biện. Hãy chắc chắn rằng bạn trả lời được những câu hỏi đó và giải quyết được những khúc mắc chưa rõ. Từ từ làm rõ ra là đề xuất của bạn là khả thi và hợp lý ở nhiều khía cạnh.

Lắng nghe những góp ý với 1 thái độ open. Tôn trọng và tin tưởng kinh nghiệm của dev team là chắc chắn sẽ có 1 giải pháp còn tốt hơn nữa. Ghi nhận góp ý của team và bổ sung vào đề xuất ban đầu của bạn.

Nếu team vẫn khăng khăng về quan điểm reject toàn bộ đề xuất ban đầu. Okay bạn sẽ cần gác nó qua 1 bên để tìm kiếm những giải pháp khác. Team có thể brainstorm để tìm ra 1 vài giải pháp khả quan. Sau đó chọn ra 3-4 idea để đào sâu hơn.

Hãy nhớ lắng nghe với thái độ cởi mở và khách quan. Chỉ lên tiếng nếu cảm thấy 1 idea nào đó không thể đáp ứng được nhu cầu kinh doanh hoặc vượt khỏi scope of work.

Và điều thú vị là, nếu bạn làm giải pháp ban đầu một cách cẩn thận, thì sau buổi brainstorm, những đề xuất mới cũng sẽ không đi quá xa đề xuất ban đầu của bạn. Nhưng đừng đắc ý chỉ ra điều đó.

Là 1 BA, việc bạn biết cách để giải quyết vấn đề không quan trọng. Làm cho dev team của bạn cảm thấy tự tin để xử lý vấn đề đó trong khung thời gian và ngân sách mới là quan trọng.

Bạn không thể chỉ đơn giản bắt họ code giải pháp của bạn. Hãy trao đổi, dẫn dắt và biến giải pháp của bạn thành của họ.

Để tránh lặp lại sự khó xử này, hãy chắc chắn rằng bạn luôn kéo team dev vào ở những giai đoạn đầu và solution đã có sự nhúng tay vào của tech lead hoặc 1 ai đó trong dev team. Như vậy sẽ dễ dàng đạt được sự đồng thuận.