Permission Scheme جیرا در مقیاس: چرا هر پروژه نباید طرح دسترسی خودش را داشته باشد

این الگو را تقریباً در هر محیط Jira که تحویل گرفته‌ام دیده‌ام: تعداد Permission Schemeها تقریباً برابر تعداد پروژه‌هاست. چهل پروژه، سی‌وهشت طرح دسترسی — که سی‌وپنج‌تایشان تقریباً یکی‌اند و کسی جرئت نمی‌کند دست بزند.

این وضعیت یک‌شبه ساخته نمی‌شود. هر بار یک پروژهٔ جدید ساخته می‌شود، یک نفر طرح موجود را کپی می‌کند («محض احتیاط، جدا باشد بهتره») و یک خط عوض می‌کند. هیچ‌کدام از این تصمیم‌ها به‌تنهایی اشتباه نیست؛ جمعشان فاجعه است.

هزینهٔ واقعی

ردیف دوم مهم‌ترین است. وقتی نتوانید به این سؤال ساده جواب بدهید، عملاً کنترل دسترسی ندارید — فقط توهم کنترل دارید.

قاعدهٔ اصلی: نقش بدهید، نه کاربر و نه گروه

این تک‌تصمیم، ریشهٔ مشکل را می‌خشکاند. Jira سه چیز را می‌تواند در طرح دسترسی بگیرد:

• کاربر مشخص — بدترین حالت. با هر جابه‌جایی نیرو باید طرح عوض شود.
• گروه — بهتر، ولی گروه سراسری است. یعنی برای هر پروژه که عضویت متفاوتی می‌خواهد، یک گروه جدید لازم می‌شود.
• Project Role — درست. نقش در طرح تعریف می‌شود، ولی عضویتش در هر پروژه جداست.

تفاوت گزینهٔ سوم همه‌چیز را عوض می‌کند: یک طرح واحد می‌گوید «نقش Developers می‌تواند Issue ببندد»، و بعد هر پروژه خودش تصمیم می‌گیرد چه کسی در آن نقش است. یک طرح، صد پروژه، صد ترکیب متفاوت از آدم‌ها.

اگر در Permission Scheme خود اسم یک آدم یا یک گروه را می‌بینید، آنجا یک بدهی فنی دارید که روزی باید صافش کنید.

چند طرح واقعاً لازم دارید

تجربهٔ من: بیشتر سازمان‌ها با سه تا چهار طرح راه می‌افتند.

1. داخلی باز — همهٔ کارمندان می‌بینند و Issue می‌سازند. برای پروژه‌های عمومی مثل درخواست IT.
2. تیم‌محور بسته — فقط اعضای نقش‌های پروژه دسترسی دارند. برای پروژه‌های محصول.
3. حساس — دسترسی محدود، معمولاً منابع انسانی یا حقوقی یا امنیت.
4. پورتال مشتری (JSM) — منطق دسترسی کاملاً متفاوتی دارد و باید جدا بماند.

اگر پروژه‌ای واقعاً در هیچ‌کدام نمی‌گنجد، اول بپرسید چرا. معمولاً جوابش این است که یک نیاز موقت، دائمی شده.

روش امن ادغام

ادغام طرح‌ها ریسک دارد: اگر اشتباه کنید، یک تیم صبح می‌آید و پروژه‌اش را نمی‌بیند. این ترتیب ریسک را تقریباً صفر می‌کند:

1. فهرست بگیرید. هر طرح، کدام پروژه‌ها از آن استفاده می‌کنند و دقیقاً چه تفاوتی با بقیه دارد.
2. خوشه‌بندی کنید. طرح‌های یکسان یا تقریباً یکسان را کنار هم بگذارید. معمولاً نصفشان کاملاً یکی‌اند.
3. طرح مقصد را بسازید. طرح موجود را عوض نکنید؛ یک طرح جدید بسازید تا مسیر برگشت باز بماند.
4. با کم‌ریسک‌ترین پروژه شروع کنید. یک پروژهٔ داخلی و کم‌اهمیت، نه پروژهٔ اصلی.
5. عضویت نقش‌ها را قبل از سوییچ پر کنید. این مهم‌ترین قدم است — اگر نقش‌ها خالی باشند، سوییچ یعنی قطع دسترسی همه.
6. سوییچ کنید و همان روز بررسی کنید. از چند کاربر واقعی بخواهید کارهای همیشگی‌شان را انجام دهند.
7. تکرار کنید. پروژه به پروژه، نه همه با هم.

دو تلهٔ رایج

تلهٔ Browse Projects

این دسترسی پایهٔ همه‌چیز است. اگر کسی Browse Projects نداشته باشد، هیچ‌کدام از دسترسی‌های دیگرش معنا ندارد — پروژه را اصلاً نمی‌بیند. وقتی کاربری می‌گوید «پروژه برام نمیاد»، اول همین را چک کنید، نه دسترسی‌های ریزتر را.

تلهٔ Issue Security

Issue Security Scheme لایه‌ای جدا و بالاتر از Permission Scheme است. کاربری می‌تواند در طرح دسترسی همه‌چیز داشته باشد ولی به خاطر یک سطح امنیتی روی Issue، آن را نبیند.

این باعث گیج‌کننده‌ترین تیکت‌های ادمینی می‌شود: «من دسترسی دارم ولی این Issue خاص را نمی‌بینم». اگر دسترسی‌ها درست به نظر می‌رسند و باز هم مشکل هست، سراغ Issue Security بروید.

نگه‌داشتن نظم بعد از تمیزکاری

تمیزکاری یک‌باره بی‌فایده است اگر شش ماه بعد دوباره سی طرح داشته باشید. سه قاعده کافی است:

• ساخت پروژه فرایند داشته باشد. پروژهٔ جدید از یک قالب مشخص با یکی از طرح‌های موجود ساخته شود.
• طرح جدید نیاز به دلیل مکتوب دارد. یک جمله کافی است: چرا هیچ‌کدام از طرح‌های موجود جواب نمی‌داد.
• بازبینی فصلی. یک بار در فصل، فهرست طرح‌ها و طرح‌های بی‌استفاده را نگاه کنید. ده دقیقه کار است.

جمع‌بندی

تعداد زیاد Permission Scheme علامت است، نه بیماری. بیماری این است که ساخت پروژه فرایند ندارد و هر کس راه خودش را می‌رود.

درمانش هم دو چیز است: نقش به‌جای کاربر و گروه، و فرایند مشخص برای پروژهٔ جدید. همان منطقی که در طراحی Workflow در Jira دربارهٔ یک Workflow مشترک برای چند پروژه گفتم، اینجا هم صدق می‌کند.

اگر می‌خواهید این بازبینی و ادغام روی محیط شما انجام شود بدون اینکه دسترسی کسی قطع شود، پیاده‌سازی و راه‌اندازی Jira شامل همین ساختاردهی است. برای اینکه ادمین داخلی‌تان خودش بتواند این تصمیم‌ها را بگیرد، دورهٔ جیرا ادمین همین سرفصل را عملی کار می‌کند.