Mobil Uygulama Teklif Brief Şablonu (Kurumsal)
Kurumsal bir mobil uygulama için teklif toplamak istiyorsanız, en çok zaman kaybettiren şey şudur:
“Herkes farklı anlıyor, teklifler kıyaslanamıyor.”
Benim önerim: Teklif istemeden önce 1 sayfalık net bir brief çıkarın. Böylece:
- Gelen tekliflerin kapsamı aynı olur,
- Süre / bütçe sapmaları azalır,
- “Sonradan çıkar” kalemler en baştan konuşulur.
Aşağıdaki mobil uygulama teklif brief şablonu, kurumsal projeler için pratik bir başlangıçtır. İsterseniz direkt kopyalayıp doldurun.
1) Projenin Özeti (1 paragraf)
- Proje adı:
- Amaç (neden yapıyoruz?):
- Başarı kriteri (ne olursa “başardı” diyeceğiz?):
Örnek: “Saha satış ekibinin ziyaretlerini, fotoğraf + konum kanıtıyla raporlamak ve ERP’ye anlık aktarmak.”
2) Hedef Kullanıcılar ve Roller (RBAC)
-
Kullanıcı tipleri (rol listesi):
- Admin / Yönetici
- Saha personeli
- Bayi / müşteri temsilcisi
- Her rol ne yapacak? (kısa maddeler)
3) Platform ve Kapsam
- Platform: iOS / Android / Flutter
- Dil: TR / EN / çoklu dil?
- Tahmini kullanıcı sayısı:
- Bölge: Türkiye / global
4) Temel Özellikler (Must / Should / Nice)
Aşağıdaki gibi 3’e ayırın:
Must Have (Olmazsa olmaz)
- Login / SSO
- Rol bazlı yetkilendirme
- Listeleme / detay / form akışları
- Fotoğraf / dosya yükleme
- Konum alma + zaman damgası
- Offline çalışma (var/yok)
- Bildirim (push) (var/yok)
Should Have (Olursa iyi olur)
- Rota / görev yönetimi
- Harita
- Raporlama ekranları
- Yönetim paneli
Nice to Have (Sonraya kalabilir)
- AI destekli öneriler
- Otomatik etiketleme vb.
5) İş Akışları (2–5 ana senaryo)
Her biri 3–6 adım olacak şekilde yazın:
Senaryo 1: Saha ziyareti
- Check-in
- Fotoğraf çek
- Form doldur
- Check-out
- Rapor ERP’ye gitsin
6) Veri ve Entegrasyonlar
- Entegrasyon var mı? ERP / CRM / başka sistem:
- API var mı? (varsa dökümantasyon)
-
Veri akışı:
- Uygulamadan ERP’ye gidenler
- ERP’den uygulamaya gelenler
- Entegrasyon yöntemi: REST / SOAP / middleware / file transfer?
7) Offline Çalışma ve Senkronizasyon (Kurumsalda kritik)
- Offline gerekli mi? (Evet/Hayır)
- Offline iken hangi işlemler yapılacak?
-
Senkron ne zaman olacak?
- otomatik / manuel / wifi olunca
- Çakışma durumunda kural ne? (son yazan kazanır vb.)
8) Güvenlik / KVKK / Loglama
- KVKK açısından hassas veri var mı? (var/yok)
- Yetkilendirme: JWT / OAuth2 / SSO
- Loglar nerede tutulacak?
- Fotoğraf/konum gibi kanıt verisi için saklama süresi?
9) Performans ve SLA (bakım beklentisi)
- Çalışma saatleri: 7/24 mü?
-
SLA beklentisi:
- kritik hata müdahale süresi
- normal hata
- Bakım modeli: aylık bakım paketi / çağrı başı
10) Teslimatlar (tekliflerin kıyaslanması için şart)
- Kaynak kod teslimi (Git repo)
- Test ortamı / staging
- Dokümantasyon
- Yönetim paneli (var/yok)
- App Store / Google Play yayın desteği
11) Zaman Planı ve Milestone
- Hedef başlangıç:
- Hedef canlıya çıkış:
-
Tercih edilen yöntem:
- MVP → iterasyon
- Tek seferde final
12) Bütçe ve Teklif Formatı (bu bölüm teklif kalitesini uçurur)
Tedarikçiden şunu isteyin:
- Tahmini süre (hafta)
- Tahmini ekip: PM/BA, mobile dev, backend dev, QA
-
Kalem kalem fiyat kırılımı:
- analiz & tasarım
- geliştirme
- test
- yayın
- bakım
En sık yapılan 5 hata (ve nasıl önlersiniz)
- “10 ekran” deyip akışları yazmamak → senaryoları ekleyin
- Offline ihtiyacını belirsiz bırakmak → net karar verin
- Entegrasyon dokümanı olmadan teklif istemek → API dokümanı paylaşın
- Teslimat tanımı yok → kaynak kod, doküman, test ortamı yazın
- Bakım/SLA konuşulmuyor → en baştan bakım modelini belirtin
NOT: Bu şablon genel olarak tüm yazılım projelerinde, inhouse veya outsource geliştirilen projelerde, kurumsal olmayan projelerde de kullanılabilir. Kendi ihtiyacınıza göre düzenleyebilirsiniz ana hatlara sadık kalarak. Bu sayede ne istediğinizi daha net anlatmış olursunuz ve daha düzgün bir teklif/çıktı alırsınız.
Yardımcı olmamı istediğiniz bir konu var ise iletişim sayfamdan benimle irtibata geçebilirsiniz.
