Ajans seçerken herkesin baktığı yer aşağı yukarı aynı: portfolyo, fiyat, teslim süresi. Üçü de önemli ama üçü de projenin sadece ilk ayını anlatır. Asıl fark, teslimden sonraki on iki ayda ortaya çıkar. Ve o farkı belirleyen şeylerden biri, ajansın hiç kendi ürününü yapıp yapmadığıdır.
Kulağa teknik bir ayrıntı gibi geliyor. Değil. Kendi ürününü yapan ekip, yazdığı kodun faturasını kendisi ödediği için başka türlü düşünmeye mecbur kalır. Bir müşteri işinde yanlış kurduğunuz bir yapıyı teslim edip unutabilirsiniz; kendi ürününüzde o yapı her sabah karşınıza çıkar.
Bu yazıda o düşünme biçiminin müşteri tarafına nasıl yansıdığını, somut başlıklarla anlatmak istiyorum. Amaç "biz şöyleyiz" demek değil; bir ajansla görüşürken neye bakacağınızı biraz daha netleştirmek.
"Kendi ürünü" ne demek, ne değil
Önce sınırı çizelim. Bir ajansın kendi ürünü olması, kurumsal sitesinin güzel olması demek değil. Hazır şablon satmak da değil. Bir kere yapılıp rafa kaldırılmış, kullanıcısı olmayan bir demo da değil.
Kastettiğim şey şu: ekibin, müşterisi olmayan, parasını kendi cebinden verdiği, kullanıcısı gerçek insanlar olan ve bakımını yıllarca kendi üstlendiği bir yazılımı olması. Sunucu faturası ekibe gelen, hata bildirimi ekibin telefonuna düşen, kullanıcı şikâyetini doğrudan ekibin okuduğu bir yazılım.
Aradaki fark şurada: müşteri projesinde kötü bir karar aldığınızda bedelini genelde başkası öder. Kendi ürününüzde aldığınız kötü kararın faturası altı ay sonra sizin önünüze gelir. Sunucu maliyeti olarak, destek yükü olarak, "bu ekranı baştan yazmamız lazım" olarak gelir. İnsan bir kez bu faturayı ödedikten sonra aynı kararı bir daha kolay kolay almıyor.
Bu, ürünü olmayan her ekibin kötü iş yaptığı anlamına gelmez elbette. Sadece bazı derslerin kısa yoldan öğrenilemediğini, yaşanarak öğrenildiğini söylüyorum.
Fark 1: Yayına almak bitiş değil, başlangıç sayılır
Proje odaklı çalışan bir yapıda teslim tarihi bir finaldir. Dosyalar aktarılır, fatura kesilir, ekip sıradaki işe geçer. Ürün geliştiren bir ekipte ise yayına alma günü, işin en heyecanlı ama aynı zamanda en zahmetli bölümünün başladığı gündür. Çünkü asıl sorunlar o gün çıkmaya başlar.
Bu alışkanlık müşteri projelerine de sirayet ediyor. Sitenin canlıya alındığı hafta, "acaba neyi gözden kaçırdık" sorusu refleks haline geliyor. Formdan mail gidiyor mu, mobilde menü garip davranıyor mu, arama motoru sayfaları doğru tarıyor mu, eski adresler yeni sayfalara yönleniyor mu — bunlar teslim listesinde yazdığı için değil, daha önce kendi ürününde bu sorunlarla uğraşıldığı için kontrol ediliyor.
Bir de şu var: bakımı kendi üstüne alan ekip, bakımı kolay olacak şekilde kurar. Paketlerimizde barındırma, alan adı ve güncellemenin dahil olmasının arkasında da aslında bu mantık var. Siteyi biz işletmeye devam edeceksek, bizi geceleri uyandıracak şekilde kurmayız.
Fark 2: Teknik borcun sahibi olmak insanı sadeleştirir
Yazılımda "teknik borç" diye bir kavram var: bugün hızlı ilerlemek için aldığınız kestirme kararların, yarın faiziyle geri gelmesi. Her projede bir miktar olur, normaldir. Sorun, borcun kime kaldığıdır.
Kendi ürününü işleten ekip bu borcu kendi taşıdığı için gereksiz karmaşıklığa doğal bir alerji geliştirir. Beş eklenti yerine tek bir temiz çözüm, on ayarlı bir panel yerine üç ayarlı ama anlaşılır bir panel tercih edilir. Çünkü o paneli iki yıl sonra yine siz açacaksınız ve o gün ne düşündüğünüzü hatırlamayacaksınız.
Sadelik müşteri tarafında neye benziyor
Müşteri tarafındaki karşılığı şu oluyor: site daha az şey yapıyor gibi görünebilir ama yaptığı şeyleri yıllarca sorunsuz yapıyor. Sayfa açılış hızı, güncelleme sonrası bozulmama, sunucu taşırken sorun çıkmama gibi başlıklar bu sadeliğin sonucudur.
Çok eklenti yüklü bir sitede her güncelleme küçük bir kumardır; bileşenlerden biri uyumsuz çıkar, sayfa bozulur, kimse nereden başlayacağını bilemez. Az parçadan kurulmuş bir sitede ise bir şey bozulduğunda arayacağınız yer bellidir. Bu, estetikten feragat etmek değil; görünmeyen tarafı kalabalıklaştırmamak.
Fark 3: Kullanıcıyı varsaymak yerine izlemek
Ajans işinde en tehlikeli cümle şudur: "Kullanıcı burada şunu yapar." Genelde yapmaz. Kendi ürününde binlerce kullanıcının davranışını izlemiş bir ekip bunu acı yoldan öğrenir.
Mesela şunlar, ürün tarafında defalarca görülmüş şeylerdir:
- İnsanlar menüyü okumaz, önce arama kutusunu arar.
- Üç adımlı formun üçüncü adımında ciddi bir kayıp olur; iki adıma indirince kayıp azalır.
- Telefonda "hemen ara" butonu, en güzel tasarlanmış iletişim sayfasından daha çok iş yapar.
- Kullanıcı bir işlemin sonucunu görmezse, aynı butona üç kez basar.
- Fiyat bilgisi olmayan sayfada geçirilen süre kısadır; insanlar cevabı bulamayınca çıkar.
- Uzun açıklama metnini kimse baştan sona okumaz; başlıklar ve ilk cümleler okunur.
Bunlar araştırma raporundan değil, kendi kullanıcı tabanınızı izlemekten gelen bilgiler. Biz de bu tarafı kendi geliştirdiğimiz projelerde epey deneyimledik. Amatör Arena'da halı saha maçı organize etmeye çalışan bir kullanıcının sabırsızlığı ile, bir işletme sitesinde teklif arayan kullanıcının sabırsızlığı aslında aynı cinsten. İkisi de cevabı üç saniyede istiyor.
Bu bilgi tasarıma nasıl dönüşür
Çok basit bir şekilde: bir sayfayı tasarlarken "güzel duruyor mu" sorusunun yanına "bu sayfaya gelen insan ne arıyor ve kaç saniyede buluyor" sorusu ekleniyor. Estetik kaybolmuyor ama tek kriter olmaktan çıkıyor.
Bir kurumsal sitede ana sayfanın üst bölümünde ne yazacağına karar verirken, animasyonlu bir slogandan çok "ne iş yapıyorsunuz, nerede hizmet veriyorsunuz, nasıl ulaşılır" üçlüsünün net olması tercih ediliyor. Hareketli bir açılış bölümü ilk ziyarette etkileyici olabilir; ama aynı ziyaretçi ikinci gelişinde sadece telefon numarasını arıyordur.
Fark 4: Fiyatlama tahmin değil, deneyim üzerine kurulur
Sektörde sıkça görülen bir durum var: düşük bir rakamla başlayan proje, yolda eklenen kalemlerle ikiye katlanıyor. Bunun bir kısmı kötü niyetten değil, ekibin işin gerçek maliyetini bilmemesinden kaynaklanıyor. Bir özelliğin yapımı iki gün sürer ama bakımı iki yıl sürer; bakımı hiç üstlenmemiş biri bu ikinci kısmı fiyatlamaya koyamaz.
Kendi ürününü işleten ekip, bir özelliğin ömür boyu maliyetini aşağı yukarı bilir. Sunucu yükünü, destek yükünü, güncelleme zahmetini tahmin edebilir. Bu yüzden baştan daha gerçekçi bir rakam söyleyebilir ve o rakamın arkasında durabilir.
Biz de bu yüzden kapsamı netleştirip sabit fiyat veriyoruz; yolda ortaya çıkan sürpriz kalemlerle müşteriye dönmek, aslında bizim ilk hesabımızı yanlış yaptığımızın itirafı olur. Kapsam dışında yeni bir istek gelirse bu ayrıca konuşulur, ama konuşulan şeyin kapsam dışı olduğu baştan bellidir.
Fark 5: Panel, müşteriye teslim edilen bir araçtır
Çok sık karşılaşılan bir tablo: site güzel, panel korkunç. İşletme sahibi bir haber eklemek için ajansı aramak zorunda kalıyor, aramaktan sıkılınca siteyi güncellemeyi bırakıyor, iki yıl sonra site ölü bir vitrine dönüşüyor. Üstelik kimse kötü niyetli davranmamıştır; sadece panel, onu kullanacak kişi düşünülerek kurulmamıştır.
Kendi ürününü yöneten ekip bu konuda hassastır, çünkü kendi panelini her gün kullanır. Kullanışsız bir yönetim ekranının günde kaç dakika yediğini bilir. O yüzden müşteri paneli de "nasılsa biz hallederiz" mantığıyla değil, "bunu işletme sahibi tek başına kullanacak" mantığıyla kurulur: alan adları Türkçe, zorunlu alanlar belli, yanlış doldurulduğunda ne olacağı anlaşılır.
Teslimde yaptığımız panel eğitiminin amacı da bu: site, bizim onayımıza ihtiyaç duymadan yaşayabilmeli. Bir işletmenin kendi içeriğini kendi güncelleyebilmesi, uzun vadede tasarımdan daha değerli bir kazanç.
Mobil tarafta işler biraz daha netleşiyor
Web'de kötü bir karar genelde telafi edilebilir. Bir dosyayı değiştirir, yayına alır, yarım saatte düzeltirsiniz. Mobil uygulamada telafi daha zordur, çünkü araya mağaza onay süreçleri girer, kullanıcıların bir kısmı eski sürümde kalır, hata düzeltmesi günler alır.
Bir ekibin kendi mobil uygulamasını mağazada yayınlamış, sürüm geçmiş, kullanıcı yorumlarını okumuş olması burada doğrudan işe yarıyor. Mağaza reddi nasıl aşılır, izin ekranları nasıl yazılır, bildirim yorgunluğu nasıl önlenir, güncelleme çıkmayan kullanıcıya ne gösterilir — bunlar dokümandan değil, yaşayarak öğrenilen şeyler.
Flutter ile tek kod tabanı üzerinden çalışmayı tercih etmemizin sebebi de burada: iki ayrı platformu iki ayrı ekiple sürdürmenin bakım maliyetini kendi ürünümüzde gördük. Tek kod tabanı sihirli bir çözüm değil, ama küçük ve orta ölçekli projelerde güncelleme yükünü gerçekten yarıya yakın azaltıyor.
Peki bu her zaman avantaj mı
Dürüst olalım: ürün geliştiren bir ekibin dikkati bölünebilir. Kendi ürününe fazla dalmış bir ajans, müşteri işine geç dönebilir. Bu riski bilmek lazım.
Bu yüzden ürün sahibi olmak tek başına yeterli bir ölçüt değil. Yanında şunlara bakmak gerekiyor: dönüş süresi ne kadar, kim muhatabınız, iş teslim edildikten sonra kime ulaşacaksınız. Biz gelen mesajlara aynı iş günü içinde dönmeyi kural haline getirdik; çünkü bir ekibin ne kadar hızlı cevap verdiği, ne kadar iyi kod yazdığından önce hissedilen bir şey.
Çalışacağınız ekibi nasıl tartarsınız
Ajans görüşmesinde sorabileceğiniz, portfolyodan daha çok şey anlatan birkaç soru:
- Kendi geliştirdiğiniz, müşteri işi olmayan bir ürününüz var mı? Kaç yıldır ayakta?
- Yaptığınız sitelerden en eskisi hangisi ve hâlâ çalışıyor mu?
- Teslimden sonra bir hata çıkarsa süreç nasıl işliyor, ücretlendiriliyor mu?
- Barındırma ve alan adı kimde kalıyor? Yarın ayrılmak istesem dosyalarımı alabilir miyim?
- İçeriği ben güncelleyebilecek miyim, yoksa her değişiklik için size mi döneceğim?
- Projede benim muhatabım kim olacak ve mesajlara ortalama ne kadar sürede dönüyorsunuz?
Bu soruların cevapları net değilse, teslim sonrası dönemde zorlanma ihtimaliniz yüksek demektir. Net cevap veren bir ekip, muhtemelen o süreci daha önce defalarca yaşamıştır. Cevapların "duruma göre değişir" ile başladığı her başlık, ileride pazarlık konusu olacak bir başlıktır.
Son söz
Kendi ürününü yapmak bir ajansı otomatik olarak iyi yapmaz. İyi yapan şey, o ürünün getirdiği sorumluluğun yarattığı alışkanlıklardır: sade kurmak, bakımı düşünerek karar vermek, kullanıcıyı varsaymak yerine izlemek, söylediği rakamın arkasında durmak.
Siz bir web sitesi ya da uygulama yaptırırken aslında bir dosya satın almıyorsunuz; önümüzdeki birkaç yıl boyunca sürdürülecek bir ilişkiye giriyorsunuz. O ilişkide karşı tarafın daha önce aynı yolu kendi parasıyla yürümüş olması, sandığınızdan daha çok şey değiştiriyor.
Manisa ve Ege genelinde çalıştığımız işlerde en sık duyduğumuz cümle şu: "Site yapıldı ama sonrasında kimseye ulaşamadık." Bu cümlenin tekrar kurulmaması için ne yapılabileceğini konuşmak isterseniz, iletişim sayfasından yazabilirsiniz; gelen mesajlara aynı iş günü içinde dönüyoruz.