راهنمای انتخاب نرم‌افزار مدیریت پروژه برای تیم‌های ایرانی

در این مقاله می‌خوانید

1. پیش از ابزار: کارتان را روی کاغذ بکشید
2. معیارهایی که برای تیم ایرانی فرق می‌کند
3. دسترسی پایدار
4. پرداخت و قرارداد
5. فارسی و راست‌به‌چپ، واقعاً
6. تقویم شمسی
7. محل نگهداری داده
8. پشتیبانی
9. معیارهای عمومی که همه باید بسنجند
10. سادگی در کار روزانه
11. به‌روزرسانی هم‌زمان
12. گفت‌وگو کنار کار
13. دسترسی و نقش‌ها
14. تاریخچه و ردپا
15. بیرون بردن داده
16. دسترسی از موبایل
17. آنچه نیاز ندارید
18. یک جدول امتیازدهی ساده
19. آزمایش دوهفته‌ای واقعی
20. هزینهٔ واقعی را حساب کنید
21. مهاجرت و تاریخچه
22. سیگنال‌های خطر در دمو و مذاکره
23. بعد از انتخاب: جا انداختن ابزار در تیم
24. یک صفحه قرارداد استفاده بنویسید
25. مرحله‌به‌مرحله گسترش دهید
26. ابزار قبلی را ببندید
27. مدیرها اول
28. جمع‌بندی
29. منابع و مطالعهٔ بیشتر

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

برای تیم‌های ایرانی چند پرسش دیگر هم اضافه می‌شود که در راهنماهای خارجی نیست: آیا سرویس فردا هم در دسترس است؟ آیا می‌شود با ریال پرداخت کرد و فاکتور رسمی گرفت؟ آیا متن فارسی و تاریخ شمسی درست کار می‌کنند؟ داده‌ها کجا نگه داشته می‌شوند؟ این راهنما هر دو دسته را پوشش می‌دهد و در پایان روشی برای یک آزمایش دوهفته‌ای واقعی پیشنهاد می‌کند تا تصمیم بر اساس استفادهٔ واقعی گرفته شود.

پیش از ابزار: کارتان را روی کاغذ بکشید

اولین قدم انتخاب ابزار، نگاه کردن به ابزارها نیست. یک ساعت با تیم بنشینید و این‌ها را بنویسید:

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

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

یک پرسش دیگر هم مهم است: چه کسانی از ابزار استفاده می‌کنند؟ فقط تیم فنی، یا مدیران، فروش و مشتری هم؟ هر چه دامنهٔ کاربران وسیع‌تر باشد، سادگی مهم‌تر از قدرت می‌شود.

معیارهایی که برای تیم ایرانی فرق می‌کند

دسترسی پایدار

دسترسی از ایران به بسیاری از سرویس‌های ابری خارجی، از جمله سرویس‌های Atlassian مثل ترلو و جیرا، به دلیل تحریم‌ها محدود است. تیم‌هایی که با وجود این از آن‌ها استفاده می‌کنند، معمولاً به ابزار تغییر IP وابسته می‌شوند و همیشه این خطر را دارند که حساب کاربری بر اساس محل اتصال محدود شود. وقتی ابزار مدیریت پروژه، حافظهٔ کاری تیم است، این وابستگی ریسک عملیاتی است، نه فقط یک ناراحتی.

پرسش عملی: اگر فردا صبح دسترسی قطع شود، تیم چقدر کار را از دست می‌دهد و چقدر طول می‌کشد دوباره راه بیفتد؟

پرداخت و قرارداد

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

فارسی و راست‌به‌چپ، واقعاً

«پشتیبانی از فارسی» در بسیاری از ابزارها یعنی ترجمهٔ منوها. آنچه برای استفادهٔ روزانه مهم است این‌هاست:

• متن مخلوط فارسی و انگلیسی (مثلاً «رفع خطای API در صفحهٔ ورود») درست نمایش داده شود و نقطه و پرانتز جابه‌جا نشود.
• کل چیدمان راست‌به‌چپ باشد: ستون اول تابلو سمت راست، کشیدن و رها کردن کارت‌ها جهت درست داشته باشد.
• جست‌وجو با «ی» و «ک» فارسی و عربی هر دو کار کند.
• قلم فارسی خوانا باشد و نیم‌فاصله درست نمایش داده شود.

تقویم شمسی

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

محل نگهداری داده

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

پشتیبانی

وقتی چیزی خراب می‌شود، با چه کسی، به چه زبانی و در چه ساعتی می‌توانید حرف بزنید؟ پشتیبانی فارسی در ساعت کاری ایران، برای تیمی که کارش به ابزار گره خورده، ارزش واقعی دارد.

معیارهای عمومی که همه باید بسنجند

سادگی در کار روزانه

ابزار را با کارهای پرتکرار بسنجید، نه با امکانات کم‌استفاده. ساختن یک کارت، جابه‌جا کردنش، افزودن یک توضیح و پیوست، پیدا کردن «کارهای من». اگر این‌ها بیش از چند کلیک می‌خواهند، تیم کم‌کم به پیام‌رسان برمی‌گردد.

به‌روزرسانی هم‌زمان

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

گفت‌وگو کنار کار

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

دسترسی و نقش‌ها

آیا می‌توانید تعیین کنید پیمانکار فقط تابلوی پروژهٔ خودش را ببیند؟ آیا این محدودیت در سرور اعمال می‌شود یا فقط دکمه‌ها پنهان می‌شوند؟ این پرسش را دست‌کم نگیرید؛ در راهنمای دسترسی در ابزار مدیریت پروژه روش آزمودنش را آورده‌ام.

تاریخچه و ردپا

چه کسی این کارت را جابه‌جا کرد؟ چه کسی تاریخ را عوض کرد؟ ابزاری که لاگ فعالیت ندارد، در اولین اختلاف، کمکی نمی‌کند. همچنین ببینید حذف چطور کار می‌کند: آیا چیزی به‌جای حذف بایگانی می‌شود تا قابل‌برگشت باشد؟

بیرون بردن داده

این معیار را پیش از ورود بسنجید، نه هنگام خروج. آیا می‌شود همهٔ داده‌ها، شامل نظرها و پیوست‌ها، را در قالبی قابل‌استفاده بیرون برد؟ ابزاری که ورود را آسان و خروج را سخت می‌کند، شما را در وضعیت «قفل شدن در یک فروشنده» قرار می‌دهد.

دسترسی از موبایل

برنامهٔ موبایل لازم است یا نسخهٔ وب که روی موبایل خوب کار کند کافی است؟ برای بیشتر تیم‌های نرم‌افزاری که کار اصلی را پشت کامپیوتر انجام می‌دهند، دومی کافی است. برای تیم‌های میدانی، ممکن است نباشد.

آنچه نیاز ندارید

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

یک جدول امتیازدهی ساده

بعد از جمع کردن معیارها، برای هر کدام وزنی بگذارید و هر ابزار نامزد را از ۱ تا ۵ امتیاز بدهید. وزن‌ها کار شماست، نه من؛ نمونهٔ زیر فقط برای نشان دادن شکل کار است:

معیار	وزن نمونه	ابزار الف	ابزار ب	ابزار ج
دسترسی پایدار از ایران	۵
پرداخت ریالی و فاکتور	۳
فارسی و راست‌به‌چپ واقعی	۴
تاریخ شمسی	۳
محل نگهداری داده	بسته به سازمان
سادگی کار روزانه	۵
نقش‌ها و دسترسی	۴
لاگ فعالیت و بایگانی	۳
بیرون بردن داده	۳
پشتیبانی	۲

دو قاعده برای استفادهٔ درست از این جدول: اول، یک یا دو معیار را «شرط ورود» تعیین کنید؛ ابزاری که در آن‌ها رد می‌شود، با هیچ امتیاز دیگری جبران نمی‌شود. دوم، امتیازها را بعد از آزمایش واقعی بدهید، نه بعد از دیدن صفحهٔ امکانات.

آزمایش دوهفته‌ای واقعی

هیچ دمو و مقایسه‌ای جای استفادهٔ واقعی را نمی‌گیرد. این برنامه را پیشنهاد می‌کنم:

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

اگر در پایان دو هفته تیم بدون یادآوری از ابزار استفاده می‌کند، نشانهٔ خوبی است. اگر مدام باید یادآوری کنید «این را در ابزار ثبت کن»، نشانه‌ای جدی است، صرف‌نظر از امتیازها.

هزینهٔ واقعی را حساب کنید

هزینهٔ اشتراک یا لایسنس فقط بخشی از هزینه است. این‌ها را هم در نظر بگیرید:

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

مهاجرت و تاریخچه

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

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

چون این راهنما را سازندهٔ یکی از گزینه‌ها نوشته، صریح بگویم: بردماگ ابزاری تحت وب، کاملاً راست‌به‌چپ و با تاریخ شمسی است که هم روی سرورهای ما در ایران و هم روی سرور خود سازمان اجرا می‌شود و تابلوها را با نظرها و پیوست‌ها از ترلو وارد می‌کند. در عوض برنامهٔ موبایل بومی، نمودار گانت، وابستگی بین کارها و ثبت ساعت برای صورت‌حساب ندارد؛ اگر این‌ها برای شما شرط ورودند، ابزار دیگری را امتحان کنید.

سیگنال‌های خطر در دمو و مذاکره

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

بعد از انتخاب: جا انداختن ابزار در تیم

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

یک صفحه قرارداد استفاده بنویسید

نه یک دستورالعمل بیست‌صفحه‌ای؛ یک صفحه که این‌ها را روشن کند:

• هر تابلو مال چه پروژه یا تیمی است و چه کسی مالک آن است.
• ستون‌ها به چه ترتیبی‌اند و هر ستون دقیقاً چه معنایی دارد. «در حال انجام» یعنی کسی همین امروز رویش کار می‌کند، نه «قرار است انجام شود».
• هر کارت حداقل چه چیزهایی دارد: عنوان روشن، مسئول، و اگر تاریخ دارد، تاریخ.
• برچسب‌ها چه معنایی دارند. پنج برچسب با معنای روشن بهتر از بیست برچسب مبهم است.
• بحث دربارهٔ یک کار کجا انجام می‌شود: روی کارت، نه در پیام‌رسان.
• کارت تمام‌شده کی بایگانی می‌شود.

مرحله‌به‌مرحله گسترش دهید

تیمی که آزمایش دوهفته‌ای را انجام داد، تیم اول است. بعد از یکی دو هفته کار عادی، تیم دوم را اضافه کنید و یک نفر از تیم اول را کنارشان بگذارید تا پرسش‌ها را جواب بدهد. گسترش هم‌زمان به کل سازمان یعنی همهٔ مشکل‌ها هم‌زمان ظاهر می‌شوند و کسی وقت جواب دادن به همه را ندارد.

ابزار قبلی را ببندید

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

مدیرها اول

اگر مدیر تیم هنوز در جلسه می‌پرسد «این کار به کجا رسید؟» به‌جای اینکه تابلو را باز کند، پیام روشنی به تیم می‌دهد: ابزار تشریفاتی است. برعکس، وقتی مدیر جلسهٔ هفتگی را پای تابلو برگزار می‌کند و پرسش‌هایش را روی کارت‌ها می‌نویسد، تیم خیلی زود دنبالش می‌آید.

جمع‌بندی

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

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

منابع و مطالعهٔ بیشتر

• Project management software — Wikipedia — مروری بر دسته‌های نرم‌افزار مدیریت پروژه و کارکردهای رایجشان.
• Vendor lock-in — Wikipedia — چرا خروج از یک ابزار می‌تواند پرهزینه شود و چطور پیش از ورود جلویش را بگیریم.
• Data portability — Wikipedia — مفهوم قابلیت انتقال داده و اهمیتش هنگام انتخاب سرویس.
• NIST SP 800-145: The NIST Definition of Cloud Computing — تعریف مرجع مدل‌های سرویس و استقرار ابری، برای سنجیدن گزینهٔ ابری در برابر نصب داخلی.