Özel Yazılım Projesi Başlatırken Nelere Dikkat Edilmeli? Maliyet ve Süreç Rehberi

Özel yazılım projelerinin başarısız olma sebebinin yetersiz yazılımcılar veya zayıf kod kalitesi olduğu düşünülür. Projeleri asıl çıkmaza sokan etken, baştan netleştirilmeyen kapsam, belirsiz veri mülkiyeti ve her ihtiyacı tek seferde bitirmeye çalışan hantal planlamadır. Özel yazılım projesi başlatırken bütçe ve süreç kontrolünü elde tutmak; işi Minimum Uygulanabilir Ürün (MVP) mantığıyla aşamalara bölmeye, kaynak kod sahipliğini sözleşmeyle garantiye almaya ve net bir gereksinim analizi yürütmeye bağlıdır.

Denizli’de son 10 yıldır sanayi tesislerinden şantiye ofislerine kadar farklı ölçeklerde yazılım projeleri teslim ederken gördüğümüz tek bir gerçek var: Yazılıma harcanan para, masaya oturup ne istediğinizi bilmediğiniz anda katlanarak artar. Çoğu şirket “bize bir program lazım” diyerek bir ajansın kapısını çalar. Oysa yazılım, şirketin operasyonel aksaklıklarını otomatik olarak düzelten bir araç değildir; aksine oturmamış bir iş akışını koda dökmeye çalışırsanız mevcut karmaşayı ikiye katlarsınız.

Özel yazılım projesinde hangi geliştirme modeli tercih edilmeli?

Yazılım geliştirme sürecine yaklaşırken önünüzde iki temel seçenek bulunur: Her detayın baştan konuşulduğu monolitik sabit kapsamlı model ya da işin çekirdeğini hızla devreye alıp geri bildirimle büyüten aşamalı MVP modeli.

Monolitik yaklaşımda şirketler 6 ay boyunca neye ihtiyaç duyabilecekleri üzerine toplantılar yapar, 80 sayfalık şartnameler hazırlar ve ajansla sabit bir bütçede anlaşır. Ancak teknoloji ve şirket ihtiyaçları bu kadar uzun süre yerinde durmaz. Dördüncü aya gelindiğinde pazar değişir, yönetim değişir veya başlangıçta tahmin edilmeyen operasyonel bir zorunluluk ortaya çıkar. Sabit kapsamlı sözleşmeler bu noktada tıkanır; her küçük değişiklik için taraflar arasında ek maliyet tartışmaları başlar.

Aşamalı MVP yaklaşımında ise sadece ilk 8 haftada şirketin en çok kan kaybeden sürecine odaklanılır. Örneğin fatura kesme, sipariş onaylama veya şantiye malzeme talebi gibi tek bir can alıcı halka koda dökülür ve canlıya alınır. Gerçek kullanıcılar ekranları kullanırken ikinci aşamanın tasarımı yapılır. Bu sayede hem çalışanların sisteme direnci kırılır hem de bütçe kontrolü işverenin elinde kalır.

Bizim sahada gördüğümüz tablo gayet net: Eğer regülasyonların her satırı zorunlu kıldığı bir kamu ihalesine girmiyorsanız, monolitik model yerine aşamalı teslimatı tercih etmek projenin batma ihtimalini neredeyse tamamen ortadan kaldırır. Şirketiniz için doğru yöntemi seçerken hazır yazılımlar neden yetersiz kalır başlıklı incelememizdeki temel kısıtları da göz önünde bulundurabilirsiniz.

Gereksiz özellikler için baştan yüz binlerce lira ödemek yerine sistemi sahada pişirmek her zaman daha kazançlıdır.

Aşamalı geliştirme modelinde modüller küçük parçalar hâlinde devreye alınır

Kapsam ve gereksinim dokümanı nasıl hazırlanır?

Gereksinim dokümanı, yazılımcının ne yazacağını değil, işletmenin işi nasıl yaptığını ve sistemden ne beklediğini anlatan metindir. Bu doküman hazırlanmadan fiyat veren bir yazılım ekibi, gerçekte ne geliştireceğini bilmediği için ya fiyata devasa bir risk payı eklemiştir ya da işin ortasında sizden ek bütçe isteyecektir.

Sağlıklı bir gereksinim analizi üç temel soruya odaklanır: Kim kullanacak, ne yapacak ve bu işlemin sonucunda hangi veri nereye akacak? Örneğin “kullanıcılar stok durumunu görecek” ifadesi bir gereksinim değildir. Doğru ifade şudur: “Depo sorumlusu rolündeki kullanıcı, Merkezefendi deposundaki ürün miktarını barkod okutarak görebilmeli; kritik stok seviyesi olan 10 adedin altına düşüldüğünde satın alma yetkilisine sistem üzerinden bildirim düşmelidir.”

İş akışlarını netleştirmek için önce Excel tablolarındaki dağınıklığı anlamak gerekir. Birçok işletme zaten işini elektronik tablolarda yürütmeye çalışırken tıkanır. Bu geçişin nasıl kurgulandığını Excel tablolarından kurtulma yolları yazımızda detaylarıyla ele almıştık.

Dokümanın ardından mutlaka tıklanabilir bir prototip (wireframe) hazırlanmalıdır. Ekranları çizmeden, düğmelerin nereye bağlandığını görmeden kod yazmaya başlamak, temeli atılmamış binaya çatı çıkmaya benzer. Prototip aşamasında bir düğmenin yerini değiştirmek 5 dakika sürer; veritabanı kurulup kod yazıldıktan sonra aynı değişikliği yapmak en az iki günlük iş gücü demektir.

Yazılım maliyetinde gözden kaçan gizli kalemler nelerdir?

Özel yazılım tekliflerinde işverenlerin en çok yanıldığı nokta, geliştirme bedelini toplam sahip olma maliyetiyle karıştırmaktır. Bir yazılımın kodlanıp sunucuya atılması harcamaların sadece ilk adımıdır.

İlk gizli maliyet üçüncü taraf servis entegrasyonlarıdır. Yazılımınız e-fatura kesecekse bir entegratöre, SMS ile onay kodu gönderecekse SMS sağlayıcısına, harita üzerinde konum gösterecekse harita API servislerine aylık veya kontör bazlı ödeme yapmanız gerekir. Bu servislerin aylık giderleri bazen sunucu maliyetinin üç katına çıkabilir.

İkinci kalem, sunucu ve altyapı mimarisidir. Çok şubeli veya sahada yüzlerce personelin giriş yaptığı sistemler basit bir paylaşımlı hosting üzerinde çalışamaz. Docker konteynerleri, yedekleme sunucuları ve güvenlik katmanları içeren özel bir bulut yapılandırması gerekir. Veri güvenliği ve kesintisiz erişim için kurumsal bir altyapı şarttır.

Üçüncü ve en büyük görünmeyen kalem ise veri taşıma ve personel eğitimidir. Eski sisteminizdeki 15 yıllık bozuk cari kayıtları, mükerrer müşteri listelerini ve hatalı stok verilerini temizleyip yeni veritabanına aktarmak bazen başlı başına 3-4 haftalık bir mesai gerektirir. Eğer bu işi sözleşmeye dahil etmediyseniz, projenin canlıya alınma tarihi en az bir ay sarkar.

Bu noktada ihtiyaç duyulan şey çoğu zaman geniş bir kurumsal mimaridir. İşletmenin işleyişine göre sıfırdan planlanan özel yazılım geliştirme projelerinde bu altyapı kalemleri ilk günden tabloya dökülmelidir.

Bir yazılımın bakım anlaşması yoksa ilk işletim sistemi güncellemesinde çökmesi sadece zaman meselesidir.

Altyapı maliyetleri hesaplanırken üçüncü taraf API servisleri unutulmamalıdır

Kaynak kodu ve veri mülkiyeti sözleşmede nasıl güvenceye alınır?

Sektörde yaşanan en acı tecrübeler genellikle mülkiyet haklarından çıkar. Yüz binlerce lira ödediği sistemin kaynak kodlarını alamayan, geliştirici ekibe küsünce yazılımı güncelleyemeyen ve veritabanını dışarı aktaramayan onlarca şirketle karşılaştık.

Yazılım sözleşmesinde şu üç madde tartışmasız şekilde yer almalıdır:

• Kaynak kodların mülkiyeti: Ödemeler sözleşme takvimine uygun yapıldığı andan itibaren yazılan tüm kaynak kodlar, arayüz tasarımları ve veritabanı mimarisi istisnasız müşteriye aittir.
• Kod deposuna erişim: Kodlar geliştiricinin kişisel bilgisayarında değil, müşterinin adına açılmış bir GitHub, GitLab veya Bitbucket deposunda tutulmalı; müşteri bu depoya yönetici olarak erişebilmelidir.
• Veri taşınabilirliği: Müşteri dilediği an sistemdeki tüm verileri standart SQL ve JSON formatlarında dışarı aktarma hakkına sahip olmalıdır. Veritabanının şifreli şekilde saklanması ya da dışa aktarımın engellenmesi kabul edilemez.

Ayrıca seçilen teknoloji yığını da sürdürülebilirlik açısından hayati rol oynar. Dünyada yaygın kullanılan Laravel, Python, modern Node.js çatıları ve PostgreSQL gibi endüstri standardı teknolojilerle yazılmış bir sistemi yarın başka bir ekibe devretmek son derece kolaydır. Buna karşılık tek bir ajansın geliştirdiği, belgelenmemiş kapalı devre dillerle hazırlanan projeler sizi o ajansa ömür boyu mahkûm eder. Bu bağımlılıktan kaçınmanın mantığını şirketinize özel yazılım yaptırmanın avantajları içeriğimizde de vurgulamıştık.

Doğru yazılım ajansı nasıl seçilir ve hangi riskler elenir?

Doğru yazılım ortağını bulmak için portföydeki logolara değil, o logoların arkasındaki gerçek saha problemlerinin nasıl çözüldüğüne bakmak gerekir.

Denizli’de çalıştığımız bir inşaat firmasında temel sorun; şantiye giderlerinin, taşeron hak edişlerinin, malzeme siparişlerinin ve kasa akışının farklı kanallarda dağınık tutulmasıydı. Proje kârlılığı ancak iş bittiğinde yaklaşık olarak hesaplanabiliyordu. Geliştirdiğimiz şantiye takip yazılımıyla taşeron sözleşmelerini, malzeme talep-sipariş-teslim akışını ve kasa hareketlerini tek merkezde topladık; rol bazlı yetkilendirmeyle saha ekibi mobilden giriş yaptı, ofis onayladı ve proje kârlılığı anlık izlenebilir hâle geldi.

Benzer şekilde birden fazla noktada faaliyet gösteren bir otomotiv yedek parça firmasında, binlerce parçanın stok ve cari takibi hazır programlarla yürütülemez hâle gelmişti. Geliştirdiğimiz özel stok ve cari takip yazılımının ardından parça hareketleri ve cari bakiyeler tek ekranda toplandı, operasyonel hata payı sıfırlandı ve raporlama süresi dakikalara indi.

Bir ajansla görüşürken şu dört soruyu sormak riskleri baştan eler:

1. Benzer bir operasyonel takip projesini daha önce canlıya aldınız mı ve referans müşterinizle doğrudan görüşebilir miyim?
2. Proje yöneticim kim olacak, yazılımcılarla doğrudan teknik toplantı yapabilecek miyim?
3. Proje teslim edildikten sonraki ilk 3 ay için garanti ve hata düzeltme kapsamınız nedir?
4. Sunucu çöktüğünde veya sistem yanıt vermediğinde sözleşmeye bağlı SLA (hizmet seviyesi taahhüdü) süreniz kaç saattir?

Eğer ajans teknik detayları geçiştirip sadece ne kadar hızlı teslim edeceğine odaklanıyorsa o masadan uzak durmak gerekir. Yazılımda aceleyle yazılan her satır kod, ileride iki katı maliyetle düzeltilen teknik borç olarak geri döner. Şirket içi süreçleri dijitalleştirirken ihtiyaç duyulan altyapı bir müşteri ilişkileri modülüyse, seçimi kolaylaştırmak için doğru CRM yazılımı nasıl seçilir rehberimize göz atabilirsiniz. Satış ve müşteri takibinizi merkezileştirmek istediğinizde ise doğrudan şirket dinamiklerinize göre kurgulanan özel CRM yazılımı çözümlerimizden faydalanabilirsiniz.

Projeye başlamadan önce uygulanacak karar kontrol listesi

Masaya oturmadan önce elinizdeki hazırlığı doğrulamak için bu adımları tek tek işaretleyin:

• Ölçülebilir hedef: “Hızlı program istiyoruz” yerine “Sipariş işleme süresini 4 saatten 20 dakikaya indirmek” gibi sayısal bir hedef belirlendi mi?
• Kullanıcı rolleri: Sistemde hangi unvanların hangi ekranları göreceği (patron, muhasebeci, saha elemanı, depo sorumlusu) listelendi mi?
• Veri envanteri: Yeni sisteme aktarılacak mevcut verilerin formatı ve temizliği kontrol edildi mi?
• Üçüncü taraf servisler: SMS, e-fatura, banka sanal posu veya kargo entegrasyonları için hesaplar açıldı mı?
• Mülkiyet maddesi: Sözleşmede kaynak kodların, veritabanının ve Git deposunun müşteriye ait olduğu açıkça yazıldı mı?
• Aşamalı teslim takvimi: İşin tamamı için tek bir tarih yerine 2-3 haftalık aşama teslimatları belirlendi mi?
• Bakım anlaşması: Yayın sonrası güvenlik güncellemeleri, yedekleme ve teknik destek şartları yazılı protokole bağlandı mı?

Bu maddelerden üçü bile eksikse yazılım geliştirmeye başlamak kumar oynamaktan farksızdır. Kendi iş süreçlerinizi analiz ettirmek, gereksinimlerinizi modüler bir yol haritasına dökmek ve projenizi sağlam temeller üzerine kurmak için iletişim sayfamız üzerinden ekibimizle bir ön analiz toplantısı planlayabilirsiniz.