Onay Süreci Yönetimi: Revizyon Döngüsünü Kısalt

Onay Süreci Yönetimi: Revizyon Döngüsünü Kısalt

Her startup ekibinde bir tablo vardır. Görevler 'Yapıldı' sütununa geçiyor ama iş bitmiyor. Tasarım onay bekliyor. Metin hukuk incelemesinde. Fiyatlandırma CEO'nun dönüşünü bekliyor. O dönüş bir türlü gelmiyor. Haftalar geçiyor. Onay bekleyen görevler birikiyor. Biri 'bu nerede kaldı?' diye soruyor. Cevap: 'sende.' Bu yazı, startup ekiplerinde onay ve revizyon döngülerinin neden darboğaza girdiğini ve görünürlük kurarak bu döngünün nasıl kısaltılabileceğini anlatıyor.

Darboğazın Anatomisi

Onay süreçleri başlangıçta zararsız görünür. Bir iş tamamlandığında birinin bakması mantıklıdır. Ama bu 'birinin bakması' adımı zaman içinde şişer ve sistematik bir tıkacı dönüşür. Neden şişer? Çünkü onay adımı genellikle belirsizdir. Belirsizlik şu sorularda kendini gösterir: Kim onaylayacak — tek kişi mi, birden fazla kişi mi? Ne zaman bakacak — bu hafta mı, gelecek hafta mı? Ne onaylıyor — tamamını mı, bir kısmını mı? Onaylamazsa ne olur — revizyon mu, iptal mi, farklı biri mi bakacak? Bu sorular cevaplanmadan iş 'onaya gönderildiğinde', aslında belirsiz bir bekleme alanına bırakılmış olur. Kim ne zaman bakacağı yazılı değildir. Onaylayacak kişi bunu ne zaman göreceğini bilmez. Bekleyen kişi ne kadar bekleyeceğini bilmez. Sonuç: onay bekleyen işler görünmez hale gelir ve görünmez şeyler ihmal edilir.

Gerçek Örnekler: Döngü Nerede Kopar?

Örnek 1: Pazarlama metninin sonsuz turu Growth ekibi bir landing page metni yazar. Ürün ekibine gönderir: 'Bir bak mısın?' Ürün ekibi bakar, iki değişiklik önerir. Growth düzeltir, tekrar gönderir. Bu sefer CEO'ya da sorarlar. CEO farklı bir ton önerir. Growth tekrar düzeltir. Hukuk ekibi KVKK ifadesine itiraz eder. Dörtüncü turda metin başladığından farklı bir şeye dönüşmüştür ve herkes yorulmuştur. Sorun metnin kötü olması değildir. Sorun şudur: her turda kimin ne onayladığı, hangi yorumun uygulandığı, neden uygulandığı — bunların hiçbiri kayıt altında değildir. Bir sonraki tur başladığında sıfırdan başlanır. Örnek 2: Özellik tasarımının limbo'su Ürün ekibi bir özelliğin tasarımını tamamlar. Slack'e atar: 'Figma linki burada, görüşlerinizi bekliyorum.' Üç kişi emoji atar. Biri 'güzel' yazar. Kimse resmi onay vermez. Geliştirici 'onaylandı mı?' diye sorar. Kimse emin değildir. İki gün kaybolur. Bu örnekte sorun iletişim eksikliği değildir. Herkes görmüştür. Sorun şudur: 'görmek' ile 'onaylamak' aynı eylem gibi muamele görmüştür. Slack emoji'si karar değildir. Örnek 3: CEO'nun gelen kutusu Küçük ekiplerde onaylar sıklıkla tek kişide toplanır: genellikle kurucu veya CEO. Fiyatlandırma değişikliği, müşteri teklifi, yeni iş birliği, basın bülteni — hepsi aynı kişinin onayını bekler. O kişi meşguldür ve her şey birikir. Bu durumda bireysel bir verimlilik sorunu gibi görünür ama değildir. Yapısal bir tasarım sorunudur: onay yetkisi dağıtılmamış, her karar en üste iletilmek zorundadır. Sonuç tahmin edilebilirdir.

Görünürlük Neden Çözümün Yarısıdır?

Onay darboğazlarını çözmek için genellikle iki yaklaşım denenir: daha fazla toplantı yapmak ya da kişilere doğrudan baskı uygulamak. İkisi de kısa vadede işe yarar gibi görünür ama sorunu çözmez, sadece erteler. Asıl sorun şudur: bekleyen işler görünmez olduğunda hiç kimse önceliklendirme yapmak zorunda kalmaz. Onayı geciktiren kişi 'bu iş bende bekliyor ve benim gecikmem tüm süreci bloke ediyor' bilgisine sahip değildir. Görünürlük bu denklemi değiştirir. Bir iş 'BEKLEMEDE' statüsüne geçtiğinde ve bu durum herkesin görebileceği bir yerde listelendiğinde, iki şey olur: onayı geciktiren kişi bunun görünür olduğunu bilir ve bekleyen kişi durumu takip edebilir, hatırlatma yapabilir. Bu küçük bir değişiklik gibi görünebilir ama davranışı gerçekten etkiler. Görünür şeyler ihmal edilmez.

Statü Sistemi: WAITING ve REVIEW Nasıl Çalışır?

İş takip sisteminde onay süreçlerini görünür kılmanın en basit yolu özel statüler kullanmaktır. İki statü özellikle kritiktir:

WAITING (Beklemede)

Bir iş tamamlanmış ama bir dış faktöre bağımlıdır: başka bir ekibin çıktısı, müşterinin kararı, tedarikçinin dönüşü. İş ilerleyemez çünkü kontrolün dışında bir şey bekleniyor. Bu statü şunu netleştirir: bu iş takılmış ama sorumlunun elinde değil. Haftalık toplantıda 'bu neden bitmedi?' sorusu sorulduğunda cevap açıktır: X'in dönüşü bekleniyor, şu tarihten beri. ,

REVIEW (İncelemede)

Bir iş tamamlanmış ve belirli bir kişinin incelemesini/onayını bekliyor. Kontrolün içinde ama henüz bitmemiş. Bu statünün değeri şuradadır: kim inceleyecek ve ne zamana kadar bekleniyor — bu bilgiler görevin üzerinde yazılıdır. 'İncelemede' statüsündeki işleri filtreleyen herhangi biri, o anda karar bekleyen tüm işleri tek ekranda görür. Statünün yanına şunlar eklenmeli • Onaylayacak kişinin adı — 'Ali inceleyecek' değil, görevin sahibi olarak Ali'nin adı. • Beklenen dönüş tarihi — 'bu hafta' değil, 'Perşembe'. • Ne onaylanıyor — 'bak mısın' değil, 'fiyatlandırma mantığını onayla' gibi net bir soru. Bu üç bilgi olmadan REVIEW statüsü yine boş bir bekleme alanına dönüşür.

Karar Kaydı: Neden Alındı, Kim Aldı?

Onay süreçlerinin ikinci büyük sorunu geçmişin kaybolmasıdır. Bir karar alınır, hayata geçirilir, sonra iki ay sonra biri 'neden böyle yaptık?' diye sorar. Kimse hatırlamaz. Slack'te kaybolan bir mesaj vardır muhtemelen ama bulunması mümkün değildir. Karar kaydı bu sorunu çözer. Basit bir pratiktir: bir karar alındığında ilgili görevin veya projenin üzerine şu bilgiler yazılır.

• Karar nedir? — net bir cümleyle.

• Kim aldı? — isim.

• Ne zaman alındı? — tarih.

• Neden alındı? — tek paragraf gerekçe.

• Alternatifler düşünüldü mü? — eğer önemliyse, evet ve neden reddedildi.

Bu format uzun değildir. Çoğu karar için beş-on satır yeterlidir. Ama bu beş-on satır altı ay sonra tartışmayı sona erdirir.

Örnek karar kaydı:

Fiyatlandırma sayfasında yıllık/aylık toggle kaldırıldı. Karar: Ahmet (CEO), 14 Mart. Gerekçe: A/B testi toggle'ın dönüşüm oranını %8 düşürdüğünü gösterdi. Aylık fiyat tek seçenek olarak sunulacak, yıllık indirim satış görüşmelerinde ayrıca sunulacak.

Bu not, altı ay sonra biri 'neden yıllık seçenek yok?' diye sorduğunda tek cümleyle yanıtlanabilir bir referans noktasıdır.

Revizyon Döngüsünü Kısaltmanın Pratik Adımları

1. Onay adımını işin başında tanımla

Bir görev oluşturulduğunda, onay adımı da tanımlanır. 'Bu iş tamamlandığında kim bakacak, ne onaylayacak, ne zamana kadar?' Bu sorular işin başında cevaplanmadan görev açılmaz. Bu adım küçük görünür ama büyük bir sonucu vardır: görev tamamlandığında herkes ne olacağını zaten bilir. 'Şimdi ne yapacağız?' sorusu ortadan kalkar.

2. Revizyonu sınırla

Her iş için kaç revizyon turu olacağını baştan belirle. İki tur standart, üçüncü tur istisnai, dördüncü tur yok. Bu kural oturduğunda yorumların kalitesi artar: biri yorum yapacaksa, sınırlı turlardan birini harcıyor demektir ve daha dikkatli düşünür. Sınırsız revizyon hakkı, sonsuz önemsiz yorum döngüsü doğurur.

3. 'Görmek' ile 'onaylamak'ı ayır

Slack'te emoji atmak onay değildir. İncelemek onay değildir. Onay, 'bu iş bu haliyle ilerleyebilir' kararının açıkça verilmesidir. Bu kararın yazılı olması gerekir — iş takip sisteminde, e-postada, nerede olursa olsun — ama bir yerde yazılı. Ekipte bu ayrım kültürel olarak yerleştiğinde 'onaylandı mı?' sorusu sorulmaz hale gelir. Ya onaylanmıştır ve yazılıdır, ya da onaylanmamıştır.

4. Bekleyen işleri haftalık gözden geçir

Her haftanın başında WAITING ve REVIEW statüsündeki işleri gözden geçir. Kaç gündür bekliyor? Beklenen dönüş tarihi geçti mi? Bloke eden faktör hâlâ geçerli mi? Bu beş dakikalık bir inceleme, aylarca limbo'da kalan işleri önler. Görünürlük olmadan bu inceleme yapılamaz; kimse hangi işlerin beklemede olduğunu bilmez.

5. Onay yetkisini dağıt

Her karar için CEO veya kurucuya gitmek zorunda değil. Hangi kararlar kimin onayıyla ilerleyebilir? Pazarlama metni için growth ekip lideri yeterliyse, bu açıkça tanımlanmalı. Tanımlanmadığında herkes her şeyi üste taşır ve darboğaz kaçınılmaz olur. Yetki matrisi karmaşık olmak zorunda değildir. 'X kararlarını Y alır, Z kararlarını kurucu alır' düzeyinde bile çok şey değişir.

Bu Yapı Alios'ta Nasıl Kurulur?

Adım 1: Özel statüleri ekle

WAITING ve REVIEW statüslerini iş takip sisteminize ekleyin. Varsayılan 'Yapıldı / Devam Ediyor / Tamamlandı' seçenekleri yeterli değildir. Onay süreçlerini görmek için bu ara statüler şarttır.

Adım 2: Her REVIEW görevine onaylayıcı ve tarih ekle

Bir iş REVIEW'a geçtiğinde görevin üstüne şunlar yazılır: kim inceleyecek, ne zaman dönmesi bekleniyor, ne onaylanıyor. Bu bilgiler olmayan REVIEW statüsü boş bir kategoriye dönüşür.

Adım 3: Karar notlarını göreve ekle

Bir onay tamamlandığında — kabul veya ret — bu karar görevin üstüne not olarak eklenir. Kimin, ne zaman, ne kararı aldığı. Bu notlar biriktiğinde proje geçmişi oluşur ve 'neden böyle yaptık?' sorusu her zaman yanıtlanabilir olur.

Adım 4: WAITING filtresini haftalık rutine ekle

Her Pazartesi, WAITING ve REVIEW filtresiyle açık işlere bakın. Kaç gündür bekliyor? Beş günden fazla bekleyen her iş için bir aksiyon tanımlayın: hatırlatma, yetki devri veya öncelik güncellemesi.

Sonuç: Onay Bir Eylem, Bekleme Bir Durum

Revizyon döngüleri şiştiğinde suçu genellikle insanlara atarız. 'Dönmüyor', 'meşgul', 'önceliklendiremiyor.' Bazen bu doğrudur. Ama çoğunlukla sistem onay sürecini görünmez kılmıştır ve görünmez şeyler ihmal edilir.

Çözüm daha fazla takip toplantısı değildir. Çözüm onay sürecini görünür kılmaktır: hangi işler beklemede, kimin elinde, ne zamandan beri, ne onaylanıyor. Bu bilgiler sistemde yazılı olduğunda hem onaylayan hem bekleyen hem de ekibin geri kalanı aynı gerçekliği görür.

Ve aynı gerçekliği gören ekipler çok daha hızlı karar alır.