Koşuşturmanın ve dinamikliğin bir başkenti olacaksa en büyük adaylardan biri hiç şüphesiz medya olur.
Türkiye gibi çok hareketli bir gündeme sahip, ortalama bir Avrupa ülkesinin bir yıllık gündemini bir haftada tükettiğimiz bir ortamda kullanıcılarımıza içeriklerimizi ulaştırmamız ciddi zorluklar ve riskler içeriyor.
Medyanın aksine IT işi projeksiyon – planlama – kaynak ayırma süreçlerinin stabil bir şekilde (sakinlik içinde) yapılması ile mümkündür.
Hal böyle olunca medya dünyası içinde IT süreçlerini yönetebilmek için çözüm ve alternatif aramak şart oluyor. Yoksa rüzgar sizi nereye sürüklerse siz ve ekibiniz onun etkisi ile savrulursunuz ve asla ürün geliştirme süreçlerinde istediğiniz başarıya ulaşamazsınız.
ÜRETİM SÜREÇLERİNİZİ MAKSİMİZE ETMEK İÇİN AGILE
İşte bu noktada AGILE yaklaşımı belki de çoğu sektörden daha fazla medya için bir kurtarıcı oluyor.
Projenin tüm paydaşlarının COLLABORATIVE çalışmasını sağlayacak dinamikleri,
Her SPRINT başında takımın kendine bir çıta belirlemesi ve ona aşmaya çalışması,
RETROSPECTIVE toplantıları ile takımın kendi dengesini bulması,
KAIZEN yaklaşımı hep daha iyiye yönelik arayışlar,
Her sprint sonunda müşterinin önüne çalışan bir ürün ile çıkmak ve geri bildirim almak gerçekten çok işlevsel ve aynı zamanda beklenen ürüne ulaşmak konusunda ise oldukça umut verici.
Bu sebeple 3-4 yıl önce kendi üretim ekiplerimizin çalışma prensibi olarak; sprint oluşturabilecek şekilde hedefler verebileceğimiz projelerde SCRUM’ı, günlük kararlarla task’lar önceliklendirelecek projelerde KANBAN’ ı tercih etmeye başladık.
Her şey güzel ama çok önemli bir eksik vardı hala;
AGILE yaklaşım bizlere işin tüm paydaşlarının COLLABORATIVE olması ve DELIVERY’ e odaklanılması konularında çok sade kurallarla destek oluyor. Ne ürettiğimizden tüm ekibin haberinin olmasını sağlayarak hızlı bir ürün geliştirebiliyoruz.
Ancak doğru ve kullanıcılarımızın ihtiyacı olan bir ürün mü geliştiriyoruz konusu hala çok net değil ve bir çok sübjektif karar ile ilerlettiğimiz UX adımları hala ürünümüzün hedef kitlesi ile buluştuğunda tercih edilebilir olması ile ilgili ciddi bir tehlike oluşturuyor.
Teknoloji geliştiren bir firmanın en büyük korkusu kimsenin kullanmayacağı bir ürün geliştirmesidir.
MÜŞTERİNİZİN İHTİYACI OLAN ÜRÜNÜ GELİŞTİRMEK İÇİN LEAN UX
AGILE ile üretim bandınızı çok iyi noktalara taşıyabilirsiniz ama müşterinin sıkıntılarına çözüm olacak ürünü geliştirebilmeniz için AGILE’ın yanına koyacağınız formül LEAN UX olabilir.
Eric Reis’ın LEAN STARTUP kavramı ve teorisi hem startup’lar hem de bundan çıkarım yapabilen şirketler için gerçekten devrimsel bir adım.
Aslında daha önce geliştirdiğimiz ürünleri nasıl riske attığımızı, başarının aslında ne kadar zor olduğunu ve bu şekilde bilimsel bir yol kullanmadan başarılı olmanın piyango biletinize ikramiye çıkması seviyesinde olabileceğini ve işin en önemli parçalarından olan UX süreçlerinin kullanıcı kitlesinden uzak nasıl kişisel kararlar ile şekillendiğini fark etmemizi sağladı.
LEAN UX = Design Thinking + Agile Practice + Lean Startup Principles
LEAN UX’ e göre asla yeni bir geliştirmenin design’ ın veya feature’ un mevcuttan daha iyi olacağı konusunda kesin hükümlü olmamalıyız, her şeyi test edip ölçmeliyiz yoksa asıl önemli olan LEARN kısmını gerçekleştiremez ve defalarca aynı hataların etrafında dolanabiliriz.
Yine asıl önemli olan ürününüze feature’ ların oluşturduğu bir yapı olarak değil validate olmuş hypotesis’ lerinizden oluşan bir yapı şekilde bakmamızı önerir.
FEAUTE’LAR YOK HİPOTEZ’LER VAR
LEAN UX, ürününüze feature’ ların oluşturduğu bir yapı olarak değil validate olmuş hippotez’lerinizden oluşan bir yapı şekilde bakmamızı önerir.
Ürün üzerinde eklemek istediğiniz her şey bir feature değil bir validate olmak zorunda olan hypotesis olmalıdır ve her hypotesis aşağıdaki sorulara cevap vermelidir;
WHO : Kimin için yapıyoruz, her geliştirme tüm personanız için olmayabilir,
WHAT : Ürünümüzde hangi iyileştirmeyi amaçlıyoruz,
IMPACT : Hangi alanda bir iyileşme bekliyoruz,
HOW MUCH : Bu alanda beklenen iyileşme oranı nedir,
HOW LONG : Ne kadar süre ile veya ne kadar kullanıcı ile deneme yapacağız
İşte bu noktada LEAN UX, Agile’ın üzerine çok önemli bir değer daha koyuyor;
Burada artık Product Owner’ın tamamlandı kararını verebildiği User Story’ler yerine son kullanıcı tarafından validate veya invalidate edilmek zorunda olan HYPOTESIS’ ler mevcut ve bu sayede ürününüz her adımda son kullanıcısı ile temas ediyor ve gerekli geri bildirimleri alarak ilerliyor.
Hiç bir geliştirmeniz gerçek anlamda sona ulaşmayıp sadece bir sonraki iterasyona kadar hazır şekilde bekler hale geliyor.
Her Sprint için yaptığınız planlama toplantısında, müşteriden gelen sıkıntıları hiptoezler şeklinde test card’lara yazıp, en kısa yoldan bunun test edilmesini sağlayarak ve sonuçlara göre iyileştirmeleri değerlendirerek sürdürebilir bir ortam yaratabilirsiniz.
Dijital ürün geliştirme süreçleri ile ilgili AGILE yaklaşımını da içine alan LEAN UX metodolojisi ve prensipleri geliştirdiğiniz ürünlerin son kullanıcılarınız tarafından beğenilen ve onların sorunlarına çözüm olan ürünler olma olasılığını ciddi şekilde yükseltiyor.