Sếp của tôi đã quyết định bổ sung một người khác để đổ lỗi cho trường vào mọi báo cáo lỗi. Làm thế nào tôi có thể thuyết phục anh ta rằng đó là một ý tưởng tồi?

Trong một trong những động thái "WTF" mới nhất, sếp của tôi đã quyết định rằng việc thêm trường "Person To Blame" vào mẫu theo dõi lỗi của chúng tôi sẽ tăng trách nhiệm (mặc dù chúng tôi đã có cách buộc lỗi vào các tính năng / câu chuyện). Lập luận của tôi rằng điều này sẽ làm giảm tinh thần, tăng chỉ tay và sẽ không tính đến các tính năng bị thiếu / hiểu lầm được báo cáo là lỗi đã không được nghe thấy.

Một số lập luận mạnh mẽ khác chống lại thực tiễn này mà tôi có thể sử dụng là gì? Có bài viết nào về chủ đề này mà tôi có thể chia sẻ với nhóm và sếp không?

Nói với họ đây chỉ là một tên nghiệp dư cho trường Nguyên nhân gốc được sử dụng bởi các chuyên gia (khi trình theo dõi vấn đề không có trường dành riêng, người ta có thể sử dụng nhận xét cho điều đó).

Tìm kiếm trên web cho một cái gì đó giống như phân tích phần mềm lỗi nguyên nhân gốc rễ , có rất nhiều nguồn lực để biện minh cho lập luận này ^{1 , 2 , 3 , 4 , ...} .

... một nguyên nhân gốc rễ cho một khiếm khuyết không phải lúc nào cũng là một nhà phát triển (đó là điểm chính của lĩnh vực này) ...

Đó chính xác là lý do tại sao "nguyên nhân gốc rễ" là chuyên nghiệp trong khi "người đổ lỗi" là nghiệp dư. Trách nhiệm cá nhân là rất lớn, nhưng có những trường hợp khi nó chỉ đơn giản là "bên ngoài" nhóm phát triển.

Nói với sếp của bạn khi có là một nhà phát triển duy nhất để đổ lỗi, lĩnh vực nguyên nhân gốc rễ chắc chắn sẽ giới thiệu đó ( "mã hóa sai lầm của Bob trong cam kết 1234, bỏ lỡ bởi Jim trong việc xem xét 567" ). Điểm của việc sử dụng nguyên nhân gốc là để bao gồm các trường hợp như vậy, cùng với các trường hợp đi ra khỏi phạm vi của nhóm nhà phát triển.

^{Ví dụ: nếu lỗi do phần cứng bị lỗi (với người đổ lỗi là người ngoài nhóm đã mua và kiểm tra), trường nguyên nhân gốc cho phép che giấu điều đó, trong khi "nhà phát triển đơn lẻ đổ lỗi" sẽ đơn giản phá vỡ các vấn đề theo dõi dòng chảy.}

^{Điều tương tự cũng áp dụng cho các lỗi khác do ai đó bên ngoài nhóm nhà phát triển - lỗi người kiểm tra, thay đổi yêu cầu và quyết định quản lý. Giả sử, nếu ban quản lý quyết định bỏ qua đầu tư vào phần cứng khắc phục thảm họa, "đổ lỗi cho một nhà phát triển duy nhất" vì mất điện trong trung tâm dữ liệu sẽ không có ý nghĩa.}

Một kết quả có thể xảy ra khác cho một chính sách như vậy là mọi người sẽ không báo cáo lỗi nếu họ nghĩ rằng họ có thể là "người đáng trách", vì vậy nó sẽ thực sự làm giảm số lượng lỗi được báo cáo bởi nhóm.

Đối số chính mà tôi sẽ sử dụng để chống lại nó là hỏi xem anh ta đang cố gắng giải quyết vấn đề gì. Hầu như chắc chắn có những cách tốt hơn để giải quyết vấn đề tương tự.

Đối với một điều, có thực sự chỉ có một người để đổ lỗi? Nếu có, bạn đang làm sai điều gì đó. Một quy trình tốt cần một phần công việc thông qua một nhà phân tích, lập trình viên, nhà phê bình và người kiểm tra trước khi đưa nó vào sản xuất. Nếu bạn không thực hiện tất cả các giai đoạn này, có thể đó là giải pháp cho vấn đề mà sếp của bạn đang cố gắng giải quyết. Nếu bạn là ai thì đáng trách? Nó có thể không phải là một trong số họ, nó có thể là mã di sản đáng trách.

Thật không tốt khi mọi người cắn lại và chỉ ngón tay, cố gắng tránh một vết đen sẽ không biến mất một khi nó được thiết lập. Nó không giải quyết được gì. Rất ít người sơ suất độc hại. Bạn cần thực hiện một hồi cứu thích hợp , xem những gì đã sai và những gì bạn có thể làm để đảm bảo nó không bị sai lần nữa.

Từ đó bạn sẽ thấy rõ nếu một người thường xuyên có lỗi và đó có thể là một vấn đề khác để giải quyết.

Mẹo để ngăn người quản lý tạo ra trách nhiệm là cung cấp nó một cách tự do , nhưng theo cách thực sự có ý nghĩa với bạn.

Có ít nhất ba vấn đề với lĩnh vực đó.

Điều đầu tiên là đổ lỗi cho mọi người không tốt cho tinh thần. Đồng ý. Nhưng có lẽ anh ta không quan tâm đến tinh thần và muốn sa thải những nhà phát triển tồi. Khó để chống lại.

Điều thứ hai là việc có được lĩnh vực đó sẽ trở nên khó khăn và thời gian khá lớn. Nó phức tạp hơn việc tìm ra ai đã viết mã xấu. Và bất kỳ thông tin có khả năng khó tìm ra đều có thể bị bao cát / lừa dối. Nhưng có lẽ anh ấy đã chuẩn bị để trả chi phí đó và kiểm tra thông tin. Khỏe.

Vấn đề cơ bản hơn là lĩnh vực này sẽ không phải là một thước đo tốt để hành động. Chắc chắn, anh ta sẽ có một thứ hạng tốt trong đó mã của họ gây ra nhiều khiếm khuyết nhất. Nhưng đoán xem ai sẽ đứng đầu danh sách đó? Có lẽ người sáng lập công ty, hoặc có thể là một nhà phát triển hàng đầu có tỷ lệ lỗi rất thấp nhưng hiệu quả đến mức anh ta viết một phần không cân xứng của mã. Vì vậy, anh ta cuối cùng sẽ sa thải nhà phát triển tốt nhất của mình, hoặc khiến anh ta chậm lại rất nhiều, anh ta không còn là nhà phát triển tốt nhất nữa. Và họ, người viết một dòng mã một tháng - tốt nhất là bình luận - có thể sẽ được thưởng cho những con số khiếm khuyết thấp của mình.

Một số liệu phần mềm thất bại.

Nguyên nhân sâu xa cho một khiếm khuyết thực địa không bao giờ là một người. Những người có lương tâm hoàn hảo sẽ mắc lỗi, và một quá trình mong đợi chúng không thể sai lầm là không hợp lý. Nếu bạn không xác minh các thay đổi đối với các hệ thống sản xuất trước khi triển khai, bằng tay hoặc thông qua thử nghiệm tự động, thì lỗi là không thể tránh khỏi.

Sai lầm:

Bob quên kiểm tra đầu vào và chương trình bị lỗi chia cho 0.

Đúng:

Mã dễ bị phân chia bởi lỗi không được phát hiện trước khi triển khai. Các trường hợp thử nghiệm mới đã được thêm vào để xác minh xử lý thích hợp đầu vào không hợp lệ. Mã đã được sửa chữa và tất cả các trường hợp thử nghiệm mới được thông qua.

Thay đổi "Người để đổ lỗi" thành "Người để khen ngợi"

Người chính để sửa lỗi có tên của họ trên đó.

Câu trả lời đơn giản.

Trường "Đổ lỗi" sẽ không được sử dụng cho mục đích nào khác ngoài việc gièm pha và chỉ tay, tinh thần sẽ giảm mạnh, niềm tin của đội sẽ bị phá hủy và mọi người sẽ cố gắng tìm cách chứng minh rằng một cái gì đó không phải là lỗi của họ thay vì sửa chữa nó. Mọi người cũng sẽ có xu hướng giữ im lặng về các lỗi thay vì báo cáo chúng, vì họ không muốn đồng nghiệp gặp rắc rối. Nó hoàn toàn phản tác dụng.

Điều gì quan trọng hơn, nạn nhân của ai đó đã phạm sai lầm trung thực, hoặc khắc phục vấn đề càng nhanh càng tốt?

Sếp của bạn dường như nghĩ rằng lỗi là một dấu hiệu của sự lười biếng hoặc chậm chạp. Họ không phải. Họ là một thực tế của cuộc sống. Microsoft đẩy ra bao nhiêu bản vá trong một năm?

Nếu bạn không tuân theo một chút bất tuân dân sự, hãy yêu cầu nhóm đồng ý đưa danh sách tất cả các nhà phát triển vào lĩnh vực đó cho từng lỗi. Nếu điều đó không phù hợp, hãy viết "Tôi là Spartacus!" thay thế. Tất nhiên, vấn đề là tất cả các bạn đều chịu trách nhiệm cho tất cả các lỗi và bạn không hài lòng về việc phải chỉ ra cá nhân đã tạo ra bất kỳ một lỗi nào.

Một lựa chọn khác: chơi cùng. Đừng làm bất cứ điều gì cụ thể - chỉ cần làm tốt công việc và điền vào trường chính xác như bạn có thể trong một vài tháng. Sau đó giải thích với sếp rằng việc gán lỗi cho từng lỗi khiến mọi người trong nhóm không hài lòng và không thoải mái. Nói với anh ấy rằng tất cả các bạn đều cảm thấy rằng có rất ít mối tương quan giữa các lỗi được tạo ra và bất cứ điều gì khác (kỹ năng, nỗ lực, sự tỉnh táo). (Sẽ hữu ích nếu bạn có thể chạy một số số cho thấy thực sự không có mối tương quan nào.)

Sự bất tuân dân sự của Gandhian: Đặt tên của bạn trên mọi lĩnh vực (trừ khi các nhà phát triển khác bước lên và đặt tên cho lỗi của họ) và chấp nhận đổ lỗi cho mọi lỗi cho dù đó là của bạn hay không. Không có gì sẽ khiến lĩnh vực đó hoặc ý tưởng đổ lỗi cho ai đó vô dụng hơn thế này. Nếu sếp của bạn hỏi tại sao tên của bạn trên mọi lĩnh vực, thì bạn có thể giải thích "bởi vì tôi không nghĩ phát triển là một trò chơi đáng trách, nếu bạn thực sự cần mọi người đổ lỗi và đóng đinh, thì hãy đóng đinh tôi vì mọi thứ và hãy để nhóm của tôi làm việc một cách hòa bình . "

Tôi đã từng có một ông chủ thực hiện một hệ thống rất giống với điều này, và mặc dù đó không phải là lập trình (đó là thiết kế in ấn cho một tờ báo hàng ngày), khái niệm và phản hồi phù hợp là như nhau.

Những gì cô ấy đã làm là thay vì thêm một trường 'người để đổ lỗi' vào giấy tờ của chúng tôi, cô ấy đã đưa cho mỗi nhà thiết kế một bộ nhãn dán màu. Mỗi nhà thiết kế có một nhãn dán màu khác nhau và được hướng dẫn rằng đối với bất kỳ thiết kế nào hoạt động hoặc thậm chí chạm vào nhãn dán phải được thêm vào giấy tờ của thiết kế đó.

Mục tiêu đã nêu của ông chủ về "sáng kiến ​​nhãn dán" là thiết lập nguồn gốc của tất cả các lỗi của bộ phận chúng tôi (lỗi về giấy tờ, lỗi sai, bản sao xấu, về cơ bản là lỗi in tương đương)

Những gì chúng tôi đã làm là đưa cho mỗi nhà thiết kế khác một phần tư nhãn dán của chúng tôi để mỗi màu của chúng tôi có tất cả các màu, và thay vì chỉ tô màu của chúng tôi lên mỗi thiết kế, chúng tôi đặt cả bốn màu của nhà thiết kế.

Đừng chỉ viết tên của bạn vào ô [Đổ lỗi] - hãy đặt tên của mọi người trong nhóm / dự án và đảm bảo rằng cả nhóm đều làm như vậy.

Chúng tôi đã làm việc cùng nhau để chống lại sự nghịch ngợm của cô ấy và kết quả là chúng tôi thực sự đã bắt lỗi lẫn nhau và nói chuyện với nhau về điều đó và cuối cùng đã giảm đáng kể các lỗi. Mặc dù vậy, cô ấy là một người quản lý, và thay vì nhận ra rằng sáng kiến ​​của cô ấy đã kết hợp chúng tôi và tăng năng suất, cô ấy đã làm tất cả và giải tán hệ thống nhãn dán và tuyên bố đó là một thất bại và chính thức khiển trách tất cả chúng tôi.

Nó sẽ kết thúc trừng phạt lập trình viên sung mãn nhất của mình. Điều lạ lùng là, một hoặc hai người có thể là những nhân viên giỏi nhất đã làm việc trong hầu hết các dự án. Nếu bạn có, trong một bộ phận 10 người, một lập trình viên chỉ là một nguồn đầu ra và anh ta đã viết 60% mã giao diện, thì 60% lỗi sẽ nằm trong mã của anh ta.

Giải thích rằng hệ thống này sẽ làm cho nó trông giống như người viết mã nhiều nhất là lập trình viên tồi nhất và người viết ít mã nhất là lập trình viên giỏi nhất.

Điều này nghe có vẻ giống như khi Scott Adams chỉ ra sự khôn ngoan thất bại của Bug Bounty khi ông chủ tóc nhọn ở Dilbert. Wally tuyên bố anh ta sẽ đi và 'viết cho anh ta một Mini Van mới ".

Dilbert truyện tranh cho ngày 13/11/1995 từ kho lưu trữ truyện tranh Dilbert chính thức.

Tôi nhớ lại một lần khi Snow Skiing nói rằng ai đó đã chỉ ra rằng "không rơi" không phải là dấu hiệu của một người trượt tuyết giỏi, mà thường là dấu hiệu của một người không thử bất cứ điều gì (hoặc không thực sự trượt tuyết).

Lỗi có thể được giới thiệu trong mã bởi lập trình kém và thiết kế kém; nhưng, chúng cũng có thể là kết quả của việc viết rất nhiều mã khó. Xử lý những người tạo ra nhiều lỗi nhất có khả năng sẽ khiến các nhà phát triển nghèo như những người có năng suất cao.

Có vẻ như ông chủ của bạn có thể thất vọng với số lượng khuyết điểm. Là những người trong nhóm của bạn đam mê chất lượng? Tạo trường 'cái gì' cho nguyên nhân thay vì trường 'ai' có thể hiệu quả hơn. Ví dụ: Thay đổi yêu cầu, Lỗi thiết kế, Lỗ hổng triển khai, v.v. Ngay cả điều này sẽ thất bại trừ khi có một nhóm phụ trợ để cải thiện chất lượng sản phẩm.

Có lẽ bạn nên xem nó là "Ai ở vị trí tốt nhất để sửa lỗi?" Một phần của tôi cũng cảm thấy, bạn đã phá vỡ nó, bạn sửa chữa nó. Cần có một số trách nhiệm.

Tôi không đồng ý với việc giữ một số điểm. Một số người tạo ra nhiều lỗi hơn vì chúng hoạt động trên các phần phức tạp hơn của mã. Nếu các dòng mã không phải là một số liệu hữu ích, tôi nghi ngờ lỗi trên mỗi dòng mã là tốt hơn. Mã sẽ không bao giờ được kiểm tra.

Tại một số điểm, người quản lý nên biết ai đang làm công việc của họ và ai không, cũng như, ai làm việc đó tốt hơn bởi vì phần còn lại của nhóm làm.

Điều kỳ lạ là không ai đề cập đến điều này trước đây: Thêm một chức năng như vậy vào trình theo dõi lỗi sẽ thúc đẩy nhân viên cố gắng chơi trò chơi hệ thống .

Đây là một vấn đề phổ biến đối với các cách tiếp cận như những gì câu hỏi được trình bày, trong số các ý tưởng tương tự khác (trả theo số dòng mã, trả theo số lỗi). Điều này sẽ khuyến khích nhiều người tập trung vào việc đạt điểm cao, thay vì giải quyết các vấn đề liên quan đến phần mềm họ đang làm việc.

Ví dụ: cố gắng gửi báo cáo lỗi với từ ngữ để giảm bớt sự đổ lỗi của chính mình và đẩy nó sang người khác có thể dẫn đến các nhà phát triển hiểu sai nguyên nhân của vấn đề (hoặc công việc được trao cho một nhà phát triển khác không biết phần đó của một mã tốt như người đã làm việc với nó nhiều nhất và là nguyên nhân chính gây ra lỗi) dẫn đến mất nhiều thời gian và nỗ lực hơn để khắc phục sự cố.

Câu hỏi thực tế của bạn là về cách thay đổi văn hóa trước khi bạn rời công ty, bằng cách thuyết phục sếp của bạn rằng thêm một người để đổ lỗi cho lĩnh vực báo cáo lỗi là một ý tưởng tồi. Nhưng tất nhiên thay đổi văn hóa đòi hỏi anh ta phải thực sự hiểu tại sao đây là một ý tưởng tồi.

Đó là một đơn hàng lớn. Bên cạnh vấn đề giữ thể diện sau khi thay đổi suy nghĩ, có một vấn đề cơ bản là những người nghĩ về giải pháp chủ yếu theo cách đổ lỗi cho cá nhân thường được đặt ra trong suy nghĩ đó.

Bạn đã yêu cầu viết về chủ đề này và Peopleware xuất hiện trong tâm trí. Nó được đánh giá cao và nói về các thuật ngữ chung về cách quản lý những người làm công việc sáng tạo mà đầu ra khó đo lường. Vấn đề là bạn đọc nó sẽ không giúp được gì nhiều, sếp của bạn sẽ phải đọc nó, và tin ít nhất là một số.

Điều kỳ lạ là, vấn đề ở đây liên quan đến con người nhiều hơn là báo cáo lỗi, nên nó rất có thể thuộc về Nơi làm việc hơn là Lập trình viên. Nhưng sự thành công của các dự án phần mềm thường có thể truy nguyên khá nhiều đối với sự tương tác xã hội của con người, vì vậy câu trả lời thực sự thường chủ yếu là về những thứ vượt qua phần mềm.

Đề nghị khác, nửa nghiêm túc của tôi là nói (hoặc thuyết phục đồng nghiệp nói, vì bạn dự định rời đi) rằng bạn sẵn sàng chịu trách nhiệm hoàn toàn cho thành công của dự án và tên của bạn phải luôn đi trong lĩnh vực , kể cả khi người khác mắc lỗi trực tiếp, bạn phải chịu trách nhiệm đảm bảo mọi người trong nhóm làm việc chất lượng.

Tất nhiên điều đó là vô nghĩa, làm thế nào bạn có thể trở lại điều đó, nhưng một số người (đặc biệt là những người có lỗi lớn) thực sự ăn những thứ đó. Ronald Reagan thường công khai chấp nhận trách nhiệm cá nhân mỗi khi bất kỳ thành viên nào trong chính quyền của ông bị vướng vào một vụ bê bối (và có khá nhiều) và nó thực sự hoạt động khá tốt về mặt chính trị mỗi lần. Phần tốt nhất cho bạn là trách nhiệm thường không có hậu quả thực tế, họ chỉ nghĩ bạn là một người đứng lên chịu trách nhiệm.

Hoặc có thể đó không phải là cách nó sẽ đi xuống. Nó hoàn toàn không có ý nghĩa với tôi vì vậy thật khó để tôi dự đoán khi nào nó sẽ hoạt động, nhưng tôi đã chứng kiến ​​nó hoạt động khi dường như không có doanh nghiệp nào làm như vậy (tại nơi làm việc, không chỉ là ví dụ của Reagan).

Mọi người không cố ý làm sai, và bất kỳ chiến lược nào được đặt ra, để đặc biệt đổ lỗi cho những gì có thể hoặc không phải là lỗi của con người là vô lý - chưa kể đến việc cực kỳ không chuyên nghiệp.

Ít nhất, một "bên có trách nhiệm" được giao trách nhiệm và "khắc phục" vấn đề, hoặc đưa ra một kế hoạch để theo dõi và / hoặc ngăn chặn các sự kiện tương tự xảy ra, sẽ tốt. Đôi khi giải pháp không có gì hơn là đào tạo bổ sung. Tôi đã làm việc cho một số công ty, nơi nó là một phần trong bản mô tả công việc của bạn, để có được một nền giáo dục "công ty trả tiền / thời gian công ty". Một nơi thậm chí còn xây dựng cả một "trung tâm đào tạo", mà trường đại học địa phương "mượn" đôi khi, cho các khóa học công nghệ công nghiệp của họ.

Tôi đã làm việc trong một môi trường sản xuất trong 20 năm qua, trong đó các lỗi lập trình không chỉ gây ra lỗi, chúng phá hủy mọi thứ và / hoặc tệ hơn là chúng khiến mọi người bị tổn thương. Tuy nhiên, một điều bất biến trong mọi lĩnh vực sản xuất đứng vững, đó là không bao giờ, trong bất kỳ trường hợp nào, có ai đó để đổ lỗi. Bởi vì đó là một khiếm khuyết trong hệ thống, đơn giản và đơn giản - không phải là khiếm khuyết trong con người. Hãy nhìn nó theo cách này - việc sử dụng trình kiểm tra chính tả - một công cụ hiệu quả cao, dành cho những người kém may mắn trong lĩnh vực văn bản, hoặc có thể chỉ là những người làm việc quá sức ... nhưng không có nghĩa là một phương pháp đổ lỗi hoặc trách nhiệm.

Một môi trường làm việc, bất kể loại nào, hoặc cho mục đích gì, nó là một hệ thống. Một hệ thống được tạo thành từ các thành phần riêng lẻ, nếu "điều chỉnh" đúng cách, sẽ hoạt động hoàn toàn hài hòa - hoặc một số ngữ nghĩa như vậy.

Đề nghị đọc về phần của sếp: 7 thói quen của những người có hiệu quả cao

Có vẻ như anh ta có thể sử dụng một chút khiêm tốn, nếu không phải là kiểm tra thực tế. Anh ấy cũng là một phần của đội, như mọi người khác, và anh ấy cần nhận ra rằng - hoặc nó sẽ không hoạt động, và cuối cùng, anh ấy sẽ cầm chiếc túi bất kể.

Đề nghị đọc và / hoặc nghiên cứu về phần của bạn:

Nhìn vào 5 lý do tại sao phân tích, phân tích nguyên nhân gốc rễ ... bất cứ điều gì đặt bạn vào vị trí tốt hơn để đưa ra giải pháp, không phải là vấn đề . Và sự bất đồng của bạn với sếp, chỉ là, một vấn đề, không phải là một giải pháp. Cung cấp cho anh ấy một cái gì đó tốt hơn, một cái gì đó có ý nghĩa, và thậm chí được chuẩn bị để cho phép anh ấy lấy tín dụng cho ý tưởng.

Ngay bây giờ có vẻ như anh ta không sẵn sàng sửa chữa bất cứ điều gì, bởi vì anh ta không có hiểu biết vững chắc về những gì bị hỏng, nếu có bất cứ điều gì bị phá vỡ - ngoại trừ tâm lý "Tôi là ông chủ" của anh ta.

Chúc may mắn! Tôi hy vọng bạn có thể vượt qua điều này, theo cách mà mọi người đều chấp nhận, đặc biệt là trong những thời điểm này.

EDIT: Cá nhân tôi, từ kinh nghiệm của riêng tôi ... "Hãy tiếp tục, đổ lỗi cho tôi. Vì chắc chắn, tôi sẽ sửa chữa nó, và khi xuống đường, khi nó xảy ra một lần nữa, ai sẽ ở đó để cứu ngày? đoán nó ... tôi, với một nụ cười ole lớn. "

Đối với trách nhiệm giải trình Tôi sẽ không muốn một person to blamelĩnh vực, tôi sẽ muốn một Person who knows the codelĩnh vực hoặc một person who can fixlĩnh vực, để tôi biết nơi để gửi vé hỗ trợ.

Điều này sẽ tăng tốc quá trình tự sửa lỗi và đưa ra trách nhiệm, giống như giết hai con chim bằng một hòn đá. Cá nhân tôi sẽ đưa nó lên cho anh ấy và để anh ấy quyết định xem điều này có giúp tăng tinh thần và trách nhiệm mà không khiến ai cảm thấy thất bại không. Kiểm tra cực đoan không bắt được tất cả các lỗi, nếu không sẽ không có báo cáo lỗi.

Nói với anh ấy "đổ lỗi" là tiêu cực. Thay đổi nó thành "người để sửa chữa", ít nhất nó được đóng khung theo cách tích cực, và công việc tương tự vẫn được thực hiện. Làm thế nào mọi người có thể làm việc nếu họ đang bị "đổ lỗi"?!

Nếu ông chủ của tôi đã làm điều đó sẽ xảy ra, theo thứ tự chính xác này:

1) Tôi sẽ ngay lập tức bắt đầu tìm kiếm một công việc mới.

2) Mỗi ​​khi một lỗi được báo cáo với một người để đổ lỗi, tên của sếp tôi sẽ xuất hiện ở đó và một bình luận về lý do tại sao một quy trình xấu trong nhóm chịu trách nhiệm cho nó. Và CC đó cho ông chủ của mình (tốt nhất là trong một đợt). Bạn có bài kiểm tra đơn vị? Nếu không thì có nghĩa là quá trình dev bị hỏng, do đó lỗi. Bạn có kiểm tra tích hợp tự động liên tục với tất cả các hệ thống bên ngoài? Sau đó, quá trình dev bị hỏng, do đó lỗi. Bạn có khả năng làm cho mọi môi trường giống hệt nhau trong sản xuất thông qua tập lệnh để không cho phép lỗi của con người không? Sau đó, quá trình dev bị hỏng, do đó lỗi. Là một nhà phát triển khủng khiếp? Sau đó, tiêu chí tuyển dụng là badm do đó là lỗi của ông chủ. Có phải tất cả các nhà phát triển đều mắc sai lầm ngu ngốc do thiếu nghỉ ngơi vì họ làm việc 12 giờ mỗi ngày? Sau đó, quá trình dev bị phá vỡ.

Như một lưu ý phụ: Mọi nhà quản lý phát triển giỏi đều nhận thức được những gì tôi đã viết ở trên. Và các chiến lược Agile có nghĩa là chỉ ra cho sếp hoặc cấp trên của anh ta tại sao nhà phát triển chậm lại: Hãy nhìn xem, chúng ta đang dành 50% thời gian để sửa lỗi. Hãy xem xét các chiến lược để giảm bớt chúng để chúng tôi có thể dành 40% thời gian để sửa lỗi và sau đó xem xét lại vấn đề này để đạt được 30%. Vân vân.

Thật không may, có vẻ như bạn không có một người quản lý tốt vì lĩnh vực này. Vì vậy, tôi khuyên bạn nên làm (1) và không đưa nó lên cho người quản lý (ngoại trừ cuộc phỏng vấn thoát của bạn)

Có vẻ như ông chủ của bạn không hiểu biết sâu sắc về phần mềm và có lẽ ông cũng không có ý định đó. Vì vậy, anh ta có một ngôn ngữ khác, một nền văn hóa khác.

Bỏ một công việc cho một vấn đề như thế này, trước cả khi cố gắng bước tới một giải pháp chỉ là một kẻ bỏ cuộc. Bỏ cuộc là bỏ cuộc. Đừng bỏ cuộc cho đến khi anh ấy chắc chắn rằng bạn không bao giờ có thể hiểu nhau. Để chắc chắn về điều đó, trước tiên bạn nên thử.

Vì anh ta không biết ngôn ngữ của chúng tôi và anh ta là ông chủ, nên bước đầu tiên ở đây là cố gắng nói chuyện với anh ta bằng ngôn ngữ của anh ta. Ý tôi là gì với ngôn ngữ? Chúng ta hãy cùng nhau suy nghĩ:

Chúng tôi là những người làm phần mềm, hầu hết chúng tôi yêu thích công việc chúng tôi làm, chúng tôi có mối liên hệ sâu sắc với những gì chúng tôi đang làm. Nếu không, nó không hoạt động và người ta không thể tiếp tục kinh doanh trong một thời gian dài mà không yêu thích nó hoặc hoàn thành ... bạn điền vào chỗ trống ...

Anh ấy, tuy nhiên, nhìn mọi thứ khác đi nhiều. Với mỗi báo cáo lỗi, trong khi hầu hết chúng ta đều hào hứng để làm cho mọi thứ hoạt động tốt hơn (không, ngay cả khi đôi khi thực sự rất căng thẳng, chúng ta yêu thích các vấn đề, chỉ cần thừa nhận nó!), Ông coi đó là một thất bại, một biện pháp của không thành công Điều đầu tiên anh ta muốn hiểu là bọ rất tốt. Lỗi khiến khách hàng yêu thích công ty. (Bây giờ đây là ngôn ngữ của anh ấy) Khi khách hàng báo cáo lỗi hoặc khi chúng tôi tự tìm ra lỗi, sau khi giải quyết xong, nó tốt hơn nhiều so với tình huống không bao giờ xảy ra. Lỗi tạo ra lòng trung thành của khách hàng (tôi nghiêm túc!), Lỗi tạo ra một cái cớ tuyệt vời để giao tiếp giữa người tiêu dùng và nhà sản xuất phần mềm.

Để "tăng lợi nhuận của các lỗi", bạn nên cung cấp các báo cáo lỗi thậm chí mở hơn. Với mỗi báo cáo lỗi và giải pháp tốt, nhanh chóng, sạch sẽ, khách hàng cảm nhận và thấy rằng "wow, những người này thật tuyệt vời! Họ làm việc rất chăm chỉ. Hãy nhìn vào những điều họ đang giải quyết. Chúng tôi thậm chí không biết rằng phần mềm rất phức tạp Điều!" blah blah và blah ...

Hãy di chuyển, nói chuyện bằng ngôn ngữ của anh ấy. Lỗi là tuyệt vời cho một công ty phần mềm, không phải là một vấn đề. Họ làm cho chúng ta một cuộc sống.

Đối với đạo đức nhóm, hiệu quả hoặc bất kỳ loại cuộc nói chuyện nào bạn sẽ thực hiện có thể hoạt động theo cách bạn dự định. Nếu bạn muốn nghỉ việc, anh ấy sẽ nghĩ "aha, giải pháp của tôi bắt đầu hoạt động ngay từ ngày đầu tiên! Các liên kết xấu đã bắt đầu tự rơi trước khi chúng bị lộ!" Anh ta tin vào ý tưởng của mình về việc tìm kiếm những chàng trai xấu trong công ty và rất khó để thuyết phục anh ta bằng cách khác. Đặc biệt là khi bạn có thể là một trong những chàng trai xấu!

Vì vậy, tập trung vào vấn đề thực sự của mình: Lỗi. Cho anh ta thấy rằng bọ có thể rất hữu ích. Không có bất kỳ vấn đề, một mối quan hệ là nhàm chán. Tất cả mọi thứ không giết chết bạn làm cho bạn mạnh mẽ hơn. Mỗi lỗi là một cơ hội tuyệt vời mà bạn có thể sử dụng để tăng hạnh phúc của khách hàng.

Đây chỉ là một điều bạn có thể nói. Hãy suy nghĩ về mối quan tâm của anh ấy và bạn sẽ tìm thấy nhiều mặt hàng khác để thêm vào danh sách của bạn. Chìa khóa VÀNG là đưa ra một thứ thay thế thay vì chiến đấu với ý tưởng của mình!

Nếu bạn đang làm Agile, và có vẻ như bạn đến từ các tính năng / nhận xét câu chuyện . Người đổ lỗi sẽ là người QA để lỗi xảy ra hoặc Chủ sở hữu sản phẩm / Khách hàng chấp nhận tính năng / câu chuyện hoàn chỉnh với lỗi trong đó.

Tôi đã sắp chữ trở lại trong ngày, đây là tôi đảm nhận nó.

Điều này giống như đổ lỗi cho một máy sắp chữ cho lỗi chính tả và những thứ khác mà một người đọc thử nên tìm thấy nhưng đã bỏ lỡ. Máy sắp chữ đã viết sai chính tả, nhưng người đọc thử đã bỏ qua nó, vì vậy nó là người đọc lỗi để đổ lỗi cho lỗi in, không phải là người gây ra lỗi ngay từ đầu.

Trong môi trường Agile, trách nhiệm của người QA là bắt lỗi (lỗi) và trách nhiệm của Chủ sở hữu sản phẩm là không chấp nhận những điều không đúng. Đây là hai cấp độ của trình đọc bằng chứng nên cách ly các nhà phát triển khỏi những thứ được phát hành, đây là cách duy nhất để mọi thứ được phân loại là một lỗi trong môi trường Agile.

Tôi nghĩ rằng người quản lý của bạn đang cố gắng giải quyết một vấn đề với giải pháp sai. Tôi nghĩ có thể có một vấn đề là có quá nhiều lỗi đang được phát hành và người quản lý của bạn muốn các nhà phát triển có quyền sở hữu và trách nhiệm hơn đối với mã mà họ viết.

Sử dụng phát triển theo hướng kiểm tra và thiết lập máy chủ tích hợp liên tục (như Jenkins ) sẽ giúp giải quyết vấn đề này mà không cần giới thiệu "trò chơi đổ lỗi". Một máy chủ tích hợp liên tục rất quan trọng đối với điều này bởi vì khi ai đó thực hiện mã "phá vỡ bản dựng", một email sẽ được gửi đến nhóm cho thấy người đó đổ lỗi. Vì mã này chưa được phát hành cho môi trường sản xuất, loại đổ lỗi này chủ động và đáng khích lệ hơn (và thú vị!).

Kết quả là các nhà phát triển sẽ có quyền sở hữu nhiều hơn, cảm thấy tự tin hơn và sẽ có ít lỗi hơn trong mã sản xuất.

Chỉ ra rằng nếu một người nào đó gây ra lỗi trong sản xuất, thì có gì đó không đúng với phương pháp của bạn hoặc cách phát triển phần mềm toàn diện của bạn. Chỉ ra rằng việc ngăn chặn lỗi vào sản xuất là trách nhiệm của toàn đội.

Sử dụng một trong hai đối số này, xem liệu bạn có thể thuyết phục sếp của bạn rằng có trường "ai sẽ đổ lỗi" làm trường chọn đơn sẽ gây hiểu lầm hay không; và do đó, cần phải đảm bảo rằng trường "ai sẽ đổ lỗi" là trường có nhiều lựa chọn. Khi bạn đã đạt được điều này, thì hãy đảm bảo rằng với mọi lỗi, tên của mọi người đều nằm trong trường. Sếp của bạn cuối cùng sẽ thấy rằng bất kỳ báo cáo về lĩnh vực này là vô ích.

Để cung cấp cho ông chủ một số tín dụng, khái niệm "gán lỗi" đã được đưa vào các công cụ như SVN và việc sử dụng dữ liệu phù hợp có thể mang tính xây dựng cho các nhà phát triển trong việc "tìm ra ai để nói chuyện" trong khi gỡ lỗi, ví dụ: http: / /www.codinghorror.com/blog/2007/11/who-wrote-this-crap.html

Mặc dù tôi đồng ý với phản hồi của gnat ở trên rằng trường Nguyên nhân gốc là một điều tốt, nhưng đây không phải là thông tin giống nhau và "không chuẩn hóa" trường để đôi khi gán tên nhà phát triển trước đó cho nguồn bị ảnh hưởng và đôi khi có một mô tả kỹ thuật (ví dụ: "không mở rộng tới 10000 người dùng") sẽ chỉ làm vẩn đục nước. Tôi ủng hộ việc giữ nguyên nhân gốc rễtrường rõ ràng là một mô tả kỹ thuật (ví dụ: ngay cả khi có lỗi lập trình viên rõ ràng, hãy ghi lại các chi tiết như "IndexOutOfRange Exception khi fooData = 999") để giải quyết toàn bộ các lớp vấn đề với thay đổi kiến ​​trúc hoặc khung (ví dụ: cải thiện các lớp chứa tùy chỉnh, xử lý ngoại lệ cấp cao nhất)

Điều đó nói rằng, việc thêm một trường Person To Blame rõ ràng có thể gửi một thông điệp rất xấu và thông điệp phá hoại đến một nhóm phần mềm mà ban quản lý muốn độc thân và trừng phạt các nhà phát triển cá nhân thường xuyên phá mã. Tôi nghi ngờ người quản lý tin rằng sự giám sát công khai này sẽ khiến các nhà phát triển cẩn thận và tự điều chỉnh hơn để tránh đặt tên của họ trên "bức tường xấu hổ" này và không hiểu tại sao các nhà phát triển sẽ cảm thấy bị đe dọa bởi điều này, đặc biệt là nếu nó được thêm vào nói chung cho mọi báo cáo lỗi.

Các vấn đề với việc thêm phần này dưới dạng trường lỗi / số liệu tiềm năng rất dễ bắt đầu liệt kê:

1. Lỗi rất khó thay đổi để giải quyết và một thống kê đơn giản về số lượng lỗi / nhà phát triển sẽ không phản ánh điều này.
2. Các nhà phát triển rất đa dạng về khả năng "" "" "" "" "" "
3. Nhiều hệ thống phần mềm có các thành phần cần tái cấu trúc, tuy nhiên tái cấu trúc các thành phần kế thừa (đặc biệt nếu cơ sở cũ không có / cơ sở thử nghiệm đơn vị giới hạn) ban đầu sẽ đưa ra lỗi. Các nhà phát triển có thể không được khuyến khích từ hoạt động "tốt" này, nếu có sự kỳ thị / sợ hãi liên quan đến việc tạo ra các lỗi mới (ngay cả khi chúng là tầm thường để giải quyết và kết quả cuối cùng là một cải tiến lớn trong hệ thống.)
4. Người kiểm tra có thể gửi một số lượng lớn các lỗi liên quan đến cùng một vấn đề, dẫn đến số lượng lỗi / nhà phát triển bị sai lệch cao, trừ khi phân tích chi tiết hơn được thực hiện.

Đó chỉ là phần nổi của tảng băng chìm. Kết hợp những điều này với việc chỉ tay xem ai đã dự đoán hành vi API nào, kết quả dự kiến ​​không chính xác trong các thử nghiệm và các vấn đề "sớm hơn trong chuỗi" với các yêu cầu không chính xác / thiếu và rõ ràng là một số liệu như thế này là vô giá trị (trừ khi mục tiêu là làm tổn hại tinh thần và gây ra một cuộc di cư hàng loạt.)

Quay lại với quan điểm của ông chủ, anh ấy / cô ấy muốn tìm hiểu xem có nhà phát triển nào đang phá mã liên tục hay không, và thử làm điều gì đó (hy vọng mang tính xây dựng) về điều đó. Cố gắng để có được thông tin này bằng cách thêm một trường vào các báo cáo lỗi sẽ không cung cấp thông tin có ý nghĩa cho các lý do được liệt kê ở trên. Theo kinh nghiệm của tôi, thông tin này có thể được học bằng cách kết nối với nhóm, tham gia hầu hết các cuộc họp nhóm, tích hợp (cẩn thận) thông tin được học trong các cuộc họp riêng lẻ với các thành viên trong nhóm và làm quen với các hệ thống con trong mã (ngay cả khi họ không thể đọc mã.)

Hãy để nó đi. Sếp của bạn sẽ tự mình khám phá ra rằng nó gây ra vấn đề, nếu có.

Hãy thẳng thắn, bạn có ý kiến ​​và anh ấy cũng vậy. Anh ấy là người quản lý của bạn và ý kiến ​​của anh ấy là người chiến thắng.

Vâng, bạn có thể đi đến chiến tranh về vấn đề này, nhưng nó có thực sự đáng giá không? Tôi nghi ngờ nó kéo dài hơn 3 tháng trước khi rơi vào tình trạng không sử dụng được.

Nhưng chủ động phá hoại điều này hoặc la hét về nó chỉ sử dụng vốn chính trị được tiết kiệm tốt hơn để xin thêm thời gian nghỉ, tăng lương tiếp theo, thăng chức hoặc khi một quyết định thiết kế thực sự quan trọng sẽ được đưa ra.

Vào lúc đó, khi nó thực sự được tính, bạn không muốn sếp nhớ rằng bạn là người chủ động phá hoại ý tưởng của mình để "người đó đổ lỗi".

Tôn trọng văn phòng ngay cả khi bạn không tôn trọng quyết định.

Tiết kiệm căng thẳng và đập bàn cho các quyết định sẽ kéo dài hơn nhiều.

Nói với sếp của bạn rằng phát triển trong một nhóm cần có kỹ năng xã hội. Anh ấy thậm chí có thể gật đầu.

Nhưng vấn đề là, đây là điều mà các nhà phát triển cực kỳ tồi tệ. Thêm các công cụ đề xuất đổ lỗi là quan trọng hơn phân tích vấn đề thích hợp là phản tác dụng.

Thay vào đó, bạn cần khuyến khích để cải thiện các kỹ năng xã hội và cơ sở hạ tầng truyền thông bạn có nên hỗ trợ điều đó. Ví dụ, xu nó tích cực: Đặt tên cho một người chịu trách nhiệm cho một vé, người chăm sóc nó.

Cũng bắt đầu với các đánh giá mã để bạn có thể học hỏi lẫn nhau. Điều đó tha thứ cho những tội lỗi sau này.

Gửi email cho anh câu hỏi này. Nếu anh ấy cởi mở với lý do, các ý kiến ​​ở đây sẽ cung cấp kiểm tra sự tỉnh táo cho lý do của anh ấy. Nếu anh ta không hợp lý, bạn khó có thể thuyết phục anh ta bằng những lý do hợp lý. Ngoài ra, anh ta sẽ có thể đọc các lý do bên ngoài một cuộc trò chuyện (đôi khi có thể thuyết phục hơn vì động lực bị loại bỏ để "đúng" trong sức nóng của một cuộc trò chuyện).

Bạn cũng có thể thử xoay nó. Trường có thể là "các bước có thể để tránh một lỗi tương tự xảy ra" hoặc một cái gì đó ngắn hơn với hiệu ứng đó. Sau đó, bạn có thể tổng hợp các giải pháp và bỏ phiếu cho những giải pháp nào sẽ thực hiện để làm cho nơi làm việc của bạn tốt hơn. Có lẽ một cách tiếp cận theo hướng giải pháp có năng suất cao hơn và có khả năng nhận được tốt hơn (với điều kiện là có sự theo dõi thực tế thông qua việc xem xét lại các đề xuất).

Tôi thấy có hai khả năng ở đây: Anh ta muốn có thể trừng phạt những người mắc lỗi, hoặc anh ta đã không nghĩ đến điều đó. Hãy cho anh ta biết rằng nhận thức cho mọi người sẽ là anh ta có ý định trừng phạt những người mắc lỗi. Hỏi anh ta nếu đó là văn hóa mà anh ta muốn khuyến khích.

ông chủ của tôi đã quyết định rằng việc thêm trường "Person To Blame" vào mẫu theo dõi lỗi của chúng tôi sẽ tăng trách nhiệm

Theo kinh nghiệm của tôi, khi quản lý muốn "làm cho mọi người có trách nhiệm hơn", điều họ muốn nói là họ muốn có thể trừng phạt chính xác cho thất bại. Cho dù đó là để sa thải những người biểu diễn kém, hay chỉ để họ bị đắm chìm trong bài đánh giá tiền lương hàng năm ("Xin lỗi, Bob, bạn có 17 lỗi được gắn cờ là lỗi của bạn và vượt quá giới hạn 15"), đó là hình phạt.

Có lẽ anh ta sẽ nói "Ồ, không, chúng tôi không muốn điều đó", vì vậy hãy hỏi anh ta dữ liệu đó sẽ được sử dụng như thế nào. Nhắc nhở anh ấy rằng bạn không thêm điểm dữ liệu vào cơ sở dữ liệu trừ khi bạn sẽ sử dụng nó. Anh ta có muốn chọn theo một tiêu chí nhất định không ("Hiển thị cho tôi tất cả các lỗi mở trong hệ thống con người tạo báo cáo"), để bạn có thể làm việc trên mọi thứ hoặc để có thể lấy dữ liệu tổng hợp ("Hệ thống con nào có nhiều nhất lỗi "), để bạn có thể thực hiện phân tích sau khi chết. Có phải anh ta hình dung một số loại bảng thất bại mà mọi người có thể bị sỉ nhục?

Vậy anh ta có ý định gì? Anh ấy có muốn nói "Chỉ cho tôi tất cả các lỗi là lỗi của Bob không?" Tại sao? Hay anh ta muốn có thể nói "Hãy cho tôi thấy ai là người có lỗi hầu hết thời gian?" Tại sao? Cái thứ nhất không có ý nghĩa, và cái thứ hai chỉ mang tính trừng phạt. Hoặc lựa chọn thứ ba là anh ta không có lý do thực sự.

Tôi thừa nhận có khả năng anh ta có thể tìm kiếm những lập trình viên trong nhóm, những người cần giúp đỡ trong việc cải thiện kỹ năng của họ. Nếu vậy, có nhiều cách tốt hơn để nắm bắt thông tin này mà không tạo ra văn hóa chỉ tay.

Tôi tin rằng khía cạnh quan trọng cần theo dõi ở đây là cách giao tiếp trong đội đối với 'ông chủ' và cách khác. Tuy nhiên, từ góc độ ngón tay không bao giờ tốt, nếu từ góc độ quản lý, nếu một trong số các nhà phát triển của bạn gặp vấn đề tương tự nhiều lần, có lẽ đã đến lúc bạn cố gắng khắc phục vấn đề lặp đi lặp lại này (ví dụ: John không kiểm tra đúng cách mã: 3 lỗi sản xuất trong 3 tháng qua, hãy đưa cho anh ấy một danh sách kiểm tra để anh ấy nhớ mã của anh ấy được coi là như thế nào và anh ấy nên kiểm tra nó như thế nào).

Từ quan điểm phát triển, 'đổ lỗi' đã được tích hợp vào một công cụ chính thống như SVN, do đó tôi thực sự không thấy bất kỳ tác hại nào khi nói "John, vui lòng sửa đoạn tin tào lao mà bạn đã viết" và đặt tên bên cạnh nó JIRA cũng kết hợp tên của một người khi bạn báo lỗi (tuy nhiên trường này không thực sự có ý nghĩa đối với người chịu trách nhiệm về nó, nó khá nhiều để ai đó sửa nó).

Mặc dù vậy, đây là điều mà nhiều người đã đề cập ở trên, nếu có lỗi phát sinh, đó là trách nhiệm chung: từ nhà phát triển, người kiểm thử, đến QA, đến người quản lý. Nếu một lúc nào đó, sếp của bạn xử lý một khách hàng giận dữ qua điện thoại với những câu như " Tôi rất xin lỗi, John không bao giờ kiểm tra điều này đúng cách ", thì tôi chắc chắn đang tìm kiếm một công việc khác. Một ông chủ tốt nên đi "chúng ta sẽ lo chuyện này". Không tên, không chỉ tay, chỉ giải pháp.

Một lần nữa, tôi tin rằng đó là tất cả về giao tiếp. Có lẽ điều duy nhất mà sếp của bạn muốn làm là xem ai gặp rắc rối trong nhóm nhà phát triển, hoặc nhóm đang gặp phải vấn đề gì (có lẽ là cho các buổi đào tạo?), Nhưng tôi không nghĩ bạn sẽ tìm ra chính xác những gì đằng sau anh ta quyết định (hay nói tốt hơn, chúng tôi áp phích / độc giả) trừ khi bạn nói chuyện với sếp và toàn bộ nhóm của bạn.