اجایل‌فال (AgileFall)، اصطلاحی کنایه‌آمیز است برای سبکی از مدیریت که در آن ضمن تلاش برای چابک (Agile) و لاغر (Lean) بودن، از تکنیک‌های بالا به پایین واترفال نیز بهره گرفته می‌شود. حاصل این ترکیب، چیزی مثل ریختن قیمه در ماست!
من اخیرا در یک جلسه مدیریت پروژه حضور داشتم و دیدم برای اولین بار اجایل‌فال چطور اتفاق می‌افتد. خبر خوب این بود که ترفندهایی وجود داشت که می‌توانست ما را به مسیر درست هدایت کند.
این جلسه در شرکت «Fortune 10» برگزار شد. جایی که قرار است به آن‌ها کمک کنیم تا یکی از خطوط بحرانی تولید را با کمک فرآیند‌های مدیریت پروژه از واترفال سنتی به متدلوژی لاغر تغییر دهیم.
مشتری ما در واقع مدیر محصول اصلی آن‌ها بود که باهوش، مبتکر و خلاق است. در حال حاضر شرکت برای رقابت با رقبای جدید مشکل دارد و او می‌داند وقتی مشکل و راه‌حل‌های ناشناخته زیادی وجود دارد، توسعه به سبک واترفال سنتی چندان مناسب نیست.
خط تولیدی که مورد توجه ما قرار گرفته، دارای ۱۵ مدیر پروژه است که بر ۶۰ پروژه نظارت دارند. در طول چند ماه گذشته ما سعی کردیم کاری کنیم که اصول اولیه متدلوژی لاغر(lean) در این پروژه‌ها پیاده‌سازی شود.
همه پروژه‌ها در افق یک یا دو (از مجموعه افق‌های سه گانه نوآوری مک کینزی) قرار دارند و ویژگی‌های جدیدی را برای محصولات فعلی ایجاد می‌کنند که می‌تواند مشتریان موجود را هدف قرار دهد یا با تغییر محصولات موجود، ابزارها یا تکنیک‌های جدیدی برای مشتریان جدید ایجاد کند.
در حال حاضر گروه‌ها حداقل محصول قابل استفاده (MVP) را تولید می‌کنند و می‌توانند برای صحبت با کاربران و شرکا یا حتی پیاده‌روی و سایر کارها از ساخمان خارج شوند. همه این‌ها مزایای اولیه و پایه‌ای متدلوژی لاغر است.
در آخرین جلسه متوجه شدم رئیس محصول هنوز هم با استفاده از واترفال مدیران پروژه‌های خود را اداره می‌کند. به عبارت دیگر گروه‌ها در بازه‌های زمانی سه ماهه (زمان رسمی برنامه‌ریزی شده) بررسی می‌شوند.
من به شکایت‌های مشتری‌ام درباره حجم کاغذبازی گروه‌ها در این بازه‌های زمانی گوش دادم.
او از کیفیت گزارش‌ها ناراضی بود و احساس می‌کرد بیشتر گروه‌ها گزارش‌ها را شب قبل از بررسی می‌نویسند. در ادامه وی از من پرسید که چگونه می‌توان نظارت بیشتری بر عملکرد و گزارش به‌موقع مدیران پروژه داشت؟
در اولین گام من فکر کردم نکات منفی درباره «دریافت اطلاعات بیشتر» چیست؟ آیا تصمیمات مبتنی بر شواهد همان چیزی نیست که ما می‌خواهیم؟
وقتی فهمیدم مشتری ما هنوز روندی دارد که در آن به‌جای توجه به نتیجه، موفقیت با گزارش اندازه‌گیری می‌شود، تصمیم گرفتم راه را برای کاغذبازی بیشتر ببندم. این فرایند گزارش‌گیری، همان روندی بود که برای اندازه‌گیری پروژه‌های واترفال یا خطی استفاده می‌شد.
(عادلانه بگویم، این گروه یک گروه کوچک با متدلوژی لاغر است و در شرکتی فعالیت می‌کند که هنوز اصول واترفال در آن حرف اول را می‌زند. هرچند این گروه توانسته طرز تفکر و آرایش سازمانی را تغییر دهد، اما گروهی که درباره آن‌ها صحبت شد، هنوز نتوانسته اصول متدلوژی اجایل/ لاغر را یاد بگیرد و از آن استفاده کند. آن‌ها فقط به کاغذبازی اهمیت می‌دهند.)
در هر دو بخش مدیریتی پایین و بالا ما به طرز تفکری متفاوت برای مدیریت پروژه نیاز داشتیم.
در ادامه مکالمات در مورد راه‌های مدیریت پروژه‌ها با استفاده از چند اصل عملیاتی مدیریت پروژه در متدلوژی اجایل/ لاغر توافق کردیم. (البته بدون ذکر کلمه اجایل یا لاغر)
۱ این افراد هستند که ارزش ایجاد می‌کنند، نه فرآیندها و گزارش‌ها (با یافتن راه‌حل/ مسیر مناسب)
۲ همچنان تهیه فرآیندها و گزارش‌ها برای مدیران بالادستی ضروری است.
۳ داشتن یک گروه برای ساختن MVP افزایشی و تکراری، مهمتر از وسواس درباره اسناد و گزارش‌های اولیه است.
۴ باید به گروه‌ها اجازه داد به‌جای پیروی کورکورانه از طرحی که روز اول به شما فروخته‌اند، آنچه در ارتباط با مشتری می‌آموزند را ادامه دهند.
۵ پیشرفت در نتایج (راه‌حل یا مسیر) غیرخطی است و همه گروه‌ها با سرعت مساوی رشد نمی‌کنند.
با کمی مذاکره، مشتری ما قبول کرد که به‌جای بررسی‌های ۳ ماهه، گروه رهبری (لیدرشیپ) در بازه‌های زمانی ۴ تا ۵ هفته یک‌بار با مدیران پروژه صحبت کند و نگاهی به ۱۶ تا ۲۰ پروژه بیندازد.
این یعنی چرخه تعامل (که هنوز هم طولانی است) به‌جای ۳ ماه یک‌بار، به ماهانه تغییر می‌کند. مهمتر از همه، ما تصمیم گرفتیم که وی در گفت‌وگو‌های خود با مدیران پروژه، به‌جای گزارش بر نتایج تمرکز کند. به‌این‌ترتیب ارتباط کلامی بیشتر و کاغذ کمتری می‌شود.
در این بررسی‌های ماهانه به موضوعاتی مانند تحویل مرتب، توسعه افزایشی و نحوه هدایت گروه پرداخته می‌شود و در نهایت می‌توان به کمک آن‌ها موانع را برطرف کرد. می‌تواند موانع را برطرف کند. در این میان گروه مشتری ما همچنان گزارش‌های پیشرفت را با سایر گروه‌ها به اشتراک می‌گذارند تا آن‌ها بتوانند از یکدیگر یاد بگیرند.
درمجموع، ایده اصلی این بود که نقش اصلی رئیس محصول این نیست که کاغذبازی را کم کند. در واقع باید از نتایج خروجی به دست آورد و سپس دستاوردهای آن را به زنجیره کاری خود منتقل کند. این برای گروه‌ها نیز بسیار خوب بود، چرا که به‌این‌ترتیب رئیس محصول می‌توانست گزارش آن‌ها را به همان صورتی که می‌خواستند ببیند و به گروه رهبری بدهد.
من می‌دانستم به پایان جلسه نزدیک شده‌ایم. در همین حال مشتری ما از گروه خود پرسید: «می‌خواهیم با این روند جلو برویم، در این شرایط کدام‌یک از اعضای گروه می‌تواند یک فرآیند لاغر را در مقابل واترفال مدیریت کند؟»
در نهایت نیز به این نتیجه رسیدند که متدلوژی لاغر، فرآیند محور است و می‌تواند توسط افراد کمی در یک محیط پر هرج و مرج یادگیری اجرا شود.
ترجمه آزاد: When Waterfall Principles Sneak Back Into Agile Workflows
