مدیر پروژهپاسخ‌های مصاحبه

من با یک منشور پروژهٔ روشن شروع می‌کنم: دامنه، اهداف، ذی‌نفعان، محدودیت‌ها و معیارهای موفقیت. یک WBS (ساختار شکست کار) و برنامهٔ زمان‌بندی تفصیلی می‌سازم، وابستگی‌ها را شناسایی می‌کنم و از روز اول یک ثبت‌خطر ایجاد می‌کنم. در مرحلهٔ اجرا، جلسات کوتاه روزانه برگزار می‌کنم، پیشرفت را نسبت به مبنای برنامه پیگیری می‌کنم و موانع را زود مطرح و ارتقاء می‌دهم. کنترل تغییر دامنه را تحت‌نظر نگه می‌دارد. در خاتمه، جلسات درس‌آموخته برگزار می‌کنم و نتایج را نسبت به خلاصهٔ اولیه مستندسازی می‌کنم. برنامه‌ریزی دقیق پیش از اجرا زمان بسیار بیشتری را نسبت به هزینه‌اش صرفه‌جویی می‌کند.

گسترش کنترل‌نشدهٔ دامنه از طریق یک فرایند رسمی کنترل تغییر مدیریت می‌شود که من در آغاز پروژه پیاده‌سازی می‌کنم. هر درخواستی که دامنه را تغییر دهد مستندسازی می‌شود، از نظر تأثیر بر زمان، هزینه و کیفیت ارزیابی می‌شود و برای تصمیم‌گیری به کمیتهٔ هدایت (steering committee) یا حامی (sponsor) ارائه می‌گردد. من با ذی‌نفعان دربارهٔ تریدآف‌ها شفاف هستم — افزودن دامنه بدون افزایش زمان یا بودجه غیرواقعی است و من این را صریح می‌گویم. ماتریس RACI و پروتکل‌های تأیید از ابتدا مسئولیت‌پذیری را روشن می‌کنند.

یک پروژهٔ مهاجرت سیستم 6 هفته عقب افتاد چون مسائل کیفیت داده را دست‌کم گرفته بودیم. من برای مرحلهٔ کشف به اندازهٔ کافی ظرفیت احتیاطی در نظر نگرفته بودم. با تجدید مبنای برنامه، اختصاص منابع به یک جریان کاری پاک‌سازی دادهٔ اختصاصی و ارتباط شفاف با حامی، وضعیت را بازیابی کردم. ما با 10 روز تأخیر تحویل دادیم اما در چارچوب بودجه بودیم. درس: همیشه برای پروژه‌های مهاجرت یک مرحلهٔ کشف/ارزیابی لحاظ کنید و هرگز داده را دست‌کم نگیرید.

من زود ذی‌نفعان را نقشه‌برداری می‌کنم — نفوذ، علاقه و ترجیحات ارتباطی آن‌ها. وقتی تعارض‌ها بروز می‌کند، آن‌ها را به یک مجمع مستند مطرح می‌کنم، تریدآف‌ها را به‌صورت عینی ارائه می‌دهم و به ذی‌نفعان کمک می‌کنم تا دربارهٔ معیارهای اصلی موفقیت پروژه هم‌راستا شوند. وقتی حل اختلاف مسدود شد، آن را به حامی ارجاع می‌دهم. معمولاً بیشتر تعارض‌ها ناشی از انتظارات ناهماهنگ هستند تا اختلافات حل‌ناپذیر — مستندسازی شفاف و ارتباطات زودهنگام بیشتر مسائل را پیشگیری می‌کند.

پیش‌فرض من یک رویکرد ترکیبی است. من اصول Agile را — اسپرینت‌های کوتاه، بازنگری‌های منظم و تحویل‌های تکراری — برای پروژه‌هایی با نیازمندی‌های در حال تغییر یا عدم قطعیت فنی به‌کار می‌برم. برای برنامه‌های نظارتی، زیرساختی یا با دامنهٔ ثابت از روش‌های ساختاریافتهٔ Waterfall یا کنترل‌های PRINCE2 — فازهای مشخص، دروازه‌های مرحله‌ای و تصمیمات مستند — استفاده می‌کنم. روش‌شناسی باید در خدمت پروژه باشد، نه برعکس. من دارای گواهی‌نامهٔ PMP هستم و تجربهٔ PRINCE2 دارم.

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

من شفافیت ایجاد می‌کنم — اهداف، نقش‌ها و انتظارات روشن پایهٔ عملکرد بالا هستند. تیم را از نویز سازمانی غیرضروری محافظت می‌کنم و به‌طور فعال موانع را برمی‌دارم. در جلسات تیم و ملاقات‌های یک‌به‌یک (1:1) از مشارکت‌ها تقدیر می‌کنم. اعضای تیم را در حل مسئله مشارکت می‌دهم به‌جای صرفاً واگذاری وظایف — مالکیت انگیزه را افزایش می‌دهد. بازنگری‌های منظم به تیم صدا می‌دهد و عمل به بازخورد نشان می‌دهد که گوش می‌دهم. فرهنگ از طریق رفتارهای سازگار شکل می‌گیرد.

من از Jira و Confluence برای تحویل Agile، MS Project برای برنامه‌ریزی مبتنی بر نمودار گانت در برنامه‌های پیچیده، Asana و Monday.com برای ابتکارات کوچکتر و Smartsheet برای دیدپذیری بین‌عملکردی استفاده کرده‌ام. برای ارتباط از Slack و Teams استفاده می‌کنم. ابزار کمتر از انضباط اهمیت دارد — هر ابزاری که باشد، مطمئن می‌شوم که یک منبع حقیقت واحد است، به‌روز نگه داشته می‌شود و برای همهٔ ذی‌نفعان قابل مشاهده است. من خود را با ابزارهای مورد علاقهٔ تیم سازگار می‌کنم.