Yazılım geliştirme teklifi için ihtiyaç dokümanı hazırlama

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.

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.

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.