بیشتر آدمها وقتی اسم PMO (دفتر مدیریت پروژه) را میشنوند، یاد فرمهای اکسل، ددلاینهای سختگیرانه، بوروکراسیهای بیپایان و «پلیسِ تیم» میافتند. واحدی که انگار وظیفهاش کند کردن سرعت تیمهای فنی و مچگیری از آنهاست.
اما در دنیای محصولات مدرن و تیمهای چابک، PMO دیگر یک واحد نظارتی صلب نیست؛ بلکه یک قابلیت استراتژیک است که به آن Agile PMO میگوییم.
مشکل از جایی شروع میشود که مدیریت پروژه به جای «تسهیلگری»، روی «کنترلگری» تمرکز میکند. وقتی تمرکز ما به جای خروجی (Outcome)، روی فرآیند (Process) باشد، PMO تبدیل به سدی در برابر خلاقیت میشود. اما Agile PMO نگاهی کاملاً متفاوت دارد.
تصور کنید در حال بازی کردن یک بازی ویدئویی هستید. شما قوانین را حس نمیکنید، اما آنها وجود دارند تا تجربه شما را لذتبخش و هدفمند کنند. یک Agile PMO واقعی، دقیقاً نقش «طراح بازی» سیستم را دارد، نه بازیکنِ آن.
او قرار است قوانینِ محیطی را طوری طراحی کند که تیم بدون درگیر شدن در پیچیدگیهای اضافه، فقط روی «بردن» و «خلق کردن» تمرکز کند. در این نگاه جدید، ما سه ماموریت اصلی داریم:
در مدیریت سنتی، هدف کنترل است؛ در مدیریت چابک، هدف «تسهیل» است. ما قوانینی را طراحی میکنیم که مسیر را روشن کنند، نه اینکه دستوپای تیم را ببندند. قانون خوب، قانونی است که مسیرِ کار را شفاف کند و باعث شود همه بدانند «قدم بعدی چیست»، بدون اینکه لایههای تایید غیرضروری ایجاد کند.
هر تیمی یک «جریان کار» یا Flow دارد. اصطکاک یعنی همان جلسات تکراری، ابهام در اولویتها و ابزارهای ناکارآمد. کار من در Agile PMO این است که مثل یک مهندس سیستم، این اصطکاکها را شناسایی و حذف کنم تا تیم فقط روی «خلق ارزش» تمرکز کند.
سیستمهایی مثل جیرا (Jira) و کانفلوئنس (Confluence) نباید ابزار مچگیری باشند. آنها باید تبدیل به «محیطی امن» شوند که تیم بداند دادههایش کجاست و حافظهی جمعی پروژه چگونه شکل میگیرد. در یک سیستم درست، اشتباهات به جای توبیخ، تبدیل به مستندات یادگیری برای آینده میشوند.
بهترین تعریف برای یک Agile PMO موفق این است: «حضورش نامرئی و تاثیرش مشهود باشد.»
اگر تیم شما بدون اینکه حس کند کسی در حال مدیریت کردن آنهاست، منظم، شفاف و سریع پیش میرود، یعنی معمار سیستم کارش را درست انجام داده است. چون بهترین سیستمها، آنهایی هستند که آدمها حس نمیکنند در حالِ «مدیریت شدن» هستند؛ فقط حس میکنند در حالِ «پیش رفتن» هستند.
شما بنویسید:
آیا در تجربه کاری شما، واحد مدیریت پروژه یک «بال پرواز» بوده یا یک «وزنه به پا»؟ به نظر شما چطور میتوان بین نظم سازمانی و آزادی عمل تیمهای فنی تعادل برقرار کرد؟
