Jira'da izin şeması ve rollerle kimin neyi göreceğini yönetmek

Jira'da yetki neden iki katmanlıdır?

Jira'da "kim neyi görebilir ve yapabilir" sorusu iki yapıyla yönetilir. Birincisi izin şemasıdır: projede hangi eylemlerin (projeyi görme, iş oluşturma, yorum ekleme, işi düzenleme, geçiş yapma, sprint yönetme gibi) kimlere verildiğini listeler. İkincisi roldür: şemada tek tek kişi yazmak yerine "geliştirici" ya da "proje yöneticisi" gibi yer tutucular kullanılır ve her proje bu yer tutucuları kendi kişileriyle doldurur.

Bu ayrım bakımı kolaylaştırır. Aynı izin şemasını birçok proje paylaşabilir, her projede roller farklı kişilere atanır. Yeni bir kişi projeye katıldığında şemaya dokunulmaz, yalnız kişi uygun role eklenir. Kişi ayrıldığında da roldan çıkarılması yeterlidir.

Bu sayfa, projelere göre kimin neyi göreceğini ve yapacağını nasıl yönetebileceğinizi anlatır. Jira yöneticisi mesleği ve iş akışı özelleştirme ayrı sayfalarda ele alınır; burada odak, şema ve rol mantığıdır.

İzin şeması neleri yönetir?

İzin şeması, proje düzeyindeki eylemleri gruplar, roller ve tek tek kişiler üzerinden verir. Bir proje yalnızca bir izin şemasına sahip olur ama bir şema birçok projede kullanılabilir. Bu nedenle şemada yapılan bir değişiklik, şemayı kullanan tüm projeleri etkiler. Değişiklik yapmadan önce kaç projenin etkileneceğine bakmak gerekir.

İzinler kabaca gruplanabilir: projeyi görme ve gezinme izinleri, iş oluşturma ve düzenleme izinleri, yorum ve ek izinleri, süre takibi ve sprint yönetimi gibi özel izinler. Bir izne kimin sahip olduğu, şemada o izin için listelenen role, gruba, kullanıcıya ya da bir iş alanına (örneğin atanan, bildiren) bağlıdır.

Alan tabanlı verme, role göre daha dinamiktir: "işi bildiren kişi kendi işine yorum ekleyebilsin" ya da "atanan kişi işi düzenleyebilsin" gibi kurallar şemaya alan üzerinden yazılır. Bu sayede kişi listesi tutmaya gerek kalmaz.

Önemli bir sınır: Jira alan düzeyinde izin tanımlamaz. Bir alanı belirli kişilerden gizlemek gerekiyorsa iş güvenlik düzeyleri gibi başka mekanizmalar düşünülmelidir.

Roller: grup mu rol mu?

Grup, Jira sitesi genelinde geçerlidir; rol ise proje bazında anlam taşır. Atlassian'ın önerdiği yaklaşım, izinleri tek tek kişilere değil rollere vermek ve kişileri projede rollere atamaktır. Böylece aynı şema, farklı güvenlik ihtiyacına sahip birden çok projede kullanılabilir.

Bir proje yöneticisi, kendi projesinin ayarlarındaki kişiler bölümünden rollere kişi ekleyebilir; şemayı değiştirmek için yönetici yetkisi gerekmez. Jira Cloud'un güncel belgeleri bu yer tutuculara alan rolleri (space roles) der: Jira yöneticisi rolü bir şemaya ekler, her proje bunu kendi kişileriyle doldurur. Bu roller şema dışında bildirim şemaları, iş güvenlik düzeyleri, iş akışı koşulları ve filtre ile pano erişiminde de kullanılabilir.

Grup ile rol arasındaki seçimi basit bir ilke yönlendirir: kurum genelinde sabit olan ekipler (tüm yazılımcılar, tüm yöneticiler) grup olarak tanımlanır; projeye göre değişen görevler rol olarak. Her ikisini birleştirmek de mümkündür: rola grup eklenir, böylece bir grubun tüm üyeleri aynı anda o rolü kazanır.

Adım adım: yeni bir proje için yetki kurmak

Önce projenin kimlere hangi ihtiyacı doğurduğunu yazın: kimler görecek, kimler iş açacak, kimler işleri düzenleyecek ve geçişleri yapacak, kimler projeyi yönetecek? Tablo basit olmalı; satırlarda eylem, sütunlarda roller bulunsun.

Sonra roller tanımlanır. Cloud yönetim ayarlarında rol oluşturulur, izin şemasında ilgili izinlere bu roller eklenir. İlk aşamada şemaya yalnız roller konur; kişiler ve gruplar eklenmez. Ardından projenin kişiler bölümünden kişiler rollere atanır.

Son olarak yetkiyi gerçek kullanıcılarla deneyin. Her rolden bir kişiyle projeyi açın: görmesi gereken görüyor mu, yapamaması gereken yapamıyor mu? Deneme, şemadaki eksikleri en hızlı gösterir. Düzen kurulduktan sonra rol-izin tablosunu bir Confluence sayfasında saklayın ve değişiklikleri o sayfaya işleyin.

Örnek: özel bir insan kaynakları projesi

Kurgusal bir örnek: bir şirket, işe alım süreçlerini Jira'da yönetmek istiyor ama adaylara ilişkin bilgilerin yalnız İK ekibince görülmesi gerekiyor. Ortak kullanılan izin şemasını değiştirmek diğer projeleri etkileyeceğinden, ekip projeye özel bir şema kullanmaya karar veriyor.

Mevcut şema kopyalanıyor. Kopyadaki bütün izinlere İK ekibi için tanımlanan rol ekleniyor ve diğer grup ve roller kaldırılıyor. Proje yöneticisi İK ekibini role ekliyor. Yönetici düzeyindeki bir kullanıcı proje kaydını görebilir ama içeriğe erişemez; erişmesi gerekiyorsa kendini role ekler. Bu, yönetici erişiminin bilinçli ve izlenebilir olmasını sağlar.

Son adımda ekip, hiçbir role bağlı olmayan bir kullanıcıyla projeyi açmayı dener ve erişemediğini doğrular. Atlassian'ın tanımladığı bu yaklaşım, özel projelerde paylaşılan şemanın yanlışlıkla bir kapı açık bırakmasını önler.

Sık yapılan hatalar

En yaygın hata, paylaşılan bir şemayı tek bir projenin ihtiyacı için değiştirmektir. Şemayı kullanan her proje etkilenir. Çözüm, şemayı kopyalayıp o projeye özel kullanmaktır.

İkinci hata, izinleri kişilere tek tek vermektir. Kişi sayısı büyüdükçe bakım imkânsızlaşır. Üçüncü hata, grupla rolü karıştırmaktır: tüm site için tanımlanan bir grubu proje düzeyinde ince ayar için kullanmak şemayı karmaşıklaştırır.

Dördüncü hata, bir sistem rolünü değiştirmeye çalışmaktır; bazı roller, örneğin uygulamaların erişimi için kullanılan rol, sistem tarafından yönetilir ve kullanıcılar tarafından değiştirilemez. Beşinci hata, kimin hangi role neden eklendiğini belgelememektir. Altıncı hata ise ayrılan kişileri rollerden çıkarmamaktır.

Bu beceriyi Mindset programlarında nerede çalışırsınız

Jira Eğitimi: Temel ve İleri Uygulama programındaki takım yönetimi ile takım yönetimli ve şirket yönetimli projelerin farkı, proje kurulumu ve yapılandırma ile kullanıcı arayüzü başlıkları, izin ve rol yapısının hangi proje türünde nasıl işlediğini anlamak için zemin oluşturur. Jira yöneticileri, proje yöneticileri ve ekip liderleri için uygundur.

İzin ayarları ve menü yolları Atlassian tarafından güncellenir; uygulamadan önce güncel belgeyi okumak ve önce test projesinde denemek önerilir.