Müşteriler

Birlikte yazılım inşa ettiğimiz markalar

Kurumsal web, portal, ERP, panel ve teknik servis yazılımları — onlarca marka için uçtan uca teslim ettik.

İş Ortakları

İş Ortaklarımız

Birlikte ürettiğimiz, birlikte büyüdüğümüz markalar.

Beyzick logo

Beyzick

Sunucu bakım hizmetleri · Güvenlik hizmetleri
Alanya TEKMER logo

Alanya TEKMER

Portal hizmeti · Web hizmeti
ZKM Teknoloji logo

ZKM Teknoloji

Robotik geliştirmeler · Web hizmetleri
Antargetech logo

Antargetech

Stratejik iş ortağı · Ortak proje girişimleri

ZSoftrade logo

ZSoftrade

Sunucu hizmetleri · Web hizmetleri · İhtiyaca özel uygulama geliştirme

Projeler

Teslim ettiğimiz işler

Kurumsal web, portal, ERP ve panel projeleri.

17

Yavuhasan Sosyal Yardımlaşma ve Dayanışma Derneği

Kurumsal web sitesi · Mobil uygulama geliştirme

19

Marmara Türk

Gıda sektörü · IT hizmeti

20

Global Türk

Gıda sektörü · IT hizmeti

21

Aquacity

Gıda sektörü · IT hizmeti

22

Mistiko

Mobil uygulama geliştirme

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 →

Referans listesine bakarken aslında neye bakıyorsunuz

Referans listesine bakarken aslında neye bakıyorsunuz

Bir işletme sahibi teklif almadan önce tedarikçinin referans sayfasını açar, logolara bakar, birkaçını tanır, sonra sekmeyi kapatır. Elinde kalan tek bilgi şudur: bu firma başkalarıyla da çalışmış. Karar için yeterli mi? Değil. Logo bir işin yapıldığını gösterir; nasıl yapıldığını, kapsam değiştiğinde kimin ne yaptığını ve teslimden sonra telefonun açılıp açılmadığını göstermez. Yazılım projeleri tam olarak bu görünmeyen kısımda ayrışır. İki firma benzer işler çıkarmış olabilir; birinde süreç yazılıdır, diğerinde her şey tek bir kişinin hafızasında durur.

Bu sayfayı bir vitrin gibi kurgulamadık. Kiminle çalıştığımızı sıralamak yerine, bir tedarikçiyi neye göre değerlendirebileceğinizi anlatmayı tercih ediyoruz. Bir kurumsal yazılım şirketi seçerken elinizde kalması gereken şey isim listesi değil, soru listesidir. Aşağıdaki başlıklar da o soruları çıkarmak için yazıldı.

Sırayla şunlara bakacağız: hangi sektör hangi ihtiyaçla masaya oturuyor, tedarikçi seçerken hangi hatalar tekrar ediyor, bir referansı incelerken hangi cevaplar belirleyici, kaynak kod ve dokümantasyon nasıl yazıya geçiyor, iş bittikten sonra ilişki nasıl yürüyor. İsim vermiyoruz. Vaka anlatmıyoruz. Anlattığımız şey, kendi değerlendirmenizi yapabilmeniz için gereken çerçeve.

Hangi sektör hangi ihtiyaçla masaya oturuyor

Perakendede ilk talep neredeyse her zaman stok tarafından gelir. Birden fazla satış kanalı açılmıştır — mağaza, pazaryeri, kendi sitesi — ve üçünün stoğu ayrı yerde tutulmaktadır. Aynı ürün iki kanalda birden satıldığında iptal edilen sipariş, müşteri kaybının en pahalı biçimi olur. İkinci sırada fiyat ve kampanya yönetimi gelir. Üçüncüsü iade akışı; kâğıt üzerinde basit görünür, sahada en karışık süreçtir. Herkes bunu geç fark eder. Bu üç başlık genelde aynı toplantıda konuşulur, ama aynı anda çözülmez.

Üretimde başlangıç noktası iş emri. Sipariş geldiğinde hangi makinenin ne zaman boşalacağı, hangi hammaddeden ne kadar kaldığı ve bir işin gerçekte kaç aşamadan geçtiği çoğu tesiste yazılı değildir; ustabaşının hafızasındadır. Hazır paket buraya oturmaz, çünkü akış her tesiste kendine özgüdür. Talep zaten "bize uyan bir program" cümlesiyle gelir. İzlenebilirlik ikinci başlıktır. Hangi parti hangi siparişe gitti sorusunun cevabı, şikâyet anında lazım olur ve o an aramaya başlamak geçtir. Kayıt yoksa cevap da yok.

Hizmet tarafında mesele randevu ve zaman. Kaynak insandır, insan da bölünmez. Çakışan randevu, boş kalan saat ve gelmeyen müşteri doğrudan gelire yazılır. Buradan gelen taleplerin çoğu takvim, hatırlatma ve raporlama etrafında toplanır. Yazılım projelerinin ölçeği burada küçük görünür, etkisi ise hızlı ölçülür. Küçük kapsamlı bir iş, doğru yere dokunduğunda büyük bir sistemden daha fazla iş görebiliyor.

Sektörler farklı, kalıp aynı. Her birinde talep bir tıkanmayla başlar: elle yürütülen bir iş büyümüştür, iki sistem birbiriyle konuşmamaktadır ya da kritik bir bilgi tek kişinin kafasında durmaktadır. Yazılım projeleri bu tıkanmanın hangisi olduğu netleştiğinde doğru kurgulanır. Netleşmediğinde kapsam ilk aydan itibaren şişer. Bir tedarikçiyi değerlendirirken bakılacak ilk şey de bu — ilk toplantıda size ne anlattığı değil, ne sorduğu. İşinizi anlamak isteyen taraf mevcut akışı adım adım yazdırır, kim hangi adımda ne yapıyor diye tek tek sorar. Hazır bir çözümü uydurmayı planlayan taraf ise doğrudan ekran gösterir. İkisi arasındaki fark ilk yarım saatte anlaşılır.

Sağlık, turizm ve eğitim tarafında ilk talep

Sağlıkta konu veriyle başlar. Hasta kaydı, görüntüleme dosyaları, randevu akışı ve erişim yetkisi aynı cümlenin içinde geçer. Hangi personelin hangi kayda erişebileceği önceden tanımlanmamışsa, bir denetim karşısında gösterilebilecek dayanak da bulunmaz. Sözlü mutabakat sayılmaz. Talep çoğunlukla "hasta takibini düzenleyelim" diye başlar; birkaç toplantı sonra saklama süresi ve yetki matrisi konuşulmaya başlanır. Kapsamın büyüdüğü nokta da genelde burasıdır ve bunu baştan görmek, sonradan pazarlık etmekten iyidir.

Turizm ve konaklamada takvim belirleyici. Sezon açılmadan yapılmayan iş, sezon içinde yapılamaz. Rezervasyon tarafı, misafir internet erişimi, kapı kilit sistemi ve muhasebe entegrasyonu aynı anda ayakta durmak zorundadır. Antalya yazılım tarafında gelen taleplerin sezon öncesinde yoğunlaşmasının nedeni de bu. Bir de dil meselesi var. Aynı arayüzün birden fazla dilde çalışması sonradan eklenen bir özellik olarak düşünüldüğünde pahalıya patlar, çünkü metin yönetimi baştan kurulmamıştır.

Eğitimde ölçek ve dönem var. Kayıt dönemi kısadır, yoğundur, sistem o hafta ayakta kalmak zorundadır. Veli iletişimi, devamsızlık takibi, ödeme planı ve belge üretimi arka arkaya dizilir. Bu sektörlerin ortak noktası şu: hiçbirinde talep "bize bir yazılım lazım" diye gelmez. Somut bir aksaklıkla gelir. Alanya yazılım ekibimizin ilk toplantıda yaptığı iş de aksaklığı sonuna kadar dinlemek, çözüm önermeye acele etmemektir. Erken önerilen çözüm, yanlış soruya verilmiş doğru cevap olma riski taşır.

Ortak bir yanılgı da şu: her sektörün kendine ait hazır bir çözümü olduğu ve doğru paketi bulmanın yeterli olacağı düşüncesi. Paketler gerçekten iş görür. Belirli bir büyüklüğe kadar. Sınır, işletmenin kendine özgü akışıyla paketin varsaydığı akışın çeliştiği yerde başlar. O noktada iki yol kalır: ya işletme kendini yazılıma uydurur ya da yazılım işletmeye uydurulur. Birincisi ucuz görünür, çalışan direnciyle karşılaşır ve genelde gölge bir Excel dosyası doğurur. İkincisi pahalı görünür, kalıcı olur. Hangisinin doğru olduğu, o akışın işletme için bir rekabet avantajı olup olmadığına bağlıdır. Antalya yazılım tarafında bu ayrımı ilk keşif toplantısında masaya koyuyoruz.

Sayıya bakmak, işin içeriğine bakmamak

En sık yapılan hata referansın sayısını ölçü almak. Uzun bir liste, tedarikçinin çok çalıştığını gösterir; sizin işinize benzer bir iş çıkardığını göstermez. Listenin uzunluğu bazen tam tersini bile anlatır: kısa süreli, birbirinden kopuk ve bakımı devam etmeyen işlerden oluşan bir geçmiş, uzun soluklu bir çalışmayı yürütebildiğine dair kanıt değildir. Bakılması gereken şey adet değil derinlik. Süre de bir kanıttır. Aynı kurumla yıllara yayılan bir ilişki, on ayrı kurumla yapılmış tek seferlik işten daha fazla şey anlatır.

İkinci hata benzer sektör aramak. "Bizim sektörde iş yapmış mı" sorusu makul görünür, ama yanıltıcıdır. Aynı sektördeki iki işletmenin süreçleri birbirine benzemeyebilir; iki farklı sektördeki iki işletmenin ihtiyacı ise teknik olarak neredeyse aynı olabilir. Çok şubeli bir restoran zinciriyle çok şubeli bir perakendecinin stok ve yetki problemi aynı ailedendir. Etiket yanıltır. Sektör etiketi yerine problem tipine bakmak daha doğru sonuç verir: entegrasyon ağırlıklı mı, saha kullanımı mı, raporlama mı, yoğun eşzamanlı kullanıcı mı.

Sektör benzerliğinin gerçekten işe yaradığı bir alan var: mevzuat. Sağlık, finans ve kamuya iş yapan yapılarda uyulması gereken kurallar teknik tercihleri doğrudan sınırlar. Orada deneyim gerçekten fark yaratır. Onun dışında "sizin sektörü biliyoruz" cümlesi çoğu zaman bir satış cümlesidir. Yazılım projelerinde asıl belirleyici olan, tedarikçinin sizin işinizi anlamak için ne kadar soru sorduğu. Az soru soran taraf, kendi hazır çözümünü uydurmayı planlıyor olabilir.

Bir hata daha eklenebilir: yalnız toplam fiyata bakmak. En düşük teklif çoğu zaman en dar kapsamdır. Eğitim yoksa, bakım yoksa, yayın sonrası düzeltme yoksa toplam elbette küçük çıkar ve aradaki fark ilk aylarda kapanır. Karşılaştırma kalem kalem yapılmalı. Yazılım projelerinde pahalıya patlayan şey yüksek teklif değil, eksik yazılmış tekliftir. Bir uyarı daha: teklifi hazırlayan kişiyle işi yapacak kişi farklıysa, satış masasında verilen sözlerin teknik ekibe ulaşıp ulaşmadığını sormakta fayda var. Sözlü kalan her söz, ilk anlaşmazlıkta buharlaşır. Alanya yazılım ekibimizde keşif toplantısına işi yürütecek kişinin katılması bu yüzden kural.

Bitmiş işi görmek, süreci sormamak

Üçüncü hata ekranlara bakıp yolculuğu atlamak. Bitmiş bir arayüz her zaman iyi görünür. Hepsi güzel görünür. Görünmeyen kısım şudur: o ekran kaç kez değişti, kim karar verdi, ilk teslimde ne eksikti, eksik çıktığında nasıl kapatıldı. Sunumda gösterilen ürünün ilk halinden ne kadar uzaklaştığı, tedarikçinin geri bildirimle çalışıp çalışmadığını gösterir. Hiç değişmeden teslim edilmiş bir iş övünülecek bir şey değil; büyük ihtimalle kimse kullanmamıştır.

Dördüncü hata iletişim ritmini hiç konuşmamak. Sözleşmede kapsam yazar, takvim yazar, bedel yazar. Haftada kaç kez konuşulacağı, hangi kanaldan ilerleneceği, kimin karar verici olduğu ve bir sorunun ne kadar sürede cevaplanacağı çoğu zaman yazmaz. Sonra ilk gecikmede taraflar birbirini beklemeye başlar. Sessizlik pahalıdır. Bir haftalık cevapsızlık, iki haftalık gecikme üretir; iki haftalık gecikme de kapsam tartışmasına dönüşür.

Beşinci hata ise karar vericiyi belirsiz bırakmak. Kurum içinde projeyi kimin sahiplendiği netleşmediğinde her toplantıda başka bir görüş öne çıkar ve kapsam sürekli yön değiştirir. Bu, tedarikçinin değil müşterinin tarafındaki bir sorundur, ama faturası ortak ödenir. İstanbul yazılım taleplerinde birden fazla departmanın aynı masada olduğu durumlar sık görülür; orada ilk iş, kimin son sözü söyleyeceğini yazıya geçirmek oluyor.

Altıncı hata teknik borcu hiç konuşmamak. Hızlı teslim edilen her iş, arkasında bir miktar geçici çözüm bırakır. Bu kaçınılmaz. Anormal olan, o geçici çözümlerin listesinin hiç tutulmaması. Bir tedarikçiye sorulabilecek en sağlam sorulardan biri şu: teslim ettiğiniz işte bilerek ertelediğiniz şeyler oldu mu, olduysa yazılı mı? Cevap verebilen taraf işini biliyordur. Cevabı "hiç öyle bir şey olmadı" olan taraf ya listeyi tutmamıştır ya da sorunun ne anlama geldiğini kavramamıştır. Yazılım projelerinde altı ay sonra ortaya çıkan yavaşlamaların büyük bölümü, kimsenin yazmadığı bu geçici çözümlerden doğuyor.

Referans görüşmesinde sorulacak sorular

Bir tedarikçinin referansıyla konuşma imkânı bulursanız, konuşmayı memnuniyet sorusuyla başlatmayın. "Memnun kaldınız mı" sorusunun cevabı neredeyse her zaman evettir ve hiçbir şey öğretmez. Bunun yerine takvimi sorun: iş ne kadar sürecekti, ne kadar sürdü, arada fark varsa nereden çıktı. Gecikme her projede olur. Öğrenmek istediğiniz şey gecikmenin varlığı değil, nasıl yönetildiği.

İkinci soru kapsam değişikliğiyle ilgili. Çalışma sırasında yeni bir ihtiyaç doğduğunda ne oldu? Yazılı bir değişiklik talebi mi üretildi, yoksa "hallederiz" denip sonra fatura mı geldi? Bu tek soru, bir tedarikçinin çalışma kültürü hakkında sözleşmenin tamamından fazla şey söyler. Üçüncüsü teslim sonrası: teslimden sonraki ilk ay nasıl geçti, hata çıktığında kaç saatte dönüş yapıldı, düzeltmeler için ayrı ücret istendi mi.

Dördüncüsü kaynak kod ve erişim. Kod kimde duruyor, depoya erişiminiz var mı, sunucu hesapları kimin adına açıldı? Beşincisi bakım: bakım anlaşması yapıldı mı, yapıldıysa kapsamı neydi, kapsam dışı işler nasıl fiyatlandı. Altıncısı ekip sürekliliği; işi başlatan kişilerle bitiren kişiler aynı mıydı. Yazılım projelerinde ekip değişikliği tek başına kötü bir işaret sayılmaz, ama devrin nasıl yapıldığı bir olgunluk göstergesidir.

Yedinci bir soru var ve cevabı çoğu zaman en açık göstergedir: bir şey ters gittiğinde ne yaptılar? Her çalışmada bir aksama olur. Bir entegrasyon beklenmedik biçimde davranır, kullanılan bir servis kurallarını değiştirir, bir varsayım yanlış çıkar. Referansın anlattığı hikâyede hiçbir aksamanın geçmemesi, hafızanın seçici olduğunu ya da anlatılanın gerçeği yansıtmadığını düşündürür. Sorunu kabul edip nasıl kapattığını anlatabilen bir tedarikçi, hiç sorun yaşamadığını söyleyenden daha sağlam bir taraftır. İstanbul yazılım taleplerinde referans görüşmeleri çoğunlukla tam bu soruda ayrışıyor. Anlatılan çözüm yolu, teknik yeterlilikten çok karakter gösterir.

Kaynak kod, dokümantasyon ve devrin yazılı hali

Kaynak kodun kimde kalacağı işin başında konuşulur. Sonradan konuşulduğunda taraflardan biri mutlaka hayal kırıklığı yaşar. Üç ayrı model var ve üçü de meşru: kod tamamen müşteriye devredilir, kullanım hakkı verilir ama mülkiyet tedarikçide kalır, ya da ortak bir lisans kurgusu yazılır. Hangisi seçilirse seçilsin, seçim sözleşmede açıkça yazmalı. Biz devir tarafını tercih ediyoruz; bir işletmenin kendi süreçlerini yürüten kodun anahtarına sahip olmasını doğru buluyoruz.

Dokümantasyon da aynı mantıkla ele alınır. Bir sistemin nasıl kurulduğu, hangi servislerin nerede çalıştığı, veri modelinin mantığı ve geçmişte hangi kararın neden alındığı yazılı olmalı. Bu belgeler tedarikçinin iç notu değil, işletmenin varlığıdır. Yıllar sonra başka bir ekip devraldığında sıfırdan keşif yapmak zorunda kalmaması buna bağlı. Kodun okunabilir olması yetmez; niye o şekilde yazıldığı kod içinde görünmez. Gerekçe ayrı yazılır.

Devir konusu ilişkinin sonunda değil, başında tanımlanır. Erişim bilgileri, depo, sunucu hesapları, alan adı yönetimi, sertifikalar ve üçüncü taraf servis hesapları tek listede tutulur. Anlaşma bittiğinde bu liste karşı tarafa teslim edilir ve bir devir toplantısı yapılır. Bunu bir nezaket olarak değil, çalışma biçimi olarak kuruyoruz. Bir kurumsal yazılım şirketi çıkışı zorlaştırarak müşteri tutuyorsa, orada bir teknik yeterlilik sorunu vardır.

Erişim hakları da aynı başlığın altında duruyor. Alan adı kimin hesabında kayıtlı, sunucu hangi e-posta adresiyle açıldı, ödeme yöntemi kime ait, kullanılan servislerin yönetici hesabı kimde? Bunlar idari ayrıntı gibi görünür. İlişki bittiğinde ise en çok zaman kaybettiren yer tam olarak burasıdır. Kural basit: bütün hesaplar işletmenin adına ve işletmenin kurumsal e-posta adresiyle açılmalı, tedarikçiye yetkili kullanıcı olarak erişim verilmeli. Kaynak kod devri sözleşmede yazdığı halde alan adının tedarikçinin kişisel hesabında durduğu işler sahada hâlâ karşımıza çıkıyor. Öyle bir durumda kodun kimde olduğunun pratikte bir kıymeti kalmıyor.

Teslimden sonra ilişki nasıl yürüyor

Yayına alma bir bitiş değil, bir başlangıç. İlk haftalarda gerçek kullanıcı gerçek veriyle sisteme girdiğinde, test ortamında hiç görünmemiş davranışlar ortaya çıkar. Bir alanı kimse doldurmaz. Bir rapor beklenenden yavaş açılır. Bir kullanıcı, tasarlanmamış bir sırayla ilerlemeye çalışır. Bunlar hata değil, kullanım gerçeği. İlk ayı bu yüzden ayrı bir aşama olarak planlıyoruz ve düzeltmeleri ayrı fatura konusu yapmıyoruz.

Bakım kapsamı yazılı olmak zorunda. Hangi işlerin dahil olduğu, hangilerinin ayrı teklif gerektirdiği, hedeflenen cevap süresinin ne olduğu ve güncellemelerin hangi ritimde yapılacağı maddeler halinde durur. Kapsam belirsiz bırakıldığında her talep bir pazarlığa dönüşür, ilişki de yıpranır. Sınırda kalan işleri de yazıyoruz. Asıl anlaşmazlık her zaman gri alanlardan çıkıyor.

İzleme tarafı çoğu zaman atlanır. Bir uygulama sessizce yavaşlayabilir, arka plan işleri sessizce durabilir, disk sessizce dolabilir. Uyarı kurulmamışsa bunları ilk fark eden kişi kullanıcı olur ve o noktada iş çoktan aksamıştır. Geç kalınmıştır. Kurduğumuz sistemleri izlemeye alıyoruz; eşikler belirleniyor, uyarılar tek kanala düşüyor. Alanya yazılım ekibimizin en sık müdahale ettiği durumlar da kullanıcıya hiç yansımadan kapanıyor.

Yeni ihtiyaç geldiğinde ise akış belli. Talep yazılı olarak alınır, mevcut yapıya etkisi değerlendirilir, ayrı bir kapsam ve teklif çıkar. Küçük düzeltmelerle yeni özellik talebini aynı torbaya koymuyoruz; ikisi farklı işler ve farklı planlanır. Antalya yazılım tarafında çalıştığımız işletmelerin çoğunda ikinci yıl konuşulan başlıklar, ilk yıl hiç gündemde olmayan şeyler oluyor. İşletme değişiyor, sistem de onunla birlikte değişiyor.

Kullanım ölçümü de bakımın bir parçası. Bir özelliğin yazılmış olması, kullanıldığı anlamına gelmiyor. Hangi ekranın kaç kez açıldığı, hangi raporun hiç çalıştırılmadığı ve kullanıcıların nerede takıldığı ölçüldüğünde bir sonraki geliştirme listesi tahminle değil veriyle çıkıyor. Aynı ölçüm bütçeyi de koruyor: kullanılmayan bir modüle daha fazla emek harcanmasını baştan engelliyor. Yazılım projelerinin ikinci yılında yapılan en verimli iş genelde yeni özellik eklemek olmuyor. İşe yaramayanı ayıklamak oluyor. Bir kurumsal yazılım şirketi ile uzun süreli çalışmanın gerçek getirisi de bu sadeleştirme kabiliyetinde ortaya çıkıyor.

Sıkça sorulan sorular

Referans listesindeki isimlerle konuşabilir miyim?
Bunu istemek hakkınız. Ciddi bir tedarikçi, müşterisinin iznini alarak bu görüşmeyi ayarlayabilir. Reddedilmesi tek başına kötü işaret değildir; bazı kurumlar sözleşmeleri gereği isim verilmesine izin vermez. Cevap "hayır" ise ikinci bir yol var: sizinle benzer nitelikte bir işin sürecini anonim olarak anlatmalarını isteyin. Kapsam nasıl yazıldı, hangi noktada değişti, teslim sonrası ne oldu. Anlatım akıcıysa iş gerçekten yaşanmıştır. Ayrıntı hatırlanmıyorsa kuşkulanın. Yazılım projelerinde yaşanmış bir süreç, aradan zaman geçse de tarifi kolay anlatılır.
Küçük bir işletmeyim; büyük referansları olan bir firma benimle ilgilenir mi?
Sorulması gereken soru ilgilenip ilgilenmediği değil. Sizin işinizin o firmanın içinde hangi önceliğe düşeceği. Küçük kapsamlı bir iş, sırası geldiğinde değil boş kalan zamanda yapılıyorsa takvim sürekli kayar. Bunu anlamanın yolu net: işi kimin yürüteceğini ve haftada ne kadar zaman ayrılacağını sorun. Cevap muğlaksa, ölçek uyumsuzluğu var demektir. Yazılım projelerinde ölçek uyumu, teknik yeterlilikten daha sık sorun çıkarır.
Sabit fiyat mı, zaman bazlı çalışma mı daha güvenli?
İkisi de doğru olabilir, kapsamın netliğine bağlı. Kapsam net yazıldıysa sabit fiyat tarafları korur. Kapsam belirsizse sabit fiyat, tedarikçiyi en dar yorumu uygulamaya iter ve her ek talep pazarlık konusu olur. Keşif aşamasını ayrı bir iş olarak yapmak bu yüzden mantıklı: önce kapsam çıkar, sonra fiyat konuşulur. Kapsamı görmeden verilen fiyat iki taraf için de risklidir. Zaman bazlı model ise şeffaflık ister; harcanan sürenin kalem kalem raporlanmadığı bir kurguda müşteri kısa sürede güvenini yitirir. Antalya yazılım tarafında keşif çıktısını ayrı bir belge olarak teslim ediyoruz. O belgeyle başka bir tedarikçiden teklif almanız da mümkün.
Aynı firmadan hem yazılım hem sistem desteği almak doğru mu?
Çoğu durumda işinize yarar. İki ayrı firmayla yürüyen bir yapıda sorun çıktığında sorumluluk topu havada kalır; biri ağı, diğeri kodu işaret eder, siz de aradaki hakemliği üstlenirsiniz. Tek muhatap varken o tartışma doğmaz. Sunucuyu tanıyan ekip uygulamanın nerede takıldığını da daha hızlı buluyor. Riski de yazalım: tek tedarikçiye bağlanmak, çıkış planı yoksa bağımlılık üretir. Panzehiri dokümantasyon ve erişim haklarının sizde olması. İstanbul yazılım ve destek taleplerinde bu iki şartı baştan yazıya geçiriyoruz.
Teklifleri karşılaştırırken neye dikkat etmeliyim?
Toplam rakama değil, kalemlere. İki teklifin toplamı yakınsa bile içerikleri bambaşka olabilir. Bakım dahil mi, kaç ay? Eğitim var mı, kime veriliyor? Sunucu ve alan adı kimin adına? Kaynak kod devri yazıyor mu? Yayın sonrası düzeltmeler kapsamda mı? Bu beş sorunun cevabı iki teklif arasındaki gerçek farkı gösterir. Ucuz görünen teklif, eksik yazılmış teklif olabilir. Bir de takvimi karşılaştırın. Aynı işi çok daha kısa sürede vaat eden taraf ya kapsamı küçük anlamıştır ya da test aşamasını hiç hesaba katmamıştır. Alanya yazılım ekibimiz teklif ederken teslim takvimine test ve düzeltme haftalarını ayrı satır olarak yazıyor, çünkü o haftalar atlandığında iş bitmiş sayılmıyor.
Çalışma sırasında memnun kalmazsam ne oluyor?
Bu ihtimalin sözleşmede karşılığı olmalı. Aşamalı teslim en pratik koruma yöntemi: iş parçalara bölünür, her parça kabul edildikten sonra bir sonraki başlar. Böylece ilerleme görünür olur, ayrılma noktası da tanımlı kalır. Ayrılma durumunda o güne kadar üretilen kod, dokümantasyon ve erişimler teslim edilir. Yazılım projelerinde tarafların yollarını ayırması nadir ama mümkün; nadir diye yazılmaması, gerçekleştiğinde işi mahkemelik hale getiriyor. Bir kurumsal yazılım şirketi ile çalışmaya başlarken bu maddeyi konuşmak kötümserlik değil, ihtiyattır.