Aynı başlıklı ilk yazıda istek ile ihtiyaç arasındaki ayırımdan bahsetmiş ve yazılımların başarısı açısından istekler yerine ihtiyaçlara yönelmenin gerekliliğini vurgulamıştık. Bu yazıda ihtiyaç kavramına biraz daha odaklanacağız ve “kapsam”ı ele alacağız.

İşin açıkçası ihtiyaçlara odaklanmak da projelerin başarısını garanti etmez ya da kullanıcılarını memnun etmez. Çünkü ihtiyaç, üzerine biraz daha düşünülmesi gereken bir kavramdır. Örneğin ihtiyaç noktasında sorulması gereken bazı sorular vardır. Bu sorulardan ilki, ihtiyacın gerçek olsa bile projenin kapsamında (scope) olup olmadığıdır. İsteklerinin üzerine düşünmeden onları ihtiyaç diye proje ekibine kabul ettirmeğe çalışmakla, aslında kapsam dışı olması gereken ihtiyaçları kapsama sokmak için proje ekibini ikna etmek arasında, projeyi riske sokmak açısından hiç bir fark yoktur.

Proje tanımından, bir projenin kapsamının ve hedeflerinin belli olması gerektiğini biliyoruz. Kapsam yönetimi, proje yönetim metodolojilerinin üzerinde önemle durduğu konulardandır. Proje kapsamından kasıt ise ihtiyaçlar açısından neyin projede ele alınacağı neyin ise proje dışında bırakılacağıdır. Kapsam, projenin sınırlarını belirler. Kapsamın önce belirlenmesi ve sonrasında kontrol edilmesi, yeni isteklerin ve değişikliklerin kapsamın içine girip girmediğine karar verilmesi, giriyorsa önceliklendirilmesi ve maliyetlendirilmesi, bu bağlamda yapılması gereken en temel çalışmalardandır. Bu noktada ihtiyaçlarını belirlerken sistemin kullanıcılarına düşen en temel şey ise ihtiyaçları arasında önce kapsam açısından bir öngörüde bulunmaları sonra da kapsam içinde olduğunu düşünüyorlarsa ihtiyacı önceliklendirmeleridir.

Gerek dünyada yazılım projelerinin başarısızlık sebepleri üzerine yapılan araştırmalar gerek ise benim ülkemizdeki yazılım projelerinden edindiğim tecrübeler, kapsamı düzgün yönetilmeyen projelerin bir süre sonra batağa saplandığını gösteriyor. Kapsam problemi, eğer proje iç BT birimi tarafından yapılıyorsa, yapılan işi proje tanımından çıkaracak noktaya kadar gidebiliyor. Bu durumda zaten hiç bitmeyen projeler ortaya çıkıyor. Yok proje eğer bir dış kuruma yaptırılıyorsa, bu durumda kurumlar arası özellikle finansal menfaatler söz konusu olduğundan, işler daha da sarpa sarabiliyor. Bu ikinci tip durumlarda projelerin ezici çoğunluğunun sabit maliyetle anlaşıldığı gerçeği de göz önüne alınırsa, durumun ne kadar riskli olduğu anlaşılır. Buradaki tek risk proje ekibinin riski değildir aslında. Yani, maliyet sabit tutulurken kapsamın genişlemesi sadece proje için o sabit maliyetin altına imza atan ekip sıkıntıya girmeyecektir. Projenin sahibi olan kurum da, ayırdığı kaynakları boşa sarfetmiş olma ve sonuçta motivasyonel açıdan son derece sıkıntılı bir duruma düşme gibi tehlikelerle karşı karşıya kalacaktır.

Peki bir ihtiyacın kapsam dahilinde olup olmadığına nasıl karar verilir? Aslında bu çok daha teknik bir soru olup farklı teknikler ve yaklaşımlarla halledilebilecek niteliktedir. Tabi olarak projenin stratejisi, iş hedefleri, paydaşların projeden beklentileri, elde etmek istedikleri fonksiyonellik vb. girdiler, projenin kapsamını oluştururken kullanılacak en temel ihtiyaçlardır. Projenin kapsamını belirlerken zaman zaman nelerin içinde olmadığını belirtmek de kafa karışıklıklarını gidermek açısından önemlidir. Kapsam belirlemede en temel problemler, paydaşların gerçekçi olmayan kapsam istekleri, birbiriyle çelişen ihtiyaçlar ve kapsam dahilindeki ihtiyaçların önceliklendirilmesi konusudur.

Paydaşların gerçekçi olmayan isteklere sahip olmalarının en temel sebebi, yöneticilerin sık rastlandığı üzere “ne isterseniz isteyin, yaptırın” tavrı kadar her şeyi “acil” ya da “blocker” statüsünde gören dolayısıyla ihtiyaçlarıyla ilgili herhangi bir önceliklendirme alışkanlığı olmayan kullanıcılardır. Oyuncaklarını paylaşmayan çocuk psikolojisiyle yazılım projelerine girdi sağlanamaz. Ayrıca projelerin pek çok farklı tipte kullanıcıları olduğu gerçeği göz önüne alındığında, her kullanıcı tipinin bu şekilde davranması durumunda projenin çok ciddi riske gireceği aşikardır. Bu tipten önceliklendirme problemlerini çözmek için “Project Champion” rolü ya da Scrum’daki “Product Owner” aslında biçilmiş bir kaftandır. Büyük yazılım projelerinde yukarıdaki bahsettiğim rollerde birden fazla kişi bulunabilir ve belki bu durumda bu rollerin en tepesindeki örneğin “Chief Product Owner” rolü bu noktada karar verici olabilir. Bu iki rolün yer almadığı projelerde iki taraftan yönetsel sorumluluklara sahip kişilerin bir araya gelip, projeyle ilgili karşılıklı özveride bulunarak, projenin yapılabilirliğini ve yetişebilirliğini garanti altına almaları çok sık karşılaştığımız durumlardandır. Burada aslolan, böyle bir noktaya gelmeden projedeki tarafların makul ölçülerde önceliklendirme yaparak anlaşma yoluna gitmeleri ve kapsamı bir kriz durumuna getirmenin sebep olduğu zaman, iş ve motivasyon kaybını önlemeleridir.

Yazılım mühendisliği literatürüne kapsamın yavaş yavaş büyümesi ve bu şekilde kontrolden çıkmasına “scope creep” denir. Bu durumla ilgili son derece komik ve bir o kadar da gerçekçi karikatürler mevcuttur:

Konuyla ilgisi açısından belki şu yazıma da bakabilirsiniz.

Buraya kadar ilk yazı dahil geldiğimiz noktayı şöyle özetleyebiliriz. Yazılım ihtiyaç analizi, adı üzerinde ihtiyaçlar üzerinden ilerler, istekler üzerinden değil. İsteklerini ifade eden kullanıcıların ve diğer paydaşların, bu isteklerin sistemin stratejik hedefleri, müşteri memnuniyeti, paydaş olarak kendi ihtiyaçları vb. girdilerle projenin kapsamını, proje ekibinin de yardımıyla, makul ölçülerde tutmalı ve daima genişleme eğiliminde olan kapsamın projenin başarısızlığına sebep olmasının önüne geçmelidirler.

Bir sonraki yazımızda kapsam dahilindeki ihtiyaçların önceliklendirmesini ele alalım.

Toplam görüntülenme sayısı: 1609

Bir yazılım projesi için en riskli durumlardan birisi de, o projeye girdi sağlayacak kullanıcıların, “işte istediğimiz an geldi, ne istiyorsak yaptıralım” şeklinde bir fikre sahip olmalarıdır. Dünyada hiç bir kimse, istediği her şeyi elde edemiyor, öbür dünyada bu söz konusu olabilir ama bu dünyada daha gerçekçi olmalıyız. Hayallerimiz ile gerçeklik arasındaki bu durum her şeyde geçerli olduğu gibi yazılım için de geçerlidir.

Yazılım zor zenaat, bu çok açık. Bu günlükte bu konuda pek çok yazı yayınlandı. Yazılımla ilgili pek çok şey, onun “zor” olmasına sebep oluyor. Örneğin onun kavramsal olan yapısı, algoritmik yapılarının karmaşıklığı, vs. Bu yazıda yazılımın karmaşıklığının en temel sebeplerinden birisi olan kullanıcı isteklerinden bahsedeceğim.

Yazılım, onu kullanacak olanlar için geliştirilir. Kullanıcılar, yazılım ile işlerini sadece daha hızlı yapmakla kalmaz aynı zamanda daha etkin bir şekilde yaparlar. Bu anlamda yazılım sistemleri çoğu defa iş yapış şeklimizi değiştiriler ya da değiştirmeleri beklenir. Gerçi bu ülkede özellikle devlet kurumlarında eski ve köhne anlayışla uygulanmakta olan pek çok alışkanlığın yazılımlara da taşındığını, bundan dolayı da yazılımların bilgisayarları sadece hızlı ve geniş hafızalı birer daktiloya dönüştürdüğüne çok sık şahit oluyoruz.

Neyse, konumuza dönersek, şunu rahatlıkla iddia edebiliriz ki yazılımlar, kullanıcılarının istekleri için geliştirilmezler. (Tabi yazılımlar derken burada iş yazılımlarını kastediyoruz, oyun ve eğlence sektörüne yönelik yazılımları ayrı bir kategoride değerlendirmek lazım.) Yazılımların bu kadar karmaşık olmasının, bu kadar sık değişmesinin, nihayetinde yazılım şirketleri ile BT bölümlerinin aşırı iş yoğunluğu altında ezilmesinin en temel sebebi, kullanıcıların, işlerini doğru ve etkin bir şekilde yapabilmek için neye ihtiyaçları olduğunu bilmemeleridir. İşine sistematik olarak bakamayan, onun hakkında düşünmek için, yaptığı işi daha basit, kolay ve etkin olarak nasıl yapacağını kurgulamaya, örneğin müşteriye verilecek hizmetin kalitesini arttırmayı düşünmeye vakit ayır(a)mayan kullanıcıların, proje başladığında, o projeye ihtiyaçlarıyla ilgili sağlıklı girdiler üretebilmesi de imkansızdır. Çoğu zaman yeni bir proje, kullanıcıların normal operasyonel iş yüklerinden bir şey eksiltmeden onlara fazladan yük getirdiğinden kullanıcılar tarafından angarya olarak bile görülebilmektedir. Dolayısıyla ne normal gündelik çalışmasında ne de proje esnasında, proje sorumluluklarının bir parçası olarak işini bir yazılım sistemiyle nasıl daha basit ve etkin hale getireceğine odaklanmayan kullanıcının, “ihtiyaçların nelerdir?” sorusuna verecekleri tek cevap, akıllarına ilk gelen ve çoğunlukla ihtiyaç bile olmayan isteklerdir. Bir de buna, “bu bizim için çok büyük bir fırsattır, ne istiyorsanız söyleyin” diye takıma moral ve motivasyon 🙂 aşılayan iş yöneticileri eklenirse varın bakın siz eğlenceye 🙂 Böyle projeler insanı bitirir ama kendileri bitmezler.

Yazılımların ve yazılım projelerinin en büyük risklerinden birisi kullanıcı ihtiyaçlarına değil de kullanıcı isteklerine odaklı olmasıdır. Dolayısıyla “kullanıcı istekleri” kavramı da yazılım ihtiyaçları açısından ele alındığında son derece sakıncalı bir kavramdır. Bu anlamda ben yazılım ihtiyaçları yerine “isterler” denmesine son derece karşıyım. Nedir isterler? Herkes her şeyi ister! Ama yazılımlar istekleri yerine getirmek için değil ihtiyaçları gidermek için geliştirilirler. İnsanların iş ihtiyaçlarına odaklanmadan isteklerine odaklanmaları, yani isteklerini ifade etmeden önce onların ne kadar ihtiyaçlarını gideren istekler olduklarını, ihtiyaçlarıyla ne kadar örtüştüğünü düşünmeleri gereklidir. Aksi taktirde isteklerini yerine getirmesine rağmen ihtiyaçlarını karşılamayan yazılımları kullanmak zorunda kalmaları kaçınılmazdır.

Bu duruma yazılımı geliştirenler açısından bakıldığında ise en iyi tarafından yazılımların bütçe ve zaman açısından planlananın dışına ciddi oranlarda sarkması sonucu ortaya çıkmaktadır. Daha kötüsü ise bitmeyen, iptal edilen projelerdir. Hayata geçse bile böyle projelerde geliştirilen şey, çoğu zaman incik-cıncık özelliklerle bezenmiş dolayısıyla da iç tutarlılığı (integrity) olmayan, nihayetinde kullanışsız, üzerine tonla emek harcanmış  pek çok özelliği kullanılmayan ama buna karşın en temel ihtiyaçlarla ilgili hala eksikleri olan yazılımlardır.

Bu blogda sıklıkla kendisinden alıntı yaptığım F. Brooks “No Silver Bullet” isimli makalesinde yazılımın doğasından bahsederken “uyumluluk” (confirmity) bahsinde bakın ne diyor:

“Uyumluluk: Karmaşıklıkla karşılaşma noktasında yazılımcılar yalnız değillerdir. Fizikçiler “temel” parçaçık seviyesindeki son derece karmaşık nesnelerle uğraşırlar. Fakat bir fizikçi, kuarklarda olsun, birleşik alan teorilerinde olsun hepsi için genel geçer prensiplerin bulunacagına dair sağlam bir inançla çalışır. Einstein, doğanın basitleştirilmiş açıklamalarının olması gerektiğini çünkü Tanrı’nın kaprisli ya da rastgele davranmayacağını ileri sürmüştü.

Böyle bir inanç, bir yazılım mühendisini kesinlikle rahatlatmaz. Çünkü üstesinden gelmek zorunda olduğu karmaşıklığın büyük çoğunluğu rastgele karmaşıklıktır ki pek çok insani kurum ya da sistem tarafından mantıksızca oluşturulmuştur ve yazılım mühendisinin arayüzleri bu yapılarla uyum içinde çalışmalıdır. Yazılım mühendisinin geliştirdiği bu arayüzler, arayüzden arayüze, zamandan zamana değişir ama bu durumun sebebi ihtiyaçlar değildir, sadece Tanrı yerine farklı kişiler tarafından tasarlanmış olmalarıdır.

Pek çok durumda yazılım uyumlu olmalıdır çünkü sahneye en son gelen odur. Diğer pek çok durumda da, yazılımın uyum  yeteneğinin yüksek olduğu düşünüldüğü için uyumlu olmak zorundadır. Fakat bütün bu durumlarda karmaşıklığın büyük çoğunluğu, diğer arayüzlere uyumdan kaynaklanmaktadır ki böyle bir karmaşıklık sadece yazılımın tekrardan tasarlanmasıyla basitleştirilemez.”

Bu yüzden iş yöneticileri hem kendilerine hem de birlikte çalıştıkları kullanıcılara, istekleri üzerinden değil de ihtiyaçları üzerinden hareket etmeleri için zaman ve fırsat tanımalılar, kendilerinin ve çalışanlarının farkındalıklarının bu yönde gelişmesine yardımcı olmalılardır. Aksi taktirde yazılımcılara boşuna saydırmaya devam ederiz.

Toplam görüntülenme sayısı: 1340