Günlük raporlar geliştiricinin verimliliğini azaltabilir mi? [kapalı]

Başka bir soruda , geliştiricilerin neden günlük scrum'u sevmeyebileceğini sordum . Geliştiricilerle konuştuk ve bir süre günlük scrum tutmamaya karar verdik (ilk denememizde denemek ve özelleştirilmiş scrum vermek için). Bu, doğrudan geliştiricilere danışmanın ürünüdür.

Öte yandan, geliştiricileri her gün koordine etme veya Anahtar Performans Göstergesi gibi işin ilerlemesini erken yapma şansı gibi günlük scrum'un iyi kısımlarını kaybetmek istemiyoruz.

Günlük scrum'a alternatif olarak, geliştiricilerden aşağıdaki koşulları içeren günlük raporlar sunmalarını istemeyi düşünüyoruz:

1. Herhangi bir formatı takip etmeye gerek yok. Her biçim kabul edilir.
2. İş yapılmasa bile ilerleme miktarını duymak istiyoruz.
3. Her görev için harcanan zamanı belirtmeye gerek yoktur.
4. Kalkınma engelleri ve koordinasyon gerekliliklerinden bahsedilmelidir.
5. Günlük raporlara takıntılı olmanıza gerek yok. O kadar katı değil.

Bunun üretkenliklerini düşürebileceğini düşünüyor musunuz? Günlük rapor deneyiminiz oldu mu? Mikro yönetici olmadığımızdan emin olabilmemiz için bize herhangi bir öneriniz var mı?

Günlük scrum'a alternatif olarak, geliştiricilerden aşağıdaki koşulları içeren günlük raporlar sunmalarını istemeyi düşünüyoruz:

Ne korkunç bir fikir.

Bunun üretkenliklerini düşürebileceğini düşünüyor musunuz?

Evet.

Neden? Bir toplantıda sözlü sunum, yazmayı ve n kişiyi raporu "okuyan" bir eşzamanlı etkinlikte birleştirir. Konuşma artı Dinleme. Bitti ve bitti. Sorular hemen cevaplandı.

Bir rapor yazmak zaman kaybıdır çünkü sorular olacaktır ve raporu (a) soruları olan ve (b) gerçekten okumamış olan kişilerle gözden geçirmeniz gerekecektir.

Günlük raporlar okunmayacak. Hızlı bir şekilde kutu içi gürültüye dönüşürler.

"Günlük raporlara takıntılı olmanıza gerek yok". Hangi durumda, neden yapıyorlar?

Mikro yönetici olmadığımızdan emin olabilmemiz için bize herhangi bir öneriniz var mı?

Evet. Günlük ayağa kalkın. Birkaç dakika sürer ve işiniz bitti.

Günlük ayağa kalkmanız birkaç (15?) Dakikadan fazla sürüyorsa, çok fazla ayrıntı paylaşıyorsunuz ve bu ayrıntılar için ayrı toplantılar planlamanız gerekiyor. Günlük stand-up yapmak kolaydır. 2 dakikalık bir özetin ardından, her şey muhtemelen tüm ekip için değil, ayrıntılardır ve bir takip toplantısına aktarılması gerekir. Toplantı, bir sonraki kişinin o günkü odağına geçer.

Bunları geçmişte yaptım, ama sabahın aksine günün sonunda. Doldurulması genellikle beş dakikadan az sürdü, bu nedenle hayır, bir geliştiricinin verimliliğinde nasıl bir düşüş olacağını göremiyorum. Sabah yapmanın güzel yanı, günün geri kalanı için ne yapacağınızı düşünmenizi sağlamasıydı.

Bunu söyledikten sonra ...

Bunun, bir önceki gün yaptığımızı ve o gün ne çalışacağımızı anlatmanın en etkili yöntemi olmadığını gördük. Neden? İnsanlar genellikle onları okumadılar. Bu, zamanlanmış bir Outlook göreviydi, bu yüzden herkes her gün onları gönderdi, ancak ya gözlerini kamaştırdılar ya da tamamen kaçırdılar (olası satışlar veya yönetim hariç).

İnsanlar birbirlerini dinleme eğilimindeyken günlük ayaklanmalara sahip olmanın çok daha değerli olduğunu gördük. Ayrıca, bir yanlış anlama varsa, o zaman ve orada kızardı, bu da daha fazla soru sormak için günlük durum e-postasına yanıt veren birinden daha gerçekleşme eğilimindedir.

Dürüst olmak gerekirse, herhangi birinin kısıtlama olmaksızın rapor vermesine izin vermek, denklemin liberal tarafına çok fazla görünüyor. Çalıştığım yerde bir daire çiziyoruz ve her geliştirici aşağıdakileri veriyor:

1. Önceki gün ne yapıldı. Tüm küçük detaylar değil, genel olarak.
   • Yukarıdakiler bitmezse, değilse, bitirmek için ne gerekiyor ve ne kadar süreceği.
   • Yukarıdakiler tamamlanırsa, bir sonraki görevin ne olduğu, ne yapılması gerektiği ve ne kadar zaman alacağı.
2. Engelleyiciler. Bar'a bağlı olan Foo üzerinde çalışıyorsanız ve Bar bitmemişse, bunun açıklığa kavuşturulması gerekir.

Herkesin izlemesi için genel bir şema oluşturmak, verilen bir rapordan geçmeyi kolaylaştırabilir. Herkesin günlük raporlarla bir e-posta alması için bazı yöntemleri kolayca ayarlayabilir ve böylece herkesin neler olup bittiğini öğrenmesine izin verebilirsiniz.

IMO her tür günlük toplantı / rapor üretkenliği azaltır, çünkü açıkçası mikro yönetimin kokusudur. Evet, Scrum ve benzerlerinin farkındayım ve kısa durum güncellemeleri ("Hey Proje X nasıl geliyor?") Olmaları şartıyla çok da kötü değiller, ancak profesyonel geliştiricilere sekmeleri tutmaları için hakaret olduğuna inanıyorum . bizi bu kadar düşük bir seviyede; günde 8 saat ofiste olduğumuzdan emin olmak için zaman çizelgeleri kullanmaya veya duvar olmadığından emin olmak için belirli bir zamanda hangi pencereleri açtıklarını görmek için insanların bilgisayarlarında casusluk yapabilirsiniz.

Herkesin çalıştığından emin olmak için sekmeleri tutmanız gerekiyorsa, onlara güvenmediğiniz anlamına gelir. Onlara güvenmiyorsanız, işyerinde endişelendiğinizden daha büyük bir sorun var.

Ekibim yaklaşık bir yıldır scrum yapıyor. Bundan önce, haftada iki toplantı yapıyorduk, bu sırada her ekip üyesi önceki 2-3 gün içindeki faaliyetlerini bildirdi. Her toplantı 30 dakika ile 1 saat arasında sürdü. Bilgi alışverişinde bulunmamız ve çalışmamızı koordine etmemiz gerektiğinde, sadece meslektaşlarımıza gider ve onlarla konuşurduk (tabii ki hala yapıyoruz).

Şimdi scrum yaptığımıza göre, günde bir toplantının (sadece 15 dakika sürmesine rağmen) çok fazla olduğu izlenimi veriyoruz. Çoğu zaman bazı üyelerin raporları şu şekildedir: "Dünden beri yeni bir şey yok". Sık sık haftada 2 toplantı şemasının daha etkili olduğu izlenimini edindik.

Diğer bir dezavantaj, günlük toplantının planlı bir kesinti olmasıdır (bkz. Örneğin Paul Graham'ın makalesi , 1. nokta. Dikkat dağıtıcı unsurlardan kaçının): Kesintinin geleceğini bildiğiniz için, toplantıdan önce zor bir şeye başlamayacaksınız (günlük toplantılar işe başladıktan bir buçuk saat sonra gerçekleşir).

Son fakat en az değil, erken geri bildirimin avantajları olsa da ("Ah, bu sorun üzerinde çalışıyorsunuz, tartışmalıyız!"), Ancak sadece fikirlerinizi zaten zihninizde düzenlediğinizde bir tartışmaya başlamak bazen daha etkilidir. , belirli sorularınız var ve tartışmaya hazır hissediyorsunuz. Bunun yerine, günlük raporlar hızla çok sayıda gereksiz ve yapılandırılmamış beyin fırtınasına neden olabilir. Bu nedenle, çok erken geri bildirimlere dikkat edin : sizi şaşırtabilir ve yavaşlatabilir.

Bazı durumlarda günlük raporlar üretkenliğimizi azalttı. Ortalama olarak, çalışmamızı daha etkili hale getirdiklerini düşünmüyorum.

GÜNCELLEME

Orijinal cevabımı birkaç yıl önce yazdım ve bu arada takım değiştirdim. Mevcut ekibimde, talep üzerine günlük toplantılar yapıyoruz, yani kısa bir durum güncellemesine ihtiyacımız olduğunu düşündüğümüzde. Yani, her gün böyle bir toplantı yapma imkanı var ama kimse istemezse yapmıyoruz. Haftalık geçmişe dönük bir toplantımız var. Bu temelde önceki çevik olmayan ekibimde kullandığımız yaklaşıma çok benziyor: sabit haftalık toplantılar ve haftanın geri kalanında ek talep üzerine toplantılar.

Gerçekten istediğiniz şey kaba bir durum ve herhangi bir engelleri not etmek için en iyi yol kısa bir "günlük durum e-postası" istemektir. Eğer çok fazla vurgu yaparsanız veya neleri içermesi / içermemesi gerektiğine dair bir liste yaparsanız, en azından geliştiricilerinizin bazıları gereksinimleri karşılamak için ekstra zaman harcayacaktır. Bunun yerine, basit bir e-posta isteyin. Gün boyunca işler ortaya çıktığında, "oh, gün sonunda e-postanıza koyun" gibi şeyler söyleyin ve gerçekten uzun bir gün sonu e-postası alırsanız, rasgele "her gün bu kadar ayrıntılı olmanıza gerek yok" deyin.

Herhangi bir toplantının veya raporun, özellikle de her gün herkes tarafından yapılan bir raporun amacı hakkında net olmak çok yararlıdır . Sebebini söylüyorsun:

her gün geliştiricileri koordine etme şansı elde etmek gibi günlük scrum'un iyi kısımlarını kaybetmek istemiyoruz,

Koordinat geliştiricileri ile ne demek istiyorsun ? Ne tür bir çalışma koordinasyona ihtiyaç duyar ve gerektiğinde geliştiriciler ve yöneticileri tarafından geçici olarak koordine edilmez mi? Koordinasyona ihtiyaç duyan görevleri tanımlamanın ve yalnızca bu durumlarda iletişim kurmanın bir yolu var mı?

veya erken harekete geçmek için Temel Performans Göstergesi gibi işin ilerlemesini izlemek.

Birçok iyi KPI (site yanıt süresi veya kritik hata sayısı gibi) mekanik olarak ölçülebilir olacaktır ve bunu yapmak için geliştiricilere bir maliyet yüklemenize gerek yoktur.

İşyerinde birkaç farklı formatta günlük raporlar yapmak zorunda kaldım. Genel olarak konuşursak, günlük raporların sadece yöneticiler için değer katma eğiliminde olduğunu düşünüyorum, geliştiricilerin kendileri için değil. Yöneticiler, her bir projenin genel durumunu ve her bir çalışanın görev yükünü kısa bir süre içinde anlatarak günlük raporlardan faydalanırken, tecrübelerime göre çoğu geliştirici birbirlerinin durum raporlarını okumaktan rahatsız olmaz.

Bununla birlikte, günlük raporlarınız için bir biçim zorunlu kılmamak gibi, raporları hem yöneticiler hem de diğer geliştiriciler için okunmasını ve işlenmesini zorlaştırırsınız, böylece kayıp geliştirici zamanı konusunu daha da kötüleştirirsiniz.

Geliştiricileriniz için günlük raporlarla ilerlemeye karar verirseniz, e-posta raporları yerine dahili bir wiki kullanmanızı önerebilir miyim? Bu şekilde, herkesin günlük durumlarının geçmişini korurken, insanların gelen kutularını spam yapmazsınız.

Agile yöntemlerinizi size uyacak şekilde özelleştirmek harika bir fikir - bunun için kudolar.

Bunun yerine, günlük raporlar, bunun günlük bir toplantıdan çok daha iyi olmadığını söyleyebilirim, hala aynı "bana ne yaptığını söyle" yaklaşımı, sadece herkesin bunu konuşmak yerine yazmasını sağladın.

İşte alternatif bir yaklaşım: her geliştiriciden durumlarını sormak istediğiniz bu 'yoklama' tekniklerini kullanmak yerine bunun yerine 'itme' tekniğini kullanırsınız. Geliştiricinin bildirecek fazla bir şeyi yoksa, bilmiyorlar, ancak ortaya çıkan sorunları ve ilerlemeleri rapor etmelidirler. Bu nedenle, bir modülü tamamladıklarında, biten tüm ekiplere, SCM'de, belgelerin nerede bulunabileceği ve ne olduğu, nasıl çalıştığı ve / veya nasıl kullanılacağı hakkında kısa bir özet göndereceklerdir. o. Eğer bir problemleri varsa, tavsiye, yardım veya herhangi bir ipucu için ekibe e-posta göndermeleri gerekir. (evet, tıpkı ekiplerin bugün yaşadığımız mikro yönetim olmadan iyi iletişim kurdukları eski günler gibi)

bunun çok daha üretken ve yapıcı olduğunu göreceksiniz. Onların uğruna anlamsız raporlar almayacaksınız ve herkes meslektaşlarını çalışmalarından haberdar etmeyi sevdiği için daha motive olmuş bir ekip alacaksınız.

Günlük stand-up'ları bir raporla değiştirmenin kötü bir fikir olduğunu da kabul ediyorum. Günlük bir stand-up fikir ve sorunları seslendirmek için harika bir yerdir. İyi eski beyaz tahtayı (Jira + Greenhopper ile birlikte kullandığımız) sevmemin nedenlerinden biri budur. Beyaz tahta, grubun toplanıp bilgi paylaştığı bir yer, her şey orada, her şey görünür, herkes üzerinde çalıştığı yapışkanlıkları hareket ettirir ve değiştirir, aynı zamanda çok eğlencelidir.

Bu bilgileri diğer araçlarınızdan çıkaramaz mısınız?

• Şu anda ne üzerinde çalışıyorsun? Atadığım biletler.
• İlerlemen nedir? 1 günden uzun süredir sahip olduğum biletler için bilet veya taahhüt mesajlarındaki yorumlara bakın. Kısa sürdüğüm biletler: muhtemelen yarın yapılır (5+ günlük büyük bilet yapmazsınız, evet?)
• Genel ilerleme nedir? açık / kapalı bilet oranına bakın
• Neyin organize edilmesi gerekiyor? Biletlerin Eğer durum ile geri atanmış olsun gerekli geribildirim ve her şey ekibinizin IRC, Kamp ateşi Odası, her ne tartışılmıştır.

Cevaplamak için daha spesifik sorularınız olduğunda, belirli raporlara olan ihtiyacı görüyorum, ancak bu olmadan raporlarınız kendi içinde bir son gibi görünüyor.