Mobil Uygulama Projesinde Revizyon ve Ek Geliştirme Talepleri Nasıl Yönetilir?
Sözleşme rehberimizde revizyon hakkının sözleşmede nasıl tanımlanması gerektiğini ele almıştık. Bu yazıda ise madalyonun operasyonel yüzüne bakıyoruz: bir revizyon veya ek özellik talebi geldiğinde günlük işleyişte bu nasıl ele alınır, önceliklendirilir ve fiyatlandırılır?
Revizyon ile Yeni Özellik Talebi Arasındaki Fark
Mevcut bir ekranın çalışma şeklini düzeltmek (ör. bir buton yanlış yere hizalanmış) revizyondur. Mevcut olmayan bir işlevi eklemek (ör. yeni bir filtreleme özelliği) ise yeni geliştirmedir. Bu ayrım, hangi talebin sözleşme kapsamında ücretsiz, hangisinin ek ücretli olduğunu belirler.
Kısa cevap
Bir talep geldiğinde önce revizyon mu yoksa yeni geliştirme mi olduğu netleştirilir, sonra kapsamı ve varsa ek ücreti/süresi paylaşılıp onayınızla ilerlenir.
Talep Yönetim Akışı
| Adım | Ne Olur |
|---|---|
| 1. Talebin iletilmesi | WhatsApp üzerinden talep paylaşılır |
| 2. Kapsam değerlendirmesi | Revizyon mu, yeni geliştirme mi olduğu netleşir |
| 3. Süre/ücret paylaşımı | Varsa ek süre ve ücret bildirilir |
| 4. Onay ve geliştirme | Onayınızla talebe başlanır |
Talepler Nasıl Önceliklendirilir?
Aktif bir geliştirme sürecinde birden fazla talep birikebilir. Önceliklendirme genellikle şu sıraya göre yapılır: önce mevcut bir işlevi bozan hatalar, sonra kullanıcı deneyimini doğrudan etkileyen revizyonlar, en son ise "olsa iyi olur" nitelikli ek özellikler. Bu sıralamayı sizinle birlikte netleştiririz.
Sık Talep Gelen Değişiklikler Baştan Nasıl Önlenir?
Tasarım aşamasında yapılan erken onaylar, ilerleyen revizyon talebi sayısını azaltır. Tasarım süreci rehberimizde anlattığımız gibi, wireframe aşamasında verilen geri bildirim, geliştirme tamamlandıktan sonra istenen bir değişiklikten çok daha ucuz ve hızlı uygulanır.
Gerçek Bir Senaryo: Biriken Taleplerin Önceliklendirilmesi
Geliştirme sürecinde beş farklı talep biriken bir projeyi ele alalım: biri bir buton hatası, ikisi tasarım revizyonu, ikisi de yeni özellik isteği. Talepler önceliklendirildiğinde, hata düzeltmesi hemen ele alınıyor, tasarım revizyonları mevcut sprint içinde tamamlanıyor, yeni özellik istekleri ise ayrı bir kapsam olarak fiyatlandırılıp bir sonraki aşamaya planlanıyor. Bu sıralama, projenin ana teslim tarihini geciktirmeden tüm taleplerin adil şekilde ele alınmasını sağlıyor.
Sık Yapılan Hatalar
En sık düşülen hatalar: her talebi aynı önem derecesinde görmek — bu, asıl kritik olan hataların gecikmesine yol açabilir; talebi netleştirmeden "şunu da ekleyin" demek — belirsiz bir talep, yanlış anlaşılma riskini artırır ve süreci uzatabilir.
mobilsepeti.com.tr'de Talep Yönetimi
Tüm talepleriniz WhatsApp üzerinden iletilir, kapsamı netleştikten sonra size süre ve varsa ücret bilgisi paylaşılır. Sözleşmenizde revizyon hakkının nasıl tanımlandığını görmek için sözleşme rehberimize göz atabilirsiniz.
Sık Sorulan Sorular
Küçük bir metin değişikliği de revizyon sayılır mı?
Hayır, küçük metin/içerik düzenlemeleri genellikle standart süreç içinde kolayca yapılır. Revizyon süreci, tasarım veya akış üzerinde daha kapsamlı değişiklikler için işletilir.
Bir talebin revizyon mu yoksa yeni özellik mi olduğuna kim karar verir?
Bu, sözleşmede tanımlanan kapsama göre birlikte değerlendirilir; mevcut bir ekranı düzeltmek revizyon, yeni bir ekran/işlev eklemek ise yeni geliştirme sayılır.
Ek geliştirme talebimin ne kadar süreceğini nasıl öğrenirim?
Talebi ilettikten sonra kapsamı değerlendirilip size bir süre ve varsa ek ücret tahmini paylaşılır; onayınızdan sonra geliştirmeye başlanır.
Projenizi konuşalım
Uygulama fikrinizi anlatın, size özel bir kapsam ve fiyat teklifi çıkaralım.