Proje Yaptırmak İstiyorum Diyene Rehber

Bu cümleyi çok duyuyoruz

"Bir proje yaptırmak istiyorum." Bu cümle bize haftada en az birkaç kez geliyor. Bazen bir startup fikri, bazen kurumsal bir iç araç, bazen de "şu uygulamaya benzer bir şey" talebi. Cümlenin kendisi masum ama arkasında genellikle belirsiz bir beklenti, tanımsız bir kapsam ve gerçekçi olmayan bir bütçe yatıyor.

Ben bu yazıyı satış yapmak için yazmıyorum. Tam tersi: bize gelen taleplerin önemli bir kısmını geri çeviriyoruz ya da "henüz hazır değilsiniz" diyoruz. Çünkü hazırlıksız başlanan bir proje hem parayı yakar hem ilişkiyi bozar. İki taraf için de.

Fikir ile proje arasındaki uçurum

"Uber ama X sektörü için" ya da "basit bir e-ticaret sitesi" gibi tanımlarla gelen çok oluyor. Sorun şu: basit diye bir şey yok. Her projenin authentication'ı var, ödeme entegrasyonu var, bildirim sistemi var, admin paneli var. "Basit" dediğiniz şeyin arkasında onlarca karar noktası duruyor.

Bir fikriniz varsa, onu projeye çevirmeden önce şu soruları cevaplamanız gerekiyor:

1. Kim kullanacak? "Herkes" geçerli bir cevap değil.
2. İlk versiyon ne yapmalı? Her şeyi değil, en kritik 3-5 özelliği belirleyin.
3. Başarıyı nasıl ölçeceksiniz? Kullanıcı sayısı mı, gelir mi, iç verimlilik mi?
4. Lansmandan sonra kim bakacak? Yazılım canlıya çıkınca bitmez, o zaman başlar.

Bu soruları cevaplayamıyorsanız, yazılım firmasına gitmeden önce bir iş analisti ya da ürün danışmanıyla çalışmanız daha doğru. Biz kod yazarız ama ürün keşfi farklı bir disiplin.

Bütçe konuşmasını neden herkes erteliyor

En garip dinamiklerden biri bu. Müşteri bütçesini söylemek istemiyor çünkü "yüksek fiyat verirlerse" diye düşünüyor. Biz de kapsam belli olmadan fiyat veremiyoruz. Sonuç: iki taraf da birbirini yokluyor, kimse net konuşmuyor.

Benim önerim şu: bütçe aralığınızı en baştan söyleyin. "50-80 bin TL arası düşünüyoruz" demek, bize kapsamı ona göre şekillendirme imkanı verir. 500 bin TL'lik bir hayal kuruyorsanız ama bütçeniz 50 bin TL'yse, bunu erken öğrenmek iki taraf için de zaman kazandırır.

Bir de şu var: ucuz yazılım diye bir şey yok, ertelenmiş maliyet var. Freelancer'a düşük bütçeyle yaptırdığınız projeyi 6 ay sonra sıfırdan yazdırma ihtimaliniz düşük değil. Bunu çok gördük.

Kapsam belirsizliği projeleri öldürür

"Detayları geliştirirken konuşuruz" cümlesi tehlike işareti. Yazılım geliştirme sürecinde en büyük maliyet kalemi değişen gereksinimler. Bir ekranı yapıp bitirdikten sonra "aslında burası şöyle olsun" demek, o ekranı sıfırdan yazmak anlamına gelebilir.

Bu, değişiklik yapılmasın demek değil. Agile zaten bunu yönetmek için var. Ama başlangıçta bir MVP kapsamı net olmalı. Neyin v1'de olacağı, neyin sonraya kalacağı yazılı olmalı. Sözlü anlaşmalar unutuluyor, herkesin kafasında farklı bir ürün canlanıyor.

Biz projelere başlamadan önce bir keşif aşaması (discovery phase) yapıyoruz. Bu genellikle 1-2 haftalık bir çalışma. Çıktısı: kullanıcı akışları, wireframe'ler, teknik mimari taslağı ve gerçekçi bir zaman-bütçe tahmini. Bu aşamayı atlayan projeler genellikle 3. ayda krize giriyor.

Teknik kararları kim veriyor

"React mı Vue mu?" ya da "Flutter mı native mi?" sorularını müşterinin sorması normal. Ama bu kararları müşterinin vermesi normal değil. Siz iş gereksinimlerini anlatın, teknoloji seçimini geliştirme ekibine bırakın.

Tabii burada da bir sorun var. Bazı firmalar her projeye aynı stack'i uyguluyor çünkü ekipleri sadece onu biliyor. Laravel gereken yere Next.js, mobil uygulama gereken yere responsive web site dayatılabiliyor. Doğru firma, teknolojiyi projeye göre seçer ve size neden o seçimi yaptığını açıklayabilir.

Bir uyarı daha: "en yeni teknoloji" her zaman en doğru teknoloji değil. Production'da kanıtlanmış, ekosistemi olgun, geliştirici bulması kolay teknolojiler genellikle daha güvenli bahis. Biz de yeni şeyler denemeyi severiz ama müşteri projesinde değil, kendi iç projelerimizde deneriz önce.

Süreç nasıl işlemeli

Sağlıklı bir yazılım projesi kabaca şöyle ilerler:

1. Keşif: Gereksinim analizi, wireframe, teknik planlama. 1-3 hafta.
2. MVP geliştirme: En kritik özelliklerin çalışır hali. Kapsama göre 2-4 ay.
3. Test ve düzeltme: QA süreci, kullanıcı testi, bug fix. 2-4 hafta.
4. Lansman: Deployment, monitoring kurulumu, ilk kullanıcı geri bildirimleri.
5. Bakım ve iterasyon: Burası süresiz. Yazılım yaşayan bir şey.

Bu süreçte müşteri tarafından en çok aksayan şey geri bildirim hızı. Biz bir şey teslim ediyoruz, onay ya da düzeltme talebi 2 hafta sonra geliyor. Bu, projenin süresini ve maliyetini doğrudan şişirir. Haftada en az bir review toplantısına katılmayı planlayın.

Firma seçerken neye bakmalı

Portfolyo önemli ama yetersiz. Güzel görünen bir site yapmak kolay, arkasındaki kodu sürdürülebilir yazmak zor. Şunları sorun:

1. Daha önce benzer kapsamda proje yaptınız mı? Referans verebilir misiniz?
2. Proje ortasında kapsam değişirse süreci nasıl yönetiyorsunuz?
3. Kod tesliminde ne veriyorsunuz? Repo erişimi, dokümantasyon, deployment scriptleri?
4. Proje bittikten sonra bakım modeli nasıl işliyor?
5. Ekipte kimler çalışacak ve o kişiler projeye ne kadar ayrılacak?

Bir de şunu bilin: çok düşük fiyat veren firma ya junior ekiple çalışıyor ya da kapsamı düşük anlıyor. İkisi de sizin için risk.

Sözleşme ve fikri mülkiyet

Şaşırtıcı sayıda proje sözleşme olmadan ya da çok belirsiz sözleşmelerle başlıyor. En azından şunlar yazılı olmalı:

1. Kaynak kod kime ait? (Cevap: ödemeyi yapan tarafa ait olmalı.)
2. Ödeme planı nasıl? (Milestone bazlı ödeme, iki tarafı da korur.)
3. Gecikme durumunda ne olur?
4. Kapsam dışı istekler nasıl fiyatlanır?

Kod sahipliği konusu özellikle kritik. Bazı firmalar kodu teslim etmiyor ya da proprietary framework kullanıyor. Bu sizi o firmaya bağımlı kılar. Projenin tüm kaynak kodu, veritabanı şeması ve deployment konfigürasyonu size ait olmalı.

Peki ne yapmalı

Eğer gerçekten bir proje yaptırmak istiyorsanız, firmaya gitmeden önce şunu hazırlayın: bir sayfalık bir brief. Kim kullanacak, ne yapacak, başarı kriteri ne, bütçe aralığı ne. Mükemmel olması gerekmiyor, ama "kafamda bir fikir var, siz şekillendirin" demekten çok daha iyi bir başlangıç noktası.

Eğer brief yazmakta zorlanıyorsanız, bu fikrinizin kötü olduğu anlamına gelmiyor. Sadece henüz proje aşamasına gelmediği anlamına geliyor. Önce bir iş modeli çalışması yapın, potansiyel kullanıcılarla konuşun, rakip analizi yapın. Sonra gelin, çok daha verimli bir süreç olur.