Bài viết được dịch từ Quá trình bình thường hóa của sự lệch lạc (2015)

Có bao giờ bạn đề cập đến một chuyện hết sức bình thường đối với bạn nhưng khiến mọi người ngạc nhiên chưa? Tôi hay bị như vậy khi có những chuyện đồng nghiệp nào của tôi cũng nghĩ đó là bình thường. Vì lý do nào đó, khuôn mặt của người đang nói chuyện với tôi đang cười chuyển dần sang kinh ngạc. Dưới đây là một vài ví dụ tiêu biểu.

Có một công ty mà tôi nghĩ là nơi tốt nhất mình từng làm việc, kết hợp giữa Valve và Netflix. Mọi người rất tuyệt vời và bạn được tự do làm những điều mình muốn. Nhưng nó cũng gây ra tác dụng phụ, họ mất khoản một nửa nhân viên mới trong năm đầu tiên, một số tự nguyện và một số thì không. Hoàn toàn bình thường, nhỉ? Dưới đây là một số giai thoại được những người ở những nơi tôi từng làm việc coi là hoàn toàn bình thường. Và đa số không chỉ bình thường mà còn đáng để nói tới.

Có một công ty cực kì bảo mật về hệ thống. Điển hình là có một team nọ, nếu họ thông báo lỗi đến nhà sản xuất phần cứng, các lỗi đó sẽ được vá và những đối thủ cạnh tranh cũng sẽ sử dụng những bản vá lỗi đó. Giải pháp: họ yêu cầu mã nguồn của phần cứng và tự sửa những lỗi đó! Gần đây, tôi biết có một nhóm ở ngoài công ty đang cố để thực hiện lại thuật toán trong bài báo khoa học mà công ty xuất bản đầu năm nay. Nhóm đó phát hiện rằng họ không thể thu được kết quả và thuật toán trong bài báo là sai; khi được hỏi về điều này, tác giả giải thích rằng “chúng tôi đã có một vài sửa đổi trong bài báo” và từ chối chia sẻ những sửa đổi đó. Công ty đã cố tình công bố một kết quả không thể thực thi lại để tránh cho đi những chi tiết đáng giá, được coi là bình thường (tiêu chuẩn). Công ty đảm bảo an toàn thông tin bằng quy định về việc xa thải những ai làm lộ ra ngoài. Chúng được giới thiệu trong các buổi họp (định hướng) nêu tên những ai bị đuổi (ví dụ người làm lộ thông tin nơi tổ chức buổi hòa nhạc), và thông báo sa thải tại các buổi họp toàn công ty. Kết quả của những chính sách đó là tôi biết nhiều người ngại chuyển tiếp email về những thứ như thông tin cập nhật về bảo hiểm y tế cho vợ/chồng vì sợ gửi nhầm email và bị sa thải; thay vào đó, họ sử dụng một máy tính khác để nhập lại email và chuyển nó đi hoặc chụp ảnh email trên điện thoại của họ.

Có một công ty tự nhiên một ngày tôi để ý thấy có hai người này không bao giờ ở chung một phòng. Tôi được biết là họ có mối thù hàng thập kỉ, và cũng có những cải thiện - trong nhiều năm họ không thể ở chung một phòng vì người kia có thể nổi nóng mà làm điều đáng tiếc, nhưng chuyện cũng nguội dần khi có lúc bắt gặp cả hai ở cùng khu hay cùng phòng. Họ cũng chẳng phải người xa lạ. Họ là quản lý của hai team duy nhất của công ty.

Có một công ty với văn hóa kì lạ đến mức khi tôi viết một bài về nó, tôi nhận ra tôi không chỉ viết dài hơn những bài khác, mà còn dài hơn tổng số chúng cộng lại (đến giờ đã hơn 100k từ, ngang với một cuốn sách nhỏ). Đây cũng là công ty tôi được biết là rất tuyệt vời, vì, thay vì sử dụng phân tích dữ liệu để đưa ra quyết định, họ sử dụng các mối quan hệ cá nhân, và ý tưởng dùng dữ liệu cũng là một điều bí ẩn; không ai làm vậy cả. Đây cũng là công ty mà bốn điều họ nói với tôi để thuyết phục tôi gia nhập đều là sai, và cuối cùng công việc ở đó tôi đặc biệt không hề muốn làm. Khi tôi vào làm, team của tôi không hề sử dụng quản lý phiên bản (version control). Mặc dù tôi đã thuyết phục được họ điều đó, tôi lại thất bại khi yêu cầu họ chạy kiểm thử (test) trước khi biên dịch chương trình (build) để khỏi phải gặp nhiều lỗi trong ngày. Khi tôi nói nó ảnh hưởng đến năng suất làm việc thì họ bảo không sao vì nó ảnh hưởng tất cả mọi người như nhau. Nếu là có vấn đề thì đó là do mức năng suất của tôi nên tôi không cần quan tâm đén việc nó ảnh hưởng đến cả team vì mọi người ai cũng thấy bình thường.

Có một công ty có nhiều sáng kiến lớn để tuyển dụng nhiều phụ nữ hơn vào các vai trò kỹ thuật, nơi họ vẫn bị từ chối sau khi phỏng vấn vì không đủ trình độ kỹ thuật sau khi được hỏi những câu hỏi như “bạn có kinh nghiệm về thuật toán không hay chỉ code thôi?”. Tôi đã nghĩ rằng lời giới thiệu với đánh giá cao của tôi sẽ ngăn chặn điều đó, nhưng thực tế không phải vậy.

Có một công ty nơi tôi làm dự án có bốn người với ngân sách hàng năm cả trăm triệu đô la và tác động hàng tỷ đô la mỗi năm, nhưng khi được yêu cầu về những thứ giá trị khoảng vài trăm đô phải mất hàng tháng trời để xử lý hoặc bị từ chối.

Bạn có thể thắc mắc phải chăng tôi đã làm việc ở những nơi có tình trạng lộn xộn một cách bất thường hay sao. Đúng vậy, các công ty đó được coi là rất ổn và hai trong số đó được coi là những nơi tốt nhất để làm việc, nhưng cũng có thể những nơi đó được đánh giá quá cao. Nhưng tôi cũng có trải nghiệm tương tự khi nghe những câu chuyện về cách các công ty khác vận hành, thậm chí ở những nơi có tiếng xuất sắc về chuyên môn kỹ thuật, ngoại trừ việc tôi là người cảm thấy sốc còn bạn của tôi cho rằng chuyện của họ là bình thường.

Có những công ty sử dụng @flaky, bao gồm phần lớn các công ty dùng Python mới nổi ở thung lũng Silicon. Nếu bạn không biết nó là gì, thì đây là một thư viện để bạn đánh dấu những kiểm thử (tests) chạy lúc đạt (pass) lúc không (fail). Khi tôi hỏi một số đồng nghiệp về thư viện này, họ đều đoán rằng nó sẽ chạy những kiểm thử nhiều lần và đánh kiểm thử đó không đạt nếu một trong những lần chạy không đạt. Đúng, nhưng không hoàn toàn. Về mặt kĩ thuật thì flaky có thể được dùng như vậy nhưng thực tế nó được dùng để chạy kiểm thử nhiều lần và đánh đạt nếu một trong những lần chạy đạt. Công ty tạo ra flaky là một công ty cung cấp sản phẩm về lưu trữ, và nó được sử dụng rộng rãi bởi các đối thủ cạnh tranh.

Có một công ty nổi tiếng vì có hệ thống vận hành với độ tin cậy hai số 9 trong lần kiểm tra trước của tôi, vì những lý do hoàn toàn có thể dự đoán được từ các quy trình kỹ thuật xuất sắc của họ. Đây là điều không cần phải được công khai vì có nhiều công ty đạt được điều đó. Ở đây tôi không nói về những công ty đang cố gắng trở thành reddit hay twitter thứ hai, vì họ chỉ cần tính ổn định một số 9 là đủ. Tôi đang nói về những công ty bán nền tảng mà các công ty khác dựa vào, nếu dịch vụ của họ có sự cố thì các công ty lệ thuộc sẽ bị liên lụy. Nhiều công ty bán cơ sở hạ tầng chỉ có độ tin cậy ở mức hai số 9.

Theo như tôi biết, điều xảy ra ở nhiều công ty này là họ bắt đầu vào tập trung gần như hoàn toàn vào phát triển sản phẩm. Điều đó hoàn toàn hợp lý, bởi vì các công ty này có giá trị gần như bằng 0 khi chúng được thành lập; họ không bận tâm đến những thứ bảo vệ họ khỏi tổn thất, chẳng hạn như các biện pháp tốt cho vận hành hoặc bảo mật, bởi vì họ không có gì để mất cả (à, ngoại trừ dữ liệu người dùng khi sự cố bảo mật xảy ra là không thể tránh khỏi và nếu bạn nói chuyện với những người làm bảo mật ở những công ty mới nổi này (unicorns) bạn sẽ biết rằng những điều này là có thật).

Kết quả là nó tạo ra một nền văn hóa nơi mà nguồn lực chỉ dồn vào phát triển và bỏ qua các nguy cơ. Văn hóa đó tồn tại ngay cả khi công ty đã phát triển đến định giá tỷ đô, và nắm trong tay thứ gì đó có thể mất. Bất cứ ai gia nhập những công ty này từ Google, Amazon hay có nền tảng vận hành hệ thống bài bản đều bị sốc. Thường thì họ sẽ cố sữa chữa rồi rời đi khi không thể cải thiện gì.

Google có lẽ có các phương pháp vận hành cũng như bảo mật tốt nhất so với bất kỳ công ty công nghệ hiện nay. Thật dễ dàng để nói rằng bạn nên coi trọng chúng như Google đã làm, nhưng chúng ta sẽ tham khảo xem họ đạt được điều đó như thế nào. Nếu nhìn vào mã nguồn của họ, bạn sẽ thấy nhiều dịch vụ khác nhau có tên kết thúc bằng “z”, cũng như một số lượng lớn các biến. Tôi được biết đó là vì ngày xưa có người muốn thêm tính năng giám sát hệ thống (monitoring). Sẽ không thực sự an toàn nếu để google.com/somename xuất ra dữ liệu giám sát, vì vậy họ đã thêm z. google.com/somenamez. Để bảo mật. Tại công ty hiện có bảo mật tốt nhất thế giới. Bây giờ họ bảo mật tốt đến mức nhiều người mà tôi đã nói chuyện (đều vào công ty sau này) kịch liệt phủ nhận nó, mặc dù lý do họ đưa ra không thực sự hợp lý lắm (như là để tránh trùng tên) và tôi có thông tin này từ những người làm việc tại thời điểm đó.

Google đi từ việc thêm “z” vào tên các dịch vụ, trở thành công ty có bảo mật hàng đầu không phải vì ai đó có một bài phát biểu hấp dẫn hay một bài viết thuyết phục. Họ trở thành như thế vì bị bẽ mặt vài lần, điều đó là đòn bẩy cho những người muốn làm mọi việc “chuẩn chỉnh” sữa chữa lại những quy trình căn bản. Mọi công ty có phương pháp vận hành tốt mà tôi biết đều trải qua câu chuyện như thế. Microsoft là một trò hề trong khâu bảo mật nhiều năm, cho đến khi số lỗi bảo mật bị khai thác quá lớn buộc họ phải nghiêm túc hơn về nó. Điều này nghe có vẻ đơn giản, nhưng nếu bạn nói chuyện với những người liên quan, sự thay đổi thật tàn khốc. Bất chấp yêu cầu từ cấp trên, vẫn có sự phản kháng mạnh mẽ từ những người đưa công ty đạt được vị thế của năm 2003 không muốn lãng phí thời gian vào vấn đề bảo mật. Tại sao phải thay đổi những gì đang hoạt động?

Bạn có thể thấy điều này trong mọi ngành công nghiệp. Một ví dụ kinh điển mà dân công nghệ thường nhắc đến là việc rửa tay của các bác sĩ, y tá. Ai cũng biết rằng vi trùng có tồn tại và việc rửa tay đúng cách sẽ làm giảm đáng kể tỷ lệ lây truyền chúng và do đó làm giảm đáng kể tỷ lệ tử vong trong bệnh viện. Mặc dù vậy, các bác sĩ và y tá đã qua đào tạo vẫn thường không làm điều đó. Nhiều biện pháp được áp dụng. Biển báo nhắc nhở mọi người rửa tay sẽ cứu được mạng sống. Nhưng nếu có người đứng ở chỗ rửa tay yêu cầu những người đi ngang qua rửa tay thì thậm chí còn có nhiều mạng sống được cứu hơn. Mọi người có thể bỏ qua các biển báo, nhưng họ không thể bỏ qua việc bị buộc phải rửa tay.

Điều này phản ánh một số nỗ lực của các công ty công nghệ đưa ra các phương pháp vận hành tốt hơn. Nếu bạn nói với mọi người rằng họ nên làm như thế này, điều đó sẽ giúp ích được phần nào. Nhưng nếu bạn yêu cầu áp dụng chúng thông qua code review, điều đó sẽ giúp ích rất nhiều.

Dữ liệu cho thấy con người thực sự rất tệ trong việc dành thời gian để làm những việc được hiểu rõ là có thể giảm thiểu nguy cơ xảy ra các thảm họa. Chúng ta sẽ biện hộ rằng đi đường tắt là điều đúng đắn và hợp lý nên làm. Có một thuật ngữ cho vấn đề này: quá trình bình thường hóa của sự lệch lạc. Nó được nghiên cứu kỹ trong một số ngành khác bao gồm chăm sóc sức khỏe, hàng không, kỹ thuật cơ khí, kỹ thuật hàng không vũ trụ và kỹ thuật dân dụng, nhưng chúng tôi không thấy nó được thảo luận trong ngành phần mềm. Trên thực tế, tôi chưa bao giờ thấy thuật ngữ này được sử dụng trong ngành phần mềm.

Có thể học hỏi từ sai lầm của người khác thay vì tự mình mắc phải mọi lỗi lầm không? Với tình trạng của ngành phần mềm thì nghe có vẻ khó xảy ra, nhưng hãy thử xem. John Banja có một báo cáo tóm tắt rất hay về quá trình bình thường hóa của sự lệch lạc trong y tế, với những bài học mà chúng ta có thể áp dụng vào ngành phần mềm. Một điều cần lưu ý là, vì Banja quan tâm đến kết quả của bệnh nhân, nên có sự tương đồng gần gũi với các phương thức thất bại của devops, nhưng quá trình bình thường hóa của sự lệch lạc cũng xảy ra trong nhiều bối cảnh khác nhau.

Phần đầu của báo cáo mô tả chi tiết một số bi kịch, cả trong y tế lẫn ngành khác. Dưới đây là một ví dụ tiêu biểu:

Một trường hợp sơ suất nghiêm trọng mà tác giả tham gia với tư cách là nhân chứng chuyên môn liên quan đến việc bác sĩ gây mê tắt máy thở theo yêu cầu của bác sĩ phẫu thuật muốn chụp X-quang bụng bệnh nhân (Banja, 2005, trang 87-101). Máy thở được chỉ định tắt trong vài giây nhưng bác sĩ gây mê lại quên bật lại hoặc tưởng là đã bật lại. Bệnh nhân không có oxy trong một thời gian đủ dài khiến cô rơi vào trạng thái thiếu oxy toàn cơ thể, khiến cô rơi vào trạng thái thực vật. Cô ấy không bao giờ hồi phục, bị ngắt máy thở nhân tạo sau 9 ngày và qua đời sau 2 ngày tiếp theo. Sau đó, người ta phát hiện ra rằng thiết bị theo dõi và báo động gây mê trong phòng mổ đã được cố tình lập trình ở chế độ “tạm dừng vô thời hạn” để bác sĩ gây mê không được cảnh báo về vấn đề của máy thở. Đáng buồn thay, chính công cụ được sử dụng để ngăn chặn rủi ro như trên đã bị vô hiệu hóa, có thể là do nhân viên phòng phẫu thuật nhận thấy tiếng bíp liên tục gây khó chịu và phiền toái.

Tắt hoặc bỏ qua thông báo vì chúng quá nhiều và gây khó chịu? Một thao tác thủ công bị sai? Những lý do xuất hiện trong các báo cáo sau sự cố (post-mortem: kết quả khám nghiệm tử thi) của nhiều công ty mà tôi có thể nghĩ đến, ngoại trừ kết quả là một cái chết bi thảm thay vì mất mát hàng triệu đô la. Nếu bạn đọc nhiều bài viết về công nghệ, bạn sẽ thấy mọi ví dụ trong báo cáo của Banja đều quen thuộc mặc dù các chi tiết có thể khác nhau.

Phần này kết luận:

Điều mà những thảm họa này thường tiết lộ là các yếu tố gây ra chúng thường có “thời gian ủ bệnh dài, điển hình là do vi phạm quy tắc, nhiều biểu hiện tích tụ mà không được chú ý và sự thừa nhận rủi ro có hệ thống đã cùng nhau ngăn chặn các biện pháp can thiệp giúp phòng tránh những kết quả có hại”. Hơn nữa, điều đặc biệt đáng chú ý là nhiều vi phạm và sai phạm có thể kết hợp lại để tạo điều kiện cho thảm họa xảy ra.

Một lần nữa, đây có thể là từ một báo cáo của các sự cố kĩ thuật. Vì thế trong phần tiếp theo cũng đáng để nghiên cứu về các lý do vì sao chúng lại xảy ra. Các lý do được kể đến là:

Các quy tắc ngớ ngẩn và không hiệu quả

Một ví dụ trong báo cáo là về việc cấp thuốc cho trẻ sơ sinh. Để ngăn chặn tình trạng “thuốc đi lạc”, các y tá được yêu cầu nhập mật khẩu của họ vào máy tính để truy cập ngăn kéo thuốc, lấy thuốc và sử dụng đúng số lượng. Để đảm bảo rằng y tá đầu tiên không lấy trộm thuốc, nếu còn sót lại thuốc, một y tá khác phải quan sát quy trình, sau đó nhập mật khẩu của họ vào máy tính để cho biết họ đã chứng kiến thuốc được lấy đúng liều.

Điều đó nghe thật quen thuộc. Biết bao nhiêu sự cố kỹ thuật bắt đầu với việc “ai đó bỏ qua một số bước vì chúng không hiệu quả”, ví dụ như “lập trình viên đưa thiết lập sai hay đoạn code sai lên server vì họ chắc chắn rằng không có gì sẽ xảy ra và bỏ qua việc kiểm thử”? Sự cố nổi tiếng của Azure (điện toán đám mây của Microsoft) vào tháng 11 năm 2014 xảy ra do vậy. Cũng trong khoảng thời gian đó, một lập trình viên từ một trong số các đối thủ cạnh tranh của Azure bỏ qua quy định không được phép đẩy lên các thiết lập chưa đạt kiểm thử vì họ biết rằng các thiết lập không thể sai được. Nhưng khi quá trình phát hành thử nghiệm (canary deployment) thất bại, họ lại tiếp tục bỏ qua quy định này và phát hành lên môi trường dùng thử (staging environment) vì họ biết rằng thiết lập không thể sai được cho nên sai sót phải đến từ chỗ khác. Báo cáo chỉ ra các thiết lập chính xác về mặt kỹ thuật nhưng nó gián tiếp thực thi phần chương trình bị lỗi; thật may mắn khi lỗi tiềm ẩn mà thiết lập đó gây ra không nghiêm trọng như lỗi của Azure.

Con người rất kém trong việc tính toán mức độ ảnh hưởng, vì vậy chúng ta đưa ra các quy tắc rõ ràng về thời điểm an toàn để phát hành. Nhưng điều tương tự khiến chúng ta khó có thể tính toán đúng thời điểm an toàn để phát hành cũng khiến các quy tắc có vẻ trở nên ngu ngốc và kém hiệu quả.

Kiến thức không hoàn hảo và không đồng đều

Mọi người không tự động biết như thế nào là tiêu chuẩn, và khi có nhân viên mới vào, họ dễ tiếp cận những quy trình lệch lạc đã trở thành tiêu chuẩn.

Julia Evans mô tả cách chúng diễn ra:

Nhân viên mới: CLGT CLGT CLGT CLGT CLGT

Nhân viên cũ: ờ tụi tao cũng có cân nhắc tới nó

Nhân viên mới: CLGT CLGT CLgt clgt clg…

Nhân viên mới thứ 2: CLGT CLGT CLGT CLGT

Nhân viên mới: tao biết rồi. tụi tao cũng có cân nhắc tới nó

Điều thực sự nguy hiểm ở đây là mọi người dễ tin vào cái ý tưởng “CLGT” kia và họ có thể truyền bá nó đi nơi khác trong suốt sự nghiệp của mình. Một lần, sau khi thực hiện một số công việc trong một dự án nguồn mở thường xuyên bị hỏng và được thông báo rằng việc có một bản build bị hỏng là điều bình thường và họ đang làm tốt hơn nhiều người khác, tôi đã đối chiếu các số liệu và nhận thấy rằng về cơ bản thì dự án đó là tệ nhất, và đã đưa ra ý tưởng rằng có thể có một tiến trình build gần như luôn thành công với nỗ lực tương đối thấp. Nhận xét phổ biến nhất mà tôi nhận được là: “Chà, anh chàng đó chắc phải làm việc với những lập trình viên siêu sao. Nhưng hãy thành thực đi. Tất cả chúng ta đều có thể làm cho tiến trình build bị hỏng ít nhất vài lần một tuần”, như thể việc chạy kiểm thử (hoặc thậm chí là biên dịch) trước khi merge code cần phải có siêu năng lực vậy. Nhưng một khi mọi người bị thuyết phục rằng những cái (lệch lạc) đó là bình thường, họ thường thực sự đầu tư vào ý tưởng đó.

Tôi phá bỏ quy tắc vì muốn tốt cho bệnh nhân

Ví dụ trong báo cáo là về một người đã vi phạm quy định phải đeo găng tay khi tìm tĩnh mạch. Lý do của họ là việc đeo găng tay khiến việc tìm tĩnh mạch trở nên khó khăn hơn, điều này có thể dẫn đến việc họ phải dùng kim đâm vào em bé nhiều lần. Thật khó để tranh luận chống lại điều đó. Không ai muốn gây thêm đau đớn cho em bé!

Một sự cố tồi tệ mà tôi có thể nghĩ đến xảy ra khi có người nhận thấy rằng cơ sở dữ liệu đang bị chậm. Họ đã đưa ra bản sửa lỗi để ngăn sự cố lan rộng, họ đã bỏ qua quy tắc rằng bạn nên triển khai chậm rãi và phù hợp theo từng giai đoạn. Thay vào đó, họ đã đưa ra bản sửa lỗi cho tất cả các server. Thật khó để tranh luận chống lại điều đó. Không ai muốn khách hàng của mình có trải nghiệm bị gián đoạn cả! Thật không may, bản sửa lỗi đã gây ra sự cố ngừng hoạt động cả hệ thống.

Các quy tắc không áp dụng cho tôi/Bạn có thể tin tôi

hầu hết mọi người đều tự nhận mình là người tốt và tử tế, đến mức họ có thể hiểu nhiều hành vi vi phạm quy tắc của họ là những phản ứng hoàn toàn hợp lý và có thể chấp nhận được về mặt đạo đức đối với các tình huống nan giải. Họ hiểu rằng mình không làm gì sai, sẽ tức giận và thường bảo vệ mình một cách quyết liệt khi gặp phải bằng chứng ngược lại.

Khi các công ty phát triển, cuối cùng họ phải áp đặt biện pháp bảo mật ngăn cản mọi nhân viên về cơ bản có thể truy cập mọi thứ. Và tại hầu hết các công ty, khi điều đó xảy ra, một số người thực sự khó chịu. “Anh không tin tưởng tôi sao? Nếu bạn tin tưởng tôi, tại sao bạn lại thu hồi quyền truy cập của tôi vào X, Y, Z?”

Facebook từng nổi tiếng vì cho phép tất cả nhân viên truy cập trang cá nhân của người dùng trong một thời gian dài và thậm chí bạn có thể tìm thấy các bình luận trên Hacker News cho biết rằng một số nhà tuyển dụng sẽ đề cập rõ ràng đến điều đó như một đặc quyền khi làm việc cho Facebook. Và tôi có thể nghĩ đến nhiều hơn một công ty, nơi mọi người vẫn có quyền truy cập vào mọi thứ, ngay cả sau một hoặc hai sự cố bảo mật nghiêm trọng. Thật khó để có được quyền lực để hạn chế khả năng tiếp cận của mọi người với những gì họ tin rằng họ cần hoặc có quyền được biết. Rất nhiều công ty khởi nghiệp thời thượng có các giá trị cốt lõi như “niềm tin” và “minh bạch”, điều này gây khó khăn cho việc tranh luận về khả năng tiếp cận tất cả mọi thứ.

Nhân viên ngại lên tiếng

Có những người mà tôi đơn giản là không góp ý cho họ vì tôi không biết liệu họ có chấp nhận điều đó hay không, và một khi bạn đã nói điều gì đó thì không thể rút lại. Trong báo cáo, tác giả đưa ra ví dụ về một bác sĩ có chữ viết kém, tỏ ra ác ý khi mọi người yêu cầu ông làm rõ những gì ông đã viết. Kết quả là mọi người đoán thay vì hỏi.

Trong hầu hết các nền văn hóa công ty, mọi người cảm thấy kỳ lạ khi đưa ra góp ý. Hẳn ai cũng có những câu chuyện về một dự án kéo dài hàng tháng hoặc hàng năm mà lẽ ra nó phải bị chấm dứt nhưng không ai sẵn sàng đưa ra góp ý rõ ràng cả. Đây là một vấn đề ngay cả khi các công ty không khuyến khích ý xấu và khuyến khích mọi người góp ý: những nơi có văn hóa tử tế dường như có nhiều vấn đề xung quanh việc phát biểu ý kiến ngang với các công ty nền văn hóa ác ý, nếu không muốn nói là nhiều hơn. Ở một số nơi, người ta ngại lên tiếng vì sợ sẽ bị ai đó ác ý tấn công. Ở những nơi khác, họ sợ họ sẽ bị coi là hèn hạ. Đó là một vấn đề nan giải.

Cấp trên né tránh hoặc giảm nhẹ tình tiếc của vấn đề

Trong báo cáo, điều này đặc trưng bởi những sai sót và yếu kém bị giảm nhẹ khi thông tin được truyền từ dưới lên trên. Một ví dụ là cách giám sát viên có thể thực hiện các hành động dưới mức tối ưu để tránh bị cấp trên coi thường.

Tôi đã bị sốc khi lần đầu tiên chứng kiến điều này xảy ra. Chắc tôi đã ra trường được nửa năm hay một năm gì đó. Tôi thấy rằng chúng tôi đang làm điều gì đó rõ ràng là không tối ưu và đã đề cập vấn đề đó với người có thâm niên trong nhóm. Anh ấy nói với tôi rằng anh ấy không phản đối, nhưng nếu chúng tôi làm theo cách đó mà thất bại thì sẽ rất xấu hổ. Ông thừa nhận rằng cách của tôi làm giảm khả năng thất bại mà không làm cho hậu quả kỹ thuật của thất bại trở nên tồi tệ hơn, nhưng điều quan trọng hơn là chúng tôi không cảm thấy xấu hổ. Bây giờ tôi đã làm việc được một thập kỷ, tôi hiểu rõ hơn về cách thức và lý do mọi người chơi trò này, nhưng tôi vẫn thấy nó vô lý.

Các giải pháp

Giả sử bạn nhận thấy rằng công ty của bạn có một vấn đề mà tôi đã nghe mọi người ở hầu hết các công ty phàn nàn: mọi người được thăng chức vì hành động anh hùng và giải quyết sự cố chứ không phải vì ngăn chặn sự cố xảy ra; và mọi người được thăng chức nhờ làm ra các tính năng chứ không phải các công việc bảo trì quan trọng và sửa lỗi. Làm thế nào để bạn thay đổi điều đó?

Lựa chọn đơn giản nhất là tự mình làm điều đúng đắn và bỏ qua những gì đang diễn ra xung quanh bạn. Điều đó có một số tác động tích cực, nhưng ảnh hưởng của bạn sẽ bị hạn chế. Tiếp theo, bạn có thể thuyết phục nhóm của mình làm điều đúng đắn: Tôi đã thử nghiệm chúng một vài lần và tôi cảm thấy thực sự quan trọng và có tính kết dính, vì thế tôi không phải tiếp tục tốn công thuyết phục mọi người khi mọi việc tiến triển.

Nhưng nếu công ty của bạn khuyến khích những điều khác, thì bạn sẽ cần phải có nỗ lực liên tục và có thể không bền vững để khiến mọi người làm điều đúng đắn. Khi đó, vấn đề sẽ chuyển sang việc đi thuyết phục người khác thay đổi quan điểm và đảm bảo rằng sự thay đổi đó diễn ra như dự kiến. Làm thế nào để thuyết phục mọi người là điều đáng bàn, nhưng cũng đủ dài và lộn xộn nên nó nằm ngoài phạm vi của bài viết này. Về việc thực hiện thay đổi, tôi đã thấy nhiều sai lầm “rõ ràng” lặp đi lặp lại, cả ở những nơi tôi từng làm việc lẫn ở những nơi mà tôi biết rất nhiều về chính sách nội bộ của họ.

Các công ty nhỏ thì khá dễ dàng. Khi tôi làm việc tại một công ty khoảng 100 người, hệ thống phân cấp là nhân viên -> trưởng nhóm (Team Lead - TL) -> Giám đốc điều hành (CEO). CEO ít khi chạm đến hạ tầng nhưng nếu ông ấy muốn điều gì đó xảy ra thì nó sẽ xảy ra. Quan trọng hơn, ông ấy biết rõ mọi người đang làm gì và về cơ bản có thể điều chỉnh khen thưởng tức thì. Nếu bạn làm được điều gì đó tuyệt vời cho công ty, rất có thể bạn sẽ được tăng lương. Không phải trong chín tháng của chu kỳ đánh giá hiệu suất, mà về cơ bản là ngay lập tức. Không phải tất cả các công ty nhỏ đều làm được điều đó một cách hiệu quả, nhưng với sự lãnh đạo đúng đắn, họ có thể làm được. Điều đó là không thể đối với các công ty lớn.

Tại công ty lớn A (CTYA), họ gặp phải vấn đề mà chúng ta đang thảo luận và nhiệm vụ được đưa ra là khen thưởng tốt hơn những người đã thực hiện những công việc quan trọng nhưng ít được chú ý. Có quá nhiều nhân viên để người quản lý trực tiếp đưa ra mọi quyết định về lương thưởng và thăng chức, nhưng họ có thể xem xét dữ liệu khảo sát, quyết định kiểm tra đột xuất và đưa ra phản hồi cho đến khi quy trình được tiêu chuẩn hóa. Theo tôi thì công ty đó chưa bao giờ đạt được mức (lương) cân bằng giữa công việc bảo trì nhàm chán và các dự án mới, nhưng cũng đủ để những người muốn đảm bảo mọi thứ hoạt động chính xác không phải gây tổn hại đáng kể đến sự nghiệp của họ khi thực hiện điều đó.

Tại công ty lớn B (CTYB), nhân viên cho rằng có vấn đề ở khâu khen thưởng cho việc làm các tính năng mới phong phú hơn so với làm những công việc nhàm chán nhưng quan trọng. Khi tôi nói chuyện với các quản lý, họ cũng thường đồng ý. Tuy nhiên, những người được thăng chức lại là những người làm ra tính năng mới. Tôi thấy ban quản lý đang nỗ lực thực hiện một số thay đổi về văn hóa và quy trình tại CTYB. Hầu hết, những điều đó đều ở dạng tuyên bố từ những người có những chức danh bóng bẩy. Đối với những điều thực sự quan trọng, họ làm một video và yêu cầu mọi người làm một bài kiểm tra trắc nghiệm sau khi xem nó. Hệ quả mà tôi quan sát thấy ở các nhân viên là mọi người nói về sự thiếu kết nối trong công việc quản lý với cuộc sống hàng ngày của họ như thế nào. Tuy nhiên, cũng vì những lý do khiến quá trình bình thường hóa của sự lệch lạc xảy ra, thông tin đó dường như không có cách nào đến được với quản lý cấp trên.

Thật buồn cười khi cuối cùng tất cả trở thành vấn đề của sự khuyến khích. Là một ngành công nghiệp, chúng ta dành nhiều thời gian để suy nghĩ về cách khuyến khích người tiêu dùng làm những gì chúng ta muốn. Nhưng sau đó, chúng ta lại thiết lập các hệ thống khuyến khích khuyến khích chúng ta làm những điều sai trái và chúng ta làm như vậy thông qua sự kết hợp giữa loan tin và vận dụng bừa bãi. Trở lại thời kỳ Microsoft còn thống trị, chúng ta đã sao chép quy trình phỏng vấn của họ và đặt những câu hỏi phỏng vấn hóc búa. Bây giờ Google đang đi lên, chúng ta sao chép quy trình phỏng vấn của họ và đặt các câu hỏi về thuật toán. Nếu bạn nhìn xung quanh các công ty mới nổi sau Google, về cơ bản, hầu hết họ đều sao chép hệ thống xếp hạng/phân cấp của Google, với một số sửa đổi nhỏ. Tin tốt là, không giống như nhiều công ty mọi người sao chép trước đây, Google đã suy nghĩ rất nhiều về hầu hết các quy trình của họ và đưa ra các quyết định dựa trên dữ liệu. Tin xấu là chúng chỉ áp dụng đặc biệt cho mỗi Google chứ không khái quát cho tất cả và mọi người vẫn thường còn “sùng bái” rất lâu sau khi chúng không còn được áp dụng ở Google.

Sự lan truyền nãy cũng xảy ra với trong kỹ thuật. Stripe đã xây dựng một message queue bằng Mongo, nên chúng ta cũng làm như vậy. Nó đã trở thành một dây chuyền.

Báo cáo có những phần nói về cách ngăn chặn quá trình bình thường hóa sự sai lệch, tôi đề xuất mọi người nên đọc hết chúng.

  • Để ý đến các tín hiệu nhỏ giọt
  • Chống lại sự thôi thúc tinh thần lạc quan vô lý
  • Dạy nhân viên cách cư xử trong những cuộc trò chuyện không thoải mái về mặt cảm xúc
  • Người vận hành hệ thống cần phát ngôn được sự an toàn
  • Nhận thức được việc dự đoán và giám sát không bao giờ kết thúc

Hãy phân tích điều đầu tiên, “để ý đến các tín hiệu nhỏ giọt”, tương tác với ví dụ đã được nói đến, cái “CLGT CLGT” khi nhân viên mới gia nhập.

Nếu một phó giám đốc nói có thứ gì đó đang không ổn, mọi người thường sẽ để ý. Đó là một tín hiệu mạnh. Và khi mọi người không để ý, phó giám đốc sẽ biết tác động vào đâu để giải quyết vấn đề. Nhưng khi nhân viên mới vào, họ không biết cần tác động vào ai, vào đâu. Họ đưa ra những tín hiệu nhỏ giọt dễ dàng bị phớt lờ. Cho đến cái lúc họ có đủ hiểu biết về hệ thống để đưa ra một tín hiệu mạnh thì họ đã thích nghi mất rồi.

“Để ý đến các tín hiệu nhỏ giọt” nghe có vẻ là một lời khuyên tốt nhưng làm sao cho đúng? Những tín hiệu mạnh ít và hiếm khiến chúng dễ dàng nhận được sự chú ý. Tín hiệu nhỏ giọt rất nhiều. Làm cách nào để lọc ra những cái không quan trọng? Và làm cách nào chúng ta có thể khiến toàn bộ nhóm hoặc tổ chức thực sự làm được điều đó? Những loại câu hỏi này không thể được trả lời một cách chung chung; chúng cần phải suy nghĩ thực sự. Nhưng chúng ta chủ yếu đặt chúng ở nơi khác. Các công ty khởi nghiệp dành nhiều thời gian để suy nghĩ về sự tăng trưởng và mặc dù tất cả họ đều nói với bạn rằng họ quan tâm rất nhiều đến văn hóa kỹ thuật, nhưng các lựa chọn ưu tiên cho thấy điều ngược lại. Dù có vài ngoại lệ, các công ty lớn cũng không có nhiều khác biệt. Tại CTYB, tôi đã xem qua các bảng phân tích cạnh tranh và thấy chúng thật tuyệt vời. Họ xem xét đến từng chi tiết cuối cùng trên hàng trăm sản phẩm để đảm bảo rằng mọi thứ phải tốt nhất cho người dùng của họ, từ việc giới thiệu đến tương tác với các sản phẩm cạnh tranh. Nếu có bất kỳ trang web nào phức tạp hoặc khó hiểu hơn của đối thủ cạnh tranh, mọi người sẽ khó chịu và cố gắng sửa nó. Việc đó khá ấn tượng. Và sau đó, khi CTYB tuyển nhân viên vào nhóm của tôi, một phần ba trong số họ thiếu ít nhất một trong số thứ như: tài khoản, chỗ ngồi hoặc máy tính, tình trạng đó có thể kéo dài hàng tuần hoặc hàng tháng. Các bảng phân tích cạnh tranh nói về tầm quan trọng của việc tiếp cận ban đầu vì bạn chỉ có một cơ hội để tạo ấn tượng đầu tiên, nhưng nhân viên mới sẽ có ấn tượng thế nào thì công ty không hề quan tâm đến và quy trình bị phá vỡ tràn lan như thế được cho là điều bình thường. CTYB thậm chí còn không thể làm ra hồn những điều cơ bản khi có nhân viên mới vào, chưa nói đến những thứ thực sự phức tạp như thích nghi với văn hóa công ty. Điều này có thể hiểu được — các số liệu bên ngoài như mức tăng trưởng hoặc sụt giảm người dùng đều có thể đo lường được nhưng các mục tiêu như cách nhận biết liệu bạn có đang thích nghi hay không để cho mọi người không bỏ qua các tín hiệu nhỏ giọt thì khó xác định hơn, nhưng điều đó không có nghĩa là chúng kém quan trọng hơn. Mọi người viết rất nhiều về những thứ như sử dụng các ngôn ngữ (lập trình) hay hơn hay các kỹ thuật như TDD hay Agile sẽ giúp nhóm của bạn làm việc hiệu quả hơn, nhưng việc có một nền văn hóa kỹ thuật vững chắc sẽ mang lại sức mạnh lớn hơn rất nhiều.