Müşteri Talebi Teknik Backlog'a Çevirme: Alios ile

Müşteri Taleplerini Teknik Backlog'a Çevirme: Alios ile

Müşteri bir şey istiyor. "Şu butonu taşıyabilir misiniz?", "Toplu export özelliği eklenebilir mi?", "Bu rapor otomatik gönderilse harika olur." E-posta geliyor, WhatsApp mesajı geliyor, toplantıda söyleniyor.

Satış veya müşteri başarı ekibi not alıyor. Ya da almıyor. Teknik ekibe iletiliyor. Ya da iletilmiyor. Backlog'a giriyor. Ya da girmiyor.

Üç ay sonra aynı müşteri aynı isteği tekrarlıyor. "Bunu söylemiştim" diyor. Haklı.

Müşteri taleplerinin kaybolması tek seferlik bir unutkanlık değil. Talep ile backlog arasında köprü olmadığında her seferinde aynı şey oluyor.

Talep Neden Backlog'a Ulaşamıyor?

Müşteri isteğinin teknik backlog'a dönüşememesinin ardında dört yapısal sorun var.

Kayıt noktası belirsiz. Talep e-postaya mı yazılacak, Slack'e mi atılacak, bir forma mı girilecek? Standart yoksa her kişi farklı bir yere yazıyor. Bazıları hiçbir yere yazmıyor.

Talep sahibi yok. Müşteri isteği geldi, kim takip edecek belli değil. Satış mı, ürün müdürü mü, geliştirici mi? Sahipsiz talep bekleyen kuyrukta uyuyor.

Analiz adımı atlanıyor. Müşteri "şunu istiyorum" diyor ama bu isteğin teknik karşılığı ne, ne kadar efor alıyor, hangi önceliğe giriyor — bunlar değerlendirilmeden doğrudan backlog'a giriyor veya hiç girmiyor.

Kapanış döngüsü yok. Talep backlog'a girdi, sonra ne oldu? Müşteriye bilgi verildi mi? "Yapıldı, yayında" denildi mi? Bu döngü kapanmadığında müşteri karanlıkta kalıyor.

Alios'ta Dört Adımlı Talep Akışı

Alios'ta müşteri talebi teknik backlog akışı dört adımdan oluşuyor: talep → analiz → geliştirme → teslim. Her adım ayrı bir durum, ayrı bir sorumlu, ayrı bir çıktı.

Adım 1 — Talep: Kayıt ve Kaynak

Talep nereden gelirse gelsin — e-posta, toplantı, destek talebi, satış görüşmesi — tek bir node olarak açılıyor. Bu node "ham talep" aşamasında yaşıyor.

📌 TALEP NODE'U

Başlık: [Talep tek cümleyle — müşterinin kendi ifadesiyle]
Durum: Talep Alındı
Sorumlu: [Talebi alan kişi — satış veya müşteri başarı]
Kaynak: [Müşteri adı — kanal — tarih]
Ham talep: [Müşterinin tam ifadesi, kopyalanmış]
Deadline: [Analiz için hedef tarih — talep tarihinden 3-5 gün sonra]

Bu adımda teknik değerlendirme yapılmıyor. Sadece kayıt altına alınıyor. Amaç: hiçbir talep kaybolmasın.

Birden fazla müşteri aynı şeyi istiyorsa yeni node açılmıyor — mevcut node'a kaynak ekleniyor:

Kaynak 1: Müşteri A — Demo görüşmesi — 3 Mart
Kaynak 2: Müşteri B — Destek talebi — 7 Mart
Kaynak 3: Müşteri C — Email — 12 Mart
Toplam: 3 müşteri / 2 farklı segment

Adım 1 çıktısı: Her talep kayıt altında, kaynağı belli, sahibi var.

Adım 2 — Analiz: Teknik Değerlendirme

Talep node'u "Talep Alındı" durumundan "Analizde" durumuna geçiyor. Sorumlu değişiyor: artık ürün müdürü veya lead geliştirici.

📌 ANALİZ NOTU [Adım 1 node'una ekleniyor]

Durum: Analizde
Sorumlu: [Ürün müdürü veya lead geliştirici]
Deadline: [Analiz tamamlanma tarihi]

Teknik karşılık nedir?
[Bu talep teknik olarak ne anlama geliyor — 2-3 cümle]

Efor tahmini:
[Küçük / Orta / Büyük — veya gün/sprint tahmini]

Bağımlılıklar:
[Başka bir şeye bağımlı mı? Önce ne bitmeli?]

Öncelik değerlendirmesi:
[Roadmap'e uyuyor mu? Kaç müşteri istedi? Stratejik değer var mı?]

Karar:
[ ] Backlog'a alındı — öncelik: [Kritik / Yüksek / Orta / Düşük]
[ ] Reddedildi — sebep: [Neden]
[ ] Daha fazla bilgi gerekiyor — sorular: [Ne öğrenilmeli]

Bu analiz formu dolmadan talep backlog'a girmiyor. Bu adım "ne istendi" ile "ne yapılacak" arasındaki köprü.

Adım 2 çıktısı: Talep teknik olarak değerlendirildi, karar verildi, öncelik belirlendi.

Adım 3 — Geliştirme: Backlog'dan Teslimata

Analiz onaylandıysa talep backlog'a giriyor. Bu noktada yeni bir node açılıyor veya mevcut node "Geliştiriliyor" durumuna geçiyor.

📌 GELİŞTİRME NODE'U

Durum: Geliştiriliyor
Sorumlu: [Geliştirici adı]
Deadline: [Sprint veya teslim tarihi]
Bağlantılı talep: [Adım 1 node'unun adı]

Teknik yaklaşım:
[Nasıl implemente edilecek — kısa teknik not]

Kabul kriterleri:
[ ] [Kriter 1 — test edilebilir]
[ ] [Kriter 2 — test edilebilir]
[ ] [Kriter 3 — test edilebilir]

PR / Branch: [Link]
Test notları: [QA çıktısı]

Kabul kriterleri kritik. "Yapıldı" demek yetmiyor — müşterinin istediği karşılandı mı, test edilebilir kriterlerle doğrulanmalı.

Adım 3 çıktısı: Geliştirme tamamlandı, kabul kriterleri karşılandı, canlıya alınmaya hazır.

Adım 4 — Teslim: Döngüyü Kapat

En çok atlanan adım bu. Geliştirme bitti, canlıya alındı, ama müşteriye bilgi verilmedi. Müşteri hâlâ talebinin ne olduğunu bilmiyor.

📌 TESLİM NOTU [Node kapanmadan ekleniyor]

Durum: Tamamlandı
Sorumlu: [Müşteri başarı veya satış]
Teslim tarihi: [Canlıya alınma tarihi]

Müşteriye bildirim:
[ ] Talep eden tüm müşterilere bilgi verildi
[ ] Release notu veya changelog güncellendi
[ ] Müşteri geri bildirimi alındı — not: [Tepkisi ne oldu]

Node kapatıldı: [Tarih]

Bu adım sadece iyi müşteri ilişkisi değil. Aynı zamanda veri: müşteri tepkisi ileride benzer taleplerin önceliklendirilmesinde kullanılıyor.

Adım 4 çıktısı: Müşteri bilgilendirildi, döngü kapandı, geri bildirim kaydedildi.

Akışın Tamamı: Tek Bakışta

MÜŞTERİ TALEBİ
      ↓
📥 TALEP ALINDI
   Sorumlu: Satış / Müşteri Başarı
   Çıktı: Kayıt altında, kaynak belli
      ↓
🔍 ANALİZDE
   Sorumlu: Ürün Müdürü / Lead Dev
   Çıktı: Teknik değerlendirme, öncelik kararı
      ↓
🔄 GELİŞTİRİLİYOR
   Sorumlu: Geliştirici
   Çıktı: Kabul kriterleri karşılandı, canlıya alındı
      ↓
✅ TAMAMLANDI
   Sorumlu: Müşteri Başarı
   Çıktı: Müşteri bilgilendirildi, döngü kapandı

Her adımda farklı bir sorumlu. Hiçbir adım sahipsiz değil. Her adımın net bir çıktısı var.

Reddedilen Talepler İçin

Reddedilen talep de kapatılır ama silinmez. Node açıklamasında neden reddedildiği yazıyor. Müşteriye kısa bilgi veriliyor — "bu talebi aldık, şu sebepten şu an roadmap'e alamıyoruz" mesajı.

Bu mesaj zor görünüyor ama güven kuruyor. "Söyledim, hiçbir şey olmadı" hissinden çok daha iyi.

Reddedilen node'lar üç ayda bir gözden geçiriliyor. Koşullar değiştiyse — daha fazla müşteri istedi, teknik maliyet düştü, stratejik öncelik değişti — yeniden değerlendirilebilir.

Son Düşünce

Müşteri talebi teknik backlog akışı kurmak büyük bir operasyon değişikliği gerektirmiyor. Gerekli olan şey: her talebin bir kayıt noktası olsun, analiz adımı atlanmasın, teslimde döngü kapansın.

Alios'ta bu dört adım node yapısı, durumlar ve sorumlularla birlikte çalışıyor. Talep e-postada kaybolmuyor, analizsiz backlog'a girmiyor, teslim edilmeden kapatılmıyor.

Müşteri "bunu söylemiştim" demiyor. Çünkü söylediği şey sistemde görünüyor ve ona geri dönülüyor.