Riski minimize etmek deyip duruyorlar. Nedir bu "riski minimize edin", doğru düzgün anlatan yok. Bir projede riskler nasıl azaltılır? Size önce bir hikaye ile proje başlangıcında dikkat etmeniz gerekenlerden bahsedeceğim. Sonra projemizi başarıya ulaştıracak kurallarımızı, nelere dikkat etmemiz gerektiğini yazacağımız.

Bütçe / Maliyet Planlama

Bütçenizi doğru hesaplamalı ve bütçeniz ölçüsünde emek alacağınızı iyi bilmelisiniz. Bütçenizin yetmeyeceği durumda küçük adımlarla yola çıkmalısınız. Bu Agile Yönetim Sisteminin en önemli kurallarındandır. Her küçük adımda projeye biraz daha ek özellik eklersiniz ancak başta sadece temel fonksiyonlar bir tuval gibi var olur.

2013 yılında bir müşteri bana telefon etmişti. Kendisi 4 senedir haber içerikleri olan bir web sitesi projesini kodlatmaya çalıştığından bahsetti. Projenin süre ve maliyet analizini yapmadan kabataslak bir fiyat teklifi verdim. Burada size verilen fiyat aralığından bir sayı seçip kesin ücreti belirleyemezsiniz. Hatta bazen proje analizi tamamlanınca bu aralıktan biraz yüksek veya düşük ücret çıkması da olasıdır. Bu teklif sadece bütçenize yakın olup olmadığını anlayacağınız, yazılım analiz sözleşmesine karar verdiğiniz olası fiyat aralığını gösterir.

Bu müşteri fiyatı ve süreyi beğenmedi. Kendisine daha ucuza bu işi yapamayacağımı, işin o kadar ucuza mal edilecek bir iş olmadığını anlatmaya çalıştım. Bu durumda genellikle beklentim gerçekten çalışmak için doğru ücreti kabul etmesi ya da bilgilendirme için bana teşekkür edip telefonun kapanması olur.

Bana yaklaşık 20 dakika boyunca 2-3 kişi tarafından dolandırıldığını ve projenin tamamlanmadığını anlattı. Kendisini dolandıran kişilere ödediği parayı fiyat teklifimden düşmem gerektiğini söyledi. (Neden!?) :) Burası gülmeye başladığım yer oldu. Proje muhtemelen yeni mezun bir amatöre veya bunu ek iş olarak yapan bir emlakçıya verilmiş. Projenin %10'u bile kodlanmamış, arkada ne kadar spagetti kod yazıldığını da tahmin etmek zor değil. Böyle bir projeyi alıp kodları baştan yazmak daha az zaman alır. Düşmek istediği ücret de teklifin yarısıydı..

Arada merak edip alan adını sordum. Bu projeyi hatırlıyordum. 4 yıl öncesinde benden yine teklif almış ve ücreti beğenmemişti. Bunu kendisine belirttim. Çektiği acıya bir kanıt olarak gösterip bu projeyi yapmak zorunda olduğumu söyledi :) Sakinleştim ve şunları söyledim;

"4 yıl önce verdiğim fiyat teklifinden düşmedim. Burası manav değil, uzun soluklu, irade gerektiren işlerden bahsediyoruz değil mi? Fiyat teklifinizi alır, beğenmediyseniz başka yere gidersiniz. İnsanların vaktini çalmazsınız. Madde madde projeniz nerede diyorum 4 senede 2 paragraf düşüncelerinizi yazdığınızı söylüyorsunuz. Yaklaşık fiyat teklifi belirtiyorum en dibini seçip yarısına 20 dakika beni aklınızca manipüle etmeye çalışıyorsunuz. Biraz daha dolaşıp gelin, 4 yıl sonra görüşürüz." deyip sakince kapattım ve engelledim. Muhtemelen bu kadar nazik olmamışımdır.

Sonraki yıllarda projeye baktığımda bozuk bir şekilde 1-2 sayfayla yayınlanmaya çalışıldığını gördüm. Muhtemelen birkaç kere daha dolandırılıp projeyi sonlandırdı. Bunun gibi "ucuza kapattım" kafasıyla iş yaptırdığını zannedip dolandırılmayan insan tanımıyorum.

Kebapçıdan gerçek ücretinin 10'da 1'ine alacağınız şey biftek aromalı cips olur. 

İçiniz karardı, biliyorum. Işıkları açalım..

Tüm bunları neden anlattım? Kaliteli bir meyve bile kaliteli topraktan çıkarken iyiyi kötüden tamamen ayırmayı öğrenmekle başlangıç yapmalıyız. Artık kurallara başlayabiliriz;

Uzun uzun yazdığım gibi bütçenizi net bir şekilde belirlemekle başlayın. Bir yerlerden alacağınız ödemeleri değil mevcut bakiyenizi kontrol edin. Aksi takdirde proje ön ödeme ve ara ödemelerini yapmakta zorluk yaşarsınız. Sözleşme şartlarını yerine getirmediğiniz için projeyi yaptıramamış olur ve ödemeleri havaya yapmış olursunuz.

Sözleşme / Ön-Ödeme / Ara-Ödeme

Hiçbir profesyonel yazılımcı veya yazılım şirketi ön-ödeme ve (proje büyüklüğüne göre) ara-ödeme almadan projenizi kabul etmez. Sözleşme yapılmıyorsa, ön-ödemeler alınmıyorsa zaten o proje asla yapılmayacaktır, emin olabilirsiniz.

Milestones (Proje Fazları)

Projenizi fazlara (milestones) ayırarak madde madde yazın. Basit bir mikro site için bile 8 saatten az çalışmanız yetersizdir. Google'ı yerle bir edin, maddelerinizi tekrar tekrar düzenleyin ve doğru akışı oluşturmaya çalışın.

Her bir fazınızda çalışır bir sistem ortaya çıkmalı ve faz bitiminde bitmiş bir proje gibi rahatlıkla test edebilmelisiniz.  Fazlarınıza yazdığınız her madde proje sözleşmesini oluşturacak bir taslaktır. Burada önemli nokta şu : Projenin sadece ilk fazı hazırlansa dahi ortaya çalışır halde çıkmalıdır. Bir sorun ile karşılaştığınızda bir fazı tamamen iptal etmeniz gerektiğinde, projeyi farklı kişi veya kurumlara devrettiğinizde bir önceki faza dönmek büyük bir maddi kayıp yaratmaz.

Proje Özeti

Projenizin maddelerini tamamladıktan sonra proje özetini hazırlayın. Özet deyince basit bir iş gibi gelebilir ancak bir projeyi birkaç paragraf veya maddeye indirgemek tüm projeyi hazırlamaktan daha zor ve daha önemlidir. Bu hızlı ve nihai fiyat ve süre teklifi almanız için gereklidir. Ben de geçmiş yıllardaki e-postalarıma baktığım zaman aşırı uzun, imla hatalarıyla dolu birçok proje teklifini okumadığımı farkettim.

Uzmanı Nasıl Bulacağım?

Referansları güçlü bir yazılımcı veya yazılım ajansı bulun. Her yazılımcı referanslarını halka açık tutmaz, kendisinden e-posta ile talep edebilirsiniz. Bütçenizin üstünde bir fiyat teklifi verilmesi durumunda projenin sadece bir veya birkaç fazını yapacağınızı belirtin ve bunlar için tekrar fiyat teklifi alın. Burada fazları doğru seçmelisiniz. Karar verdiğiniz yazılımcı / ajans genellikle üçüncü talebinize dönmez çünkü bütçenizin fazla düşük olduğunu düşünmeye başlar.

Bu noktada zengin görünmek iyi bir seçenek gibi algılamayın. Ya sizi vasat bir wordpress kitleyip soymaya çalışacak ya da gerçekten iyi bir yazılımcı belirttiğiniz işi beklediğinizden çok daha iyi yapacak. Bu projenizin süresi ve olduğundan büyük gösterdiğiniz bütçeniz için çok kötü sonuçlanacaktır. Literatürde buna erken optimizasyon sorunu denir.

Temiz Kod, SOLID, Yazılım Mimarisi

Güncel bir framework üzerinde SOLID prensiplerine uygun temiz bir kodlama istediğinizi belirtin. Size uyguladığı prensipleri anlatması önemli. Teknik bilgi sahibi olmasanız da köşeye sıkışan bir insanı herkes tanır. Bazıları da jargon kasıp yalan söyler! Lütfen belirttiği kavramları not alıp internette araştırın!

Dökümantasyon

Yazılım yapısının dizaynını ve yazılan kodların dökümantasyonunu her hafta bir raporla isteyeceğinizi belirtin. Bu rapor basitçe geçmiş haftadan bu haftaya kadar yapılan değişiklikleri içerebilir. Dökümanda ise tüm yazılım dizaynı teknik olarak detaylandırılmalı. Dikkat edilmesi gereken bu işlemleri baştan belirtmeniz gerekir çünkü böyle bir talebin sonradan ortaya çıkması ek iş yükü getirir. Yazılımcı veya Ajans baştan böyle bir talep gelmediği için boş bulunup kabul etmesi projeniz için çok daha kötü sonuçlanır. Başından sonuna kadar dürüst olun. Hepimiz müşterilerin ek özellikleri bugların arasına sıkıştırdığını falan farkedebiliyoruz :) 

Bu son talepler maliyeti arttıracak olsa da başarılı bir proje için riski ciddi ölçüde minimize eder.

Büyük Projeler'in Proje Yönetimine-Nasıl Başlanır?-Nelere Dikkat Edilmeli? 

Büyük Saas projeleri gibi konularda kurallarınız daha da artacak. Başarısız ve başarılı saas projeleri hikayerini farklı makalelerde paylaşacağım. Şimdi madde madde bu çapta bir projede nelere dikkat etmeniz gerektiğinden bahsedeyim.

Çok büyük projelerde de önceki maddeler aynen geçerlidir. Şimdi bunlara biraz ekleme yapacağız;

Toplantı ve Raporlama Döngüsü

Her bir fazda işleyen bir yapının ortaya çıkması gerektiğini belirtmiştim. Bu fazları (milestones) daha çok kısaltmanız gerekiyor. Küçük projelerde yazılımcı ile faz bitişlerinde ara toplantılar yapılırken çok büyük projelerde haftalık veya iki haftalık toplantılar yapılır, fazın ilerleyişi hakkında konuşulur.

Yazılım İş Akışını Bozmaktan Kaçının

Projede devam ederken eklenecek her değişiklik projenin süresini çok ciddi şekilde arttıracaktır. Yazılım tarafında ciddi bir iş akışı vardır. Proje başladığında birbiriyle yazılım üzerinde bağlantılı noktalarda ilerleriz. Bu bağlantılar kullanıcı açısından değil, yazılım açısından soyut bağlantılardır. Belirlediğiniz fazlar istediğiniz adımlarla gerçekleşebilse dahi bu fazlarda belirlediğiniz maddeler sırasıyla gerçekleşmez, teknik olarak sağlıklı değildir. Bu yüzden üzerinde çalıştığımız sayfanın farklı noktasında bile ek işlem yapmak iş akışını bozabilir. Bu iş akışı yazılımcının takip ettiği algoritmalardan ibarettir. 

Takvim karışmaya başladığında hem psikolojik hem de maddi olarak sorunlar ortaya çıkar. Maliyetiniz ciddi bir şekilde artabilir. Bu yüzden önemli eksikler gördüyseniz yeni fazlar oluşturabilirsiniz ancak devam eden fazda değişiklikler talep etmemelisiniz. Oluşturduğunuz yeni fazları proje yöneticisi veya yazılımcılar ile konuşmalı ve hem ek fiyat teklifi hem de ilave süre tahmini almalısınız. En önemlisi de takvimde konumlandırmasını teknik kişilerle ile yapmalısınız. Bu ara-faz'ın en sona eklenmesi gerekebilir, bir sonraki faz olarak da yapılabilir.

Kısacası bir yazılım iş akışı mevcutken araya iş sıkıştırmak, minik bir ek proje sıkıştırmak (ki şirketlerde bolca yaşanır) o projenin asla bitmemesine, bazen hiç başlamamasına sebep olur. Bu konuda uyarmama rağmen para hırsıyla hep aynı hataları yapıp durur ve ellerindekinden de olurlar.

Tek Yazılımcı mı? Ekip mi?

Büyük projelerde tek bir yazılımcı değil genellikle bir ekip ile çalışılır. En azından görsel kodlama için frontend developer ve yapısal algoritma geliştiren backend developer olması gerekir.

Geçtiğimiz yıl içinde; ciddi devops süreçleri, render motorları, reactjs ile canvas üzerinde sürükle bırak işlemleri, yatay mimari de ölçeklendirilmesi gibi dallı budaklı bir işi tek başıma ne kadar zamanda bitireceğim soruldu.  Ekip kurulması gerekiyor dedim. Aşırı ısrar ettiler kıramadım 10 yıl dedim. Gerçekten öyleydi inanmadılar :) Benzer bir projede çalışan 15 kişilik çekirdek ekip var ve projeyi 3 senede ayağa kaldırdılar. Hatta sıradan gözüken bir online muhasebe programı geliştiren şirketin ekibinde 7 kişi çalışıyor ve proje 2 yıldır tam anlamıyla bitebilmiş değil. Benim belli güçlerim olduğu doğrudur ancak öyle uhrevi şeyler değil. 

Kısacası büyük projelerden de ziyade DEV PROJELER'e cesaret ettiyseniz en az 20-30 kişilik ekip barındıran bir şirket kurmaya da cesaret etmelisiniz. Bu tip projelerde küçükten başlamak teknik olarak mümkün olmuyor. Faz'ı nereden böleceksiniz? Bir faz 3 yıl sürecekse, bir kişinin 3 yılını bu işe bağlayacaksanız ve yarın projenizi bırakıp gittiğinde yeni yazılımcı "bu çok karışık tesisatı baştan yapmak lazım" derse ne diyeceksiniz?

Teknoloji Seçimi

Doğru teknolojiyi seçmek çok önemlidir. Eski bilgilerle modellenmiş yapay zekalar tarafından oluşturulan sitelerden doğru teknolojiyi bulmak çok zordur. Bunun için proje danışmanlığını ayrı, projeyi ayrı ekibe de yaptırabilirsiniz.  

Nihai fiyat ve nihai süre neden yazılım analizi sonrası çıkar? 

Çıkardığınız maddeler konuşulmuş, tartışılmış, gerekli teknolojiler belirlenmiş olur. Bu teknolojiler gözetilerek maddeler gruplandırılıp temelde süre ve bu süreye karşılık gelen ücret belirlenir.

Daha spesifik olarak : Bir ekiple çalışılıyorsa yazılımcıların görev süresi düşüktür (çabuk iş değiştirirler). Bu bir risktir. Analiz yapılırken netleşmeyen kör noktalar vardır. Bu kör noktalar bazen belirlenen deadline'ı profesyonellerde %30'a, amatörlerde %1200'e kadar uzatabilirler.

Bir yazılımcının tek gideri masa, sandalye, bilgisayar değil. Sürekli yeni teknolojileri takip etmeli, ücretli araçlar ve eğitimler satın almalı, sürekli soyut düşmanlarla uğraştığı için psikoloğa, sürekli hareketsiz kaldığı için iyi bir sağlık hizmetine ihtiyacı vardır. İyi beslenmeli, beynini korumalı, 4 duvarın arasından sık sık çıkmalıdır. Bu sebeplerden dolayı bu sektörde kalifiye eleman çok zor yetişir. Birçok yazılımcı arkadaşım ya mesleği bıraktı ya da daha tekdüze şirketlerde memur zihniyetinde kodlamaya devam etti. Yazılımcılıkta para var deyip neden 2.senesini doldurmadan çoğunluğu kaçıyor dersiniz? Bu gibi sebeplerden yazılımcı ücretleri diğer sektörlere göre daha yüksek olmaktadır. Maliyetiniz sert eğitimlerden geçmiş bir emekle ortaya çıkıyor ve bu kişilerle profesyonel bir şekilde çalışmazsanız işler istediğiniz gibi olmuyor.

Aklım Çok Karıştı

Milyonlarca parametre ile ilgilenen bir mesleği özetleyen jargonlarla proje yapmak zorunda kalıyorsunuz. Bu biraz zorlayıcı olacak. Biraz yazılımın temellerini, nasıl işlediğini araştırmanız tüm bunlara çok büyük ek faydalar sağlayacaktır. Burada sadece "ben de yaparım" yanılgısına girmek. Evet yaparsınız, mevcut işinize  ve projelerinize elveda deyip geceleri uykusuz kalarak :) Sizin amacınız bu süreç yönetimini doğru yapabilecek kadar giriş seviyesinde teknik bilgi sahibi olmanız, yoksa kimse sizden ileri düzey bir yazılım bilgisi beklemiyor. 

Tüm bunları gerçekleştirdikten sonra iş Proje Süreç Yönetimine geçiyor. Süreç yönetiminden daha detaylı bahsedeceğim. İyi bir projeyle birlikte yukarıdaki uyguladığınızda projenizin başarı şansını %70 arttıracaksınız.