ResearchOps Hangi Ölçekte İşe Yarar, Hangi Ölçekte Yük Olur

ResearchOps anlatılırken neredeyse her zaman aynı yerden başlanır: araştırma sayısı artıyor, süreçler dağılıyor, o halde operasyon kurun. Bu zincirin ilk halkası doğru, sonuncusu ise koşullu. Operasyon kurmanın da bir maliyeti var ve bu maliyet araştırma sayısından bağımsız olarak her ay ödeniyor. Asıl soru ResearchOps'un gerekli olup olmadığı değil, sizin ölçeğinizde kendini çıkarıp çıkarmadığı.

Terim ne kadar yeni, iş ne kadar eski

ResearchOps, kullanıcı araştırmasının etrafındaki tekrar eden işlerin adı: katılımcı bulmak, onam ve gizlilik belgelerini düzenli tutmak, araçları standartlaştırmak, bulguları bulunabilir bir yerde saklamak. Bu işler ResearchOps diye bir başlık olmadan önce de vardı. Fark, kimin yaptığında.

Küçük ekiplerde bu işleri araştırmacının kendisi yapar ve genelde farkında bile olmaz. On kişilik bir araştırma ekibinde ise aynı işler herkesin biraz zamanını yer, kimsenin sorumluluğunda olmaz, hepsi yarım kalır. ResearchOps'un çözdüğü asıl problem karmaşıklık değil, sahipsizlik. Bu ayrım önemli, çünkü sahipsizlik yoksa çözülecek bir şey de yok.

"Ölçeklenebilir süreç" iddiasının sessiz varsayımı

ResearchOps yazılarının ortak vaadi şu: süreçler standartlaşınca proje başına harcanan efor düşer, dolayısıyla projeler arttıkça toplam maliyet kontrol altında kalır. Cümlenin ilk yarısı doğru. İkinci yarısı, operasyonun kendisinin bakım gerektirmediğini varsayıyor.

Basit bir hesap kurun. Diyelim ki standartlaşmış bir süreç araştırma başına iki gün kazandırıyor. Buna karşılık katılımcı panelini güncel tutmak, araç aboneliklerini yönetmek, arşivi etiketlemek ve şablonları elden geçirmek haftada yarım gün alıyor. Yılda bu 23 güne yakın bir bakım yükü demek. Getirinin bunu geçmesi için yılda 12'den fazla araştırma yapmanız gerekir. Yılda dört araştırma yapan bir ekipte tablo net: 8 gün kazanıp 23 gün harcarsınız.

Sayılar sizin ekibinizde başka çıkar, buradaki varsayımlar sabit değil. Ama hesabın şekli değişmiyor: ResearchOps'un getirisi araştırma sayısıyla çarpılır, maliyeti ise sayıdan bağımsız akar. İki doğrunun kesiştiği yer sizin kırılma noktanız. O noktanın altındaysanız kurduğunuz şey operasyon değil, bürokrasi.

Bileşen listesi bir başlangıç planı değildir

Katılımcı yönetimi, yönetişim, bilgi yönetimi, araçlar, yetkinlik, savunuculuk. Bu altı başlık her ResearchOps yazısında karşınıza çıkar ve bir kontrol listesi gibi görünür. Kontrol listesi gibi kullanıldığında da hepsine aynı anda başlanır, hiçbiri bitmez.

Altısının aynı anda acil olduğu bir organizasyon yok. Ekibe sorun: son üç ayda hangi iş en çok kez ertelendi, hangi soruya "bilmiyorum, bir yerde olması lazım" cevabı verildi. Cevap genelde tek bir yerde toplanır ve şaşırtıcı biçimde çoğu ekipte aynı yerde toplanmaz. Bazı ekiplerde katılımcı bulmak, bazılarında geçen yılın bulgusunu bulmak, bazılarında ise hukuk onayını beklemek.

Savunuculuk bileşeni de burada tersinden anlatılıyor genelde. Araştırmanın değerini yönetime anlatmak için önce anlatılacak bir şey olması gerekir. Operasyon kurulmadan yapılan üç iyi araştırma, kurulmuş ama boş çalışan bir operasyondan daha ikna edicidir.

Merkezi bilgi havuzu, aranmıyorsa havuz değildir

"Bulgular merkezi bir sistemde saklanır, böylece tekrar eden araştırmalar önlenir" cümlesi kulağa mantıklı geliyor ama pratikte en sık çöken bileşen bu. Depolamak kolay, bulmak zor.

Tekrar eden araştırmanın önlenmesi, birinin yeni bir çalışmaya başlamadan önce "bu daha önce yapıldı mı" diye araması şartına bağlı. Bu arama alışkanlığı kendiliğinden oluşmuyor. Arşive konan şey 40 sayfalık bir sunum dosyasıysa hiç oluşmuyor, çünkü kimse dört sunum açıp içinde cevap aramaz.

İşe yarayan tek yapı, bulguların araştırma raporundan ayrı, tek cümlelik ve etiketli olarak tutulması. "Kullanıcılar filtre panelini fark etmiyor" gibi bir cümle, bağlandığı çalışmayla birlikte aranabilir olduğunda değer taşır. Rapor arşivi bir kayıt, bulgu listesi ise bir hafızadır. İkisi aynı şey değil.

Küçük ekip için asgari kurulum

Ölçeğiniz kırılma noktasının altındaysa hiçbir şey yapmayın demek değil bu. Yapılacaklar var, sadece azlar.

• Katılımcı listesini elektronik tabloyla tut, araç almadan önce altı ay öyle çalıştır. Hangi alanların gerçekten kullanıldığını ancak o zaman görürsün, ondan sonra alacağın araç da doğru araç olur.
• Onam metnini ve veri saklama süresini bir kez yaz, her çalışmada yeniden yazma. Bu, bileşenler arasında sabit maliyeti en düşük olanı ve atlandığında geri dönüşü en pahalı olanı.
• Her çalışmadan çıkan bulguları tek satır halinde ortak bir dosyaya ekle. Formatı sonra düzeltirsin, kayıt kaybını sonra düzeltemezsin.

Ekip büyüdükçe bu üç şeyin hangisinin altından kalkamadığınızı fark edersiniz. Operasyonu o zaman kurun, ihtiyaç ortaya çıktığında; kurulacak şeyin ne olduğunu da o zaman bilirsiniz. Baştan tasarlanmış bir ResearchOps programı, henüz yaşanmamış problemlere çözüm üretmeye çalışır ve genelde yanlış problemleri seçer.