Görev Onay ve Test Süreci Nasıl Kurulur?

"Bitti" kelimesi ekipten ekibe farklı anlamlara gelir. Yazılımcı için kodun yazılması, satış ekibi için teklifin gönderilmesi, yönetici için ise sonucun beklentiyi karşılaması "bitti" demektir. Bu farkı kapatmanın yolu, işin hangi noktada gerçekten tamamlanmış sayılacağını bir onay ve test süreciyle tanımlamaktır.

İyi kurulmuş bir onay süreci bürokrasi yaratmaz; tersine, işin geri dönme ihtimalini azaltır ve kimin neyi kontrol ettiğini kayıt altına alır. Bu yazıda görev seviyesinde onay ve test akışının nasıl tasarlanacağını, proje talepleri için onay zincirini ve sık yapılan hataları ele alıyoruz.

Onay süreci neden gerekli?

Onay adımı üç temel ihtiyaca cevap verir:

• Kalite: Çıktı, işi talep eden ya da sonucundan sorumlu kişi tarafından görülmeden kapanmaz.
• Hesap verebilirlik: Kimin hangi tarihte onay verdiği iz bırakır.
• Görünürlük: "Tamamlandı ama onay bekliyor" işleri ayrı izlenir, gözden kaçmaz.

ISO 9001 gibi kalite yönetim sistemleriyle çalışan kurumlarda bu kayıtlar, işin kontrol edildiğini gösteren kanıt olarak da değer taşır.

Yönetici onayı nasıl işler?

HibritİK'te bir göreve yönetici atandığında, sorumlu kişi görevi tamamladığında görev otomatik olarak onay bekliyor durumuna geçer. Yönetici iki seçenekten birini kullanır:

1. Onaylamak: Görev kesin olarak tamamlanır.
2. İade etmek: Görev gerekçeyle birlikte sorumluya geri döner.

İade gerekçesi neden önemli?

"Olmamış" demek yeterli değildir. İade gerekçesi, sorumlunun neyi düzeltmesi gerektiğini açıkça anlamasını sağlar ve aynı işin ikinci kez geri dönmesini önler. Gerekçeler görev geçmişinde kaldığı için sonradan yapılan değerlendirmelerde de başvurulabilir bir kaynak oluşturur.

Test sorumlusu ve Geçti/Kaldı kaydı

Bazı işlerde yöneticinin onayı yeterli değildir; çıktının teknik olarak kontrol edilmesi gerekir. Yazılım geliştirme, form tasarımı, rapor hazırlama ya da bir sürecin sahada denenmesi bu türden işlerdir.

Bu durumda göreve bir test sorumlusu atanır. Görev teste gönderildiğinde durumu "Test" olur ve test sorumlusu sonucu Geçti veya Kaldı olarak kaydeder. Testten kalan iş, sorumlunun gündemine geri döner. Test sorumlusu atanmamış bir görev teste gönderilemez; bu kural, testin "birisi bakar" belirsizliğine düşmesini engeller.

Test sorumlusu kendi bekleyen işlerini "Testimi bekleyen" sekmesinden, yönetici ise "Onayımı bekleyen" sekmesinden takip eder.

Test adımının verimli olması için kabul kriterlerini görev açılırken yazmak önemlidir. "Rapor doğru olsun" yerine "Rapor geçen ayın verisiyle karşılaştırıldığında toplamlar tutmalı" gibi somut bir ifade, test sorumlusunun neyi kontrol edeceğini netleştirir ve Kaldı sonucunun gerekçesini de kolaylaştırır.

Toplu onay kuyruğu

Çok sayıda kişiyle çalışan yöneticiler için en büyük zorluk, onay bekleyen işlerin birikmesidir. HibritİK'teki merkezi onay ekranı, onayınızı bekleyen tüm görevleri tek bir kuyrukta toplar. Kontrol ettiğiniz işleri tek tek ya da toplu onay ile aynı anda onaylayabilirsiniz.

Toplu onayı alışkanlık haline getirirken dikkatli olun: Toplu onay, gözden geçirilmiş işler için bir hızlandırıcıdır, kontrol adımının yerini tutmaz. Mobil uygulamadaki onay ekranı sayesinde bu kuyruk sahada ya da toplantı arasında da eritilebilir.

Proje talebi onay zinciri

Onay yalnızca görev seviyesinde değil, işin başında da gerekir. Yeni bir projenin açılması bütçe ve kaynak kararı demektir. HibritİK'teki proje talebi sihirbazı; bütçe, amaç, hedef ve proje üyeleri bilgilerini toplar ve talebi yapılandırılabilir bir onay zincirinden geçirir. Proje onaylandıktan sonra onay geçmişi proje detayındaki ayrı bir sekmede saklanır.

İzlenebilirlik: Kim, ne zaman, neye karar verdi?

Onay sürecinin asıl değeri, aylar sonra geriye dönüp bakıldığında ortaya çıkar. Bir müşteri şikâyeti, iç denetim ya da bir proje değerlendirmesi sırasında "bu işi kim onayladı, kaç kez iade edildi, testte ne bulundu?" soruları sorulur. HibritİK'te görev geçmişi; durum değişikliklerini, onay ve iade kararlarını, test sonuçlarını sırasıyla görev içinde saklar. Böylece ayrı bir tablo tutmadan işin tüm yolculuğunu takip edebilirsiniz.

Bu kayıtlar ekip içi öğrenme için de kullanılabilir. Sık iade edilen iş türleri, tanımların ya da kabul kriterlerinin baştan yeterince net yazılmadığını gösterebilir. Belirli bir aralıkla iade gerekçelerini gözden geçirmek, görev açma şablonlarınızı iyileştirmenin pratik bir yoludur. Görev değerlendirme ve başarı puanı ile ilişkisini merak ediyorsanız görev değerlendirme yazımıza göz atabilirsiniz.

Adım adım kurulum

1. İş türlerini ayırın: Hangi görevlerin yalnızca yönetici onayı, hangilerinin ayrıca test gerektirdiğini belirleyin.
2. Rolleri standartlaştırın: Onay gerektiren görev türlerinde yönetici rolünü zorunlu kabul edin.
3. Test sorumlularını belirleyin: Her ekipte test yapabilecek kişileri tanımlayın; işi yapan kişiyi kendi işinin test sorumlusu yapmayın.
4. İade kuralını yazın: İade gerekçesinin somut ve uygulanabilir olmasını ekip kuralı haline getirin.
5. Onay ritmi oluşturun: Yöneticiler için onay kuyruğunu günde bir veya iki kez kontrol etmeyi rutin yapın.
6. Proje taleplerini sihirbaza yönlendirin: E-postayla gelen proje fikirlerini standart talep akışına alın.

Sık yapılan hatalar

• Her göreve onay koymak: Basit işlerde onay adımı yalnızca bekleme süresi yaratır.
• Onay kuyruğunu biriktirmek: Bekleyen onaylar ekibin sonraki işlere geçmesini yavaşlatır.
• Gerekçesiz iade: Ne düzeltileceği belli değilse iş tekrar aynı şekilde geri gelir.
• Testi işi yapan kişiye bırakmak: Kendi işini test eden kişi hatayı görmekte zorlanır.

HibritİK ile onay ve test akışınızı kurun

Onay ve test süreçleri, HibritİK görev ve proje yönetimi modülünün bir parçasıdır. Rollerin temellerini görev yönetimi rehberimizde bulabilirsiniz. Kendi ekibinizle denemek için 14 gün ücretsiz deneyin.