İletişim

Bir sonraki projenizi konuşalım

Aklınızdaki yazılım projesini birlikte değerlendirelim. 1 iş günü içinde dönüş yapıyoruz.

Proje talebi

Projenizi anlatın, size ulaşalım

Formu doldurun; seçtiğiniz kanaldan 1 iş günü içinde dönüş yapalım. Bilgileriniz yalnızca bu görüşme için kullanılır ve KVKK kapsamında korunur.

Görüşme planla

Ücretsiz 30 dakikalık keşif görüşmesi

Google Calendar üzerinden müsait bir zaman seç, kurucumuzla doğrudan görüş.

Randevu Al

Kariyer başvuruları: Staj ve iş başvuruları yalnızca career@donedynamics.com adresine yapılmalıdır. Diğer adreslere gönderilen başvurular değerlendirmeye alınmayacaktır.

Telefon

+90 538 691 22 83

Pzt – Cum · 09:00 – 18:00 (TRT)

Doğrudan kurucu

devrim@donedynamics.com

Stratejik iş birlikleri için.

Ofisler

  • İstanbul

    Yeşilkent, Avcılar, İstanbul, Türkiye

  • Alanya

    Alanya, Antalya, Türkiye

Bir e-posta uzaktayız.

Yazılım projeniz için doğrudan ulaşın. 1 iş günü içinde dönüş yapıyoruz.

Teklif isterken hangi bilgiyi vermek işi hızlandırır?

Teklif isterken hangi bilgiyi vermek işi hızlandırır?

Bir projeyi anlatmaya nereden başlamalı? Çoğu görüşme aynı cümleyle açılır: "Bize bir fiyat verebilir misiniz?" Verilebilir. Verilen rakamın işe yaraması ise karşı tarafın neyi ölçtüğünü bilmesine bağlıdır. Sağlıklı bir yazılım teklifi üç şeyi aynı anda söyler: ne yapılacak, ne kadar sürecek, hangi varsayımlar geçerli. Üçünden biri eksikse elinizde teklif değil, tahmin durur.

Done Dynamics'te teklif hazırlamak tarife okumaya benzemiyor. Merkez ofis Alanya'da, ikinci ofis İstanbul'da. Bir kurumsal yazılım şirketi olarak aynı hafta içinde bir otelin rezervasyon entegrasyonunu, bir üretim tesisinin stok akışını ve bir e-ticaret markasının arama görünürlüğünü konuşabiliyoruz; hiçbiri tek cümlelik bir brief'ten çıkmadı. Talebin hangi ekibe düşeceği genelde ilk mesajın üçüncü satırında belli oluyor.

Aşağıda dört başlık var: teklif isterken hangi bilginin süreci kısalttığı, takvimin nasıl yürüdüğü, hangi kanaldan gelmenin ne zaman doğru olduğu ve teklifin neye göre şekillendiği. Rakam yazmıyoruz. Kapsamı görmeden verilen rakam ne bizi bağlar ne sizi korur.

Brief'in altı sütunu: durum, hedef, takvim, bütçe, karar, entegrasyon

İlk sütun mevcut durum. İş şu an nasıl yürüyor — Excel'le mi, hazır bir paketle mi, kâğıtla mı, yoksa hiç mi yürümüyor? Bu soruya verilen cevap teklifin yarısını yazar, çünkü sıfırdan kurulacak bir sistemle yıllardır kullanılan bir yapının yerine geçecek sistem birbirine hiç benzemez. İkincisinde veri var, alışkanlık var, kırılmaması gereken bir günlük ritim var. Mevcut ekranların birkaç fotoğrafı, tek başına bir sayfa açıklamadan daha çok şey anlatır.

İkinci sütun hedef. "Site istiyoruz" bir hedef değildir; "bayilerimiz siparişi telefondan girsin, muhasebe aynı akıştan faturayı kessin" hedeftir. Aradaki fark sayfa sayısıyla değil, ölçülebilir çıktıyla ilgili. Hedefi cümleye dökemiyorsanız keşif görüşmesinin ilk yarısı zaten bunu yapmakla geçer — sıkıntı değil, ama takvime yazılması gerekir. Kimin işini kolaylaştıracağını söylemek de çoğu zaman hedefi netleştirir: sahadaki ekip mi, muhasebe mi, müşteri mi?

Üçüncü sütun zaman kısıtı. Bir tarih varsa söyleyin. Sezon açılışı, fuar, denetim, sözleşme bitişi, bir entegrasyon zorunluluğu. Tarih kapsamı belirler, tersi değil. Otuz günde teslim edilmesi gereken bir işte doğru soru "her şey yetişir mi" değil, "hangi parça birinci sürümde olmalı" sorusudur. Antalya yazılım taleplerinin ciddi bir bölümü şubat ve mart aylarında geliyor; sebebi tek, sezon mayısta açılıyor ve nisanda başlayan iş yetişmiyor.

Dördüncü sütun bütçe aralığı. Aralık söylemek pazarlık gücünüzü düşürmez, sizi boş tekliften korur. Aynı ihtiyaç üç farklı bütçede üç farklı biçimde çözülebilir: hazır bir ürünü yapılandırarak, mevcut sisteme bir modül ekleyerek ya da sıfırdan yazarak. Aralığı bilmeyen taraf üçünden birini rastgele seçer ve genelde yanlış seçer. Rakam vermek istemiyorsanız üst sınırı söyleyin, o bile yeter.

Beşinci sütun kimin karar verdiği. Teklifi okuyacak kişi ile bütçeyi onaylayacak kişi farklıysa, teklif iki dilde birden yazılmak zorunda: teknik kısım biri için, gerekçe ve geri dönüş kısmı diğeri için. Bunu baştan bilmek belgeyi kısaltır ve toplantı sayısını düşürür. Ortaklı yapılarda tek bir muhatap belirlemek, süreci haftalarca kısaltan en ucuz karardır.

Altıncı sütun entegre olacak sistemler. Muhasebe programı hangisi, e-fatura entegratörü kim, kargo tarafında kaç firma var, ödeme altyapısı ne, kartlı geçiş ya da barkod donanımı devrede mi? Bu liste teklifin en oynak kalemidir. Belgelenmiş bir API'si olan sistemle, verisini yalnız ekrandan gösteren bir sistem arasındaki maliyet farkı kat kat olabiliyor. Adını bilmiyorsanız ekran görüntüsü gönderin; biz tanırız.

Eksik brief neden hem teklifi hem takvimi bozuyor

Eksik brief'in ilk zararı gecikme değil, yanlış varsayım. Bilgi olmayan yere varsayım kurulur; varsayım da fiyata risk payı olarak yazılır. Yani eksik anlatılan iş, iyi anlatılan işten pahalı çıkar. Bu bir ceza değil, matematik. İhtimalleri daraltamayan taraf en kötü ihtimale göre hesap yapmak zorunda kalır.

İkinci zarar revizyon zinciri. Teklif gider, "biz aslında şunu da düşünüyorduk" cevabı gelir, belge yeniden yazılır. Üç turdan sonra karşılaştırma yapılamaz hale gelir; çünkü ilk teklifle son teklif artık aynı işi tarif etmiyordur. Şirket içinde de kafa karışır: yönetim ilk rakamı hatırlar, ekip son kapsamı bekler. Aradaki boşluk projenin ortasında patlar.

Üçüncü zarar takvimde. Geliştirme başladıktan sonra ortaya çıkan entegrasyon, planı yalnız kendi süresi kadar uzatmaz; sırasını beklemeyen bir iş olarak araya girer ve önündeki her şeyi kaydırır. Veri taşıma tarafı bunun en klasik örneği. Eski sistemdeki kayıtların temizliği görülmeden verilen bir yazılım teklifi, ilk aktarım denemesinde bozulur. Mükerrer kayıtlar, boş alanlar, tutarsız tarih biçimleri — hepsi görünmez emek. Bir yazılım teklifi hazırlarken en çok zaman ayırdığımız yer de burasıdır: neyin taşınacağı, neyin arşivde bırakılacağı.

Dördüncü zarar karşılaştırmada. Üç ayrı firmadan alınan üç teklif, ancak aynı kapsamı tarif ediyorsa yan yana konabilir. Brief eksikse her firma boşluğu kendi varsayımıyla doldurur ve elinizde kıyaslanamayan üç belge kalır. En düşük rakamı veren taraf genelde en az şeyi yapmayı planlayandır. Aynı brief'i herkese aynı biçimde göndermek, bir yazılım teklifi turunda alınabilecek en ucuz önlem.

Keşiften teklife: süre neye göre değişiyor

Formdan gelen talebe seçtiğiniz kanaldan 1 iş günü içinde dönüş yapıyoruz. Bu dönüş teklifin kendisi değil, ilk temas. Amacı basit: doğru soruları sormak ve keşif görüşmesine ihtiyaç olup olmadığını anlamak. Bazı talepler yazışmayla netleşiyor. Çoğu netleşmiyor.

Keşif görüşmesi otuz dakika sürüyor ve ücretsiz. Takvimden müsait bir saat seçiyorsunuz, kurucuyla doğrudan konuşuyorsunuz. Otuz dakika kısa görünebilir; kapsamın sınırlarını çizmeye yeter. O yarım saatte üç şeyi anlamaya çalışıyoruz: işin bugünkü hâli, birinci sürümün sınırı ve kimin hangi kararı verdiği. Bunlar netleştiğinde teklifin iskeleti çıkmış olur.

Teklif hazırlama süresi kapsamla ölçeklenir. Tek kanallı, entegrasyonsuz bir iş için belge birkaç gün içinde çıkar. Birden fazla sistemin konuştuğu, veri taşıma içeren ve saha kullanımı olan işlerde süre uzar, çünkü arada teknik doğrulama vardır: entegratörün dokümanına bakılır, mevcut veritabanının yapısı sorulur, gerekiyorsa küçük bir deneme yapılır. Tahminle yazılmış bir yazılım teklifi hızlı gelir ve pahalıya patlar.

Görüşme dili de süreyi etkiliyor. Alanya yazılım ekibiyle aynı şehirdeyseniz genelde tek bir yerinde toplantı yetiyor; ekranlar açılıyor, süreç canlı izleniyor, ikinci tura gerek kalmıyor. Uzaktan yürüyen işlerde aynı netliğe ulaşmak için bir ekran paylaşımı daha gerekebiliyor. İstanbul yazılım tarafındaki taleplerde ise en sık darboğaz teknik değil takvimsel: doğru kişileri aynı saatte aynı toplantıya toplamak.

Karar süreci uzarsa teklife ne oluyor

Teklif bir fiyat etiketi değil, bir zaman dilimidir. İçinde kapsam, varsayımlar ve bir başlangıç penceresi vardır. Karar üç hafta içinde gelirse pencere durur. Üç ay sonra gelirse pencere kapanmıştır ve belgenin yeniden bakılması gerekir. Bunun sebebi fiyat artışı değil, sıradaki işlerin yerleşmiş olması.

Uzayan kararın ikinci etkisi kapsamda görünür. Üç ay içinde işletmenin ihtiyacı da değişir: bir şube açılır, bir tedarikçi değişir, mevzuat tarafında bir kalem eklenir. Eski kapsamla yeni ihtiyacı zorla eşleştirmek yerine belgeyi güncellemek daha ucuzdur. Kısa bir görüşme genelde yeterli oluyor; sıfırdan başlamıyoruz.

Üçüncü etki sıradadır. Ekip kapasitesi sınırlı ve takvim gerçek. Onaylanan işler sıraya girer, sıra da ilk gelen ilk girer mantığıyla değil, hazırlık durumuna göre işler: kapsamı net, verisi hazır, muhatabı belli olan iş erken başlar. Yoğun dönemler de belli. Sezon öncesi ilkbahar, yıl sonu kapanışları ve mevzuat değişikliklerinin yürürlüğe girdiği aylar. O pencerelerde başlamak isteyen işletmenin bir ay önceden konuşmaya başlaması gerekiyor. Bir kurumsal yazılım şirketi için dürüst olan tavır bu: yetişmeyecek takvime evet dememek.

Kararı erteleten görünmez bir sebep daha var: iç mutabakatın tamamlanmamış olması. Teklif dışarıdan bekleniyor gibi görünür, oysa asıl bekleyen içeridedir. Muhasebe bir şey ister, saha başka bir şey. İstanbul yazılım taleplerinde bu tıkanmayı en sık çok ortaklı yapılarda görüyoruz. Çaresi basit: teklifi iki senaryoya bölmek. Her iki tarafın da kendi satırını görmesi, tartışmayı fiyattan kapsama taşıyor ve karar birden hızlanıyor.

Telefon, e-posta, form, yerinde görüşme: hangisi ne zaman

Telefon acil ve operasyonel işler için. Sistem durmuşsa, bir ödeme akışı kesilmişse ya da yayına alınmış bir sayfada yanlış bilgi görünüyorsa yazışma vakit kaybıdır. Arayın. Aynı şekilde, mevcut bir işin küçük bir detayını netleştirmek için de telefon en kısa yol; üç cümlelik bir soru için e-posta zinciri açmanın kimseye faydası yok.

E-posta dokümanlı ve kapsamlı işler için. Şartname, mevcut sistemin ekran görüntüleri, örnek veri dosyası, mevzuat metni, önceki tedarikçiden kalan teknik notlar — bunların hepsi ek olarak gidebilir ve arşivlenebilir. Yazılı iletişimin ikinci faydası kayıt: altı ay sonra "şunu konuşmuş muyduk" tartışması çıkmaz. Kurumsal alım süreçlerinde satın alma birimi de zaten yazılı iz ister.

Form ilk temas için. Henüz şartname yoksa, kapsam kafanızda olgunlaşmamışsa ve öncelikle karşı tarafın bu işi yapıp yapmadığını anlamak istiyorsanız en hızlısı budur. İki dakikada dolar. Bir yazılım teklifi yolculuğunun çoğu buradan başlıyor, çünkü hiç kimse ilk adımda yirmi sayfalık bir belge hazırlamak istemiyor.

Yerinde görüşme kapsamı büyük işler için. Üretim hattının nasıl aktığını, depodaki barkod okuyucunun nereye bağlı olduğunu ya da otelin resepsiyonunda hangi ekranın kaç kez açıldığını anlatmak zordur; görmek kolaydır. Alanya yazılım merkezimizden çıkıp Alanya ve Antalya çevresinde yerinde görüşmeye geliyoruz. Antalya yazılım ve otelcilik taleplerinde bu ziyaret genelde bir tur hâline dönüşüyor: ön büro, muhasebe, teknik servis. Üç durakta çıkan notlar, üç toplantıdan fazlasını anlatıyor.

Formda ne soruyoruz, cevaplar nereye gidiyor

Form kısa tutuldu. Ad ve soyad, size hangi kanaldan ulaşmamızı istediğiniz — telefon, e-posta ya da Telegram —, telefon numarası ve projeyi anlattığınız bir açıklama alanı. Hepsi bu. Uzun bir anket doldurmanızı istemiyoruz, çünkü doğru soruların ne olduğu talebe göre değişiyor ve o soruları görüşmede sormak daha verimli.

Açıklama alanı formun en değerli kısmı. Oraya yazılan üç cümle ile üç paragraf arasındaki fark, ilk dönüşün kalitesini doğrudan belirliyor. En işe yarar hâli şu: ne yapıldığı, neyin çalışmadığı ve ne zamana kadar olması gerektiği. Ekran görüntüsü ya da doküman göndermek isterseniz form yerine e-posta daha uygun.

Kanal seçimi görünürde küçük bir detay, pratikte değil. Telegram'ı seçen işletmelerin çoğu hızlı yazışmayı tercih ediyor; e-postayı seçenler kurumsal süreçten geçiyor; telefonu seçenler genelde acele ediyor. Seçtiğiniz kanal, dönüş yaparken hangi tonu kullanacağımızı da belirliyor. İstanbul yazılım taleplerinde e-posta ağır basıyor, sahil hattındaki işletmelerde telefon.

Bilgilerin nereye gittiği konusunda net olalım. Formdan gelen bilgiler yalnızca bu görüşme için kullanılıyor ve KVKK kapsamında korunuyor. Pazarlama listesine eklenmiyorsunuz, üçüncü taraflara aktarılmıyor. Anlattığınız iş fikri de aynı şekilde: teklif hazırlamak için okunuyor, başka bir yerde konuşulmuyor. Bu, sözleşmeye gerek duyulmadan uyulan bir kural — talep ederseniz yazılı hâle de getiriyoruz.

Gelen her talep kayda giriyor ve tek bir yerden takip ediliyor. Kaybolan mesaj olmuyor. Yoğun haftalarda sıra değişebiliyor; duran bir sistemi bildiren talepler öne alınıyor. Alanya yazılım ekibi sabah gelen kutusunu açtığında önceliği arıza kayıtları alıyor, teklif talepleri onun hemen arkasından geliyor. Bu sıralama kimseyi bekletmek için değil: çalışan bir işletmenin durması, henüz başlamamış bir projeden daha acildir.

Teklifin şeklini belirleyen beş değişken

Birincisi kapsam. Kaç ekran, kaç kullanıcı rolü, kaç farklı iş akışı? Bir sipariş formu ile onaydan geçen, stoktan düşen ve faturaya bağlanan bir sipariş akışı aynı kelimeyle anılır, aynı işi tarif etmez. Kapsam büyüdükçe maliyet doğrusal artmaz; roller ve durumlar çarpım etkisi yaratır.

İkincisi entegrasyon sayısı. Her dış sistem ayrı bir sözleşme gibi davranır: kendi kimlik doğrulaması, kendi hata kodları, kendi bakım penceresi. İkiden fazla entegrasyonu olan işlerde test yükü geliştirme yükünü geçebiliyor. Bir yazılım teklifi okurken entegrasyon kaleminin ayrı yazılıp yazılmadığına bakın; toplu yazıldıysa içeride belirsizlik var demektir.

Üçüncüsü veri taşıma. Kaç yıllık kayıt var, hangi formatta duruyor, temizlenmesi gerekiyor mu? Veri taşımanın zor tarafı kopyalamak değil, eşleştirmek. Eski sistemde tek alanda duran adres bilgisinin yeni sistemde dört alana bölünmesi gerekiyorsa, o işin adı geliştirme değil arkeoloji.

Dördüncüsü özel geliştirme oranı. Hazır bileşenlerle çözülebilen kısım ile sıfırdan yazılması gereken kısım arasındaki denge teklifi doğrudan biçimlendirir. Kendi geliştirdiğimiz ürünlerin bir kısmı bu yüzden var: aynı ihtiyacın beşinci kez sıfırdan yazılmasının kimseye faydası yok. Standart olan yerde standardı kullanıp, işletmeye özgü olan yere emek ayırmak daha akıllıca.

Beşincisi bakım seviyesi. Yayına almak işin sonu değil. Güncelleme ritmi, izleme, yedek doğrulama, mevzuat değişikliklerine uyum ve destek süresi — hepsi ayrı satırlar. Bakım kalemi olmayan bir yazılım teklifi ucuz görünür, ilk yılın sonunda pahalıya gelir. Sistemin kime emanet edileceği baştan belli olmalı.

Beş değişkenin ortak özelliği şu: hiçbiri sayfa sayısıyla ölçülmüyor. Bir yazılım teklifi okurken bakılacak asıl yer, toplam tutarın altındaki varsayımlar listesidir. Orada "mevcut verinin temiz olduğu varsayılmıştır" gibi bir cümle duruyorsa, o cümle sizin riskiniz demektir. Varsayımları sorun. İyi hazırlanmış bir belge zaten onları saklamaz, satır satır yazar.

Fiyat kırma pazarlığı neden kapsam kırpmaya dönüşüyor

Bir teklifte indirim istendiğinde iki şey olabilir. Ya kâr marjı düşer ya da kapsam daralır. Marj bir yere kadar esner; ötesinde işin süresi kısalır, süre kısaldığında ise kesilen şey test, dokümantasyon ve devreye alma desteği olur. Kesilen kalemler görünmez, bu yüzden kesildikleri anda kimse itiraz etmez. Fatura ikinci ayda gelir.

Sahada gördüğümüz en yaygın hasar şu: yüzde yirmi indirim için kapsamdan çıkarılan "detay" işler, altı ay sonra ayrı bir proje olarak geri dönüyor ve toplamda daha pahalıya mal oluyor. Yeniden başlatmanın kendi maliyeti var — hatırlama, yeniden test, yeniden devreye alma. Bir yazılım teklifi üzerinde pazarlık yapılacaksa doğru soru "ne kadar indirim" değil, "hangi parça ikinci sürüme kalabilir" sorusu.

İkinci sağlıklı yol aşamalandırma. Birinci sürümde işi ayakta tutan çekirdek, ikinci sürümde konforu artıran kalemler. Bu, hem nakit akışını rahatlatır hem de en riskli varsayımları erken test eder. Kullanıcının gerçekten hangi ekranı açtığını, kâğıt üzerindeki plandan değil ilk aydan öğrenirsiniz.

Somut bir örnek: sezonluk çalışan bir işletmede bütçe baskısı mart ayında zirve yapar ve teklifin en kolay kırpılan kalemi eğitim olur. Nisanda sistem devreye alınır, mayısta yeni personel gelir, kimse ekranı tanımaz. Antalya yazılım ve otel projelerinde tekrar tekrar gördüğümüz döngü budur. Eğitim satırını korumak, ilk sezonda kaybedilen saatlerin yanında ucuz kalıyor. Kırpılacaksa başka bir yerden kırpılmalı.

Üçüncüsü şeffaflık. Teklifin içindeki kalemlerin ayrı ayrı yazılması, hem karşılaştırmayı mümkün kılar hem de pazarlığı kapsam üzerinden yapılabilir hâle getirir. Toplam tutarı tek satırda gösteren belge kolay okunur, zor tartışılır. Bir kurumsal yazılım şirketi ile çalışırken beklemeniz gereken asgari şey, neye ne ödediğinizin görünür olması. Biz de aynısını sizden bekliyoruz: neyin gerçekten gerekli olduğunu söyleyin, gerisini birlikte kırpalım.

Sıkça sorulan sorular

Teklif almak için hazır bir şartname hazırlamam gerekiyor mu?
Hayır. Şartname varsa işi hızlandırır, yoksa birlikte çıkarırız. Aslında elde hazır şartname olan işlerin bir kısmında ilk yaptığımız şey o belgeyi sadeleştirmek oluyor; çünkü uzun şartnameler çoğu zaman ihtiyacı değil, daha önce bakılmış bir ürünün özellik listesini tarif ediyor. Bir yazılım teklifi için gereken asgari bilgi üç cümleyle anlatılabilir: bugün ne yapıyorsunuz, ne olmasını istiyorsunuz, ne zamana kadar. Gerisini sorularla tamamlıyoruz.
Dönüş ne kadar sürede geliyor?
Formdan gelen talebe seçtiğiniz kanaldan 1 iş günü içinde dönüyoruz. Bu ilk dönüş bir fiyat değil; ya birkaç netleştirici soru ya da doğrudan bir görüşme önerisi. Teklifin kendisi kapsama göre birkaç gün ile birkaç hafta arasında değişiyor. Süreyi uzatan şey neredeyse hiçbir zaman yazma işi olmuyor, doğrulama oluyor: entegre olunacak sistemin gerçekten ne verdiğini görmeden belge yazmıyoruz.
Alanya dışındaysak yerinde görüşme mümkün mü?
Alanya ve Antalya çevresinde yerinde görüşmeye geliyoruz. Merkez ofis Alanya'da, ikinci ofis İstanbul'da olduğu için bu iki hatta hareket rahat. Antalya yazılım ve turizm işletmelerinde ziyaret genelde tek seferde bitiyor. Türkiye'nin başka bir şehrindeyseniz süreç uzaktan yürüyor; ekran paylaşımı ve video görüşmesi çoğu iş için yeterli. Kapsam büyükse ve fiziksel süreç görülmeden anlaşılmıyorsa, seyahat planlanabiliyor — bunu baştan konuşuyoruz. İstanbul yazılım tarafındaki taleplerde ofis üzerinden yüz yüze görüşme zaten mümkün.
Anlattığım fikir gizli kalıyor mu?
Evet. Formdan ve görüşmeden çıkan bilgiler yalnızca o görüşme için kullanılıyor, KVKK kapsamında korunuyor ve başka bir yerde konuşulmuyor. Gizlilik sözleşmesi imzalamak isterseniz teklif öncesinde imzalıyoruz; talep etmezseniz de aynı kurala uyuyoruz. Rakip bir işletmeye aynı fikri taşımak kısa vadede bir iş kazandırabilir, uzun vadede itibar kaybettirir. Bu hesabı yapmayan bir kurumsal yazılım şirketi zaten uzun süre ayakta kalamıyor.
Teklif ne kadar süre geçerli?
Belgenin üzerinde bir geçerlilik penceresi yazıyor ve o pencere fiyattan çok takvimle ilgili. Süre dolduğunda teklif otomatik olarak çöpe gitmiyor; kapsam ve başlangıç tarihi yeniden konuşuluyor. Çoğu durumda güncelleme kısa sürüyor. Aradan uzun zaman geçtiyse ve işletmede yapısal bir değişiklik olduysa keşif kısmını tazelemek gerekebiliyor. Alanya yazılım ekibimizin gündemi sezona göre değiştiği için, başlangıç penceresini net konuşmak iki taraf için de rahatlatıcı oluyor.
Küçük bir iş için de teklif veriyor musunuz?
Veriyoruz. Tek sayfalık bir düzeltme de, çok kullanıcılı bir sistem de aynı formdan geliyor. Küçük işlerde teklif süreci doğal olarak kısalıyor — bazen tek bir yazışma yetiyor. Bakılan şey işin büyüklüğü değil, sürekliliği: bir defalık bir düzeltme mi, yoksa arkasından bakım ve geliştirme gelecek bir iş mi? İkisinin de yeri var. Bir yazılım teklifi hazırlarken sorduğumuz son soru genelde şu oluyor: bu işi bir yıl sonra kim ayakta tutacak? Cevap belirsizse, teklife bakım kalemi de ekliyoruz.