Patronum, her hata raporuna bir "suçlu kişi" alanı eklemeye karar verdi. Onu kötü bir fikir olduğuna nasıl ikna edebilirim?

En son "WTF" hamlelerinin birinde patronum hata izleme şablonumuza bir "Şahsı Suç Vermek" alanı eklemenin hesap verebilirliği artıracağına karar verdi (zaten özellikleri / hikayelere hataları bağlama yöntemimiz vardı). Bunun morali azaltacağı, parmak işaretini artıracağı ve hata olarak bildirilen eksik / yanlış anlaşılan özellikleri hesaba katmayacağı iddiası duyulmamış hale geldi.

Bu uygulamaya karşı kullanabileceğim bazı güçlü argümanlar nelerdir? Takım ve patronla paylaşabileceğim bu konuda herhangi bir yazı var mı?

Onlara bunun sadece profesyoneller tarafından kullanılan Kök Neden alanı için amatörce bir isim olduğunu söyleyin (sorun izleyici özel bir alana sahip değilse, bunun için yorum kullanabilirsiniz).

Web yazılım hata kökü neden analizi gibi bir şey için arama, bu neden ^{1 , 2 , 3 , 4 , ...} haklı çıkarmak için bol miktarda kaynak var .

... bir kusurun temel nedeni her zaman tek bir geliştirici değildir (bu alanın ana noktasıdır) ...

İşte bu yüzden "kök neden" profesyonel, "suçlayacak kişi" ise amatörce. Kişisel hesap verilebilirlik harika, fakat sadece dev ekibin "dışına" yattığı durumlar var.

Orada ne zaman Patronuna söyle olduğunu suçlamak tek geliştiricisi, kök neden alanı kesinlikle (yani kapsayacaktır "inceleme 567 yılında Jim tarafından kaçırılmış, 1234 taahhüt Bob tarafından yapılan kodlama hata" ). Terimi kullanmanın noktası kök neden böyle servis taleplerini karşılamak üzere olduğunu boyunca dev ekibinin kapsam dışına çıkar vakalarla.

^{Örneğin, hatanın hatalı donanımdan kaynaklanmış olması halinde (kişi onu satın alan ve test eden ekibin dışında biri olmakla suçlayacak olan), kök neden alanı bunun kaplanmasına izin verirken, "tek geliştiricinin suçlaması" basit bir şekilde kırılır sorun izleme akışı.}

^{Aynısı, geliştirici ekibinin dışındaki birinin neden olduğu diğer hatalar için de geçerlidir - test cihazı hataları, gereksinim değişikliği ve yönetim kararları. Diyelim ki, yönetim felaket kurtarma donanımına yatırım yapmayı atlamaya karar verirse, veri merkezindeki bir elektrik kesintisi için "tek bir geliştiriciyi suçlamak" mantıklı olmaz.}

Böyle bir politika için olası başka bir sonuç da, insanların "suçlanacak kişi" olduğunu düşündükleri takdirde hatayı rapor etmemeleridir, bu nedenle ekip tarafından bildirilen hata sayısını azaltır.

Buna karşı kullanacağım temel argüman, hangi sorunu çözmeye çalıştığını sormak. Aynı problemi çözmenin neredeyse kesinlikle daha iyi yolları var.

Birincisi, suçlanacak tek bir kişi var mı? Varsa, yanlış bir şey yapıyorsunuz. İyi bir süreç, bir analist, programcı, bir inceleme uzmanı ve üretime başlamadan önce bir test cihazı aracılığıyla bir parça çalışmayı gerektirir. Tüm bu aşamaları yapmıyorsanız, belki patronunuzun çözmeye çalıştığı sorunun çözümü budur. Öyleyse hangisini suçlayacaksın? Hiçbiri olmayabilir, suçlanacak eski kod olabilir.

İnsanların parmaklarını geri ısırmalarına ve işaret etmelerine, ayarlandıktan sonra kaybolmayacakları siyah işaretlerden kaçınmaya çalışmak iyi değildir. Hiçbir şey çözmez. Çok az insan kötü niyetli olarak ihmalkar. Doğru bir retrospektif yapmalısın , neyin yanlış gittiğini ve neyin yanlış gitmediğinden emin olmak için ne yapabileceğini gör.

Bundan bir kişinin düzenli olarak hatalı olup olmadığını açıkça göreceksiniz ve bu başa çıkmak için farklı bir sorun olabilir.

Sorumluluk yaratma konusundaki bir yöneticiyi durdurmanın püf noktası, özgürce sunmaktır , ancak sizin için gerçekten mantıklı bir şekilde.

Bu alanda en az üç sorun var.

Birincisi, insanları suçlamak moral için iyi değil. Tamam. Ama belki de morali önemsemiyor ve kötü geliştiricileri kovmak istiyor. Tartışması zor.

İkincisi, bu alanı düzeltmek zor ve oldukça büyük bir zaman alıcı olacak. Sadece kötü kodu kimin yazdığını bulmaktan daha karmaşık. Ve çözülmesi zor olabilecek herhangi bir potansiyel bilgi kum torbası / aldatma olabilir. Ama belki de bu bedelini ödemeye ve bilgiyi denetlemeye hazırdı. İnce.

Daha temel mesele, bu alanın harekete geçilmesi için iyi bir ölçüm olmayacağıdır. Elbette, kodu en çok hasara neden olan hoş bir sıralamaya sahip olacak. Bil bakalım bu listenin başında kim olacak? Muhtemelen şirket kurucusu ya da çok düşük bir kusur oranına sahip olan ancak o kadar üretken bir üst geliştirici, kodun orantısız bir kısmını yazar. Bu yüzden ya en iyi geliştiricisini kovacak ya da daha fazla en iyi geliştiricisi olmadığı için onu yavaşlattıracak. Ve ayda bir satır kod yazan adamlar - tercihen yorumlar - muhtemelen düşük kusurlu sayılarıyla ödüllendirilecekler.

Yine başka bir yazılım metrik hatası.

Alanlı bir kusurun kök nedeni asla tek bir kişi değildir. Kusursuzca vicdan sahibi insanlar hata yaparlar ve yanılmaz olmalarını bekleyen bir süreç mantıksızdır. Dağıtımdan önce, manuel olarak veya otomatik testlerle üretim sistemindeki değişiklikleri doğrulamıyorsanız, hata kaçınılmazdır.

Yanlış:

Bob girişi kontrol etmeyi unutuyor ve program bölüştürmeyi sıfıra indirdi.

Sağ:

Açılmadan önce sıfır hata ile bölünmeye açık olan kod algılanmadı. Geçersiz girişin uygun şekilde ele alındığını doğrulamak için yeni test senaryoları eklendi. Kod düzeltildi ve tüm yeni test vakaları geçiyor.

"Suçlayacak Kişi" ni "Övmek için Kişi" olarak değiştir

Hataları düzeltecek asıl kişi ismini alır.

Basit cevap

"Suçlama" alanı, günah çıkarma ve parmakla işaret etmekten başka bir şey için kullanılmayacak, moral düşecek, takım güveni yok edilecek ve herkes bir şeyin onu düzeltmek yerine onların suçu olmadığını kanıtlamanın yollarını bulmaya çalışacak. İnsanlar ayrıca, bir meslektaşının başının derde girmesini istemediklerinden, rapor etmekten ziyade böcekleri sessiz tutma konusunda daha istekli olacaklardır. Tamamen karşı üretken.

Daha önemlisi, dürüst bir hata yapmak için birini mağdur etmek ya da sorunu olabildiğince çabuk düzeltmek mi?

Patronunuz, böceklerin tembellik veya dikkatsizlik işareti olduğunu düşünüyor gibi görünüyor. Onlar değil. Onlar yaşamın bir gerçeğidir. Microsoft bir yılda kaç tane yamayı zorlar?

Küçük bir sivil itaatsizlik için hazırsanız, ekibin her bir böcek için bu alandaki tüm geliştiricilerin bir listesini koymaya karar vermesini sağlayın. Bu uygun olmazsa, "Ben Spartaküs'üm!" Yazın. yerine. Mesele şu ki, hepiniz tüm böceklerden sorumlu olmanız ve herhangi bir böcek yaratan kişiyi işaret etmek zorunda kalmaktan memnun değilsiniz.

Başka bir seçenek: birlikte oynamak. Özel bir şey yapmayın - sadece iyi işler yapın ve alanı birkaç ay boyunca olabildiğince doğru bir şekilde doldurun. Ardından her bir hata için suçu atamanın takımdaki herkesi mutsuz ve rahatsız edici yaptığını patronuna anlatın. Ona hepinizin yaratılan hatalarla başka herhangi bir şey arasında (beceri, çaba, akıl sağlığı) küçük bir ilişki olduğunu hissettiğinizi söyleyin. (Gerçekten bir korelasyon olmadığını gösteren bazı rakamlar çalıştırabilirseniz yardımcı olacaktır.)

Gandhian Sivil itaatsizlik: Her alanda isminizi yazın (diğer geliştiriciler adım atar ve böcekleri için ismini koymazsa) ve sizinki olsun veya olmasın her hata için suçu kabul edin. Hiçbir şey bu alanı ya da birisini bundan daha işe yaramaz hale getirmekle suçlayamaz. Patronunuz neden her alanda adınız olduğunu sorarsa, "açıklamanın bir suçlama oyunu olduğunu sanmıyorum, çünkü gerçekten suçlu ve çarmıha gerilmeye ihtiyacınız varsa, beni her şey için çarmıha gerin ve ekibimin barışçıl çalışmasına izin verin. ."

Bir patronum buna çok benzer bir sistem uygulamıştı ve programlama olmamasına rağmen (günlük bir gazete için baskı tasarımıydı) kavramı ve uygun cevap aynıydı.

Yaptığı şey, evraklarımıza 'suçlayacak' bir alan eklemek yerine, tasarımcıların her birine bir dizi renkli çıkartma verdi. Her tasarımcı farklı renkte bir çıkartmaya sahipti ve üzerinde çalışılmış veya dokunulmuş herhangi bir tasarım için çıkartmanın bu tasarımın evraklarına eklenmesi gerektiği söylendi.

Patronun "çıkartma girişimi" için hedefini belirttiğimiz gibi, tüm departmanımızın hatalarının kaynağını oluşturmaktı (evrak hatalarında, yanlış doldurmada, kötü kopyada, esasen hataların basılmasında)

Yaptıklarımız, diğer tasarımcıların her birine çıkartmalarımızın dörtte birini verdi, böylece her birimizin tüm renklere sahip olmasını sağladık, ve her bir tasarıma sadece rengimizi koymak yerine, tasarımcının dört renginin hepsini koyduk.

Sadece isminizi [Blame] kutusuna yazmayın, ekibin / projenin üzerindeki herkesin adını yazın ve tüm ekibin aynı şeyi yaptığından emin olun.

Onun orwellian kaltaklığına karşı birlikte çalıştık ve sonuç olarak birbirimizin hatalarını yakalayıp birbirimizle konuştuk ve sonuçta hatalarda önemli bir düşüş yaşadık. Yine de sh * t müdürüydü ve inisiyatifinin bizi bir araya getirip üretkenliği arttırdığı sonucuna varmak yerine, her şeyi mahvetti ve çıkartma sistemini dağıttı ve bir başarısızlık ilan etti ve resmen hepimize azarladı.

En üretken programcısını cezalandırmaktan kurtulacak. Muhtemelen, bir ya da iki kişi, çoğu projede çalışmış en iyi çalışanlar olabilir. 10 kişilik bir departmanda, yalnızca bir çeşme çeşidi olan bir kodlayıcı varsa ve arayüz kodunun% 60'ını yazdıysa, böceklerin% 60'ı kendi kodunda olacaktır.

Bu sistemin, en çok kod yazan kişi en kötü programcı ve en küçük kod yazan kişi en iyi programcı gibi görünmesini sağlayacağını açıklayın.

Bu, Scott Adams, Dilbert'teki Pointy Haired Boss'un Bug Bounty'nin başarısız bilgeliğine işaret ettiği zamana çok benziyor. Wally gideceğini ve 'ona yeni bir Mini Van yazacağını' duyurdu.

Resmi Dilbert çizgi roman arşivinden 11/13/1995 için Dilbert çizgi roman şeridi.

Bir keresinde Snow Skiing'in birisinin 'düşmemenin' iyi bir kayakçı işareti olmadığını, genellikle bir şey denemeyen (ya da hiç kayak yapmayan) işareti olmadığını söylediğini hatırlıyorum.

Hatalar, zayıf programlama ve zayıf tasarım ile kodlanabilir; ancak, birçok zor kodun da bir sonucu olarak gelebilirler. En fazla hatayı üreten insanlara Dinging, Ding geliştiricilerinin yüksek verimlilikte olduğu kadar muhtemel.

Patronunuz kusur sayısından dolayı sinirlenmiş gibi görünüyor. Grubunuzdaki insanlar kalite konusunda tutkulu mu? Neden için 'kim' alanı yerine 'ne' alanı oluşturmak daha verimli olabilir. Örn: Gereksinimler Değişiklik, Tasarım Kusuru, Uygulama Kusuru, vb.

Belki de "Hatayı düzeltmek için en iyi konumda kimdir?" Olarak bakmalısınız. Bir parçam da hissediyor, sen kırdın, tamir ettin. Sorumluluk olmalı.

Bir çeşit skor tutmaya katılmıyorum Bazı insanlar daha fazla hata yaratır çünkü kodun daha karmaşık kısımlarında çalışırlar. Kod satırları yararlı bir ölçüm değilse, kod satırlarının başına düşen hataların daha iyi olduğundan şüpheliyim. Kod asla kontrol edilmeyecek.

Bir noktada bir yönetici, işini kimin yaptığını ve kimin yapamayacağını bilmelidir, çünkü takımın geri kalanı da bunu daha iyi yapar.

Daha önce hiç kimsenin bundan bahsetmemesi garip: Böcek izleyicisine böyle bir işlevsellik eklemek, çalışanları sistemi oynamaya motive edecek .

Bu, diğer benzer fikirlerin yanı sıra, (kod satırı sayısına göre ödeme, böcek sayısına göre ödeme yapma), sorunun sunulduğu gibi yaklaşımlar için yaygın bir sorundur. Bu, birçok kişinin üzerinde çalıştıkları yazılımla ilgili sorunları çözmek yerine iyi bir puan almaya odaklanmasını teşvik edecektir.

Örneğin, kendi suçunu azaltmak için bir ifade içeren bir hata raporu sunmaya çalışmak ve bir başkasına itmek, geliştiricilere sorunun nedenini (veya bu bölümü bilmeyen başka bir geliştiriciye verilen çalışmayı yanlış anlama) yol açabilir. üzerinde en çok çalışan ve hatanın ana nedeni olan kişi kadar iyi bir kod) sorunu çözmek için daha fazla zamana ve çabaya yol açar.

Asıl sorunuz, şirketten ayrılmadan önce kültürün nasıl değiştirileceği ile ilgiliydi, patronunuzu hata raporları alanını suçlayacak bir kişi eklemenin kötü bir fikir olduğuna ikna ederek. Fakat elbette kültürü değiştirmek onun neden kötü bir fikir olduğunu anlamasını gerektiriyor .

Bu uzun bir emirdir. Fikrini değiştirdikten sonra yüz kurtarma konusunun yanı sıra, temel olarak bireysel suçlama açısından çözümler hakkında düşünen insanların genellikle bu zihniyete yerleştiği temel sorun var.

Bu konuyla ilgili yazı yazmayı istediniz ve Peopleware akla geliyor. Çıktının ölçülmesinin zor olduğu, yaratıcı işler yapan insanların nasıl yönetileceği hakkında genel olarak konuşulur. Sorun şu ki, onu okumanın pek bir faydası olmaz, patronunuz onu okumak zorunda kalır ve en azından bazılarına inanır.

İşin garibi, buradaki sorun hata raporlarından ziyade insanlarla ilgili olduğu için muhtemelen İşyerinde Programcılardan daha fazladır. Ancak yazılım projelerinin başarısı genellikle insan sosyal etkileşimi ile oldukça fazla izlenebilirdir, bu nedenle gerçek cevaplar çoğunlukla yazılımı aşan şeylerle ilgilidir.

Benim sadece diğer yarısı ciddi, öneri olduğunu söylemek (veya bırakmak için plan beri söylemek bir meslektaş ikna) etmektir Eğer projenin başarısı için tam sorumluluk almaya hazırız ve adınız gerektiğini hep alanına gitmek Çünkü bir başkası doğrudan hata yapmış olsa bile, takımdaki herkesin kaliteli işler yaptığından emin olmak için sorumluluk aldınız.

Elbette saçmalık, bunu nasıl geri alabilirsin, ama bazı insanlar (özellikle de suçlu olan insanlar) bu şeyleri gerçekten yiyorlar. Ronald Reagan, yönetiminin herhangi bir üyesi bir skandala yakalandığında (ve epeyce vardı) her zaman kişisel sorumluluğu kabul ediyordu ve aslında her seferinde oldukça iyi sonuç veriyordu. Sizin için en iyi yanı, sorumluluğun genellikle gerçek sonuçları olmadan ortaya çıkmasıdır, sadece sorumluluğu üstlendiğiniz için ayakta durabileceğiniz bir adam olduğunuzu düşünüyorlar.

Ya da belki de böyle devam edemez. Bana hiç bir şey ifade etmiyor, bu yüzden ne zaman işe yarayacağını tahmin etmem zor, ama iş yapmayan bir iş göründüğünde (işyerinde, sadece Reagan örneğinde değil) çalıştığına şahit oldum.

İnsanlar hata yapma niyetine çalışmaya gitmezler ve insan hatası olabilir ya da olamayacağına dair suçu özellikle eklemek için uygulanan herhangi bir strateji saçmadır - son derece profesyonelce değil.

En azından, sorunu ele almak ve “düzeltmek” için görevlendirilen veya sorumlu olayların gerçekleşmesini izlemek ve / veya önlemek için bir plan bulmakla görevlendirilmiş bir “sorumlu parti” iyi olurdu. Bazen çözüm ek eğitimden başka bir şey değildir. Bir "şirket ücretli / şirket zamanı" eğitimi almak için iş tanımınızın bir parçası olduğu birkaç şirkette çalıştım. Hatta bir yer, yerel kolejin zaman zaman endüstriyel teknolojiler dersleri için ödünç aldığı “bir eğitim merkezi” inşa etti.

Programlama hatalarının sadece hatalara neden olmadığı, fiziksel olarak bir şeyleri yok ettiği ve / veya daha da kötüsü insanlara zarar verdiği bir üretim ortamında çalıştım. Bununla birlikte, güçlü duran her üretim alanında bir sabit, hiçbir koşulda, hiçbir zaman suçlanacak birisinin olmamasıdır. Çünkü sistemdeki bir kusur, sade ve basit - insanlarda bir kusur değil . Şuna bakın - yazım denetleyicisinin kullanımı - metinsel erdem alanında daha az şanslı olanlar için ya da sadece biraz fazla çalışmış olanlar için oldukça etkili bir araç ... ama hiçbir şekilde bir suçlama ya da hesap verme yöntemi yok.

Bir çalışma ortamı, ne tür olursa olsun veya hangi amaçla hizmet ettiği bir sistemdir. Bireysel bileşenlerden oluşan bir sistem, eğer uygun şekilde "uyum halinde" ise, tam bir uyum içinde çalışır - veya bunun bir benzeri.

Patronunuzun bölümünde önerilen okuma: Yüksek Etkili İnsanların 7 Alışkanlığı

Gerçeklik kontrolü olmasa bile, biraz alçakgönüllülük kullanabilecek gibi görünüyor. O da herkes gibi ekibin bir parçası ve bunun farkına varması gerekiyor - ya da sadece işe yaramayacak ve sonunda çantayı ne olursa olsun elinde tutacak.

Sizin tarafınızdan önerilen okuma ve / veya araştırma:

Neden analiz, kök neden analizi ... bir sorun değil, çözüm önermek için sizi daha iyi bir konuma sokan herhangi bir şeyi inceleyin . Ve patronunuzla olan anlaşmazlığınız, sadece bir problem, çözüm değil. Ona daha iyi bir şey teklif et, mantıklı bir şey ve hatta fikir için kredi almasına izin vermeye hazır ol.

Şu anda hiçbir şeyi düzeltmeye hazır gibi görünmüyor, çünkü neyin kırıldığına dair kesin bir anlayışa sahip değil, eğer kırılmış bir şey varsa - “patron benim” zihniyetinden başka bir şey bilmiyor.

İyi şanslar! Umarım bunu, özellikle bu zamanlarda, herkes için kabul edilebilir bir şekilde gerçekleştirmeyi başarırsınız.

EDIT: Şahsen, kendi tecrübelerime göre ... "Devam et, beni suçla. Çünkü yeterince eminim, onu düzelteceğim, ve yolun aşağısında, tekrar olduğunda, günü kurtarmak için orada kim olacak? tahmin etmiştim ... ben, kocaman bir sırıtış gülüşü ile. "

Hesap verebilirlik için bir person to blamealan istemem, bir Person who knows the codealan veya person who can fixalan isterdim, böylece destek biletini nereye göndereceğimi bilirdim.

Bu, böceğin kendisini düzelterek süreci hızlandırır ve hesap verebilirlik sağlar, bir tür iki kuşu bir taşla öldürmek gibi. Bunu şahsen ona getirip, kendisinin başarısız hissettiğini düşünmeden moral ve hesap verebilirliğin artırılmasına yardımcı olup olmayacağına karar vermesine izin verdim. Aşırı test, tüm hataları yakalamaz, aksi halde hata bildirimi olmaz.

Ona "suçlama" nın olumsuz olduğunu söyle. Bunu "düzeltilecek kişi" olarak değiştirin, en azından olumlu bir şekilde çerçevelenir ve aynı iş hala devam eder. İnsanlar "suçlanmak" durumunda nasıl çalışabilir ?!

Patronum bunu yaptıysa, tam da bu sırada olacaktı:

1) Hemen yeni bir iş aramaya başlardım.

2) Suçlanacak bir kişiyle ne zaman bir hata bildirilirse, patronumun adı orada belirir ve ekipteki kötü bir sürecin neden sorumlu olduğuna dair bir yorum yapar. Ve CC patronuna (tercihen toplu halde). Birim testleriniz var mı? Eğer öyleyse, bu dev sürecinin bozulduğu anlamına gelir, böylelikle böcek. Tüm harici sistemlerle sürekli otomatik entegrasyon testiniz var mı? Sonra dev süreci, böylece böcek bozuldu. İnsan hatalarına izin vermemek için, üretimdeki her ortamı senaryo aracılığıyla özdeşleştirebiliyor musunuz? Sonra dev süreci, böylece böcek bozuldu. Bir geliştirici korkunç mu? O zaman işe alım kriterleri kötüdür, dolayısıyla patronun suçu. Günün 12 saati çalıştıkları için tüm geliştiriciler dinlenme eksikliği nedeniyle aptalca hatalar yapıyor mu? Sonra dev süreci bozuldu.

Bir not olarak: Her iyi gelişim yöneticisi yukarıda yazdıklarımın farkındadır. Çevik stratejiler, devin yavaşlamasının neden patron veya onun üstünlerine işaret ettiğini belirtmek içindir: Bak, zamanımızı düzelten hataların% 50'sini harcıyoruz. Onları azaltmak için stratejilere göz atalım, böylece zamanın% 40'ını sabitleyen hataları harcayabiliriz ve sonra bu sorunu% 30'a kadar tekrar gözden geçirebiliriz. vb.

Maalesef saha yüzünden iyi bir menajerin yokmuş gibi geliyor. Bu yüzden (1) yapmayı ve bunu yöneticiye getirmemeyi öneririm (çıkış görüşmeniz hariç)

Patronunuzda derin bir yazılım anlayışı yok gibi görünüyor ve belki de niyetinde değildir. Bu yüzden farklı bir dili, farklı bir kültürü var.

Böyle bir problem için bir işten ayrılmak, bir çözüm için öne çıkmaya çalışmaktan önce bile sadece bir pes etmek. Bırakma bırakmadır. Birbirinizi asla anlayamayacağınızdan emin olana kadar istifa etmeyin. Bundan emin olmak için önce denemelisin.

Dilimizi bilmediğinden ve patron olduğu için, buradaki ilk adım onunla kendi dilinde konuşmaya çalışmak olacaktır. Dil ile ne demek istiyorum? Birlikte düşünelim:

İnsanları yazılımlıyoruz, çoğumuz yaptığımız işi seviyoruz, yaptıklarımızla derin bir bağlantımız var. Aksi taktirde işe yaramaz ve kişi bu işte çok fazla sevmeden ya da tamam olmadan uzun süre devam edemez ... boşlukları dolduruyorsunuz ...

Ancak, işleri çok farklı görüyor. Her hata raporunda, birçoğumuz işin daha iyi çalışmasını sağlamak için heyecanlanırken (hayır, bazen çok stresli olsa bile, sorunları seviyoruz, sadece itiraf etmeliyiz!), Bir başarısızlık, varlık ölçüsü olarak görüyor. başarısız. Anlaması gereken ilk şey, böceklerin iyi olduğudur. Hatalar müşterilerin şirketi sevmesini sağlar. (Şimdi bu onun dilidir) Bir müşteri bir hata bildirdiğinde veya kendimizi bulduğumuzda, çözüldükten sonra, hiç olmadığı durumdan çok daha iyidir. Hatalar müşteri sadakatini yaratır (ben ciddiyim!), Hatalar tüketici ile yazılımın üreticisi arasındaki iletişim için harika bir bahane yaratır.

"Hata kârını artırmak" için, hata raporlarını daha da açık hale getirmeyi teklif etmelisiniz. Her hata raporunda ve hızlı, temiz, iyi çözümünde müşteriler "vay, bu adamlar harika! Gerçekten çok çalışıyorlar. Çözdükleri şeylere bakın. Çözdükleri şeylere bakın. Yazılımın bu kadar karmaşık olduğunu bile bilmiyorduk." şey!" filan filan ve filan ...

Hamleni yap, onun dilinde konuş. Hatalar bir yazılım şirketi için harika, sorun değil. Bizi geçim ettiriyorlar.

Takım etiği, verimlilik veya yapacağınız her türlü konuşma için istediğiniz şekilde çalışabilir. Eğer istifa etmek istersen, "aha, çözümüm ilk günden itibaren çalışmaya başladı! Kötü linkler ortaya çıkmadan önce kendiliğinden düşmeye başladı!" Diye düşünecektir. Şirketteki kötü çocukları bulma fikrine inanıyor ve onu başka türlü ikna etmek çok zor. Özellikle o kötü çocuklardan biri olabileceğin zaman!

Bu yüzden asıl problemine odaklan: Hatalar Ona böceklerin çok faydalı olabileceğini göster. Herhangi bir sorun olmadan, ilişki sıkıcıdır. Seni öldürmeyen her şey seni güçlendirir. Her hata, müşteri mutluluğunu artırmak için kullanabileceğiniz harika bir fırsat.

Bu söyleyebileceğin tek şey. Endişelerini düşünün ve listenize eklemek için başka birçok şey bulacaksınız. ALTIN ​​ANAHTARI fikri ile savaşmak yerine alternatif bir şey sunmaktır!

Çevik yapıyorsanız ve özellikler / hikayeler yorumundan gibisiniz . Suçlu kişi böcek arasından kaçmasına izin QA kişi, veya içinde böcek olan tamamlandı olarak özellik / hikaye kabul Ürün Sahibi / Müşteri olurdu.

Gün içinde dizgi yaptım, işte benim üstümde.

Bu, yazım hataları ve bir prova okuyucunun bulması gereken, ancak kaçırması gereken diğer şeyler için yazı dizisini suçlamak gibidir. Dizici hatalı yazım hatası yaptı, ancak düzeltici bunu kaçırdı, bu nedenle ilk önce hatayı yapan kişiyi değil , yazdırmayı yapan hatayı suçlamak için düzelticidir .

Çevik bir ortamda, QA kişisinin hataları (böcekleri) yakalama sorumluluğu ve doğru olmayan şeyleri kabul etmemesi Ürün Sahiplerinin sorumluluğundadır. Bu, geliştiricileri yayınlanacak şeylerden izole etmesi gereken iki düzey kanıt okuyucusudur; bu, bir şeyin Çevik bir ortamda böcek olarak sınıflandırılması gereken tek yoldur .

Sanırım yöneticiniz bir sorunu yanlış bir çözümle çözmeye çalışıyor. Bence belki de çok fazla hatanın serbest kalması ve yöneticinizin geliştiricilerin yazdıkları koda karşı daha fazla sahiplik ve sorumluluk almalarını istediği bir sorun var.

Test odaklı bir geliştirme kullanmak ve sürekli bir entegrasyon sunucusu ( Jenkins gibi ) ayarlamak, bu sorunu "suçlama oyunu" lanse etmeden çözmenize yardımcı olacaktır. Bunun için sürekli bir entegrasyon sunucusu önemlidir, çünkü birisi "yapıyı bozan" bir kod yazdığında, suçlanacak kişiyi gösteren takıma bir e-posta gönderilir. Bu kod bir üretim ortamına bırakılmadığından, bu tür bir suçlama daha proaktif ve cesaretlendiricidir (ve eğlencelidir!).

Sonuç olarak, geliştiriciler daha fazla sahiplik alacak, kendinden emin olacak ve üretim kodunda daha az hata olacak.

Tek bir kişinin hatasının üretime son vermesine neden olması durumunda, metodolojinizde veya her şeyden önce yazılım geliştirme biçiminizde bir sorun olduğunu belirtin. Üretime geçmenin önlenmesinin tüm ekibin sorumluluğunda olduğuna dikkat edin.

Bu iki argümandan birini kullanarak, patronunuzu “kimi suçlayacaksınız” alanını tek bir seçim alanı olarak almanın yanıltıcı olacağını; ve bu nedenle, "kimi suçlayacak" alanının çoktan seçmeli bir alan olduğundan emin olmak gereklidir. Bunu başardıktan sonra, her böcek için herkesin adının sahada olduğundan emin olun. Patronunuz nihayetinde sahadaki herhangi bir raporlamanın boşuna olduğunu görecektir.

Patrona biraz kredi vermek için, "suçlama ataması" kavramı zaten SVN gibi araçlara dönüştürüldü ve verinin uygun kullanımı, hata ayıklama sırasında "kiminle konuşacağını bulma" konusunda geliştiriciler için yapıcı olabilir, örneğin: http: / /www.codinghorror.com/blog/2007/11/who-wrote-this-crap.html

Gnat'ın bir Kök Sebep alanının iyi bir şey olduğu konusundaki tepkisine katılıyorum , ancak bu aynı bilgi değil, etkilenen kaynak için önceki geliştirici adlarını bazen atamak için bazen alanın "denormalize edilmesi" ve bazen teknik açıklama (örneğin "10000 kullanıcıya ölçeklendirilmedi") suları kirletecektir. Bir Kök Neden Tutmayı Savunurdumaçıkça açıkça teknik bir tanım (örneğin, net bir programcı hatası olsa bile, "fooData = 999 olduğunda IndexOutOfRange İstisnası" gibi ayrıntıları yakalasın) Bu, potansiyel olarak gözden geçirildiğinde bazı yararlı geri bildirimler sağlayabilir ve bazı düzeltici eylemlerin alınmasına izin verebilir mimari veya çerçeve değişiklikleriyle tüm sorun sınıflarını çözmek için (örneğin, özel konteyner sınıflarını iyileştirmek, üst düzey istisna teslimi)

Buna göre, bir Kişiyi Suç Alanına açıkça eklenmesi , yönetimin en sık kodları kıran bireysel geliştiricileri ayırmak ve cezalandırmak istediği bir yazılım ekibine çok kötü bir mesaj ve yıkıcı bir mesaj gönderebileceğini söyledi. Müdürün bu kamu denetiminin, geliştiricilerin bu "utanç duvarı" ndaki isimlerini almaktan kaçınmak için daha dikkatli ve öz düzenlemeye neden olacağına inanıyor ve geliştiricilerin bu durumdan neden özellikle tehdit edildiğini düşündüğünü anlamıyor genel olarak her hata raporuna.

Bunu bir hata alanı / potansiyel ölçüm olarak eklemekle ilgili sorunların numaralandırılması kolaydır:

1. Hataların çözülmesinde zorluk oldukça değişkendir ve hata sayımı / geliştiricisinin basit bir istatistiği bunu yansıtmayacaktır.
2. Geliştiriciler "" "" "" "" "" "yeteneklerinde oldukça değişkendir
3. Pek çok yazılım sistemi, yeniden kaplamaya ihtiyaç duyan bileşenlere sahiptir, ancak eski bileşenleri yeniden düzenleme (özellikle eski tabanda / sınırlı ünite test tesisleri yoksa) başlangıçta hatalar doğuracaktır. Geliştiricilerin bu "iyi" aktiviteden caydırılması muhtemeldir, eğer yeni hataların üretilmesiyle ilgili bir damgalanma / korku varsa (bunlar çözülmesi önemsiz olsa ve sonuçta sistemde büyük bir iyileşme olsa bile).
4. Test edenler, aynı konuyla ilgili oldukça değişken bir hata sayısı verebilir ve daha ayrıntılı bir analiz yapılmadıkça, çarpık hata sayıları / geliştiricisi ile sonuçlanabilir.

Bu sadece buzdağının görünen kısmı. Bunları, hangi API davranışının beklendiği, testlerde hatalı beklenen sonuçların ve "zincirin önceki bölümlerinde" kimin yanlış / eksik gereklilikleri ortaya koyduğunu umduğunu gösteren parmak izi ile birleştirin ve bunun gibi bir metriğin değerli olarak mahkum olduğu açık olmalıdır (aksi takdirde) Amaç morali bozmak ve toplu göçlere neden olmaktır.)

Patron bakış açısına göre, art arda kodları kıran geliştiriciler olup olmadığını öğrenmek ve bu konuda bir şeyler (umarım yapıcı) yapmaya çalışmak ister. Bu bilgileri hata raporlarına bir alan ekleyerek almaya çalışmak, yukarıda listelenen nedenlerle anlamlı bilgiler sağlamayacaktır. Tecrübelerime göre, bu bilgiler ekiple bağlantıya sokularak, takım toplantılarının çoğuna katılarak, arada sırada yapılan toplantılarda öğrenilen bilgileri ekip üyeleriyle bir araya getirerek ve alt sistemler ile tanışarak öğrenilebilir. kod (kodu okuyamasalar bile)

Salla gitsin. Patronunuz kendi başına bir soruna neden olduğunu keşfedecektir, eğer öyleyse.

Künt olalım, senin bir fikrin var, o da öyle. O senin menajerin ve onun kazandığı fikir.

Evet bu konuda savaşa gidebilirsin, ama buna gerçekten değer mi? Kullanılmadığı düşmeden 3 aydan fazla sürdüğünden şüpheliyim.

Ancak, bunu aktif olarak sabote etmek ya da çığlık atmak, bu fazladan izin, bir sonraki zam, terfi ya da gerçekten kritik bir tasarım kararının ne zaman alınacağını sormak için daha iyi tasarruf sağlayan politik sermayeyi kullanır.

O anda, gerçekten önemli olduğu zaman, patronun “suçlanacak kişi” fikrini aktif olarak sabote eden kişi olduğunuzu hatırlamasını istemezsiniz.

Karara saygı duymasanız bile ofise saygı gösterin.

Çok daha uzun sürecek kararlar için stresi ve masa vuruşlarını kaydedin.

Patronuna, bir takımda gelişmenin sosyal becerilere ihtiyacı olduğunu söyle. Başını bile sallayabilir.

Ancak sorun şu ki, bunun geliştiricilerin aşırı derecede kötü olduğu bir şey. Suçlamayı öneren araçlar eklemek, uygun problem analizinden daha önemlidir.

Bunun yerine, sosyal becerileri geliştirmek için teşviklere ihtiyacınız var ve sahip olduğunuz iletişim altyapısı bunu desteklemeli. Örneğin, olumlu bir şekilde işaretleyin: Biletten sorumlu olan ve onunla ilgilenen bir kişi adlandırın.

Ayrıca kod incelemeleriyle başlayın, böylece birbirinizden öğrenebilirsiniz. Bu daha sonra suçlamaları yedekler.

Ona bu SO sorusunu e-postayla gönder. Eğer akla açıksa, buradaki yorumlar akıl yürütmesine ilişkin akıl sağlığı kontrolleri sağlayacaktır. Makul değilse, onu mantıklı nedenlerle ikna etme ihtimaliniz yoktur. Ek olarak, bir konuşmanın dışındaki nedenleri de okuyabilir (bu, bir konuşma sıcağında “doğru olma” motivasyonu nedeniyle bazen daha ikna edici olabilir).

Ayrıca tersine çevirmeyi deneyebilirsin. Alan "benzer bir hatanın oluşmasını önlemek için olası adımlar" veya bu etkiye kısa bir süre olabilir. Daha sonra çözümleri toparlayabilir ve iş yerinizi daha iyi hale getirmek için hangilerini uygulayacağınıza oy verebilirsiniz. Belki de çözüm odaklı bir yaklaşım daha üretkendir ve muhtemelen daha iyi karşılanmaktadır (önerilerin gözden geçirilmesiyle ilgili gerçek bir takip var olması şartıyla).

Burada iki olasılık görüyorum: Hata yapan insanları cezalandırmak istiyor ya da henüz düşünmemiş. Herkese yönelik algının, hata yapanları cezalandırmak niyetinde olacağını bilmesini sağlayın. Ona teşvik etmek istediği kültür olup olmadığını sorun.

Patronum, hata izleme şablonumuza bir "Suçlayacak Kişi" alanı eklemenin hesap verebilirliği artıracağına karar verdi

Tecrübelerime göre, yönetim "insanları daha hesap verebilir kılmak" istediğinde, kastettikleri, başarısızlıktan tam olarak ceza alabilmeleridir. Fakir oyuncuları kovmak ya da sadece yıllık maaş incelemesinde çürümelerine izin vermek ("Özür dilerim, Bob, senin suçun olarak işaretlenmiş 17 böcek vardı ve bu da 15 'in sınırını aşıyor"), ceza.

Muhtemelen "Ah, hayır, istemiyoruz" diyecek, o zaman ona bu verilerin nasıl kullanılacağını sor. Kullanmayacağınız sürece veritabanına veri noktaları eklemediğinizi hatırlatın. Belirli bir kritere mi ("Rapor oluşturucu alt sistemdeki tüm açık hataları göster") seçmek istiyor mu? böcek "), böylece ölüm sonrası analiz yapabilirsiniz. İnsanların kamusal olarak aşağılanabileceği bir tür başarısızlık kurulu öngörüyor mu?

Peki hangisini hedefliyor? "Bob'un suçu olan bütün böcekleri göster" diyebilmeyi istiyor mu? Neden? Yoksa "Çoğu zaman kimin suçlu olduğunu göster bana" diyebilmeyi mi istiyor? Neden? Birincisi anlamlı değil, ikincisi ise sadece cezalandırıcı. Veya üçüncü seçenek, gerçek bir sebebi olmamasıdır.

Yeteneklerini geliştirmek için yardıma ihtiyacı olan takımdaki programcıları arayabileceği ihtimalinin olduğunu itiraf ediyorum. Öyleyse, parmakla işaret etme kültürü oluşturmayan bu bilgileri yakalamanın daha iyi yolları vardır.

Burada izlenecek en önemli husus iletişimdeki takımın 'patron' ve diğer tarafa doğru ne kadar açık olduğuna inanıyorum. Bununla birlikte, parmakla işaretleme, yönetim açısından, geliştiricilerinizden biri birkaç kez aynı konuya girerse, adım atmak ve bu tekrarlayan sorunun üstesinden gelmesine yardım etmeyi denemek için zaman alabilir (örneğin, John düzgün test etmiyor). Kod: Son 3 aydaki 3 üretim hatası, ona bir kontrol listesi verelim, böylece kodunun nasıl olması gerektiğini ve nasıl test etmesi gerektiğini hatırlar).

Gelişme bakış açısına göre, 'suçlama' zaten SVN gibi bir ana araca dahil edildi, bu yüzden "John, lütfen yazdığın pisliği düzelt" ve yanına bir isim koyma konusunda hiçbir zarar görmüyorum o. JIRA ayrıca bir hata verdiğinizde bir kişinin adını da içerir (ancak alanın sorumlusu için gerçekten bir önemi yoktur, birileri tarafından düzeltilmesi yeterlidir).

İşte bir şey var, yukarıda birçokları tarafından bahsedildiği gibi, eğer bir hata ortaya çıkarsa, bu paylaşılan bir sorumluluktur: geliştiriciden, test uzmanlarından QA'ya, yöneticilerden. Patronunuz bir noktadan öfkeli bir müşteriyi telefonla " Çok üzgünüm, John bunu hiç doğru düzgün test etmedi " gibi şeylerle tutarsa , o zaman kesinlikle başka bir iş ararım. İyi bir patron "buna dikkat edeceğiz" demeli. İsim yok, parmakla işaret yok, sadece çözümler var.

Yine, bunun tamamen iletişim ile ilgili olduğuna inanıyorum. Belki de patronunuzun yapmak istediği tek şey, dev ekipte kimin sıkıntı yaşadığını veya ekibin ne tür problemler yaşadığını (belki de eğitim seansları için mi?) Görmek, ama tam olarak onun arkasında ne olduğunu bulacağınızı sanmıyorum. Patronunuzla ve tüm ekibinizle konuşmuyorsanız, karar (ya da daha iyisi, biz posterleri / okuyucuları söyleriz).