Murat Uysal

bir matematik mühendisi olarak hislerim ve deneyimlerimden süzülen yazılar dizisi

Proje yönetiminde başarılı olmak için dikkat edilmesi gereken konular


Selamlar yazılarımı okumaya değer bulan sevgili okurlarım.  Yazılım uzmanı olarak başladığım kariyerim, proje yöneticiliği ile devam etmekte ve hergün yeni şeyler öğrenmekteyim.

Her projede tekrar eden ana sorunu sizlere açıklıyorum. "Ne kodlayacağız konusunda herkesin farklı bir kanıda olmasına rağmen toplantının sonuçlanıp projeye başlanması" diyebilirim. Herşey netmiş hissi ile birbirinden çok kutup noktalarda düşünceler ile toplantı masasından kalkan insan yığını nedeniyle o isteneni yakalamakta hep zorlanıyoruz.

Bunun sebebine gelirsek müşteri taraflı ve proje ekibi taraflı olmak üzere 2 merkezi var;

Proje ekibi kaynaklı sorunlar:

- Yanlış Sorular

Doğru sorular çok önemlidir. Müşteriye sormanız gerken kritik soruları iyi bilirseniz bu durumda ancak gerçekten iyi bir iş çıkarabiliriz. Bir nevi o polisiye filmlerdeki sorgu sahnelerindeki gibi müşteri sorgulanmalıdır. Bazı istekleri gereksiz ise karşı çıkılmalı tartışılmalıdır. Ancak hatalı sorular ile tamam tamam denerek notlar alındığ için proje anlaşılmakta zorlanılmaktadır.

- Eski Deneyimlerden Dolayı Hatalı Şablon Takıntısı

Eski deneyimlerden dolayı o anki projeyi de bir şablona uydurma güdüsü istemdışı bir tavırdır. Bu tavır nedeniyle proje maalesef kendine uygun olmayan bir formata bürünür ve bu büyük bir felaketin en önemli kıvılcımıdır. Eğer bir projeyi hatalı bir şablonla başladıysa bir ekip, sonuçta çıkan şey kesinlikle müşteriye çözüm için yeterli gelmeyecektir.

- Gerçekten bilgi sahibi olması gereken kişilerin bilgi eksikliği

Projeyi asıl anlaması gerkene kişilerden ziyade, daha üst düzey yönetimsel noktadaki kişilerin toplantıları yapması ve edindiği bilgileri aktarırken değişime uğraması sonucu yaşanan zorluklar büyük bir sorun olarak ileride kaşımıza çıkıyor. Mesela parametrik olması gereken şey statik yapıldığ için kilitler oluşabiliyor. Veya statik olması yeterli bir iş parametrik olsun diye boşa ekip yoruluyor ve bu özellik hiçbir şekilde kullanılmıyor. Ciddi gecikmelerin temelinde bu vardır.

- Daha kolay metotları gözardı etme riski

Teknik anlamda yetersizlik nedeni ile müşteriye sunulabilecek daha kolay seçeneklerin bilinmemesi ve bilinen metotlardan yol alıp zor yoldan çözüm çabası göstermek de büyük sorun. Bulut sistemler mesela artık çoğu projede tercih edilmekte. Veya daha basite indirgersek e-ticaret projesi isteyen bir müşteri özel çözüme ihtiyaç duymuyor ise ona özel bir eticaret sitesi yazmak yersiz olacaktır.


Müşteri kaynaklı sorunlar:

- Müşterinin çok iyi bildiğini sanma duygusu


Genelde bu kişiler ya şirket sahibi yada o şirkette uzun yıllar deneyimli kişiler olmaktadır. Kendi sektörlerinde kendilerini ispatlamışlardır ve maalesef yazılımı da en iyi kendileri tasarlayabilir sanarlar. Analist e bırakılacak konuları kendileri böyle istiyorum şeklinde net cümleler ile anlatırlar. Müşteriyi kaçırmak istemeyen kişi de herşeye hatalı da olsa evet demek zorunda kalır. Sonuçta iş alınır projeye başlanılır ama binlerce hatalı istek onaylanmış şekilde yola çıkılmış olur. Başarı imkansızdır, büyük geçmiş olsun.

- Yakın bir rakibi örnekleme güdüsü

Kendi sektöründe yakın bir rakibinin kullandığı metodu en doğrusu sanıp benzerini bazen de birebir aynısı istemede diretmesi de söz konusu olur. Anlatırsınız, bu şekilde istersenizi yaparız elbette ancak sizin için bizim önerdiğimiz yöntem daha iyi sonuç üretecektir dersiniz ama maalesef. Evet diyor gibi yapar size ama sonuçta yine kendi kafasına taktığı rakibin yaptığını ister. Çünkü korkar, o yaptıysa doğrudur der aynısını uygulayıp gece rahat uyumak ister. Proje bu sayede karşımızda firmaya değil o rakip firma için yapılırcasına başlar. Başarı şansı var ama eğer firmalar gerçekten birbirine uymuyorsa sonuç felakettir.

- Bütçe takıntısı

Bazı şirketler en iyi çözümü istemek yerine nasıl bu işi ucuza mal ederim diye bakar. Halbuki yazılım tasarruf edilecek birşey değildir ki. Bir projeyi 1 ayda teslim etmek de mümkün 3-6 ay arasında da. Aradaki fark sonradan gelecek değişiklikleri daha hızlı adapte olan bir yazılım. Eğer ekibi zaman sıkışıklığı içinde boğarsanız kaliteli kod yazmak ikinci plana atılır. Kalitesiz yazılan kod ise bugün için kar gözükse de uzun vadede büyük külfet getirir. Müşteri teknik tarafı bilmez maliyeti düşürmek için pazarlık yapar, pazarlık sonucu istediği rakamı da alınca mutlu olur ancak o mutluluğun anlamsızlığını anlamaz. İşi kaçırmak istemeyen analist veya pazarama uzmanı da onay verir imzalar atılır. Vah ki ne vah, yazık o ekibe hemde çok yazık. Asla beğenmedikleri şekilde kodu yazıp bir an önce projeyi bitirmeleri gerekecek.


Yukarıdaki sorunlar gördüğüm en büyük temel sorunlar arasında yer alıyor. Detaylandırsam bu maddeleri ciddi adette arttırabilirim. Bu sorunların sonucu da birbirini anlamadan çalışan insanlar yığını oluyor. Bu yığın birlikte çalışıyor ancak herkes farklı beklentiler ile proje sürecini devam ettiriyor.

Bu yazıdaki sorunlar nedeniyle işte aşağıdaki karikatür hayatımızın önemli bir bölümünde büyük bir gerçeği yansıtlmaktadır :)



İşte bunca kafası çalışan insanlar ile bir ekibi yönetmemize ve müşterilerimizi gerçekten sevmemize rağmen, sonrasında müşterilerimizi memnun etmekteki büyük zorluğun en iyi açıklaması.

Saygılar sevgiler efendim. Okuduğunuz için teşekkür ederim.


Comments are closed