Ekibimin süreçleri kontrol dışı mı?

Yazılım geliştirici ekip lideriyim (yakın zamanda yeni bir ekibin kontrolünü ele aldım) ve sonuçta yüksek verimlilik, kaliteli ve organize öncelikleri korumaktan sorumluyum.

Ekibimde 6 üst düzey geliştirici var, ancak işler burada bir karmaşa gibi hissediyorum. Durum şudur: Şirketimizde yaklaşık 10 farklı iletişim noktasından JIRA talepleri ile uğraşmak zorundayım ve hepsi farklı iş birimlerini veya müşterileri temsil ediyor.

Benim sorunum, işimin ağırlıklı olarak bütün gün yangın söndürmek ve herkesin sorunlarının üzerinde çalışılmasını sağlamaktan ibaret olmasıdır. Ne yazık ki, şirketimizdeki kültür yüksek verimlilik (hızlı sürümler) ancak düşük kalite (üretim hataları) olmuştur ve müşterilerimiz sonuçlarda ani bir gecikmeyi kabul etmeyecektir.

Bunu ele almanın iyi yolları nelerdir? Tonlarca teorim var, ama benim gibi bir durumda gerçekten iş deneyimi olan birinden cevap arıyorum.

İşte işlerin nasıl çalıştığının küçük bir listesi:

• Her geliştirici, belirli bir uygulama ve onunla etkileşen hizmetlerden sorumludur;
• Sürümler tipik olarak istemci tarafından simüle edilmiş bir üretim sunucusunda test edilir ve ardından canlı sunucuya dağıtılır;
• Her uygulama toplam 8 uygulama olmak üzere ortalama 50-80 kişi tarafından kullanılmaktadır.

Teşekkürler

Müşterilerimiz sonuçlarda ani bir gecikmeyi kabul etmeyecek

O zaman aldıkları kalitesizliği kabul etmek zorundalar.

Ne var (! Ya da başka bir üretim): Aceleye kalitesini etkilediğini Bunu değiştirmek için yapılacak yazılım geliştirme realitesini kabul etmek müşterilerinize olsun.

Yanlış giden şeylerin, kırılan şeylerin, şikayet ettikleri zamanların büyük bir listesini oluşturun. Onlara bu sorunların nedenini açıklayın ve bunu değiştirmek için ne yapmak istediğinizi söyleyin. Onlara ekibinizin canlı uygulamaları desteklemeye ve düzeltmeye harcadıkları sürenin yüzdesini açıkladığınızdan emin olun. Bununla ilgili veri toplamıyorsanız, şimdi başlama zamanıdır (ve bilgileri istemcilere sunmadan önce bir ay boyunca toplayın).

Bir odadaki kilit paydaşları alın ve “X'in sabit olmasını mı istiyorsunuz, yoksa Y'nin dağıtılmasını mı istiyorsunuz? Sadece ikisinden biri için zamanımız var.” Deyin. Make onları öncelikleri belirlemekle sorumlu ve kapasitesi sınırlı olduğu açıkça anlaşılmalıdır. Yeni bir şey isterlerse, onlara ulaşmak için mevcut yol haritalarından ne feda etmek istediklerini sorun.

Ekibinize "işleri düzeltmek için ne zaman ve kaynak" gerektiğini (hem temel hataları düzeltmek hem de kod kalitesi / mimarisi / vb. Gibi daha büyük sorunları düzeltmek için) sorun. Bu öğeleri, paydaşlarınızın öncelik vermesi gereken şeyler listesine ekleyin.

Şu anki işimde yaptığım en iyi şey, aynı anda bir odaya ilk 8 paydaşı almak ve talep edilen yeni özellikleri temsil eden 16 dizin kartı yığını hazırlamaktı. Masadan geri adım attım ve "Bunlardan birini bir defada teslim edebiliriz. Onları hangi sırayla istiyorsun?" Dedim. Onları tartışmaya edelim birbirinden yerine ortasında sıkışmış olma iş önceliği bitti.

Dur, bırak ve yuvarlan. Yangınlar yakıta ihtiyaç duyar ve genellikle panik şeklinde gelir. Kendinizi ve ekibinizi sırayla yönetmek için zaman ayırın. Geliştiricilerinizi değerlendirin ve yeterince becerikli olmayan ve / veya istediğiniz sonuçları elde etmek için yeterince çalışmayan herhangi birine sahip olup olmadığınızı görün. Kimin kalacağına karar verin (ve onları tutmak için çaba gösterin), kimin biraz itmeye ihtiyacı var, gerisi gitmek zorunda. Programcılarınızın işlerini yapabildiklerinden emin olmak için aldıkları destek ve araçları değerlendirin. Ses testi, inceleme, kaynak kontrolü ve belgelerin takip edildiğinden emin olun. İyi araçlara sahip iyi insanların iyi işler yapabilmeleri için hesap verebilir olmaları gerekir.

Ekibinizin ne yapması gerektiğini, şu anda üzerinde çalıştığını ve ne zaman tamamlanmasını beklediğini bilmek için bir sistem olmalı. Bunu yapmak için birçok yöntem, teori, yazılım, kuru silme panoları ve yapışkan notlar, belgeler ve e-posta. Herkesin ona yapışmasını sağlayarak bir şeylerin işe yaramasını sağlayın. Herkesin sisteme bir girişi varsa, onu takip etmek için daha fazla teşvik vardır.

Müşterilerin neler beklediğini daha iyi anlayın. Bu işinizin bir parçası olmayabilir. Saçlarının yanıyormuş gibi davrandığı, müşterileri mutsuz ve gökyüzü düştüğü başka kişiler de olabilir. Yaptıkları şey bu ve bazıları gerçekten çok iyi. Eğer her şey bir acil durumsa, hiçbir şey bir acil durum değildir, çünkü hepsi yapılmayacaktır. Müşterilerle tartışmalara oturmayı teklif edin. Pek çok 'iyi niyetli' şeylerin dev ekibine ulaştıklarında 'anlaşma kırıcılarına' dönüştüğünü göreceksiniz. Yardım etmek için teknik irtibat kişisi veya başka bir mazeret olun. Tutamayacağınız sözler vermek, ilk etapta duymak istemediklerini anlatmaktan daha kötüdür. İyi bir iş yapmak istiyoruz, bu yüzden 5 değil, 8 haftaya ihtiyacımız var. Uzun vadede daha mutlu olacaklar.

Sonuçta, müşterilerinizi yazılım geliştirme konusunda eğitmeniz ve mümkün olduğunca sürece dahil etmeniz gerekir. Şu anda gördükleri, yeni özelliklerin hızlı bir şekilde sunulması, aynı zamanda yazılımdaki hataların da hızlı bir şekilde sunulmasıdır. Birincisi ile mutlu olurken, ikincisi ile mutlu olmazlar (ya da olmamalıdırlar).

Onlara, daha iyi süreçlerle, yeni yazılımın sunulmasının kısa bir süre geciktirileceğini, daha az hata olacağını (asla sıfır olmayacağını) açıklamanız gerekir. İlerlemenin bu yolu olduğu konusunda anlaşmaya varırsanız, gelişiminiz üzerinde kontrolü yeniden kazanmak için ihtiyaç duyduğunuz süreçleri tanıtmaya başlayabilirsiniz.

Agile sürecini kullanmak, müşterinin ekibin bir parçası olarak dahil edildiğini öne sürdükleri (ve bazı uygulama görevlerinde) burada yardımcı olabilir. Müşterileri çok yakından dahil ederseniz, neyin işe yarayıp neyin ilk elden üretilebileceğini göreceklerdir.

Benim (sınırlı deneyim) düşüncem: Çözülmesi gereken iki sorun olduğunu düşünüyorum. İlk olarak, kalite süreci. Arada scrum / şelale / bir şey kullanıyor musunuz? Scrum'da her hikaye için ek görevler ekleyebilirsiniz: 1 bir test senaryosu / planı, diğeri onu çalıştırmak, diğeri kod incelemesi için vb.

Diğer sorun, yazılımın her yerinde var olan büyük ana sorundur. Beklentileri yönetmek. Yani X'i yapmak için bir düğmeye ihtiyaç duyduklarını söyleyen birinden teslim edilmesine kadar geçen süreyi arttırmak.

Sürece fazladan adımlar ekleyebilir ve bu konuda büyük bir tanıtım duyurusu yapabilirseniz [şimdi bu kalite sürecini uyguluyoruz: bu, hataları düzeltmek için daha az zaman anlamına gelecektir! ve daha kaliteli sonuçlar! büyük e-posta / toplantı vb. Hataları düzeltmek için daha az zaman = özellikleri uygulamak ve test etmek için daha fazla zaman.

Müşteriler sonuçlarda ani bir gecikmeyi kabul etmiyor mu? Hemen hemen yapmak zorundalar. Olduğu gibi devam edemeyeceği açıktır. Belki ekstra KG adımları ekleyebilir ve daha sonra ihtiyaç duymanız halinde daha fazla ekip üyesi ekleyebilirsiniz? Ancak kalite adımları kesinlikle gereklidir.

Scrum veya benzeri bir şey kullanırsanız, düzenli bir sonuç teslimi için bir haftalık bir sprint hedefleyebilirsiniz. Bu, insanları hızlı bir geri dönüş kadar rahatlatacaktır.

Umarım bir dereceye kadar yardımcı olur .. umarım bu noktayı kaçırmadım.

Açıkladığınız şey çok normal ve hiç de endişe verici değil.

• Müşteriler genellikle mühendislerden neyin önemli olduğu konusunda farklı bir zihniyete sahiptir. İşlerin doğru olmasını seviyoruz, ancak müşteriler saflık üzerinde dakikliği ödüllendiren bir gerçekle karşı karşıya. Rekabetçi olabilmek için problemlerinin hızlı bir şekilde çözülmesi gerekiyor ve tam da size bunun için ödeme yapıyorlar.
• Öncelikleri belirlemek, bir kişinin tek başına yönetmesi için çok büyük ve tüylüdür, önemli sorunların bir birikimine sahip olmak (yani JIRA kullanıyorsunuz), her bir ilgi alanını yöneten teğmenler, önemli çalışmaları ön planda tutmak için sahip olduğumuz en iyi seçenektir. program.

Endişelenecek bir şey yok. Bununla birlikte, yönetim görevlerinin çoğunu, ödeme yapan müşteriye mümkün olduğunca kaydırarak, öncelikleri belirleme geliştirme sürecine dahil ederek ve teknolojiye kadar, rutinin çoğunu otomatikleştirerek kendinizi çok fazla acıdan kurtarabilirsiniz. mümkün.