Com. at work: Đưa kết luận trên trước

Bài trước chúng ta đã đến với một nguyên tắc được khuyến khích trong giao tiếp công sở:

Trả lời Yes No cho câu hỏi Yes No

Thực ra, nguyên tắc trên có thể xem là trường hợp cụ thể của một nguyên tắc khác, đó là:

  Kết luận trước

(đưa kết luận lên trước)

Từ góc độ lý thuyết, nguyên tắc “Kết luận trước” nói trên lại là một phần rút gọn của phương trình gọi là PREP (Point, Reason, Example, Point) hoặc cũng có tên gọi khác là CREC. Đây là một phương pháp rất cơ bản và dễ áp dụng. Với phương pháp này, bạn sẽ trình bày theo thứ tự: “Point (Đưa ra luận điểm), Reason (Giải thích lý do), Example (Đưa ra ví dụ), Point (Khẳng định lại luận điểm)”.

1. Đưa ra luận điểm chính: Bắt đầu bằng việc đưa ra luận điểm chính của bạn.
2. Giải thích lý do: Tiếp theo, giải thích lý do tại sao luận điểm của bạn là quan trọng.
3. Đưa ra ví dụ: Bạn cần cung cấp một số bằng chứng hoặc giải thích để thuyết phục người nghe quan điểm đã nêu. Việc đưa ra ví dụ sẽ giúp người nghe dễ hình dung.
4. Khẳng định lại luận điểm chính: Kết thúc bằng cách khẳng định lại luận điểm chính để nó hằn sâu vào tâm trí người nghe.

Công thức PREP giúp ta trình bày hiệu quả nên nó được áp dụng rộng rãi trong những tình huống như trả lời phỏng vấn, trả lời đối tác hoặc trả lời câu hỏi trong các buổi hội họp, viết bài luận, giảng dạy và cả giao tiếp hàng ngày. Cụ thể hơn, PREP giúp người nghe hoặc độc giả nắm bắt được ý chính ngay từ đầu, vì thế làm cho thông điệp được truyền tải rõ ràng và dễ hiểu. Với một cấu trúc logic PREP giúp bạn trình bày lý do và bằng chứng để hỗ trợ quan điểm của mình, tăng khả năng thuyết phục của bài trình bầy. Cấu trúc của PREP cũng giúp người nghe dễ nhớ thông điệp của bạn. Việc lặp lại điểm chính ở cuối giúp củng cố ấn tượng và làm người nghe nhớ lâu hơn.

Đó là lý thuyết. Tiếp theo bài viết sẽ giới thiệu một vài ví dụ giao tiếp trong thực tế dự án và vài cách đơn giản để cải thiện chúng theo nguyên tắc “Kết luận trước”.

Tình huống 1:

Bối cảnh:

Sau sự cố network traffic tăng cao dẫn đến phải tắt các batch trên môi trường dev và staging, team đề xuất bỏ thêm tiền để tăng network capacity đồng thời bật lại các batch đó như cũ. PO thì muốn cân nhắc thêm khả năng không bỏ thêm chi phí ngay, tạm thời không bật lại các batch mà thử làm giảm traffic bằng cách khác. PO hỏi thêm thông tin từ team để có thể ra quyết định bật lại hay không bật lại batch.

PO: câu hỏi đặt ra về mặt nghiệp vụ là: Nếu không mở lại batch trên dev và staging tuần này thì sẽ có vấn đề gì?

Tech lead: Nếu ngừng batch thì

• không có project abcd mới được sync về
• không có project mới được sync từ gmail về
• không update tbd group mới khi có thay đổi group history
• không có report gmail hàng ngày
• Không unlock tự động được những kol đã bị khóa
• không gửi email nhắc nhở cho những poet import bị fail

đây là các hoạt động bị ngừng khi không chạy batch staging ạ Hiện tại team không có hoạt động test trên staging Nếu tuần này khách cũng không có hoạt động gì trên staging thì em nghĩ là cũng sẽ không có ảnh hưởng ạ

Có thể thấy câu trả lời khá dài, nhiều chi tiết. Trở lại với người đặt câu hỏi thì ở đây logic của PO là:

Nếu không ảnh hưởng lắm –> tạm thời không cần bật lại batch, ngược lại thì sẽ phải bật lại

.Với logic đó, điều PO quan tâm nhất là: Ảnh hưởng ít hay nhiều?

Tuy nhiên với một câu trả lời càng dài, PO sẽ phải đọc càng nhiều trước khi hiểu kết luận của team.

.Trong trường hợp này, nếu người trả lời áp dụng PREP thì sẽ tăng được tốc độ hai bên hiểu nhau và giúp PO ra quyết định nhanh hơn mà vẫn chính xác. Vậy cách đơn giản nhất để làm việc này là gì?

.Thực tế, tôi đã tham khảo chính Tech lead, chủ nhân câu trả lời ở trên:

hỏi: Theo em, câu nào là quan trọng nhất trong đoạn trả lời?

đáp: Là 2 câu cuối cùng ạ: “Hiện tại team không có ….. không có ảnh hưởng ạ”

.Như vậy ta đã biết chỗ nào là quan trọng nhất. Tiếp theo, rất đơn giản là chỉ cần chọn câu có chứa kết luận mà PO quan tâm và đưa nó lên đầu:

Phương án sửa:

Tech lead: Nếu tuần này khách cũng không có hoạt động gì trên staging thì em nghĩ là cũng sẽ không có ảnh hưởng ạ

Nếu ngừng batch thì

• không có project abcd mới được sync về
• ….
• …..

đây là các hoạt động bị ngừng khi không chạy batch staging ạ

Hiện tại team không có hoạt động test trên staging

Hoàn toàn không thay đổi gì hết ngoài việc di chuyển một câu quan trọng nhất. Đơn giản phải không ạ? Tất nhiên phương án sửa trên là chưa hoàn hảo nhưng đã thoả mãn nguyên tắc: Kết luận trước, qua đó giúp PO nắm được ảnh hưởng nhanh hơn.

Nếu có thời gian, ta hoàn toàn có thể chỉnh sửa thêm một chút câu trả lời cho formal hơn, còn nếu không, cứ trả lời như phương án trên cũng đã là tốt hơn rồi.

Tình huống 2: PO liên lạc với khách hàng như sau

——-

[Xin ý kiến:] Security policy của FV có thay đổi

[Hiện trạng]:

• Chúng tôi đã chuẩn bị sẵn sàng để release yêu cầu đảm bảo security trước đây vào ngày 22/11
• Các hệ thống hiện đang sử dụng kỹ thuật Encrypt 2 chiều cho password
• Các thông tin config hiện được lưu trong Gitlab

[Vấn đề]:

Ngày hôm nay, Security policy của FV lại được nâng cấp, cụ thể các yêu cầu mới như sau:

•   a. Toàn bộ các password phải chuyển sang áp dụng kỹ thuật Encrypt một chiều (không giải mã ngược)
•   b. Các thông tin config nhạy cảm cần được lưu lên Verata thay vì Gitlab

Vậy chúng tôi muốn xin ý kiến các bạn về giải pháp cho vấn đề đã nêu ở trên.

Phương án 1: Việc đảm bảo security theo yêu cầu cũ sẽ được release theo kế hoạch như cũ vào ngày 22/11. Sau đó, chúng tôi sẽ phát triển phần liên kết abcd và khi hoàn thành, chúng tôi sẽ triển khai Encrypt một chiều và lưu trữ các thông tin config vào Verata.

Phương án 2: Không release bản đối ứng cho yêu cầu đảm bảo security cũ nữa, thay vào đó chúng tôi sẽ dành khoảng 3-5 ngày để hoàn thành chuyển đổi sang Encrypt một chiều và lưu vào Verata các thông tin config (cho đến ngày 28/11), release. Và sau đó chúng tôi sẽ phát triển phần liên kết abcd (từ ngày 29/11).

Phía chúng tôi recommend Phương án 2. Tuy nhiên, do có ảnh hưởng làm chậm kế hoạch phát triển phần liên kết abcd (hoãn đến 29/11 thay vì 23/11 ) nên chúng tôi muốn xác nhận ý kiến của quý khách về phương án xử lý.

—–

Vâng, một liên lạc khá dài! Liệu ta có thể áp dụng nguyên tắc “Đưa kết luận lên trước” để sửa trường hợp này thế nào?

Đơn giản nhất thì ta lại tìm câu quan trọng nhất và đưa nó lên trên, tuy nhiên trong trường hợp này không có “câu quan trọng nhất” nào thực sự truyền tải được thông điệp. Như thế, ta sẽ phải bỏ công “chế biến” một chút.

.Vì tạm thời không thấy câu nào quan trọng nhất để “ăn sẵn”, ta sẽ phải đi tìm những ý quan trọng nhất.

.Vì mục đích liên lạc ở đây là “Xin ý kiến”, hẳn những ý cần tìm nằm ở phần Xin ý kiến. Phần này thực chất đưa ra 2 phương án, vậy ý quan trọng nhất của 2 phương án này ở đâu.

. Ta thử tìm và bôi đậm chúng:

    Phương án 1: Việc đảm bảo security theo yêu cầu cũ sẽ được release theo kế hoạch như cũ vào ngày 22/11. Sau đó, chúng tôi sẽ phát triển phần liên kết abcd và khi hoàn thành, chúng tôi sẽ triển khai Encrypt một chiều và lưu trữ các thông tin config vào Verata.

Phương án 2: Không release bản đối ứng cho yêu cầu đảm bảo security cũ nữa, thay vào đó chúng tôi sẽ dành khoảng 3-5 ngày để hoàn thành chuyển đổi sang Encrypt một chiều và lưu vào Verata các thông tin config (cho đến ngày 28/11), release. Và sau đó chúng tôi sẽ phát triển phần liên kết abcd (từ ngày 29/11).

.Phần diễn đạt của Phương án 2 hơi loằng ngoằng nhưng thôi, ta sẽ không đi sâu vào điểm đó trong bài này. Điều thiết yếu hơn là chúng ta đang muốn đưa ra một “Kết luận”, một thứ tóm tắt được điểm chính mà PO đang muốn “xin ý kiến”.

.Vậy hãy cùng nhìn vào điểm giống và điểm khác giữa 2 ý được bôi đậm ở trên. Điểm giống là cả 2 đều có ngày release, điểm khác là ngày và nội dung release cụ thể.

.Xuất phát từ điểm chung trên, ta thấy ở phương án 1 thì ngày release được giữ nguyên như cũ, còn ở phương án 2 ngày release bị thay đổi

.Với những điểm trên thì tiếp theo ta chỉ cần “chế biến” một câu văn với những keyword đã cố ý được in nghiêng ở trên để biểu đạt mục đích “xin ý kiến”. Cụ thể, hãy đặt câu phù hợp với mục đích liên lạc, sử dụng những từ sau:

"xin ý kiến", "ngày release", "giữ nguyên", "thay đổi"

.Đến đây vấn đề chỉ còn là một bài tập đặt câu của học sinh lớp 2. Tôi du hành quá khứ giả tưởng về trường tiểu học của mình và cho ra kết quả 🙂 :

 Xin ý kiến v/v giữ nguyên hay thay đổi ngày release

.Đặt câu xong thì ta chỉ cần đưa nó lên đầu là có phương án sửa theo nguyên tắc “Kết luận trước” rồi !

Phương án sửa:

[Xin ý kiến v/v giữ nguyên hay thay đổi ngày release]

[Hiện trạng]: ….

[Vấn đề]: ….

…..

.Vì ta đang xin ý kiến về ngày release, tiếp theo có thể bôi đậm 2 phương án ngày để KH nhìn thấy cụ thể ngay:

[Xin ý kiến v/v giữ nguyên hay thay đổi ngày release]

[Hiện trạng]: ….

[Vấn đề]: ….

Vậy chúng tôi muốn xin ý kiến các bạn về giải pháp cho vấn đề đã nêu ở trên.

Phương án 1: Việc đảm bảo security theo yêu cầu cũ sẽ được release theo kế hoạch như cũ vào ngày 22/11. ….

Phương án 2: … hoàn thành chuyển đổi sang Encrypt một chiều và lưu vào Verata các thông tin config (cho đến ngày 28/11), release. …..

Phía chúng tôi recommend Phương án 2. …..

. Đến đây, nhận thấy đằng nào ta cũng recommend Phương án 2, như thế có thể rút ngắn câu Kết luận ở đầu một chút:

–>

[Xin ý kiến v/v thay đổi ngày release]

[Hiện trạng:] ….

[Vấn đề:] …….

….

Bạn có thể cho rằng: ờ thì đưa Kết luận lên trước cũng được, nhưng hiệu quả thu được có đáng kể? có đáng phải làm thế ? Các PO phải tự đi mà hiểu kết luận chứ, đó là công việc của họ mà.

Vâng, thực ra tôi cũng là một PO và tôi có thể đọc rất lẹ, tuy nhiên khoa học cho thấy khi đọc và xử lý thông tin thì năng lượng tâm trí bị hao mòn khá nhanh. Vì thế nếu trong ngày tôi phải đọc đến đoạn liên lạc thứ 20 dài như trên thì chắc là khá mệt và hoàn toàn có thể hiểu sai. PO hiểu sai, làm việc không hiệu quả thì hậu quả không chỉ mình ông ta phải gánh. Thôi thì áp dụng PREP cũng coi như một cơ hội giúp ông PO và qua đó cũng là giúp mình khỏi phải OT hay viết báo cáo lên báo cáo xuống nếu nhỡ incident xảy ra.

Mà thật lòng, nếu là bạn thì bạn muốn trả lời liên lạc có tiêu đề nào hơn:

[Xin ý kiến: Security policy của FV có thay đổi]

hay là

[Xin ý kiến v/v thay đổi ngày release]

Cảm ơn bạn đã đọc bài và xin hẹn gặp lại 🙂