وقتی اصول‌ مدل waterfall به جریان‌های کاری agile باز می‌گردد

تهیه‌کننده مقاله : تیم مارکتینگ

دسته بندی: مقالات HBR
5 دقیقه زمان مطالعه
1401/03/01
0 نظر

AgileFall یک اصطلاح کنایه آمیز برای مدیریت پروژه است که در آن سعی می‌کنید چابک و سریع باشید، اما همچنان  از تکنیک‌های توسعه آبشاری استفاده می‌کنید.  اغلب نتیجه‌ای مانند ترکیب یک موم کف بر روی دسر ایجاد می‌کند.

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

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

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

بخش تولید محصول که تمرکز اصلی ماست، ۱۵ مدیر پروژه دارد که بر روی ۶۰ پروژه نظارت دارند. در چند ماه گذشته ما به او کمک کردیم تا اصول اولیه (لاغر و چابک) Lean را به این پروژه‌ها تزریق کند. در تمامی‌پروژه‌های Horizon ۱ و۲ هدف ما ایجاد ویژگی‌های جدید، برای محصولات موجود با هدف قرار دادن مشتریان فعلی، یا استفاده مجدد از محصولات، ابزارها یا تکنیک‌های موجود برای مشتریان جدید بود. اکنون تیم‌ها در حال ایجاد محصولاتی دارای قابلیت حداقل دوام (MVP) هستند، از ساختمان خارج می‌شوند تا در واقع با کاربران و سهامداران صحبت کنند، و مجوز‌ها را دریافت می‌کنند، و …. همه این ها اصول ناب خوب است .

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

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

(اگر بخواهیم منصف باشیم، این تیم یک جزیره مناسب در شرکتی است که هنوز مدل آبشاری بر آن حاکم است. در حالی که این گروه طرز فکر و آهنگ سازمان را تغییر داده است، افرادی که به او گزارش می‌دهند هنوز یادگیری و نتایج چابک/مناسب را دریافت نکرده اند. آنها فقط می‌خواهند مدارک را ببینند.)در هر دو بخش مدیریت پایین و بالا، ما به یک طرز فکر مدیریت پروژه بسیار متفاوت نیاز داشتیم.

همانطور که گفتگو ادامه داشت ، ما در مورد راه‌های مدیریت پروژه‌ها با استفاده از چند اصل عملیاتی مدیریت پروژه ناب/ چابک به توافق رسیدیم (بدون ذکر کلمه Lean یا Agile).

  1. این افراد هستند که ارزش ایجاد می‌کنند (یافتن راه‌حل/ماموریت مناسب)، نه فرآیندها و گزارش‌ها
  2. با این حال، روند و گزارشات هنوز برای مدیریت بالاتر از او ضروری است
  3. داشتن تیم‌ها برای ساختن MVP‌های افزایشی و تکراری مهم تر از وسواس در مورد مستندسازی/گزارش اولیه است.
  4. به تیم‌ها اجازه دهید به‌ جای پیروی کورکورانه از برنامه‌ای که در روز اول به شما فروخته‌اند، روی آن چه در کشف مشتری آموخته‌اند تمرکز کنند.
  5. پیشرفت به سمت نتایج (تناسب راه حل/ماموریت) غیرخطی است و همه تیم‌ها با سرعت یکسان پیشرفت نمی‌کنند.

مشتری ما موافقت کرد که به جای بررسی‌های فصلی، تیم رهبری هر هفته با ۴ تا ۵ مدیر پروژه صحبت کند و ۱۶ تا ۲۰ پروژه را بررسی کند. این بدان معناست که چرخه تعامل – اگرچه هنوز طولانی است ، اما از سه ماه فعلی به حداقل یک بار در ماه می‌رسد.

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

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

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

من نمی‌توانم برای جلسه بعدی صبر کنم.این متن ترجمه شده مقاله https://hbr.org/2019/09/when-waterfall-principles-sneak-back-into-agile-workflows از وبسایت HBR‌است.

مشاهده فرصت‌های شغلی در آسا مشاهده فرصت‌های شغلی در آسا