برای تیم دورکار، بهترین ابزار مدیریت پروژه همان ابزاری است که همه بتوانند در آن مسئول هر کار، مهلت، وضعیت و مانع را ببینند. Trello برای برد ساده وظایف، Asana برای کارهای دارای وابستگی و چند نمای برنامه‌ریزی، و GitHub Projects برای تیمی که کارش به کد و مسئله‌های مخزن گره خورده گزینه‌های قابل بررسی‌اند. پیش از خرید یا مهاجرت، یک پروژه واقعی را در دو ابزار آزمایش کنید.

خلاصه پاسخ
  • ابتدا مسئله تیم را تعریف کنید: گم شدن کارها، ابهام مسئولیت یا دشواری هماهنگی وابستگی‌ها.
  • برای جریان ساده «در صف، در حال انجام، انجام‌شده»، برد Trello می‌تواند کافی باشد.
  • برای وابستگی میان کارها و نماهای زمانی، امکانات Asana را بررسی کنید.
  • برای تیم توسعه نرم‌افزار، GitHub Issues و Projects کار را به مخزن کد نزدیک می‌کنند.
  • قیمت و محدودیت پلن‌ها تغییر می‌کند؛ پیش از تصمیم، صفحه رسمی روز را ببینید.

ابزار مدیریت پروژه در دورکاری چه مشکلی را حل می‌کند؟

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

پیش از مقایسه نام محصولات، یک هفته کار تیم را مشاهده کنید. آیا کارها فراموش می‌شوند؟ آیا یک وظیفه چند صاحب دارد؟ آیا منتظر ماندن برای تأیید مشخص نیست؟ پاسخ، ویژگی لازم را تعیین می‌کند. اگر مشکل اصلی تصمیم‌های نامکتوب است، افزودن نمای گانت شاید آن را حل نکند. اگر مشکل وابستگی چند تیم است، یک برد ساده ممکن است خیلی زود شلوغ شود.

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

چه معیارهایی را برای انتخاب بررسی کنیم؟

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

برای تیمی که چند پروژه هم‌زمان دارد، نماهای مختلف، فیلتر و جست‌وجو اهمیت می‌یابد. برای تیم کوچک با یک پروژه، این امکانات ممکن است پیچیدگی اضافی ایجاد کنند. همچنین نیاز به ثبت وابستگی، بازبینی و تأیید را جدا بسنجید. اگر هیچ‌کس گزارش‌های زمانی را نمی‌خواند، پرداخت برای نمای پیچیده زمان‌بندی ارزش عملی ندارد.

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

Trello؛ برد دیداری برای جریان ساده

راهنمای رسمی Trello ساختار آن را با برد، فهرست و کارت توضیح می‌دهد. یک برد می‌تواند پروژه باشد، فهرست‌ها مرحله‌های کار باشند و هر کارت یک وظیفه را نشان دهد. برای تیم محتوا، فهرست‌هایی مانند ایده، در حال نگارش، بازبینی و منتشرشده قابل فهم‌اند. کشیدن کارت از یک فهرست به دیگری، پیشرفت را به چشم می‌آورد.

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

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

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

Asana؛ کارهای مرتبط و نمای زمانی

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

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

Asana ابزارهای بیشتری برای دیدن کار در سطح پروژه ارائه می‌کند، اما همه امکانات در همه پلن‌ها یکسان نیستند. صفحه رسمی مدیریت پروژه Asana وابستگی، مسئول کار و هماهنگی میان پروژه‌ها را شرح می‌دهد. هنگام آزمون، دقیقاً همان ویژگی موردنیاز را در پلنی که می‌خواهید استفاده کنید بررسی کنید. نسخه آزمایشیِ دارای امکانات بیشتر ممکن است تصویر متفاوتی از پلن انتخابی بدهد.

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

GitHub Projects؛ برای کار نزدیک به کد

اگر تیم توسعه نرم‌افزار است و مسئله‌ها، تغییرات و بازبینی کد در GitHub ثبت می‌شود، GitHub Issues و Projects گزینه طبیعی‌ای برای بررسی‌اند. مسئله می‌تواند به مخزن، درخواست تغییر و بحث فنی وصل شود. برد یا جدول پروژه امکان گروه‌بندی کارها و دنبال کردن وضعیت را می‌دهد. این پیوند برای برنامه‌نویسانی که هر روز در GitHub کار می‌کنند اصطکاک جابه‌جایی میان ابزارها را کمتر می‌کند.

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

مستندات GitHub درباره Issues توضیح می‌دهد مسئله‌ها برای کار، خطا و ایده به کار می‌روند و می‌توان آن‌ها را به پروژه‌ها افزود. برای تیم فنی، قالب یکسان برای گزارش خطا مفید است: رفتار مورد انتظار، رفتار واقعی، راه بازتولید و مسئول بررسی. اما هر گفت‌وگوی عمومی سازمان را نباید در مخزن کد جا داد.

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

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

چگونه ابزار را در یک هفته آزمایش کنیم؟

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

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

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

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

هر وظیفه یک مسئول اصلی داشته باشد، حتی اگر چند نفر همکاری می‌کنند. وضعیت‌ها کم و تعریف‌شده باشند؛ «در حال انجام» باید معنای یکسانی برای همه داشته باشد. تاریخ تحویل را با ظرفیت واقعی هماهنگ کنید و دلیل جابه‌جایی موعد را بنویسید. وقتی کار متوقف است، مانع و فردی را که می‌تواند آن را رفع کند مشخص کنید.

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

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

جمع‌بندی

برای تیم دورکار، ابزار را بر اساس شکل کار انتخاب کنید: Trello برای برد ساده، Asana برای برنامه‌ریزی با وابستگی و GitHub Projects برای کار نزدیک به مخزن کد مناسب بررسی‌اند. هیچ‌کدام بدون تعریف مسئول، خروجی و مهلت مشکل هماهنگی را حل نمی‌کنند. یک پروژه واقعی را آزمایش کنید و پیش از پرداخت، محدودیت پلن، دسترسی‌ها و امکان خروج داده را ببینید.

سوالات متداول

آیا تیم کوچک حتماً به ابزار پولی نیاز دارد؟

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

Trello بهتر است یا Asana؟

برای برد وظایف ساده Trello قابل بررسی است؛ برای وابستگی‌ها و نماهای زمانی Asana را آزمایش کنید. نتیجه به فرایند و توان استفاده اعضای تیم بستگی دارد.

GitHub Projects فقط برای برنامه‌نویسان است؟

خیر، اما بیشترین مزیت آن وقتی دیده می‌شود که کار به مخزن، Issue و تغییر کد وصل باشد. راحتی اعضای غیر فنی را نیز آزمایش کنید.

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

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

منابع

نوشته قبلی