Ký sự BrSE

Những nẻo đường kỹ sư cầu nối

Kỹ năng giải thích – thuyết trình

Series kỹ năng mềm dành cho BrSE :

  1. Làm việc nhóm
  2. Xử lý vấn đề
  3. Giải thích – thuyết trình
  4. Đàm phán
  5. Tìm kiếm thông tin
  6. Giao tiếp
  7. Tự học

Cách đây chừng 7 năm, hồi còn mới chập chững vào nghề, có lần mình vừa được khách hàng chỉ cho luồng nghiệp vụ của chức năng mới. Hôm đó anh Onsite Lead bận … fix bug nên mình mới được “đặc cách” đi họp 1 mình. Lúc về truyền đạt lại, sau vài lần giải thích, ãnh nhăn mặt hỏi lại “chú đang nói cái giống chi rứa” (ãnh người miền Trung), căn bản là ỗng chậm tiêu nên mới nói thế … Lúc đấy đã từng nghĩ vậy, nhưng sau một thời gian bầm dập, thấy sai quá sai, cốt lõi vẫn tại bản thân, cụ thể hơn là do không có kỹ năng giải thích – thuyết trình. Không có thì học, có sao đâu.

Đấy, như trên cái hình có hết rồi, ai biết tiếng Nhật nhìn vào hiểu ngay cần phải làm gì, còn không thì đọc cái đống bùi nhùi mình viết bên dưới.

Giải thích – thuyết trình trước 1 vài người hoặc trước cả hàng trăm người có sự khác nhau về âm lượng và cả sắc thái. Vì sự khác nhau về âm lượng (đông người nói to hơn) nên gió ra nhiều hơn, người ta gọi là “chém gió” có lẽ vì vậy 😀 . Còn về nội dung cũng như mục đích thì cơ bản là giống nhau :

  • Nội dung : cái mình muốn nói, cái người ta muốn nghe
  • Mục đích : làm sao cho người ta hiểu

Thật vậy, nói mà họ không hiểu thì 1 là do họ ngu hoặc ngược lại … mình ngu. Vì thiếu kiến thức, thiếu kỹ năng bẻ nhỏ – liên kết – lập luận nên các ý rời rạc, thiếu tính thống nhất khiến cho ngay cả bản thân đôi khi còn không biết mình nói cái gì thì đôi phương hiểu bằng niềm tin.

Tiếp theo là trình tự để giải thích – thuyết trình. Có 3 bước

  • Hiểu rõ cái mình muốn nói
  • Tìm cách hay nhất để biểu đạt
  • Truyền đạt và nhận phản hồi

Hiểu rõ cái mình muốn nói

Thì cũng với cách thông thường mà làm, to quá bẻ nhỏ ra, 1 bó đũa khó quá thì bẻ từng chiếc. Một chủ đề quá phức tạp ta cứ chia nhỏ thành các chủ đề con, ứng mỗi con thì có nhiều cháu, đưa về đơn vị nhỏ tới mức hiểu được là được. Và sau đấy tổng hợp lại, đúc kết ra được khái niệm, ý tưởng. Từ đó mới xuất ra câu chữ mà phụt ra mồm được.

Đối với giải thích lúc nói chuyện, đàm đạo thì cái khó là phải đối ứng nhanh, không có nhiều thời gian để nghĩ. Chỉ trông cậy vào lượng kiến thức có sẵn để đưa ra điều muốn trình bày. Vậy nên hãy đọc thật nhiều sách vở báo chí, blog để có nền tảng cơ bản về các chủ đề, lúc đó lời nói mới đủ sâu và có tính hệ thống giúp người nghe vừa hiểu vừa khoái.

Còn nếu là họp hành, hội nghị sẽ có nhiều thời gian hơn. Cứ chuẩn bị kỹ và nói những gì mình chắc thì không phải lo sợ ai bắt bẻ cả. Nếu họ có ý muốn hỏi sâu, cứ trả lời những gì mình biết. Còn vặn vẹo chỉ để thoả mãn tính thích thể hiện, cứ cho họ toại nguyện, hơi đâu chấp vặt 😀

Tìm cách hay nhất để biểu đạt

Đối với một vấn đề thường có nhiều cách nói – cách viết, các bạn để ý cái chữ in đậm ở trên “cách hay nhất”. Để đánh giá được cách nào là hay thì cần phải hiểu rõ được đối tượng của mình là ai, đang như thế nào. Ví dụ bạn muốn trình bày với sếp lớn về vấn đề quan trọng, cái đầu tiên cần để ý không phải là cách nói, mà đó là … calendar. Xem sếp có rảnh ko, lúc có thời gian nói chuyện gì cũng dễ, còn đang gấp phải chuẩn bị cho buổi họp với khách hàng lớn chẳng hạn, sếp còn tâm trí đâu mà nghe bạn tỉ tê. Bởi vậy các hợp đồng thường trôi chảy thông qua các buổi nhậu, tất nhiên về mặt ký kết chính thức không phải ở quán nhậu, nhưng những câu chuyện bên lề sẽ suôn sẻ khi 2 bên đều thoải mái về tâm trí và thời gian 😀 nhắc đến nhậu lại thèm bia.

Cách thì có nhiều : bằng lời, bằng file Slide, bằng biểu đồ, hình vẽ, đôi khi bằng tay chân … cách nào cũng được, kết hợp 1 vài cái trên càng tốt nếu thấy cần thiết. Thường nếu để giải thích về bug, trường hợp đối tượng là người biết kỹ thuật, cách hay nhất là cho xem source, còn nếu người nghe mù tịt như sếp (các ông sếp thường mù code) thì đừng có lôi code ra, chọn cách nói nào ít liên quan đến code – database nhất để mà nói. Giải thích về nghiệp vụ thì nên có hình vẽ, biểu đồ hoặc màn hình nghiệp vụ vẫn dễ hiểu hơn là … tả bằng lời. Hoặc giải thích về sự cố hệ thống với khách hàng, phải có file ghi rõ các mục : nguyên nhân, thời điểm phát sinh step by step, đối sách, thời gian đối ứng.

Truyền đạt và nhận phản hồi

Quay lại câu chuyện về sếp ở trên, bước vô phòng nói ít câu mà thấy ánh mắt và cử chỉ bất thường thì nên dừng lại, để lúc khác, vì đánh nhau với cấp trên không phải ý hay. Đó cũng là một cách nhận phản hồi thông qua cử chỉ – đôi khi thông qua cả lời nói với âm lượng lớn kèm một số từ chỉ các bộ phận cơ thể nam nữ. Còn nếu đối phương nghe mình giải thích mà mặt bắt đầu ngu dần đi thì nên dừng lại 1 chút, xem họ không hiểu chỗ nào rồi nói tiếp, tránh làm người nghe sợ hãi.

Những người giỏi nói và có năng khiếu nói (bẩm sinh) họ có cảm quan rất tốt để biết làm chủ câu chuyện, biết lúc nào nên nhanh, nên chậm, biết làm sao cho thú vị hấp dẫn. Còn dân kỹ thuật như anh em mình không nên đua đòi làm gì, nói mà đối phương mặt không ngu ra coi như thành công rồi, đừng đặt kỳ vọng cao quá, té đau lắm.

Kết

Nói làm sao để người ta hiểu thì học dần sẽ được, còn nói sao cho người ta thương và cảm mến thì rất khó. Cái này xuất phát từ tâm. Nếu tâm thiện, kỹ năng mình yếu một chút (yếu chứ không phải không có) cũng bù đắp được. Còn nói hay cỡ nào mà miệng lưỡi ma lanh, mắt đá lên xuống không ngừng, thái độ lồi lõm thì cũng bằng thừa. Vậy nên làm cái gì cũng cốt ở cái tâm, có nhiều BrSE mình biết họ cứ ậm ờ miết, nhưng khách rất thương, mời về nhà ăn cơm suốt. Cái đó chả phải là giao tiếp bằng tâm đó sao. Nếu mà tâm tốt, đắp thêm kỹ năng nữa thì còn gì bằng, tại vì không phải ai cũng đủ thời gian vs tâm huyết để cảm nhận xem tâm mình có tốt hay không, nhiều khi họ chả quan tâm. Nhà bao việc.

4.3/5 - (16 votes)
Nếu thấy hay thì đừng ngại