منشور پروژه؛ قبل از شروع همه را هم‌مسیر کنید

اگر اعضای تیم از هدف، محدوده و موفقیت پروژه برداشت متفاوتی داشته باشند، دردسر خیلی زود شروع می‌شود. در این درس یاد می‌گیرید چطور با یک منشور کوتاه، قبل از شروع کار همه را روی هدف، مسئولیت‌ها و مرزهای پروژه هم‌مسیر کنید.

یک فروشگاه آنلاین تصمیم گرفته اپلیکیشن موبایل بسازد. مدیر فروش افزایش فروش می‌خواهد، مدیر پشتیبانی کاهش تماس‌ها را، و مدیرعامل فقط می‌گوید «تا نمایشگاه ماه آینده آماده باشد!» تیم فنی هنوز نمی‌داند دقیقاً چه چیزی باید تحویل دهد. شروع پروژه در این وضعیت، یعنی دعوت‌نامه برای اختلاف‌های بعدی.

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

به‌جای جمله‌های مبهمی مثل «تجربه مشتری را بهتر کنیم»، مسئله و نتیجه را مشخص کنید. مثلاً: «بخش بزرگی از تماس‌های پشتیبانی مربوط به پیگیری سفارش است؛ نسخه اول اپ باید امکان ثبت و پیگیری سفارش را فراهم کند.» بعد هم تعیین کنید با چه معیاری می‌فهمید پروژه موفق بوده است.

مدیران مختلف از اپلیکیشن انتظارهای متفاوتی دارند و تیم هنوز نمی‌داند اولویت چیست. بهترین اقدام چیست؟
طراحی رابط کاربری را سریع شروع کنیم و بعداً تصمیم بگیریم

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

در پایان پروژه دقیقاً چه چیزهایی باید تحویل داده شوند؟ مثلاً نسخه قابل انتشار اپ، پنل مدیریت، راهنمای کاربر و آموزش تیم پشتیبانی. لازم نیست همه تسک‌های ریز را در منشور بنویسید؛ کافی است خروجی‌های مهم طوری روشن باشند که همه درباره نتیجه نهایی برداشت مشابهی داشته باشند.

دو هفته بعد مدیر بازاریابی پیشنهاد می‌دهد سیستم کد تخفیف پیشرفته هم به اپ اضافه شود. درخواست بدی نیست، اما خارج از محدوده فعلی است. حالا تیم می‌تواند به‌جای یک «نه» سلیقه‌ای، اثر این تغییر بر زمان، هزینه و محدوده توافق‌شده را جداگانه بررسی کند.

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

تیم روی یک تصمیم مهم اختلاف دارد و سه مدیر مختلف هرکدام دستور متفاوتی می‌دهند. احتمالاً کدام بخش منشور از ابتدا به‌اندازه کافی روشن نشده است؟
طراحی رابط کاربری

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

ریسک چیزی است که ممکن است اتفاق بیفتد؛ مثلاً کمبود نیروی متخصص. فرض چیزی است که فعلاً درست در نظر می‌گیرید؛ مثلاً آماده‌شدن API شرکت حمل‌ونقل تا ماه آینده. محدودیت هم مرزی قطعی است؛ مثلاً «نسخه اول باید قبل از نمایشگاه منتشر شود». ثبت این موارد، دلیل تصمیم‌های اولیه را روشن نگه می‌دارد.

اگر یک نفر منشور را تنهایی بنویسد و فقط برای بقیه بفرستد، اختلاف‌ها ممکن است دیر آشکار شوند. افراد کلیدی را در تهیه و مرور آن درگیر کنید. وقتی درباره هدف، محدوده، زمان و اختیار تصمیم‌گیری توافق شد، تأیید نهایی یعنی: «روی همین تصویر کلی توافق داریم و می‌توانیم وارد برنامه‌ریزی جزئی‌تر شویم.»

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

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