Bağlantı Kopyalandı!
Bülten #26: Yeni Özellik Geliştirmek-2: Planlama (Gereksinimler)
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 devam ediyoruz. Konuyu “Akış” ve “Gereksinimler” temaları altında iki ayrı sayıda inceleyeceğiz demiştik, ve bu sayının konusu bu yüzden “Planlamada gereksinimler”: Gereksinim nedir ve neden önemli, içeriği ne ve nasıl oluşturuluyor, diğer fonksiyonlarla beraber planlama yaparken bu gereksinimler üzerine nasıl hemfikir olunuyor gibi konular üzerine kafa yorduk ve topluluk üyelerimizden fikirlerini aldık. Umarız sizde yeni fikirler oluşmasına vesile oluruz!
İ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:
Yeni Özellik Geliştirmek-2: Planlama (Gereksinimler)
-
Gereksinimler: Nedir?
-
Planlama süreci: Gereksinimleri Aktarma ve Hemfikir Olma
1. Gereksinimler: Nedir?
Gereksinimler özetle ürün geliştirme süreçlerinin standart bir parçası haline gelmiş, özünde geliştirilecek ürünün/özelliğin detaylarını belirlemeye ve ekipler arasında tektipleşmiş bir biçimde aktarmaya yarayan bilgiler bütünü olarak tanımlanabilir. Bu araçlar planlama öncesinde ya da sırasında ortaya çıkan detayları yazılı ve görsel olarak dökümante etmeyi sağlıyor ve organizasyonlar arasında farklılaşsa da genel olarak bazı temel noktaları barındırıyor.
Önceki sayılarımızdan “Ürün Gereksinimleri Dökümanı (Product Requirements Document, PRD)”nda gereksinimlerin öneminden, faydalarından ve zorluklarından bahsetmiştik ve hem globalden, hem topluluk üyelerimizin deneyimlerinden hareketle örnekler paylaşmıştık. Bu sayıda tekrara düşmemek için daha çok bu gereksinimlerin aktarım şekillerini ve ürün yönetimi ekiplerinin organizasyondaki diğer fonksiyonlarla ortak çalışma yollarını anlamak istedik ve sözü topluluk üyelerimize bıraktık.
2. Planlama süreci: Gereksinimleri Aktarma ve Hemfikir Olma
Gereksinimleri aktarmak
Topluluk üyelerimize gereksinimleri aktarırken izledikleri yöntemleri, kullandıkları araçları, bu gereksinimlerin içeriğini ve diğer fonksiyonların içeriğe olan katkılarını sorduk ve şöyle cevaplar aldık:
1. Gereksinimleri aktarma yönteminiz ne oluyor?
Nihan Demirkazıksoy (Zalando, Senior Product Manager):
Gereksinimleri aktarma yöntemi olarak genellikle yapılandırılmış bir prosedürü takıp ediyorum. Öncelikle kullanım senaryolarını (use cases) belirgin bir şekilde ayrıntılı olarak yazıyorum. Bunun için daha önceden yaptığım kullanıcı görüşmelerinden faydalanıyorum. Daha sonra bütün menfaat sahipleri ile görüşerek kullanım senaryolarını anlatıyor ve onların sorularını cevaplıyorum. Kullanım senaryoları ve amaç anlaşıldıktan sonra menfaat sahipleri ile sorumluluklar ve zaman çizelgelerini belirliyoruz. Riskli durumlar varsa risk analizi yapıyoruz. Çalışmaya başlamadan önce dökümanlar bütün menfaat sahipleri ile paylaşılıyor ve ürün üzerinde çalışmak için onay alınıyor.
Hepsiburada mobil ürün ekibi (Ahmet Ertaş, Product Owner – Selen Kozanoğlu, Product Owner – Özge Yağlı, Product Owner):
Gereksinimlerin belirlenmesi ve geliştirme sürecine dahil edilmesi pek çok adım içeriyor. Gereksinimler paydaşlardan gelebileceği gibi, bizim tarafımızdan veri analizleri ve geri dönüşlerin değerlendirilmesi ile de geliştirme sürecine alınabiliyor. Gereksinimler her çeyreğin yol haritası üzerinden iletilebilir veya mevcut sprint içerisinde ek gereksinimler ortaya çıkabilir. Bu gereksinimler bir önceki sprint başında product owner ekibi tarafından öncelik durumuna göre değerlendirilmek ve bir sonraki sprint planına alınabilmek üzere paylaştırılır. Her product owner gereksinimin detaylarını araştırır. Bu araştırma süreci; benchmarking, paydaşlarla gereksinimin detaylarını inceleme ve bağımlılıkları yönetme, tasarımların netleştirilmesi ve geliştirme kısıtlarına uygunluğunun kontrol edilmesi, geliştiricilerle ilgili servis ve iş akışlarının değerlendirilmesi, gereksinimin aciliyetinin ve teslim edilme sürecinin incelenmesi gibi durumların tamamını kapsar. İlgili gereksinimler bütünü, tüm detaylar netleştirildikten sonra bir sprint içerisinde teslim edilebilir boyutlarda olacak şekilde user story’lere paylaştırılır. User story’lere bölüştürülmüş gereksinimin detayları her sprint öncesinde geliştirme ve QA ekipleriyle konuşulur ve işlerin tahmini eforları sayısal puanlama üzerinden belirlenir. Oy çokluğu ile efor belirlendikten sonra gereksinim öncelik durumuna göre sprint’e dahil edilir. Ekip içerisinde işin detayları product owner’ın işi anlattığı ve tüm soruların cevaplandığı kick-off toplantısıyla tekrar netleştirilir. Kontrat (Backend ve client ekibi arasındaki servis detaylarının netleştirilmesi) yapıldıktan sonra iş geliştirici tarafından çalışılmaya hazır olur.
2. Bu sırada hangi araçları kullanıyorsunuz?
Hepsiburada mobil ürün ekibi:
Kullandığımız toollar ihtiyaçlara göre dönemsel olarak değişiklik gösterebiliyor, son dönemde aktif olarak kullandığımız toollar:
-
Miro: Taleplerin etkilediği ekranlar ve bu ekranlar arasındaki akışların gösterilmesi, benchmarking çalışmalarının paylaşılması, bütün paydaşların yorumlarıyla katılım sağlaması gibi talebin genel detaylarını oluşturan öğeleri bir arada görmek ve değerlendirmek için Miro’yu kullanıyoruz.
-
Asana: Paydaşlardan gelen taleplerin yönetimi, Product Owner’lar arasındaki iş birliğini ve genel talep takibini sağlamak için Asana’yı kullanıyoruz. Bu süreç için tool kullanımı ekipten ekibe göre değişebiliyor, Mobil ekip olarak biz Asana’yı tercih ediyoruz.
-
Zeplin: UX ekibinin hazırladığı ekran tasarımları için Zeplin’i kullanıyoruz.
-
ProtoPie: UX ekibinin hazırladığı tasarımlar üzerindeki etkileşim demolarının gösterilmesi için ProtoPie kullanıyoruz.
-
Jira: Gereksinim detayları finalize edildikten sonra talebi user story formatında ekibe aktarmak için Jira’yı kullanıyoruz.
-
Slack & Google Meet: Gereksinimleri ekibe aktarmak için toplantıları Slack ya da Google Meet üzerinden organize ediyoruz.
Nihan Demirkazıksoy:
Genellikle Google Sheets, Google Docs, Figma ve Jira kullanıyoruz.
3. Gereksinimlerin içeriği ne oluyor?
Hepsiburada mobil ürün ekibi:
İşi detaylandırdığımız user story’ler için belli bir taslak kullanıyoruz ve bu taslak içerisinde şu 3 ana başlık yer alıyor:
-
Context: Taslak yapısının ilk elementi olarak Context bölümü bulunuyor. İşi yapacak ekibe ve tüm paydaşlara anlamlı bir anımsatıcı olması için user story’nin çıkış hikayesini ve kapsamını bu başlık altında iletiyoruz.
-
Assumptions: Bu bölüm ile user story’nin tamamlanması için gerekli maddeleri listeliyoruz.
-
Geliştirilecek özelliğin beklenmedik durumlarda açılıp/kapanabilme yeteneğinin kazandırılması isteniyorsa Toggle bilgilerini maddeler arasına ekliyoruz.
-
VoiceOver ve TalkBack (Accessibility) özellikleri için gerekli bilgileri detaylandırıyoruz.
-
Tasarım gerektiren bir iş ise mutlaka Zeplin linkini ekliyoruz.
-
İlgili user story için yük testi ihtiyacını takımla görüşüp netleştiriyoruz ve bunun sonucuna göre Assumptions maddeleri arasına yük testi gerekliliğini ekliyoruz.
-
Servis yenileme ya da data tanımlama işi ise servis kontratlarını ekliyoruz
-
İş kapsamının ve diğer detayların çalışıldığı bir Miro board’u mevcut ise o board’u linkliyoruz.
-
Başka bir iş ile alakalı herhangi bir bağımlılık varsa o bağımlılığı belirtiyoruz. Bağımlı işleri birbirine linkleyerek ilişkilendiriyoruz ve işlerin takibini sağlıyoruz.
-
-
Acceptance Criteria: Son adım olarak belirlenen kapsamı doğrulayacak kabul kriterlerini ekliyoruz.
Nihan Demirkazıksoy:
Özetle şu ana başlıkları takip ediyorum:
-
Kullanım senaryoları,
-
Amaç,
-
Başarı kriterleri,
-
Tasarım spesifikasyonları,
-
Kullanıcı görüşmeleri özeti
-
Teknik detaylar,
-
Eğer tamamiyle yeni bir konsept veya birçok özelliği bulunduran bir ürün ise, press release de yazabiliyorum.
4. Her bir fonksiyonun bu içeriğe nasıl katkısı oluyor?
Hepsiburada mobil ürün ekibi:
Aslında her birimin görev tanımı ve tecrübeleri doğrultusunda içeriğe optimum seviyede katkıları oluyor. Product ekibi olarak, bu katılımın istenen seviyede olmasını sağlayacak yönlendirmelerin yapılması ve koordinasyonun sağlanması için aktif bir rol alıyoruz. Bu süreci özetlemek gerekirse;
-
Talep sahibi, ihtiyacı ve talebi iletiyor. Bu paydaş, bazı durumlarda teknoloji dışından bir birim, bazı durumlarda ise teknoloji bünyesindeki diğer ekipler olabiliyor. Bu aşamada doğru sorular ve yönlendirmeler ile gereksinimler şekillenmeye başlıyor. İhtiyacın sağlıklı bir şekilde adreslenebilmesi açısından en kritik süreç bu adımda gerçekleşiyor. İhtiyaçları nitel formdan nicel forma doğru evirmeye çalışıyoruz ve bunu sağlamak için gerekli aksiyonları belirliyoruz.
-
İhtiyaçlar netleştikten sonra Miro’da bir board oluşturup; elimizdeki doneleri ve ihtiyaç duyulan akışlar, metrikler, yorumlar, kurallar gibi bilgileri bu boardda topluyoruz. Sürecin devamı da bu board üzerinden ilerliyor.
-
UX ekibi ile ihtiyacı tartışıp, kullanıcı deneyimine karar veriyoruz ve çıktı olarak; arayüz tasarımları ve etkileşimler için gereksinimleri gösteren/anlatan çalışmaları alıyoruz. Deneyime ve etkileşimlere karar verme süreci bazen sadece bir toplantı ile mümkün olabilirken, bazen de araştırma, benchmarking, data toplama vb. çalışmalardan oluşabiliyor.
-
Bu noktaya kadar elimizde olan doneler çerçevesinde, geliştirme ekibiyle bir grooming session düzenliyoruz. Bu session’da işin teknik boyutunu değerlendiriyor ve izleyeceğimiz yönteme karar veriyoruz. Tabi her şey, her zaman bu kadar pürüzsüz ilerlemiyor ve çıkmaza girdiğimiz noktalar da oluyor. Bu gibi durumlarda ise, ilgili paydaşların yer aldığı (pazarlama, geliştirme ekibi, UX vb.) bir oturum daha düzenliyoruz ve geldiğimiz noktayı değerlendiriyoruz. Çıktı olarak ise ortak paydada buluşabilmeyi hedefliyoruz.
-
Yukarıdaki adımlar istenen olgunluğa geldiğinde ise artık Product ekibi olarak User Story’lerin oluşturulması sürecine geçiyoruz. Eğer tek bir User Story yeterli olacaksa elimizdeki tüm doneleri barındıracak şekilde oluşturuyoruz. Eğer birden fazla User Story’den oluşan bir süreç ise, user story list belirlenerek, ilgili user storylerin içerisine ilişkili doneleri ekliyoruz. Son olarak, oluşturulan User Story’lere belirlenen kapsamı doğrulayacak kabul kriterleri ekleniyor ve iş, eforlama sürecine hazır hale geliyor.
Diğer fonksiyonlarla hemfikir olmak
5. Yapılacak işlerin teknik gerekliliklerinin planlanma sürecine ne kadar dahil oluyorsunuz?
Nihan Demirkazıksoy:
Çok fazla değil. Sadece planlama yapıldıktan sonra zaman çizelgeleri ve yöntem konusunda bilgilendiriyorum. Sorularım veya sorunlarım varsa bunları dile getiriyorum, geliştirme ekibi ile birlikte daha iyi bir zamanlama veya yöntem bulabilir miyiz tartışıyoruz.
Hepsiburada mobil ürün ekibi:
Hepsiburada’da Product Owner’lar geliştirme ekiplerinin bir parçası olarak iş süreçlerinin takibini sağlıyor. Uçtan uca iş takibi yapma sorumluluğunu üstlendiğimiz için işlerin teknik gerekliliklerinin belirlenmesi ve planlanması noktasında doğrudan müdahil oluyoruz. Gereksinim henüz bizim tarafta olgunlaşmadan önce teknik paydaşlarla beraber servislerin, tasarım ve iş akışlarını karşıladığına emin oluyoruz. Servislerde eksik varsa paydaşlara bunu bildiriyoruz, aynı zamanda tasarım süreçlerinde teknik gerekliliklere uygun tasarımların çalışıldığından emin oluyoruz. Uygulamadan atılan analitik event datalarının kontrol edilebilmesi noktasında hazırladığımız kontratlar ile teknik ekiplerin ortak bir dil üzerinden event datalarını takip etmesini sağlıyoruz. Belli işlerde, kickoff toplantıları üzerinden backend ve client ekipleri arasındaki kontrat planlama süreçlerine destek verebiliyoruz.
6. Geliştirme ve tasarım fonksiyonları beraber ve aynı anda mı hareket ediyor, yoksa tasarım tamamen finalize olduğunda mı geliştirme başlıyor? Tasarım kararlarında ne kadar bulunuyorsunuz?
Nihan Demirkazıksoy:
Beraber çalışılıyor, hatta çalışmanın başında geliştirme ve tasarım ekipleri sürece dahil olarak kullanım senaryolarına göre ürünler tasarlamamız için en baştan fikir ve yorumlarıyla bize yardımcı oluyorlar.
Tasarımlara dair alınan kararlarda hep varım, benim onayım olmadan geçmiyor
Hepsiburada mobil ürün ekibi:
Tasarımın netleşmediği durumlarda işe başladıktan sonra çok fazla git-gel yaşanıyor, kapsam değişiklikleri olabiliyor ve işin tamamlanma süreci riske giriyor. Bu sebepler dolayısıyla tasarım finalize edilmediyse ilgili işe başlamayı tercih etmiyoruz. Fakat bazı durumlarda, işin önceliğine göre inisiyatif alıp tasarımı tamamlanmamış işi sprinte ekleyebiliyoruz.
Bir iş ihtiyacı doğduğu noktada biz ve ilgili paydaşlar tasarım ekipleri ile ortaklaşa çalışıyoruz. Kullanıcı deneyimi odaklı çalışan ekipler, kullanıcı araştırmaları ve benchmarking çalışmaları yürütüyor. A/B test ihtiyacı konuşuluyor ve bu çalışmaların neticesinde Miro üzerinden tasarım planları bizimle paylaşılıyor. Bu noktada; teknik kısıtları, mobil dünyaya uygunluğu ve gelen feedbackleri değerlendirerek tasarımlar üzerinden yorumlarımızı iletiyoruz. Bir işin eforu ve bu işin etki hacmi üzerine anlaşma yapıyoruz, örneğin kullanıcılar tarafından limitli oranda kullanılan bir gereksinim için yüksek eforlu tasarım çalışılmaması gerektiği konusunda yönlendirmeler yapabiliyoruz veya kullanıcının sevdiği ve desteklediği deneyimleri artırmaya çalışıyoruz. Zeplin’e yüklenen tasarımların; hata, başarı, bilgilendirme, yüklenme caselerini içerdiğinden, ikonların uygun tipte olduğundan, pop-up/tool-tip gibi yardımcıların eklendiğinden emin oluyoruz. A/B test neticesine göre kullanıcı deneyimi ve etkileşimi açısından revize ihtiyacı varsa belirleniyor ve gerekli düzenlemelerden sonra geliştirme bütün kullanıcı gruplarında canlıya alınıyor. Bunun yanında, geliştirme aşamasında ortaya çıkan ekstra durumlarda tasarım ekibiyle bire bir etkileşim kurarak hızlı çözümler üretiyoruz.
8. Kapsam konusunda farklı fonksiyonlarla hemfikir olma sürecini nasıl yönetiyorsunuz?
Hepsiburada mobil ürün ekibi:
Genelde kapsam konusunda hemfikir olma süreci, gereksinimler olgunlaştırılırken organik bir şekilde oluşuyor. Bir noktada tüm fonksiyonların ortak bir amacı bulunuyor ve bu çerçevede en verimli olacağına inandığımız ya da kanıtlayabildiğimiz kapsam üzerinden ilerliyoruz. Genelde birinci önceliğimiz pazara sürüm süresi (time to market) oluyor. Pazara sürüm süresi üzerinden kapsamı belirlemeye çalışıyoruz ancak bu kaliteden ödün verdiğimiz anlamına gelmiyor tabii ki. Duruma göre esnediği senaryolar da olabiliyor. Bu tarz durumlarda da ilgili talebi fazlandırarak ilerliyoruz. Bir MVP kapsamı belirliyoruz ve sonraki iterasyonların kapsamlarını netleştirip tüm paydaşlarla neden fazlandırılması gerektiğini, bize neler kazandıracağını, riski ne kadar minimize ettiğini şeffaf bir şekilde anlatıp, hemfikir olup süreci ilerletiyoruz.
Nihan Demirkazıksoy:
Devamlı bütün menfaat sahipleri ile ortaya çıkmakta olan ürünün defalarca üstünden geçerek. Haftalık olarak buluşuyor süreci ve ortaya çıkmakta olan ürünü değerlendiriyoruz. Tasarım veya geliştirmeyi yaparken karşımıza çıkan engelleri tartışıyor ve ürünü daha iyi nasıl yapabiliriz üzerine birlikte çalışıyoruz. Kapsam biraz bu görüşmelerde değişebiliyor ama asıl kapsam en başında kullanıcı senaryolarının üzerinden geçerken belirleniyor. Tutumumuz genellikle en az özellikle en fazla değeri nasıl aktarabiliriz baz alınarak kararlaştırılıyor.
🤔 Siz gereksinimleri nasıl aktarıyorsunuz, diğer ekiplerle nasıl hemfikir oluyorsunuz? Slack’te yeni sayılar üzerine sohbet etmeyi seviyoruz, sizi de bekleriz!
Üretim Bandı Podcast 🎙
-
Akın Ömeroğlu ile Açık Kaynak Üzerine – 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:
Bültenler
