Bülten #25: Yeni Özellik Geliştirmek-2: Planlama (Akış)

Bültene hoş geldin 👋

Bu sayıda geçen sayı başladığımız “Yeni bir özellik geliştirmek” yazı dizisinin ikinci kısmı olan “Planlama” konusuna giriş yaptık. Konuyu “Akış” ve “Gereksinimler” temaları altında iki ayrı sayıda inceleyeceğiz ve bu sayının konusu bu yüzden “Planlamada akış”: Geliştirecek olan özelliğin hangi probleme çözüm olacağını netleştirip kapsamı da belirledikten sonra planlama süreci nasıl başlıyor, hangi metodolojiler nasıl uygulanıyor bunlar üzerine global örnekler paylaşıp, topluluk üyelerimizin de deneyimlerini aktarmaya gayret ettik.

İyi internetler,
Burcu

Hatırlatma: Üretim Bandı Slack! 🎉

Slack’te her geçen gün daha aktifiz: Podcast bölümlerini ilk elden Slack’ten duyuruyoruz, üyelerimiz de ilk elden iş ilanlarını buradan paylaşıyor. Üyelere özel buluşmalara da başladık! Ürün geliştirmeyle alakalı birçok konuda sorular sorup cevaplar alabildiğimiz bir platform olma yolundayız, soruların veya bildiğin konularda topluluğa katkı sağlayabilecek cevapların için bekliyoruz:

Slack Grubumuza Katıl

Yeni Özellik Geliştirmek-2: Planlama (Akış)

1. Planlama: Nedir? Neden önemli?

2. Planlama süreci: Akış

3. Faydalı Kaynaklar

1. Planlama: Nedir? Neden önemli?

Yeni bir özellik geliştirirken temelde yaptığımız üç şey var: Problemi/ihtiyacı/beklentiyi anlamak (Serinin “Keşif” isimli ilk sayısında bu konu üzerine kafa yormuştuk), uygun çözümü geliştirmek ve bu çözümü kullanıcılara sunmak. Aslında keşif sürecinde edindiğimiz bilgiyi uygun çözümü geliştirebilmek adına kullanmaya hazır hale getirmek için yaptığımız her şeyi planlama kapsamında değerlendirebiliriz. Planlama adımı yeni bir özellik geliştirirken izlenen süreçte en az keşif kadar önemli ve değerli; çünkü nasıl doğru probleme odaklanılmadığında çözümün bir önemi kalmıyorsa, doğru planlama yapılmadığında da keşfin bir yanı eksik kalıyor.

Çözümü geliştirmeye başlamadan önce planlama yapmak neden önemli?

• Planlama sonucunda bu yeni özelliği geliştirecek her bir ekip üyesinin payına ne düştüğünü görmesi ve takip etmesi kolaylaşıyor.

• Herkesin problemi ve çözümü doğru anladığına ve aynı şeyi anladığına emin olmak mümkün oluyor.

• Özelliği geliştirmeye başlamadan önce tüm organizasyon bu özellikten ne bekleyeceğini, özelliği geliştirecek ekibi ve detayları anlayabileceği bir çıktıya sahip olabiliyor ve geri bildirim verebiliyor.

• Organizasyondaki tüm ekiplerin aşina olduğu ve sürdürdüğü bir planlama sistemi, organizasyon ölçeklenirken olan biteni izlemeyi ve ürün kalitesini yüksek tutmayı kolaylaştırıyor.

2. Planlama süreci: Akış

Planlama konusunda biraz geriye gidelim: 2000’li yıllar öncesinde teknoloji şirketlerinde yapılan planlamalarda ilk günden kesinleştirilen ve sabit tutulan bir gereksinimler dosyası takip ediliyor, bu gereksinimlerin zaman ekseninde planladığı Gantt chart’lar oluşturuluyor ve tüm bunlar Waterfall metodolojisi çatısı altında yönetiliyordu. Değişiklik yapılması gerektiği fark edilse dahi plan dışına çıkmak mümkün görülmediğinden, geliştirme yapılırken geçen onca zamanda gelişen yeni ihtiyaçlara cevap vermeyen, ölü doğan ürünler, özellikler ortaya çıkıyordu. Tutmayan kaynak planları da cabası.

2000’ler sonrasında teknoloji ekiplerinin daha pratik planlama yöntemleri üzerine kafa yormasıyla gelen çevik yazılım geliştirme metodolojileri bu uzun dönemli, değişmez ve bölünmez planları daha kısa döngülerle, güncellenebilen ve yakın geleceğe odaklanan planlara evriltti. Şimdilerde bir özellik üzerine planlamaya başlamanın ya da planlar yaparken izlenebilecek yöntemlerin türlü türlü çeşitleri, örnek uygulamaları var. Ekipler organizasyon büyüklüğüne, iş modeline, hatta ekip üyelerinin çalışma tercihlerine göre bu yöntemlerden birini ya da birkaçını sentezleyerek seçiyor, uyguluyor, değiştiriyor ya da terk edip başka bir model denemeye geçiyor. Kanaat önderleri de bu yüzden planlama süreçleri için bu dinamik ve çevik kalma halini öneriyor: 30 kişiden 100 kişiye çıkan ya da ekip yapılarının değiştirildiği bir organizasyonda mutlaka planlamada da değişmesi gereken şeyler olacaktır.

Son dönemde gözlemlediğimiz bir yaklaşımsa organizasyonun ürün kültürüne göre takip edilebilecek planlama yöntemlerine karar vermesi, yapılacak özellik granülünde uygulanacak yöntemin ve akışın seçilmesi şeklinde. Ölçeklenmiş ve ürün odaklı teknoloji şirketleri, ürün kültürünü tüm ekiplerin benimsemesine gayret ederken onlara yol gösterici “Playbook”lar hazırlıyor ve ihtiyaca göre süreci adapte edebilmelerine izin veriyorlar.

“Playbook” konseptini uygulayan ve nasıl uyguladığını aktaran iki ürün şirketine dair blog yazılarını buraya bırakıyorum: Typeform ve Zalando.

Planlamaya başlamak (Kick-off)

Topluluk üyelerimize bir özelliği planlamaya başlamadan önce neler yaptıklarını sorduk ve şöyle cevaplar aldık:

Emrah Şamdan (Thundra, VP of Product)

Planlamanın ilk adımı CTO, Engineering Manager, ben ve benim ile birlikte çalıştığım PM arkadaşım oluyor. Aslında burada teknik feasibility işlerini temsilen CTO, resource management ı temsilen eng. manager ve ürün gerekliliklerini temsilen PM ekibi oluyor. Biz bundan öncesinde, ürünün prototip tasarımlarının hazır olduğundan ve job story’lerinin belirlenen scope kapsamında yazılmış olduğundan emin oluyoruz. Aslında daha geniş bir ekip ile bu konuları önceden konuşmuş oluyoruz. (Tasarımcı, engineer arkadaşlar). Yani aslen story’ler o zaman periyodu için ekipçe shape edilmiş oluyor ve scope’lar belirlenmiş oluyor. 

Hepsiburada ürün ekibi (Aybüke Kayacı, Product Owner – Merve Artukarslan, Product Manager – Eslem Aykutluğ, Product Owner)

Planlamaya başlamadan önce ihtiyaç veya problemi belirliyoruz. Geliştireceğimiz özelliklere bazen elimizdeki verileri anlamlandırarak, kullanıcıların potansiyel ihtiyaçlarını belirleyerek karar veriyoruz, kimi zaman da doğrudan kullanıcı geri bildirimlerinden yola çıkıyoruz. Elimizdeki KPI’ları da düzenli takip ederek bunların iyileştirilmesi üzerine yaptığımız fikir alışverişlerinden yola çıkıp, özelliğin kullanıcılara nasıl bir iyileştirme sağlayacağını netleştiriyoruz.

Öncelikle product ekibi (product owner, product lead, product manager) olarak fikir alışverişi yaparak kapsamı genel hatlarıyla belirliyoruz.

Sonrasında özelliğin nasıl geliştirileceğini ve teknik detayları tartışmak için teknik ekip (developer/data scientist) ve tech leadler ile bir araya geliyoruz. Böylece ürünü geliştiren ekip neyin neden yapıldığı konusunda fikir sahibi oluyor ve işin etkileşimi net bir şekilde anlaşılıyor. Yapılabilecekler ile ilgili karara varıp, işin yaklaşık büyüklüğünü tahminliyoruz.

Bu aşamadan sonra büyük resmi, detayları, kısıtları, akışı, metrikleri toparladığımız bir product canvas hazırlıyoruz. Özellik canlıya alındıktan sonra yaratacağı etkiyi ölçebilmek için KPI’lara karar veriyoruz ve tespit ettiğimiz data eksiklikleri varsa bunlar için ön hazırlıklar yapıyoruz. Yapılmak istenen ölçümlere göre A/B test koşulup koşulmayacağının kararını veriyoruz. A/B test yapılacak ise testin gereksinimlerini de ayrıca belirleyip feature canlıya çıkmadan önce hazırlık yapılmak üzere planlıyoruz.

Yapılacak iş farklı takımlara dokunuyorsa bunları da göz önünde bulundurarak diğer ekipler ile bir araya geliyoruz.

İhtiyaçlar belirlendikten sonra UX ekibine geliştirilecek özelliği aktarıyoruz. İşin ölçeğine göre belirlenen bir MVP varsa hem bu kapsam hem de fazlandırmayı düşündüğümüz aşamaları aktarıyoruz. Bu doğrultuda tasarım ihtiyaçları üzerine konuşarak özellik ile ilgili gerekli tasarımları alıyoruz.

Planlama süreci – yöntemler ve akış

Topluluk üyelerimizin planlama akışlarına ve uyguladıkları yöntem ve metodolojilere dair görüşleri şöyle:

Emrah Şamdan:

Biz Shape Up kullanıyoruz. Ama onu da zaman içinde kendi sistemize göre uyarladık. Aslında Shape Up’a sprint’te bir şey deliver edememe problemi yüzünden geçmiştik. 2 haftalık sprint planlaması, ölçmesi, groom etmesi derken sürekli bir koşturma nedeniyle neredeyse verimli iş yapamadığımıza karar verdik. Shape Up sayesinde 6 haftalık bir sürede gerçekten müşteriler ve takım için anlamlı bir şeyler çıkaracak planlamayı yapabilir hale geldik. Ancak son dönemde bir pivot halindeyiz ve Shape Up’ı da yine kendimize göre değiştirerek, biraz sprint’e yakınsar hale geldik. Çünkü daha hızlı bir şekilde bir şeyleri test etmek istiyorduk. O nedenle 3’er haftalık daha ufak deliverable’lara odaklandık. Ancak akış genel olarak aynı. O da şöyle: 

• PM herhangi farklı bir metodolojide olacağı gibi yapılacak işi getirir. Bunun için biz JTBD metodolojisine dayanıyoruz. Ama Shape up ile harmanlarken çok son seviyede detay vermemeye dikkat ediyoruz. 

• Daha sonrasında bu getirilen iş üzerinden developerlardan bir bölüm (daha senior’lar diyeyim), designer, CTO bir scope belirleme çalışması yapıyor. Bunu yaparken aslında bir işi 6 haftada yapmak için hangi kısımlardan feragat edebiliriz, bilmediğimiz bir teknik engel var mı, bu konu müşterilere nasıl fayda sağlayacak bakıyoruz. 

• Daha sonrasında belirli bir iş setinden hangilerini alacağımıza CTO, PM Ekibi ve Eng. Manager olarak karar veriyoruz. 

• Arkadaşlar işi yapıyor. Ölçümleme metriklerimizi koyuyoruz.

Hepsiburada ürün ekibi

Scrum metodolojisini göz önünde bulundurarak planlama sürecini yürütüyoruz. Ürün geliştiren takımlar agile çalıştığı ve scrum uyguladıkları için biz de ürünler için bir execution planı yaparken buna göre hareket ediyoruz. Roadmap’i her bir çeyrek için önceden planlanıyoruz ve önceliklendiriyoruz. Takımların çeyrek içerisindeki işleri bitirme hedefleri oluyor. Burada işin kapsamını baştan belirleyip kullanıcılarımıza geliştirdiğimiz özellikleri en hızlı şekilde sunmayı hedefleyen bir MVP planı hazırlayarak bu işi parçalara bölüyoruz. Küçük ölçekli işleri ise ekip ile birlikte doğrudan sprintlere dağıtıyoruz.

Bu metodoloji ile ilerleme sebebimiz işleri küçük parçalara bölerek daha hızlı bir şekilde canlıya almak. Bu sayede işlerin planlama ve geliştirme tarafında karmaşıklığını ve birbirine bağımlılığını azaltmış oluyoruz. Küçük parçalara bölünmüş işleri canlıya alarak hatalı olan işlerden daha erken dönebilme fırsatı da yakalıyoruz. Başarısız olabilecek bir işe büyük eforlar harcamış olmak yerine, en başta az bir efor harcayarak canlıya alıp, gözlemleyip, takımın eforunu verimli kullanabilmiş oluyoruz.

• Bazen plananan özellikler çok büyük eforlar gerektiriyorsa bu işleri çok sayıda parçaya bölmüş olabiliyoruz. Bu durumda her zaman önceliğimiz MVP için planlanan işler olsa da geliştirme takımının kapsamdan uzaklaşmaması adına planlanan feature üzerine detaylı aktarım yapıp takımın büyük resmi de takip edebilmesini ve işin devamını görebilmesini sağlamaya çalışıyoruz.

• Her çeyrek için development takımı ile birlikte roadmapin üzerinden geçiyoruz. Çeyrek içerisinde, ekibin roadmap ile align olabilmesi ve oluşabilecek belirsizlikleri gidermek için düzenli aralıklarla ekibe roadmap içerisinde hangi noktada olduğumuzu ve ileriki sprintlerde yapılması planlanan işleri anlattığımız toplantılar yapıyoruz.

Akış ise şöyle oluyor:

• İhtiyaç belirlendikten sonra development ekibi ile bir araya geliyoruz, işin kapsamını ve büyüklüğünü çıkarıyoruz.

• İş için MVP belirleyip büyüklüğüne göre mevcut çeyrek içerisine eklenebilecek bir iş olup olmadığını kararlaştırıyoruz. Düşük eforlu bir iş ise bu işler takımın roadmap yoğunluğuna göre çeyreğe eklenebiliyor. Büyük eforlu ancak öncelikli bir işse de çeyrekte farklı bir iş ile değiştirilebilir mi kontrolü yapıp ona göre ilerliyoruz.

• Product Canvas’ı hazırlayıp öncelikle MVP olarak yapılacak işleri küçük parçalara bölüyoruz. İleriki fazlar için de genel planı çıkarıyoruz.

• Diğer takımlara dokunan işlerde onların çeyrek planlamalarını da göz önünde bulundurarak iletişime geçip ortak bir planlama yürütüyoruz.

• UX ekipleriyle ve varsa işin dokunacağı ekipler ile birlikte tasarım ihtiyaçlarını konuşup netleştiriyoruz. Tasarım ihtiyacı olan bir iş ise işi kararlaştırılan tasarıma uygun akışa döküyoruz tekrar product Canvas’ta.

• İşin MVP kapsamındaki adımlarını sprintlere dağıtıyoruz ve her sprint öncesi tüm takım ile birlikte konuşarak puanlanabilir işlere kırıyoruz.

• Puanlanan işleri önceden planlanmış olan sprintler içerisine yerleştiriyoruz ve sprint başladığında takım sprint içi önceliğine göre üzerinde çalışmaya başlıyor.

Sizin uyguladığınız, örnek uygulamalardan farklı ya da hibrit planlama akışları var mı? Slack’te yeni sayılar üzerine sohbet etmeyi seviyoruz, sizi de bekleriz!

3. Faydalı kaynaklar

• Üretim Bandı Podcast: Thundra nasıl ürün geliştiriyor? – Link – Emrah Şamdan’ın yazıda bahsettiği Shape Up yöntemiyle alakalı daha fazla bilgi alabileceğiniz bir podcast bölümü.

• Great Products Don’t Happen By Accident – Link – Jon Lax’tan, ürün tasarımı ve geliştirme süreçlerini iyileştirmek için Playbook’ları önerdiği bir blog.

Üretim Bandı Podcast 🎙

• Can Algül ile Pubinno – Biranın İnterneti – Buradan dinleyin

İş İlanları

Tüm aktif ilanları görmek, ilk elden ilanı paylaşan üyelerimize ulaşmak ya da yeni bir ilan paylaşmak için Slack grubumuza katılın!

Bu sayılık bu kadar!

Bizi seveceğini düşündüğünüz birileri varsa, aşağıdaki butonu kullanarak haberdar edebilirsiniz:

Share Üretim Bandı Bülten