Yazılım Projelerini Yönetmek

by Süleyman Petek 3. Temmuz 2015 20:45
Yazılım projelerinde çok sıklıkla karşılaşılan, projenin tahmin edilen maliyetten daha yüksek m

Yazılım projelerinde çok sıklıkla karşılaşılan, 

projenin tahmin edilen maliyetten daha yüksek maliyete çıkması, 

proje bitiş tarihinin tahmini tarihe yetişmemesi ve 

finalde ortaya çıkan ürünün en başta tasarlanan prototipe nazaran daha az kaliteli ve daha az fonksiyonel olması durumu, 

hepimizin başına geliyordur ya da gelecektir. Burada asıl mesele, bu rutini yaşamadan başarılı olabilmektir. Bu rutin sorunla başa çıkabilmek için şu 4 adımın mutlaka uygulanması gerekmektedir:

1) Planlama ve Tahmin

2) Ölçme ve Kontrol

3) İletişim, Koordinasyon ve Liderlik

4) Riski yönetmek


Aslında bütün projeler aslında birbirine benzer (yönetim anlamında)

-Projeden beklentiler belirlenir

-Yapılacak aktiviteler planlanır

-Kaynaklar atanır

-Sorumlular belirlenir

-Yapılacak işler koordine edilir

-İşin ilerleyişi izlenir

-İletişim sağlanır

-Risk faktörleri belirlenir ve önlenmesi için yapılması gerekenler belirlenir

-Yanlışları düzeltici aksiyonlar alınır (gerekliyse)


fakat yazılım projelerini daha zor ve kompleksleştiren faktörler, yazılım projelerini diğer sektör projelerinden ayırt etmektedir ki bunlar :

-Yazılımın aslında doğasının kompleks oluşu

-Yazılımın değişkenliği

-ve Yazılımın görünmeyen aslında soyut bir ürün olması

Maalesef ki ülkemizde yazılım yöneticiliği yapanlar halen işe inşaat mantığıyla bakıyorlar, şöyle ki, geç kalmış bir inşaata takviye eleman ekleyerek bir miktar hızlandırabilirsiniz işi, ancak bu mantık yazılım projelerinde tam tersi etkiye neden oluyor genelde.(Bkz. The Mythical Man - Month , "Adding manpower to a late software project makes it later ."Bu olayın bir diğer güzel örneği de anne-doğum örneği, yani 1 anne 1 çocuğu 9 ayda doğuruyorsa, 9 anne 1 çocuğu 1 ayda doğuramaz, yazılım projeleri de aynen böyledir. Aslında inşaat için de bir yerden sonra aynı şey geçerlidir, hızlanması gereken bir inşaata gereğinden fazla takviye işçi sağlanırsa bu sefer işçilerin inşaata yaklaşamaması tehlikesi muhtemeldir.(İnsan kalabalığından kaynaklanan istenmeyen durum). 

Yazılım için bu adam eklemenin yarardan çok zarar getirmesini, PMI in da anlattığı gibi iletişim kanallarının her bireyle, logaritmik artması sebebiyle de destekleyebiliriz. PMI der ki iletişim kanalları=n(n+1)/2, n burada ekibin sayısını temsil eder. Bir de buna ekibe yeni katılan elemanların öğrenme eğrisinin de ters logaritmik artışını eklersek, sanırım olayın ciddiyeti daha da anlaşılır olur.

Peki ne yapmalıyız, neler yapılsa böyle olmaz dersek, aslında kesin bir çözüm olmamakla beraber, takımın ve şirketin yapısına göre farklı alternatifler denenebilir, bu aralar çok popüler olan çevik yöntemler buna bir örnek olabilir mesela. (Eğer yönetim desteği varsa ve ekip çok kalabalık değilse (5-8 kişi)).


Tags: , , , ,

Project Management

Calendar

<<  Eylül 2018  >>
PztSalÇarPerCumCmtPaz
272829303112
3456789
10111213141516
17181920212223
24252627282930
1234567

View posts in large calendar

RecentPosts