Proje Sonrası Toplantı Zaman Kaybı mı?

İş yerimde, bazı ciddi büyüyen acıları yaşadık. 3 ila 10 kişilik bir geliştirme ekibinden gittik ve geçtiğimiz yıl şirketin kendisi% 30 büyüdü. Çoğu ölçümle iyi gidiyoruz. Ne yazık ki, yazılımımızın kalitesi acı çekti.

Bugün bölüm müdürümle yaptığım bir toplantıda, ürün piyasaya sürüldükten bir veya iki gün sonra bir proje ekibi teklif ettim. Bütçe endişelerini, kapsamını, neyin yanlış gittiğini ve neyin doğru gittiğini tartışabiliriz. İdeal olarak, hatalarımızdan ders almak. Diğer insanlar için siteler / uygulamalar oluşturuyoruz, bu nedenle zamanımız ya faturalandırılamaz durumda faturalandırılabilir. Bunun gibi bir toplantı ikincisinin altına düşer.

Yöneticim neredeyse hemen onu vurdu: "Bu zaman faturalandırılabilir değil. Bu konu hakkında konuşarak zamanımızı boşa harcadığımız için başka bir projeye geçmemizi sağlayacak." Bu mantıktan ötürü nöbetçi kalmıştım, onunla savaşmayı bile zahmet etmedim.

Öyleyse benim sorum: Değeri proje sonrası toplantılar, ama görmüyorum. Var mı belgelenmiş uzun (veya kısa) vadede zamandan ve paradan tasarruf yardımcı sonrası proje toplantıları kanıtını? Sezgisel olacağını düşünüyorum / olacağını, ancak açıkça orada olması gereken 5 kişiden az miktarda faturalandırılamaz zaman hakkında endişeli.

Geriye Bakış, İleriye Bakış , fikrin belgelenmiş kanıtına yakın olacaktır. Proje Sonrası: Sürekli İyileştirme için Değerli Bir Araç bunun hakkında bir blog yazısı olacaktır.

Mortem Sonrası Sanatı fikri ile ilgili şu noktaya sahiptir:

Mortem Post'un kökenleri, bu tür bir süreci rutin olarak ön saflardaki insanları sorgulamak için kullanan orduyla birliktedir. Ancak yönetim uygulaması yüksek performanslı, öğrenen herhangi bir organizasyon için çok önemlidir.

Yöneticiniz Teknik Borç kavramını anlamıyor .

Proje sonrası toplantılar bir maliyettir, bir yatırımdır. Onları böyle satmak zorundasın. Herhangi bir toplantının amacı , uzun vadede nasıl para biriktirileceği ve şirketin hedeflerine ulaşma konusunda fikir alışverişinde bulunmaktır .

Yöneticiniz bir menajer çünkü bu uzun vadeli hedeflerle ilgileniyor. Bu yüzden benim görüşüme göre iki olası gerçek var: menajeriniz tüm kontrolü kendi için istiyor, yoksa menajeriniz işini yapmıyor. Şirketin işleri "doğru şekilde yapma" ve kendi başarısına yatırım yapma geçmişi ve felsefesi varsa, konuyu yöneticinizin üstünde tutmayı düşünün.

Bu, esasen , sadece askeri değil, birçok farklı bağlamda özellikle yararlı olan bir eylem sonrası gözden geçirmedir.

Benim kendi gelişim döngüm, hem bir sonraki yinelemede ya da projede ne yapılması gerektiğini ve bir önceki projede daha iyi ne yapılabileceğini analiz etmeyi içerir. Bir proje bir süre rafa bırakılsa bile, üzerinde çalışılacak şeylerin bir listesi olması raftan çıktığında (ya da arkadan çalışan ...) yardımcı olur ve yine aktif bir projedir. Bir dahaki sefere dokunduğumda, ne yapmam gerektiğini incelemek için fazla zaman harcamak zorunda değilim.

Ek olarak, bir projeyi gözden geçirip benim veya başkalarının uyguladığı temiz hileleri bularak bunlar yayılır ve bir sonraki proje veya bir sonraki yineleme çok daha iyidir. (Yinelemeler konusunda sıkça düşündüğüm için sürpriz olmayabilir.)

Bunun değeri basit bir mantık ve doğası gereği açıktır. Önceki projelerinizdeki hatalarınızdan asla bir şey öğrenmezseniz, gelecekteki projelerinizde nasıl gelişebilirsiniz?

Özel olarak dokümantasyon olmasa da, sürecin gözden geçirilmesi (tamamlanma sırasında veya sonrasında), özellikle CMMI ve Lean 6 Sigma gibi bildiğim standart tabanlı kalite kontrol sistemlerinin hemen hemen önemli bir bileşenidir.

Belki de bunu bir zorunluluk değil, gönüllü olarak bir öğle yemeği toplantısında yapılan bir şey veya başka bir şey olarak önerebilirsin? Muhtemelen, geliştirme ekibinizin çok azının yeni şeyler denemek ve denemek için istekli olacağı iyi ... bu yüzden en azından birincisini sallarsan, sonuçlar kendileri için konuşacak.

Yöneticiniz bütçe baskısı altında olabilir. Kısa sürede 3 ila 10 geliştiriciyi genişletirken bu büyük bir endişe olmalı. Durum buysa, şu an için sadece ölüm sonrası toplantıları atlamak ve birkaç ay içinde tekrar önermek iyi bir fikirdir, umarım ki acil bütçe sorunları bu kadar acil olmayacaktır.

Kalitenin acı çekmesinin bir nedeni, 10 kişi arasındaki iletişimin 3 kişi arasındaki iletişimden çok daha büyük bir problem olmasıdır: 3! << 10! Muhtemelen bir süreliğine olduğu gibi karışabilseniz de, nihayetinde, geliştiriciler arasında daha iyi bir iletişim kurmak için bazı değişiklikler yapmanız ve orijinal 3 geliştiricinin kurduğu ilkelere uyulduğundan emin olmanız gerekecektir. daha yeni millet ve yeni büyük grubunuzda iyi çalışması için güncellendi. Proje ölüm sonrası toplantıları bunu yapmanın bir yoludur; periyodik kod incelemeleri başka bir şeydir. Ölüm sonrası toplantıların, tıptan üretime kadar endüstrilerde kalite geliştirmenin kritik bir parçası olduğunu belirtmek acı vermez.

Yöneticinizin, geliştirme ekibini, sadece ek insanları işe alarak genişletebileceğine inandığını hayal etmek zor. Eğitim ve takım oluşturma konusunda kesinlikle bazı yatırımlar yapılmalı; Bu olmadan, kuruluşun kendi ağırlığı altında çökecek. Kısa bir süre beklerseniz, kuruluşunuz doğrudan zayıf iletişim ile ilişkilendirilebilecek bazı somut problemler yaşamaya başlayabilir. Bu noktada, yöneticiniz muhtemelen şöyle diyecektir: "Herkesi aynı sayfaya almalıyız! Tüm geliştiricilerle bir toplantı planlayın!" Ve eğer yardım edecek gibi görünüyorsa, muhtemelen şöyle diyecektir: "Bunu her projeden sonra yapmalıyız!" ;-)

Öyleyse sabırlı olun ama ısrarcı olun.

Bu eğilimi yakalayacağım: Yöneticiye katılıyorum.

Proje sonrası değerlendirmeleri büyük ölçüde anlamsız buldum çünkü ortaya çıkan sorunları düzeltmek için çok şey yapmak için çok geç.

En çok tavsiye edeceğim şey , proje sırasında yapılan periyodik retrospektifler . Ayda bir veya iki kez, ekibin neyin iyi gittiğini, neyin iyi olmadığını; ne daha fazlasını, daha az ne yapmalı. Bunu yapın proje süresince hemen önerileri uygulamak ve nasıl çalıştıkları iyi görebilmesi için.

Toplantının uyumsuzluğuna bak. Proje sonrası toplantıların çoğu konuşmacıdır ve yöneticiniz desteklememekte kesinlikle haklıdır.

Sizleri toplantıya yönetmeye davet edin (başkanlık yapmasını veya ılımlı olmasını isteyin), gündemi yayınlayın ve özel sonuçları alın. Bir yönetici olarak, toplantıdaki değeri görebilir.

Kullanıyoruz ve ben de Bono'nun "6 Düşünce Şapkası" inceleme sürecini öneriyorum ( bakınız Wikipidia ). Sonuç, toplantının öğrenilen en önemli hata olduğu tespit ettiği birkaç (2 veya 3) eylem noktasıdır. İlk birkaç kez başlangıç ​​bloklarından çıkmakta zorlanıyoruz, ama bir kez alıştıktan sonra geri dönmeyecek.

Proje sonrası inceleme yapılmaması, önceki projede yaptığınız aynı hataları yapmanıza yol açar.