Yazılım Projelerinin Başarısızlığındaki Teknik Nedenler

Son yayınlamış olduğum yazımın sonunda bir sonraki yazımda  yazılım projlerinin  başarısızlık nedenlerinden  bazılarını irdeliyor olacağım demiştim.Sözümü tutma zamanı.

Başarısızlık nedenleri  3 grupta toplayacak olursak bunları şu şekilde sıralayabiliriz.

1. Teknik yanlışlıklardan kaynaklı  sebepler
2. Yönetimsel yanlışlıklardan kaynaklı sebepler
3. Sosyal etmenler

Bu yazımda  teknik nedenleri biraz irdelemek istiyorum .

Teknik nedenleri   belirtmede önce  temelde teknik nedenler den ne kast ediliyor onu  benim kurğuladığım  bir örnekle anlatmak istiyorum .

Siz bir kaptansınız  Türkiyeden Amerikaya  bir deniz yolculuğu yapacaksınız.Size diyorlarki bu gemiye yanına 100 kişilik  bir yolcu veriyoruz .Bu yolculuğun  her adımından siz sorumlusunuz.Bu kişileri Amerikaya sağ salim en güzel şekilde  ulaştır deniyor.

Sizin bu yolculuk öncesinde bu yolculuk için  Hangi özelliklere  sahip olan hangi büyüklükte  gemi ile yolculuğa  çıkacaksınız önce bunu belirlemelisiniz  yeterli büyüklükte okyanus dalgalarına dayanamayacak zayıflıktaki gemi ile   muhtemelen okyanustaki ilk fırtınada geminiz alabora olacaktır.

Projelerinizde bu gemi gibi batmasın
(www.yasarerkan.com)

Geminin büyüklük ve dayanklılığını iyi belirlemeniz yetermi tabiki hayır.Yolculuğa çıkmadan önce testlerin iyi yapıldığından emin olmalısınız  .Belki yolculukta gemide olşabilecek hasarlar için teknik personelinizi  yanınıza almalı hasarın giderilidiğinden emin olmaları için testlerin en iyi şekilde yapıldığından emin olmalısınız. 

Yolculuk için  gerekli olan gereksinimleri çok iyi tespit etmeli  gemideki mürettebat sayısınından  varından onların niteliğine varanaka kadar iyi belirlemeli.Personelin ve yolcuların sağlık ,yemek  vb ihtiyaçlarını iyi belirlemeli ve yeterli malzeme miktarını iyi hesaplamalısınız , bittimi hayır.Yolculuk süresince  hava ,deniz basınç ,rüzgar vb koşulları iyi analiz etmelisiniz.


Bu örneği ben bırakada bırakıyorum siz isterseniz devam ettirebilirsiniz.Bunlardan herhangi birini  doğru yapmazsanız bu yolculuk başarısız sonuçlanabilir.

Bu örnek deki yolculuk için gerekli olan doğru geminin karar verilmemesi durumunda okyanustaki  muhtemel  fırtınalardagemi nasıl alabora olursa  yazılım projenizdeki yazılım teknolejinizi iyi seçmezseniz  proje başarısız snouçlanabilir.
Personel   gereksinimliliklerini ve yeterliliklerini iyi tespit etmezseniz gemide kaos olması muhtemel olabileceği gibi projenizdeki ekibinizi iyi belirlemez yeterli kaynakları tespit edip  yeterliliklerini ölçemezseniz projedeki kaoslara  hoş gelsin diyebilirisniz.

Yolculuk için yolcuların ve personelin  sağlık ,yemek vb gereksinimleri iyi tespit edilip analiz edilmediğinde yolculukta büyük krizlere salğın hastalıklara hazır olunması gerektiği gibi  sizde projenizdeki fonksiyonel gereksinimlerini,  paydaşların ve ekip gereksinimlerini iyi analiz  edemezseniz projenin başarısızlığı yine muhtemeldir.

Nasılki geminin testlerini iyi yapmazsanız. Nelerle karşılabilceğinizi tam olarak sadece Allah bilir.Yazılım projelerindede siz gerekli testleri  yeterince ciddiye alarak yapmazsanız gerçek ortamda nelerle karşılaşabilceğinizi  Allahtan başka kimse tam olarak bilemez.

Bu örnek üzerinden teknik bazı yanlışlıklardan bahsettim sanırım bukadarı bu örnek için yeterli.

Maddeler halinde sıralayacak olursam şunlar ilk bahsedebileceklerim :

• Etkin olmayan yanlış yazılım teknolejisi ve araçlarının  seçimi
• Mimari alt yapı seçimindeki yanlışlık
• Gereksinimleri iyi belirleyememesi
• Ekibin teknik bilgi yetersiliği
• Testleri iyi yapmama
• Tasarımın başarısızlığı
• Kod denetimlerini ya hiç yapmamak yada yetersiz yapmak
• Uygun veri tabanı ve tablo tasarımının yapılmaması

bunlar çoğaltılabilir  tabiki.Ben bazılarını sıraladım .Bence bunları madde madde bilmek önemli değil .Mesele projerin  başarısız sonuçlanmasındaki teknik nedenleri ve önemini kavrayıp bunlara doğru yaklaşımlarla çözüm üretmek.

Yaşar ERKAN(PMP)

Endüstri Mühendisi

Proje Ekibinin Ve Proje Yöneticisinin Projenin Başarısındaki Önemi

Bu yazıma ilginç bir araştırma sonuçlarıyla başlamak istiyorum. Amerikada 23000 uygulama incelemeye alınarak yapılan bir araştırmada  yazılım projelerinin sadece % 26 sı başarılı şekilde sonuçlanıyor.

Bütçesini ve zamanını aşan proje oranı %46, iptal edilen proje oranı %28 dir.İnanılmaz rakamlar bence.
Bu oranlar gösteriyorki aslında bir projeyi başarılı şekilde bitirmek hiçde kolay iş değil.

Bir proje hangi durumlarda başarısızdır peki:

• Tamamlanmadan iptal edilirse,

• Tasarlanmış bütçesini aşarsa,

• Öngörülen tamamlanma süresinden daha uzun sürerse,

• Önceden belirlenen özellik ve işlevlerin daha azını karşılarsa

başarısız olmuş demektir. 

Yukarıdaki ilk maddenin gerçekleşmesi mutlak başarısızlık (absolute failure), diğerleri ise
göreceli başarısızlık (relative failure) olarak da adlandırılır.

Başarısızlığın  nedenlerini gruplarsanız 

1. Teknik nedenler
2. Yönetimsel nedenler
3. Sosyal nedenler
4. Diğer nedenler diyebiliriz

Ben bu yazımda sosyal nedenlerden bahsediyor olacağım.
Aşağıdaki resmi önceki yazılarımda paylaşmıştım.Bu resim PMBOOK tan alıntıdır.



Proje ekibinin  (resimdeki diğer proje takım üyeleri diye gruplanan) farklı kişisel özelliklere sahip  bireylerden oluşması  muhtemeldir.Özellikle bunlar arasındaki uyum inanılmaz önemlidr.Yanlış anlaşılması diğer paydaşlarla olan uyum ve iletişim önemsizdir sadece bunların  uyumu ve iletişimi önemlidir demek istemiyorum .

Ancak bu kadro aslında çekirdek kadrodur ve bunlar arasındaki uyum  lokomotif etkisi yapıp projeyi başarıya sürüklemede çok etkili olabilir.Ancak aksi bir durumda negatif yöndede o derece başarısızlığa  götürme  gücüne sahiptir.



Yukardada belirttim burada  farklı kişisel özelliklere sahip insanların bulunması güçlü  ihtimal.İnsanları kişisel özelliklerine göre  kategorilere ayırmışlar.Bununla ilgili internette bir şema gördüm çok güzel özetlenmiş onu paylaşayım.İncelemenizi  tavsiye ederim.

Benim kişisel kanaatim ideal bir ekipte bu kişisel özelliklerin tamamından kişilerin bulunması projenin başarısına pozitif katkı sağlayabilir.Tabiki bunların uyum içinde  çalışmasının sağlanmasında en önemli faktör proje yöneticisinin  bu noktadaki yönetim becerisi ve performanstır.

Proje yöneticisinin bunu yapabilmesinin yoluda   ekibindeki kimin hangi kişilik  özelliklerine sahip olduğunu  gözlemleyip analiz edebilmeli ve  buna göre bu insanları ortak bir hedefe projenin başarısı için yönlendirebilmeyi başarabilmelidir.

Proje ekibinin ortak hedefe kitlenmesi.
(www.yasarerkan.com)

Yoksa sadece işi veya kişileri yönetmekten öteye gidemez ve gerçek  proje başarısını yakalaması oldukça  zora girer.Proje yöneticisi  ekip üyeleri arasında yaşanabilecek  stresli durumlarda Stres yönetimini başarılı şekilde yürütebilmeli.Ayrıca bu çatışmalarda nasıl bir yaklaşıma sahip olması gerektiğini  hızlıca belirleyebilmeli (Çatışma yönetimine ilişkin daha önceki yazıma buradan ulaşabilirsiniz"  Proje Yönetimiminde Çatışma Yönetimi ".)

Özetle ekipde farklı kişisel özelliklerinin olması   proje yöneticisi tarafından iyi yönetilirse bir problem olmamakla birlikte pozitif bir etkisi dahi olacağını düşünüyorum.Projelerin başarısız sonuçlanmasında ekibin kişisel özellikleri dikkate alınmaksızın iyi yönetilmemesi tabiki tek neden olamaz ama bu husus bile başarısızlığa götürebilir. Bir sonraki yazımda da başarısızlık nedenlerinden bir kaçını daha irdeliyor olacağım.

Yaşar ERKAN(PMP)
Endüstri Mühendisi

Yazılım Projelerinde Test Süreci Ve Önemi

                    Bu yazımda özellikle yazılım projelerindeki test sürecinden bahsetmek istiyorum.

Nedense  bu süreç yazılım projelerinde nekadar kabul edilmesede en yüzeysel geçilen en az zamanın, kaynağın ayrıldığı  süreçtir.Aslında kesinlikle bu işin daha uzmanca bir bakış açısıyla ele alınması ve tamamlanması gerekir. Genelde ülkemizde hele bir başlayalım ara ara test ederiz hallederiz ,nasılsa herkes test yapabilir bakış açısıyla  değerlendirilen süreç.Ama kanaatimce bu çok yanlış ve aslında maliyetli bir bakış açısı.Peki test nedir ona bakalım.Dokumanlarda  yer alan bazı tanımları aktarmak istiyorum.

Ürünün beklenilen saviyede  olduğunu belirlemek ,değilse de istenilen ölçüye gelmesini sağlamak için
yürütülenbir süreçtir.Bir diğer tanım geliştirilen bir yazılımın  sistematik olarak  kontrol edilmesi sürecidir. Tanımı

aktarmışken hemen ardından test türlerinnde bazılarından bahsetmek istiyorum .

Aşağıda belirttiğim test türleri tabiki hepsi değil.Bu sektördeki herkesin bilmesi gerektiğini düşündüğüm test
çeşitleri.

·       Bırımtest:Çalışan bir kod parçası ya da modül için, geliştiriciler tarafından gerçekleştirilir.Düşük seviyede işlem gerçekleştirir.

·        Tümleyim testi(Integration testi):Bir uygulamanın farklı bileşenlerinin beraberce  uyum içinde çalışıp çalışmadığı kontrol edilir.

·        Regresyon testi:Uygulamada  ve uygulama ortamlarında  gerekli değişiklikler  ve sabitlemeler  yapıldıktan sonra  yeniden yapılan testlerdir.

·        Performans testi:Bu test çoğu kez yük testi ile aynı anlamda kullanılır.

·        Kullanıcı kabul testi:Son kullanıcı veya müşteri siparişine uygunluğun alındığı testtir.

Testler  aslında sistemde yer alan hataların yakalanması amacıyla yapılıyor.Peki hatalar neden oluyor .Bir çok
nedeni  var tabiki ama ilk aklıma gelenlen şunlar:

·        Yazılım ürünü insanlar tarafından yazılan kod lardan oluşur.İnsanlar birşeyleri bilebilir ama herşeyi değil bu nedenle hep bu şekilde düşünüp yazılımcı hata yapmış olabilir diye bakmak önemli. İnsanlar yetenekli olabilir ancak kusursuz değillerdir

·        Zaman kaygısı  kaliteyi düşürür.Kontrol için  yeterince zaman kalmamış veya verilmemiş olabilir.Yarım kalmış yapılar olabilir

·        İşi birden fazla yazılımcı yapmış olabilir. Bir yazılımcı  konusunda  uzman  iken diğeri asistan seviyesinde olabilir.

Hatalar nekadar  erken tespit edilirse maliyeti bize o kadar az olur.Bu maliyet göz önünde bulundurularak test süreci gerçekten  dikkat edilmesi ve önem verilmesi gereken bir süreçtir.

Bu maliyet aslında çok bazit Aşağıdaki grafik hatanın zaman içindeki maliyetini göstermektedir.

 

Hatanın zaman içindeki maliyeti

Test sürecinin yazılım sürecindeki yerini gösteren şemayada göz attığımızda test yapma sürecinin yazılımın başlamasından bir süre sonra başlayabileceğini söyleyebiliriz.Teste hazırlık ise analiz sürecinin  başlaması ile başlayabilir diyebiliriz.

Testin önemini ve maliyetini göstren ufak bir  projeksiyon  paylaşmak istiyorum.Yazılım hatalarının amerikan ekonomisine maliyeti yıllık yaklaşık 60 milyar $  olduğu tahmin ediliyormuş .Ciddi bir rakam değilmi.

Test sürecinin  bazı temel ilkeleri vardır şimdi bunlara bir göz atalım isterseniz.

1.     Test defect in varlığını gösterir:Test defectin ,bug ın varlığını gösterir ama yokluğunu ispat etmez.Sadece keşfedilmemiş bugların olma olasılığını azaltır.Hiç bug bulmamış olmak hata yok anlamına gelmez.

2.     Herşeyi kapsayan test mümkün değildir.Herşeyi test edemeyiz dolayısıyla risk analizi yapıp öncelikler belirlemeliyiz

3.     Erken test:Yazılım yaşam döngüsünde  mümkün olduğunca erken teste başlanmalı ve  tanımlı hedeflere odaklanılmalı

4.     Pesticide Paradoksu:Aynı testler üst üste tekrarlandığında  potansiyel diğer bugları yakalama şansı azalıyor

Yukardada ifade ettim testyapan kişinin  bu işi   uzmanlık bakış açısıyla ele alıyor olması  yeterli  bilgiye, deneyim ve tecrübeye sahip olmaı gerekir .Test yapan kişide aslında bazı temel özelliklerin olması gerekir diyebiliriz.Peki bunlar nelerdir ilk aklıma gelenler şunlar:

·        Şüpheci olmak durumundadır

·        Sistemdeki hataları bulmaya istekli ve hırslı olmalı

·        Sabırlı olmak  zorundadır

·        Detaycı olmak durumundadır

·        Dikkatli olmak zorundadır

·        Analitik zekaya sahip olması beklenir

·         

Bu yazımı belkide yazının en  can alıcı kısmı ile tamamlamak istiyorum  oda şu peki  test yaparken nasıl bir  yaklaşımla test yapılmalı hangi noktalar ele alınmalı.Şu şekilde   gruplanabillir.

·         Yazılımdan istenilenler yerinde ve yapılmış mı?(validation)

·         Yazılım istenen işlevleri yerine getiriyor mu?(verification)

·         Yazılım işlevleri yaparken hata veriyor mu?(reliability)

·         Yazılım işlemi istenen hızda yapıyormu?(performance)

·         Yazılım istenilen kadarişlev yapabiliyor mu?(Load)

·         Yazılım istenilen işlevleri en çok nekadar yapabiliyor?(stress)

·         Yazılımda istenilen işlem kolay yapılabiliyor mu?( usability)

·         Yazılım istenilen işlevi güvenli yapabiliyor mu?(security)

·         Yazılım işlevleri herzaman yapabiliyor mu?(compatibility)

Yaşar ERKAN(PMP)

Endüstri Mühendisi

Proje Yönetiminde Çatışma Yönetimi

Öyle bir proje yöneticisi hayal edinki şöyle diyor etrafındakilere.

"Ben bu zamana kadar küçük ,orta ,büyük ölçekli yüzlerce hatta binlerce proje yönettim ama hiç birinde hiç ama hiç çatışma olmadı.Benim olduğum projede çatışma olmaz."

Komik geliyor değilmi kulağa.Başta ifade etmiştim hayal edin diye anca hayallerde olur bu durum zaten . 

Çağdaş yönetim anlayışında örgütlerde çatışmanın kaçınılmazlığı, bastırılması değil yönetilmesi ve örgütün gelişmesi için kullanılması anlayışı hakimdir.Proje ortamında çatışmanın olması kaçınılmazdır.Yetersiz kaynaklar ,zaman çizelgesi öncelikleri ve kişisel çalışma tarzları ,çatışma oluşturabilecek kaynaklar arasındadır.

Projede çatışmaların başarılı şekilde yönetilmesi öncelikle olarak proje yöneticisinin sorumluluğundadır. 

Proje Yöneticisinin Çatışmadaki Rolü

Proje yöneticisinin proje ekiplerini yönetmediki başarısı genellikle büyük ölçüde çatışmaları çözme kabiliyetlerine bağlıdır.Farklı proje yöneticileri farklı çatışma çözme yöntemleri kullanabilir ama aslında bu yöntemlerin herbirinin farklı durumda kullanılması en makul olanıdır. 


Çatışmaların çözümünde kullanılabilecek 5 genel teknik vardır. 

• Geri çekilme /Kaçınma:Çatışma durumundan geri çekilmek ,daha iyi hazırlanmak veya başkaları tarafından çözülmesi için ertelemek.Gerektiğinde geri çekilmeyi bilmekte önemlidir.

·         En büyük kayıp çözümsüzlüktür

·         Olumsuz durumlarda eğer yapacak daha iyi bir şeyiniz yoksa sakin olmak ve çekilmek

Duyguları kontrol etmek.

 • Yatıştırma/Uyum sağlama :Ortak paydalarda buluşulmaya çalışılır.Farklılıklar yerine uzlaşma alanlarını vurgulamsk,uyum ve ilişkileri korumak için bir kişinin pozisyonunu diğerlerinin ihtiyaçlarına uyarlamak .

• Ödünleşme/Uzlaşma:Çatışmanın geçici olarak kısmen çözülmesi için tüm tarafları bir ölçüde tatmin edecek çözümler aramadır. 

·         Amaçlar ve ilişki odaklı

·         Amaçlarından vazgeçebilirler, başkalarının da vazgeçmesini beklerler

·         Zaman baskısı yoksa

·         Basit çözüm veya anlaşma olamayacaksa

• Zorlama/Yönlendirme:Kendi görüşünü dayatma kabuş ettirmeye çalışma. Hızlı  bir aksiyon alınması gerekiyorsa , ortamdadeğişim beklentisi çok zayıfsa  ve tarafların kesinlikle yanıldığını düşünülüyorsa kullanılır.

·         Amaç odaklıdır

·         Zorlama yapılır

·         Güç kullanımı vardır

·         Yarışmacı

• İşbirliğinde Bulunma/Sorunu Çözme:Birden fazla bakış açısını birleştirme,işbirlikçi bir tutum ve açık diyalog gerektirir. 

·         Amaçlara ve ilişkiye büyük derecede önem verme

·         Kazan-kazan

·         Olumsuz duygular yaşanmaz

·         Fazla zaman ve enerji ister

·         Öğrenme ve gelişim talep

Çatışmalar her nekadar istenmeyen bir durum gibi görünsede başarılı  yönetilirse projelerin başarısında etkili olan bir dinamik olabilir. Çatışmaları yönetemeyen,onlardan korkarak bastırmaya çalışan ve onları projenin  amaçlarına yönlendiremeyen yöneticiler başarısız olmaya mahkûmdur.

İyi proje yöneticisi çatışmalardan  korkmaz ve hangi durumda hangi çatışma çözüm  yöntemini kullanacağını bilir .Çatışmaları projenin başarısı için bir  basamak olarak kullanır.


Yaşar ERKAN(PMP)
Endüstri Mühendisi