راهنمایی کاربردی برای ساختن سیستم مدیریت پروژه بر پایهی شیوهی واقعی تحویل کار تیم شما: چرا ابزارهای آمادهی مدیریت پروژه نادیده گرفته میشوند، چطور مراحل و تحویلهای واقعی خود را مدل کنید، نسخهی یک به چه چیزی نیاز دارد، و چگونه کارِ در جریان را بدون جلسههای وضعیت ببینید.
آژانسها، تیمهای خلاق، پیمانکاران، تیمهای محصول و کسبوکارهای خدماتی که شیوهی تحویلشان با ابزارهای آمادهی پروژه جور درنمیآید.
- مدلی از پروژه که بر مراحل و تحویلهای واقعی شما بنا شده است
- نمایی از کارِ در جریان که جایگزین جلسهی وضعیت میشود
- سیستمی که هرگاه فرایند تحویلتان تغییر کند میتوانید بازآراییاش کنید
بیشتر تیمها ابزاری برای مدیریت پروژه امتحان کردهاند و دوباره به صفحههای گسترده و چت برگشتهاند. مشکل خودِ ابزار نبود؛ تناسب آن بود. ابزارهای آمادهی پروژه یک شکل را تحمیل میکنند، وظایفی که در ستونها جابهجا میشوند، اما تحویل شما شکل خودش را دارد: مراحل شما، تأییدهای شما، تحویلهای شما. وقتی ابزار با شیوهی واقعی تحویل شما جور نباشد، بهروزرسانیاش به کاری بیهوده تبدیل میشود و بیسروصدا میمیرد. این راهنما دربارهی ساختن سیستمی است که جور باشد، تا ماندگار شود.
چون یک شکل عمومی را تحمیل میکنند، معمولاً وظایفی که در ستونها حرکت میکنند، در حالی که تحویل شما مراحل، تأییدها و تحویلهای مشخصی دارد که بر آن منطبق نمیشود. پس افراد ابزار را برای دلِ مدیریت بهروز نگه میدارند، اما هماهنگی واقعی در چت رخ میدهد، ابزار کهنه میشود و به جای اینکه جایی باشد که به آن نگاه میکنند، به جای دومی برای بهروزرسانی بدل میشود. سیستم پروژه فقط زمانی ماندگار میشود که مراحلش مراحل شما باشد، با واژههای خودتان.
نشانهاش آشناست: ابزار میگوید پروژه "در حال انجام" است در حالی که همه میدانند در واقع "منتظر فایلهای مشتری" است، حالتی که ابزار نامی برایش ندارد. هر حالتِ جاافتاده یک دروغ کوچک است، و تختهای پر از دروغهای کوچک تختهای است که کسی به آن اعتماد نمیکند، پس کسی آن را بهروز نگه نمیدارد. راهحل انضباط بیشتر نیست؛ سیستمی است که مراحلش با مراحل واقعی جور باشد، از جمله همان حالتهای انتظارِ دستوپاگیر که کار واقعاً در آنها متوقف میشود.
برای همین، توصیف شیوهی تحویل خودتان و ساختن سیستم بر گردِ آن، از پیکربندی قالبِ کسِ دیگر بهتر است. مراحل، نقاط تأیید و تحویلها خودِ محصولاند و ویژهی شیوهی کار شمایند.
پیش از هر تختهای، بازسازی کنید که چند پروژهی اخیر واقعاً چگونه از آغاز تا پایان پیش رفتند، از جمله جایی که متوقف شدند. شما دارید شکلِ تحویلتان را استخراج میکنید.
یک استودیوی طراحی مدام پروژهها را در شکافِ میان "برای مشتری فرستاده شد" و "مشتری پاسخ داد" از دست میداد، جایی که کارها روزها بیصاحب و بدون ساعتِ آشکار میماندند. وقتی صادقانه مدل شد، جریانشان هشت مرحله داشت که سهتای آنها حالت انتظار بودند، و ویژگی تعیینکننده صرفاً آشکار کردن حالتهای انتظار با یک ساعت بود، بهطوری که پروژهای که یک هفته در "منتظر بازخورد مشتری" گیر کرده بود بهجای پنهان شدن در ستون عمومیِ "در حال انجام"، قرمز نشان داده میشد. هیچ چیز دیگری تغییر نکرد و تحویل بهموقع جهش کرد.
ابزارهای پروژه تقریباً سریعتر از هر نوع دیگری متورم میشوند: پیگیری زمان، صدور صورتحساب، برنامهریزی منابع، درگاههای مشتری، وابستگیها. نسخهی یک کوچکترین چیزی است که کار را آشکار و در حرکت نگه میدارد.
جلسهی دورهای وضعیت وجود دارد چون وضعیت هیچجا آشکار نیست؛ افراد گرد هم میآیند تا بلند بگویند آنچه را که یک سیستم خوب نشان میداد. هدف یک سیستم پروژه این است که آن جلسه را غیرضروری کند، نه اینکه ابزاری بیفزاید که دربارهاش در جلسه حرف بزنید.
به آن میرسید وقتی هر کس بتواند یک نما را باز کند و هر پروژه، مرحلهاش، صاحبش و مدتی که نشسته را ببیند. مراحل انتظار با یک ساعت، توقفهای خاموش را به توقفهای آشکار بدل میکنند؛ پروژهای که هشت روز در "بازبینی مشتری" مانده خودبهخود نمایان میشود و گفتوگو بهجای کشف به تصمیم بدل میشود. وقتی تخته مورد اعتماد و بهروز باشد، جلسه به همان چند چیزی که واقعاً به بحث نیاز دارند جمع میشود و اغلب ناپدید میشود.
مورد اعتماد ماندنِ سیستم به دو چیز بستگی دارد که از مالکیتِ آن برمیخیزند: تخته با واقعیت جور است چون مراحل شما مراحل واقعیاند، و همچنان جور میماند چون خودتان میتوانید مراحل را وقتی تحویلتان تکامل مییابد تغییر دهید. یک سیستم پروژه که گردِ جریان کار شما ساخته شده و میتوانید بدون تیکتِ مهندسی بازآراییاش کنید، سیستمی است که تیمتان بهروز نگهش میدارد، چون سرانجام حقیقتِ کار را میگوید.
چون ابزار یک شکل عمومی را تحمیل میکند، معمولاً وظایفی در ستونها، که با مراحل، تأییدها و تحویلهای واقعی شما جور نیست. افراد آن را برای دلِ مدیریت بهروز نگه میدارند در حالی که هماهنگی واقعی در چت میماند، پس کهنه میشود. سیستم زمانی ماندگار میشود که مراحلش مراحل واقعی شما باشد، از جمله حالتهای انتظاری که کار واقعاً در آنها متوقف میشود.
بازسازی کنید که چند پروژهی اخیر واقعاً چگونه پیش رفتند، از جمله جایی که متوقف شدند، و مراحل واقعی را با واژههای خودتان نامگذاری کنید: بریفشده، در طراحی، بازبینی مشتری، اصلاحات، تأییدشده و همینطور. مهمتر از همه، حالتهای انتظار مانند "منتظر بازخورد مشتری" را بگنجانید، چون کار در ابزارهای آماده در همانجا پنهان میشود.
پروژههایی که در یک مرحلهی واقعیِ روشن نشستهاند، یک صاحب برای هر پروژه و مرحله، یک نمای واحد از همهی کارِ در جریان به تفکیک مرحله، و تحویلهای صریح تا صاحبِ بعدی بدون پیام چت بداند. پیگیری زمان، صدور صورتحساب و وابستگیها همه میتوانند تا نسخهی دو صبر کنند.
تا حد زیادی، بله. جلسه وجود دارد چون وضعیت هیچجا آشکار نیست. وقتی یک نمای واحدِ مورد اعتماد هر پروژه، مرحلهاش، صاحبش و مدتی که نشسته را با یک ساعت روی مراحل انتظار نشان دهد، بخشِ کشفِ جلسه ناپدید میشود و فقط تصمیمهای واقعی میمانند. تخته باید بهروز و صادق باشد، و این از مالکیت و شکلدادنِ خودتان به آن برمیخیزد.