Takım Hızlandırma Artışı Özellik Hızını Artırır mı?
Yayınlanan: 2020-03-28Yayın hızını artırmak için ekipleri hızlandırırken en önemli unsurlardan biri, netliğin ürün ekiplerinden sprint ekiplerine aktarılmasıdır.
Sorunsuz bir sprint uygulaması, hem üründen hem de sprint ekiplerinden gelen kayda değer katkıların sonucudur.
'İlk seferde doğru (FTR)' felsefesi, tüm ekip üyelerinin ortak bir hedefe uyum sağlamasına yardımcı olur
Startup'lar erkenden büyüme aşamasına geçtiğinde, öncelikleri önemli ölçüde değişir. Diğerlerinin yanı sıra, özellik hızı bir öncelik olarak öne çıkıyor ve büyüme arayışlarında çok önemli bir rol oynuyor.
Çalıştığım ve yakın zamanda A serisini yükselten tohumla finanse edilen bir girişimin kurucusu, altı ay içinde yeni işlevleri piyasaya sürmek için mühendislik ekibini ikiye katlamamı istedi. Ancak, döngü süresini azaltmada tek ilgili faktör bu mu? Cevap olarak, bu yaygın 'yanlış anlama'nın ardındaki göz ardı edilen yönleri ele almaya karar verdim.
Kaynak kapasitesi, üretime sık sık salımları yönlendiren kritik faktörlerden biri olsa da, bu tek başına döngü süresinin azalmasını garanti edemez. 16'dan fazla girişim için ürün üretirken, erkenden büyüme aşamasına birçok kez geçişe tanık oldum. Bu deneyimden yola çıkarak, başlangıç kurucularının dikkate alması için paylaştığım bazı önemli faktörler burada.
Netliği Aktarın: Yukarıdan Aşağıya Temel
Ekipleri serbest bırakma hızını artırmak için hızlandırırken en önemli unsurlardan biri, netliğin ürün ekiplerinden sprint ekiplerine aktarılmasıdır. Bir sprint belirsizlikle başladığında veya başlamak için yeterli hikayeye sahip olmadığında, sprint teslim oranı olumsuz etkilenir. Belirsiz tanımlanmış hikayeler veya görevlerin sprint ortası dahil edilmesi, hızı yavaşlatır, bunun sonucunda sprint ekipleri planlandığı gibi teslim edemez.
Sorunsuz bir sprint uygulaması, hem üründen hem de sprint ekiplerinden gelen kayda değer katkıların sonucudur. Ürün ekibi, en azından çeyrek için yol haritasını hazırlayarak ve sprint ekibiyle paylaşarak, ekibin çıktılarını buna göre planlayabilmesi için üzerine düşeni yapabilir.
Öte yandan, sprint ekibi, ürün takımını bir ürün biriktirme listesi almaya zorlamaya devam etmeli ve odaklanmış teslimatı sağlamak için haftalık/iki haftada bir düzeltmelidir.
'Hatasız' Yayınlamak için Otomatikleştirin
“Verimlilik, işleri doğru yapmaktır; etkililik, doğru şeyleri yapmaktır.” - Peter Drucker
Otomasyonu düşündüğünüzde, ikinci kategoriye bir örnektir. Özellik geliştirmenin hız kazandığı an, doğru süreçler uygulanmadıkça üretimin çökmesi büyük olasılıktır. Ürün, yeni özellik geliştirmelerinin üstesinden gelebilecek kadar kararlı değilse, ekibiniz yeni özellikler oluşturmaktan çok sorunları düzeltmek için zaman harcar. Sonuç olarak, mühendislik hızınız düşer.
İşte burada CI/CD (sürekli entegrasyon ve sürekli dağıtım) devreye giriyor. Burada, kapsamlı birim, entegrasyon ve otomasyon testi kapsamı, gönderilenlerin sistemi bozmamasını sağlar.
Sizin için tavsiye edilen:
RBI'nin Hesap Toplayıcı Çerçevesi Hindistan'da Fintech'i Dönüştürmek İçin Nasıl Ayarlandı?
Girişimciler 'Jugaad' Yoluyla Sürdürülebilir, Ölçeklenebilir Girişimler Yaratamaz: Cit...
Metaverse Hindistan Otomobil Endüstrisini Nasıl Dönüştürecek?
Anti-Profiteing Hükmü Hintli Startuplar İçin Ne Anlama Geliyor?
Edtech Startup'ları Hindistan'ın İşgücünün Becerilerini Geliştirmesine ve Geleceğe Hazır Olmasına Nasıl Yardımcı Oluyor?
Bu Hafta Yeni Çağ Teknoloji Hisseleri: Zomato'nun Sorunları Devam Ediyor, EaseMyTrip Gönderileri Stro...
Sadece Daha Fazla İnşa Etmeyin, Yoksa Daha Fazla Kırarsınız
Yeniden işleme büyük bir üretkenlik katilidir ve belirsiz şekilde tanımlanmış hikayeler, geliştirme testi eksikliği, test kapsamı eksikliği vb. gibi çeşitli faktörlerin bir sonucu olabilir. Yeniden çalışma, QA mühendislerinin test ve gerileme, geliştiricilerin hata ayıklama ve serbest bırakma yöneticilerinin yeniden yayınlamadaki zamanını ve çabalarını tüketeceği için üretkenliği azaltabilir.
Biraz yavaşlamak, ekibinizin daha hızlı sonuç vermesine ve değer katmasına yardımcı olabilir, çünkü etkili hız her zaman sadece hızdan çok daha faydalıdır.
'İlk seferde doğru (FTR)' felsefesi, tüm ekip üyelerinin ortak bir hedefe uyum sağlamasına yardımcı olur - ilk seferde sağlam ve istikrarlı kod sunar. Acele edip yeniden çalışmaya takılmak yerine kodun kalitesini belirlemek için fazladan zaman harcamak her zaman sağlıklıdır.
FTR oranını iyileştirmenin denenmiş ve test edilmiş yollarından bazıları, düzenli birikmiş iş yığını düzeltmesi, hikayelerin tekrarı, ürün yöneticisine düzenli demolardır. Sadece gereksinimleri toplamak yerine, sprint ekibi FTR oranını iyileştirmek için bunları açıklamaya daha fazla odaklanmalıdır.
Paralel Sprintler İçin Takımınızı Yapılandırın
Girişiminiz küçük bir ürün ekibine sahip olduğunda, herkes aynı anda bir veya iki özellik üzerinde çalışır (genellikle 4-6 kişilik bir ekip için geçerlidir). Bununla birlikte, birden fazla özellik sunma beklentisi arttıkça, farklı odak alanlarına sahip birden çok alt ekip oluşturmanız şiddetle tavsiye edilir. Bu şekilde, her alt takım sprintini çalıştırır ve yol haritasını tanımlar.
Büyük bir takımla karşılaştırıldığında, bir 'mantıksal ayrım' çerçevesinden doğan daha küçük takımlar daha etkilidir ve daha iyi sonuçlar verir. Mikro hizmetler, farklı ürün grupları ve çeşitli bileşenler için bireysel ekipler, 'mantıksal ayırma' yaklaşımının birkaç örneği arasındadır.
Yeniden yapılanma sırasında, DNA'yı korumak için bu alt ekiplerin her birine önceki çekirdek ekipten en az bir üyenin dahil edilmesi her zaman esastır. Teslimatlar için ekipler arası koordinasyon ek bir ek yük gerektirse de, bu haklı bir ödünleşimdir.
Hızla Birlikte Özellik Kullanımını Takip Edin
Kullanıcı deneyimi, yeni bir özellik sürümünün başarısını ölçmek için en hayati ölçüttür. Hızla birden fazla özelliği sunmaya başladığınızda, kullanıcı deneyimi genellikle arka planda kalır. Ürününüz sınırlı özelliklere sahip olduğunda, kullanıcı etkileşimi düzgün ve kesintisiz bir eğri olmaya devam eder.
Ancak, yeni özellikler yayınlamaya başladığınızda, kullanıcıların bunalma ve deneyimlerinin etkilenme olasılığı yüksektir.
Kullanıcıların daha iyi benimsenmesini sağlamak için, özellik hızıyla birlikte kullanıcı etkileşimini izlemek, ileriye dönük en iyi yol olmaya devam ediyor. Kapsamlı kullanıcı araştırması kanıtlanmış bir yol olsa da, diğer önemli olanlar, her yeni sürümden sonra özellik bayrakları, AB testi ve kullanıcı yolculuğunun izlenmesi (genlik veya benzer analiz araçları aracılığıyla) aracılığıyla başlangıçta seçilen kullanıcılara sunuluyor.
Çekirdek Üyelerinizi Kaybetmeyin
Bu çok yaygın olarak göz ardı edilen bir husus olabilir, ancak çok önemli bir husus olarak sağlam duruyor. Küçük ekiplerin süreçlere ihtiyacı yoktur ve çevik bir yapıya sahiptir ve herkesin sesi duyulur. Bu ekipler süreçlerin kurulduğu ve yeni mühendislik ve fonksiyonel üyelerin eklendiği bir duruma geçtiğinde, kaostan kaçınmanın tek yolu sağlıklı yönetimdir.
Mühendislik ekibiniz başarılı bir şekilde ölçeklenirken, mühendislik ekibini sürekli beslemek için iyi yetenekli bir ürün ekibi şarttır. Ekip üyelerinin önemli bir işi olmadığında, ancak hiçbir girişim çekirdek üyelerini kaybetmek istemediğinde bir kayıp kaçınılmaz hale gelir. Bu durumda insanlarla iyi ilişkiler kurmanın ve dinamikleri iyi anlamanın anahtarı üst yönetimdedir.
Burada paylaştığım bilgiler, yıllar içinde birden fazla startup ile edindiğim deneyimlerden alınmıştır. Halihazırda elinde çok şey olan startup kurucuları için tekerleği yeniden icat etmeyecek şekilde faydalı olmasını bekliyorum.