Mục đích của câu này nhằm giúp bạn xóa điểm mù công nghệ mà chỉ anh Dev kia biết còn bạn thì không biết, mà một trong hai người không biết thì làm sao mà giao tiếp chung được với nhau. Vậy nên cần phải hỏi để được khai sáng. Mà cái thái độ của bạn lúc này cũng quan trọng không kém. Nó phải "nửa cầu khẩn nửa quan tâm" để cho người ta thấy mình có quan tâm và dù không có chuyên môn sâu về tech nhưng sẽ ráng, sẽ cố nghe để hiểu cho bằng được.

Có thể nó sẽ khá là phức tạp. Bạn phải kiên nhẫn và tập trung để người đối diện họ cũng cảm thấy vậy. Chỉ một phút giây bạn tỏ vẻ "bỏ cuộc" hay "mất tập trung" là người ta sẽ ngưng cái việc ban phát ánh sáng tri thức cho bạn ngay. Khi đó có tiền cũng không cứu được lần thứ 2. :))

Hoặc: “Nếu không làm được đúng như yêu cầu này, mình có giải pháp thay thế nào khả thi hơn không?”. Cái câu này thì lại khác. Câu trước thì nó khiến Dev trở thành nhà đào tạo không hơn không kém, vừa đào tạo vừa trình bày sao cho dân Non Tech cũng hiểu.

Còn giờ câu này là nó bắt người ta phải suy nghĩ. Suy nghĩ xem có phương án thay thế không. Tuy nhiên có một điều bạn phải quan tâm. Đó là một khi có phương án thay thế thì nó sẽ đi kèm với "Nhưng". Tức là bạn phải "đánh đổi" khi chọn phương án này. Vậy nên việc của bạn đó là chờ người ta nghĩ ra phương án thay thế, sau đó chờ người ta giải thích. Có thể việc giải thích này "không quá mượt" như bạn nghĩ đâu. Vì cơ bản kinh nghiệm và skill của Dev dành để develop chứ không phải là chuyên gia "trình bày".

Đôi khi họ có thể quên cái việc nói cho bạn nghe cái "Nhưng" đó là gì. Việc của bạn là chủ động hỏi có "Nhưng" tiềm ẩn nào không? Kiểu như :"Nếu làm theo cách này thì thời gian làm hay công sức bỏ ra có ngang ngửa với cách cũ không? Cách thay thế này có gây mâu thuẫn hay ảnh hưởng gì đến các tính năng và toàn bộ hệ thống không? Đây là cách bạn quan tâm đến Risk. Bạn muốn quyết định thì phải có thông tin.

Ngoài công sức, thời gian, rủi ro cũng là cái cực kì quan trọng bạn phải cân nhắc. Để còn mà giải thích cho các stakeholder khác. Tránh cái việc sau này khi xảy ra cái điều không hay rồi, họ sẽ nói bạn:"Sao lúc trước em không nói với chị?". Cái này thì có mà "God bless you". Hmmm.

Mình lại có cái giả dụ khác thế này. Khách hàng yêu cầu “Hệ thống phải xử lý 1 triệu giao dịch mỗi giây”, dev bảo “Không làm được”. Mình sẽ hỏi: “Với hệ thống hiện tại, mình xử lý được bao nhiêu giao dịch? Có cách nào tối ưu để gần với con số khách hàng muốn không?” Lắng nghe dev sẽ giúp bạn hiểu rõ vấn đề và tránh hiểu lầm.

Ngoài ra, bạn còn cần “Đào sâu” để hiểu gốc rễ. Là BA/PO/PM, mình phải đóng vai trò cầu nối, nên cần hiểu cả góc nhìn kinh doanh lẫn kỹ thuật. Nếu dev nói chung chung, mình sẽ đặt câu hỏi cụ thể hơn:

Đây là cách bạn "mớm thông tin" cho Dev. Có thể họ bí câu từ để giải thích cho bạn. Bạn cứ đoán rồi đề xuất. Bạn nói sai không sao cả. Ngay lập tức họ sẽ đính chính. Bạn ngu tech hay giả bộ ngu tech cũng oke. Việc bạn cần là thông tin bên trong suy nghĩ của anh chàng dev đó. Cố gắng đừng để không khí trở nên căng thẳng mà nó phải rất "nhẹ nhàng êm ái" như hai người đang cụng ly bia rồi bàn về cách sống :)).

Hoặc có thể bạn mở cờ thêm cho người ta kiểu :“Nếu tăng thời gian phát triển thêm 2 tuần, có làm được không?”. Nhiều khi cái "làm không được đâu" mà người ta nói với bạn là câu chuyện Impossible về thời gian thực thi. Có thể stakeholder của bạn khá cứng trong chuyện này. Nhưng mà bạn ơi. Con người ta thường "ngoài cứng trong mềm". Có khi đó chỉ là chiến lược của người ta. Người ta tỏ vẻ "cứng" trong việc kì vọng thời gian. Cho đến khi team bạn nói làm không được. Mà giả sử cái việc "nhận được release mới" nó lại quan trọng hơn cái "mốc thời gian release".

Kiểu thà có còn hơn không thì rồi người ta cũng sẽ thỏa hiệp thôi. Việc của bạn là tìm ra cái "điểm G thỏa hiệp" của Stakeholder. Ai cũng có hết. Chỉ là mỗi người khác nhau. Khôn ngoan trong thương lượng là tìm ra cái "điểm G" ấy để hai bên đều sướng, đều vui vẻ, đều tiếng nói chung và đều có thể cười khà khà sau khi nghiệm thu xong dự án. Đây chẳng phải là vai trò của BA/PO/PM à. Khi mà bạn biến bản thân thành nhà thương lượng, thành đại sứ hòa bình, là cầu nối giữa các bên sao.

Còn một cái chiêu này nữa. Đó là thỏa hiệp lại chất lượng, độ phức tạp hay tiêu chuẩn trong kì vọng của stakeholder. Tức là nếu khách muốn 5. Mà Dev bảo không làm được. Thử deal lại thành 2 hoặc 3 thì có oke không. Ví dụ như: “Nếu không làm được tính năng này, mình có thể làm một phiên bản đơn giản hơn không? Ví dụ, thay vì báo cáo real-time, làm báo cáo cập nhật mỗi giờ?”

Bạn cũng cần giải thích cho dev tại sao khách hàng cần tính năng này (ví dụ: “Khách hàng cần báo cáo nhanh để ra quyết định kinh doanh nên rất là quan trọng với các sếp bên ấy”), rồi hỏi: “Có cách nào đáp ứng một phần nhu cầu này trong thời gian hiện tại không?”.

Cái này là cho Dev hiểu bối cảnh và thông cảm cho tình hình hiện tại và nhu cầu cũng như lợi ích mang lại cho khách hàng vì đâu chỉ mình bạn hay stakeholder muốn biết giới hạn về công nghệ nó nằm ở chỗ nào, Dev cũng cần biết nguyên nhân tại sao người ta lại "muốn" nó đến vậy, nó có lợi gì. Để đẩy anh ta đến giới hạn, khơi cái lòng trắc ẩn (nếu có) của anh ta để khiến họ phải trở thành "đấng cứu thế" ráng nghĩ cách và cày để mà release cho stakeholder.

Quan trọng là giữ tinh thần hợp tác, đừng để dev cảm thấy bị ép buộc. Mình thường nói: “Em hiểu bên anh áp lực thời gian, mình cùng tìm cách để khách hàng hài lòng mà vẫn khả thi nhé!”. Nói nhỏ nhẹ mềm mỏng như người yêu cũ vậy. Món này mà gặp mấy chị em gái thì ối giồi, hết nước chấm. :)) Các anh dev thì cứ kiểu "thôi thôi em không cần phải nói, miễn em vui là được, để đó anh lo". Nói tới đây mình cũng hiểu kha khá vì sao các sếp hay tuyển BA/PO là nữ rồi.

Rồi giờ khi có được thông tin rồi thì quay lại với khách hàng để trình bày lại với khách hàng, nhưng phải rõ ràng và thuyết phục:

Giải thích lý do: “Hiện tại, do hạn chế kỹ thuật, hệ thống chưa thể xử lý 1 triệu giao dịch mỗi giây.”

Đề xuất thay thế: “Nhưng đội đã đề xuất tối ưu để xử lý 500k giao dịch, và sẽ nâng cấp thêm trong giai đoạn sau. Anh thấy phương án này ổn không?”

Mình luôn cố gắng dùng ngôn ngữ kinh doanh, nhấn mạnh lợi ích cho khách hàng, để họ thấy mình đã cân nhắc kỹ lưỡng.

Đừng bao giờ hứa hay cam kết với stakeholder cái gì mà mình "không biết" hoặc "không tự tin". Đơn giản đó là "điểm mù" của bạn thì cứ nói "dạ để em làm việc lại với team rồi phản hồi cho anh/chị vào chiều nay ạ". Thật tình thì chả ai dí súng vào đầu bạn bắt bạn hứa gì đâu. Mà có cả bị dí súng như vậy nhưng tiêu chuẩn làm việc của bạn là phải có.

Đừng có ra vẻ. Đừng có khệnh khạng muốn thể hiện power rồi về "ép team chảy nước" để đạt được cái "khệnh khạng" kiểu như "tao vừa ép được team làm một thứ impossible. Thật là chiến tích. Cái suy nghĩ này nó tào lao vãi cả ra. Việc của bạn khi làm nghề là "cân bằng lợi ích giữa các bên" chứ không phải chỉ là "làm hài lòng khách hàng". Đôi khi cái cảm giác hài lòng ấy sẽ khiến bạn chẳng còn ai phía sau lưng. Làm người có trước có sau. Đừng mỗi chỉ bợ đít cái thằng hay khen mình.

Rồi sau mấy cái sự vụ như vầy. Nên tỏ ra biết điều tý xíu. Mời ly cà phê chẳng đáng làm bao đâu. Có thể đúng đây là job và mọi người đều đã được nhận lương. Nhưng mà mấy cái này đâu phải cái ngày vẹo nào nó cũng xảy ra. Lâu lâu nó mới xảy ra. Đặc biệt nó mới xảy ra. Mà đã đặc biệt thì mời ly nước có có đáng là bao. Nó thể hiện cái "sự biết điều" của bạn với anh em đồng nghiệp. Thì mới còn mấy cái gọi là "lần sau". Chứ cứ cái kiểu này thì có cái vẹo lần sau cho anh em thương lượng. :))

Lời tâm sự tới đây. Cảm ơn cho câu hỏi của bạn Lemon Tree Lemon Tree trên cộng đồng chuyện nghề BA/PO/PM để có cái post này. Have fun. Hi vọng là nó giải quyết được cái điều bạn lăn tăn.