Onay kapısı bir eylemin durup durmayacağını belirler. Durduktan sonra kimin karar vereceğini ise belirlemez. Pek çok ekipte bu ikinci soru kendiliğinden çözülür: bildirimi ilk gören kişi düğmeye basar. Bu düzen, düğmeye basan kişinin onaylanan şey üzerinde hiçbir yetkisi olmadığı ana ya da bir yerde verilen onayın sessizce başka bir yerde de geçerli sayıldığı ana kadar işler. Onay sorumluluğu, kapının kendisi kadar bilinçli bir tasarımı hak eder.
Şirket sınırıyla başlayın
En dıştaki çizgi şirkettir. İş, bellek, dosyalar ve kimlik bilgileri tek bir şirkete aittir; o şirket içinde verilen bir kararın dışarıda hiçbir ağırlığı olmamalıdır. Bu, onu sınayan durumlarla karşılaşana kadar apaçık görünür: iki müşteri çalışma alanına birden üye olan bir danışman, birkaç marka için iş yürüten bir ajans, bağlı şirketler arasında geçiş yapan bir çalışan. Aynı kişi bir şirkette meşru bir onaylayıcı, diğerinde ise bir yabancı olabilir. Karar, onu veren kişiyle değil, verildiği şirketle birlikte hareket etmelidir.
GoCux şirketi iş, bellek, dosya ve kimlik bilgileri için sınır olarak ele alır. Bir şirket içinde verilen evet, başka bir şirkette hiçbir şey ifade etmez.
Projeler kapsamı daraltır
Şirketin içindeki bir alt kapsam projedir. Projeler müşteri dosyalarını, ürün hatlarını ya da ekipleri birbirinden ayırır ve onay kurallarının çoğunun yaşaması gereken yer de burasıdır. Finans projesinden bir dışa aktarmayı onaylayabilen biri, bu sayede hukuk projesinden dışa aktarmayı onaylama hakkı kazanmış olmaz. Onay kurallarını genel olarak kişi bazında değil, proje ve eylem türü bazında yazın.
Üye, başlatan ve onaylayan farklı görevlerdir
İnsanların çoğu zaman tek bir şeymiş gibi düşündüğü üç konuyu ayırmak işe yarar:
- İşi kimin görebildiği. Bir projeye üyelik, iş emirlerini, sonuçları ve kanıtları okumayı sağlar.
- İşi kimin başlatabildiği. Bir iş emrini başlatmak, onun hedefini, kapsamını ve sınırlarını belirlemektir.
- Sonuç doğuran adımlara kimin karar verebildiği. Bir gönderimi, dışa aktarmayı ya da silmeyi onaylamak.
Bunlar kesişir ama aynı olmamalıdır. Makul bir başlangıç noktası şöyle görünebilir:
| Eylem | Makul bir onaylayıcı |
|---|---|
| Başlatanın kendisinin istediği bir taslağı göndermek | İşi başlatan kişi |
| Proje dosyalarını dışa aktarmak | O projenin verisinden sorumlu biri |
| Kayıt silmek | Kayıtların bulunduğu sistemin sahibi; tek başına işi başlatan değil |
| Tekrarlı iş zamanlamak | Harcanacak bütçenin sahibi |
| Bir ajanın talimatlarını değiştirmek | Değişikliği öneren kişiden başka biri |
Kalıp basittir. Bir eylem başlatanın kendi işinin ötesine ne kadar uzanıyorsa, onaylayan kişinin de uzandığı alan üzerinde o kadar yetkili olması gerekir.
Bir yüzeydeki erişim, başka bir yüzeyde izin değildir
Onayın en sessiz bozulma biçimi çıkarımdır. Birinin bir şeye erişimi vardır ve sistem ya da ekip bunu komşu bir şey için izin sayar. Sık görülen örnekler:
- Bir sistem için kimlik bilgisi verilmiştir. Bu, bir ajanın oraya gözetimsiz yazabileceği anlamına gelmez.
- Bir bağlayıcı kaydedilmiştir. Bu, her görevin onu kullanabileceği anlamına gelmez.
- Bir istemcide MCP sunucusu yapılandırılmıştır. Bu onu her iş için yetkili kılmaz.
- Bir beceri kurulmuştur. Yeniden kullanılabilir bir talimat, yetki devri değildir.
- Bir kişi bir e-postayı onaylamıştır. Bu ne bir sonraki e-postayı ne de aynı e-postanın düzeltilmiş hâlini onaylar.
- Biri, ajanın yazdığı sistemde yöneticidir. Bu onu çalışma alanınızdaki ajan işleri için onaylayıcı yapmaz.
Bunların her biri ayrı ve açık bir karar olmalıdır. Bağlayıcı tarafını yetkiyi genişletmeden araç bağlamak yazısı daha ayrıntılı ele alıyor.
Onay sorumluluğunu tasarlamak
- Her eylem ve proje için bir kişi ya da küçük bir rol adlandırın. “Ekip” bir onaylayıcı değildir. Herkesin tıklayabildiği bir grup, zamanla herkesin isteği başkasının okuduğunu varsaydığı bir gruba dönüşür.
- Yokluğu planlayın. Onaylayıcı ortada yoksa iş, o an çevrimiçi olan kişiye yönlenmemeli, beklemelidir. Yedek kişiyi önceden belirleyin.
- Kendi kendini onaylamaya açıkça karar verin. Başlatanın kendi gönderimini onaylaması çoğu zaman sorun değildir. Kendi silme işlemini ya da talimat değişikliğini onaylaması ise genellikle sorundur.
- Yürütme anında yeniden kontrol edin. Yetki, karar ile kapsadığı eylem arasında değişebilir. Kontrol yalnızca düğmeye basıldığı anda değil, eylemin çalıştığı anda da yapılmalıdır.
- Kimin karar verdiğini ve ne gördüğünü kaydedin. Sonradan izini süremediğiniz sorumluluk, sorumluluk değildir. Ayrıntı için bir ajan denetim izi neyi kaydetmeli yazısına bakın.
GoCux'ta bu nasıl görünür
GoCux'ta kısa bir eylem sınıfı listesi ekipten birinin kararı için durur; geri kalan her şey iş için belirlenen sınırlar içinde yürür. Bir iş emri karar beklerken ondan sonra gelen hiçbir adım başlamaz. Her karar yalnızca verildiği girişim için geçerlidir ve eylem yürütüldüğünde yeniden kontrol edilir; kararlar işin kaydında makbuz olarak saklanır. Projeler şirket içindeki kapsamlardır; kimlik bilgileri tarayıcıda değil, sunucuda referans olarak durur. Rollerin bu izinlere nasıl karşılık geldiği roller ve izinler belgesinde anlatılıyor; genel çerçeve için yönetişim sayfasına bakabilirsiniz.
Onayları açmadan önce netleştirilecek sorular
- Her projede, sonuç doğuran her eylem sınıfını kim onaylayabilir?
- Yedek kim ve ikisi de yoksa bekleyen işe ne olur?
- Kendi kendini onaylamaya nerede izin var, nerede yok?
- Her proje hangi kimlik bilgilerini, bağlayıcıları ve becerileri kullanıyor; her biri bu kullanım için ayrıca onaylandı mı?
- Her onayın izi tek bir şirkete, tek bir projeye, tek bir girişime ve tek bir kişiye sürülebiliyor mu?
Neyin durması gerektiğine hâlâ karar veriyorsanız ajanlar neden önce sormalı yazısıyla başlayın.
Bu iş akışını çalışma alanınıza taşıyın.
Kapsamı belirleyin. Kanıtları inceleyin. Gereken adımları onaylayın.