Những yêu cầu nhỏ nhưng thiếu chính xác có thể lãng phí rất nhiều thời gian của cả nhóm
(staysaasy.com)- Những yêu cầu mơ hồ từ quản lý và lãnh đạo, dù trông như câu hỏi nhỏ, vẫn có thể làm xáo trộn lớn về thời gian, mức độ ưu tiên và hướng thực thi của cả nhóm
- Những cách nói như “hãy kiểm tra giúp”, “cần làm theo hướng hiện đại” rất dễ dẫn tới phản ứng quá mức như làm báo cáo, slide, làm việc cuối tuần hoặc nâng cấp quy mô lớn
- Người đưa ra yêu cầu cần nói rõ cả mức thời gian đầu tư mong đợi, ảnh hưởng tới ưu tiên, là kiểm tra tài liệu sẵn có hay công việc mới, và kết quả sẽ được dùng vào đâu
- Người nhận yêu cầu cũng cần hỏi lại về mức độ công sức và xác nhận những điểm chưa rõ, đồng thời không nên giả định rằng lãnh đạo bận đến mức không thể trả lời
- Nếu nói cụ thể đến mức hơi ngượng ngay từ đầu, có thể giảm đáng kể sự hỗn loạn, công việc sai hướng và chi phí lãng phí về sau
Cách một yêu cầu nhỏ phình thành công việc lớn
- Trong tổ chức, việc một yêu cầu ngắn và có vẻ nhẹ nhàng phình ra thành khối lượng công việc lớn hơn nhiều so với dự kiến diễn ra lặp đi lặp lại
- Có trường hợp quản lý hỏi “có thể làm X không?”, người báo cáo trực tiếp lại dành nhiều thời gian gấp 10 lần dự kiến, rồi quản lý phản hồi rằng “tôi không hề muốn bạn tốn đến mức đó”
- Một câu ngắn của lãnh đạo trong cuộc họp như “bạn kiểm tra giúp việc này nhé?” có thể dẫn đến tình huống 24 người tạo ra 4 phiên bản bộ slide và làm việc cả cuối tuần
- Nhưng đến cuộc họp, vị lãnh đạo đó có thể chỉ xem phần tóm tắt ở câu đầu tiên của slide đầu tiên rồi nói “không cần cả bài trình bày đâu”
- Câu như “phải hiện đại, không cần biện minh” nếu không xác nhận ý nghĩa thì có thể bị hiểu thành một đợt nâng cấp công nghệ quy mô lớn
- Trong thực tế, ý định chỉ có thể là cập nhật cú pháp API sang phiên bản mới trong vài năm
- Trong lúc đó, việc phát hành các dự án quan trọng có thể bị trì hoãn
Những gì người đưa ra yêu cầu cần quyết định trước
- Khi giao việc, lãnh đạo cần nói thẳng giới hạn thời gian mong đợi
- Ví dụ: “Đừng dành quá 20 phút, sau 20 phút cứ mang những gì đã có đến”
- Cũng cần nêu rõ việc này sẽ ảnh hưởng thế nào đến mức độ ưu tiên
- Ví dụ: “Tôi dự đoán sẽ mất khoảng 2 tuần, và không nên làm giảm đáng kể mức ưu tiên của các việc quan trọng khác”
- Nếu lịch thực tế khác đi hoặc xung đột với việc khác, cần nói ngay là phải liên hệ lập tức
- Cần phân biệt rõ là chỉ cần kiểm tra tài liệu sẵn có hay phải phân tích hoặc tạo mới
- Ví dụ: “Chỉ cần cho tôi biết chúng ta đã có gì về chủ đề này chưa. Nếu chưa từng nghĩ tới thì chỉ cần biết vậy là đủ”
- Nếu cho biết kết quả sẽ được dùng ở đâu, người nhận sẽ dễ điều chỉnh mức công sức phù hợp hơn
- Ví dụ: câu trả lời gửi cho khách hàng tiềm năng bên bán hàng, chuẩn bị cho phần Hỏi & Đáp của buổi All Hands tiếp theo, hoặc chủ đề trọng tâm của cuộc họp hội đồng quản trị sắp tới
Những gì người nhận yêu cầu cần xác nhận
- Người nhận yêu cầu cần đặt câu hỏi làm rõ
- Cần xác nhận mức công sức, chẳng hạn: “Anh/chị mong đợi một kết quả rất kỹ lưỡng cần nhiều giờ, hay chỉ là một bản tóm tắt ngắn?”
- Hỏi không khiến bạn trông ngốc nghếch; nguy hiểm hơn là không hỏi rồi làm hoàn toàn sai việc
- Thay vì mất thời gian diễn giải email hay tin nhắn của lãnh đạo như giải mã cổ vật, tốt hơn là xác nhận trực tiếp với chính người đã đưa ra yêu cầu
- Nếu lãnh đạo có thời gian để đưa ra yêu cầu, thì họ cũng có thời gian để làm rõ yêu cầu đó
1 bình luận
Các ý kiến trên Hacker News
Điều tôi ghét nhất là khi một lãnh đạo phi kỹ thuật bỏ qua một, hai cấp và nói chuyện trực tiếp với nhân sự kỹ thuật junior, thay vì với nhân sự kỹ thuật senior có kinh nghiệm đặt câu hỏi làm rõ hoặc xác định lịch trình/sản phẩm bàn giao.
Đây là mẫu hình tôi thường thấy ở nhiều tổ chức vận động tranh cử hoặc tổ chức công nghệ chính trị.
Nhân sự kỹ thuật junior cũng hiểu chuỗi chỉ huy, nên dù cấp trên có chủ ý hay không, việc phá vỡ nó sẽ gây nhầm lẫn và hỗn loạn.
Người làm công việc thực tế thường là kỹ sư junior, và họ có thể trả lời một số câu hỏi cụ thể tốt hơn người nhìn ở cấp cao hơn.
Tôi nghĩ không nhất thiết phải chơi trò truyền lời.
Khi một điều phối viên dự án của nhà cung cấp thiếu kinh nghiệm, một kỹ thuật viên phía nhà cung cấp đã quen để điều phối viên xử lý công việc, và một khách hàng mới bước vào lĩnh vực này gặp nhau, có thể xảy ra khá nhiều hỗn loạn.
Về các câu “nếu không hỏi gì rồi làm một việc hoàn toàn sai thì chắc chắn sẽ trông rất ngốc” và “đừng bao giờ mặc định rằng người kia quá bận để trả lời câu hỏi làm rõ trong lúc làm việc”, tôi tự hỏi nên làm thế nào trong tình huống làm việc từ xa và thậm chí không có chat online.
Nếu gặp trực tiếp, rất dễ đặt nhiều câu hỏi nhỏ, nhanh, được sắp xếp sơ bộ; còn email thì cảm giác trang trọng và gây phiền hơn, nên phải mất thêm thời gian để giải thích mình đang bối rối ở đâu và chặn trước cả các câu trả lời dự kiến.
Cuộc gọi video thì mất thời gian sắp xếp và chi phí phụ cũng lớn.
Trong các dự án khách hàng, mỗi khi nảy sinh câu hỏi nhỏ, tôi thêm vào Google Doc, rồi thỉnh thoảng nhắc khách hàng xem tài liệu hoặc để khách hàng đăng ký nhận thông báo chỉnh sửa.
Khách hàng viết câu trả lời trực tiếp vào tài liệu, và quá trình này lặp lại khi công việc tiến triển.
Ưu điểm là khách hàng không cần trả lời tất cả cùng một lúc, số thông báo giảm đi, cả hai bên có thể viết ít trang trọng hơn, tạo cảm giác cộng tác, dễ gắn câu hỏi tiếp theo bên cạnh phần liên quan, cũng có thể thảo luận ngắn hoặc giao/theo dõi các việc nhỏ bằng bình luận trong tài liệu, và người khác cũng dễ đọc và đóng góp.
Ở đây tôi đang nghĩ tới các tình huống phát sinh nhiều câu hỏi nhỏ, chẳng hạn công việc theo hợp đồng với khách hàng phi kỹ thuật mà mình chưa hiểu rõ.
Người khác không áp các ràng buộc như vậy lên email.
Nếu không phải gửi cho CEO, cứ viết câu hỏi khi nghĩ ra và gửi ngay cũng được.
Cũng không cần sợ gửi ngay email thứ hai kiểu “À, tôi quên mất câu hỏi này nữa. Cảm ơn! $QUESTION”.
Nhìn email của các lãnh đạo cấp cao tại https://twitter.com/TechEmails thì phần lớn đều rất không trang trọng.
Một số email cũ giữa Bill Gates và các lãnh đạo Microsoft thậm chí cũng không chỉn chu hơn tin nhắn của học sinh cấp ba là mấy.
Tôi không có ý nói bạn nên thêm emoji khi gửi cho sếp của sếp của sếp của sếp, nhưng email nhanh, không quá trang trọng sẽ không chấm dứt sự nghiệp của bạn.
Tôi hiểu là với nhiều người nó có cảm giác nặng nề hơn, nhưng không rõ liệu trên thực tế nó có phiền hơn cho cả hai bên hay không.
Nếu cần đối thoại qua lại để làm rõ câu hỏi thì cứ làm vậy.
Cách dùng tài liệu chia sẻ cũng là một ý hay, và còn có thêm hai lợi ích.
Việc viết ra trở thành một bước bổ sung giúp câu hỏi rõ hơn, và câu hỏi cùng câu trả lời được ghi lại để dùng về sau.
Cả hai đều là lợi ích lớn so với một cuộc trao đổi nhanh mà sau này phải viết lại.
Hãy chuyển gánh nặng nhận thức sang cho đối phương.
Vì làm phiền một lần vẫn tốt hơn làm phiền nhiều lần trong ngày.
Khi nhận một issue mới, tôi sẽ đọc lướt trước, lên kế hoạch xem phải làm gì, đào sâu trong đầu các vấn đề hoặc xung đột tiềm ẩn, đôi khi tạo ra một danh sách câu hỏi khổng lồ, rồi phân loại xem ai có khả năng trả lời câu hỏi nào, sau đó mới bắt đầu trao đổi online.
Trong nội bộ công ty, thường chỉ cần dùng messenger nội bộ như Slack để đề nghị một cuộc gọi video ngắn 5 phút.
Với đồng nghiệp làm việc gần gũi, đôi khi tôi cũng gọi ngay mà không báo trước.
Với khách hàng bên ngoài, nếu đã thống nhất trước, cũng có thể làm tương tự bằng số điện thoại thật hoặc cuộc gọi video.
Ví dụ, trong buổi họp kickoff, có thể xác định tần suất liên hệ mà khách hàng mong muốn, câu hỏi nào cần trao đổi ngay, và câu hỏi nào chỉ cần giao tiếp bất đồng bộ chậm hơn.
Thời gian là một chỉ số đại diện rất tệ cho nỗ lực, thực chất và phạm vi
Ví dụ, với yêu cầu kiểu “chỉ xem qua 20 phút rồi sau 20 phút mang những gì có được đến”, lượng việc mỗi người đạt được trong 20 phút sẽ hơi khác nhau
Ngay cả khi bỏ qua khác biệt đó, cũng không có gì bảo đảm rằng người quản lý đưa ra yêu cầu sẽ nhận được thứ họ cần từ 20 phút nỗ lực ấy
Trong môi trường Agile, tôi thường thấy công việc khám phá/điều tra được gọi là “spike” và được đặt “timebox”, nhưng khi hỏi “nếu không tìm ra thứ mong muốn trong khoảng thời gian đó thì sao?” thì thường không có câu trả lời hay
Trên thực tế, timebox sẽ được kéo dài cho đến khi tìm ra thứ cần thiết
Vì vậy thời gian là một chỉ số thay thế tệ cho nỗ lực, thực chất hay phạm vi
Tôi nghĩ ví dụ ở phần sau của bài, “Bạn mong một bản rất kỹ lưỡng mất nhiều giờ, hay chỉ cần một bản tóm tắt nhanh?” là tốt hơn
Vì câu đó nói về phạm vi công việc, chứ không phải thời gian cần mất
Nếu đo bằng thời gian thì không có gì bảo đảm sẽ nhận được thứ mong muốn trong khoảng thời gian đó, và cuối cùng lại phải cộng thêm thời gian
Câu trả lời cho “nếu không tìm ra thứ mong muốn trong khoảng thời gian đó thì sao?” là: ta biết được rằng không thể tìm ra câu trả lời trong thời gian đã dự kiến, và điều chỉnh kỳ vọng về nỗ lực cần cho công việc điều tra này
Với tư cách người quản lý, chính thông tin đó là một trong những thông tin cốt lõi muốn biết
Vì vậy, để ngăn dự án trật đường ray rồi đi vào sọt rác, bất cứ việc gì cũng cần timebox
Điều này cũng áp dụng cho công việc cá nhân hoặc việc làm một mình
Vì có thể bám lấy bất cứ thứ gì mãi mãi, nên tốt hơn nhiều là ép tạo ra một điểm dừng, nhận phản hồi hoặc phát hành rồi quyết định xem có đáng tiếp tục hay không
Cơ chế vận hành ở đây là buộc mọi người phải đặt ưu tiên
Nếu phán đoán ưu tiên rất tốt thì có thể ít cần timebox hơn, nhưng ngay cả khi đó, nếu không có timebox thì có thể khó cưỡng lại cám dỗ tiếp tục làm đến mức chất lượng cao hơn mức cần thiết
Mẫu làm việc này hữu ích khi những điều chưa biết nhiều hơn rất nhiều so với những điều đã biết
Mục tiêu là từng chút một tăng tỷ trọng “điều đã biết” đủ để đưa ra phỏng đoán dựa trên thông tin, chứ không phải phỏng đoán mò
Ví dụ, nếu trong một codebase kế thừa có lỗi, còn hệ thống thay thế thì gần như đã hoàn tất và dự kiến ra mắt sau hai tháng, ta sẽ xử lý lỗi đó thế nào
Có thể phớt lờ, hoặc bảo ai đó “sửa bằng mọi giá”, nhưng cả hai đều không tốt
Vì vậy ta nói “hãy điều tra lỗi này nhưng đừng quá một giờ, rồi cho tôi biết đã đi đến đâu”
Sau khi kết thúc, ta sẽ hiểu rõ hơn hình dạng của vấn đề
Nếu họ quay lại và nói “đã tìm được khu vực vấn đề, nhưng phải giải cùng người hiểu rõ business logic thì mới sửa được”, thì có thể gắn nguồn lực phù hợp và tiếp tục sửa
Nếu họ nói “nằm ở phần này của code và đã được dọn khá ổn, nhưng vẫn chưa truy vết hoàn toàn”, thì dựa trên niềm tin rằng đây sẽ không phải việc khổng lồ, có thể cho thêm thời gian
Ngược lại, nếu họ nói “nó ở đâu đó trong đống spaghetti kỳ quái này, và khi nhìn vào thì vực thẳm nhìn ngược lại tôi khiến sống lưng lạnh toát, còn tranh trên tường thì khóc ra máu, nên xin đừng bắt tôi quay lại đó nữa”, thì rõ ràng là không đáng truy vết thêm và có thể bỏ qua
Tôi tin là bạn đã từng trải nghiệm việc không nhận được thứ mong muốn trong thời gian đó rồi phải cộng thêm thời gian, nhưng điều đó không phổ quát
Vấn đề nằm ở chỗ coi chính “thứ mong muốn” là mục tiêu cuối cùng
Vì vậy bài viết cũng nói “hãy nói vì sao cần nó”
“Khách hàng lớn nhất cần biết trước khi gia hạn hợp đồng” đáng để chi nhiều tiền và nhiều thời gian nhân sự hơn so với “chỉ tò mò thôi”
Ở cấp lãnh đạo, cần nhận ra rằng không thể theo đuổi mọi lợi ích, và phải tập trung một cách chiến lược vào những việc có hiệu quả so với chi phí tốt nhất
Không chỉ đơn giản là gán người vào việc, mà còn bao gồm việc phân công đúng việc cho người có kỹ năng phù hợp
CEO của một startup đã yêu cầu điều gì đó, và yêu cầu có vẻ chỉ ngắn khoảng một hai câu
Kết quả là tôi đã làm một báo cáo 14 trang, mất vài giờ, phần lớn làm trong thời gian cá nhân
Tôi gửi báo cáo cho CEO nhưng sau đó không nhận được phản hồi nào, và cũng chẳng có chuyện gì xảy ra
Sau đó tôi tự đặt ra một quy tắc mới
Chi phí của một yêu cầu phải tỷ lệ với chi phí truyền đạt yêu cầu đó
Giờ nếu nhận một yêu cầu có chi phí lớn, tôi sẽ chờ, trì hoãn và yêu cầu escalation
Người đưa ra yêu cầu phải thực hiện thẩm định và nhận phê duyệt từ cấp cao hơn để cho thấy yêu cầu đó đáng trả chi phí
Nếu là yêu cầu vớ vẩn thì sẽ không bao giờ nghe lại nữa; nếu là yêu cầu có giá trị thì sẽ xử lý, và còn có lợi ích phụ là nỗ lực đó sẽ không âm thầm diễn ra mà không có mức độ hiển thị phù hợp
Thứ nhất, tuyệt đối không làm gì với yêu cầu đầu tiên
Nếu quan trọng thì họ sẽ yêu cầu lại, khi đó mới nghĩ
Thứ hai, nếu tôi phải làm thêm giờ thì đối phương cũng phải làm thêm giờ
Nếu đối phương không muốn làm thêm giờ thì nghĩa là việc đó không quan trọng đến mức ấy
Sau nhiều năm trải qua nhiều cấp bậc trong lĩnh vực kỹ thuật, từ junior đến C-level, tôi đã học được vài điều
Thứ nhất, mọi người đều phải hành động với thiện chí
Tôi từng thấy lãnh đạo không suy nghĩ nổi 5 giây, bộc phát yêu cầu cấp dưới trực tiếp làm việc gì đó; ngược lại cũng từng thấy cấp dưới trực tiếp chỉ chịu di chuyển khi được đưa cú pháp chính xác như “dòng lệnh con người”
Cả hai đều không ổn
Thứ hai, với quản lý hay lãnh đạo, không có “yêu cầu một lần”
Bất kỳ yêu cầu nào cũng mặc nhiên có mức ưu tiên cao hơn mọi việc khác
Bạn phải vận hành trong toàn bộ hệ thống và bối cảnh; nếu không, tức là đang đẩy lựa chọn đó cho cả đội
Thứ ba, nếu là bên nhận yêu cầu, bạn cần giúp người yêu cầu hiểu họ thật sự cần gì
Phải loại bỏ các giả định ngầm, vì rồng thường ẩn ngay ở đó
Cần giao tiếp, thông báo, hướng dẫn, xác nhận điều người yêu cầu muốn và bảo đảm hai bên đã đồng thuận
Những chuyện này thường phát sinh từ mong muốn hiệu quả, không muốn lãng phí thời gian nếu không cần thiết; nhưng nếu người yêu cầu và người nhận yêu cầu cố gắng giúp nhau, cuộc sống nhìn chung sẽ dễ chịu hơn nhiều
Có sự khác biệt rất rõ giữa một lãnh đạo luôn đẩy giới hạn xem có thể đi xa đến đâu và một lãnh đạo muốn xây dựng quan hệ thiện chí với đội
Một quản lý liên tục đưa ra các yêu cầu thiếu suy nghĩ sẽ đều đặn mất những nhân viên giỏi nhất
Theo kinh nghiệm của tôi, sau đủ lâu, dưới quyền kiểu lãnh đạo này chỉ còn junior, vì những người có kinh nghiệm sẽ tránh đội đó
Thành viên kiểu “dòng lệnh con người” cũng là một ví dụ điển hình về hành xử với ác ý
Tôi từng làm việc với những người yêu cầu rằng ngay cả một yêu cầu rất nhỏ cũng phải điền biểu mẫu hoặc tài liệu do họ tạo ra rồi mới có thể bắt đầu, rồi mất vài ngày tranh luận, phê bình hoặc chuyển qua chuyển lại trước khi họ nghĩ đến việc nhỏ đó
Họ tưởng mình đã tự bảo vệ khỏi các yêu cầu nhỏ bằng cách khiến không ai muốn bỏ công đặt câu hỏi thật chính xác, nhưng theo thời gian, họ tích lũy danh tiếng là người khó làm việc cùng
Một biến thể khác là người lợi dụng sự mơ hồ của mọi yêu cầu
Dù phần lớn hiểu mình được yêu cầu gì, họ vẫn “dạy cho một bài học” bằng cách đưa ra kết quả đúng theo từng chữ của yêu cầu, nhưng biết rõ đó không phải là thứ mọi người cần hay muốn
Không phải ngẫu nhiên mà phần lớn những người từng chơi trò này đã bị sa thải trong vòng một năm qua
Mọi người có thể chịu đựng một đồng nghiệp tệ nhưng vẫn làm được phần nào công việc trong một thời gian, nhưng khi cắt giảm nhân sự, họ sẽ nằm ở đầu danh sách bị loại
Một tháng trước, với tư cách lãnh đạo, tôi nhận ra thất bại mà mình từng mắc phải
Bề ngoài, ý định là trao quyền sở hữu cho đội, và tôi đổ vào rất nhiều việc cần làm, nhưng thực ra tôi đang đẩy căng thẳng của câu hỏi “ngay lúc này phải làm gì” sang cho đội
Đây là một cái bẫy tinh vi khiến ta dễ nghĩ “mình đang ủy quyền cho đội cực nhiều!”, nhưng thực tế là làm đội căng thẳng và làm giảm khả năng tập trung
Theo OED, cách danh từ hóa này bắt nguồn từ khẩu ngữ Úc
https://www.oed.com/search/dictionary/?q=ask
Ai cũng biết ngôn ngữ là sản phẩm nhận thức sinh-xã hội luôn biến đổi nên không có quy tắc thật sự, nhưng khi đã có những từ đồng nghĩa tốt đang dùng ổn, cách dùng này vẫn gây khó chịu như cảm giác nhai phải cát
Vì tôi không muốn thông tin đó chi phối quyết định
Tôi nghĩ mình nên làm điều tốt nhất cho doanh nghiệp và người dùng cuối, chứ không phải điều dễ nhất với tôi
Nhưng đối phương lại chọn phương án dài hơn và khó hơn; sau này mới biết thật ra họ muốn phương án kia, nhưng nghĩ rằng phương án đó sẽ khó hơn cho tôi
Ngoài đời cũng xảy ra chuyện tương tự
Khi làm tủ bếp mới, tôi đưa cho vợ hai lựa chọn về thanh ray trên cùng của cánh cửa; một lựa chọn khó hơn, nhưng tôi không nói vì muốn cô ấy chọn thứ mình thích
Tất nhiên vợ tôi chọn phương án khó hơn, rồi hóa ra cô ấy nghĩ phương án đó dễ hơn, và thật ra lại thích phương án kia hơn
Vì vậy, hãy luôn cung cấp cho đối phương mọi thông tin
Tại sao không thể nói rằng câu hỏi do ban lãnh đạo đặt ra là vô lý
Câu trả lời dĩ nhiên là vì không muốn đi ngược hệ thống cấp bậc
Nhưng kiểu tuân phục thứ bậc này thực tế không giúp ích cho doanh nghiệp
Nó trông giống một giá trị nên dễ bị vứt bỏ hơn
Câu hỏi “Bạn kỳ vọng một bản thật kỹ, hay chỉ cần tóm tắt nhanh?” khá buồn cười
Nếu kỹ sư nói thật với người không phải kỹ sư rằng một việc sẽ mất bao lâu, người không phải kỹ sư sẽ sốc và nói không được
Yêu cầu “đừng dành quá 20 phút, sau 20 phút có gì thì mang tới” nghe như điên rồ
Không có việc nào mất 20 phút cả
Thà nói “đừng xem cái này, đi uống cà phê rồi quay lại ước tính sơ bộ cho tôi” còn hơn
Chúng ta đang làm công việc phức tạp và cần thời gian để suy nghĩ
Nếu không muốn tốn thời gian suy nghĩ thì tốt nhất là đừng hỏi
Một phần vấn đề nằm ở chỗ bạn không muốn bảo sếp biến đi, cũng không muốn nói rằng mình đã mất 6 tiếng cho thứ mà sếp nghĩ là việc 20 phút
Vì vậy, thay vào đó, mọi việc khác đều bị dồn lại
Đó là lý do quản lý kỹ thuật tốt cố gắng giữ kỹ sư tránh xa nhất có thể khỏi những người vô tình lôi kéo nhân sự kỹ thuật khỏi công việc của họ
Dấu hiệu điển hình của quản lý yếu kém là yêu cầu báo cáo hoặc giao việc mà bản thân họ không hiểu hết toàn bộ hàm ý
Dấu hiệu điển hình của kỹ thuật yếu kém là trả lời “vâng” với yêu cầu đó
Khi một nhà quản lý yếu kém yêu cầu một việc vượt ngoài phạm vi có thể xử lý như chuyện nhỏ, người thực hiện nên làm một trong ba điều, tùy theo bối cảnh kỹ thuật và xã hội
A) Hỏi “Vậy phải làm việc đó như thế nào?”
Cách này hiệu quả khi nhà quản lý cũng là người kỹ thuật nhưng giao việc mơ hồ để bù đắp cho sự kém năng lực kỹ thuật của mình
Khi trả lại nguyên xi mớ lời vô nghĩa đó, họ sẽ phải đối diện với phạm vi của việc mình đang yêu cầu và thực tế về cơ chế thực hiện
B) Nói rõ “Việc đó cần X tài nguyên. Kỳ vọng là gì?”
Ở đây X có thể là rất nhiều giờ công, tiền, GP RuneScape cổ điển, hay bất cứ thứ gì
Phù hợp với nhà quản lý không có nền tảng kỹ thuật, và cũng giống A, buộc họ phải đối diện rằng đây là một yêu cầu lớn cần đi qua quy trình bình thường chứ không phải việc có thể phê duyệt ngay tại chỗ
C) Nói “Không”
Điều này không phải lúc nào cũng khả thi trong mọi tổ chức hay mọi bối cảnh xã hội, nhưng các tổ chức hiệu suất cao biến nó thành khả thi
Trong môi trường kỹ thuật hiệu suất cao, tổ chức kỹ thuật có quyền phủ quyết mạnh với những việc vô nghĩa phi lý, và chỉ cấp C-level ở trên mới có thể lật lại
Biết khi nào và cách dùng quyền phủ quyết này cũng là một kỹ năng quan trọng mà bộ phận kỹ thuật cần phát triển
Vì vậy, bất cứ điều gì bạn nói về việc đó cũng có thể dẫn đến kết quả là tự đẩy mình ra phía cửa
Mỗi lần thấy “ask” được dùng như danh từ là cảm giác ngôn ngữ của tôi lại ngứa ngáy, nên tôi tìm thử và thấy bài này
https://english.stackexchange.com/questions/4246/can-or-shou...
Có thể hữu ích cho những ai cũng thấy khó chịu tương tự
Một trong những thứ lãng phí thời gian nhất là khi yêu cầu thiếu ngữ cảnh
Có vẻ như họ đang cố tiết kiệm thời gian bằng cách chỉ báo cho người cần biết, nhưng “vì sao” và ngữ cảnh thực sự rất quan trọng để đưa ra giải pháp tốt
Không có chúng thì bạn không thể biết người kia đã cân nhắc những gì
Ví dụ, nếu nói “cần chặn các yêu cầu đến từ quốc gia X”, thì với hầu hết dịch vụ tường lửa việc đó không khó
Nhưng vì sao phải làm vậy?
Nếu mục tiêu là đưa ra bảo đảm theo hợp đồng rằng không có lưu lượng truy cập phát sinh từ một quốc gia cụ thể, thì cách đó không hiệu quả, vì bất kỳ ai cũng có thể dùng VPN để vượt qua phát hiện mã quốc gia trong 2 phút
Người dùng muốn làm X nhưng không biết cách, nghĩ rằng Y sẽ hiệu quả nên yêu cầu trợ giúp về Y, còn những người khác thì bối rối vì Y trông có vẻ kỳ lạ
https://xyproblem.info/
Đã có rất nhiều người ngã xuống trên ngọn đồi đó, nhưng cuối cùng nó vẫn được triển khai
Tốt nhất là đừng trở thành một nạn nhân nữa
Rốt cuộc, điều này phụ thuộc rất nhiều vào văn hóa công ty và mức độ mọi người cảm thấy thoải mái khi phản biện các lãnh đạo cấp cao
Gánh nặng nằm ở các lãnh đạo cấp cao, những người phải tạo điều kiện để cấp dưới cảm thấy thoải mái khi phản biện
Theo kinh nghiệm của tôi, những lãnh đạo tốt nhất thường khiêm tốn và có thái độ sẵn sàng lắng nghe
Tuy vậy, đôi khi làm những việc vô ích cũng là một phần của công việc
Nếu quá nhiều thì dĩ nhiên bạn có thể tìm việc khác, nhưng tốt hơn là đừng trở thành người lúc nào cũng nghi ngờ và chất vấn ban lãnh đạo