Khi nào / tại sao việc cầu xin tha thứ lại dễ dàng hơn là xin phép? [đóng cửa]

Câu nói "Dễ dàng cầu xin sự tha thứ hơn là xin phép" có vẻ khá phổ biến đối với các lập trình viên và IIRC được quy cho Grace Hopper. Trong những tình huống này điều này thường đúng, và tại sao bạn tin rằng một đề xuất phản trực giác như vậy sẽ được tổ chức?

Tôi nghĩ rằng một lý do quan trọng là trách nhiệm. Bằng cách xin phép, bạn đang chuyển giao trách nhiệm cho người bạn đang hỏi, vì vậy người đó có thể có khuynh hướng từ chối chỉ để tránh phải chịu trách nhiệm về kết quả, trong trường hợp thất bại.

Mặt khác, một khi nó được thực hiện, đó không còn là vấn đề nữa. Ngay cả khi kết quả là một thất bại, đó vẫn là trách nhiệm của bạn, bất kể bạn có nhận được sự tha thứ hay không.

Bởi vì một khi một cái gì đó được thực hiện, miễn là nó không làm mọi thứ tồi tệ hơn, thì thường dễ dàng bỏ nó hơn là lấy nó ra (tức là "những gì đã làm xong.")

Đó là chính trị, tất cả chính trị.

Đôi khi tôi thấy điều này trở thành hiện thực, khi ban quản lý hoặc khách hàng đưa ra quá nhiều rào cản đối với những thay đổi đơn giản (ví dụ: đánh giá "chất lượng" của những người không biết gì về hệ thống, cần phải đăng nhập từ quá nhiều lĩnh vực kinh doanh) Đôi khi nhanh hơn và dễ dàng hơn để "xé băng": đừng nói với quá nhiều người, chỉ cần thực hiện thay đổi và nếu nó hoạt động, mọi người đều vui, bạn có thể bị tát vào cổ tay vì "không tuân theo quy trình" v.v.

Tất nhiên, nếu thay đổi thất bại, bạn có thể tìm thấy nhiều quy trình hơn nữa được đưa vào ... nhưng đó là rủi ro bạn đã mắc phải.

(từ chối trách nhiệm: Tôi không gặp vấn đề gì với kiểm soát chất lượng và kiểm tra và cân bằng - miễn là chúng hợp lý)

Tôi nghĩ nó phức tạp hơn nhiều so với bạn nghĩ. Dưới đây là hai quan điểm của tôi về vấn đề:

Hỏi chi phí không có gì

Tôi luôn luôn tuyệt vời khi nghe thảo luận về việc tăng lương. Người dân phàn nàn họ không tăng. Nhưng nếu họ không hỏi (trừ khi họ ở trong chính quyền tự động và tăng lương được xác định trước), họ sẽ không nhận được gì khi chỉ chờ đợi.

Nó giống với chiếc xe của người hàng xóm mà bạn muốn mượn ... Bạn có thể nghĩ "anh ấy sẽ nghĩ tôi ....." hoặc "Cô ấy sẽ không chấp nhận vì ....." hoặc "Anh ấy sẽ dù sao cũng có thể cần nó .... ".

Sự thật là bạn không biết cho đến khi bạn hỏi. Tuy nhiên, cách mà bộ não của chúng ta hoạt động sẽ lấp đầy tâm trí của chúng ta với những suy nghĩ không ích lợi mà bạn tự tạo ra. Trong hầu hết các trường hợp, họ là sai.

Vì vậy, yêu cầu có thể là điều đầu tiên để thử.

Làm điều đó thay vì yêu cầu sẽ ngăn bạn từ chối. Nếu bạn thất bại, bạn có thể xin lỗi

Tuyên bố này cũng đúng bởi vì trong doanh nghiệp nơi khả năng đáp ứng được xác định rõ ràng và nơi mọi người được đánh giá dựa trên thành tích cá nhân của họ.

Nếu bạn yêu cầu trách nhiệm của bộ phận khác về điều gì đó có thể (nghĩ rằng anh ta tạo ra) ảnh hưởng tiêu cực đến anh ta, nhưng kết quả (nếu tích cực), sẽ không ảnh hưởng đến anh ta, anh ta chắc chắn sẽ từ chối, để an toàn.

Hai câu trả lời rất giống nhau: sợ hãi. Trong câu trả lời đầu tiên, đó là nỗi sợ CỦA BẠN, thứ hai là nỗi sợ THEM.

Để vượt qua nỗi sợ hãi của người khác, đừng hỏi. Trong nhiều trường hợp, bạn sẽ thành công, và trong trường hợp thất bại, thì có ... xin lỗi sẽ là đủ.

Không phải trong hầu hết các trường hợp không may, nhưng đó là một rủi ro BẠN PHẢI thực hiện để thăng tiến trong cả cuộc sống và sự nghiệp của bạn.

Trong một tổ chức phân cấp, quản lý cấp trên thường không có manh mối về vấn đề bạn đang làm việc; sau đó, các quyết định của họ chắc chắn sẽ dựa trên cách bạn thể hiện các đề xuất của bạn cho họ. Đại diện cho các ý tưởng kỹ thuật cho những người phi kỹ thuật nổi tiếng là khó: nếu bạn giải thích nó như vậy, họ sẽ không hiểu bất cứ điều gì và có thể từ chối chỉ vì điều đó. Và nếu bạn giải thích nó để họ hiểu, bạn sẽ không nói rõ điều đó. Có phải là đạo đức không? Vì vậy, tốt nhất là chỉ nên làm điều đúng thay vì cố gắng giải thích rằng theo cách hoa mỹ và sai lầm như vậy mà ban quản lý đồng ý với nó.

Nó không vô trách nhiệm. Ngay cả khi bạn đã xin phép, kết quả sẽ phụ thuộc rất nhiều vào cách bạn thể hiện vấn đề của mình. Vì bạn có thể ảnh hưởng đến quyết định theo cách này, tại sao phải bận tâm? Chỉ cần làm điều đó và vít quan liêu. Ít nhất thì bạn không nói dối. Điểm mấu chốt là bạn biết đó là điều đúng đắn .

Tất nhiên, bạn phải khá chắc chắn rằng bạn đúng, vì bây giờ bạn là người chấp nhận rủi ro. Những gì bạn đang tiết kiệm là thời gian và công sức của bạn và quản lý; không phải là một kỳ công nhỏ

Khi bạn xin phép, người bạn đang hỏi phải tưởng tượng hậu quả mà COULD xảy ra nếu bạn được phép làm điều đó. Điều này có thể bao gồm những điều khủng khiếp như công ty sắp phá sản. Một người không thích rủi ro (hoặc một người có trí tưởng tượng lằng nhằng) sẽ cho bạn biết không. Họ có thể không bị ảnh hưởng bởi lợi ích có thể có trong kế hoạch của bạn. Khi bạn chỉ tiếp tục và làm điều đó mà không yêu cầu, nếu bạn nhận được lợi ích thì bạn không có khả năng bị trừng phạt hoặc khiển trách. Nếu bạn nhận một hậu quả nhỏ, bạn sẽ nhận một hình phạt nhỏ. Tất nhiên, nếu bạn phá sản nhà tuyển dụng, tất cả đã kết thúc.

Tôi không thể thuê một người nào đó cần kiểm tra với tôi trên mỗi email, mọi dòng mã, liên tục muốn được phép thực hiện công việc thường xuyên của họ. Nhưng ai đó nghĩ rằng chấp nhận rủi ro cho toàn bộ công ty về một canh bạc lố bịch (một công ty không phải là rủi ro của họ, vì tôi sở hữu nó không phải họ) sẽ không làm việc cho tôi ngay cả khi đánh bạc đã được đền đáp. Bạn cần phải ở trong một tổ chức bỏ túi khá lớn và sâu (ví dụ như quân đội Hoa Kỳ) để có thái độ này - và bạn cần hiểu rất rõ những rủi ro.

Những gì tôi đã trải nghiệm đôi khi thật khó để đưa ra một lập luận để thực hiện một số thay đổi nhất định trong quy trình làm việc hoặc công cụ của bạn. Miễn là quy trình và công cụ hiện tại hoạt động, có thể không có động lực mạnh mẽ nào cho bất kỳ người quản lý (hoặc đồng nghiệp) nào đi và có nguy cơ thử một thứ gì đó mới mà a) có thể không tốt hơn hoặc b) có thể thất bại.

Có thời gian và tài nguyên đi vào đó, mọi người có thể phải thích nghi, v.v. Nếu bạn đi thẳng và yêu cầu thay đổi, bạn có thể gặp một số sự miễn cưỡng và sẽ phải đưa ra những lập luận mạnh mẽ. Có thể có rất nhiều lý do để người quản lý không muốn thay đổi và điều đó không nhất thiết là vì họ lười biếng hoặc không kịp thay đổi. Nhưng bạn đang yêu cầu một quyết định dứt khoát hoặc "Đi!" mà thực sự đặt trách nhiệm lên người quản lý của bạn.

Nếu bạn chỉ thực hiện thay đổi và lẻn vào nơi làm việc của bạn tại thời điểm mà sự thay đổi trở nên rõ ràng đối với những người ra quyết định, bạn có thể đã chứng minh rằng:

a) Nó có thể được thực hiện.
b) Nó hoạt động.
c) Nó cải thiện công việc của bạn.
d) Nó không thực sự chiếm nhiều tài nguyên.

... và cứ thế.

Nếu thất bại, có thể có một số hậu quả, nhưng trừ khi bạn làm việc với một ông chủ nhảm nhí, những điều này có thể không đi sau một số cú tát cổ tay và một số lý do khiêm tốn đến từ bạn.

Chúng tôi đã làm điều đó một lần khi chúng tôi cố gắng lẻn vào một hệ thống theo dõi lỗi khác đằng sau lưng của CTO. Một người tại chỗ bị ghét bởi niềm đam mê bởi đơn giản là tất cả mọi người trong nhóm nhà phát triển (nhưng nó đã được đánh giá - không phải bởi bất kỳ nhà phát triển nào - và được trả tiền, vì vậy chúng tôi dự kiến ​​sẽ sử dụng nó) và chúng tôi còn một số giấy phép cho một người khác .

Đáng buồn thay, trường hợp này yêu cầu sự tha thứ thay vì sự cho phép thất bại. Chúng tôi được yêu cầu quay lại hệ thống cũ. Tôi không biết nếu ai đó thực sự phải trả lời CTO.

Về cơ bản, yêu cầu CTO thay đổi hệ thống theo dõi lỗi và xin phép: Không có cơ hội.

Mặt khác, bắt đầu sử dụng nó (không có chi phí nào khác ngoài thời gian dành cho việc thiết lập nó) và sau đó xem liệu chúng tôi có thể có được sự cho phép SAU thực tế: Không phải là một cơ hội béo, nhưng cao hơn đáng kể so với không.

Có vẻ như tôi đã nghe / đọc rằng tuyên bố có trước Đô đốc Hopper, nhưng tôi không nhớ chi tiết. Tôi nghi ngờ nguồn gốc bị mất theo thời gian.

Dù sao, điều đầu tiên tôi nhớ là đã nghe "xin lỗi dễ dàng hơn xin phép" là tại một cuộc nói chuyện mà người phụ nữ tuyệt vời đã đưa ra khi một trường đại học gần đó mở một trung tâm máy tính mới vào năm 1985. Lời giải thích của cô ấy là những lời ngưỡng mộ mà cô ấy đã báo cáo. Tôi thường hiểu những gì cô ấy đã cố gắng thực hiện. Câu trả lời mặc định của họ cho bất cứ điều gì họ không hiểu là "Không". Tuy nhiên, họ gần như luôn hài lòng với kết quả nếu cô bỏ qua câu trả lời của họ. Vì vậy, cô nhanh chóng nhận ra rằng việc tiến hành mà không cần xin phép sẽ dễ dàng hơn; nếu bất cứ ai buồn, cô ấy chỉ có thể nói rằng cô ấy xin lỗi.

Nanosecond của tôi là một món quà lưu niệm ấp ủ cho đến khi nó bị mất trong một vài năm trước. :-(

Tại sao bạn tin rằng một đề xuất phản trực giác như vậy sẽ giữ

Đó là một quan điểm ủng hộ việc chấp nhận rủi ro. Theo quan điểm đó, nếu bạn không chấp nhận rủi ro, bạn sẽ không thử nước và bạn sẽ không đạt được tiềm năng tối đa của mình.

Nếu bạn đồng ý rằng bạn học được từ những sai lầm của mình, thì bạn có thể đồng ý với câu ngạn ngữ này. Bạn có thể thấy rằng những vết bầm tím của bạn không tệ như bạn tưởng tượng, và khi bạn thành công, bạn thấy mình được khen thưởng quá mức, bởi vì bạn "thể hiện khả năng lãnh đạo".

Mô hình suy nghĩ này làm cho khái niệm trực quan, nếu không phải là thực tiễn.

• http://en.wikipedia.org/wiki/Risk
• http://en.wikipedia.org/wiki/Risk_aversion

Trong tình huống nào thì điều này thường đúng

Thái độ này có giá trị nhất đối với một người đang ở trong một tình huống công việc mới, nhưng có một hồ sơ theo dõi được thiết lập (giả sử quản lý có thẩm quyền). Đây là khi những sai lầm thường sẽ được tha thứ (giả sử ý thức tốt, ý định và lý do), và tiến bộ sẽ được đền đáp cao nhất.