Bir çevik geliştirme taslağı yazılım firmalarının healthcare.gov’daki yaşanan sorun gibi yönetim sıkıntılarından kendi başlarına kaçınmalarını sağlayabilir mi?
Amerikan Hasta Koruma ve Karşılanabilir Sağlık yasası sigortalama sitesi healthcare.gov, yazılım ürünlerindeki başarısızlık sorununu bütün bir ulusun önüne serdi. Her ne kadar bu yakın zamanda en bilinen IT yazılım ürünü başarısızlığı olsa da, tek olmaktan uzak. Bu başarısızlıklar, dünyanın dört bir tarafındaki her türden endüstrideki işletmelerin başına her gün geliyor.
IT ile işletme arasındaki iletişim sorunu
Bu başarısızlıklarından altında ne yatıyor? Virginia merkezli yazılım ve çözümleri firması 3Pillar Global’ın satış ve pazarlama başkan yardımcısı Tony Orlando, iş birimi paydaşları ile (satış, pazarlama, finans vb.) IT arasındaki kopukluğa dikkat çekiyor. “IT projelerinde, yeni teşebbüslerde yüzleştiğimiz bu sıkıntıların nedenlerinden bir tanesi iş tarafıyla IT tarafının yapmak istediği şeylerin senkronize olmamasıdır” şeklinde konuşuyor Orlando.
Sahip olduğunuz şey büyük resmi (dijital ekonominin olgunlaşmasıyla birlikte müşterilerin bir ürün ya da servisten beklentilerini) göremeyen bir firmadır. Bu kullanıcı deneyiminin sizin tüm iş stratejinizin bir bileşeni ve bir yansıması olması gerekiyor. Teknolojiye, işletmeye ya da kullanıcı deneyimlerine ayrı ayrı bakamazsınız” diyor Orlando. Görünürde ters gibi görünen bu hedefler yüzünden çevik geliştirme taslağı doğdu ve onun prensipleri günümüzün iş ikliminde daha da önemli bir hal aldı. Sizin işiniz ancak yazılımı kadar çeviktir. Aynı anda iş gereksinimlerini karşılarken müşteri taleplerine hızlıca yanıt verebilmek, yazılım geliştiricilerinin yazılımı hızlı ve verimli bir biçimde inşa etme özgürlüğüne sahip olmasını gerektiriyor; son kullanıcı standartlarını ve kurumsal paydaşların gelişim süreci içinde görünürlüğe sahip olmasını sağlamak için, diyor Orlando.
“Geliştiriciler kaliteli, temiz kod yazmak ister. Satış, pazarlama ve finanstakiler ürünlerin başarılı olduğunu görmek ister. Müşteriler iyi bir kullanıcı deneyimi talep eder. Tüm bu şeylerin gerçekleşmesini ve bir şeyler ters gittiğinde manşetlerde olmamayı nasıl sağlarsınız?” diye soruyor Orlando. Odağınızı bir proje odağından bir ürün odağına değiştirmelisiniz ve anlaşmazlık halinde gözüken iş hatlarıyla departmanlar arasında işbirliği ve iletişim üzerine bir vurgu oluşturmalısınız, diye konuşuyor Orlando.
Çevikten önce çoğu yazılım projesinin “şelale” tarzı sürecin bir yapısı takip edilerek inşa edildiğini açıklıyor 3Pillar Global’ın ürün yönetimi direktörü Dan Klaussen. Bu da her bir ürünün olası gereksinimlerini onu inşa etmeye başlamazdan evvel karşılanmaya çalışılması manasına geliyordu. “Her ne kadar iyi tanımlanmış gereksinimlere sahip olmak harika olsa da, büyük oranda bir tür vakum içinde yazıldıklarından gerçek dünyanın düzensizliğini tahmin etmek pek mümkün değil” diyor Klaussen. “Kullanıcılar esasında yapacaklarını söyledikleri şekilde davranmıyor, yazılım güçlükleri bazen beklenenden daha güç oluyor, rakipler beklenmedik yollardan değişim gösteriyor, yönetim desteği gelgitlerle dolu. Çevik, yazılım geliştirme sürecinde bir miktar esnekliğe izin vermenin bir yolu olması gerektiği görüşüne bir yanıt olarak geldi,” diye konuşuyor Orlando. “Temel düşünce pazara ayak uydurabilmek için yinelemek, hızlı ve tekrar tekrar. Fikrinizi minimal formda hızla pazara çıkartın ve müşteri geri bildirimini kullanın ki o ürünü müşterilerin ihtiyaçlarına göre gerçek zamanlı olarak yineleyebilesiniz ve adapte edebilesiniz” diye açıklıyor Orlando.
Dokunarak, hissederek geliştirme
Günümüzün dijital, sürekli bağlantıda olan, sosyal medya ağırlıklı ortamında yeni bir ürün geliştirmenin içerdiği büyük riskler mevcut, diyor Orlando. Hata payı jilet kadar keskin ve bir şey ters gidecek olursa, 24 saatlik haber döngüsü işinizin kalabalıklar tarafından cezalandırılacağını sizi temin edecek. Başarısızlık potansiyeli işletmenizin risk toleransını aşağı çekiyor ve ürünlerin başarılı olmasını temin etmek için onları yeni yollar düşünmeye zorluyor, diyor 3Pilla Global’dan Klaussen. “İşletme sahipleri arzu edilen iş sonuçlarını başarma ihtimali düşük bir projeyi fonlamaya istekli, ve muktedir, değil” şeklinde konuşuyor Klaussen. “Bu proje sponsorları ürünlerinin doğru istikamete yönelmesi için onlara dokunma, hissetme ve mümkün olduğunca erkenden test etme imkanı tanıyan bir yola dahil olmak istiyor” diye ekliyor. Klaussen şöyle devam ediyor: “Ve çevik taslağı tarafına yönelme geliştiricilerin kendisi tarafından harekete geçirildi. Bir geliştirici için hiç kimsenin kullanmayacağı binlerce satırlı kodu yazmaktan daha kötü bir şey yoktur. Bu bilhassa üzerinde çalıştıkları ürünün beklentileri karşılamadığını görebilen geliştiriciler için can sıkıcı. Onların kodlarını gerçek kullanıcıların ve paydaşların önüne düzenli olarak koyarak (tipik olarak her hafta) ve değer katan direkt, dürüst geribesleme elde etmek oldukça motive edici. Şimdi onlar kullanıcılarını nasıl memnun edeceklerini tam olarak biliyorlar.”
Ayarlanabilir çeviklik
Çevik geliştirme prensiplerini uygulayan geliştiriciler ve paydaşlara adanmış bir organizasyon olan Agile Alliance’a göre çevik taslağı esnekliğe, istikrarlı yinelemeye ve her şeyin ötesinde işbirliğine vurgu yapıyor. “Oldukça açık bir şekilde çevik süreci, önemli paydaşların bir ürünün organizasyonun iş hedefleriyle uyumlu olduğunu ve karşıladığını kesintisiz olarak doğrulamalarına izin verecek biçimde tasarlandı. Bu, inşa ettiğiniz yazılımın hiçbir zaman tamamlanmadığı ve statik olmadığını düşünen bir kavram” diyor Klaussen. Ve çevik taslağı işbirliğine zorluyor, diyor ESPN program yöneticisi Brian Bragmann. (Bargmann konu hakkındaki görüşlerinin kendisine ait olduğunu, ESPN’nin görüşleri olmadığını belirtiyor.) “Birlikte çalışan ve işbirliği yapan iş tarafı ve IT’ye sahipsiniz ve fark yaratacak olan da bu” diyor Bargmann. “Başlangıçta herkes birlikte çalışmaya ‘zorlanmış’ gibi hissediyor ama her iki ekip için amacın kesintisiz gelişim olduğu ortaya çıktıktan sonra, işte o zaman değer görmeye başlıyorsunuz” şeklinde konuşuyor. Bir çevik metodolojisiyle eğer ürünler yanlış bir istikamete yöneldiyse, problemler daha erken yakalanıyor ve metodoloji ürün yol haritasının toplamında çok fazla israf olmaksızın (sermaye, kaynaklar ve zaman açısından) değişikliklere imkan tanımak üzere tasarlandı, diyor Klaussen. Bunlar tüm paydaşlar, iş tarafı, geliştiriciler ve müşteriler, tarafından görülen ve hissedilen gerçek faydalar, diye sürdürüyor konuşmasını. “Çevik süreci ekibin dokunulan, hissedilen ve sık sık test edilen bir yoldan projeyi inşa etmeye teşvik ediyor. Bu, ürünün sıklıkla çözümün her bir küçük çözümünün birlikte çalışmasını gerektiren gösterilebilir değer temelinde (son kullanıcı fonksiyonelliği gibi) dilimler halinde inşa edilmesi manasına geliyor” diyor Klaussen, ki bu yüzden geliştirici ekipleri sıklıkla tüm parçaları son dakikada tıkıştırmaya çalışmak yerine fonksiyonelliği temin etmek üzere ön uç, özel yazılım ve arka uç bileşenleri entegre ediyor.
“Bunun ortadan kaldırdığı şey” diyor ESPN’den Bargann, “geliştirici ekiplerinizin söz gelimi dokuz aylık bir proje tahminin ardından onlar bunun tamamen bitirilemeyeceğini fark etmesi ya da geri dönerek diğer özellikleri entegre etmek veya hataları düzeltmek zorunda kalmaları. Bu yüzden iş paydaşlarına dönüp, ‘Üzgünüm, bu birkaç hafta daha sürecek,’ derler,” diyor Klaussen. Çevikle birlikte “Vizyonunuz var, planı oluşturursunuz. Fakat gerçek göründüğünde, geribildirimin dahil edilmesi gerektiğinde, iş hedefleri değiştiğinde, bunu hesaba katan bir metodolojiyi takip etmek ekibin elastik olmasına ve elde edilen sonucun gerçek iş değerini teşvik etmesine imkan tanıyor” şeklinde konuşuyor Klaussen.
Geleneksel yazılım geliştirme taslaklarıyla ürün yol haritası içerisine geribeslemeleri dahil etmek bir hata olarak görülüyordu, Çevik’te ise bir başarı olarak görülüyor, diyor Klaussen. “Bu bir başarı zira ekip onu olabildiğince doğru yapamadıklarını öğrendi ve onu hızlıca düzeltebildi. Diğer metodolojilerin çoğu buna bir hata olarak yaklaşıyor. Özellikler doğru yapılmadığından, ardından suçlama oyunu devreye giriyor. Ancak dinlemede, özellik belirlemede ve bir çözümün uygulanmasında insan bileşeni mevcut. Ve ekip duyduklarını kontrol eden ve anlamlı fonksiyonellikleri yaratan bir döngüyü ne kadar çok oluşturursa, onu nasıl doğru yapacaklarını o kadar hızlı öğrenir,” ve dolayısıyla işletmelere daha fazla değer katar, diye sürdürüyor konuşmasını Klaussen.
Çevik her şeyin yanıtı değil
Elbette sadece lafta ‘çevik olmak’ pek bir değişiklik yapmayacak, diyor Bargmann. En azından gerçek, ürün ve iş sonucuna odaklı bir düşünce yapısı oluşturmalısınız, diye konuşuyor Bargman. “Herhangi bir geliştirme ekibi, ‘Bak, bir iş gereksinimini karşılayacak hızlı bir çözüm verebilirim’ diyebilir ancak siz bütünsel bir iş sonucuna odaklanmadıysanız bu size gerçekten ne verebilir?” diyor Bargmann. “Bu eski geliştirici literatüründeki ‘sincap burger’ hikayesine benziyor. Müşteriniz ‘Bir burger istiyorum, hemen’ derse ve geliştirici de ‘Hmm, o eti yetiştirmek, işlemek ve pişirmek çok uzun zaman alacak’ der ama müşteri, ‘o zaman bana herhangi bir şey ver’ der ki siz de ardından ona bir ‘sincap burger’ verirsiniz. Bu iki parça ekmek arasına konmuş bir tür ettir ama bu ‘bir tür’ sizin ihtiyacınız olan şey değildir. Sizden istenen de o değildir ve hiç şüphesiz ne işletmenin ne de müşterinin ihtiyaçlarını karşılamaz” diye konuşuyor Bargmann.
Çeviğe kendi yararı için yönelmek iş sonucunu değiştirmeyecektir, diyor Klaussen; eğer problemin işbirliği ve yineleme parçalarını çözmüyorsanız. “Bu, küçük bir miktar fonksiyonellikle başarılı olmak büyük planla başarısız olmaktan çok daha iyidir’e geliyor. Başarısız olan vizyon üzerinde yeniden çalışmak için gerek zaman daha uzun sürecek ve dahil olan herkes için çok daha acı verici bir yol olacak” diye konuşuyor.