Paydaş geri bildirimini yapıyı saptırmadan toplayın

Geri bildirim bir yapıyı neden saptırır

Çoğu yapı tek bir nedenle rayından çıkar: plan sürekli değişiyor.

Biri yeni bir ekran istiyor. Başkası farklı bir ifade dili öneriyor. Bir başkası daha önce onaylanmış bir tercihi tekrar açıyor. Bu her gün olunca ekip inşa etmeyi bırakıp tepki vermeye başlar.

Bu yüzden paydaş geri bildirimi, herkes iyi niyetli olsa bile sorun haline gelebilir. Her yorum tek başına küçük görünür, ama sürekli gelen küçük talepler projeyi yavaş yavaş hedefine çeker.

Sorun, geri bildirim dağıldığında daha da kötüleşir. Yorumlar e-postada, sohbette, toplantı notlarında ve hızlı aramalarda birikir. İnsanlar başkasının takip ettiğini varsayar, ama kimse bütünü görmez. Kısa süre sonra aynı istek üç farklı yerde belirir ve ekip gerçekten önemli olanın ne olduğunu çözmek için zaman kaybeder.

Bir diğer yaygın sorun da hatalarla fikirleri karıştırmaktır. Bozuk bir giriş butonu ile daha hoş bir gösterge panosu önerisi aynı yığın içinde rekabet etmemeli. Böyle olunca acil düzeltmeler gömülürken isteğe bağlı değişiklikler gürültü yaratır.

Sahiplik eksikliği bu durumu daha da kötüleştirir. Eğer kimsenin son sözü yoksa her küçük istek tartışmaya döner. Bir renk değişikliği uzun bir tartışma haline gelir. Bir özellik önerisi her toplantıda geri gelir. Yapı ivmesini kaybeder çünkü kararlar gerçekten kalıcı olmaz.

Bu durum özellikle teknik olmayan ekipler hızlı hareket ettiğinde sık görülür. Örneğin Koder.ai içinde bir uygulama şekillendiren bir kurucu, aynı anda satıştan, operasyondan ve iş ortağından geri bildirim alabilir. Her yorum doğrudan yapıya girerse, ürün ilk sürüm bitmeden yön değiştirebilir.

Maliyeti sadece ekstra iş değildir. Bu kafa karışıklığı, yavaş teslimat ve artık "bitti"nin ne olduğu bilinmeyen bir ekip demektir.

Geri bildirim başlamadan önce kurallar koyun

Yararlı geri bildirim istiyorsanız, kuralları erken belirleyin.

Çoğu proje yorumlar beş farklı yerde, beş farklı tarzda, beş farklı zamanda gelince sendelemeye başlar. Çözüm basittir: geri bildirime bir ev, bir format ve bir gözden geçirme ritmi verin.

İstekler için tek bir yerle başlayın. Bu paylaşılan bir doküman, bir proje panosu veya kararlaştırılmış tek bir kanal olabilir. Araç kuraldan daha az önemlidir. İnsanlar her yere yorum bırakabiliyorsa ekip daha çok avlanır, daha az inşa eder.

Herkesten aynı temel formatı kullanmasını isteyin. Karmaşık olması gerekmez. Kısa bir not neyin değişmesi gerektiğini, nerede göründüğünü, neden önemli olduğunu ve ne kadar acil olduğunu açıklamalı. Bu, "bunu daha iyi yap" veya "bu ekranı sevmiyorum" gibi belirsiz yorumları ortadan kaldırır.

Ayrıca geri bildirimin gün boyu ekibi bölmemesi için gözden geçirme zamanları belirlemek faydalıdır. Haftada iki kez değerlendirme veya teslimat sonu kontrolü genellikle yeterlidir. Paydaşlar girdilerinin ne zaman görüleceğini bilir, geliştiriciler ise odaklanmak için korunmuş zaman kazanır.

Kapsam konusunda da net olun. İnsanlara şu anda neyin gözden geçirildiğini, neyin sonraki faza ait olduğunu ve neyin mevcut versiyonun dışında olduğunu söyleyin. "Bu tur sadece kayıt akışı ve gösterge panelinin temel öğeleri için" gibi basit bir not yan taleplerin birikmesini engeller.

İyi zemin kuralları katı olmakla ilgili değildir. Herkes için geri bildirimi kolaylaştırır. İnsanlar nereye göndereceklerini, nasıl yazacaklarını, ne zaman değerlendirileceğini ve şu anda hangi tür girdilerin faydalı olduğunu bilir.

İstekleri iş akışına göre gruplayın

Geri bildirim gelmeye başladığında, kullanıcı yolculuğunun etkilediği kısmına göre ayırın.

Bu, tartışmayı kimin önce söylediğine veya kimin daha yüksek sesle söylediğine bağlı olmaktan kurtarır. Kayıtla ilgili bir yorum diğer kayıt yorumlarıyla birlikte olmalı. Ödeme akışıyla ilgili notlar diğer ödeme sorunlarıyla birlikte durmalı. Aynı, karşılama, arama, raporlama, hesap ayarları ve diğer temel akışlar için de geçerlidir.

Bu tür bir sıralama iki fayda sağlar. Birincisi, çoğaltılmış maddeleri ortaya çıkarır. Bir paydaş "form başta çok fazla soru soruyor" derken diğeri "kullanıcıların devam etmeden önce beş alan doldurmaması gerekiyor" diyorsa, genellikle aynı konuyu farklı kelimelerle ifade etmiş olurlar.

İkincisi, zincirleme etkileri gösterir. Kayıt kısaltılırsa karşılama, e-posta doğrulama ve ilk gösterge paneli ekranını da ayarlamanız gerekebilir. Bunu erken görmek ekibin işi dürüstçe tahmin etmesine yardımcı olur.

İyi bir alışkanlık, geri bildirimi geldiği sıraya göre değil, iş akışı partileri halinde tartışmaktır. Toplantılar odaklı kalır ve tekrarlayan tartışmalar azalır.

Örneğin bir ekip Koder.ai üzerinde müşteri uygulaması inşa ediyorsa, yorumlar satıştan, destekten ve kurucudan aynı anda gelebilir. Her mesajı ayrı ayrı ele almak yerine onları lead capture, hesap kurulumu ve takip görevleri gibi iş akışları altında gruplayın. Bu, insanların farklı şeyler isteyip istemediğini veya aynı sürtüşme noktasına tepki verip vermediğini görmekte çok daha kolaylaştırır.

Ve eğer bir yorum hiçbir iş akışına uymuyorsa, bu da bir şey anlatır. İçerik, görsel cilalama veya mevcut yapıyı kesintiye uğratmaması gereken daha geniş bir ürün fikri olabilir.

Hataları fikirlerden ayırın

Çok fazla gereksiz karışıklığa neden olan bir hata var: her yorumu aynı tür istekmiş gibi ele almak.

Bir şey kırıldığında ile birisi değiştirilmesini istediğinde aynı şey değildir.

Bir hata, bir şeyin başarısız olduğu, eksik olduğu veya açıkça yanlış olduğu anlamına gelir. Bir fikir ise öneri, tercih veya özellik isteğidir. Tepki farklı olmalı.

Bir müşteri formu gönderilmiyorsa bu bir hatadır. Birisi formun daha kısa olmasını veya buton renginin değişmesini isterse bu bir fikirdir.

Ekip bir bildirilen hatayı düzeltmek için işi durdurmadan önce somut bir şey isteyin. Ekran görüntüsü, tam adımlar, etkilenen sayfa ve kişinin beklediği sonuç genellikle yeterlidir. Bunlar olmadan bildirilen birçok "hata" yanlış anlamalar, eski sürümler veya tasarım tercihleri çıkar.

Hızlı bir test işe yarar: gerçekten bir şey mi çalışmıyor, tekrar çoğaltılabiliyor mu ve kanıt var mı? Evetse, hata kuyruğuna koyun. Ürün halen çalışıyorsa ve istek onu daha iyi yapmakla ilgiliyse, fikir kuyruğuna koyun.

Bu iki kuyruğu ayrı tutun. Hatalar ve fikirler karıştığında gerçek sorunlar gömülür ve tercih tartışmaları acilmiş gibi görünür.

Bu ayrım zaman kazandırır. Birisi "gösterge paneli kullanışsız" diyorsa, bu etiket kabul edilmeden önce kontrol edin. Sayfa çöküyorsa bu bir hatadır. Farklı grafikler veya başka bir düzen isteniyorsa bu bir fikirdir. Sonraki adım hangisi olduğuna bağlıdır.

Bir net karar sahibi tutun

Çok fazla insan evet diyebildiğinde, her istek açık kalır.

Bu, küçük yorumların uzun yazışmalara, tekrar eden toplantılara ve sürekli şekil değiştiren bir yapıya dönüşmesinin yoludur. Bunu önlemek için bir kişi son sözü söylemeli.

Bu, bir kişinin diğer herkesi görmezden gelmesi demek değildir. Girdiler paylaşılır, sonra karar hareket etmez. Tasarımcılar, geliştiriciler, satış, destek ve liderlik tüm bağlamı ekleyebilir. Ama bir isimli sahip neyin şimdi ekleneceğine, neyin bekleyeceğine ve neyin atılacağına karar verir.

Güçlü bir karar sahibi, yapının amacını anlar, hız ile kapsam arasında denge kurabilir ve görüşler ayrıldığında karar vermeye güvenilirdir.

O sahibi ilk günden görünür yapın. Proje özetine, kickoff notlarına ve geri bildirim kanalına adını koyun. Bir istek sohbette ortaya çıktığında herkes kimin karar verdiğini bilmelidir.

Ayrıca nihai kararları tek bir yerde kaydetmek yardımcı olur. Kısa bir not yeterlidir: ne istendi, ne karar verildi ve neden. Örneğin: "Karşılama etkileniyor, bu yüzden sonraya alındı." Bu, aynı fikrin her hafta yeniden açılmasını durdurur.

Basit bir örnek: satış yeni bir dışa aktarma seçeneği istiyor, destek daha net hata mesajları istiyor ve kurucu ana sayfada bir düzenleme istiyor. Karar sahibi hepsini yayın hedefiyle karşılaştırır. Hata mesajı düzeltmesi onaylanır çünkü şu anda kullanıcıları engelliyor. Diğer ikisi daha sonra planlanmak üzere kaydedilir.

İnsanlar yine de duyulmuş hisseder, ama yapı ilerlemeye devam eder.

Her seferinde basit bir inceleme süreci kullanın

Geri bildirimi iyi yönetmenin en kolay yolu, her seferinde aynı yolu takip etmektir.

Her isteği tek bir paylaşılan yere göndererek başlayın. Sonra sabit bir sırayla gözden geçirin:

1. Etkilenen iş akışı altında sınıflandırın.
2. Net bir etiket verin: hata, fikir, özellik isteği veya soru.
3. Belirsizse, kimse işlem yapmadan önce takip isteyin.
4. Tekrar edenleri birleştirin.
5. Etki hakkında kısa bir not ekleyin.

Çoğu ekip için bu yeterlidir.

Bundan sonra karar sahibi temizlenmiş listeyi gözden geçirir ve neyin şimdi ilerleyeceğine, neyin bekleyeceğine ve neyin reddedileceğine karar verir. Birçok ekibin atladığı adım budur. Herkes yorum yapabilir, ama eğer seçme yetkisi net değilse proje tıkanır.

Kararlar verildikten sonra, bunları sade bir dille paylaşın. İnsanlara şimdi neyin düzeltileceğini, neyin ertelendiğini ve neyin reddedildiğini söyleyin. Kısa bir güncelleme yeterlidir.

Örneğin, bir kurucu Koder.ai üzerinde bir CRM inşa ediyorsa, üç kişi satış panosunda değişiklik isterken bir kişi kişilerin kaydedilmediğini bildirebilir. Bunlar aynı şekilde ele alınmamalıdır. Pano yorumları birlikte gözden geçirilen fikirlerdir. Kaydetme sorunu bir hatadır ve önce ele alınabilir.

Net bir süreç, insanların duyulduğunu hissettirir ama her fikri anında işe dönüştürmez.

Gerçekte geri bildirim triajı nasıl görünür

Küçük bir ekibin müşteri uygulaması inşa ettiğini hayal edin.

Bir satış yetkilisi kayıt sayfasına iki ekstra alan eklenmesini istiyor. Destek, şifre sıfırlama e-postalarının hiç gelmediğini bildiriyor. Pazarlama ise gösterge panosuna yeni bir grafik istiyor.

Üç istek de önemli görünüyor ve her birinin makul bir nedeni var. Ama hepsi aynı öncelik sepetinde olmamalı.

Ekip önce onları iş akışına göre gruplayarak başlar. Ek alanlar kayıt ile ilişkilidir. Sıfırlama e-postası hesap kurtarma ile ilgilidir. Grafik isteği raporlama ile ilişkilidir.

Bu hızlı sınıflama zaten yardımcı olur. Bunlar üç rastgele yorum değildir; ürünün farklı bölümlerini etkiler ve farklı aciliyet seviyelerine sahiptir.

Sonra sahibi her birini etiketler. Sıfırlama e-postası hatadır. Ek alanlar özellik isteğidir. Grafik bir iyileştirme fikridir.

Hata önce gelir çünkü insanlar hesaplarına geri dönemez. Bu gerçek bir engeldir. Sahibi bunu mevcut yapıya taşır ve düzeltmenin nasıl kontrol edileceğini onaylar.

Ek alanlar faydalı olabilir ama acil değildir. Sahibi bir takip sorusu sorar: bu alanlar şu anda leadleri nitelendirmeye yardımcı mı yoksa önce mevcut formu test etmemiz mi gerekiyor? Cevap belirsizse istek bekler.

Grafik fikri beklemeye alınır. Pazarlama buna hala ihtiyaç duyabilir, ama kimsenin kayıt olmasını, giriş yapmasını veya ana görevleri tamamlamasını engellemiyor.

İşte iyi bir triaj böyle görünür. Bir kişi karar verir, ekip gerekçeyi görür ve yapı ilerlemeye devam eder. Hızlı kurulumlarda, örneğin Koder.ai içinde oluşturulan bir uygulamada, bu tür sıralama geri bildirimi kaotik yerine faydalı tutar.

Kaçınılması gereken yaygın hatalar

Bir yapının kontrolünü kaybetmenin en hızlı yolu her geri bildirimi bir görevmiş gibi ele almaktır.

Bu genellikle birkaç tanıdık şekilde ortaya çıkar. Takımlar her yorumu doğrudan tasarımcılara veya geliştiricilere yollar, bu odakları bozar ve yan konuşmalar yaratır. Aktif iş varken kapsam değişir, böylece küçük bir istek beklenenden daha fazla gecikmeye neden olur. En yüksek sesli görüş en acil gibi muamele görür, oysa arkasında az kanıt olabilir.

Belirsiz notlar da sorun yaratır. "Daha kolay yap" veya "bunu temizle" gibi yorumlar yardımcı gibi görünür, ama eyleme geçirilemeyecek kadar bulanıktır. Birisi bunları net bir soruna dönüştürene kadar ekip tahmin yürütüyor demektir.

Sahte mutabakat başka bir tuzaktır. İnsanlar bir toplantıda başlarını sallayıp "hepimiz anlaştık" der, ama eğer gerçekten bir karar sahibi yoksa aynı sorun ertesi gün yeni bir görüşle geri döner.

Bunun pratikte nasıl göründüğüne dair bir örnek: Bir paydaş kayıt akışının kafa karıştırıcı olduğunu söylüyor, bir diğeri yeni bir fiyatlandırma bölümü istiyor, üçüncüsü renk değişimi talep ediyor. Eğer bunların hepsi doğrudan geliştiricilere giderse, ekip gerçek kayıt sorununu çözmeyi bırakıp yüzeysel isteklere tepki verebilir.

Daha iyi bir alışkanlık basittir: durun, netleştirin, gruplayın ve karar verin.

İşe başlamadan önce kısa bir kontrol listesi

Yeni bir geri bildirime müdahale etmeden önce beş dakika ayırıp birkaç temel şeyi kontrol edin.

İlk olarak, isteğin türüne karar verin. Bir şey mi bozuk, yoksa yeni bir fikir mi? Sonra doğru iş akışına yerleştirin. Hangi kullanıcı sorununu çözdüğünü sorun. Kimse tek cümlede sorunu açıklayamıyorsa istek muhtemelen hâlâ çok belirsizdir.

Bundan sonra karar sahibinin onaylayıp onaylamadığını ve bunun şimdi mi yoksa bir sonraki inceleme döngüsünde mi ele alınması gerektiğini kontrol edin.

Bu küçük filtre çok fazla gürültüyü keser. Kullanıcıları engelleyen bir hata hızla ilerlemeli. Deneyimi geliştirebilecek bir fikir planlama aşamasına kadar bekleyebilir.

Bir paydaş müşteri panosunun "daha modern hissetmesi" gerektiğini söyleyebilir. Bu inşa etmeye başlamak için yeterli değildir. Ekip hangi iş akışının etkilendiğini, kullanıcıların neyle zorlandığını ve değişikliğin mevcut döngüye girip girmeyeceğini sormalıdır. Gerçek sorun faturaları bulamamaksa, istek spesifik ve kullanışlı olur.

Koder.ai gibi bir platformda hızlı inşa ediyorsanız, bu daha da önemlidir. Hız, çalışma gerçek kullanıcı ihtiyaçlarına ve net onaya bağlı kaldığında faydalıdır.

Pratik sonraki adımlar

Ağır bir süreçle başlamayın. Herkesin kullandığı tek bir paylaşılan şablonla başlayın.

Kısa tutun. Değişikliği, kimin etkilendiğini, bunun hata mı yoksa fikir mi olduğunu ve neden şimdi önemli olduğunu sorun. Bu tek alışkanlık çok fazla gürültüyü kaldırır. İnsanlar belirsiz istekleri sohbetlere bırakmayı bırakır ve ekip her seferinde aynı düzeyde bilgi alır.

Sonra hafif bir haftalık ritim oluşturun. Çoğu ekip için haftada bir veya iki inceleme oturumu yeterlidir. Acil hatalar daha hızlı ilerleyebilir, ama fikirler ve iyileştirme talepleri bir sonraki incelemeye kadar beklemeli, böylece ekip her gün farklı yönlere çekilmez.

Basit bir karar günlüğü de tutun. Bir elektronik tablo veya kısa bir tablo yeterlidir. Önemli olan insanların neyin onaylandığını, neyin ertelendiğini ve nedenini görebilmesidir.

Eğer ekibiniz Koder.ai içinde inşa ediyorsa, onaylanan geri bildirim sonrası planlama modu, bir isteği değişiklik başlamadan önce net inşa adımlarına dönüştürmenize yardımcı olabilir. Snapshots, bir güncelleme test etmek, tepkileri toplamak ve gerekirse daha güvenli sürüme geri dönmek istediğinizde faydalıdır.

Küçük bir örnek düşünün. Bir satış yetkilisi yeni bir CRM alanı istiyor, destek bir form sorununu bildiriyor ve kurucu ana sayfa değişikliği istiyor. Bir şablon, sabit bir inceleme zamanı ve bir karar sahibiyle bu istekler artık birbirleriyle rekabet etmeyi bırakır. Hata hızlıca düzeltilir, CRM değişikliği planlanır ve ana sayfa fikri daha güçlü bir gerekçe olana kadar bekletilir.

Hedef budur. Geri bildirim ürünü iyileştirmeli, onu yolundan çıkarmamalı.