Yazının başlığı bile tartışma konusu oldu.

Yazılım, “olmuyor” değil çünkü. Bir şekilde, işler yapılıyor, oluyor, paralar veriliyor-alınıyor. Belli sürelerde de, bazı şeyler üretiliyor. Ancak, yazılımı yapan da, yaptıran da şikayetçi pek çok yerde. İğneyi de, çuvaldızı da her iki tarafa batırmak lazım. Yazılımın müşterisi ne istediğini ya da ne beklemesi gerektiğini bilmediği gibi, yazılımcı da eldeki iş için gerekli sonuçları nasıl elde edeceğini bilmiyor.

Sonuçta, başlığı böyle attım. Yazılım aslında “olmuyor”, yani “adam gibi” olmuyor. Yarım yamalak olan, iki tarafta da tam bir memnuniyet yaratmayan işleri “olmamış” diye tanımlarsak, yazılım basbayağı olmuyor işte.

Tabii, olayı subjektif bir “adam gibilik” tanımıyla bırakırsak, üzerinde tartışmak yada düşünce üretmek çok zor. “Adam gibi yazılım projesi”nin şartlarını tanımlayalım önce:

“Adam gibi yazılım” kriterleri:

• Yazılım sürecinde, her iki taraf için sürprizler olmaz.
• İki taraf da haksızlığa uğradığını düşünmüyordur.
• Ürün, müşterinin beklentilerini karşılar.

Şaşırtıcı, değil mi? Kriterler arasında teknik herhangi bir kavram ya da laf yok. Düşünürseniz, olması da gerekmiyor zaten. Herhangi bir teknik ölçü getirmeye kalkışırsanız, “kime göre, neye göre” sorusuyla karşılaşırsınız. Dolayısıyla, kriterlerin tamamı insan faktörünü içeriyor. Alan memnun, veren memnun iken, ben ne diyebilirim ki zaten?

Yukarıdaki kriterleri bir de şöyle ifade etmek mümkün: Başarısız her projede, ya beklenmedik bir durumla karşılaşılmıştır, ya en az bir taraf haksızlığa uğradığını düşünüyordur, yada ürün müşterinin beklentilerini karşılamamıştır. 

Sürprizler…

Sürprizler, vaktin çok net olarak nakitle eşdeğer olduğu yazılım projelerinde en önemli sorunlardan biridir. Mesela, elimizde altı aylık bir yazılım projesi olduğunu düşünelim. Böyle bir projede başa gelebilecek (hatta çok defa gelmiş) sürpriz senaryolarından bir kaç örnek verelim:

• Altıncı ayın başında, yazılım ekibi projeyi test amaçlı olarak müşterinin önüne ilk defa koyar. Ancak, proje hiç de müşterinin istediği gibi oluşmamıştır. Sürpriz! Sonrasında, diğer sürprizler bunu takip eder. O noktadan sonra, değişiklikleri yapmak, işi uzatacaktır. Hem de, altı aydan daha fazla uzatacaktır! İki taraflı sürpriz…
• Proje tamamlanır. Tamamlanma itibarıyla, kabul edilebilir düzeydedir. Ancak, sonrasında müşterinin istediği her küçük değişiklik, çok uzun zamanlar alır. Sürpriz! Bazı değişikliklerin ne kadar süreceği hakkında bilgi bile alınamaz, bazı değişiklikler ise, külliyen mümkün değildir…
• Test yaparken şahane çalışan sistem, üretim ortamına çıkınca olağanüstü performans problemleriyle karşılaşır. Sürpriz!
• Projenin altı ayda bitmesi beklenirken, on sekiz ayda biter. Çok fena sürpriz.

Haksızlık…

Haksızlığa uğramış olma, ya da daha kaba tarifiyle “kazık yemiş” olma, iki durumda gerçekleşir. Birincisi, kasıtlı veya kasıtsız, ücretlendirmede piyasa rayiç bedellerinin altında kalınması veya üstüne çıkılması durumudur. İkincisi ise, yukarıda bahsettiğimiz sürpriz durumunda, ortaya çıkan maliyetin taraflarca bir şekilde paylaşılmak durumunda kalınması durumudur.

Birinci durum aslında açıktır. Müşterinin veya yazılımcının piyasa tecrübesizliğinden veya düpedüz kazıkçılığından ortaya çıkar. Kaçınması pek kolay değildir, çünkü en iyi yazılımcılar ağzı en iyi laf yapan adamlar değildir; aksine iyi yazılımcı insanla değil makinayla iyi anlaştığı için yazılımcı olmuştur zaten.

Yazılımcılar, en çok “normal iş şartları buymuş gibi” gece-gündüz fazla mesaili olarak çalıştırıldıklarında kendilerini haksızlığa uğramış sayarlar. Haklıdırlar da. Bu sıklıkla, proje süresinin “tepeden inme” verilmesinden oluşur. Yani, “şunu altı ayda istiyorum” gibi. Öte yandan, yazılımcıların ezici çoğunluğu, çok çalışmaya karşı değildir aslında. Bundan zevk de alırlar. Kendi verdikleri süreyi tutturmak için 7/24 dahi çalışsalar, gıkları çıkmayacaktır.

Müşteri ise, sürpriz olarak proje süresi uzadığında kendini haksızlığa uğramış hisseder. Bu durumda, ya süre başına ödeme yapılır (müşteri haksızlık olduğunu hisseder) ya da proje bedeli sabit kalır (yazılımcı haksızlığa uğradığını hisseder).

Müşteriye çok küçük görünen değişiklikler, gelinen noktada, yazılımcı için çok maliyetli bir işe dönüştüyse, iki taraf birden kendini haksızlığa uğramış hissedecektir!

Beklentileri Karşılama(ma)…

Beklentiler karşılamama durumu, pek çok durumda müşterinin kendi beklentileri hakkında bir fikri olmamasından kaynaklanır. Beklenti, “iyi olsun, güzel olsun”dan öte değildir çünkü. Buna, klasik yazılımcı iyimserliği ve de yazılımcının kendisine kolay geleni yapma alışkanlığı eklenince, günün sonunda projenin beklentileri karşılama olasılığı pek yoktur.

Yazılımcı refleks olarak en kısa sürede makinasıyla baş başa kalıp kod yazmak istediğinden, müşteri de en kısa sürede işlerin bitmesini istediğinden, işin başında beklentileri, gereksinimleri belirlemeye yeterince vakit ayrılmaz. Öte yandan, herkes gereksinimler üzerine anlaşıldığını da zanneder. Ama iki tarafın anladığı aynı şey değildir ki… Bu şekilde şekillenen bir projenin, herhangi bir beklentiyi karşılama ihtimali yoktur.

Çözüm Nedir?

Çözüm nedir? İfade ettiğimiz kriterler, insan bazlı olduğundan, çözüm de aslında insan bazlıdır. Teknik olarak yapılabilecek bir şeyler yok mudur? Elbette vardır ve önemlidir, ama onlar nihayetinde “Adam Gibi Yazılım” üretme amacında kullanılacak araçlardır.

Çözüme, ancak hem müşteri hem de yazılımcının doğru yöndeki davranışlarıyla ulaşılabilir. Önce müşteriyle başlayalım:

Müşterinin Bilmesi ve Yapması Gerekenler

Yazının başından beri, bir müşteri lafıdır gidiyor. Müşteri dediğim zaman, bir işini halletmek için yazılımcıyla işi olan herhangi birini kastediyorum. Genel olarak yazılımdan anlamayan, ama yazılımcı takımına iş yaptırmak isteyen biri yani. Şirket içinde kırık plaza dilimizle “business tarafı” dediğimiz adamlar da olabilir, bir şirketin ortağı da olabilir, dışarıdan başka bir şirkete iş yaptırmaya çalışan biri de olabilir. Ortak nokta, yazılımcıdan kendisi yapamayacağı bir işi çıkartmak isteyen insan olmasıdır.

1. Korkacak Bir Şey Yok!

Gerçekten yok. Yazılımdan anlamıyor olabilirsiniz. Hatta teknolojiyle aranız çok iyi olmayabilir. Gerek olan tek şey, beklediğiniz ürünün kullanıcısı olmayı istiyor olmanızdır. Mesela, birine e-ticaret sitesi yazdırmaya niyetleniyorsanız, e-ticaret sitesi yapmayı bilmenize gerek yok. Ancak, girip e-ticaret sitesi kullanabiliyor olmanız gerekir. Yoksa, ehliyeti olmadan otomobil satın almaya çalışan adam durumuna düşersiniz. (Ehliyet olmadan şoförünüz varsa araba alabilirsiniz. Aynı şekilde, e-ticaret sitesi kullanmadan, e-ticaret sitesi kullanan adamlarınız varsa, e-ticaret sitesi yaptırabilirsiniz elbette.)

2. Projede Siz de Çalışacaksınız!

İşinizi siz biliyorsunuz. Yazılımcı ise, bilgisayara iş yaptırmayı bilir. İşin içinden, yazılımcıya işin başında kısa bir süre ayırıp, sonra işin yapılmasını ona bırakarak çıkabileceğinizi düşünmeyin. Bizde yine plaza dilinde “brief vermek” diye bir şey var. “Brief”, adı üzerinde, “kısa” demek. İşin en başında “brief” vermek önemlidir, ama bu “kısa”nın bir de “uzun”u olması gerektiğini bilin. O “uzun” dediğim şeye, “spesifikasyon” denir. Bu dokümanın kim tarafından ve nasıl oluşturulacağı değişebilir (iş analistiniz olabilir, ya da ürün müdürünüz, ya da yazılımcı/analist biri de hazırlıyor olabilir) ancak bunun oluşmasında sizin katkınızın çok ama çok önemli olduğunu unutmayın. Muğlak kalan her noktada, kararı -aslında sizin işinizi sizin kadar iyi bilmeyen- yazılımcıya bırakıyorsunuz demektir.

Baştan da söyledğimiz üzere, yazılım işinde, vakit net olarak nakittir. Projede siz de çalışacağınıza göre, zaman zaman sizden beklenen ve “bloke edici” pozisyonunda olan işler olacaktır. Tasarım beğenmek ve karar vermek, belli bir fonksiyonaliteyi test etmek, belli ayrıntılar hakkındaki sorulara cevap vermek gibi. Bu işleri, olağanüstü ciddiye alıp, üstün öncelik vermeniz gerekir. “Canım o arada yapacak başka işleri mi yok?” diye düşünmeyin. İş değiştirmek, verimin en büyük düşmanıdır. Ayrıca, hızlı geri dönüşler, sizin işe verdiğiniz önemin göstergesi olacak ve yazılımcıların motivasyonunu pozitif etkileyecektir.

3. İsteklerinizde Düzenli ve Tutarlı Olun!

Hiç bir proje ilk istendiği ve yapıldığı şekliyle bitmez. Bitmesi de beklenmemelidir zaten. Dolayısıyla, bütün proje boyunca çok sayıda istek ve düzeltmeniz olacaktır. Yapabileceğiniz en kötü şey, istekleri aklınıza geldiği sırayla ve o anda aklınıza gelen ilk yöntemle bildirmektir.

O anda gördüğünüz hata veya eksiklik, size dünyanın en önemli problemi gibi görünse de, muhtemelen değildir. Projede planlanan işlerle ve daha önceki (hatta daha sonraki) isteklerinizle karşılaştırıldığında, bir öncelik sıralaması vardır. Bunu o anda elinize gelen ilk yöntemle yazılımcıya iletirseniz, iki şeyden biri olur: Ya bu istek gözardı edilerek kaybolur yada haketmediği bir öncelik alarak en ön sıraya geçip daha önemli işleri engeller.

İstekler, bir ve yalnız bir kanal üzerinden, önce iş için kıymeti, daha sonra yazılımsal maliyeti belirlendikten sonra, bir öncelik değerlemesi üzerinden yazılımcıya iletilmelidir. Bunu yapmak için muhtelif araçlar vardır; yazılımcınız böyle bir şey kullanmıyorsa, siz talep edin. (Bakkalınızdan ısrarla isteyiniz tadında oldu bu ya, neyse.) Bu işin “düzen” kısmını halledecektir.

İkinci mesele tutarlılık. Tutarsızlık şöyle oluşur: Bir işi yapmanın iki yolu vardır. A ve B diyelim. Önce A olarak yapılsın istersiniz. Sonra bunu beğenmeyip B’ye çevirtirsiniz. Buraya kadar sorun yok. Sonra yeniden A’ya çevrilmesini istediğinizde, problem başlıyor demektir. Sonra yeniden B mesela… Tepki olarak yazılımcılar bir süre sonra isteklerinizi göz ardı etmeye başlayacaktır, “nasıl olsa yine değişecek” diye. Haksız da değillerdir hani.

4. Süre Tahmini Hakkındaki Gerçekleri Bilin!

“Matbaacının Kanunu”nu unutmayın:

• Hızlı
• Ucuz
• Kaliteli

hernangi ikisini seçin!

Yani, üçü bir arada olmaz. Üçü bir arada olmayacağı gibi, herhangi birini yükseltmek için, aslında diğer ikisini kısmanız gerekir.

“Bunu süre tahminiyle ne ilgisi var?” diyebilirsiniz. Yazılım işinde marifet, hız, kalite ve maliyeti dengeli bir noktada tutmaktır. Kalitede belli bir seviyenin altına düşerseniz, ürününüz kullanılmaz ve projeniz başarısız olacaktır. Nihai amaç bir fayda sağlamak olduğundan ve kaynakları verimli kullanmak istediğimizden, maliyeti de belli limitlerde tutmak isteriz. Dolayısıyla, proje kapsamı, kalite ve maliyet limitleri ile beraber, proje süresini ortaya çıkartacaktır.

Proje süresi hesaplamak, zor ve çaba gerektiren bir iştir. Yani, yapılmaması gereken iki şeyi hemen sıralayalım:

• Önceden süreye kendiniz karar vermek.
• Hemen masada “ne kadar sürede yapılır” diye sorup, cevap beklemek.

Süreye önceden kendiniz karar vermek, müşteri olarak yapabileceğiniz en zarar verici hareketlerden biridir. Hız-maliyet-kalite üçgeninde, hız kısmını baştan sabitliyorsunuz demektir. Yani, aslında en son hesaplanması makul olan parametreyi, baştan belirliyorsunuz. Tam gerekli süreyi tahmin ettiyseniz, nihai olarak tek sorun, yazılıcıların işe sizin bu işten anlamadığınızı ve anlamak istemediğinizi düşünerek başlamaları olacaktır. Süreyi kısa tahmin ettiyseniz, felakete doğru yelken açmışsınız demektir. Kalite-maliyet ikilemini ne yapsanız çözemeyeceksinizdir çünkü. Süreyi uzun tahmin ettiyseniz, eh o proje o süreyi doldurmak üzere kendiliğinden zaten sarkar…

Süre tahmini, zor bir iştir. İş üzerinde çalışacak insanlar belli olmadan, süre tahmini yapılamaz. Doğru süre tahmini, iş kapsamı ve ihtiyaçlar belirlendikten sonra, işi yapacak olan ekibin oturup, iş bölümüne karar vermesiyle olur. Yapılacak işler, en uzunu iki günü geçmeyecek birimlere bölündükten sonra, ortaya bir süre çıkar. Böyle belirlenmiş bir sürenin altına, işi yapacak herkes imzasını atmış olur.

Bu şekilde çıkartılan süre, eğer o ekip öyle bir işi önceden yapmamışsa, halen %50 hata payına sahiptir! Ekip, benzer bir işi önceden yaptıysa, hata payı %30’a iner. Ancak ve ancak, ekip o işin tıpkısının aynısını önceden yaptıysa, hata payı %10 civarına inebilir.

Bir de, herhangi bir proje planlama esnasında, “kara delik” diye bir kavram vardır. “Kara delik”, ekipten kimsenin nasıl yapılacağını tam olarak bilmediği problemleri ifade eder. Bunların ne kadar zaman alacağını net olarak anlamak için, önce üzerlerinde zaman harcamak gerekir. Proje süresi çıkartma esnasında, böyle bir zaman harcamak mantıklı olmadığından, bunlar “kara delik” olarak kalır. Bu durumda, proje süresi, mesela, “dört ay artı iki kara delik” şeklinde çıkabilir. Genelde, bu kara deliklere ya bir süre “uydurulur”, ya da sıfır süre atanıp, süre müşteriye öyle bildirilir.

Kara deliklerin varlığını, daha önemlisi, projenin nerelerinde var olduğunu bilmek sizin için önemlidir. Yazılımcınıza bunları sorarsanız, öğrenebilirsiniz. (“Kara delik” terimini her yazılımcı bilmeyebilir. Ama “Projenin süre tahmini en zor, en riskli yerleri nereleri?” diye sorarsanız, cevap alırsınız.)

Baştan verilen sürenin, her durumda bir “tahmin” olduğunu unutmayın.

Yazılımcının Bilmesi ve Yapması Gerekenler

Yazılımcılar, sütten çıkmış ak kaşık mı? Değil. Müşeriye atıp tutarken iyiydi, şimdi sıra yazılımcıya geldi…

1. Müşteri Ne İstediğini Bilmez. Bilmemeye de Hakkı Vardır.

Müşteri velinimettir.

Bunun üzerine bir kaç dakika oturup düşünün. İçinize sindirin. Memnun edemediğiniz her müşteri için elliden fazla müşteri kaybedersiniz. Sözün ne kadar eski olduğunu da düşünün bu arada. “Velinimet” falan geçiyor içinde! “Velinimet”in İngilizce tek kelime karşılığı var, “benefactor”; Türçesi ise “birine, etkisi yaşadığı sürece sürecek bir iyilik ve bağışta bulunan kimse” demek.

“Müşteri ne istediğini bilmez” derken, demek istediğimiz, projenin başından, tam olarak ne istediğini ayrıntılarıyla tarif edemeyebilir. Herkes “vizyon sahibi” değildir. Bu içi boşaltılmış laflardan biri, ama orijinal olarak, bir şeyin nasıl olacağını, nasıl işleyeceğini önceden tasarlayıp kafasında canlandırabilmek demektir. Az insanda bu yetenek bulunur. (“Vizyoner” falan derler…) “Vizyon sahibi” olmak, müşteri olmanın ön şartı değildir, olamaz da. Yani, müşteri nihai ürünün neye benzemesi gerektiğini bilmez. Bilmemeye de hakkı vardır. Hatta, bazen bildiğini zanneder. Hatta ve hatta, bildiğini iddia eder!

Bu ahval ve şeraitte dahi, birinci vazifeniz, müşterinin tam olarak probleminin ne olduğunu anlayıp, onun problemini çözecek ürünü ortaya çıkartmaktır.

2. Ne Yaptığınızı Anlamadan, Yazılım Yapmaya Çalışmayın!

Kalite üretmek ilk olarak sizin işinizdir. Kaliteyi kontrol etmek başkalarının işi olsa da, siz kaliteyi üretmeden istedikleri kadar kontrol etsinler…

Eğer ne üretmeye çalıştığınızı bilmiyorsanız, kalite üretmeniz mümkün olmaz. Sık sık karar vermek zorunda olduğunuz “trade-off” (Türkçesi var mı bunun? “Ödünleşme” veya “ödünleşim” fena gitmiyor sanki..) kararlarını doğru veremezsiniz. Önceliklerin ne olduğunu düzgün anlayamazsınız…

Daha da kötüsü, ne yaptığınızı anlamazsanız, müşterinin ihtiyacını değil, söylediğini yaparsınız. Sonra, ihtiyacı karşılamadığı için yeniden yaparsınız onu…

3. Siz Kendi İşinizi Yönetmezseniz, Başkası Yönetir.

Diyeceksiniz ki, “Müdür bu, buna konuş…” Lafım elbette müdüre de, ancak “sade yazılımcı” olarak da, kendinizi yönetmekle sorumlusunuz.

İşinizin salt kod yazmaktan ibaret olduğunu düşünmeyin. Kod yazmak, test yazmak, “debug” etmek, doküman üretmek (kod içinde yada dışında), süre tahmininde bulunmak, müşteriyle iletişmek, gereken araştırmayı yapmak, “code review” yapmak… Bunların hepsi işinizin parçasıdır. Bunları dengeleyip, zamanınızı doğru kullanamazsanız, işinizi tam anlamıyla yapamazsınız.

Eğer yazılımı yönetiyorsanız (müdür, sözüm sana) o zaman sağlam bir de “omurga sahibi” olmak zorundasınız. Yani, müşteriden işlerin daha hızlı olması için mutlaka her aşamada baskı gelecektir. Elbette kendinize yan gelip yatma süresi çıkartmak için değil ama, işlerin hakkıyla yapılması ve projenin başarıya ulaşması adına, gelen baskılara göğüs germeniz gerekir. Eğer bir noktada kırılırsanız, bunun sonu gelmeyecektir. Sonuçta, her gelen basıkya boyun eğer ve elemanlara iletirseniz, yazılım yöneticisi değil, “trafik polisi” olursunuz. Yani, oradan geleni buraya, buradan geleni şuraya gönderen birisi olursunuz.

Müşteri velinimettir. İhtiyaçları çözümlenmelidir. Ancak, yazılım yönetimi müşteriye bırakılamaz.

4. İteratif ve Çevik Olmak Zorundasınız.

Geçen yıllar içinde, yazılım aleminde net öğrendiğimiz bir şey varsa, işte yukarıdaki satırda yazdığım şeydir. Tek yönlü, “waterfall” şeklinde bir çalışma sistemiyle başarıya ulaşmanız mümkün değildir. Yani, gerekninimleri toplarlarım, analiz yaparım, kod yazarım, test ederim, üretime geçerim… Bu formül o kadar çok defa işe yaramamıştır ki, aslında artık bir yönetm olarak değerlendirilmemektedir bile…

“İteratif” nasıl olunur konusunda, çok miktarda yöntem var. Bunların arasından size en uygun olanını seçebilirsiniz. Temel mesele, yukarıda söz ettiğim, baştan projenin varması gereken yeri bilmemenin, projenin başarısızlığına yol açmasını engellemektir. Mümkün olan en kısa sürede ortaya (daha sonra çöpe atılacak olsa bile) görünür bir şey çıkartırsınız. Ondan sonra, müşteriyle beraber kısa iterasyonlarla (haftalık civarı diyelim, günlükten aylığa kadar uygulanıyor, proje boyutlarına göre) hedefe doğru ilerlersiniz.

Çeviklik ise, genel anlamıyla, geliştirme esnasında meydana gelen gereksinim değişikliklerine hızlı cevap verebilme yeteneğini kasteder. İteratif olmak, çevik olmanın şartlarından biridir diyebiliriz. Bundan ötesinde, çevik olmak için düzgün kod alışkanlıkarı, otomasyon kültürü, iyi bir mimari ve sağlam sistem yönetimi de gerekir.

5. Mesleğinizi İyi Bilin, Alet Çantanız Geniş Olsun.

Eğer elinizdeki tek alet çekiç ise, her şey gözünüze çivi gibi görünmeye başlar. Mesela, bildiğiniz tek dil PHP ise, her projeyi PHP ile yazma refleksinde olabilirsiniz. Ya da .NET ile. Veya Java. Problem, çekicinizin hangi marka olduğu değil, alet çantanızda sadece çekiç bulundurmanızdır.

Hızlı prototipleme için bir silahınız mutlaka olmalıdır. Hatta, muhtelif “mock-up” veya “wireframe” üretim araçlarını da kullanmak, size süre ve müşteri ile iletişimde kolaylık sağlayacaktır.

İşin farklı parçaları için eğer uygun oluyorsa, farklı dil ve teknolojileri kullanmaya çekinmeyin. Aletlerinizi iyi tanıyın, size ne getirip ne götürdüğünü, güçlü ve zayıf yanlarının ne olduğunu iyi bilin ve anlayın. Çivi varsa çekiç, vida varsa tornavida, duvar varsa matkap çıkartmayı iyi bilin.

Konu bitti mi? Muhtemelen bitmemiştir. Öte yandan, koca bir kitap olacak konuyu, bir yazıda bu kadar özetleyebildim. Yazılar sürecek…