Çevikliğe Yolculuk: Braze Yazılım Proje Yönetim Sürecini Nasıl Yeniden Düşündü?

Yayınlanan: 2019-02-19

Braze'i inşa etmek için ilk beş yılı resmi proje yönetimi yolunda fazla bir şey olmadan geçirdik. Muazzam miktarda iş yapmak için tasarım belgeleri, Trello, elektronik tablolar, buluşsal yöntemler, en iyi uygulamalar ve çok sayıda toplantı kullandık. Hiçbir proje birbirinin aynısı değildi - bazıları mevcut durumu kafasında tutan bir ordu tarafından yürütülürken, diğerleri pratik olarak bireysel taahhütlere kadar titizlikle belgelendi. Her şey yeterince iyi çalıştı... ta ki çalışmayana kadar.

2018'in başlarında, bazı temel sorunların olduğuna dair açık işaretler görmeye başladık:

  • Aynı anda uçuşta çok fazla proje var.
  • Yapı döngüsünün sonlarında değişen çok fazla gereksinim var.
  • Diğer insanların ne üzerinde çalıştığına dair çok az şeffaflık.
  • Projeleri nasıl yönetecekleri ve işleri nasıl düzgün bir şekilde parçalayacakları konusunda insanlara koçluk yapmak için çok fazla zaman harcandı.

Bunların hepsi, birbirine bağlı, önemli konulardan oluşan bir ağın parçasıydı. Projelerin nasıl önceliklendirildiği, ne zaman üzerinde çalışıldığı ve neyin inşa edilmesi beklendiği belirsizdi. Sorun olabildiğince temeldi: nasıl çalışırız? Yazılım projelerini yönetme şeklimizi temelden değiştirmenin zamanı gelmişti.

Plan Yapmak

Biraz düşündükten sonra mühendislik ekipleri için denenmiş ve gerçek bir metodolojiye doğru ilerlemeye karar verdik - daha Çevik olmak istediğimize karar verdik.

Bu yeni zorluğa yaklaşmak için, tüm ürün ve mühendislik organizasyonumuzun bilgisini temsil edecek ve bunlardan yararlanacak bir grubu bir araya getirmek istedik - bu nedenle ürün yönetimi, tasarım ve mühendisliği temsil eden sekiz üyeden oluşan bir komite oluşturduk. Hem yöneticileri hem de bireysel olarak katkıda bulunanları ve ayrıca farklı seviyelerde Çevik geçmişe, kıdeme ve deneyime sahip kişileri dahil ettik.

Bizim adlandırdığımız şekliyle bu Çevik Komite, duruma birkaç temel ilkeyi kesin olarak göz önünde bulundurarak yaklaştı:

  • Hem metodolojiler hem de yazılımlar arasında mümkün olduğunca kanıtlanmış çözümleri kullanmak istedik. Benzersiz olmak çok çaba gerektirir ve biz sadece gerekli ve stratejik alanlarda benzersiz olmak istedik. Ayrıca, insanların işlerini yönetme konusunda Google'ın en iyi uygulamalarından yararlanabilmelerini ya da daha da iyisi, insanların Braze'e katılmasını zaten çoğunlukla nasıl yapacaklarını bilmelerini istedik.
  • Braze genelindeki ürün mühendisliği ekiplerinin, aynı dili konuşabilmek değerli olduğu için, nasıl çalıştıkları konusunda büyük ölçüde tutarlı olmasını istedik.
  • Hiçbir şeyi dogmatik olarak ya da iyice düşünmeden yapmak istemedik. Sadece bir yöntem seçip kitabına uymak yeterince iyi değildi; Sağduyu ve düşünceli yinelemenin güne hükmetmesi bizim için önemliydi.

Bu yönergelerle donanmış olarak, birçok kuruluş için etkili olduğu kanıtlanmış bir Çevik çerçeve olan Scrum'ı kullanmaya karar verdik. Yaygın olarak bilinir, ölçeklenebilirdir ve Çevik bir süreç uygulamak istediğinizde güvenli, varsayılan seçimdir.

Daha sonra iki ana kararla karşı karşıya kaldık: (1) yeni sürecimizi desteklemek için hangi araçları kullanmalıyız ve (2) değişiklikleri sürecimizde nasıl uygulamaya koymalıyız. Birkaç yazılım parçası hakkında konuştuk, değerlendirdik ve demosunu yaptık ve sonuçta Atlassian'ın Jira'sı bizim için doğru seçim olduğunu kanıtladı. Bu kendini kanıtlamış bir çözüm, ekibimizdeki birçok kişi zaten bunu kullanma deneyimine sahipti ve Braze içindeki diğer ekipler zaten kullanıyordu ve hepimiz tek bir sistem içinde çalıştığımız için daha iyi ekipler arası işbirliği için bir fırsat yarattı.

Agile için bir dağıtım planı seçmeye gelince, vermemiz gereken birkaç önemli karar vardı. İlk olarak, takımı nasıl eğitiriz/etkinleştiririz? Çevik bir koç tutabilir, ekipte deneyimli kişilerin diğerlerini eğitme işini yapmasını sağlayabilir veya yardımcı olacak danışmanlar bulabiliriz. İkincisi, Agile konusunda biraz deneyimi olan mühendislik içindeki ekipleri uygulamadan önce eğitimi bekletmeli miyiz?

Sonunda, Jira ve Scrum'a aşina olan ekiplerin kendilerini hissettikleri ölçüde başlamalarına izin vermeye karar verdik ve kuruluş çapında geçişe yardımcı olması için bir danışman tuttuk. Geçiş boyunca ekip üyelerine koçluk yapmaktan öncelikli olarak ekibimizde veya bağımsız bir oyuncunun sorumlu olmasıyla ilgilenmedik, çünkü:

  • Herhangi bir takımın Agile'ı nasıl yaptığımıza sahip olmasını istemedik ve eğitimin daha iyi karşılanacağını ve üçüncü bir taraftan gelirse önerilerin daha kapsayıcı olacağını hissettik.
  • Bir danışmanlık işinin bireysel bir Agile koçundan daha istikrarlı ve daha güvenilir olacağını düşündük
  • Tüm mühendislik organizasyonu için temel bir eğitim almak ve organizasyondaki bireylerin Agile hakkında sahip olduğu bilgiler hakkında herhangi bir varsayımda bulunmadan başlamak istedik.
  • Son olarak, organizasyonumuzdaki herkesin ileriye dönük süreci sürdürmekten sorumlu olduğunu açıkça belirtmek için koçların belirli bir noktada ayrılmasını istedik.

Birçok kuruluş için etkinliği kanıtlanmış bir Çevik çerçeve olan Scrum'ı kullanmaya karar verdik. Yaygın olarak bilinir, ölçeklenebilirdir ve Çevik bir süreç uygulamak istediğinizde güvenli, varsayılan seçimdir.


Brian Wheeler
Başkan Yardımcısı, Braze'de Ürün Mühendisliği

Planın Yürütülmesi

Birkaç aylık planlamadan sonra, yapmayı düşündüğümüz her şeyi ayrıntılı olarak anlatan büyük bir belgemiz oldu ve geri bildirim için bunu kuruluşla paylaştık. Ardından, birkaç satıcıyı değerlendirdikten sonra, Agile yolculuğunda bizimle ortak olması için Eliassen'i seçtik. Bu yolculuk, Eliassen tarafından yürütülen iki günlük bir Agile eğitimi ile başladı ve ardından Eliassen'in bizimle bağlantı kurduğu bir uzmandan üç aylık Agile koçluğu aldı.

Başından beri Jira ve Scrum'a geçmek konusunda oldukça temkinliydik. Hem internet hem de ekibimizin kişisel deneyimleri, aşırı dogmatik yaklaşımların tehlikeleri, Jira'nın nasıl bir “anti-kalıp” olarak işlev görebileceği ve Scrum'ın organizasyonlarda ters gidebileceği tüm yollar hakkında uyarıcı hikayelerle doluydu. Danıştığımız kişiler tarafından, bu değişikliklerin büyük olasılıkla zaman alacağı ve Agile'ın gerçek faydalarını görmeden önce artan sancıların olabileceği konusunda yoğun bir şekilde uyarılmıştık.

Neyse ki yeni süreçte anında değer bulduk. Bu geçişle ilgili güzel şeylerden biri, Scrum'ın herhangi bir yönünü körü körüne takip etmek için hiçbir zaman herhangi bir baskı hissetmememizdir; işlerin daha iyi yürümesini sağlamak için, her birkaç haftada bir işlerin nasıl gittiğine dair bir geriye dönük bakış yapardık ve sonra değiştirilmesi gerekenleri değiştirirdik. Ve üç aylık koçluk boyunca, mühendislik organizasyonunda kapsamlı değişiklikler uyguladık:

  • Herkes kullanıcı hikayelerini yazmayı, düzeltmeyi, işaretlemeyi, parçalamayı ve almayı öğrendi
  • Standup'lar, eldeki işi bitirmeye geldiğinde yenilenmiş bir odak buldu
  • Ürün, Tasarım ve Mühendisliğin tümü aynı dilleri konuşmayı öğrendi ve arayüzler giderek daha iyi tasarlandı

Sonuçlar

Şimdi bu kabaca altı aylık çabanın diğer tarafında olduğumuza göre, değişiklikler açık ve dramatik. Bu çabaya yol açan konularda önemli bir azalma gördük. Agile ile artık imzalama, işbirliği, biriktirme listesi oluşturma ve bakım için net ve anlaşılması kolay mekaniklere sahibiz ve nelerin iyileştirileceği konusunda düzenli olarak geriye dönük çalışmalar yapıyoruz.

Ayrıca, tasarım ürünleri için önemli ölçüde daha tutarlı konumlara ve belirli bir proje için gerçekten "yapılanın" ne olduğuna ilişkin daha iyi hizalanmış beklentilere sahibiz. Diğer ekiplerin ne üzerinde çalıştığını görmek kolaylaştı ve insanların birlikte nasıl iyi çalışacağını anlaması her zamankinden daha kolay.

Bu geçişin sonunda fark ettiğim bir şey, daha fazlasını yapıyor ve ekibimizin boyutunu büyütüyor olsak bile, herhangi bir zamanda kuruluştaki toplam açık çekme isteklerinin azalmasıydı. Daha küçük artışlarla çalışarak ve işleri bitirmeye odaklanarak, uçuştaki öğelerin sayısı önemli ölçüde azaldı.

Kuruluşumuzda elde ettiğimiz başarı, başkalarına da ilham verdi. Braze'deki diğer departmanlardaki ekiplerin kendi Çevik dönüşümlerini başlattığını görmeye başlıyoruz, bu nedenle yakında daha fazla insan aynı dili konuşacak ve işbirliğini tanımlamak ve geliştirmek için ihtiyaç duydukları araçlara sahip olacak.

paket servisler

Çalışmamızın iki ana unsuru başarısını sağladı.

Birincisi, bir temsili komite tarafından yürütülüyor olması, mühendislik organizasyonunun çevresinden ve çeşitli farklı bakış açılarından girdi elde etmek için gerekliydi. Şirket genelinde, insanlar günlük işlerini etkileyecek bir konu hakkında duyulduklarını ve temsil edildiklerini hissettiler. Ekiple paylaşılabilecek bir Çevik geçiş için motivasyonları ve planları ortaya koyan kapsamlı bir belgenin daha sonra oluşturulması da oldukça faydalı oldu. Kararların nasıl alındığını göstermeye ve geri bildirim için net yollar sunmaya inanıyoruz - çünkü bu bağlam sağlar ve geri bildirimde bulunulacak bir yapı oluşturur.

İkincisi, ekibimize koçluk yapması için üçüncü bir taraf bulma kararı çok önemliydi. Objektif, deneyimli bir ortağa sahip olmak, sürecimizde hızla çok sayıda iyileştirme yapmamızı sağladı. Antrenörümüz iyiliğin nasıl göründüğünü biliyordu ve önyargısız tavsiyelerde bulunabildi, birkaç kez “Takımlar normalde nasıl X yapar?” Diye sorabildik. ve hemen uygulanabilir bir çözüm elde edin. Öte yandan, iç kaynakları kullansaydık, aldığımız geri bildirimin taraflı bir taraftan gelmesi ve mevcut sorumluluklarla kaynak çekişmesini artırma riskini alırdık.

Başka bir şey?

Ürünümüz hakkında nasıl düşündüğümüz ve onu yapmak için yapılan çalışmalar hakkında daha fazla bilgi edinmek istiyorsanız Building Braze'e göz atın. Ekibimize katılmayı düşünür müsünüz? Güncel iş ilanlarımıza göz atın.