AgileFall یک اصطلاح کنایه آمیز برای مدیریت پروژه است که در آن سعی می‌کنید چابک و سریع باشید، اما همچنان از تکنیک‌های توسعه آبشاری استفاده می‌کنید. اغلب نتیجه این کار چیزی شبیه ترکیب موم کف روی دسر است؛ همانقدر نامنناسب و گیج‌کننده!
من در یک جلسه مدیریت پروژه AgileFall را از نزدیک دیدم. خبر خوب این بود که چند تغییر در فرآیند، ما را به مسیر اصلی بازگرداند. این جلسه در یکی از شرکت‌های Fortune 10 برگزار شد.
ما به آنها کمک کردیم تا یکی از خطوط حیاتی تولید محصول را، از فرآیند مدیریت پروژه آبشاری و سنتی به مدل چابک تبدیل کنند. در ادامه توصیفی از شرایطی که داشتیم را آورده‌ایم!
مشتری ما، مالک محصول آنها، باهوش، مبتکر و با انگیزه است که شرکتش از رقبای جدید عقب مانده است. او متوجه شد زمانی که مشکل و راه حل‌های آن نقاط ناشناخته و تاریک زیادی دارند، توسعه به روش آبشاری و سنتی مناسب نیست.
بخش تولید محصول که تمرکز اصلی ماست، ۱۵ مدیر پروژه دارد که روی ۶۰ پروژه نظارت دارند. در چند ماه گذشته ما به او کمک کردیم تا اصول اولیه Lean را به این پروژه‌ها تزریق کند. در تمامی پروژه‌های Horizon ۱ و۲ هدف ما ایجاد ویژگی‌های جدید برای محصولات موجود با هدف قرار دادن مشتریان فعلی، یا استفاده مجدد از محصولات، ابزارها یا تکنیک‌های موجود برای مشتریان جدید بود.
اکنون تیم‌ها حداقل محصول قابل عرضه (MVP) را توسعه می‌دهند، از ساختمان خارج می‌شوند تا در واقعیت با کاربران و سهامداران صحبت کنند، و مجوز‌ها را دریافت می‌کنند و … . همه این ها اصول اولیه Lean هستند.
اما در آخرین جلسه ما، متوجه شدم که مدیر محصول هم چنان، مدیران پروژه خود را طبق مدل آبشاری (Waterfall) مدیریت می‌کند. تیم‌ها فقط هر سه ماه یک بار در یک بازبینی رسمی، برنامه‌های خود را ثبت می‌کنند. مشتری ما «در مورد شکایت تیم‌های مختلف در رابطه با میزان کاغذبازی‌ای شکایت می‌کنند که هر فصل باید در زمان گزارش‌دهی انجام دهند» گفت. در همین حال او از کیفیت گزارش‌ها هم ناراضی بود؛ چرا که احساس می‌کرد اکثر تیم‌ها گزارش‌ها را شب قبل از بررسی می‌نویسند. او پرسید که چگونه می‌تواند معیارهای عملکردی را مشخص کرده و گزارشات را به موقع از مدیران پروژه بگیرد؟
در نگاه اول، من فکر کردم چه چیزی می‌تواند در رابطه با داده‌های بیش‌تر، نامناسب به نظر برسد؟ آیا این چیزی نیست که ما می‌خواهیم؟ «تصمیمات مبتنی بر شواهد»!
داشتم فکر می‌کردم که چطور می‌توانم اقدامات موثرتری پیشنهاد بدهم که متوجه شدم مشتری ما هنوز فرآیندی دارد که در آن موفقیت با گزارش‌ها سنجیده می‌شود، نه نتایج. این همان فرآیند گزارش‌دهی بود که برای اندازه‌گیری پروژه‌هایی که از مدل ترکیبی آبشاری و خطی استفاده می‌کردند، استفاده می‌شد.
(اگر بخواهیم منصف باشیم، این تیم یک جزیره Lean در شرکتی است که هنوز مدل آبشاری بر آن حاکم است. در حالی که این گروه طرز فکر و آهنگ سازمان را تغییر داده است، افرادی که به او گزارش می‌دهند هنوز یادگیری و نتایج Agile/Lean را دریافت نکرده‌اند. آنها فقط می‌خواهند مدارک را ببینند.) در هر دو بخش مدیریت پایین و بالا، ما به یک طرز فکر مدیریت پروژه بسیار متفاوت نیاز داشتیم.
همانطور که گفتگو ادامه داشت، ما در مورد راه‌های مدیریت پروژه‌ها با استفاده از چند اصل عملیاتی مدیریت پروژه Agile/Lean به توافق رسیدیم (بدون ذکر کلمه Lean یا Agile).
- این افراد هستند که ارزش ایجاد می‌کنند (یافتن راه‌حل/ماموریت مناسب)، نه فرآیندها و گزارش‌ها
- با این حال، روند و گزارشات هنوز برای مدیریت بالاتر از او ضروری است
- داشتن تیم‌ها برای ساختن MVPهای افزایشی و تکراری مهم‌تر از وسواس در مورد مستندسازی/گزارش اولیه است.
- به تیم‌ها اجازه دهید به جای پیروی کورکورانه از برنامه‌ای که در روز اول به شما فروخته‌اند، روی آن چه در کشف مشتری آموخته‌اند تمرکز کنند.
- پیشرفت به سمت نتایج (تناسب راه حل/ماموریت) غیرخطی است و همه تیم‌ها با سرعت یکسان پیشرفت نمی‌کنند.
مشتری ما موافقت کرد که به جای بررسی‌های فصلی، تیم رهبری هر هفته با ۴ تا ۵ مدیر پروژه صحبت کند و ۱۶ الی ۲۰ پروژه را بررسی کند. این بدان معناست که چرخه تعامل – اگرچه هنوز طولانی است، اما از سه ماه فعلی به حداقل یک بار در ماه می‌رسد.
مهم‌تر از آن، ما تصمیم گرفتیم که او محور این گفتگوها را به جای تمرکز برگزارشات، بر نتایج قرار دهد. ارتباط کلامی‌بیش‌تر و استفاده از کاغذ بازی بسیار کم‌تر خواهد بود. بررسی‌ها در مورد تحویل مکرر، توسعه تدریجی، و این که چگونه رهبر می‌تواند موانع را برطرف کند، خواهد بود و تیم مشتری ما با اشتراک گزارش پیشرفت در بین تیم‌ها ادامه می‌دهد تا بتوانند از یکدیگر بیاموزند.
در مجموع، ایده رادیکال این بود که نقش اصلی محصول، میزان کاغذبازی را پایین نیاورد. با یک جهت‌گیری نتیجه را پایین بیاورد و سپس پیشرفت آن را به زنجیره بالا برگرداند. در حالی که این برای تیم‌ها عالی بود، این مسئولیت را بر عهده محصول گذاشت تا پیشرفت را به رهبری خود گزارش دهد به گونه ای که آنها می‌خواستند آن را ببینند.
می‌دانستم نزدیک به پایان جلسه مسیر کاملا روشن شده است. مشتری از تیم خود پرسید: «در ادامه، اعضای تیم مناسب برای مدیریت فرآیند چابک و مناسب در مقابل مدل آبشاری چه کسانی هستند؟» و من لبخند زدم وقتی به این نتیجه رسیدند که Lean می‌تواند در برابر یک محیط اجرایی و فرآیند محور توسط افراد کم‌تری مدیریت شود که می‌توانند در یک محیط یادگیری پر هرج و مرج به خوبی عمل کنند.
البته هنوز کار ما با این تیم تمام نشده است، اما تا اینجا گزارش مختصری از اول راه ما تا الان را مطالعه کردید.
این متن ترجمه شده مقاله https://hbr.org/2019/09/when-waterfall-principles-sneak-back-into-agile-workflows از وبسایت HBRاست.
دیدگاهتان را بنویسید