Kurumsal Yazılımda Kullanıcı Araştırması: Yöneticiyle Yetinmeyin

Dört farklı ilişkiyi görünür kılın

Kararı veren, işlemi yapan, sonucu kullanan ve sorun çıktığında destek veren kişileri ayrı yazın. Bir kişi birkaç rolü üstlenebilir; bu, rollerin aynı ihtiyaca sahip olduğunu göstermez. Satış temsilcisi hızlı teklif hazırlamak isterken finans ekibi fiyat değişikliğinin izini görmek isteyebilir.

GOV.UK deneyim araştırması, insanların bir hizmette ne yaptığını ve zaman içinde neler yaşadığını öğrenmeye odaklanır. [1] Keşif rehberi de farklı kullanıcı gruplarını araştırma kapsamına alır. [2] Aşağıdaki rol matrisi ise kurumsal yazılım için önerdiğimiz özgün uygulama biçimidir.

Görüşmede son gerçek işi konuşturun

“Nasıl bir uygulama istersiniz?” yerine son tamamlanan işi sorun. Hangi bilgi eksikti, hangi dosya açıldı, kimin onayı beklendi? Somut olaylar, ideal süreç anlatısından farklı ayrıntılar verebilir. Ekran kaydı alınacaksa izin ve veri gizliliğini önceden ele alın; müşterilerin kişisel bilgileri gösterilmesin.

Günlük iş yapan kişi bir kestirme yöntem kullanıyorsa bunu hemen yanlış davranış saymayın. Kestirme, sistemin karşılamadığı ihtiyacın işareti olabilir. Örneğin saha çalışanı konumu not alanına yazıyorsa, adres verisinin iş emrine doğru taşınmadığını araştırın. Yeni sürümde not alanını kaldırmak sorunu çözmeyebilir.

Çelişkiyi oylamayla gizlemeyin

Yönetici her kaydın eksiksiz girilmesini isteyebilir. Kullanıcı ise müşterinin bazı bilgileri görüşme sonunda verdiğini söyleyebilir. “Çoğunluk hangisini istiyor?” sorusu yerine bilginin hangi aşamada gerekli olduğunu inceleyin. Taslak, tamamlanmış ve onaylanmış kayıtları ayırmak iki ihtiyacı da karşılayabilir.

Varsayımsal teknik servis örneğinde teknisyen sahada hızlı kapatma ister; destek ekibi ise kullanılan parçayı bilmek zorundadır. Parça bilgisini iş kapanışında zorunlu yapmak doğru olabilir, ama teknisyenin parça kataloğuna çevrimdışı erişimi yoksa bu kural uygulanamaz. Kullanıcı talebini teknik bağlamdan koparmayın.

Araştırma kapsamı matrisi

Tablodaki roller örnektir. Farklı cihaz, deneyim seviyesi ve çalışma ortamlarını da göz önünde tutun. Aynı ofisteki beş kişi, farklı koşullarda çalışan beş rolün yerini tutmayabilir. Araştırma kapsamını istatistiksel temsil iddiasına dönüştürmeden sınırlarını yazın.

Bulguyu gereksinime çevirirken iz bırakın

Görüşme notu, yorum, öneri ve onaylanmış gereksinim farklı kayıtlardır. Her yeni özelliği hangi gözleme dayandırdığınızı gösterin. “Müşteri bunu istedi” cümlesi yerine işi, koşulu ve beklenen sonucu belirtin. Tek kullanıcının tercihinin ürünün tümüne uygulanıp uygulanmayacağı ayrıca değerlendirilsin.

İlk sürümü sadece yöneticiye onaylatmayın. Günlük işi yapanlar temsilî görevleri tamamlasın, destek ekibi sorunlu kaydı inceleyebilsin. Farklı rollerin kabulü aynı ekrana bakmak değil, aynı sürecin kendi bölümlerini doğrulamak anlamına gelir. Böylece proje tesliminde görünmeyen iş yükleri daha erken ortaya çıkar.

Sık sorulan sorular

Kullanıcının istediği her özellik yapılmalı mı?

Hayır. Söylenen çözümün arkasındaki ihtiyacı araştırın. Aynı problem daha basit bir süreç değişikliğiyle çözülebilir.

Yönetici görüşmesi gereksiz mi?

Hayır. İş hedefi, risk ve bütçe için değerlidir. Ancak günlük kullanımın tek kaynağı olarak ele alınmamalıdır.