Geleneksel bir yazılım geliştirme yaşam döngüsünde:

  • İş birimleri problem veya fırsatı tanımlar.
  • İş birimleri en iyi çözüm seçeneğini tahmin eder ve taleplerini talep yönetim sistemi ile BT (Bilgi Teknolojisi) bölümüne gönderir.
  • İş analizi ekibi, çözüm kapsamını ve ayrıntılı gereksinimleri belirlemek için birkaç kez iş birimi temsilcileriyle bir araya gelir.
  • Tasarlanan çözüm geliştirme ve test işlemlerinden sonra kullanıcı kabul testleri (UAT) için son kullanıcılara (müşterilere) gönderilir. Bu aşama, son kullanıcıların tüm proje yaşam döngüsü boyunca projeye dahil oldukları ilk ve son zamandır.

İş analistlerinin ve BT ekiplerinin tüm çalışmalarına rağmen, klasik yaklaşımın başarı oranı çok düşüktür. Hedeflenen zaman çizelgesi ve bütçeleri içinde projelerin sadece küçük bir yüzdesi tamamlanabilmekte ve çoğu zaman projeler, hedef kitlenin ihtiyaçlarına hizmet etmeyen bir çözüm ile bitmektedir.

İş birimleri, beklentilerin altında bir çözüm sunduğu için BT ekiplerini suçlamaktadır. Taleplerinin geç teslim edilmesinden dolayı, önerilen çözümün hızla değişen piyasa koşullarında ve pazar baskısında önemini yitirdiğini iddia etmektedir.

BT ekipleri iş birimlerini; proje süresince hiç bitmeyen, proje gecikmeleri ve öngörülemeyen proje maliyetlerine sebep olan değişiklik talepleri (CR) için eleştirmektedir. İş birimlerinin gerçekten neye ihtiyaçları olduğunu bilmediğini iddia etmektedir. Bu durum, projenin göreceli olarak daha karmaşık bir sorunu ya da fırsatı ele aldığı durumlarda daha da kötüleşir.

Geleneksel yazılım geliştirme yaşam döngüsünün dezavantajları aşağıdaki gibi özetlenebilir:

  1. Belirsiz Proje Hedefleri

İş birimleri ve BT, proje hedefleri ve hedef kitle hakkında ortak ve net bir anlayışa sahip değildir.

  1. Müşteri Katılımının Yetersizliği

Müşteriler; analiz, tasarım ve geliştirme aşamalarında yer almamaktadır. İş birimleri müşterilerin ihtiyaçlarını onlardan daha fazla tanıdıklarına inanmaktadır. Çözümün kapsamı ve gereksinimleri, gerçek müşteri ihtiyaçları ve iç görülerden ziyade varsayımlara dayanarak tanımlanır.

  1. Sınırlı İş Birliği

İş birimleri ve BT, silo tabanlı yapıda çalıştıklarından; iş birlikçi bir ekipten ziyade, olası bir proje başarısızlığının sorumluluğundan kurtulmak için onay süreçleri ve resmi imzalarla hareket ederler.

Başarılı şirketler bu dezavantajı önlemek için design thinking yaklaşımıyla yazılım yaşam döngüsünü aşağıdaki aşamalar yardımıyla bir araya getirmektedir.

  1. Çözüm önermek yerine problem veya fırsatın tanımlaması ile başlayın.

İş birimi bir problem yaşadığında ya da fırsat tespit ettiğinde, öncelikle sorunun temel nedenleri ayrıntılı olarak ele alınmalıdır.

Genellikle üç tür problem vardır:

  1. Bilinen / Bilinen: Sorunun temel nedeni ve çözümü kesinlikle bilinir.
  2. Bilinen / Bilinmeyenler: Sorunun olası kök nedenleri bilinir, çözüm bilinmez.
  3. Bilinmeyen / Bilinmeyenler: Sorunun temel nedenleri ve olası çözümleri kesinlikle bilinmez.

Design thinking, özellikle karmaşık ve belirsiz olan birçok bilinmeyenli projelerde etkilidir. Tip 2 (bilinen/bilinmeyen) ve özellikle tip 3 (bilinmeyen/bilinmeyen) problemlerini; empati, iç görü ve deneysel yönleriyle yeni bir bakış açısı getirerek çözmeyi hedefler.

  • İş birimleri, en iyi çözüm seçeneğini öngörmek ve hemen BT’ye bir proje talebi göndermek yerine; design thinking workshop düzenlemeyi önermelidir.

İş birimi temsilcileri ve iş analistleri, “How might we’ (HMW) soru tekniğini kullanarak problemi veya fırsatı iş birimlerinin vizyonuna hizmet edecek bir amaç haline dönüştürmeye odaklanmalıdır. Örneğin; satış ve pazarlama departmanlarının, dijitalleşmenin faydalı olabileceğini düşündüklerini ancak bayilerin tepkisi ile ilgili endişe duyduklarını varsayalım. Bu durumda geleneksel olarak talep yönetim sistemine bir mobil uygulama proje isteği göndermek yerine design thinking workshop’ı düzenleyerek, ‘bayilerimizle çatışmaya girmeden dijital kanallardan nasıl yararlanabiliriz?’ sorusu yardımıyla çözüme gitmeyi hedeflemelidirler.

  1. Çözümü müşteri ile birlikte tasarlayın:

İş birimleri temsilcileri ve iş analistleri, çözüme giden süreçte müşterilerin adına çözüm tasarlamak yerine hedef kitlenin demografik ve davranışsal niteliklerini persona tanımlamaları üzerinden açıklığa kavuşturmalıdır.

  • Design thinking workshop’larına her bir persona grubunu temsil eden müşteriler davet edilir. Kullanıcıların ihtiyaçları, beklentileri ve sıkıntı yaşadıkları noktalar; ‘customer journey map’  ve ‘empathy map’ gibi kullanıcı odaklı tekniklerle belirlenir.
  • Ayrıca, müşterilerin direkt olarak dile getirilmemiş, açıkça ifade edilmeyen ihtiyaç ve beklentileri, ‘affinity map’ ve ‘mind map’ teknikleri ile tanımlanır.

Bu çalışmalar ve tekniklerle elde edilen sonuçların her biri; iş analistleri tarafından, projenin ilerleyen dönemlerinde ayrıntılı gereksinimleri belirleme aşamasında bir girdi olarak kullanılabilir.

  • Design thinking workshop katılımcıları ilk olarak kısıtlamalara takılmadan mümkün olduğunca çok yaratıcı fikir üretmeye odaklanırlar. Sonrasında üretilen fikirleri beklenen değer getirileri ve uygulama zorluklarına göre önceliklendirirler. Önceliklendirilmiş fikirler, yüksek seviyeli prototipler biçiminde bir çözüm konseptine dönüştürülür.

Müşteriler, prototipler yardımıyla bu çözüm konseptinin ihtiyaç ve beklentilerini karşılayıp karşılamadığını değerlendirirler. Tasarlanan çözüm, kullanıcı geri bildirimlerine göre revize edilir.

Seçilen fikirler ve prototipler, iş analistleri tarafından çözüm kapsamını belirlemede bir girdi olarak kullanılır. Seçilen her fikir, yazılım yaşam döngüsünde kullanılacak metodolojinin waterfall veya agile olmasına bağlı olarak, use case veya user story’ler için bir temel olarak düşünülebilir.

Projenin başlangıcında nihai kullanıcıların katılımı ile düzenlenen design thinking workshop’ları, proje boyunca her paydaşın aynı stratejik yönde ilerlemesini sağlar. Bu yaklaşım, proje boyunca gecikmelere ve öngörülemeyen proje maliyetlerine sebep olan değişiklik taleplerini (CR) azaltarak kapsam kaymalarını önlemeye yardımcı olur.

  1. İş birliği içinde olun.
  • Design thinking workshop’larına farklı departmanlardan iş birimi temsilcileri, müşteriler, IT ekipleri ve iş analistleri davet edilir. Böylelikle çözüm fikirleri, organizasyon içinde farklı perspektifler kullanılarak iş birliği içinde gerçekleştirilir.

Tüm fikirlerin müşteriler, iş birimleri ve BT işbirliği ile değerlendirilmesi, iş birimlerinin önceliklerini daha açık bir şekilde belirtmelerine ve BT ekiplerinin kısıtlamalarını daha anlaşılır bir şekilde iletmelerine yardımcı olur.