Çoğu işletme sahibi, sağlayıcısına ilettiği geliştirme talebinin bir sıraya girdiğini ve önüne kaç kişi varsa o kadar bekleyeceğini sanır. Bu yüzden talep gönderdikten sonra ilk yapılan şey beklemek, ikinci yapılan şey de birkaç hafta sonra "benim talep ne durumda" diye sormaktır. Oysa hiçbir ciddi yazılım ekibi talepleri geliş sırasına göre işlemez; işlese zaten kritik bir güvenlik yaması, ikinci sırada bekleyen bir renk değişikliğinin arkasında kalırdı.
Gerçek şu ki her e-pin satış yazılımı ekibinin görünmeyen bir puanlama tablosu vardır. Talebin bu tabloda aldığı puan; kaç kullanıcıyı etkilediği, ne kadar gelir riski taşıdığı, yapılması ne kadar süreceği ve mimariye ne kadar dokunduğu ile belirlenir. Bu yazıda o tablonun nasıl işlediğini, kendi talebini nasıl yüksek puanlı hale getireceğini ve hangi yazım hatasının talebini kuyruğun dibine gömdüğünü açıkça anlatıyorum.
Talebin gerçekte hangi tabloda değerlendiriliyor?
Bir epin yazılım ekibi talebe baktığında dört soru sorar. Bu özellik olmazsa kim para kaybeder? Kaç müşteri bunu istedi? Yapması ne kadar sürer? Mevcut mimariye ne kadar dokunur? İlk iki soru etkiyi, son iki soru eforu ölçer. Etki yüksek, efor düşükse talep hemen yapılır. Etki düşük, efor yüksekse talep kibarca rafa kalkar ve sana "yol haritasına aldık" denir.
Buradaki kritik ayrıntı şudur: etki, talebin ne kadar önemli olduğu değil, ne kadar kanıtlanabilir olduğudur. "Bu özellik çok önemli" cümlesi hiçbir puan kazandırmaz çünkü ölçülemez. Buna karşılık "bu eksiklik yüzünden ayda yaklaşık 140 sipariş elle işleniyor ve kişi başı 3 dakika sürüyor" cümlesi doğrudan bir sayıya çevrilir. Sayıya çevrilebilen her talep, çevrilemeyen her talebin önüne geçer.
Neden senin "acil" dediğin şey ekipte acil sayılmıyor?
Aciliyet iki farklı anlama gelir. Senin için acil, "bu hafta bir müşteriye söz verdim" demektir. Ekip için acil, "bu düzeltilmezse veri bozulur veya para kaybolur" demektir. İkisi çakışmadığı sürece etiket işe yaramaz, hatta zarar verir: her talebine acil yazan işletmelerin talepleri zamanla otomatik olarak indirimli okunur.
Aciliyeti gerçekten iletmenin yolu etiket değil, sonuç anlatmaktır. "Bu olmazsa ne olacak" sorusuna somut cevap ver: kaç sipariş etkileniyor, hangi tarihe kadar geçerli, geçici bir çözümle idare edilebiliyor mu. Geçici çözümü olan hiçbir talep gerçekten acil değildir; ama geçici çözümü olduğunu sen söylersen güvenilirliğin artar ve bir sonraki gerçekten acil talebin anında ciddiye alınır.
| Talep sınıfı | Tipik işleme süresi | Öncelik puanı | Ne belirler |
|---|---|---|---|
| Güvenlik veya veri bütünlüğü | 0 - 3 gün | Çok yüksek | Risk büyüklüğü |
| Para akışını durduran hata | 1 - 5 gün | Çok yüksek | Etkilenen işlem hacmi |
| Çok müşterili ortak eksik | 1 - 2 sürüm | Yüksek | Talep eden müşteri sayısı |
| Tek müşteriye özel işlev | Teklif sürecine bağlı | Orta | Ücretlendirme ve mimari uyum |
| Kullanım kolaylığı iyileştirmesi | 2 - 4 sürüm | Orta-düşük | Efor ve toplu paketleme |
| Görsel veya tercih meselesi | Belirsiz | Düşük | Zaten ayarla çözülebiliyor mu |
Talebini kuyruğun önüne taşıyan üç bileşenli yazım biçimi
İyi bir geliştirme talebi üç parçadan oluşur ve hiçbiri uzun değildir. Birinci parça bağlam: hangi ekranda, hangi rolde, hangi iş akışında. İkinci parça sorun: şu anda ne oluyor ve bunun bedeli ne. Üçüncü parça istenen davranış: ne olmasını bekliyorsun. Çoğu talep yalnızca üçüncü parçayla gelir ve bu yüzden ekip birinci ve ikinci parçayı tahmin etmek zorunda kalır.
Tahmin etmek zorunda kalan ekip iki şeyden birini yapar: ya sana geri soru sorar, ki bu bir hafta kaybettirir, ya da talebi anlaşılana kadar beklemeye alır, ki bu bir ay kaybettirir. Talebini üç parçayla yazmak, ortalama bekleme süresini yarıdan fazla kısaltır. Aynısı bir dijital ürün satış scripti için gönderilen hata bildirimlerinde de geçerlidir: adım adım tekrar üretim senaryosu yazılan hatalar, yazılmayanlara göre kat kat hızlı kapanır.
Gelen geliştirme taleplerinin kaderi
- Zaten mevcut, ayarla çözülüyor 45%
- Yol haritasına alınıyor 25%
- Ücretli özelleştirmeye dönüyor 20%
- Reddediliyor veya bekliyor 10%
Taleplerin yüzde kırk beşi neden zaten yapılabilir çıkıyor?
Olgun bir e-pin scripti yıllar içinde onlarca ayar, izin kuralı ve otomasyon biriktirir. Kullanıcı bunların tamamını görmediği için var olan bir işlevi geliştirme talebi olarak gönderir. Bayi bazlı fiyat kuralı, sipariş durum otomasyonu, stok eşiği bildirimi, çoklu depo, kısmi iade gibi ihtiyaçların büyük kısmı bu gruba girer.
Bu yüzden talep göndermeden önce iki dakikalık bir kontrol yap: aradığın işlev ayar ekranlarında, rol izinlerinde veya raporlama filtrelerinde var mı? Yoksa gerçekten yeni bir geliştirmedir ve talebin puanı yükselir. Varsa hem sen zaman kazanırsın hem de kuyruğu meşgul etmemiş olursun. Mevcut kapsamı görmek için özellik bölümüne göz atmak, çoğu talebi göndermeden çözer.
Talebinin sonuna şunu ekle: "Bu eksiklik bize ayda yaklaşık X saat elle iş ve Y sipariş gecikmesi yaratıyor." Ölçülebilir bedel yazan talepler, puanlamada bir üst sınıfa çıkar.
Aynı anda on talep göndermek neden hepsini yavaşlatır?
Toplu gönderilen talep listesi ilk bakışta verimli görünür ama pratikte tersini yapar. On maddelik bir liste, ekip tarafından tek bir büyük iş gibi algılanır ve büyük işler küçük işlere göre daha uzun süre planlama bekler. Ayrıca listenin içindeki bir madde belirsizse, tüm liste o madde netleşene kadar duraklayabilir.
Doğru yöntem şudur: listenin tamamını gönder ama kendin sırala ve ilk üçünü işaretle. "Bizim için kritik olan sırayla şu üçü, diğerleri zamanla" cümlesi ekibe karar yükü bırakmaz ve o üç madde bağımsız olarak işlenmeye başlar. Sıralamayı sen yapmazsan, senin adına başkası yapar ve sonuç hoşuna gitmeyebilir.
Yol haritasına alındı denen talep gerçekten yapılacak mı?
Bu cümle üç farklı anlama gelebilir: gerçekten planlandı, benzer taleplerle birleştirilmek üzere bekletiliyor veya kibarca reddedildi. Hangisi olduğunu anlamanın tek yolu tarih ve sürüm sormaktır. "Hangi sürümde hedefleniyor" sorusuna sürüm numarası veya çeyrek cevabı geliyorsa talep gerçekten plandadır. "İlerleyen dönemde" cevabı geliyorsa talep bekleme havuzundadır.
Bekleme havuzundaki bir talebi hareket ettirmenin meşru iki yolu vardır: aynı ihtiyacı yaşayan başka kullanıcıların da talep etmesi veya talebin ücretli özelleştirmeye çevrilmesi. İkincisini seçeceksen, kapsamı ve bütçeyi netleştirmek için paket ve modül bedellerini inceleyip hangi eşikte ödeme yapmanın mantıklı olduğunu hesapla.
| Kontrol maddesi | Etkisi | Durum |
|---|---|---|
| Ayar ekranlarında zaten var mı diye baktım | Gereksiz talebi eler | Zorunlu |
| Bağlam, sorun ve beklenen davranışı yazdım | Geri soru turunu ortadan kaldırır | Zorunlu |
| Ölçülebilir bedel belirttim | Öncelik puanını yükseltir | Zorunlu |
| Geçici çözümüm olup olmadığını söyledim | Güvenilirliği artırır | Önerilir |
| Listemi kendim sıraladım | İlk maddeleri bağımsız işletir | Önerilir |
| Ekran görüntüsü veya örnek sipariş ekledim | Tekrar üretim süresini kısaltır | Önerilir |
| Hedef sürüm veya çeyrek sordum | Belirsiz cevabı görünür kılar | Önerilir |
| Ücretli seçenek olup olmadığını sordum | Bekleyen talebi hareket ettirir | Duruma göre |
Önce kapsamı gör, sonra talep yaz
Talep listendeki maddelerin yarısı muhtemelen bugün açılabilir bir ayardır. Pinova'nın modül ve yetki yapısını incele, gerçekten eksik olanı ayır ve enerjini oraya harca.
Talebime hiç cevap gelmediyse ne yapmalıyım?
Genellikle talep anlaşılmadığı için beklemededir. Aynı talebi tekrar göndermek yerine bağlam, sorun ve beklenen davranış üçlüsüyle yeniden yaz ve ölçülebilir bir bedel ekle. Yeniden yazılan taleplerin işleme alınma oranı ilk göndermeye göre belirgin biçimde yüksektir.
Ücretli özelleştirme istersem talebim hemen yapılır mı?
Hemen değil ama sıradan bağımsız hale gelir. Ücretli işler ayrı bir planlama hattında yürütüldüğü için genel yol haritasını beklemez. Yine de ekip kapasitesine bağlı bir başlangıç tarihi olur ve bu tarih sözleşmede yazılı olmalıdır.
Başka kullanıcıların da aynı şeyi istemesi gerçekten etkiliyor mu?
Evet, en güçlü etkenlerden biridir. Birden çok müşteriden gelen aynı ihtiyaç, tek müşteriye özel işten çok daha yüksek puan alır çünkü aynı efor daha geniş bir kitleye değer üretir. Aynı ihtiyacı yaşayan tanıdık işletmelerin de talep iletmesi süreci hızlandırır.
Hata bildirimi ile geliştirme talebini ayırmam gerekir mi?
Kesinlikle. Hata, var olan bir işlevin bozulmasıdır ve farklı bir hatta işlenir. Geliştirme ise yeni davranış isteğidir. İkisini aynı mesajda karıştırmak, hatanın geliştirme kuyruğunda beklemesine yol açar ve gereksiz gecikme yaratır.
Önceliklendirme bir lütuf dağıtımı değil, kaynak matematiğidir; ve bu matematiğin girdilerini büyük ölçüde sen sağlarsın. Talebini ölçülebilir, tekrar üretilebilir ve sıralanmış biçimde yazdığın gün, kuyrukta bekleyen bir istekten planlanmış bir işe dönüşür. Hangi işlevlerin zaten hazır geldiğini kendi gözünle görmek istersen canlı demo üzerinde senaryonu dener, ancak gerçekten eksik kalan maddeler için talep açarsın.