Câu nói tôi nghe được từ một người bạn cách đây một năm, điều khiến tôi phải suy nghĩ khá nhiều. Đọc các bài tâm sự của dev đi tán gái có một câu rất phổ biến: "Mình làm lập trình nên khô khan, giao tiếp kém".
Tất cả chúng ta đều biết lập trình viên giao tiếp kém, nhưng bao nhiêu người cố gắng thay đổi nó hay đổ lỗi rằng đây là đặc điểm chung, Dev nào cũng thế?
Tôi không phải người giao tiếp tốt, nhưng tôi luôn cố gắng thay đổi điều đó từng ngày. Có những đêm trước khi họp, tôi ngồi trong phòng nhìn lên trần nhà hàng giờ suy nghĩ về các trường hợp có thể xảy ra và mình cần nói như nào? Lúc nào nên chèn cảm xúc vào câu nói và chèn bao nhiêu là vừa đủ?
Và đây là những mẹo nhỏ trong công việc có thể giúp cuộc đời Dev tươi đẹp hơn. Vốn dĩ làm Dev khổ, hãy tự cứu vớt nó.
Hạn chế trả lời thẳng
Dev hay người làm kỹ thuật nói chung thường có thói quen trả lời thẳng. Hỏi A thì trả lời A, hỏi B trả lời B. Nhưng có thực sự lúc nào cũng tốt?
Một ví dụ mà tất cả Dev đã gặp:
Bao giờ xong em nhỉ?
Tôi khẳng định một tỷ phần trăm dev gặp câu này, có khi hằng ngày luôn. Không trả lời thẳng câu hỏi này là điều tôi làm.
- Mình sẽ trả lời bạn trong chiều nay nhé, mình cần xem lại các công việc khác và nguồn lực của team mình đang có để đưa ra quyết định chính xác.
- Mức độ quan trọng của việc này là như nào bạn nhỉ? Team mình đang full workload nên cần cân đối.
Có rất nhiều cách để trả lời nhưng lời khuyên chân thành là đừng trả lời luôn câu này. Dev rất dễ bị trạng thái 0–1, tức là mọi thứ thẳng thắn, hỏi A là trả lời A, hỏi B là trả lời B. Trả lời luôn thường dẫn đến sai lầm đơn giản là bạn ra quyết định quá vội vàng dẫn đến một là deadline quá sớm, hai là dealine quá muộn. Còn nếu bạn tự tin thì trả lời luôn cũng được, bản thân mình thì thường không làm thế ?
Bám sát mục đích cuối cùng
Dev là một vai trò tại công ty, không phải tay sai của người khác nhưng rất hay bị team khác "lái", vì đơn giản là các feature của sản phẩm đều phục vụ business.
Nếu bạn không muốn làm hùng hục rồi lại xóa code rồi lại làm hùng hục mà chẳng được ghi nhận thành quả thì hãy học cách bám sát mục đích.
Ví dụ 1:
Đối phương nói quá nhiều từ ngữ chuyên ngành mình không hiểu
Đây là tình trạng phổ biến khi giao tiếp với các team khác. Họ dùng từ tiếng anh, thuật ngữ chuyên ngành mà mình không hiểu. Thường thì cách này dùng để đánh lạc hướng đối phương, chờ đối phương hoang mang, chiếm lợi thế rồi chốt hạ.
- Từ từ, bạn nói overview trước cho mình dễ hiểu đi. (Trong lúc này thì hỏi ý nghĩa các thuật ngữ, học hỏi kiến thức luôn)
- Việc này liên quan đến xxx như nào (XXX là chủ đề đang nói, mục đích là bám sát mục tiêu của cuộc nói chuyện)
Ví dụ 2:
Vẽ quá nhiều feature, toàn feature khó mà không biết có dùng không, lớ ngớ code hùng hục xong không ai dùng
Cái này thì cũng gặp nhiều, mấy ông tính "bay bay" vào phòng họp là y rằng làm chức năng giống google, giống facebook ?
"Vũ khí" của họ là đánh vào lòng tự trọng của Dev. Kiểu như "ơ, anh thấy thằng này có chức năng đấy này", "Anh thấy chức năng hay nhưng sợ khó các em không làm được"...
Nhắc lại phần một: "Không trả lời thẳng"
Anh hỏi em làm được không, không có nghĩa là em phải trả lời có hay không. Bám sát mục tiêu thôi, business của công ty bạn có thực sự cần feature đó ngay tại thời điểm này không?
Lời kết phần đầu
Biết địch biết ta, trăm trận trăm thắng. Trước khi họp hay trước các cuộc nói chuyện có thời gian chuẩn bị thì hãy suy nghĩ thật kỹ, tính toán trước các trường hợp có thể xảy ra và sẽ trả lời như nào? Có thể inbox hỏi những người có kinh nghiệm về các trường hợp đó.
Còn đối với những cuộc nói chuyện không có thời gian chuẩn bị thì uốn lưỡi 7 lần trước khi nói. Uốn 7 lần chưa ra thì xin thêm thời gian nghĩ chứ đừng quyết định vội.
