شروع کار با یک نرم‌افزار مدیریت پروژه زمانی موفق است که تیم در همان روز اول یک جریان واقعی را تجربه کند؛ نه اینکه ساعت‌ها میان تنظیمات و قابلیت‌ها بچرخد. در تسکی می‌توانید از ساخت فضای کاری به پروژه، برد، دعوت اعضا و اولین تحویل برسید، اما کیفیت نتیجه به چند تصمیم ساده وابسته است: مرز فضا، خروجی پروژه، وضعیت‌های معنادار و مسئول هر کار.
این آموزش بر اساس مستندات رسمی تسکی در ۱۲ شهریور ۱۴۰۵ نوشته شده است. رابط و امکانات ممکن است با انتشار نسخه‌های بعدی تغییر کنند؛ برای جزئیات روز به مرکز راهنمای تسکی مراجعه کنید. هدف این مقاله ساخت یک پروژه آزمایشی قابل استفاده است، نه فعال کردن همه قابلیت‌ها.
قبل از ثبت‌نام، یک جریان کوچک انتخاب کنید
برای شروع، مهم‌ترین یا پیچیده‌ترین پروژه سازمان را انتخاب نکنید. یک جریان پرتکرار با پنج تا بیست کار، چند وضعیت روشن و دو تا پنج عضو مناسب‌تر است؛ مثلاً تولید یک مقاله، پیگیری درخواست داخلی، آماده‌سازی کمپین یا انتشار نسخه کوچک محصول.
پیش از ورود، این چهار مورد را در یک برگه بنویسید:
- نتیجه پروژه در یک جمله؛
- نقطه شروع هر درخواست؛
- سه تا پنج وضعیت واقعی کار؛
- فردی که مالک اجرای پایلوت است.
این محدودیت مانع می‌شود ساختار کل سازمان را پیش از دیدن رفتار واقعی ابزار طراحی کنید.
گام اول: حساب و فضای کاری را بسازید
پس از ثبت‌نام و ورود نخست، تسکی در مسیر راه‌اندازی اولین فضای کاری را ایجاد و شما را مالک آن می‌کند. فضای کاری بیرونی‌ترین مرز تیم است؛ اعضا، پروژه‌ها، تنظیمات و اشتراک زیر آن قرار می‌گیرند. نامی انتخاب کنید که اعضای دعوت‌شده فوراً تشخیص دهند، مانند نام شرکت یا تیم مستقل.
اگر چند شرکت، مشتری یا تیم کاملاً جدا دارید، از ابتدا درباره مرز فضا تصمیم بگیرید. هر فضای کاری اعضا و پروژه‌های مستقل دارد. برای هر پروژه کوچک فضای جدا نسازید؛ این کار جابه‌جایی و مدیریت دسترسی را بی‌دلیل سنگین می‌کند.
راهنمای رسمی ساخت اولین فضای کاری توضیح می‌دهد که تسکی نوع وظیفه و وضعیت‌های پایه، صندوق ورودی شخصی و سند شروع را نیز آماده می‌کند.
گام دوم: پروژه اول را از قالب یا صفحه خالی بسازید
گزینه «پروژه جدید» را انتخاب کنید. می‌توانید از قالب آماده متناسب با سناریو شروع کنید یا یک پروژه خالی بسازید. قالب فقط نقطه شروع است؛ وضعیت، بخش و وظیفه‌های نمونه بعداً قابل تغییرند. اگر جریان تیم روشن نیست، قالب نزدیک را بردارید و آن را ساده نگه دارید. اگر جریان تثبیت‌شده دارید، پروژه خالی کنترل بیشتری می‌دهد.
نام پروژه را بر اساس خروجی بنویسید، نه واژه‌های کلی مانند «کارها». «انتشار وب‌سایت پاییز» یا «درخواست‌های پشتیبانی محصول» در جست‌وجو و گزارش معنای بیشتری دارد. در توضیح پروژه، نتیجه، محدوده، مالک و معیار پایان را ثبت کنید.
گام سوم: وضعیت‌های برد را معنادار کنید
نمای بورد تسکی هر وضعیت را به یک ستون و هر وظیفه را به یک کارت تبدیل می‌کند. برای پایلوت، چهار یا پنج وضعیت کافی است:
- ورودی: درخواست ثبت شده اما هنوز پذیرفته نشده است.
- آماده: اطلاعات و اولویت کافی برای شروع دارد.
- در حال انجام: یک نفر فعالانه روی آن کار می‌کند.
- بازبینی: خروجی آماده کنترل یا تأیید است.
- انجام‌شده: معیار پایان را گذرانده است.
هر ستون باید تغییر واقعی در مسئولیت یا تصمیم را نشان دهد. برای هر ریزگام ستون نسازید؛ ریزفعالیت‌ها می‌توانند زیرکار یا چک‌لیست باشند. در راهنمای نمای بورد می‌توانید جابه‌جایی کارت، مدیریت ستون، محدودیت WIP و شناورها را ببینید.
گام چهارم: پنج کار واقعی بسازید
کار نمونه یا ساختگی به تیم نشان نمی‌دهد سیستم در زندگی روزمره چگونه عمل می‌کند. پنج مورد واقعی و کم‌ریسک را وارد کنید. برای هر کار، عنوان نتیجه‌محور، مسئول، موعد در صورت وجود، اولویت و تعریف پایان قرار دهید. پیوست و زمینه لازم را روی همان کار نگه دارید.
عنوان «صفحه قیمت آماده انتشار شود» از «کار روی سایت» بهتر است. اگر بیش از یک نفر مشارکت می‌کنند، یک مالک حرکت بعدی تعیین و سهم دیگران را به زیرکار تبدیل کنید. برای اصول بیشتر، راهنمای مدیریت وظایف را بخوانید.
گام پنجم: اعضا را با نقش درست دعوت کنید
در تسکی نقش‌های مالک، مدیر، عضو و مهمان مرز اختیار را مشخص می‌کنند و عضویت پروژه تعیین می‌کند هر فرد چه داده‌ای ببیند. مالک بالاترین اختیار را دارد؛ مدیر ساختار و اعضا را اداره می‌کند؛ عضو در پروژه مشارکت می‌کند؛ مهمان برای مشتری یا پیمانکار با دامنه محدود مناسب است.
اصل کمترین دسترسی را رعایت کنید. به همه نقش مدیر ندهید و برای سرعت از حساب مشترک استفاده نکنید. دو حساب آزمایشی بسازید و ببینید عضو و مهمان دقیقاً چه چیزی مشاهده یا ویرایش می‌کنند. پس از خروج هر همکار، دسترسی را قطع و کارهای باز او را واگذار کنید؛ تاریخچه پروژه باقی می‌ماند.
گام ششم: یک کار را از ابتدا تا پایان حرکت دهید
یکی از کارها را به مالک بسپارید، سؤال و پیوست را در همان صفحه ثبت کنید و کارت را میان وضعیت‌ها جلو ببرید. در نمای بورد با کشیدن کارت به ستون دیگر، وضعیت وظیفه تغییر می‌کند. بازبین باید معیار پایان را کنترل کند و در صورت نیاز کار را با دلیل مشخص برگرداند.
این چرخه کوچک چند ابهام را آشکار می‌کند: آیا ورودی کافی است؟ چه کسی اجازه بستن دارد؟ بازخورد کجا می‌ماند؟ آیا «بازبینی» مالک مشخص دارد؟ پیش از افزودن خودکارسازی، همین قواعد را اصلاح کنید.
گام هفتم: نمای مناسب هر نقش را انتخاب کنید
همه نباید از یک نما استفاده کنند. برد برای دیدن جریان، فهرست برای مرور دقیق، تقویم برای موعدها و گانت برای وابستگی زمانی مفید است. نمای هوشمند نیز ترکیب فیلتر، مرتب‌سازی و چینش را ذخیره می‌کند تا هر نقش تصویر مورد نیازش را سریع باز کند.
برای شروع فقط سه نمای روزمره بسازید: «کارهای من»، «عقب‌افتاده‌ها» و «بدون مسئول». اگر تیم موعدمحور است، نمای تقویم را با تقویم جلالی و شروع هفته شنبه تنظیم و تراکم تحویل‌ها را بررسی کنید.
گام هشتم: سند و تصمیم را کنار پروژه نگه دارید
یک سند کوتاه برای هدف، قواعد برد و تعریف پایان بسازید. صورت‌جلسه و تصمیمی که جریان را تغییر می‌دهد باید به پروژه یا کار مرتبط بماند، نه در پیام خصوصی. لازم نیست همه دانش قدیمی را روز اول منتقل کنید؛ فقط اطلاعاتی را وارد کنید که برای اجرای پایلوت لازم است.
اگر درخواست‌ها از بیرون تیم می‌آیند، بعد از تثبیت جریان یک فرم بسازید تا ورودی کامل و قابل پیگیری شود. ترتیب مهم است: ابتدا منطق کار، سپس فرم و خودکارسازی.
گام نهم: اعلان و ریتم پیگیری را تنظیم کنید
اعلان زیاد تیم را به نادیده گرفتن همه پیام‌ها عادت می‌دهد. مسئول هر کار، موعدهای واقعی و منشن‌های ضروری را مشخص کنید. جلسه پیگیری را با برد یا نمای عقب‌افتاده‌ها برگزار کنید و به‌جای پرسیدن وضعیت تک‌تک افراد، روی مانع، تصمیم و تحویل بعدی تمرکز کنید.
در پایان هر هفته سه سؤال بپرسید: کدام کارها بدون مالک ماندند؟ کجا کارت برگشت؟ کدام اطلاعات بیرون از تسکی ثبت شد؟ پاسخ‌ها نسخه بعدی ساختار را شکل می‌دهند.
چه زمانی اتوماسیون اضافه کنیم؟
وقتی تیم چند بار جریان دستی را بدون ابهام اجرا کرد، کارهای تکراری و کم‌قضاوت را خودکار کنید؛ مانند یادآوری نزدیک موعد یا حرکت پس از یک تأیید مشخص. برای هر قانون، محرک، اقدام، مالک خطا و راه توقف داشته باشید.
اتوماسیون زودهنگام، وضعیت بد یا مسئول نامعلوم را سریع‌تر تکثیر می‌کند. ابتدا گردش کار را استاندارد کنید و سپس بخش پایدار آن را به قانون تبدیل کنید.
پایلوت هفت‌روزه پیشنهادی
- روز اول: فضای کاری، پروژه، نتیجه و وضعیت‌ها؛
- روز دوم: پنج تا بیست کار واقعی و مسئول‌ها؛
- روز سوم: دعوت عضو و مهمان با آزمون دسترسی؛
- روز چهارم: اجرای کار، کامنت، پیوست و بازبینی؛
- روز پنجم: نماهای برد، فهرست و تقویم؛
- روز ششم: جلسه کوتاه روی داده زنده و رفع مانع؛
- روز هفتم: خروجی آزمایشی، بازخورد کاربر و تصمیم ادامه.
اشتباهات رایج شروع کار با تسکی
- وارد کردن همه پروژه‌های سازمان پیش از اجرای پایلوت؛
- ساخت ستون برای هر فعالیت و پیچیده کردن برد؛
- ثبت کار بدون مسئول، نتیجه یا معیار پایان؛
- دادن نقش مدیر به همه اعضا؛
- آموزش همه قابلیت‌ها در جلسه اول؛
- ساخت اتوماسیون پیش از تثبیت جریان دستی؛
- نگه داشتن تصمیم و فایل در پیام‌رسان؛
- سنجش موفقیت با تعداد کار ثبت‌شده، نه تحویل واقعی.
معیار موفقیت راه‌اندازی
پایلوت زمانی موفق است که اعضا بدون کمک مداوم بتوانند کار خود را پیدا، به‌روز و تحویل کنند؛ مدیر وضعیت را بدون پرسیدن ببیند؛ مهمان فقط محدوده خود را مشاهده کند؛ و یک خروجی واقعی از ابتدا تا پایان در سیستم ثبت شده باشد. تعداد قابلیت‌های فعال معیار مناسبی نیست.
اولین فضای کاری تسکی را همین حالا بسازید
با یک پروژه کوچک شروع کنید، چند کار واقعی را روی برد قرار دهید و اعضا را با نقش درست دعوت کنید. پلن رایگان برای آزمودن جریان اصلی تیم در دسترس است.
جمع‌بندی
شروع درست با تسکی از ساده‌سازی می‌آید: یک فضای کاری با مرز روشن، یک پروژه نماینده، چند وضعیت معنادار، کارهای واقعی و نقش‌های محدود. اولین کار را کامل حرکت دهید، نما و اعلان را با نیاز هر نقش تنظیم کنید و فقط بعد از تثبیت جریان سراغ فرم، گزارش و اتوماسیون بروید. پذیرش تیم با تحویل موفق ساخته می‌شود، نه با جلسه معرفی طولانی.
سؤالات متداول
برای شروع تسکی باید فضای کاری را دستی بسازیم؟
طبق راهنمای فعلی، تسکی در مسیر ورود اول فضای کاری اولیه را می‌سازد و شما را مالک آن قرار می‌دهد؛ نام و تنظیمات بعداً قابل تغییرند.
پروژه را از قالب بسازیم یا خالی؟
اگر جریان هنوز روشن نیست، قالب نزدیک نقطه شروع خوبی است. برای فرایند تثبیت‌شده، پروژه خالی کنترل بیشتری می‌دهد. در هر دو حالت ساختار را ساده نگه دارید.
برای برد اول چند ستون مناسب است؟
عدد ثابت وجود ندارد، اما سه تا پنج وضعیت که تغییر واقعی مسئولیت یا تصمیم را نشان دهند معمولاً برای پایلوت کافی‌اند.
چه کسی را با نقش مهمان دعوت کنیم؟
مشتری یا پیمانکاری که باید فقط در پروژه مشخص مشارکت کند. دسترسی را پیش از داده واقعی با یک حساب آزمایشی بررسی کنید.
چه زمانی تیم را کامل منتقل کنیم؟
پس از آنکه پروژه نماینده، دسترسی‌ها، یک تحویل کامل، اعلان‌ها و خروج داده از معیار پذیرش عبور کردند.
