Ana içeriğe atla

Yazılım Projelerinde Güvensizlik Nedenleri



Yazılımcıya güvenmeli mi, güvenmemeli mi? Yazılımcı ya işi beceremezse, ya fikrimi çalarsa, ya başka bir yerden teklif alınca kaçarsa? 

İşverene, yöneticiye güvenilmeli mi? Yönetici projeyi yanlış anladıysa, işveren aynı projeyi başkasına da yaptırırsa, bana sorumluluk verip imkan vermezlerse?



Bu yazıda paylaşacağım durumlar özellikle freelance çalışanların başına gelse de hemen hemen her yazılımcının meslek hayatında karşılaşabileceği durumlardır. Bu yazının içeriği sanayi dilinde ve biraz ortaya karışık oldu, çünkü durumlar karışık ve hoş olmayan durumlar. Bu yazı gerçek olaylara dayanmaktadır. (arka fonda korku filmi müziği)

Yazılım sektöründe yazılımcılara güvenmek bir projenin sağlıklı bir şekilde ayağa kalkabilmesi için gereklidir. Doğru ekibi kurup, ekibine güvenen bir proje yöneticisi için işin zor kısmı bitmiştir. Sektörde bazen yazılımcılara güvenilmediğini bazen de yazılımcıların yöneticilere (işveren, patron, proje yöneticisi, PM) güvenmediğini görüyoruz. Bu yazıda bunun nedenlerini açıklamaya çalışacağım.

Özellikle freelance dünyasında yazılımcıların projeleri bitirmemesi sorunu var. Bu sorun düşük ücret nedeniyle düşük motivasyondan, projedeki ihtiyacın hem yönetici hemde yazılımcı tarafından tam anlaşılamamasından, freelance çalışan yazılımcıların aynı anda birçok iş almasından kaynaklanıyor. Proje sahipleri freelance çalışanlara işi bitirme konusunda güvenemeyince aynı işi birkaç yazılımcıya verme yolunu seçebiliyorlar. Aynı iş üzerinde çalışanlardan en önce işi bitiren freelance yazılımcı parasını alırken diğer yazılımcılar harcadıkları emeğin karşılığını alamıyorlar.

Yurtdışında başlayan Türkiye’de hayatına devam eden projeler ile karşılaşabilirsiniz. Proje sahipleri biz projeyi yurtdışında geliştirdik, proje çok sistemli yazıldı diye yazılımcıları motive etmeye çalışırlar. Genellikle Hindistan’da yapılmaya başlanan bir proje iletişimin zorlaşması nedeniyle kendisini Türkiye’de bulur. Yazılımcı olarak böyle bir projeyle karşılaşırsanız hemen oradan kaçın. Ucuzluk göz önüne alınarak kaliteden uzak bir şekilde geliştirilmeye başlanan ve iletişim kazaları nedeniyle kullanıcı ihtiyacını karşılamayan bu tür projeler dipsiz kuyu gibidir. Emek harcarsınız ama karşılaştığınız hataları çözmeye harcadığınız zaman nedeniyle emeğiniz görünmez.

Yazılımcı olarak yeni bir işe girdiniz ya da bir proje aldınız. Yönetici sürekli önceki yazılımcıları kötülüyorsa dikkatli olun. Önceki yazılımcılar ne kadar süre sonra projeden kaçmaya başlamışlar, proje anlatıldığı gibi değil mi, projenin teslim tarihi nedir gibi soruların cevaplarını bulmaya çalışın. Önceki yazılımcılara güvenmeyen size de güvenmez.

Aşırı güvenme de büyük bir sorundur. Yazılımcıların tereddütlerini “sen yaparsın koçum” ile karşılayan yöneticiler sorunların motivasyon ile çözülebileceğini düşünürler. Bu yöneticiler aynı zamanda proje teslimi yaklaştığında yazılımcıları fazla mesaiye bırakmaya meyillidirler. Bir yazılımcı olarak sorduğunuz sorulara cevap verilmiyorsa, cevap yerine gaz alıyorsanız yöneticinin projeyi anladığına güvenmeyin.

Yönetici kadrosunun şımarıklığı nedeniye ölü doğan projeler için yazılımcıları heba etme yüzünden yazılımcılar sıfırdan başlayan projelere şüphe ile bakıyorlar. Yönetici kadrosu toplantıda kulağa hoş gelen bir fikrin piyasada tutup tutmayacağını araştırmadan, kullanıcı ihtiyaçlarını anlamaya çalışmadan 3-5 kişilik bir yazılımcı iş ilanı açıp, yeni yazılım ekibi toplayıp, ölü doğacak projeyi gerçekleştirmeye çalışabilir. Yeni iş bulmanın heyecanı ile projenin gerçek hayattaki yerini sorgulamayan yazılımcı, projenin bir PowerPoint sunumu olarak hayatını sonlandırmasını görünce yeni proje için açılan iş ilanlarına karşı önyargı olarak güvensizlik hisseder.

Önce para sonra kod, önce kod sonra para! Freelance işlerde proje tesliminde yazılımcının emeğinin karşılığını almak istemesi, işverenin parasının karşılığını almak istemesi normaldir. İşin bitiminde yaşanacak tatsız bir olay iki tarafta da sonraki projeler için güvensizlik oluşturacaktır. Freelance işlerde arabuluculuk yapan platformların komisyon oranlarının yüksek olması da bu soruna katkı sağlamaktadır. Bu problemin çözümünü bilen varsa gelsin bu tarafa.

Sunucu firmalarından kaynaklanan hataların yazılımcıların beceriksizliği olarak algılanması bir diğer güvensizlik kaynağıdır. Sunucu firmalarının sorun bizde değil sizin kodlarınızda açıklamaları nedeniyle aslında suçsuz olan yazılımcılar günah keçisi ilan edilirler.

Proje yöneticisinin aldığı bazı riskli kararların yazılım ekibine mal edilmesi karşılaşılan diğer bir durumdur.. Örneğin her saat başı veri tabanının yedeğinin alınmasına karşı çıkıp günde sadece bir kez yedek alınmasına karar veren proje yöneticisi, veri kaybı yaşanması durumunda üst yönetime yazılımcıları şikayet edebilir.

Yazılımcı monitör isteyince alınmaması, en güçlü bilgisayarın patrona alınması gibi maddiyat ile ilgili kararlarda yazılımcıya verilen değer göz önüne çıkar. Bu durumda olan bir yazılımcı büyük ihtimalle piyasa şartlarından düşük seviyede bir maaş alıyordur. Bu yazılımcı kendini güvende hissetmeyeceğinden iş arayışına devam eder.

Ya fikrimi çalarsa! Aman veri tabanımı görmesin! Sunucunun parolasını veremem! Sen arkadaşa dosyaları gönder, o sunucuya yükler! O dosyadaki kodlarda bizim işin know how’ı var, sana gösteremeyiz! Telefonlara sen bakma, cep telefonundan kimseyi arama. Bu yazılımcıyla pek bir şey paylaşmayalım, toplantılara çağırmayalım, nasıl olsa 6 ay sonra bu da çeker gider. Bu tür cümleleri duyduğunuz işyerinde personele geçici gözle bakıldığından kimseye güvenmezler.

Doğrucu Davut olan yazılımcıların sevilmemesi de bir diğer sorundur. Teknik bir iş için; o iş çok uzun sürer, öyle bir özelliği geliştiremeyiz diyen bir yazılımcıyı kimse sevmez. İsterler ki yazılımcı herşeyi yaparız desin, bir haftaya bitiririz desin. Teknik konularda doğruları söyleyen yazılımcıyı kendini beğenmiş egolu bir şahıs olarak gören yöneticiler yazılımcıya güvenmez, yazılımcının yalan söylediğini düşünür.

Her gelen yazılımcı bu kod kötü baştan yazalım, düzeltelim diyor, yalancılar! Bizim kodlarımız güzel sen anlamıyorsun! Teknik konularda bilgili olduğunu zanneden bir yönetici böyle cümleler sarf edebilir. Bu tür yöneticiler yazılımcılara güvenmezler, kendi bilgisizliklerini çalışanlarına olumsuz davranarak saklamaya çalışırlar.

Çalışsın yeter kararlarının projenin büyümesiyle patlamaya başlaması ve bu kötü kararların yazılımcılara mal edilmesi sık görülen bir durumdur. Proje büyümemişken gerekli düzeltmelerin ve mimari değişikliklerin yapılmasına karşı çıkan yöneticiler, proje büyüyünce ortaya çıkan hataların ve performans kayıplarının sorumlusu olarak yazılımcıları gösterirler. Mevcut çalışan yazılımcıların bir kısmı işten çıkarılır yerlerine daha becerikli yazılımcılar alınır. Ancak yeni yazılımcılar da aynı konularda düzeltmeler yapılmasını söylerler. Proje çıkmaza girer, başarısız olur. Yine eski yazılımcılar suçlanır. Ve bu hikayede herkes mutsuz olur.

Plaza dili ile bol teknik terimlerle konuşarak kendini bilgili göstermeye çalışan, bir konuda tecrübesi olmadığı halde tecrübesi varmış gibi davranan, sürekli iş aramaya devam eden, eğitimlerle tecrübe kazandıktan sonra kaçan, part time iş alıp gündüz işe uykusuz gelen, başka bir yerden iş teklifi gelince habersiz kaçan, proje teslimi yaklaşınca kaybolan, teknik konularda yalan söyleyen yazılımcı arkadaşları saygıyla anıyorum. Bunlar yüzünden biz yazılımcılara olan güven zedeleniyor.

Güven ilişkisi için şeffaf bir iletişim sağlanmalıdır. Proje başarısız olduğunda sorun tek bir tarafta değil tüm taraflarda aranmalıdır. Kişileri suçlamaktan ziyade projede neyin yanlış gittiği araştırılmalıdır ve bu yanlışlardan ders alınmalıdır.

İğneyi kendimize çuvaldızı başkasına batıralım.

Yorumlar

Bu blogdaki popüler yayınlar

Bir Uluslararası Yazılım Şirketinin Batış Hikayesi

 Güzel başlamıştı hikaye. Yazılımcılar mutlu, kullanıcılar memnundu. Sonra pandemi başladı. Sorun para değildi. Olmayan şey huzurdu… Durdurun hype trenini, inecek var kırık kalpler durağında  — Photo by Kelly Sikkema on  Unsplash Gerçek olamayacak kadar güzeldi çalışma ortamı. Yazılımcılara istedikleri eğitim ve donanım alınıyordu, personel arası hiyerarşik bir yapı yoktu, sorumluluğun yanında yetki de veriliyordu, esnek çalışma saatleri yazılımcılara göre esnekti, izin isteyen hiç kimse geri çevrilmiyordu, pandemiden önce bile uzaktan çalışma vardı. Ne oldu bu şirkete? Nazar mı değdi? Şirketin yazılım ürünü Türkiye’de doğmuştu. Ürün birçok ülkede hem kamu tarafından hem de özel sektör tarafından kullanılıyordu. Yazılım geliştirme ekipleri hem Türkiye’de hem de diğer ülkelerde bulunuyordu. Yazılımın argesi için gelen geri bildirimlerin çoğu Türkiye’den geliyordu. Yazılımın kalbi Türkiye’de atıyordu.  Koronavirüs pandemisi nedeniyle Türkiye’de kamu kuruluşları hizmet alımı ile aldıklar

Türkiye'de Yazılım Şirketi Açmak ve Çıldırmamak

Aklında bir fikir vardı. Piyasada bunu karşılayan yazılımlar vardı ama hepsi eksikti. Hayalindeki yazılım ürününe hiçbiri yaklaşamıyordu. Gördüğü kadarıyla piyasanın böyle bir ürüne ihtiyacı vardı. Kullanıcılar mevcut ürünlerden şikayetçiydi. Kendi ekibini toplayıp hayalindeki şirketi kurmaya niyetlendi. Rüzgarlara dikkat!- Francesco Ungaro -  Pexels İşinden istifa etmeden önce piyasa araştırmasını yaptı, rakip ürünleri inceledi. En önemlisi ekibini kurdu. Ürününün MVP hali için çalışmaları başlattı. Girişim kurmak ile ilgili birçok kitap ve blog okudu, podcastler dinledi. Girişimci birkaç kişinin çayını kahvesini içti. Öngörebildiği her şey için önlemini aldı ve istifa edip kendi yazılım şirketini kurdu. Şirket kurmak için gerekli süreçler düşündüğünden daha kolay geçti. Şirketin adı ve logosu zaten hazırdı. Şirket teknoparkta yerini almıştı. Kendisi etiketlere çok önem vermiyordu ama yine de LinkedIn’deki profiline “Founder of the …” ibaresini ekledi. MVP’nin ortaya çıkması hedefini

Yazılımcılar İçin Yan Proje Oluşturma Rehberi

İster hobi amaçlı olsun ister maddi amaçlı her yazılımcının bir yan projesi olmalıdır. Peki yan proje oluştururken nelere dikkat edilmelidir, nasıl bir yan projemiz olmalıdır? Organize olalım beyler Yan proje (side project) için öncelikle bir fikir bulmak gerekli. Bu projenin amacı ne olacak? Hangi ihtiyacı çözecek? Yeni bir fikir mi olacak yoksa mevcut bir fikrin daha iyi uygulanmış bir hali mi olacak? Sadece yeni bir teknolojiyi öğrenmek için mi? Deneysel mi olacak ya da eğlenceli mi? Yoksa maddi bir getirisi olacak mı? Bu proje ürün olursa kimler kullanacak? Ürünü kullanacak kişilere erişip geri bildirim alabilecek miyim? . . . Bu soruların doğru bir cevabı yok, cevaplar size bağlı. Ama proje bir amaca hizmet edip bir ihtiyacı çözecekse, hele birde maddi getirisi olacaksa motivasyonunuz yükselecektir. Bunun yanında sadece eğlence amaçlı olan deneysel bir proje yapmak stressiz bir öğrenme ortamı sağlayacaktır. Gün içinde proje için aklınıza gelen her şeyi not alın. Not almazsan