پیاده سازی جیرا برای تیم های غیر فنی (HR، مالی، فروش و…)

چطور Jira را برای تیم‌های غیر فنی (HR، مالی، فروش و…) پیاده‌سازی کنیم؟

وقتی نام Jira را می‌شنویم، معمولاً ذهنمان به سمت تیم‌های توسعه نرم‌افزار، Sprint، Bug و Workflowهای فنی می‌رود. بااین‌حال، Jira فقط برای برنامه‌نویس‌ها ساخته نشده است. سازمان‌ها می‌توانند از Jira برای مدیریت کارهای منابع انسانی، مالی، فروش، بازاریابی، عملیات، حقوقی و حتی فرآیندهای داخلی استفاده کنند. Atlassian نیز برای تیم‌های غیر فنی قالب‌ها و سناریوهای مشخصی مانند منابع انسانی، مالی، فروش و عملیات ارائه می‌دهد.

بااین‌حال، یک مشکل رایج وجود دارد: بسیاری از سازمان‌ها Jira را برای تیم غیر فنی دقیقاً مانند تیم توسعه تنظیم می‌کنند. سپس همان ساختارهای پیچیده را به HR یا واحد مالی تحمیل می‌کنند. در نتیجه، کاربران احساس می‌کنند Jira ابزار فنی و دشواری است؛ درحالی‌که مشکل اصلی از طراحی نادرست فرآیند شروع می‌شود.

در این راهنما، از همین نقطه شروع می‌کنیم و قدم‌به‌قدم توضیح می‌دهیم چطور Jira را برای تیم‌های غیر فنی پیاده‌سازی کنیم تا هم استفاده از آن ساده باشد و هم سازمان بتواند کنترل، گزارش‌گیری و اتوماسیون مناسبی داشته باشد.

چرا Jira برای تیم‌های غیر فنی مناسب است؟

هر تیم، صرف‌نظر از نوع فعالیتش، مجموعه‌ای از کارها، مسئولیت‌ها و فرآیندهای قابل پیگیری دارد. برای مثال، واحد منابع انسانی درخواست استخدام را از مرحله نیازسنجی تا پذیرش نیروی جدید دنبال می‌کند. از طرف دیگر، واحد مالی ممکن است خرید داخلی، بررسی فاکتور و تأیید پرداخت را مدیریت کند. همچنین تیم فروش باید سرنخ‌ها را تا مرحله قرارداد پیگیری کند.

در همه این مثال‌ها یک الگوی مشترک وجود دارد:

درخواست → بررسی → انجام کار → تأیید → تکمیل

Jira همین الگو را به یک سیستم قابل اندازه‌گیری تبدیل می‌کند.

علاوه بر این، Jira به هر تیم اجازه می‌دهد Workflow، Work Type، Field، Permission و Dashboard متناسب با نیاز خودش داشته باشد. در نسخه‌های Cloud، Atlassian حتی قالب‌های آماده برای تیم‌های HR، Finance، Sales، Marketing، Operations و Legal ارائه می‌کند.

مهم‌ترین تفاوت Jira برای تیم فنی و غیر فنی

قبل از پیاده‌سازی، باید یک اصل مهم را در نظر بگیرید:

تیم غیر فنی به Jira نرم‌افزاری نیاز ندارد؛ به Jira متناسب با فرآیند خودش نیاز دارد.

برای یک تیم توسعه ممکن است این Workflow مناسب باشد:

To Do → In Progress → Code Review → Testing → Done

اما همین ساختار برای واحد مالی منطقی نیست.

برای مثال، تیم مالی می‌تواند چنین فرآیندی داشته باشد:

درخواست خرید → بررسی مالی → تأیید مدیر → خرید → ثبت فاکتور → پرداخت → تکمیل

بنابراین، بهتر است ابتدا فرآیند واقعی تیم را طراحی کنید و سپس Jira را با آن هماهنگ کنید.

---

مرحله اول؛ قبل از ساخت پروژه، فرآیند را روی کاغذ مشخص کنید

یکی از مهم‌ترین اشتباهات سازمان‌ها این است که بلافاصله وارد Jira می‌شوند و شروع به ساخت Project، Status و Field می‌کنند.

ابتدا با اعضای همان واحد جلسه کوتاهی برگزار کنید و به پنج سؤال پاسخ دهید:

چه چیزی وارد فرآیند می‌شود؟

مثلاً:

• درخواست استخدام
• درخواست خرید
• سرنخ فروش
• درخواست مرخصی
• درخواست پرداخت
• درخواست تجهیزات

چه کسی آن را ثبت می‌کند؟

ممکن است کارمند، مدیر، مشتری داخلی یا خود تیم مربوطه درخواست را ثبت کند.

چه کسی آن را بررسی می‌کند؟

این شخص می‌تواند HR Manager، مدیر مالی، مدیر فروش یا مسئول واحد باشد.

چه مراحلی را طی می‌کند؟

در این بخش Workflow واقعی را استخراج کنید.

چه زمانی می‌توانیم درخواست را Done بدانیم؟

این سؤال بسیار مهم است؛ زیرا بسیاری از Workflowهای Jira به دلیل تعریف مبهم وضعیت نهایی، گزارش دقیقی تولید نمی‌کنند.

مرحله دوم؛ برای هر واحد Project یا Space مناسب ایجاد کنید

Jira می‌تواند کار تیم‌ها را در فضاهای جداگانه سازمان‌دهی کند و هر فضا Work Item، Workflow، Board و تنظیمات خودش را داشته باشد. Atlassian در نسخه Cloud بین Team-managed و Company-managed تفاوت مشخصی قائل می‌شود: Team-managed استقلال و سادگی بیشتری دارد، درحالی‌که Company-managed برای استانداردسازی بین چند تیم و کنترل متمرکز مناسب‌تر است.

برای سازمان‌های بزرگ معمولاً بهتر است قبل از ایجاد Projectهای متعدد، یک معماری مشخص تعریف کنید.

برای مثال:

HR

• Recruitment
• Employee Requests
• Onboarding

Finance

• Purchase Requests
• Payment Requests
• Budget Requests

Sales

• Leads
• Opportunities
• Customer Requests

Operations

• Internal Requests
• Facilities
• Procurement

این ساختار به شما کمک می‌کند Permissionها، گزارش‌ها و Workflowها را منطقی‌تر مدیریت کنید.

Team-managed یا Company-managed؟

این تصمیم یکی از مهم‌ترین تصمیم‌های Jira Admin است.

اگر تیم کوچک است و می‌خواهد سریع شروع کند، Team-managed معمولاً انتخاب ساده‌تری است. این مدل تنظیمات مستقل‌تری دارد و تغییرات آن روی پروژه‌های دیگر اثر نمی‌گذارد.

اما اگر سازمان می‌خواهد چند واحد را با استاندارد مشترک مدیریت کند، Company-managed انتخاب مناسب‌تری است. در این مدل Jira Admin می‌تواند Workflowها، Permissionها، Screenها و سایر تنظیمات مشترک را استاندارد کند.

برای مثال، اگر سازمان شما ۱۰ واحد دارد و می‌خواهد همه درخواست‌ها یک مدل Permission و Reporting داشته باشند، مدیریت متمرکز ارزش بیشتری ایجاد می‌کند.

مرحله سوم؛ Work Typeها را ساده نگه دارید

برای تیم‌های غیر فنی لازم نیست از همان روز اول ده‌ها Work Type ایجاد کنید.

در بیشتر موارد، این چند نوع کافی هستند:

• Request
• Task
• Approval
• Incident
• Employee Request

برای مثال، در HR بهتر است به‌جای استفاده از اصطلاح‌هایی مانند Epic، Story و Bug، از اصطلاح‌هایی استفاده کنید که کاربر با آن‌ها آشناست.

این تغییر کوچک، تجربه کاربری را به‌طور محسوسی بهتر می‌کند.

مرحله چهارم؛ Workflow را از روی فرآیند واقعی طراحی کنید

Workflow باید فرآیند واقعی تیم را نشان دهد، نه اینکه صرفاً زیبا یا پیچیده باشد.

 

نمونه Workflow برای HR

فرض کنید می‌خواهیم فرآیند استخدام را در Jira طراحی کنیم:

درخواست جذب → بررسی HR → تأیید مدیر → انتشار فرصت → غربالگری → مصاحبه → تصمیم نهایی → استخدام

Atlassian نیز برای HR قالب‌هایی ارائه می‌کند که فرآیند استخدام را از ثبت متقاضی تا غربالگری، مصاحبه، تصمیم درباره پیشنهاد و پذیرش یا رد دنبال می‌کنند.

بنابراین، شما می‌توانید همین ساختار را متناسب با فرآیند داخلی خودتان ساده‌تر یا کامل‌تر کنید.

 

نمونه Workflow برای واحد مالی

برای واحد مالی می‌توانید چنین ساختاری ایجاد کنید:

ثبت درخواست → بررسی اطلاعات → بررسی بودجه → تأیید مدیر → تأیید مالی → پرداخت → تکمیل

در این Workflow می‌توانید Rules مشخصی نیز تعریف کنید.

مثلاً:

اگر مبلغ درخواست بیشتر از یک سقف مشخص باشد، کار باید وارد مرحله تأیید مدیر ارشد شود.

به این ترتیب، Jira فقط وضعیت کار را نشان نمی‌دهد؛ بلکه فرآیند کنترل سازمان را نیز اجرا می‌کند.

 

نمونه Workflow برای تیم فروش

در فروش بهتر است Workflow را براساس مرحله واقعی فرصت طراحی کنید:

Lead → بررسی اولیه → Qualified → مذاکره → Proposal → قرارداد → Won / Lost

سپس می‌توانید برای هر مرحله اطلاعات موردنیاز را ثبت کنید.

برای مثال:

• نام مشتری
• صنعت
• ارزش قرارداد
• مسئول فروش
• تاریخ پیگیری بعدی
• احتمال موفقیت
• محصول موردنظر

Atlassian نیز برای تیم‌های فروش قالب Lead Tracking ارائه می‌کند تا مراحل فروش را از پیگیری اولیه تا بسته شدن فرصت مدیریت کنند.

مرحله پنجم؛ فقط Fieldهای لازم را ایجاد کنید

یکی از بزرگ‌ترین مشکلات پیاده‌سازی Jira در سازمان‌ها، تعداد زیاد Custom Field است.

برای هر فرآیند ابتدا از خودتان بپرسید:

آیا واقعاً به این اطلاعات نیاز داریم؟

برای مثال، برای درخواست خرید شاید این Fieldها کافی باشند:

• درخواست‌کننده
• واحد
• مبلغ
• نوع خرید
• مرکز هزینه
• اولویت
• تاریخ موردنیاز
• توضیحات

در مقابل، اگر ۲۰ Field اجباری روی فرم قرار دهید، کاربر به‌جای اینکه Jira را ابزار ساده‌ای برای ثبت درخواست ببیند، آن را یک فرم اداری پیچیده تصور می‌کند.

بنابراین، حداقل اطلاعات لازم را جمع‌آوری کنید و فقط زمانی Field جدید اضافه کنید که فرآیند واقعاً به آن نیاز داشته باشد.

مرحله ششم؛ فرم ثبت درخواست را ساده طراحی کنید

کاربر غیر فنی معمولاً نمی‌خواهد بداند Issue Type چیست یا چرا باید بین چند Status انتخاب کند.

او فقط می‌خواهد درخواستش را ثبت کند.

پس فرم را بر اساس زبان همان تیم طراحی کنید.

برای مثال:

عنوان درخواست

نوع درخواست

مبلغ

دلیل درخواست

تاریخ موردنیاز

پیوست

و در پشت صحنه، Jira می‌تواند Workflow، Permission و Automation را مدیریت کند.

مرحله هفتم؛ Approval را وارد فرآیند کنید

بسیاری از فرآیندهای سازمانی بدون تأیید کامل نمی‌شوند.

برای مثال:

درخواست خرید → تأیید مدیر → تأیید مالی → پرداخت

یا:

درخواست استخدام → تأیید مدیر واحد → تأیید HR → انتشار موقعیت

Jira می‌تواند مرحله Approval را در Workflow قرار دهد. در Jira Cloud، Business Spaceها امکان تعریف Approval در Workflow را دارند و این قابلیت در سطوح مشخصی از Cloud در دسترس است.

در Jira Data Center، اگر نیاز به Approvalهای پیچیده دارید، می‌توانید آن فرآیند را با Workflow، Condition، Validator و افزونه‌هایی مانند ScriptRunner پیاده‌سازی کنید.

مرحله هشتم؛ Automation را از همان ابتدا طراحی کنید

وقتی تیم غیر فنی وارد Jira می‌شود، Automation یکی از ارزشمندترین قابلیت‌هاست.

برای مثال در HR:

وقتی درخواست به مرحله مصاحبه رسید، مسئول مصاحبه به‌صورت خودکار Assign شود.

در مالی:

وقتی مدیر درخواست را تأیید کرد، Issue به تیم مالی منتقل شود.

در فروش:

وقتی فرصت به مرحله Proposal رسید، یک Task برای ارسال پیشنهاد قیمت ایجاد شود.

در عملیات:

وقتی درخواست جدید ایجاد شد، براساس نوع درخواست آن را به تیم مربوطه Assign کنید.

Jira برای برخی سناریوهای Workflow نیز قوانین آماده دارد؛ برای مثال Jira می‌تواند با تغییر Status، Assignee را به‌صورت خودکار تغییر دهد.

مرحله نهم؛ Permissionها را از ابتدا استاندارد کنید

در سازمان‌های غیر فنی، امنیت داده اهمیت زیادی دارد.

برای مثال، ممکن است واحد HR اطلاعات محرمانه کارکنان را در Jira نگهداری کند. بنابراین نباید هر کاربری بتواند این اطلاعات را مشاهده کند.

بهتر است دسترسی‌ها را براساس Role و گروه سازمانی طراحی کنید.

برای نمونه:

مدیریت دسترسی در Jira برای تیم منابع انسانی (HR)

در واحد منابع انسانی، HR Agent می‌تواند درخواست‌های کارکنان را مشاهده و مدیریت کند و مسئولیت پیگیری فرآیندها را بر عهده داشته باشد.

از سوی دیگر، HR Manager باید دسترسی کامل‌تری به پروژه داشته باشد تا بتواند درخواست‌ها، فرآیندها و عملکرد تیم را مدیریت و بررسی کند.

برای کارکنان نیز بهتر است دسترسی محدود باشد؛ به‌طوری‌که هر Employee فقط درخواست‌های مربوط به خودش را ثبت و مشاهده کند و به اطلاعات سایر کارکنان دسترسی نداشته باشد.

مدیریت دسترسی در Jira برای واحد مالی (Finance)

در بخش مالی، Finance Agent وظیفه مدیریت و پیگیری درخواست‌های مالی را بر عهده دارد و باید بتواند درخواست‌ها را در مراحل مختلف Workflow بررسی کند.

در مرحله تأیید، Finance Manager به سطح دسترسی بالاتری نیاز دارد تا درخواست‌های مالی را بررسی و تأیید کند و در صورت نیاز، آن‌ها را به مرحله بعدی فرآیند بفرستد.

کارمندان سازمان نیز می‌توانند درخواست‌های مالی خود را در Jira ثبت کنند و وضعیت همان درخواست‌ها را مشاهده کنند؛ بنابراین Employee نباید به اطلاعات مالی سایر کارکنان دسترسی داشته باشد.

این مدل بسیار بهتر از ایجاد Permissionهای اختصاصی برای تک‌تک کاربران عمل می‌کند.

مرحله دهم؛ Dashboard مناسب هر تیم بسازید

هر تیم باید Dashboard خودش را داشته باشد.

Dashboard منابع انسانی

می‌تواند شامل این موارد باشد:

• درخواست‌های جدید
• درخواست‌های در انتظار بررسی
• تعداد استخدام‌های فعال
• درخواست‌های عقب‌افتاده
• میانگین زمان استخدام

Dashboard مالی

برای مثال:

• درخواست‌های در انتظار تأیید
• مبلغ کل درخواست‌ها
• خریدهای تکمیل‌شده
• درخواست‌های عقب‌افتاده
• درخواست‌ها براساس واحد

Dashboard فروش

می‌تواند موارد زیر را نشان دهد:

• Leads جدید
• فرصت‌های فعال
• فرصت‌های نزدیک به قرارداد
• فرصت‌های Lost
• ارزش Pipeline

در نتیجه، هر مدیر به‌جای بررسی دستی صدها Issue، اطلاعات موردنیاز خود را در یک صفحه می‌بیند.

مرحله یازدهم؛ SLA و زمان پاسخ را مشخص کنید

اگر تیمی با حجم زیادی از درخواست‌ها کار می‌کند، فقط دانستن وضعیت کافی نیست.

باید بدانیم:

چه مدت طول کشید؟

برای مثال:

• HR باید درخواست استخدام را حداکثر در دو روز بررسی کند.
• مالی باید درخواست خرید را ظرف یک روز بررسی کند.
• فروش باید Lead جدید را در چهار ساعت پیگیری کند.

با ثبت این زمان‌ها، سازمان می‌تواند عملکرد واقعی فرآیند را اندازه‌گیری کند.

در این مرحله می‌توانید از Dashboard، Automation، گزارش‌ها یا Jira Service Management استفاده کنید؛ مخصوصاً زمانی که فرآیند ماهیت Service Desk دارد.

مرحله دوازدهم؛ Jira را به ابزارهای دیگر متصل کنید

تیم‌های غیر فنی معمولاً در ابزارهای مختلف کار می‌کنند.

برای مثال:

• HR در سیستم منابع انسانی
• مالی در ERP
• فروش در CRM
• سازمان در Microsoft 365 یا Google Workspace

بنابراین، بهتر است Jira را به‌عنوان بخشی از اکوسیستم سازمان ببینید، نه یک نرم‌افزار جدا.

برای مثال، می‌توانید Jira را با GitLab برای تیم توسعه، ابزارهای ارتباطی برای اعلان‌ها و سیستم‌های داخلی از طریق API یا Webhook یکپارچه کنید.

اگر Data Center دارید، این بخش اهمیت بیشتری پیدا می‌کند؛ زیرا معمولاً به Integrationهای اختصاصی و APIهای سازمان نیاز دارید.

---

برای کسب اطلاعات تخصصی راجع به خدمات مشاوره ما در نصب جیرا به مطلب زیر مراجعه فرمایید:
نصب و راه اندازی جیرا

پیاده‌سازی Jira برای HR؛ یک مثال کامل

فرض کنید می‌خواهیم فرآیند استخدام را برای یک شرکت ایرانی در Jira پیاده کنیم.

Work Type

Recruitment Request

Fieldها

• عنوان موقعیت
• واحد درخواست‌کننده
• تعداد نیرو
• نوع همکاری
• محل کار
• بودجه
• تاریخ موردنیاز
• توضیحات

Workflow

ثبت درخواست → بررسی HR → تأیید مدیر → انتشار → غربالگری → مصاحبه → پیشنهاد → استخدام / رد

Automation

پس از ورود به مرحله مصاحبه:

Assign → HR Specialist

پس از تأیید:

Create Task → تهیه قرارداد

پس از استخدام:

Create Task → Onboarding

Dashboard

• موقعیت‌های فعال
• مصاحبه‌های این هفته
• درخواست‌های معطل
• استخدام‌های تکمیل‌شده
• میانگین زمان استخدام

در نتیجه، HR بدون اینکه با مفاهیم فنی Jira درگیر شود، یک سیستم کامل مدیریت استخدام خواهد داشت.

پیاده‌سازی Jira برای مالی؛ یک مثال عملی

حالا فرض کنید واحد مالی می‌خواهد درخواست‌های خرید را مدیریت کند.

Workflow

ثبت درخواست → بررسی اطلاعات → بررسی بودجه → تأیید مدیر → تأیید مالی → پرداخت → تکمیل

Automation

اگر مبلغ از سقف مشخصی بیشتر بود:

Create Approval → مدیر ارشد

اگر تأیید انجام شد:

Assign → واحد مالی

پس از پرداخت:

Transition → Done

Dashboard

• درخواست‌های در انتظار تأیید
• درخواست‌های پرداخت‌نشده
• درخواست‌های عقب‌افتاده
• مجموع مبالغ
• عملکرد هر واحد

این مدل، فرآیند را شفاف‌تر می‌کند و نقاط تأخیر را نیز سریع‌تر نشان می‌دهد.

پیاده‌سازی Jira برای فروش؛ یک مثال عملی

در فروش، استفاده از Jira بیشتر برای فرآیندهای Lead و Opportunity مناسب است.

برای مثال:

Lead جدید → Qualification → Discovery → Proposal → Negotiation → Won / Lost

در هر مرحله می‌توانید اطلاعات موردنیاز را ثبت کنید و در پایان، Dashboard فروش را با شاخص‌هایی مانند تعداد Lead، ارزش فرصت‌ها، نرخ تبدیل و فرصت‌های معطل بسازید.

بااین‌حال، اگر سازمان شما به یک CRM کامل با قابلیت‌هایی مانند مدیریت تماس‌ها، ایمیل‌ها، کمپین‌ها و پیش‌بینی فروش نیاز دارد، نباید Jira را بدون بررسی جایگزین CRM تخصصی کنید. بهتر است ابتدا مشخص کنید Jira دقیقاً کدام بخش فرآیند فروش را مدیریت خواهد کرد.

برای سازمان ایرانی چه نکات مهم‌تری وجود دارد؟

در سازمان‌های ایرانی، علاوه بر ساختار معمول Jira، چند موضوع اهمیت بیشتری پیدا می‌کند.

فارسی‌سازی و RTL

اگر کاربران اصلی فارسی‌زبان هستند، محیط Jira باید برای استفاده روزمره آن‌ها مناسب باشد.

این موضوع می‌تواند شامل:

• فارسی‌سازی Interface
• راست‌چین کردن محتوا
• نمایش مناسب تاریخ
• بهبود نمایش فارسی در Comment و Description
• هماهنگ‌سازی قالب‌های گزارش

باشد.

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

 

ساختار نام‌گذاری را از ابتدا استاندارد کنید

یکی دیگر از مشکلات رایج سازمان‌ها، نام‌گذاری نامنظم Projectها، Issue Typeها و Fieldهاست.

برای مثال، ممکن است یک واحد فیلدی با نام:

Request Type

و واحد دیگری:

Type of Request

بسازد.

در بلندمدت، چنین تفاوت‌هایی گزارش‌گیری را دشوار می‌کنند.

بنابراین، از ابتدا یک استاندارد برای موارد زیر تعریف کنید:

• نام Projectها
• Project Key
• Work Typeها
• Statusها
• Custom Fieldها
• Labelها
• Componentها

چه زمانی از Jira و چه زمانی از Jira Service Management استفاده کنیم؟

این سؤال برای تیم‌های غیر فنی اهمیت زیادی دارد.

اگر تیم فقط فعالیت‌ها و پروژه‌های داخلی را مدیریت می‌کند، Jira معمولاً کافی است.

اما اگر فرآیند شما ماهیت درخواست و خدمت دارد، Jira Service Management گزینه مناسب‌تری است.

برای مثال:

• درخواست IT
• درخواست HR
• درخواست تجهیزات
• درخواست دسترسی
• درخواست خدمات داخلی

Atlassian برای Jira Service Management نیز قالب‌های Enterprise Service Management مانند HR، Facilities، Legal و Customer Service ارائه می‌کند.

بنابراین، قبل از پیاده‌سازی، نوع فرآیند را مشخص کنید.

اشتباهات رایج در پیاده‌سازی Jira برای تیم‌های غیر فنی

اشتباه اول: استفاده از Workflow تیم توسعه

Workflow نرم‌افزار را مستقیماً برای HR یا مالی کپی نکنید.

اشتباه دوم: ساخت تعداد زیاد Status

هر Status باید یک مرحله واقعی در فرآیند باشد.

اشتباه سوم: ایجاد Custom Fieldهای بیش از حد

هر Field هزینه نگهداری و پیچیدگی بیشتری ایجاد می‌کند.

اشتباه چهارم: باز گذاشتن دسترسی ساخت Project

اگر هر کاربر بتواند بدون کنترل Project ایجاد کند، معماری Jira به‌سرعت نامنظم می‌شود. در Jira Cloud، مدیران می‌توانند مجوز ایجاد Team-managed Space را کنترل کنند.

اشتباه پنجم: شروع با Automationهای پیچیده

ابتدا فرآیند را پایدار کنید؛ سپس Automation را اضافه کنید.

اشتباه ششم: استفاده از Jira برای هر نوع کاری

هر فرآیند الزاماً به Jira نیاز ندارد. ابتدا مسئله را تعریف کنید، سپس ابزار را انتخاب کنید.

معماری پیشنهادی برای یک سازمان متوسط

برای یک سازمان متوسط می‌توان چنین ساختاری در نظر گرفت:

Jira

├── HR
├── Finance
├── Sales
├── Marketing
├── Operations
└── IT

در لایه بعدی، هر واحد Workflow و Dashboard خودش را خواهد داشت؛ بااین‌حال، Jira Admin استانداردهای اصلی مانند Permission، Naming، Fieldها و گزارش‌ها را کنترل می‌کند.

اگر سازمان رشد کند، می‌توانید به‌تدریج Templateهای استاندارد بسازید. در Jira Cloud Enterprise، Atlassian حتی امکان ساخت Custom Template برای استفاده مجدد از تنظیمات سازمانی را ارائه می‌کند.

چک‌لیست پیاده‌سازی Jira برای تیم غیر فنی

قبل از تحویل پروژه به تیم، این موارد را بررسی کنید:

• فرآیند واقعی تیم مستند شده است.
• Work Typeها مشخص شده‌اند.
• Workflow بیش از حد پیچیده نیست.
• Fieldهای غیرضروری حذف شده‌اند.
• Permissionها براساس Role تعریف شده‌اند.
• Dashboard مناسب ساخته شده است.
• Automationهای اصلی تست شده‌اند.
• کاربران آموزش اولیه دیده‌اند.
• Naming Convention مشخص شده است.
• فرآیند گزارش‌گیری تعریف شده است.
• داده‌های محرمانه سطح دسترسی مناسبی دارند.
• محیط آزمایشی قبل از Production بررسی شده است.

جمع‌بندی

پیاده‌سازی Jira برای تیم‌های غیر فنی، بیشتر از آنکه یک پروژه نرم‌افزاری باشد، یک پروژه طراحی فرآیند است. اگر ابتدا فرآیند واقعی HR، مالی، فروش یا عملیات را بشناسید و سپس آن را به Workflow، Work Type، Field، Permission و Automation تبدیل کنید، کاربران خیلی سریع‌تر با Jira ارتباط برقرار می‌کنند.

از طرف دیگر، بهتر است از یک Workflow ساده شروع کنید و بعد از دریافت بازخورد کاربران، قابلیت‌های بیشتری اضافه کنید. به این ترتیب، Jira به‌جای اینکه به یک سیستم پیچیده و خسته‌کننده تبدیل شود، به یک ابزار کاربردی برای مدیریت واقعی کار در سازمان تبدیل خواهد شد.

در نهایت، مهم‌ترین اصل این است:

Jira را برای فرآیند سازمان طراحی کنید، نه سازمان را برای Jira.

 

برای اطلاعات بیشتر و دریافت مشاوره سازمانی با ما در ارتباط باشید