Hizmet detayı

İhtiyaca Özel Uygulama Geliştirme

Windows, Linux, macOS ve web üzerinde tek kod tabanından çalışan; iş süreçlerinize birebir uyarlanmış güvenli ve güçlü yazılım çözümleri.

Done Dynamics; ihtiyaca özel masaüstü ve çoklu platform uygulama geliştirme, kurumsal iç yazılım, ERP paneli, saha operasyonu aracı, POS sistemi ve donanım entegre yazılımlar üreten bir kurumsal yazılım şirketidir. Aynı kod tabanını Windows, Linux, macOS ve web üzerinde çalıştırır; kod imzalama, otomatik güncelleme ve yerel donanım entegrasyonunu varsayılan olarak teslim ederiz — sadece tasarım+kod değil, çalışan, imzalı, dağıtılan sistem.

Platformlar

Windows, Linux, macOS ve web — hepsi tek elden

Kullanıcılarınızın hangi cihazı kullandığını sormayız; uygulamanız her birinde aynı kalitede çalışır.

Windows

Windows 10 ve 11 üzerinde yerel kurulum, MSI ve MSIX paketleme, Active Directory entegrasyonu, kurumsal imzalı sürümler.

Linux

Debian, Ubuntu, Red Hat, Fedora ve Arch dağıtımlarında .deb, .rpm ve AppImage paketleri. Sistem servisi olarak çalışabilir.

macOS

Apple Silicon ve Intel Mac'ler için Apple imzalı, noter onaylı, .dmg ile dağıtılan yerel uygulamalar.

Web

Aynı kod tabanından çalışan tarayıcı sürümü. Kurulum gerektirmeyen, her cihazdan açılabilen modern ve hızlı web uygulaması.

2 dakika · 4 soru

İşinize özel yazılım mı, hazır paket mi?

Dört soruda süreçlerinize bakalım. Hazır bir çözüm işinizi görüyorsa bunu söylemekte sakınca görmüyoruz.

Kullandığınız hazır program iş akışınıza ne kadar uyuyor?

Soru 1 / 4

Kullandığınız hazır program iş akışınıza ne kadar uyuyor?
Neden ihtiyaca özel?

Hazır paket size uymuyorsa, biz size uyan paketi yazarız

Her şirketin işleyişi farklıdır. İhtiyaca özel yazılım, süreçlerinizi bükmek yerine onları olduğu gibi destekler — ölçeklendikçe sizinle birlikte büyür.

  • Tek kod, dört platform

    Aynı çekirdeği Windows, Linux, macOS ve web'de çalıştırırız. Bakım maliyetiniz ikiye, üçe katlanmaz.

  • Yerel hız ve yerel donanım

    Tarayıcı kısıtlamalarına takılmayan; disk, USB, yazıcı, kamera ve seri porta doğrudan erişen güçlü yazılım.

  • Çevrimdışı çalışır

    İnternet kesilse bile uygulamanız durmaz. Veri yerelde tutulur, bağlantı geldiğinde eşitlenir.

  • Size özel, paket değil

    Hazır pakete iş akışınızı uydurmazsınız. Yazılım sizin sürecinize uyar, tam tersi değil.

  • Sahibi sizsiniz

    Kaynak kodu, paket imzaları ve dağıtım kanalları size aittir. Sağlayıcı bağımlılığı yok.

  • Üretim odaklı yığın

    Electron, Tauri, .NET MAUI, Flutter Desktop ve Qt — ihtiyacınıza en uygun çerçeveyi birlikte seçeriz.

Kullanım Alanları

Üretebileceğimiz uygulamalar

Kurumsal iç yazılımdan saha uygulamasına, ERP panelinden POS sistemine kadar geniş yelpaze.

Kurumsal İç Yazılım

Şirket içi süreçleri otomatikleştiren, çalışanın tek ekrandan iş bitirdiği özel uygulamalar.

ERP & Yönetim Panelleri

Stok, sipariş, üretim, finans ve müşteri verisini tek arayüzde birleştiren ölçeklenebilir paneller.

Saha Operasyon Araçları

Çevrimdışı çalışabilen, sahadaki teknisyen, kurye veya bayinin telefonundan ve dizüstüsünden erişebildiği uygulamalar.

Veri Toplama & Analiz

Birden çok kaynaktan veri çeken, gerçek zamanlı işleyen, raporlayan masaüstü ve web araçları.

Donanım Entegrasyonu

Barkod okuyucu, terazi, yazıcı, IP kamera ve sensör gibi yerel donanımlarla doğrudan konuşan yazılımlar.

POS & Satış Noktası

Çevrimdışı dayanıklı, hızlı, dokunmatik uyumlu satış noktası ve kasa uygulamaları.

Güvenlik

Güvenli ve güçlü — slogan değil, kontrol listesi

Masaüstü uygulamada güvenlik tarayıcıdaki kadar belirgin değildir; bu yüzden her madde gözle görülür hâle getirilir.

  • Kod imzalama: Windows, macOS ve Linux paketleri kurumsal sertifika ile imzalanır; kullanıcıya "bilinmeyen yayıncı" uyarısı çıkmaz.
  • Şifreli yerel veri: Hassas veriler kullanıcı cihazında AES-256 ile şifreli saklanır.
  • Güvenli iletişim: Sunucu ile tüm haberleşme TLS 1.3 üzerinden, sertifika sabitleme ile korunur.
  • En az ayrıcalık: Uygulama yalnızca ihtiyacı olan dosya, ağ ve sistem haklarını ister.
  • Otomatik güncelleme: Güvenlik yamaları kullanıcı müdahalesi olmadan, doğrulanmış imza ile dağıtılır.
  • KVKK ve GDPR uyumlu: Veri saklama, izin ve silme süreçleri yasal çerçeveye göre tasarlanır.
Süreç

Fikirden imzalı paketlere

Beş aşamada teslim; her aşamada görünür çıktı.

  1. 01

    Süreç Analizi

    İş akışınızı yerinde gözlemleriz. Hangi adım manuel, hangi adım yazılımla otomatikleşmeli — net çıkarılır.

  2. 02

    Platform Kararı

    Hangi platformlar zorunlu, hangileri tercih — kullanıcı cihaz envanterine göre belirleriz.

  3. 03

    Mimari ve Prototip

    Veri modeli, çevrimdışı eşitleme, donanım entegrasyonu ve güvenlik mimarisi prototiple doğrulanır.

  4. 04

    Geliştirme

    Test odaklı geliştirme, kod incelemesi ve sürekli teslim. Her sürüm imzalanır, dağıtım kanalına otomatik düşer.

  5. 05

    Dağıtım ve Destek

    Otomatik güncelleme altyapısı, çökme raporlama ve uzaktan tanılama. Hata önce bize, sonra kullanıcıya görünür.

Ticari model

12 ay sabit · sürprizsiz yenileme

Uygulama teslim edildiğinde iş bitmiyor: kullanım hakkı, bakım, hata düzeltme ve işletim sistemi güncellemelerine uyum sürekli devam eden bir yük. Bu yüzden hizmet 12 aylık sözleşmeyle veriliyor. Kapsam ve bedel baştan yazılır, yıl içinde değişmez; ara zam ya da sonradan çıkan lisans faturası yok. Yıl sonunda kullanım, gelen talepler ve bir sonraki yılın kapsamı birlikte gözden geçirilip sözleşme yeniden imzalanır — devam kararı sizindir.

İlgili hizmetler

Web uygulama geliştirme →

Tarayıcı tarafında kalmak isteyen ekipler için; SEO uyumlu, S3+CDN destekli kurumsal web uygulama paketi.

Mobil uygulama geliştirme →

Sahadaki kullanıcı için iOS ve Android — masaüstü uygulamanızla aynı backend paylaşımı.

Veri yedekleme ve S3 depo →

Çevrimdışı sıra ve yerel veritabanı kullanan uygulamalarınız için şifreli yedekleme ve CDN entegrasyonu.

Bir sonraki yazılım projenize hazır mısınız?

Ekibimizle 30 dakikalık ücretsiz bir keşif görüşmesi planlayın.

Proje Başlat Daha Fazla →

İhtiyaca özel uygulama geliştirme ne zaman gerçekten gerekir

İhtiyaca özel uygulama geliştirme ne zaman gerçekten gerekir

Muhasebe paketine üç ay önce geçen bir imalatçı, sipariş takibini hâlâ ortak klasördeki bir tabloda yürütüyor. Paket faturayı kesiyor, stoğu düşüyor, ay sonu raporunu çıkarıyor. Ama üretim emri hangi tezgâhta bekliyor, hangi parti fireye gitti, hangi müşteriye verilen termin kaymak üzere — bunların hiçbiri ekranda yok. Ekip de boşluğu kendi yöntemiyle doldurmuş: bir dosya, üç farklı sürüm, bir de kimsenin dokunmaya cesaret edemediği makro. Bir işletmede özel yazılım ihtiyacı genelde böyle sessizce doğar; strateji toplantısında değil, ay sonu mutabakatı tutmadığında. Done Dynamics bunu bir kurumsal yazılım şirketi olarak defalarca gördü. Sorun paketin kötü olması değil. Paketin sizin işinizi bilmemesi. Aşağıda hangi durumların gerçekten kendi sisteminizi gerektirdiğini, fiyatı neyin belirlediğini ve hangi hallerde hazır bir paketin daha akıllıca olduğunu tek tek açıyoruz.

Hazır paketin ilk tosladığı yer: kendine özgü üretim akışı

Standart bir üretim modülü şunu varsayar — hammadde girer, iş emri açılır, ürün çıkar, stok düşer. Sahada işler nadiren bu kadar doğrusal ilerler. Bir mermer atölyesinde aynı bloktan çıkan plakaların kalınlığı değişir, fire oranı bloğa göre farklıdır ve fiyat kesim öncesi ölçüye değil, kesim sonrası net alana göre belirlenir. Bir boyahanede parti numarası küvete bağlıdır; aynı reçete iki ayrı küvette iki ayrı ton verir, müşteri ton farkını kabul etmez, sevkiyat karışırsa mal geri döner. Bunlar egzotik istisnalar değil, o işin normali.

Hazır modül bu kuralları taşımadığında ne olur? Kullanıcı sisteme yalan söylemeye başlar. Stok sayısını tutturmak için hayali fire fişi keser, terminleri kafasında tutar, gerçek maliyeti kendi tablosunda hesaplar. Yazılım vardır ama veri yoktur. İşte özel yazılım tercihinin ilk gerekçesi budur: sistemin sizin fiili akışınızı tanıması, kullanıcının sistemi kandırmak zorunda kalmaması.

Reçeteli üretimde bir katman daha var. Yarı mamul kendi başına bir stok kalemi mi, yoksa yalnızca ara adım mı? Aynı ürün iki farklı reçeteyle üretilebiliyorsa maliyet hangisine göre hesaplanacak? Hurda geri kazanılıp yeniden girdiye dönüyorsa değeri kaç? Bu soruların cevabı muhasebeciyle üretim müdürü arasında bile farklı çıkabiliyor — ve kararı yazılım vermiyor, siz veriyorsunuz. Bizim işimiz kararı doğru soruyla ortaya çıkarmak.

Bu tabloyu en net gördüğümüz yerlerden biri Antalya'daki üretim ve tedarik zinciri. Antalya yazılım talebinin büyük kısmı sıfırdan bir sistem kurma isteğinden değil, hazır paketin sahayla arasındaki açığı kapatma zorunluluğundan geliyor.

Çok şubeli stok, bayilik komisyonu ve saha ekibi

Tek depolu bir işletmede stok basit bir sayıdır. Beş şubeye çıktığınız gün aynı sayı bir soruya dönüşür: hangi şubede, hangi rafta, kimin adına rezerve? Şubeler arası transfer yolda mı, teslim mi alındı, fire kimin hanesine yazıldı? Hazır paketlerin çoğu çok depolu çalışır, doğru. Ama transfer onayı, şube müdürünün yetki sınırı, merkez deposunun otomatik ikmal eşiği gibi kuralları sizin kurgunuza göre esnetmezler. İstanbul yazılım taleplerinde en sık duyduğumuz cümlelerden biri de bu: merkez depo ile mağaza arasındaki mutabakat her ay elle yapılıyor.

Bayilik ve komisyon hesabı ayrı bir dünya. Bir bayi ciro üzerinden, bir diğeri tahsilat üzerinden, üçüncüsü ürün grubuna göre kademeli oran alıyorsa; üstelik iade ve vade farkı komisyondan düşülüyorsa, bunu genel amaçlı bir modülde kurmak neredeyse imkânsızdır. Excel'e kaçış tam burada başlar. Ay sonunda bir kişi oturur, hakedişi elle hesaplar, hata payı da onun dikkatine kalır. O kişi izne çıktığında ne olacağını hiç kimse konuşmaz.

Bayi paneli meselesi de çoğu projede sonradan patlar. Bayi kendi bakiyesini, açık siparişlerini ve hakedişini görebilecek mi? Görebilecekse hangi veriyi görmeyecek — diğer bayilerin fiyatını, merkez maliyetini, stoğun gerçek adedini? Yetki matrisi baştan kurulmazsa panel ya hiç açılmaz ya da açıldığı gün görülmemesi gereken bir alan görünür. Bir özel yazılım projesinde bu matris ekranlardan önce yazılır, sonra değil.

Saha ekibi takibi ise mobil ve çevrimdışı gerçeklikle uğraşır. Teknisyen bodrum katta sinyal bulamaz. Kurye kırsalda çalışır. Servis formunun imzası, fotoğrafı ve kullanılan parça kaydı o an alınmazsa bir daha alınamaz. Yerel veritabanı ve olay tabanlı eşitleme kurgusu olmayan bir sistem burada işe yaramaz — bağlantı geri geldiğinde çakışmayı kimin çözeceği baştan tasarlanmalıdır. Alanya yazılım ekibimiz saha projelerinde ilk prototipi hep en kötü bağlantı koşuluna göre kuruyor, ofis masasındaki ideal koşula göre değil.

Mevzuata özel raporlama ve eski sistemden veri taşıma

Bazı sektörlerde rapor bir tercih değil, yükümlülük. Turizmde konaklama beyanı, gıdada izlenebilirlik kaydı, sağlıkta hasta verisinin saklama süresi, ihracatta menşe ve gümrük evrakı zinciri. Bu raporların formatı da mevzuat değiştikçe değişiyor. Hazır paketin yeni formata uyum sağlaması sağlayıcının yol haritasına bağlıdır; sizin denetim tarihinize değil. Kendi sisteminizde ise rapor şablonu bir konfigürasyon meselesidir, sürüm bekleme meselesi değil. Bir özel yazılım projesinde raporun kaynağı da açıktır: hangi alanın hangi hesaplamayla toplandığını denetçiye gösterebilirsiniz.

KVKK tarafı da benzer bir başlık. Hangi kişisel veri hangi amaçla tutuluyor, saklama süresi dolduğunda kim siliyor, silme talebi geldiğinde arşivdeki kopyalar ne oluyor? Bu akışların ekranda karşılığı olmadığında iş yine elle yürüyor ve denetimde kanıtlanamıyor. Kendi sisteminizde rıza kaydı, saklama süresi ve silme işlemi log'a düşer; sorulduğunda gösterecek bir şeyiniz olur. Yerelde tutulan hassas veriyi şifreli saklamak, sunucuyla haberleşmeyi TLS üzerinden yürütmek ve uygulamaya yalnızca ihtiyacı olan yetkiyi vermek bizde varsayılan ayar.

Eski sistemden veri taşıma da projelerin en çok küçümsenen kalemi. On yıllık cari hesap, kapanmamış açık faturalar, stok kartlarının çift kayıtları, elle düzeltilmiş bakiyeler… Veriyi olduğu gibi aktarmak çoğu zaman yanlış cevaptır; taşımadan önce temizlenmesi, eşleştirilmesi ve mutabakatının alınması gerekir. Biz bu adımı ayrı bir iş kalemi olarak planlıyoruz, çünkü göç gecesi sürprizi en pahalı sürprizdir. Kaynak sistem kapalı bir veritabanıysa dışa aktarma yolları önceden test edilir; ODBC bağlantısı, düz metin dökümü ya da rapor çıktısının ayrıştırılması — hangisi mümkünse.

Fiyatı belirleyen şey kullanıcı sayısı değil

Hazır paket dünyasında fiyat kullanıcı başına hesaplanır. On kişi kullanırsa on lisans. Kırk kişi kullanırsa kırk lisans, her yıl yenilenir. Bu mantık geliştirme tarafında geçerli değildir ve teklif alırken en sık karışan nokta budur. Bir özel yazılım projesinin maliyetini belirleyen üç şey var: iş kuralı sayısı, entegrasyon derinliği ve ekranların arkasındaki durum karmaşıklığı.

İş kuralı derken şunu kastediyoruz — "iskonto uygula" bir kural değildir, bir başlıktır. Kural şudur: bayi tipi A ise ve sipariş tutarı eşiği geçtiyse ve ürün grubu kampanyaya dahilse ve müşterinin vadesi otuz günü aşmadıysa iskonto şu oranda uygulanır, aksi halde satış temsilcisinin onayına düşer. Bu tek cümle; testi, ekranı, kayıt izi ve istisna yönetimiyle birlikte günlerce iştir. Yirmi kişilik bir şirketin böyle kırk kuralı olabilir, iki yüz kişilik bir şirketin altı tane. Fiyat farkı da oradan çıkar.

Entegrasyon derinliği ikinci kalem. Mevcut muhasebe programına fatura yazmak ile aynı programdan gerçek zamanlı bakiye okumak aynı iş değildir. Banka ekstresi eşleştirme, e-fatura entegratörü, kargo firmasının servisi, pazaryeri sipariş akışı, barkod okuyucu ve kantar gibi yerel donanımlar — her biri kendi hata senaryosunu getirir. Servis yanıt vermezse ne olacağı da tasarlanmalıdır; sessiz başarısızlık, bir süre sonra hiç kimsenin güvenmediği bir sisteme dönüşür. Teklifte "entegrasyon dahildir" ibaresini gördüğünüzde hangi yönde ve hangi sıklıkta veri aktığını mutlaka sorun.

Üçüncüsü, ekranın arkasındaki durum. Bir sipariş kaç aşamadan geçiyor, geri alınabiliyor mu, kısmi sevkiyat mümkün mü, iptal edilen kalem faturaya nasıl yansıyor? Kullanıcıya tek bir liste gibi görünen ekran, arkada onlarca geçiş kuralı taşıyabilir. Teklif isterken "kaç ekran olacak" sorusu bu yüzden yanıltıcıdır. Doğru soru şu: kaç karar noktası var ve her birinde yanlış giden senaryoda ne olacak? Bir kurumsal yazılım şirketi teklifi bu ayrımı yapmıyorsa, kapsamın yarısı sonradan ek iş olarak geri gelir.

Lisans yok ama geliştirme var

Karşılaştırmayı dürüst yapalım. Hazır pakette baştaki maliyet düşüktür, geliştirmede yüksektir. Buna karşılık hazır pakette her yıl lisans yenilenir, kullanıcı sayısı arttıkça faturaya yansır, kullanmadığınız modüller de aynı pakette gelir ve onların bedelini de ödersiniz. Kendi sisteminizde tekrarlayan kalem lisans değil bakımdır: sunucu, yedekleme, güvenlik güncellemesi ve yeni ihtiyaçların geliştirilmesi.

Hesabı beş yıla yayarak yapmak gerekir, tek yıla değil. Sorulacak sorular şunlar: paketin yıllık bedeli kullanıcı sayınız iki katına çıkarsa ne olur, kullanmadığınız modüllerin oranı ne, "özelleştirme" adı altında sağlayıcıya ödediğiniz danışmanlık kaç gün tutuyor, ve paketten çıkmak istediğinizde verinizi hangi formatta alabiliyorsunuz? Son soru en kritik olanı. Çıkış maliyeti görünmez bir kalemdir ve genelde sözleşme imzalanırken hiç konuşulmaz.

Bir özel yazılım projesinde ise ilk yıl yüklü, sonraki yıllar düzleşen bir eğri görürsünüz. Sistem oturduktan sonra harcama yeni ihtiyaç geldiğinde yapılır, takvim dolduğu için değil. İstanbul yazılım bütçeleri hazırlanırken bu farkı tabloya koymak işi kolaylaştırıyor: paket tarafında sabit ve artan bir kira, geliştirme tarafında bir yatırım ve ardından değişken bakım. Hangisinin daha ucuz olduğu işletmeye göre değişir; peşinen "geliştirme pahalıdır" demek de yanlış, "paket ucuzdur" demek de.

Hazır paket ne zaman daha doğru cevaptır

Her işletmeye özel yazılım gerekmez. Bunu açıkça söylüyoruz, çünkü yanlış projeye başlamak iki tarafı da yorar. İşiniz standart bir akışta yürüyorsa, mevzuatın çizdiği sınırların dışına çıkan bir kuralınız yoksa ve rekabet avantajınız süreçlerinizden değil ürününüzden geliyorsa hazır paket doğru seçimdir. Ön muhasebe, bordro, e-fatura, temel müşteri takibi — bu alanlarda olgun ve ucuz paketler var. Bunları yeniden yazmak paranın israfıdır.

Sınırı şu soruyla çizmek işe yarıyor: bu süreç rakiplerinizden farklı mı, yoksa herkesin yaptığı gibi mi yapılıyor? Farklıysa ve o fark size para kazandırıyorsa, o süreci hazır bir pakete sığdırmaya çalışmak farkı silmek demektir. Herkesle aynıysa, hazır paket zaten sizin için düşünülmüş. İkinci bir eşik daha var: süreç önümüzdeki iki yılda değişecek mi? Değişmeyecekse pakete uyum sağlamak katlanılabilir bir bedel. Antalya yazılım görüşmelerimizin bir kısmı bu noktada teklifsiz bitiyor; işletmeye hazır bir paket öneriyoruz ve iş orada kapanıyor.

Melez kurgu da sık tercih ediliyor ve çoğu zaman en akıllıca yol bu oluyor. Muhasebe ve bordro pakette kalır, farklılaştığınız operasyon katmanı için ayrı bir uygulama yazılır, ikisi entegrasyonla konuşur. Böylece mevzuat takibini paket sağlayıcısı sırtlanır, siz de işinizin kalbindeki akışı kendi kontrolünüzde tutarsınız. İstanbul yazılım projelerinde bu modeli sıkça kuruyoruz; merkez ofisin finansal altyapısı yerinde dururken saha ve operasyon tarafı ayrı bir sistemle yönetiliyor.

Tek kod tabanı, dört platform ve kaynak kodun sahibi

Teknik tarafta iki şey işin ekonomisini değiştiriyor. Birincisi, aynı çekirdeği Windows, Linux, macOS ve web üzerinde çalıştırmamız. Depodaki terminal Windows, muhasebenin bilgisayarı macOS, sunucudaki servis Linux, bayinin eriştiği panel tarayıcı olabilir — dört ayrı ekip, dört ayrı bakım bütçesi gerekmez. Windows tarafında MSI ve MSIX paketleme, Linux tarafında .deb, .rpm ve AppImage, macOS tarafında Apple imzalı ve noter onaylı .dmg dağıtımı standart teslimatın parçası.

Masaüstü tarafında bir avantaj daha var: yerel donanım. Tarayıcı bir kantarla, seri porta bağlı bir etiket yazıcısıyla ya da eski bir barkod terminaliyle doğrudan konuşamaz. Masaüstü uygulama konuşur. Depoda etiket basmak, kasada fiş kesmek, üretim hattında tartım almak gerekiyorsa bu fark projeyi baştan şekillendirir. Donanımla konuşan bir özel yazılım tasarlarken cihazın markası ve sürücü desteği kapsam belgesine yazılır, çünkü aynı kantarın iki modeli farklı protokol konuşabiliyor. Çerçeveyi de buna göre seçiyoruz — paket boyutu, performans ve donanım erişimi ihtiyacına göre birlikte karar veriyoruz.

İkincisi mülkiyet. Kaynak kod, paket imzalama sertifikaları ve dağıtım kanalı yetkileri sözleşmeyle müşteride kalır. Yarın başka bir ekiple devam etmek isterseniz elinizde çalışan bir sistem olur, bir rehin değil. Bu tercih bize kolay müşteri kaybı riski getiriyor, farkındayız. Gel gelelim, kilitlenmiş müşteriyle kurulan ilişki uzun vadede kimseye yaramıyor. Alanya yazılım geliştirme ekibimiz projeleri en baştan bu varsayımla kuruyor: belgelenmiş, devredilebilir, okunabilir kod.

İş akışını çıkarmak, kapsamı yazmak, veri modelini kurmak

Süreç şöyle yürüyor. Önce sahaya geliyoruz. Toplantı odasında anlatılan akış ile masada gerçekten olan akış arasında neredeyse her zaman fark çıkar; depo görevlisinin not defteri, satışçının telefonundaki mesaj listesi, muhasebenin ayrı tablosu — sistemin kapsaması gereken asıl iş oralarda saklı. Bir gün gözlem, bir yığın soru. Sonra iş akışı diyagrama dökülür ve karşı tarafa okutulur; "burası yanlış" denmesi iyi haberdir, çünkü kodlanmadan önce denmiştir. Bu adımı atlayan bir kurumsal yazılım şirketi size hızlı başlangıç sözü verir, altıncı ayda kapsam tartışması yaşatır.

Kapsam belgesi bunun ardından yazılır. İçinde ekran listesi, rol ve yetki matrisi, iş kuralları, entegrasyon noktaları, kapsam dışı bırakılanlar ve kabul kriterleri yer alır. Kapsam dışı bölümü en az kapsam kadar kritiktir; ilk sürümde neyin olmayacağını yazmak, projeyi süresiz uzayan bir isteğe dönüşmekten korur. Bir özel yazılım projesini raydan çıkaran şey genelde kötü kod değil, yazılı olmayan beklentidir.

Veri modeli üçüncü adım ve geri dönüşü en pahalı olanı. Bir kaydın hangi durumlardan geçtiği, hangi alanın zorunlu olduğu, silmenin gerçekten silme mi yoksa pasife alma mı olduğu, geçmişe dönük düzeltmenin muhasebeyi nasıl etkileyeceği — bunlar baştan kararlaştırılmazsa altı ay sonra tabloları taşımak zorunda kalırsınız. Ardından iterasyon başlar: iki üç haftalık turlar, her turun sonunda çalışan bir sürüm, gerçek veriyle deneme. Ekran görüntüsü değil, tıklanabilir sistem. Her turun sonunda ne yapıldığı ve bir sonraki turda neye bakılacağı tek sayfada yazılır.

Eğitim, devreye alma ve ilk ay

Devreye alma günü projenin bitişi değil, en riskli anıdır. Genelde paralel çalışma öneriyoruz: eski sistem bir süre daha açık kalır, yeni sisteme aynı veriler girilir, iki taraf karşılaştırılır. Sıkıcı bir dönem. Ama farkı kapanışta değil, ilk haftada yakalamanızı sağlıyor. Geri dönüş planı da yazılı olur — hangi koşulda eski sisteme dönüleceği, o gün girilen verinin ne olacağı baştan bellidir.

Eğitim tarafında sunum yerine kendi verinizle çalışmayı tercih ediyoruz. Kullanıcı kendi müşterisinin kaydını açıp kendi siparişini girdiğinde öğreniyor; örnek kayıtlarla değil. Rol bazlı kısa oturumlar, sonrasında ekran içi yardım metinleri ve kimin neyi soracağını bilen tek bir iç sorumlu. İlk ay boyunca hata bildirimleri önceliklendirilir ve haftalık sürümlerle kapatılır. Otomatik güncelleme altyapısı sayesinde yeni sürüm kullanıcıya kendiliğinden iner; kimse elle kurulum yapmaz. Antalya yazılım projelerinde yoğun sezon başlamadan önce devreye almayı planlıyoruz; Ağustos'un ortasında sistem değiştirmek kimsenin işine yaramaz.

Sonrasında ne oluyor? İlk üç ay kullanım verisi izlenir. Hangi ekran hiç açılmıyor, hangi rapor her gün alınıyor, kullanıcı nerede duraksıyor — bunlar sistemin ikinci sürümünü şekillendirir. Yazılım teslim edilen bir ürün değil, işletmeyle birlikte yaşayan bir araç. Alanya yazılım tarafındaki ekibimiz destek taleplerini de bu gözle okuyor: tekrarlayan soru, eğitim eksikliği değil tasarım eksikliği demektir. Aynı ekranla ilgili üçüncü kez soru geliyorsa o ekranı yeniden çiziyoruz, kullanıcıyı yeniden eğitmiyoruz.

Sıkça sorulan sorular

Hazır paketi özelleştirmek mi, sıfırdan yazmak mı daha mantıklı?
Cevap paketin ne kadar açık olduğuna bağlı. Bazı paketlerin eklenti altyapısı gerçekten esnektir; kural motoru, servis arayüzü ve rapor tasarımcısı vardır — o zaman özelleştirme daha ucuz ve hızlı yoldur. Bazılarında ise "özelleştirme" sağlayıcının kaynak kodunda yaptığı yamadır ve her sürüm yükseltmesinde yeniden kırılır. İkinci durumda üç yıl sonunda ödediğiniz toplam, kendi sisteminizin bedelini geçer. Teklif isterken paketin özelleştirme mimarisini sorun, önce fiyatını değil. Sağlıklı bir özel yazılım kararı, paketin ne yapabildiğini gerçekten öğrendikten sonra verilir.
Beş kişilik bir şirkete de yazılır mı?
Yazılır, ama gerekçesi kişi sayısı olmamalı. Beş kişilik bir laboratuvarın numune izleme akışı benzersizse ve o akış işin kendisiyse, bir özel yazılım yatırımı anlamlıdır. Beş kişilik bir danışmanlık ofisi standart bir teklif ve fatura döngüsü yürütüyorsa anlamlı değildir. Ölçek değil, farklılık belirleyicidir. Küçük ekiplerde kapsamı dar tutup tek bir acı noktayı çözmek genelde daha isabetli oluyor; ilk sürüm küçük olsun, işe yaradığı görülsün, sonra büyüsün.
Eski programdaki on yıllık veri ne olacak?
Üç seçenek var ve genelde üçü birden kullanılır. Aktif veri yeni sisteme taşınır: açık cariler, güncel stok, devam eden siparişler. Geçmiş veri salt okunur bir arşive alınır; sorgulanabilir kalır ama yeni sistemi yavaşlatmaz. Kapalı formatta sıkışmış veri için dışa aktarma yolu bulunamıyorsa eski program bir sanal makinede erişilebilir bırakılır. Hangisinin seçileceği denetim yükümlülüğünüze ve verinin gerçekten aranıp aranmadığına göre kararlaştırılır. Pratikte beş yıl öncesinin hareket detayına neredeyse hiç bakılmıyor; bakılan şey bakiye ve belge.
Proje süresi neye göre değişiyor?
Ekran sayısına değil, karar sayısına göre. Kapsam belgesi net çıkmış, veri modeli üzerinde uzlaşılmış ve karşı tarafta yetkili tek bir karar verici varsa proje hızlı ilerler. Kararlar toplantıdan toplantıya ertelendiğinde ya da her turda yeni bir departman farklı bir istekle geldiğinde süre iki katına çıkar. Bizim tarafımızdaki en büyük hızlandırıcı, sizin tarafınızda haftada birkaç saat ayırabilen bir iş sahibi. Bunu teklif aşamasında konuşuyoruz, sonradan sürpriz olmasın diye. Uzaktan yürüyen İstanbul yazılım projelerinde haftalık sabit bir görüşme saati koymak, aylık uzun toplantılardan çok daha iyi işliyor.
Kaynak kod bende kalacaksa siz nasıl kazanıyorsunuz?
Geliştirmeden ve sonrasındaki bakımdan. Lisans kilidi kısa vadeli bir gelir modeli; iş devam ediyorsa müşteri zaten kalıyor, devam etmiyorsa kilit sadece kötü bir ayrılık yaratıyor. Yıllar içinde gördük ki en sağlam işler, müşterinin istediği an gidebileceğini bilerek kaldığı işler. Alanya yazılım ekibimizin portföyünde bu şekilde uzun süredir yaşayan sistemler var — hiçbiri sözleşme zorunluluğuyla değil. Bir kurumsal yazılım şirketi seçerken bu maddeyi sözleşmede aramanızı öneririz.
Uygulama internet kesildiğinde durur mu?
Doğru tasarlandıysa durmaz. Yerel veritabanı kaydı cihazda tutar, bağlantı geldiğinde sunucuyla eşitler. Kritik olan çakışma çözümlemesi: aynı kayıt iki cihazda değiştiyse hangisi kazanır, kullanıcıya sorulur mu, yoksa zaman damgasına mı bakılır? Bu kural işin doğasına göre belirlenir. Kasa ve depo uygulamalarında çevrimdışı dayanıklılığı varsayılan olarak kuruyoruz, sonradan eklenen bir özellik olarak değil. Antalya yazılım tarafında otel ve restoran projelerinde bu madde neredeyse her zaman ilk sırada geliyor.