DÖNGÜLERLE ÇALIŞARAK ve ÜZERİNE EKLEYEREK ÜRÜN GELİŞTİRME

DÖNGÜLERLE ÇALIŞARAK ve ÜZERİNE EKLEYEREK ÜRÜN GELİŞTİRME

Bugünün rekabetçi ortamında kârlı olabilmek için, işletmeler hem doğru olanı üretmeli, hem de bu ürünleri verimli bir biçimde üretmeliler; yani hem etkin hem de verimli olmalılar. Müşterilerine değer sunacak ‘doğru’ ürünü, kıt kaynaklarını, yani zaman ve paralarını, en iyi şekilde değerlendirerek üretmeliler.

Üzerinde zaman ve para harcanacak olan bu “doğru” ürün aranırken, iki farklı yöntem kullanılabilir: analiz ve deney yöntemleri. Sadece analiz yöntemini kullandığımızda, aylarca piyasayı, kullanıcıların davranışları ve ihtiyaçlarını analiz etsek de, müşterilerimiz için bir fark yaratacak olan ürün özelliklerini tespit edemeyebiliriz.

Çevik tabanlı uygulama geliştirme yöntemleri işte tam olarak bu sorunu çözüyor, yazılım inşa ederken analiz ve deney yöntemlerini beraber kullanmaya fırsat veriyor.

Yazılım dünyasının fikir liderlerinden Craig Larman, “Agile and Iterative Planning” adlı kitabında, üretim ile yazılım geliştirme dünyasını karşılaştırıyor ve “Waterfall” yani Şelale yönteminin, üretim sektöründe, yazılım sektörüne oranla daha başarılı bir şekilde kullanılabileceğinden bahsediyor. Çünkü spesifikasyonuna uygun bir şekilde daha önce ürettiğiniz ürünün aynından tekrar ürettiğiniz bir sürecin yönetiminin gerektirdiği yaklaşım ile, yazılım üretmenin gerektirdiği yaklaşım farklıdır. Yazılım geliştirirken, her seferinde yeni problemleri çözmeye çalışıyorsunuz, bu yaratıcı bir süreç. Bu da preskriptif bir planlama süreci değil, değişime izin verebilecek adaptif bir planlama sürecini gerektiriyor.

Yazılımın tüm gereksinimlerini eksiksiz bir şekilde tespit ettikten sonra geliştirmeye başlamak aslında zaman ve emek kaybından başka bir şey değil. Projenin erken etaplarında, domain bilgimizin az oluşu, geliştirilecek ürünün pazara uygunluğundan emin olmayışımız gibi sebeplerle, aslında belirsizlik çok yüksek ve pek çok varsayımla ilerliyoruz.

Agile süreçler, bu aşamada sadece analiz değil, deney yönteminden de faydalanmamızı doğru buluyor. Potansiyel kullanıcılarımıza erkenden ulaşıp geri bildirim almamızı, kullanılacak ürün özelliklerini geliştirip, popüler olacağını düşündüğümüz ancak kullanıcılar tarafından beğenilmeyen ürün özellikleri üzerine daha çok efor harcamamamızı mümkün kılıyor.

Agile yaklaşımlarda, işe öncelikli olarak bir “temel uygulanabilir ürün”, yani MVP tanımlayarak başlanıyor. Temel kullanılabilir ürün, ayakları üzerinde durabilen, katma değer üreten, minimum özellik setinden oluşan, ürünümüzün bir ilk versiyonu gibi düşünülebilir. Ancak MVP’ye temel özellikler ötesinde özelliklerin de eklenmesi gerekiyor. Aşağıda, Profesör Noriaki Kano’nun ihtiyacın karşılanma düzeyine göre ürün özelliklerinin müşteri memnuniyetini ne şekilde etkilediğini gösteren yaklaşımını görüyoruz.

Yani ürün özellik seti belirlenirken, temel ve müşterinin beklediği özellikler üzerine, heyecan verici, innovatif bazı özellikler de eklemek gerekiyor. Analiz, geliştirme ve test etaplarını kendi içerisinde barındıran kısa ve dinamik döngülerle çalışılarak MVP hayata geçiriliyor. Bu döngüler, tipik olarak bir ya da iki hafta sürüyor. Amaç etkin ve verimli olmak, yani MVP hayata geçirildikten sonra (mümkün olduğunca erkenden) kullanıcılara ulaşılarak geri bildirim toplamaya başlamak ve bu geri bildirim doğrultusunda ürünü şekillendirmek. Plan, tespit ettiğimiz yeni bilgiler ışığında sürekli evriliyor. İçinde analiz, geliştirme ve test etaplarını barındıran kısa ve dinamik döngüler, her döngü sonunda canlıya çıkabilecek nitelikte kod üretebilmeyi de mümkün kılıyor.

Böylelikle, yazılımı, veri toplayarak, döngüsel bir biçimde üzerine ekleyerek geliştirmek mümkün oluyor. Geribildirimleri dikkate almamıza izin veren, kullanıcılarımız için önemli olan ürün özelliklerine odaklanmamıza, çabamızı gereken yerde harcamamıza yardımcı olan çevik metodlar, kıt kaynakları verimli ve etkili bir biçimde kullanmamızı sağlıyor.

Elif Özdemir, Mobil Proje Yöneticisi/Agile Coach, N11.com