Skip to main content

Günümüzde dijitalleşme ve hızlı tüketimle birlikte müşterilerin ihtiyaçları ve beklentilerinde hızlı değişimler olmaya başlamıştır. 1 hafta önce bir fonksiyonla fark yaratılabilirken 1 hafta sonra geçersiz olup yeni bir özelliğin sahaya sunulması gerekebiliyor veya donanım bağımlılığı olan bir ürün geliştiriliyor ise dünyada çıkabilecek bir tedarik sorunu (örneğin dünyadaki çip üretim kısıtı) bütün iş süreçlerini, sektörü etkileyebilmektedir. Hal böyle olunca müşterilerimizin de beklentileri, ihtiyaçları hızlı bir şekilde değişmektedir.

İş analistleri olarak dış çevrede oluşan bu değişimlere rağmen müşterinin ihtiyacını karşılayacak ürün/hizmeti sunabilmek için gereksinim analizini doğru yapabilmek oldukça önemlidir. Gereksinim Analizi serisinde iş hayatında yaşanan örnekler üzerinden Gereksinim Analizinin önemine ve tekniklere değineceğiz.

Şu an okumakta olduğunuz serinin ilk bölümünde gereksinim analizi yapılmayan bir agile proje örneğinde müşteri ve takım tarafında neler yaşandığını birlikte gözlemleyeceğiz.

Hikaye: Gereksinim Analizi Yapılmamış Proje Başarısızlığa Mahkumdur

Örnekleme yapılacak senaryoda Agile metodolojisinde çalışılmaktadır. Her şey bir t anında müşteriden Product Owner’a talep gelmesi ile başlıyor.

Talep: Müşteri Ahmet Bey, 2 hafta içinde sahaya X modelinde yeni bir cihaz çıkarmak istiyor. Bu sebeple birlikte iş yaptıkları ABC yazılım geliştirme firmasındaki Product Owner, Hande Hanım ile iletişime geçiyor ve sahaya sürmek istedikleri cihazı en hızlı şekilde entegre edip sahaya çıkmak istediklerini dile getiriyor. Ahmet Bey, belirtilen süre içinde istekleri karşılanmayacaksa, diğer yazılım geliştirme firmasına talebi iletmeyi planlamaktadır. Product Owner – Hande Hanım, Ahmet Bey’e talebi belirtilen zamanda yapabileceklerini iletir ve süreç başlar. Şimdi, takım içinde gelişen olaylara ve müşteri Ahmet Bey’e olan yansımalarına bakalım.

Takımdaki İş Süreci: Müşteriden gelen talep, Product Owner üzerinden takım ile paylaşılır ve süreç aşağıdaki gibi ilerler.

  •  Takımın mevcutta çalıştığı backlog maddeleri ve takımın doluluk kapasitesine bakılmadan ve takım ile konuşulmadan         Product Owner-Hande Hanım, müşterisi Ahmet Bey’e söz vermiştir.
  •  Geliştirme takımı gelen talebin neden acil olduğunu sorgulamaz.
  •  Müşterinin sahaya çıkarmak istediği modelin özellikleri, yapılacak çalışmalar yazılı ve detaylı bir şekilde belirlenmemiştir.
  •  Talep geldiği sırada takım, sprint’teki işleri önceden planlamış ve sprint hedefine doğru koşmaktadır.
  •  Müşterinin sahaya çıkmak istediği model devreye alınınca nasıl bir kar elde edilecek, kaç adet kullanılacak, maliyetin geri  dönüşüm süresi ne olacak değerlendirilmemiştir.
  •  Süreçte gereksinim ile ilgili hiçbir şey de dokümante edilmemiştir.

Bu koşulların ardından takımda ve yazılım geliştirme sürecinde aşağıdaki olaylar yaşanır.

  •  Koşulan bir sprint hedefi varken, dışarıdan gelen ek iş ile takımın odak noktası dağılmıştır.
  •  Takım, mevcut planlamasının dışına çıkarak ek iş almıştır. Fazla mesai yaparak araya alınan yükü kapatmaya çalışır.

Not: Bu davranış, uzun vadede çalışanların motivasyonuna, şirkete olan bağlılığına zarar verir ve yapılan işin çıktı kalitesinde düşüşler görülebilir. Bu iş yapış şekli, bir düzen haline gelmiş ise takım üyelerinde, yapılan işe dair değersizlik hissi oluşabilir, çalışanın kendisini yetersiz değersiz görmesine sebep olabilir.

  •  Takım elindeki işi bırakarak yeni talep üzerinde çalışmaya başlar, ama gereksinim analizi yapılmadığı için ne yapması   gerektiğini bilemez.
  •  Takımda sektörel iş bilgisi fazla olan uzman iş analisti Deniz Bey, tecrübeleri doğrultusunda bir takım varsayımlar yaparak müşterinin beklentisini tahminler ve bu varsayımlar üzerinden yazılım geliştirmesi yapılır.
  •  Müşterinin talebi ile müşteriye sunulacak ürün/hizmet arasındaki uçurum artmaya başlar.
  •  Teslimat gününe 2 gün kala müşteri Ahmet Bey’e çıktılar sunulur, müşteri onayından sonra sahaya çıkılması   planlanmaktadır.
  •  Ahmet Bey, ürünü gördüğünde hayalindeki fonksiyonları uygulamada göremediğini fark eder. Emin olmak için firmaya   sorar. ABC firmasında takım, ilk defa duydukları talep karşısında şaşkınlık içinde kalırlar.
  •  Müşteri Ahmet Bey zaman kaybetmiştir, sahada planladığını aksiyonu yapamayacak kadar artık çok geç kalmıştır.
  •  Takım, müşteri ihtiyacı hakkında gerekli bilgi verilmediği için Product Owner- Hande Hanım’ı  suçlar.
  •  Yaşanan tüm bu sorunlar sonucunda müşteri ve takım açısından sonuçlar nasıl olur?

■ Müşteri Ahmet Bey, istediği hizmeti alamamıştır ve bunun için bir süre bekleyerek zaman kaybetmiştir.

■ Müşteri, sonunda talep etmediği bir ürün/hizmet için yazılım desteği aldığı ABC firmasına ücret ödemesi gerekecek veya bu sözleşmede belirtilmiş ise maliyet, ABC yazılım geliştirme firmasına bırakılabilir.

■ Yazılım geliştirmesini yapan takım inisiyatif alarak, belki de fazla mesai yaparak geliştirdiği ürünün başarısız olduğunu gördüğünde motivasyon zedelenmesi, emeklerin boşa çıkması gibi bir algı oluşacaktır. Takım içinde varsayımlarla yönlendirme yapan takım arkadaşı ve diğerleri arasında güvensizlik oluşacaktır. Takım bu başarısızlığın sebebini Product Owner’a yıkmak isteyecektir. Bütün bu süreçler olurken sprint’e daha önceden alınan işler askıya alındığı için o işlerde de sorunlar ortaya çıkacak ve başka müşteri taleplerinde de zincirleme sorunlar gündeme gelecektir.

Yukarıdaki senaryoya bakıldığında gereksinim analizinin sürecin en başında, doğru tekniklerle yapılmasının bütün paydaşlar açısından ne kadar önemli olduğunu görmekteyiz. Hikayede tek bir suçlu yoktur, süreçte yer alan herkes eşit derecede sorumludur. Ancak iyi bir iş analistinin farkı tam da bu tarz durumlarda ortaya çıkar. 

Bir sonraki yazımızda canlandırdığımız senaryoda gereksinim analizi yapılsaydı süreç nasıl ilerlerdi konusuna değineceğiz.

 

 

Pelin Dökmen

Senior Expert Business Analyst & Scrum Master @Garanti BBVA Technology

Content Writer @BA-Works