↓ Chuyển đến nội dung chính
Người đứng trước cánh cửa văn phòng đóng kín giữa nhà máy
  1. Bài viết/

Khi stakeholder không chịu nói chuyện, BA làm gì?

·
Đặng Đức Quân
Tác giả
Đặng Đức Quân
Chuyện nghề BA trong lĩnh vực sản xuất. Viết cho mình, và cho cả những ai đang muốn dấn thân vào con đường này.

Cập nhật lần cuối:

Bạn hẹn họp, họ báo bận, hẹn lại, lại bận, đến lần thứ ba thì bắt đầu tự hỏi họ bận thật hay là không muốn dính vào. Mình gặp kiểu stakeholder này rồi, cứ báo bận, tìm đủ cách để không tham gia dự án, và lý do sâu xa không phải họ ghét ai, mà là họ không thích phải thay đổi.

Nó cũng giống mấy cú sốc mình kể trong bài BA mới vào nghề: 5 cú sốc không ai nói trước, stakeholder không hợp tác chẳng phải chuyện hy hữu gì, nó là chuyện thường ngày của nghề.

họ không ghét bạn, họ ngại thay đổi
#

Rất dễ nghĩ là người ta ghét mình, chắc tại mình hỏi nhiều quá, hay tại mình là thằng tư vấn phiền phức. Theo mình gốc thường nằm ở thay đổi, hệ thống mới nghĩa là cách làm quen tay bị đảo lộn, đằng sau đó có thể là nỗi sợ mất quyền, sợ bị soi ra lỗi, sợ phần mềm làm mình thành thừa. Giả sử một quản đốc đã quen ghi sổ tay, giờ có BA tới hỏi quy trình anh chạy thế nào, rất có thể anh ấy nghe thành người này tới để thay mình. Đổi câu hỏi từ “sao họ ghét mình” sang “họ đang bảo vệ cái gì” thì theo mình mọi chuyện dễ thở hơn nhiều.

nói bằng cái đau của họ
#

Lỗi dễ mắc nhất là mở miệng ra là timeline, requirement, KPI của dự án, theo mình stakeholder nghe xong chỉ muốn đứng dậy về chỗ. Người ta chỉ chịu ngồi nói chuyện khi thấy mình được gì, hoặc đỡ mệt đi, bạn cho ảnh thấy cái màn hình mới giúp ảnh khỏi gõ lại báo cáo mỗi sáng thì ảnh nghe, còn bạn bảo em cần requirement để làm tài liệu thì ảnh trốn.

cửa chính đóng thì đi đường vòng
#

Có người đóng cửa vĩnh viễn, đừng đập cửa, đi cửa sau. Tìm người thật sự nắm quy trình, thường là nhân viên dưới quyền chứ không phải sếp, rồi đi Gemba, đứng cạnh chỗ họ làm việc mà quan sát thay vì hỏi dồn. Với mình observation nhiều khi còn tốt hơn interview, phỏng vấn thì họ có thể không nhớ, hoặc họ kể mà mình hiểu sai, còn đứng xem họ làm thật thì mình hiểu rõ hơn, và còn thấy họ làm khác quy trình, khác cả cách họ nói.

mở màn nhỏ thôi
#

Hẹn một stakeholder đang né mình bằng buổi workshop ba tiếng là cách chắc chắn nhất để ảnh bận đột xuất. Bắt đầu bằng mười lăm phút cà phê, một câu hỏi thôi, không agenda dài dòng, không slide, khi ảnh thấy nói chuyện với bạn chẳng mất gì thì lần sau ảnh ngồi lâu hơn.

có người không bao giờ hợp tác
#

Có những người bạn làm gì cũng vậy, thế thì đừng cố một mình đến kiệt sức, escalate sớm, kéo PM hoặc sếp của họ vào, và ghi lại từng lần mình đã thử liên hệ. Không có requirement thật thì mọi thứ phía sau đều là đoán mò, như mình viết trong bài bộ kỹ năng khai phá “nhu cầu thật”.

Stakeholder không hợp tác không phải lỗi của bạn, nhưng không có cách xử lý thì nó sẽ thành lỗi của bạn, vì cuối cùng dự án vẫn cần requirement, mà requirement lại nằm trong đầu họ. Bạn có nhớ một stakeholder từng đóng cửa với mình không, giờ nghĩ lại thì điều họ đang sợ là gì?

Bài viết liên quan

"em ơi, làm giống Excel cũ nhé": cơn ác mộng của BA

Giả sử bạn đang họp với một anh trưởng phòng, anh ấy mở ra cái file Excel đã dùng nhiều năm, ô xanh ô đỏ loạn xạ, VLOOKUP chồng lên VLOOKUP, rồi nhẹ nhàng bảo “em ơi, làm giống cái này nhé, đơn giản thôi”. Bạn cười, trong lòng thì không cười nổi. Chưa nghe câu đó bao giờ thì chắc bạn chưa làm BA cho dự án chuyển đổi số ở Việt Nam, còn nghe rồi thì chắc bạn hiểu cái cảm giác vừa buồn cười vừa bất lực ấy.

3 nguyên tắc sống còn để lấy yêu cầu hiệu quả

Lấy yêu cầu nghe thì đơn giản, cứ đến ngồi hỏi rồi ghi lại là xong, nhưng làm thật rồi mới thấy nó dễ biến thành ác mộng thế nào, và mấy nguyên tắc dưới đây là những thứ mình đúc ra từ chính các vết sẹo của mình ở dự án ERP/MES. hai trở ngại lớn # Cái bẫy đầu tiên là kinh nghiệm. Thiếu kinh nghiệm thì mình chỉ khai thác được phần nổi của tảng băng, còn phần chìm thì nằm ở mấy chỗ khách hay quên kể như các trường hợp ngoại lệ (business cases), các rủi ro kỹ thuật kiểu tích hợp hệ thống hay chuyển đổi dữ liệu, và phức tạp nhất là yếu tố con người. Cái này không có đường tắt, phải trầy vi tróc vảy qua ít nhất một dự án trọn vẹn mới mong thuần thục. Theo mình, nếu chỉ cầm bảng câu hỏi mẫu đi hỏi thì bạn sẽ chỉ nhận về đúng phần nổi đó, còn nếu người cần hỏi lại né tránh thì xem thêm cách làm khi stakeholder không hợp tác.

Scope creep, chuyện kinh điển và cách sống sót

Hợp đồng ghi đúng ba chữ “module mua hàng”, nghe thì rõ, nhưng module mua hàng 5 input với module mua hàng 15 input là hai thứ rất khác nhau, mà hợp đồng thì không nói là cái nào. Đây là chuyện mình gặp thật. Phạm vi không được ghi rõ nên change request cứ tới liên tục, scope cứ thế phình ra, và mình không có cách nào từ chối khách, vì chẳng có tờ giấy nào nói cái gì nằm ngoài phạm vi. Scope creep, cái thuật ngữ nghe rất chuyên nghiệp ấy, thực chất là chuyện những cái “thêm tí nữa” không bao giờ dừng, và nó không chỉ là vấn đề của BA mà của cả team, cả dự án, cả cái deadline.