Eğer bir ekip içinde yazılım geliştiriyorsak her zaman yeni
teknolojilere ayak uydurmak, yarım kalan işleri tamamlamak, müşteri problemleri
ile uğraşmak gibi sorunlarla başetmek zorunda kalırız. Analist Yazılım Uzmanı
olarak ta kendimizi geliştirmek ve bilgilerimizi çoğaltmak ile yükümlüyüz.
Gelişme eğer temelleri iyi atılmış ise mümkün olur ve izlenen yola göre,
faydaları zaman içinde ortaya çıkar. Yıllardan beri izlediğiniz yöntemler (bir
işe yaramadığını bile bile), okulda öğretilen metodlar, mühendislik
yöntemlerinin yazılım alanında yanlış kullanılması sonucu artık işe yaramaz hale
gelmiş, durağan işleyiş modellerinin değiştirilmesi gerekebilir.
Tabii her değişim bir öğrenme evresi ve eğitim zorunluluğu ile birlikte gelir.
Fakat belli bir yöntemi firma genelinde oturtmak uzun vadede çok daha faydalı
olacaktır. Her yiğidin bir yoğurt yiyişi vardır fakat firmalarında belli bir
yoğurt yiyişi olmalıdır. Firmanın sahip olduğu bu "kişilik" ve "kültür"
çalışanlar tarafından benimsenmelidir. Firmalar kendi içlerinde küçük sosyal
yapılardır ve her sosyal yapının haberleşmeye ve paylaşmaya ihtiyacı vardır.
Ayrıca her sosyal yapının bir de karşıtı (rakibi) vardır ki, ayakta kalabilmesi
ve gelişebilmesi için bu gereklidir. Yani düşman olmadan ilerleme olmaz.
Firma içindeki yazılım geliştirme kültürü ise bu sosyal yapının bir nevi
anayasasıdır. Kurallara uymak ile yükümlü olan çalışanlar anayasa üzerinde
değişiklik yapılması için önergede bulunabilir. Tabii bu anayasanın da
uluslararası yasalara uygun olması gerekir ki firmanın dışarı ile olan
ilişkileri (hem yabancı hemde Türk firmalar) de belli çerçeveler içinde ve
anlaşılabilir düzeyde olsun.
Tepeden inme metodlar, aniden değişen kurallar firma çalışanlarını korkutabilir,
direnişe veya bölünmelere neden olur. Bunu hepimiz çok iyi biliyoruz sanırım.
Fakat sindirilerek ve belirli politikalar uygulanarak yapılan değişiklikler daha
kalıcı olur. Ayrıca bu değişikliğin, verimi arttırdığı görüldüğün de kabul
edilmesi çok daha hızlı olacaktır. Bir iki dinazor çıkacaktır tabii fakat
sebeplerin çok iyi analiz edilmesi ve yeni sistemin öğretilmesi için zaman
harcanması gerekir.
Firmaya yeni kişiler alınırken de firma kültürü ve ahlakı da ortaya konulmalı ve
görüşmeler sırasında adayın bu kurallara aşina olup olmadığı veya öğrenmeye ve
uymaya istekli olup olmadığı, uymazsa sonuçlarının neler olacağı
tartışılmalıdır. Bu şekilde aday seçimi aşaması çok daha verimli olacaktır ve
firmanın geleceği garanti altına alınmış olacaktır.
Buraya kadar yazdıklarımı lütfen yavaş yavaş ve tekrar okuyun. Bir yazılım
firması hayal edip kavramları oturtmaya çalışın.
Bu kadar genel konuşmadan sonra, firma kültürünün nasıl oluşturulacağına,
anayasanın nasıl uygulanacağına, dünyada mevcut uluslararası kurallara bir göz
atalım.
MÜŞTERİ
Bir firmanın varoluş sebebi müşterileridir. Müşterisi olmayan bir firma
düşünebiliyor musunuz? Bu durumda mutlu edilmesi gereken en önemli birim
müşteridir. Mutlu müşteri bedava reklam demektir. Bir yazılım projesinde de en
önemli unsur müşteri gereksinimleridir. Şimdi bir düşünelim; yaptığınız kaç
projede gerçekten müşteri ile yüz yüze geldiniz, müşteriyi dinlediniz veya
müşteri ile bir fikir birliğine vardınız yada müşteriyi tam olarak anladığınıza
inandınız? E o zaman bu kadar önemli bir unsuru neden proje dışında tuttunuz?
Neden müşteriyi iyice dinlemediniz?
Cevap sanırım çok kısa ve klasik, çünkü düşündüğünüz tek şey sonuçta ortaya
çıkacak üründü. Ürüne odaklandığınız için müşteri ikinci plana itildi. Oysa ki
en önemli unsur müşteriler; firmanızın hayatta olma sebebi.
Ürün odaklı sistemler ile müşteri odaklı sistemlerin en büyük farkı müşteri
odaklı sistemlerin devinimsel olmalarıdır. Yani projenin hayat süreci boyunca
müşteri yeni bir şeyler ister sizde bunları uygulamakla yükümlü olursunuz.
Dinamik yapısından dolayı ürün odaklı sisteme göre daha zor gelebilir fakat
işleme modelini bir kere oturttuktan sonra sorun olmayacaktır.
Ürün odaklı sistemlerde ise ürünün ne olacağı, ne yapacağı belirlenmiştir. Belli
bir müşteri kitlesi belirlenmiştir fakat müşterinin üründen haberi yoktur. Eğer
tutarsa ne ala, kar yapabilir fakat batabilirde.
Görülüyorki müşteri odaklı bir sistemin hayatta kalabilme şansı daha fazla ve
riskleri daha az. Müşteri üründen haberdar, ayrıca geliştirme aşamasında katkıda
bulunduğu için memnun ve mesut. Demek ki firmamızın işleme modelinde ilk
değiştirmemiz gereken şey müşterinin önemini anlamak ve ürün yerine müşteriye
odaklanmak. Böylece ortaya çıkacak ürün müşteri gereksinimlerini daha iyi
karşılayacak ve kendi kendini satacaktır. İşte size mutluluğun resmi. Abidin
Dino gibi ressam olmasakta kendi alanımızda mutluluğun resmini yaptık işte.
KÜLTÜR
Firmanın yazılım geliştirme kültürü, işleme modeli ile yakından ilgilidir. Eğer
firmanın işleme modeli genel standartlar içinde ise kalite zaten kendiliğinden
gelir. Burada bahsettiğim firma kültürü, yazılım geliştirme metodolojileri ile
(waterfall, agile, XP vs.) karıştırılmamalıdır. yazılım geliştirme metodu
firmanın işleyiş modeli içine entegre olmuş bir parçadır ve işleme modelindeki
kontrol mekanizmaları ile kontrol edilir. Metodolojinin açıkları veya yetmeyen
tarafları varsa eklenir veya değiştirilir.
Peki nedir bu işleme modeli?
İşleme modeli bir firmanın yaptığı işi ele alış şeklidir. Aynı sektörde olupta
farklı yöntemlerle iş yapan firmalar vardır. Örneğin kimisi tahsilatı aylık
yapar, diğeri peşin çalışır, bir başkası bir al bir bedava der v.b. gibi.
Yazılım firmalarında ise kimisi paldır küldür kod yazmaya girer, kimisi önce
analiz belgelerini yazar, kimisi kalite kontrolü en sona bırakır, kimisi
müşteriyi hiç görmek istemez, kimisi de bazı işleri taşeronlara verir yada Open
Source modülleri kullanmaya çalışır. Kontrol ve işleme modelini geliştirmek gibi
konular üzerinde de fazla durulmaz.
Bir firmanın öncelikle bir organizasyon şemasına ihtiyacı vardır. Bu şemalarda
yapılan en büyük yanlış; görevler yerine isimlerin yazılmasıdır. Sadece
görevlerin yer aldığı bir şema daha motive edici bir şema olacaktır. Her görevin
ne iş yaptığı ayrıntılı olarak açıklanmalıdır. Böylece çeşitli görevler için
atanan kişiler ne yapacaklarını önceden bileceklerdir. Ayrıca atamaların karar
verilmesi için kişinin bir üst pozisyondan yaptığı işleride rahatça görebiliriz.
Problemler için nerelere başvurulacağıda kolayca görünür.
Konumuz yazılım geliştirme olduğuna göre bu konudaki işleme modellerine bakalım.
Çeşitli standart kuruluşları ve Amerikan ordusu bu konuya el atıp bir standarda
oturtmaya çalıştılar, zamanına göre de oldukça başarılı oldu. İlk başlarda çıkan
pek çok standart ürün odaklı idi fakat bu günlerde artık müşteri odaklılar.
Avrupada ISO (International Standards Organisation) bir standart çıkarınca
Amerikada boş durmayıp IEEE (The Institute of Electrical and Electronics
Engineers) ile bazı standartlar çıkardılar fakat biraz bölük pörçük ve acele ye
gelmiş bir standart. Amerika bu işin devlet eli ile olmayacağını anlayınca
Carnegie Mellon - Software Engineering Institue (SEI) ile anlaşıp bu işi
üniversite bazında çözmek için girişimde bulundu ve ortaya CMM (Capability
Maturity Model) çıktı.
IEEE 12207 çok güzel bir işleme modeli ortaya koyuyor ve yazılım firmaları yada
departmanları için ideal. Ayrıca 12207'nin nasıl uygulanacağını anlatan 15504
numaralı bir standartları da var. ISO'da da aynı numaralarla standartlar mevcut.
Maalesef lınk veremiyorum çünkü bunlar paralı satılıyor.
SEI ise bir adım daha ileri gidip hem ISO ve IEEE sentezinde hemde EIA/IS
(Electronic Industries Alliance Interim Standard), IPD-CMM (Integrated Product
Development) ve Capability Maturity Model işleme modellerini aynı potada eritip
CMMI (Capability Maturity Model Integrated) modelini ortaya çıkardılar. Amerikan
ordusu tarafından desteklenen bu proje şimdiye kadar çıkan tüm IEEE, ISO ve
diğer standartların katkısı ve eklenen yeni modüllerle oluştu. Hala da
geliştirilmeye devam ediyor.
Destek anlaşmaları gereği üretilen her ürünün halka açılması zorunluluğundan
dolayı SEI tüm bu standartları kendi örütbağ sitesinde yayınlıyor. 724 sayfalık
CMMI pdf dosyasını indirdiğinizde elinizde hatırı sayılır bir işleme modeli
oluyor ki bunu uygulayabilirseniz ne ala. İlk 93 sayfayı okuyup diğer bölümleri
yeri geldikçe okuyabilirsiniz.
CMMI'ın iki farklı modeli var. Biri "Continues" yani devinimsel diğer ise
"Staged" yani merdiven modeli. (Gene felaket bir çeviri oldu farkındayım :-) )
Merdiven modelinde bir organizasyonun değerlendirilmesi aşağıdan yukarıya her
departman için yapılıyor. Yani size bağlı çalışan tüm departmanlar belli
kriterleri geçmeden CMMI sertifikası alamıyorsunuz. CMMI sertifika sistemi ilk
çıktığında bu model vardı sadece. Genelde insan hayatının söz konusu olduğu
sistemlerde bu model kullanılır.
Öte yandan Devinimsel model ise organizasyon departmanlarını tek tek ele alıp
değerlendiriyor ve CMMI sertifikası veriyor. Yeri gelmişken bu sertifikalardan
da bahsedeyim. 5 adet CMMI sertifikası mevcut, bunlar:
0. Incomplete (Beyaz Kuşak)
1. Performed (Sarı Kuşak)
2. Managed (Turuncu Kuşak)
3. Defined (Mavi Kuşak)
4. Quantitatively Managed (Kahverengi Kuşak)
5. Optimizing (Siyah Kuşak)
Tavsiyem Continues modeli indirip bir göz atmanız ve ilk 93 sayfayı okumanız.
Bir başka modelde SPICE. SPICE size yazılım geliştirme modelinizi tetkik edecek
bir sistem sunuyor. Bu tetkikler sırasında da yapılması gerekenleri anlatıyor.
ISO ve IEC standartları göz önüne alınarak hazırlanmış. Esas dökümanları
olmasada "draft" sürümünü indirip bakabilirsiniz.
Gerekli Linkler:
http://www.sei.cmu.edu/publications/documents/02.reports/02tr011.html CMMI
Continues Model
http://www.sei.cmu.edu/cmmi/ CMMI Ana Sayfa
http://www.sei.cmu.edu/cmmi/adoption/iso-mapping.html ISO9001:2001 ve CMMI
arasındaki benzerlikler
http://www.sqi.gu.edu.au/spice/ SPICE Ana Sayfa
http://www.psmsc.com/
Practical Software Measurement
http://www.sei.cmu.edu/sema/welcome.html Software Engineering Measurement
and Analysis
http://www.sei.cmu.edu/publications/documents/96.reports/96.hb.002.html Goal
Driven Software Measurement