Khách nói họ cần cả một đống màn hình quản lý ở nhiều module, mình hì hục đào mãi mới vỡ ra là thứ họ thật sự cần chỉ là một cái dashboard. Sốc nhẹ.
Đó là một trong những cú sốc đầu tiên của mình với nghề BA, và nó chẳng có trong giáo trình nào mình từng đọc. Bài này gom lại mấy cú sốc mà BA mới vào nghề hay va phải, trong đó hai cú đầu là chuyện thật của mình, còn ba cú sau là quan điểm của mình về những gì người trong nghề hay gặp.
khách nói một đằng, cái họ cần là một nẻo#
Chuyện là có khách yêu cầu rất nhiều màn hình quản lý phức tạp ở các module khác nhau, nghe qua thì tưởng việc to lắm, nhưng khi đào sâu hơn mới thấy thứ họ cần là một dashboard tổng hợp vài chỉ số đơn giản, để theo dõi chỉ số và sự thay đổi theo thời gian, vì họ làm gì có thời gian đi theo dõi công việc từng ngày. Cách đào từ lời khách nói xuống nhu cầu thật, mình viết kỹ hơn trong bộ kỹ năng khai phá nhu cầu.
Cái sốc ở đây là yêu cầu khách nói ra thường là giải pháp họ đã nghĩ sẵn trong đầu, chứ không phải vấn đề của họ. Theo mình, câu đáng hỏi nhất khi nghe một yêu cầu là “anh chị dùng nó để làm gì, và bao lâu dùng một lần”, chuyện này mình có viết thêm trong bài 3 nguyên tắc sống còn để lấy yêu cầu hiệu quả.
nhiều stakeholder, nhiều cách hiểu, yêu cầu đổi liên tục#
Cú này cũng là chuyện của mình. Khi nhiều stakeholder cùng tham gia thiết kế chức năng thì mỗi phiên họp lại vắng một vài người khác nhau, buổi này thiếu ông này, buổi kia thiếu ông kia, thế là chẳng bao giờ thống nhất được cách làm, mà gốc của vấn đề là ngay trong quy trình hiện tại họ đã hiểu khác nhau rồi, nên yêu cầu cứ đổi liên tục. Hoá ra yêu cầu đổi nhiều đôi khi không phải do khách khó tính, mà là dấu hiệu bên trong khách chưa thống nhất với nhau.
Đoạn này là quan điểm của mình chứ không phải kể mình đã làm. Theo mình, trước khi cãi nhau chuyện sẽ làm thế nào, nên đưa các bên về cùng một bản mô tả quy trình hiện tại (AS-IS) và để họ xác nhận, rồi mỗi quyết định thì ghi lại ai quyết, ngày nào, gửi cho cả những người vắng mặt. Đến lúc yêu cầu đổi, bạn có chỗ để chỉ vào mà hỏi: thay đổi này khác gì so với cái cả nhóm đã thống nhất?
dev và ba hiểu spec theo hai kiểu#
Phần này là quan điểm chứ không phải chuyện của mình. Nhiều BA mới vào nghề nghĩ cứ viết spec xong là dev sẽ hiểu, nhưng theo mình BA ngồi giữa stakeholder và dev, mà hai bên cần hai kiểu thông tin khác nhau, stakeholder cần thấy vấn đề của họ được giải quyết, còn dev cần biết dữ liệu nào, logic nào, trường hợp ngoại lệ nào. Viết dài chưa chắc đã rõ, viết sao cho dev hỏi lại ít nhất mới đáng quý.
cảm giác “mình đang đóng góp gì thế nhỉ”#
Giả sử một BA mới vào nghề dành mấy tuần đầu chỉ để quan sát và ghi biên bản họp, trong khi dev vẫn code, stakeholder vẫn nói chuyện với nhau, thì cảm giác mình là người đứng ngoài lề rất dễ xuất hiện. Đây là tình huống giả định, không phải chuyện của mình.
Theo mình, giá trị của BA nằm ở chỗ nhìn ra những chỗ các phòng ban hiểu quy trình khác nhau mà chính họ không nhận ra, và giá trị đó thường đến muộn hơn cái cảm giác vô dụng. Nếu bạn đang ở giai đoạn này thì cứ tập đi xuống chỗ làm việc thật và hỏi những câu tưởng là ngớ ngẩn.
không có template nào dùng nguyên xi được#
Cái này cũng là quan điểm. Template giúp bạn khỏi phải bắt đầu từ trang trắng, nhưng mỗi dự án, mỗi stakeholder một khác, và một tài liệu dày chưa chắc đã có người đọc. Theo mình, BA giỏi là người đọc được tình huống rồi chọn công cụ vừa đủ, thậm chí dám vứt template đi khi nó không giúp gì.
Kể ra mấy cú sốc này không phải để bạn sợ. Theo mình gần như BA nào cũng sẽ va phải ít nhất một cú, và chính chúng dạy mình làm nghề.
Còn bạn, bạn đang gặp cú sốc nào nhất, hay có cú nào mình chưa kể ra?
