Braze Ürün Ekibini Yeniden Yapılandırma

Herhangi bir yazılım ürününün arkasındaki en önemli itici güç, onu oluşturan insan grubu ve bunların birbirleriyle olan ilişkileridir. Bu nedenle, ekipleri mümkün olduğunca fazla kaldıraç ve etkiye sahip olacak şekilde düzenlemek önemlidir.

Braze'de, ürün ve mühendislik organizasyonumuzun nasıl tasarlandığını kapsamlı bir şekilde düşündük ve özelliklere öncelik verme, ekip uzmanlığını geliştirme ve ürünümüzü daha verimli bir şekilde oluşturma şeklimizi büyük ölçüde iyileştirmemize yardımcı olan büyük bir departman yeniden organizasyonundan öğrendiklerimizi paylaşmak istiyoruz.

Erken Yapı: Ürün/Pazar Uyumu ve Ötesi

Ürün/pazar uyumunu bulmak ve bunu bir işi büyütmek için kullanmak, tüm startup'ların geçmesi gereken bir potadır. Bir girişimin gelişimindeki bu aşama boyunca, deneme hızı ve fırsatlardan hızla yararlanma yeteneği kritik öneme sahiptir. Bu amaçla, orijinal ürün ekibi yapımız şöyle görünüyordu:

Ekibimizi işlevsel özelliklere göre bölen bu yapı, çeşitli nedenlerle iyi çalıştı.

Birincisi, ürün/pazar uyumuna giden yolda dönüşümsel ürün değişiklikleriyle etkin bir şekilde başa çıkmamızı sağladı; uzmanlar kod tabanımızın büyük alanlarına sahip olabilir ve en rahat oldukları dilleri, çerçeveleri ve tasarım kararlarını kullanabilirler. Muazzam miktarda kafeinle beslenen, tek ordudan oluşan proje "ekipleri" düzenli olarak büyük çabalar harcadılar. Bunlar, müşteriye yönelik genel API'mizi oluşturmayı ve tüm mesaj gönderme altyapımızı elden geçirmeyi, genellikle tek mühendis, ürün yöneticisi ve tasarımcı rolünü doldurmayı içeriyordu. Bu tür aşırı önlemler büyük bir şirket için çılgınlık olabilir, ancak erken büyüme sırasında gerekli ve neredeyse rutindir.

Ayrıca bu yapı, sadece 10-15 kişilik bir ekiple belirli teknik alanlarda derin bir ustalık kazanmamıza yardımcı oldu. Temel ürünlerimizin pek çok unsuru - örneğin ön uç modelimizin model-görünüm-denetleyici katmanı, API'ler ve yüksek verimli mesaj gönderme kodu - yalnızca birkaç kişi tarafından tam olarak anlaşıldı.

O zamanlar basitti ve ihtiyacımız olan tek şeydi. Hız her şey olduğunda, basit yönergelere göre düzenleme, bilişsel yükü azaltmaya yardımcı oldu ve dikkatimizi en iyi yapabileceği yere odaklamamızı sağladı.

Sonraki Yapı: Büyüme ve Ölçekleme

Ancak ekibimiz 30-40'ı geçtikçe bu yapı bozulmaya başladı. Sonuç olarak, ürün ekibimizin yeniden düzenlenmesini en büyük zorluklarımızdan bazılarına çözüm olarak belirledik. Stratejik projeler için ekipler oluşturmak için beceri setleri ve zaman çizelgeleri arasında denge kurmak için sürdürülemez bir çaba harcıyorduk. Ayrıca, önceliklendirme için aşırı miktarda zaman harcadık ve teknolojiye dayalı ekip yapımız doğrudan en temel ürün gereksinimleriyle eşleşmediğinden, kendimizi iş genelinde tüm ürün önceliklerini zorunlu olarak sıralarken bulduk. Ve son olarak, ekip üyelerinin belirli müşteri kullanım durumlarıyla ilgili derin deneyim geliştirmeleri için çok az fırsatımız oldu.

Sonunda, Spotify tarafından popüler hale getirilen Squad/Tribe modeline benzer, Çevik çapraz fonksiyonel ekipler etrafında yapılandırılmış bir organizasyona geçtik. Yeni kuruluş yapımız şuna benziyor:

Ekibimizin çoğunluğu, ürün veya işimizin önemli bir alanına karşılık gelen "ürün dikeyleri" içinde çalışır. Örneğin:

• E-posta ve Kurumsal ekibimiz, E-postayı yukarıdan aşağıya ve ayrıca en büyük müşterilerimizin çoğu için kritik olan izin yönetimi gibi belirli ürün alanlarını çalıştırır.
• Mesajlaşma ve Otomasyon ekibimiz, kullanıcı segmentasyonu, mesajlaşma ve amiral gemisi orkestrasyon ürünümüz Canvas ile ilgili çeşitli ürün alanlarına sahiptir.

Bir sektör içinde, her bir sektör belirli bir müşteri ihtiyaçlarına karşılık geldiğinden, önceliklendirmenin (nispeten) basit olmasını bekleriz. Görsel Tasarım, DevOps ve Altyapı Mühendisliği gruplarımız gibi belirli ekipler, tüm platforma yayılarak kilit alanlarda tutarlılık oluşturur.

Etkiler

Yeniden yapılanmamız, ekipler arası bağımlılıkları önemli ölçüde azalttı. Daha önce, belirli bir zamanda belirli bir projeye özel beceri setlerinin (mühendislik, tasarım, ürün yönetimi, vb.) doğru dengesini yerleştirmeye yönelik Sudoku benzeri zamanlama problemi ile mücadele ediyorduk. Aynı zamanda kısa vadeli teşvikleri de uyumlu hale getirdi – geçişten önce ekipler kendilerini genellikle birbiriyle alakasız hedefleri hedefleyen karşı taraflara güvenirken buldu. Yeni yapımızla, ürün ekipleri bağımsızdır, zaman çizelgeleri üzerinde çok daha fazla kontrole sahiptir ve hedeflere tam olarak uyum sağlayarak üretkenliği ve morali artırır.

Yeni kuruluş tasarımı, önceliklendirmeyi de iyileştirdi. Örneğin, E-posta ve Kurumsal ekibimiz, e-posta altyapımızı yükseltmek, temel bir e-posta özelliği oluşturmak veya bir kurumsal kullanılabilirlik sorununu çözmek arasında karar verme ihtiyacı duyabilir; bu, üçü de müşterilerimizin ihtiyaçlarıyla benzer şekilde ilişkili olduğundan, basit ve kolayca ölçülebilir bir karardır. .

Çok fazla yüksek öncelikli ihtiyaçla mücadele eden bir ekip, aynı zamanda ürün alanlarının daha fazla kaynağa ihtiyaç duyduğunun bir göstergesidir. Bu, zorlu önceliklendirme sorunlarını, hala zorlu ancak kavramsal olarak ele alınması kolay olan personel ihtiyaçları olarak yeniden çerçevelendirmemizi sağlar.

Son olarak, çoğu ekibin belirli bir ürün alanına odaklanması, bireylerin zaman içinde derin uzmanlık ve son derece verimli çalışma ilişkileri kurmasına olanak sağlamıştır. Başlangıçta, inşanın ilk birkaç yılında, bireyler esasen tüm ürünü ve kod tabanını kafalarında tutabiliyorlardı, ancak biz büyüdükçe bu imkansız hale geldi. Ürün sorunları fraktaldır: Her daha yakından baktığınızda daha fazla nüans ve derinlik bulursunuz. Sonuç olarak, bir ürünün veya kod tabanının belirli bir alanında saatler harcamak ve iş ihtiyaçlarını derinlemesine anlamak, gerçek ürün atılımlarına ulaşmanın en iyi yollarından biridir. Ek olarak, odaklanmış uzun vadeli ekipler oluşturmak, sahiplik ve uyum sağlar ve tutarlı bir işbirlikçi grubu arasında konuşulmayan çalışma ilişkilerinin gelişmesini sağlar.

Elbette hiçbir sistem mükemmel değildir. Ürün odaklı sütunlara odaklanarak, ekiplerin bütünsel öncelikler pahasına yerelleştirilmiş ihtiyaçlar için optimize etme potansiyelini artırdık. Örneğin, küresel sorunlar yerine (“ön uç çerçevemizi değiştirmek genel mühendislik hızını artıracaktır”) yerelleştirilmiş teknoloji borcuna (“bu denetleyici hantaldır”) odaklanılabilir. Bu ihtiyacı öngörerek, yukarıda bahsedilen kesişen ekipleri oluşturmak için adımlar attık ve diğer geniş projeler için özel komiteler kullandık - örneğin, ön uç bileşenler ve tasarım modellerinden oluşan bütünsel bir ürün/tasarım sistemi oluşturmak için bir komite .

Yeni yapımız ayrıca bütünsel, dönüşümsel ürün değişiklikleri için daha yüksek aktivasyon enerjisi getiriyor. Arka uç API'lerimiz gibi ürünümüzün bazı alanları, birkaç ekibin ortak mülkiyetindedir. Kod tabanımızın geniş, kesişen alanlarında kapsamlı değişiklikler yapma eşiği daha yüksektir, bu nedenle bu tür yapı, ürününüzün iskeleti büyük ölçüde oluşturulduktan sonra en iyi sonucu verir.

paket servisler

Genel olarak, yeniden tasarlanmış ürün organizasyon yapımızdan memnunuz: Ekip bağımlılıkları, önceliklendirme ve uzun vadeli ürün uzmanlığı oluşturma konusundaki zorluklarımızı çözdük veya büyük ölçüde geliştirdik ve ayrıca nasıl ölçekleneceğimize dair yardımcı bir yol haritamız var. Özellikle şunu öğrendik:

• Bağımlılıkları kaldırmak ve teşvikleri hizalamak, büyük verimlilik kazanımlarına yol açar.
• Elmalar arası önceliklendirme hem daha basit hem de daha etkilidir.
• Belirli bir müşteri veya iş ihtiyacındaki derin uzmanlık, daha iyi ürün sonuçlarına yol açar.
• Uzun bir süre boyunca aynı ekip üyeleriyle çalışmak, harika iş ilişkileri kurmak için çok önemlidir.

Bu yapıyı, belirli temel özellikleri paylaşan herhangi bir ekip için tavsiye ederim: ürün yöneticileri, tasarımcılar ve mühendisler gibi işlevsel uzmanların eşit paydaşlar olduğu işlevler arası bir organizasyon; birleşik ürün geliştirme ekibinde kabaca 15-20'den fazla kişi; ve en önemlisi, sağlam ürün-pazar uyumu. Ve bu tür bir ekip yapısı size çekici geliyorsa, işe alıyoruz!