پیاده‌سازی و راه‌اندازی جیرا (Jira) برای شرکت‌ها

ساختار پروژه، Issue Type، فیلد، Screen و دسترسی‌ها را از صفر طراحی می‌کنم — بر اساس فرایند شما، نه قالب پیش‌فرض Jira.

Deliverables

چیزی که در پایان تحویل می‌گیرید:

  • نقشهٔ ساختار پروژه‌ها و طرح نام‌گذاری
  • مجموعهٔ Issue Type با Screen و فیلدهای متناسب هر کدام
  • Permission Scheme و نقش‌های پروژه به‌صورت مستند
  • سند تحویل: چه چیزی کجا تنظیم شده و چرا

بیشتر شرکت‌هایی که سراغ من می‌آیند Jira را نصب کرده‌اند و شش ماه بعد به این نتیجه رسیده‌اند که «کار نمی‌کند». تقریباً هیچ‌وقت مشکل از نصب نیست. مشکل این است که ساختار پیش‌فرض Jira برای تیم آن‌ها طراحی نشده بود و کسی هم آن را عوض نکرد.

چرا راه‌اندازی پیش‌فرض معمولاً شکست می‌خورد

وقتی یک پروژهٔ جدید در Jira می‌سازید، ابزار یک قالب آماده به شما می‌دهد: چند Issue Type، یک Workflow ساده، و یک Permission Scheme باز. این قالب برای شروع خوب است و برای یک سازمان واقعی کافی نیست. سه اتفاق رایج می‌افتد:

  • فیلدهای سفارشی از کنترل خارج می‌شوند. هر تیم فیلد خودش را می‌سازد، اسم‌ها تکراری می‌شوند، و بعد از یک سال هفت فیلد مختلف با معنی «اولویت» دارید. در Jira Cloud این موضوع مستقیم روی سرعت جست‌وجو و بارگذاری فرم اثر می‌گذارد.
  • هر پروژه Workflow خودش را می‌گیرد. به‌جای سه Workflow مشترک، بیست Workflow تقریباً یکسان دارید که هیچ‌کس جرئت دست‌زدن به آن‌ها را ندارد.
  • دسترسی‌ها با گروه مدیریت می‌شوند، نه با نقش پروژه. نتیجه این است که برای هر تغییر کوچک باید سراغ ادمین سیستم بروید.

کاری که در پیاده‌سازی انجام می‌شود

  1. تعیین مرز پروژه‌ها. اول مشخص می‌کنیم واحد کار شما چیست: تیم، محصول، یا مشتری. این یک تصمیم است، نه یک تنظیم — و بعداً عوض‌کردنش گران است.
  2. طراحی Issue Type بر اساس چیزی که واقعاً فرق دارد. اگر دو نوع کار Workflow و فیلد یکسانی دارند، دو Issue Type نمی‌خواهند. تعداد کم و معنادار بهتر از فهرست بلند است.
  3. طراحی Screen برای هر مرحله. Jira اجازه می‌دهد فرم ساخت، ویرایش و نمایش متفاوت باشند. استفاده‌نکردن از این قابلیت، همان چیزی است که فرم‌های ۲۰ فیلدی و ناقص می‌سازد.
  4. Permission Scheme با نقش پروژه. دسترسی به نقش داده می‌شود و عضو نقش را مدیر پروژه تعیین می‌کند. با این کار ادمین سیستم از مسیر روزمره خارج می‌شود.
  5. مستندسازی. هر تصمیم با دلیلش نوشته می‌شود، معمولاً در Confluence. بدون این، شش ماه بعد کسی نمی‌داند چرا یک وضعیت وجود دارد و آن را پاک می‌کند.

Cloud یا Data Center؟

تصمیم بین Jira Cloud و Jira Data Center برای شرکت‌های ایرانی معمولاً تصمیم فنی نیست؛ تصمیم دسترسی و تحریم است. هر دو را می‌شود کانفیگ کرد، ولی محدودیت‌ها فرق دارند: در Cloud به Automation داخلی، JSM و مارکت‌پلیس دسترسی دارید ولی سقف custom field و اجرای قوانین محدود است. در Data Center کنترل کامل دارید و در عوض نگهداری، بکاپ و ارتقا روی دوش خودتان است. در جلسهٔ اول همین را روشن می‌کنیم چون بقیهٔ طراحی به آن وابسته است. مقایسهٔ کامل دو نسخه با چک‌لیست تصمیم را در Jira Cloud یا Data Center؟ نوشته‌ام.

چه زمانی این خدمت مناسب شماست

  • تازه می‌خواهید Jira را بیاورید و نمی‌خواهید دو سال بعد مجبور به بازسازی شوید.
  • Jira دارید ولی عملاً به‌عنوان یک لیست کار استفاده می‌شود و هیچ گزارشی از آن درنمی‌آید.
  • چند تیم دارید که هر کدام ساختار خودش را ساخته و حالا مقایسه‌شان غیرممکن است.

می‌خواهید این را روی محیط خودتان ببینید؟

جلسهٔ اول ۳۰ دقیقه است و هزینه‌ای ندارد. اگر مسئلهٔ شما در حوزهٔ من نباشد، همان‌جا می‌گویم.

درخواست جلسه

خدمات مرتبط

درخواست جلسهتماس