Yazılım geliştirme teklifi için ihtiyaç dokümanı hazırlama
Özel yazılım teklifi almadan önce kullanıcı rolleri, iş akışları, kabul ölçütleri, entegrasyonlar ve bakım kapsamını tanımlayın.
Teklif istemeden önce çözülecek problemi, kullanıcıları ve tamamlanma ölçütünü yazın. Ekran sayısı yerine iş akışları ve somut kabul senaryoları üzerinden kapsam belirleyin.
Bu rehberde neler var?
- Problemi mevcut iş üzerinden anlatın
- Rol, akış ve kabul senaryosu yazın
- Karar tablosu: durumunuzu değerlendirin
- Teklifte görünmesi gereken kapsam
- Teklifleri aynı senaryoyla değerlendirin
- Tek bir özellik talebini kabul senaryosuna çevirmek
- Kapsam değiştiğinde teklif nasıl güncellenmeli?
- Uygulama kontrolü ve dikkat edilecek nokta
- Sık sorulan sorular
Problemi mevcut iş üzerinden anlatın
“Bir yönetim paneli istiyoruz” yerine bugün kimin hangi işi nasıl yaptığını yazın. Örneğin siparişler farklı tablolarda tutuluyor, aynı müşteri iki kez kaydediliyor ve durum bilgisi telefonda soruluyor olabilir. Hangi sorunun öncelikli olduğunu belirtin.
Mevcut işlem hacmi, ekip büyüklüğü ve kullanılan sistemler teknik kararları etkiler. Gerçek veri paylaşmanız gerekiyorsa kişisel veya gizli bilgileri ayıklanmış örnekler hazırlayın. Sorunu anlatmak için üretim veritabanının tamamını göndermek gerekmez.
Rol, akış ve kabul senaryosu yazın
Rolleri müşteri, operasyon çalışanı ve yönetici gibi ayırın. Her rolün okuyabildiği, oluşturabildiği ve değiştirebildiği bilgileri belirtin. “Sipariş yönetimi” başlığını sipariş açma, durum değiştirme, arama ve dışa aktarma gibi akışlara bölün.
Bir kabul senaryosu şöyle olabilir: “Operasyon çalışanı bir siparişin durumunu değiştirdiğinde eski ve yeni durum, işlem zamanı ve işlemi yapan kişi kaydedilir; yetkisiz kullanıcı bu işlemi yapamaz.” Bu cümle tasarım ve test için ortak bir ölçüt sağlar.
Karar tablosu: durumunuzu değerlendirin
Dar ekranda tüm sütunları görmek için tabloyu yatay kaydırabilirsiniz.
| Durum | Nasıl yorumlanır? | Sonraki adım |
|---|---|---|
| Sabit kapsam | İstenen akışlar yeterince tanımlı ve değişiklik ihtiyacı sınırlı. | Kabul ölçütünü, hariç işleri ve değişiklik fiyatlama yöntemini yazın. |
| Aşamalı keşif | İş süreci veya veri yapısı henüz net değil. | Önce belirsizliği azaltacak keşif teslimini tanımlayın; tüm proje için kesin tahmin istemeyin. |
| Devam eden ürün | Yeni ihtiyaçlar düzenli ortaya çıkıyor. | Önceliklendirme, ekip kapasitesi ve dönem sonunda değerlendirilecek çıktıyı netleştirin. |
Teklifte görünmesi gereken kapsam
- İlk sürüme dahil işler ve sonraya bırakılanlar.
- Tasarım, mobil uyumluluk ve erişilebilirlik beklentileri.
- API, ödeme, e-posta ve muhasebe entegrasyonları.
- Veri taşıma, test ortamı ve yayına geçiş planı.
- Kaynak kodu, dokümantasyon ve hesapların devri.
- Hata düzeltme, bakım, barındırma ve değişiklik süreci.
Üçüncü taraf hizmetlerin güncel ücretleri ve erişim koşulları teklif sırasında doğrulanmalıdır. Bir API’nin mevcut olduğunu söylemek, gerekli işlemlerin verilen erişim düzeyiyle yapılabildiğini kanıtlamaz.
Teklifleri aynı senaryoyla değerlendirin
Her adaya aynı ihtiyaç dokümanını ve örnek iş akışını gönderin. Belirsiz kalan varsayımları ayrı listelemelerini isteyin. Çok kısa bir teslim süresini avantaj saymadan önce test, veri taşıma ve kullanıcı kabulünün bu süreye dahil olup olmadığını kontrol edin.
İlk sürümü ana problemi çözen dar bir kapsamda tutabilirsiniz. Canlıya geçişte geri dönüş planı ve yedekleme testi bulunmalı. API entegrasyonu rehberi, bağlantılı sistemler için sorulacak teknik soruları tamamlar.
Tek bir özellik talebini kabul senaryosuna çevirmek
AÇIKLAMALI ÖRNEK · TEMSİLÎ SENARYO
“Müşteri yönetimi olsun” ifadesi iki ekip için çok farklı işler anlamına gelebilir. Bunun yerine satış çalışanının yeni müşteri açması, aynı kayıt tekrar girildiğinde uyarı alması ve yalnız yetkili kişilerin dışa aktarım yapması gibi senaryolar yazılır. Her senaryoda başlangıç durumu, yapılan işlem ve beklenen sonuç bulunur.
Teklif veren ekip bu senaryoların hangilerini kapsadığını gösterir. Veri aktarımı, eğitim ve eski sistemin kapatılması ayrı iş kalemleridir. Değerlendirmede yalnız toplam süreye değil, ara teslimlerde hangi işlerin görülebileceğine bakılır. Örnek bir müşteri kaydıyla erken demo yapmak, bütün geliştirme tamamlandıktan sonra ortaya çıkacak kapsam farklarını daha erken görünür kılar.
Kapsam değiştiğinde teklif nasıl güncellenmeli?
Proje başladıktan sonra yeni bir ihtiyaç ortaya çıkabilir. Talebi mevcut işe sessizce eklemek yerine hangi kullanıcı sorununu çözdüğünü, mevcut akışı nasıl etkilediğini ve ilk sürüm için zorunlu olup olmadığını yazın.
Örneğin başlangıçta tek şubeli sipariş yönetimi planlanırken çok şubeli yetkilendirme istenmesi yalnızca bir seçim alanı eklemek olmayabilir. Kayıt erişimi, raporlar, testler ve veri modeli etkilenebilir. Geliştiriciden bu etkileri ve yeni kabul senaryolarını açıklamasını isteyin.
- Talebin açıklaması ve gerekçesi.
- Mevcut kapsama etkisi ve bağımlı işler.
- Ücret ve teslim tarihindeki değişiklik.
- Onaylayan kişi ve uygulanacak sürüm.
İlk aşamada daha küçük bir çözümün yeterli olup olmadığını anlamak için hazır sistem ve özel yazılım karşılaştırmasını da kullanabilirsiniz. Kararı özellik sayısıyla değil, ana iş akışının karşılanmasıyla verin.
Uygulama kontrolü ve dikkat edilecek nokta
KENDİ ÇALIŞMANIZA UYGULAYIN
- En kritik üç akışı örnek veriyle tanımlayıp tekliflerin aynı kapsamı yanıtlamasını sağlayın.
- Harici servis, lisans ve hesap sahipliğini proje bedelinden ayrı listede gösterin.
- Teslim sonrası hata düzeltmesi ile yeni özellik talebinin nasıl ayrılacağını yazın.
Sık sorulan sorular
Teklif almak için tasarımın hazır olması gerekir mi?
Şart değil. Ancak temel iş akışları, kullanıcı rolleri ve beklentiler yeterince açık olmalıdır; tasarım işi ayrıca kapsamlandırılabilir.
Bakım geliştirme ücretine dahil midir?
Her teklif farklıdır. Hata düzeltme dönemi, güncelleme, izleme ve yeni özellik taleplerini ayrı kalemlerle netleştirin.
Teklif için bütün ekranları çizmek gerekir mi?
Her zaman değil. Kullanıcı rolleri, temel akışlar, örnek veriler ve kabul koşulları başlangıç için daha belirleyici olabilir. Karmaşık etkileşimlerde prototip belirsizliği azaltır; görsel çizim tek başına iş kurallarını tanımlamaz.
Bu rehber Takipci.gen.tr tarafından hazırlanmıştır. Temsilî senaryolar ve hesaplamalar yöntemi açıklamak içindir; ölçülmüş müşteri sonucu veya başarı garantisi değildir. Yayın ve kaynak yaklaşımımız.