thay Không bằng Có, nhưng

Chúng ta đã cùng đi qua một vài nguyên tắc được khuyến khích trong giao tiếp:

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

Đưa kết luận lên trước khi trả lời câu hỏi về công việc

Đó đều là các nguyên tắc khá đơn giản trên lý thuyết nhưng trên thực tế lại khó thành thạo.

Tôi nghĩ một nguyên nhân chủ yếu là mọi người chưa thấy “giao tiếp trong công việc” là rất khác so với “giao tiếp trong cuộc sống”, từ đó chưa thấy sự cần thiết phải bỏ chút công sức xây dựng thói quen giao tiếp hiệu quả trong công việc, mà phần lớn chỉ dựa vào thói quen giao tiếp cuộc sống sẵn có, nghĩ sao nói vậy (và nói sao viết vậy nữa!) thôi.

Trong bài này, xin giới thiệu một nguyên tắc nữa trong giao tiếp:

Trả lời Yes, but … thay vì trả lời No

Trong thực tế công việc, sự thực là các team khá thường xuyên phải đối mặt với những yêu cầu khó từ khách hàng, có yêu cầu vượt quá khả năng và team buộc phải từ chối.

Thực ra bản thân việc từ chối là hợp lý trong nhiều tình huống. Một BrSE còn non kinh nghiệm sẽ thấy mình rất khó từ chối khách hàng và thậm chí phải mất nhiều năm mới biết lúc nào nên từ chối và quan trọng hơn nữa là căn cứ đâu để từ chối. Người ấy sẽ chú trọng thoả thuận về phạm vi công việc (SOW scope of work) và biết SOW sẽ trở thành căn cứ quý giá thế nào cho bản thân anh ta trong những tình huống phải từ chối khéo về sau.

I. Bắt đầu từ cơ bản

Dần dà về sau, có một số người sẽ cân nhắc lựa chọn giữa việc phát triển quan hệ xã giao/ họ hàng/ làng xóm với việc giữ gìn sức khoẻ cá nhân, giành thời gian cho gia đình nhỏ. Một số ít sẽ tìm cách cân đối (balance) các ưu tiên và sẽ phát triển kỹ năng từ chối ăn nhậu cho riêng mình.

Một BrSE nhanh nhạy trong công việc cũng sẽ nhận ra cần cân nhắc độ ưu tiên của rất nhiều yếu tố: Yêu cầu khách hàng, khả năng của team, tốc độ, chất lượng, chi phí OT…. Phần lớn sẽ phải tìm được cách balance phù hợp nhất trong tình huống hiện tại và đương nhiên không phải lúc nào điểm cân đối “phù hợp nhất” đó cũng là thoả mãn 100% yêu cầu của khách hàng, và thường xuyên hơn là sẽ chỉ thoả mãn được một phần, đồng nghĩa với việc phải từ chối một số phần khác của Yêu cầu khách hàng.

Suy ngẫm về việc này, tôi thấy về cơ bản có vẻ chỉ có 2 loại chiến lược từ chối.

Chiến lược thứ nhất, đơn giản và hiển nhiên nhất là đưa ra lý do từ chối. Bị mời rượu thì: “Tôi không uống được rượu”, “cháu đang ốm, bác sĩ bảo phải kiêng”, “tôi theo đạo, giữ giới không uống rượu” …. BrSE thì “team chưa có kinh nghiệm về việc này”, “e rằng team sẽ không đảm bảo được chất lượng”, “do đang bận việc xyz nên không thể hoàn thành vào ngày abc”, “theo policy của công ty thì phải viết operation note và xin approve cho từng target DB nên không thể kịp được”…

Chiến lược thứ hai, được rút kinh nghiệm bài bản hơn từ những sự vụ trong quá khứ thì chính là đàm phán SOW ngay từ đầu, nêu rõ x thì thuộc scope, còn y thì không. Ví dụ “estimate này chưa bao gồm effort viết test code”, “việc cung cấp thống kê sample dựa trên dữ liệu thật sẽ được cover bởi ticket khác”, “chi phí thuê tên miền sẽ do khách hàng chi trả”…

Những ai quen tư duy viết hợp đồng thì hiểu cái này ngay: “bên thuê nhà phải tự chi trả phí dịch vụ/ internet/ điện nước …”, “phí cầu đường do quý khách tự trả”, “vui lòng thanh toán thêm nếu dùng mỳ tôm ở minibar” …. Tôi cũng từng trả lời lời mời đi ăn nhậu kiểu: “nếu tớ đến được thì cũng chỉ uống nước cam thôi đấy”, hoặc ngay lúc ngồi xuống có mặt vài sếp Nhật “xin phép là tôi không uống rượu, nên các bác thấy không ổn thì tôi xin ngồi ra chỗ khác”.

II. Cũng được, nhưng rồi …

Sau nhiều năm kinh nghiệm với vai trò BrSE, bản thân tôi đã hình thành thói quen đàm phán SOW sớm và Nói “không” (say No) khi cần thiết.

Những tưởng vậy là xong (problem solved), nhưng tôi đã nhầm.

Thượng tầng công ty thay đổi và vào một trong những training đầu tiên của sếp mới, mọi người tham dự được yêu cầu áp dụng nguyên tắc: Không say No với khách hàng !

Tôi hơi choáng váng vì nguyên tắc trên của sếp hoàn toàn ngược lại với cách tôi vẫn làm: say No trong công việc khi cần thiết, như đã nói ở phần trước.

Trong lúc còn đang hoang mang bối rối thì sếp mới giải thích lý do của điều trên. Tuy không còn nhớ chính xác, nhưng đại loại nó thế này: “say No với khách hàng thì không hay!”

Từ chối khách hàng thì không hay!

Đời là thế, giải quyết được một vấn đề thì vài vấn đề khác sẽ lại mọc ra thêm. Nhưng dù thế nào, ta vẫn phải tiến lên.

III. Tiến hoá

Đến lúc này, tôi buộc phải suy nghĩ hẳn hoi về chuyện say No (Nói “không”).

Ừ thì tôi không phụ thuộc vào, nên chẳng cần khéo léo giữ các mối quan hệ trên bàn nhậu. Tôi có thể không quan tâm người khác nghĩ gì, đánh giá gì về mình, nhưng ….. nghĩ kỹ thì mọi chuyện đâu chỉ về tôi.

Khi sếp nói “từ chối không hay” thì ý là Khách hàng sẽ đánh giá công ty tôi qua người tiếp xúc (contact point) với họ, và trong trường hợp này, đó là BrSE/ Comtor.. Như thế, mỗi khi tiếp xúc khách hàng, sếp muốn mọi người luôn phải ý thức rằng lúc đó mỗi người tự động trở thành một phần bộ mặt của công ty.

Vai trò có sự tiến hoá thì đòi hỏi cách giao tiếp cũng phải tiến theo!

Trong lần sếp training đó, chúng tôi cũng được luyện tập với nhiều ví dụ làm sao chuyển từ “No, chúng tôi không thể làm x, y ….” sang một cách diễn đạt khác:

“Yes, chúng tôi có thể làm x, y…, tuy nhiên” –> đây chính là mẹo mà bài viết sẽ giới thiệu:

Yes, but ... (Vâng, tuy nhiên...)

Để chuyển từ diễn đạt No sang diễn đạt Yes, but, chúng ta cần sự tiến hoá trong tư duy. Và để đạt đến trình độ Không bao giờ say No với khách hàng, ta cần xây dựng một thói quen suy nghĩ mới trước những tình huống cũ.

Tôi sẽ hình dung sự tiến hoá ấy đại loại như sau:

. Việc x, y, z là không thể làm được

↓ (nhích lên một tẹo)

. Việc x, y, z là rất khó có thể làm được

↓ (mơ đi – dream on)

. Để mà làm được x,yz thì phải vô cùng “có điều kiện” nhé: Tiền nhiều, thợ giỏi, công cụ xịn vãi chưởng ….

↓ (chém gió chút)

. Nếu “nhà tôi” mà có điều kiện lý tưởng như trên thì tôi cũng làm được x

↓ (tem tém lại)

. Ừ, kể ra muốn làm x cũng được, nhưng cần tiền, tài và tool (3T) xịn đấy 😉

IV. Lý thuyết và ví dụ mẫu

Về lý thuyết thì kỹ thuật “Yes, but” là một phương pháp giao tiếp hiệu quả, giúp duy trì sự tích cực trong cuộc trò chuyện mà không phải từ chối hoàn toàn yêu cầu.

Cách thực hiện kỹ thuật “Yes, but”:

1. Xác nhận:
   • Bắt đầu bằng việc đồng ý hoặc công nhận một phần của ý kiến hoặc yêu cầu của đối phương. Điều này cho thấy bạn lắng nghe và hiểu quan điểm của người khác.
2. Đưa ra điều kiện của bạn:
   • Sau đó, sử dụng “but” để chuyển hướng sang các điều kiện lý tưởng mà bạn cho là cần thiết để yêu cầu của đối phương trở thành chắc chắn được thực hiện. Đây là lúc thay vì giải thích lý do tại sao yêu cầu không thể thực hiện như mong muốn, bạn vẽ nên một bức tranh nửa thực nửa hư trong đó bạn “bỗng dưng” được trang bị một cách lý tưởng để đáp ứng yêu cầu.

Chính thế, mấu chốt ở đây là: Biến các lý do khiến bạn từ chối (say No) thành các điều kiện lý tưởng mà nếu có chúng, bạn sẵn sàng nói “Vâng, tôi đồng ý” (say Yes)

Ví dụ:

Khách hàng: “Bạn có thể hoàn thành dự án trong tuần này không?”

Bạn: “Vâng, tôi hiểu tính cấp thiết của việc này. Chúng tôi có thể, tuy nhiên chúng tôi sẽ cần phía bạn giúp đỡ với chi phí làm thêm giờ (OT), huy động thêm nhân sự từ dự án khác, mua sắm một vài thiết bị chuyên dụng và chấp thuận lùi lịch cho tác vụ update API thêm 2 tuần …. “

Lợi ích của Yes, but:

• Giữ mối quan hệ tích cực: Thể hiện rằng bạn tôn trọng ý kiến đối phương.
• Gợi ý các hướng thay thế có thể đàm phán: Tạo cơ hội để thảo luận về các giải pháp thay thế.
• Tránh xung đột: Giảm bớt căng thẳng với đối phương.

Kỹ thuật này rất hữu ích trong giao tiếp ở nhiều tình huống, bao gồm trong quản lý dự án, thương lượng và giải quyết xung đột.

V. Một tình huống thực tế

Trả lời Yes/ No với lại Đưa kết luận lên trước còn khó để thành thạo thì dĩ nhiên “Yes, but” không hề dễ. Những thói quen cũ luôn có cái đà mạnh mẽ và nếu không đủ sự luyện tập có ý thức/ rút kinh nghiệm/ tiếp tục rèn luyện thì ta sẽ không thể có sự thay đổi hay tiến bộ. Cần có sự kiên trì với bản thân và kiên nhẫn thuyết phục team để tạo ra một thay đổi dù nhỏ.

Câu chuyện thực tế cho bài viết lần này xuất phát từ việc BrSE (kỹ sư cầu nối) của dự án liên lạc xin lùi thời hạn deploy lên Staging do các khó khăn khách quan:

a. Chúng tôi xin lùi thời hạn deploy Ver 2.18 lên Staging đến cuối tháng 9 vì những lý do sau:

1. Cập nhật Slim mode của Bladim gặp khó khăn hơn estimate ban đầu.
2. Phát sinh việc sửa lỗi sau security scan (HSTS và CrossSite).
3. Đối ứng feedback cho version 2.17 (cần khoảng 2 sprint)
4. Giám sát và xử lý các vấn đề liên quan đến Aluna gần đây.
5. Phát sinh điều tra sự cố vào ngày 4 tháng 6.

Chúng tôi xin lỗi về sự thay đổi này và hy vọng nhận được sự đồng ý của các bạn. Đề xuất trên giả định rằng không có feedback nào nữa cho version 2.17., vì vậy xin hãy lưu ý.

Lý do khách quan là thế nhưng sau đó ít phút, khách hàng trả lời:

b.”Có cách nào để điều chỉnh và kịp thời gian release production vào ngày 23 tháng 9 không?”

Khoảng hơn 1 tiếng sau, không thấy BrSE có react gì cho khách hàng, tôi chủ động hỏi thì bạn thông báo team đang họp, họp xong sẽ trao đổi lại với tôi. Chừng 30 phút sau, BrSE chat Slack lại:

c. …em có chia sẻ cho team về mong muốn của khách là release prod vào 09/23
Team thấy như thế rất khó, risk.
Phần ver2.17 chưa lên được prod, ( vừa khách báo thêm 1 bug staging)
Khó giảm scope : vì các phần trong scope đều đang làm dở
Chỉ có cách OT mà như thế team không muốn.

Theo anh mình nên làm thế nào, nên trao đổi thế nào với khách ạ.

Như vậy “rất khó” và “không muốn” là những keyword từ team và may là tôi chủ động hỏi, nếu không rất có thể BrSE đã mang nguyên những keyword đó đi để say No với khách hàng rồi. Điểm tốt là đã có thể ngăn chặn một thông điệp No từ team đến thẳng khách hàng, tuy nhiên điểm khó là sẽ cần thuyết phục team đưa ra một câu trả lời tích cực/ mềm dẻo hơn.

Muốn team trả lời Yes, but, tôi cũng phải bắt đầu từ việc trả lời Yes, but với bạn BrSE:

d. ko muốn và ko được thì cứ từ chối khách thôi em,

có điều là mình có thể xem lại các mục 1-5 và đề xuất bỏ cái gì đó đi.

vd: “2. sửa lỗi sau security scan…” có bỏ được ko? (đang làm dở cũng bỏ đó luôn, cho pending), ngoài ra trong số feedback của 2.17 mình cũng có thể xem xét thêm (có khoảng 16 mục nhỉ) cho một số mục pending …

Ngay lập tức, BrSE trả lời:

e. dạ cái ……đó team làm rồi, đang test ạ, cái feedback 2.17 này bọn em xong rồi ( trừ thằng pending), khách đang test trên staging đó ạ

Hơi chán vì cảm giác như đập đầu vào tường team 🙂 . Nhưng giờ không phải lúc bỏ cuộc. Muốn có kết quả phải chịu khó, kiên trì tiến lên. Tôi tóm tắt tình hình và hẹn trao đổi thêm

f. ok,
btw, anh ghi nhận team ko muốn dừng gì hết và ko muốn thay đổi gì hết
có gì mai anh lên nói chuyện thêm 🙂

Bạn BrSE trả lời đồng ý, lúc này tôi giải thích luôn kết quả tôi muốn thu được từ cuộc nói chuyện, đồng thời hỏi kỹ thêm scope test mà team đang làm vì thấy bạn trả lời ở e. là “đang test ….”:

g. Những mục đang test trên staging ta cũng hoàn toàn có thể xem xét pending được mà: ưu tiên hạn 23/9 hay ưu tiên cái test hơn? –> đẩy cho khách hàng lựa chọn “điều chỉnh” mà em.

Quan trọng nhất là mình có thể trả lời được theo hướng “điều chỉnh” mà KH bảo, đưa ra câu trả là Yes, but (pending abcd, dừng test, dừng sửa sau test xyz….) thì tốt hơn là câu trả lời: No, we can do nothing for you …

anyway, giờ nếu anh hỏi em list up giúp:
.Team đang test những tính năng gì? (ko tính bug)
.KH đang test những tính năng gì trên staging (ko tính bug)
thì em có liệt kê được ko?

Đến hôm sau, trong cuộc họp, sau khi hỏi và tóm tắt lên bảng scope hiện tại, timeline…, tôi nêu thêm các câu hỏi hướng Critical Thinking

• Đâu là bottle neck?  QA hay Dev?

• Có cách nào giảm bottle neck 

• Có cách nào giảm scope release?

• Mốc nào đã chắc chắn và không thể giảm? 

• Từ câu trả lời cho các ý trên đến câu trả lời Yes cho KH thì trở ngại là gì?

Kết quả trao đổi thực tế lúc họp cho thấy hiện tại công việc QA đang là bottle neck, tuy nhiên dù có cắt giảm một số task không phục vụ cho mục tiêu trước mắt thì cũng không rút ngắn được như KH muốn. Tuy vậy, về hướng giảm scope release thì có một số phần có thể nghiên cứu cắt giảm dev. và test …

Đây là note sau buổi họp trên:

h. thanks 2 em về về buổi họp sáng nay, anh note ít kết luận trọng yếu như sau:

thay cho câu trả lời: No, there’s nothing I can do for you

team có thể consider 3 câu trả lời Yes, but như dưới:
. Yes, but the Customer need to test together with us on Dev. env. from xxx (date)
. Yes, but we may need to omit some minor refactorings of …. ( scope of Slim mode refactor to be reduced)
. Yes, but there may be bugs found after release (from 20 – 23 Sep: not enough time to find all issues, no time to fix found issues)

Team đồng ý và sau đó thì câu trả lời được đưa đến KH như sau:

Chúng tôi có thể release lên prod vào 23/9 với các đề xuất điều chỉnh sau:

1. Slim mode có thể sẽ disable các chức năng a,b,c và sẽ chưa sửa các feature k,l,m … (nên có thể sẽ không hoạt động mượt mà）để giảm công phát triển/ test

2. Nhờ bên quý KH cũng sẽ cùng test với chúng tôi trên môi trường dev từ 16/9 đến 20/9 (Bỏ qua việc test trên staging)

3. Sau khi release production ngày 23/9 có thể tìm thấy bug vì chưa được verify đầy đủ

Giờ ta có thể nhìn lại và so sánh phát ngôn của team trước và sau khi áp dụng diễn đạt Yes, but 🙂

VI. Ngoại truyện

Cảm ơn các bạn đã đọc đến dòng này và hy vọng các bạn có thể có một hình dung về tư duy Yes, but.

Xin kết thúc bài viết bằng một tích truyện như sau:

Tương truyền, Bồ Đề Đạt Ma sau khi dùng thần thông vượt biển sang Trung Quốc chỉ bằng một cây gậy và một đôi dép thì ẩn tu quay mặt vào vách suốt 9 năm không nhận đệ tử. Huệ Khả một lòng tầm đạo, tìm đến được am ngài ở ẩn, quyết tâm xin học.

Lúc ấy là mùa đông, Huệ Khả quỳ xuống tuyết trắng ngập gối trước am mà thưa rằng:

“Con không an được tâm mình, xin ngài an tâm cho con”

Bồ Đề Đạt Ma không quay ra, chỉ nói:

“Được thôi, hãy tự chặt một cánh tay của nhà ngươi cho ta, sau đó ta sẽ an tâm cho”

….

Đùa thôi, câu chuyện không phải như vậy, các bạn có thể search goole hoặc hỏi AI phiên bản thật của câu chuyện nhé. Quan trọng là bạn hiểu cách mà Yes, but đã được sử dụng ở đó 😉

Hẹn gặp lại ở tình huống sau