اجایل برای مدیریت پروژه های غیر نرم افزاری
سیستم‌های مدیریت پروژه کلاسیک، مشابه اون چیزی که تو پم‌باک و پرینس۲ توضیح داده می‌شه، طوری طراحی شدن که برای همه نوع پروژه قابل استفاده باشن. با این حال پروژه‌های نرم‌افزاری تفاوت‌هایی با پروژه‌های دیگه دارن و احساس می‌شه که سیستم‌های کلاسیک برای مدیریت اون‌ها به اندازه کافی موفق نیستن. تلاش‌هایی که تو این زمینه شده، منجر شده به تدوین گروهی از سیستم‌های مدیریت پروژه مدرن که عموما تم و رویکرد مشابهی دارن و به همشون Agile (چابک) گفته می‌شه. موفق‌ترین و پر استفاده‌ترین سیستم اجایل هم Scrum (اسکرام) هست.
حالا بریم سراغ تفاوت‌های پروژه‌های نرم‌افزاری و غیر نرم‌افزاری. دلیل ریشه‌ای که باعث ایجاد این تفاوت شده، تغییرات خیلی زیاد تو پروژه‌های نرم‌افزاریه. مثلا وقتی یه پروژه ساخت کارخونه، بیمارستان یا راه دارین، از اول پروژه تعریف می‌شه و معمولا تا آخر کار تغییرات زیادی نمی‌کنه؛ ولی پروژه نرم‌افزاری اینطوری نیست. مشتری نرم‌افزاری رو سفارش می‌ده و به هر شکلی که هست محصول تعریف می‌شه، ولی با جلو رفتن کار انقدر نظرش عوض می‌شه و با دیدن قسمت‌های انجام شده انقدر ایده‌های جدید به نظرش میاد یا چیزهایی که از قلم افتادن یادش می‌افته، که عملا محصولی که در آخر کار به وجود میاد ربطی به محصولی که از اول تصور کرده بودیم نداره.
حالا چه دلیلی وجود داره که کسایی مثل من که تو پروژه‌های غیر نرم‌افزاری کار می‌کنن بخوان اسکرام یاد بگیرن؛ از نظر من دو دلیل می‌تونه وجود داشته باشه:
- تلاش برای به‌کارگیری آموزه‌های اجایل
- درک بهتر سیستم‌های کلاسیک
تلاش برای به‌کارگیری آموزه‌های اجایل
وقتی آدم می‌بینه که یه سیستمی تو گروهی از پروژه‌ها موفق بوده، قطعا به این فکر می‌کنه که شاید بتونه ازش تو پروژه‌های خودش هم کمک بگیره. حالا ممکنه بشه قسمت‌هایی از اون رویکرد رو وارد پروژه کرد، یا قسمت‌هایی از پروژه رو به طور کامل با اون رویکرد مدیریت کرد. مثلا من بعید نمی‌دونم که بشه پروژه‌های طراحی یا قسمت طراحی پروژه‌ها رو اجایل مدیریت کرد.
هرچی که باشه، این ترکیب کار ساده‌ای نیست و به نظر نمیاد که صرفا آشنایی با این دو سیستم برای به وجود آوردن ترکیب کافی باشه. من فکر می‌کنم در آینده سیستم‌های جدیدی از سنتر این دو گروه سیستم به وجود بیاد که بتونه بهتر از هردو راهگشا باشه.
درک بهتر سیستم‌های کلاسیک
یه چیزی که با مطالعه جدی و به خصوص آکادمیک فلسفه و هنر می‌شه یاد گرفت، اینه که درک کامل یه سیستم ممکن نیست، مگر با درک سیستم‌های رقیبش. مثلا هنر مفهومی یا سوررئال رو هیچوقت نمی‌شه فقط با مطالعه خودشون درک کرد، حتما باید دید که این رویکردها پاسخ به کدوم رویکردهای قبلی بودن و بعدا چه پاسخ‌هایی به این‌ها داده شده. فلسفه‌ای مثل پازیتیویسم رو صرفا با مطالعه آموزه‌هاش نمی‌شه درک کرد، باید دید که در پاسخ به چه چیزهایی به وجود اومده و بعدا چه پاسخ‌هایی بهش داده شده.
همین ماجرا در مورد سیستم‌های مدیریت پروژه هم وجود داره. وقتی آدم رویکرد یه سیستم جدید رو ببینه که اصول برای جانشینی سیستم‌های کلاسیک ساخته شده، اون سیستم‌های کلاسیک رو بهتر درک می‌کنه.
از نظر من این دلیل مهم‌ترین چیزیه که می‌تونه باعث بشه یادگیری اسکرام برای ماها مفید باشه.
اجایل و پم‌باک
یکی از تغییرات نسخه پنجم پم‌باک، که الان نهایی نشده و تو مرحله پیش‌نویسه، پشتیبانی از سیستم‌های اجایله. این‌که استاندارد شماره ۱ مدیریت پروژه دنیا این سیستم‌ها رو کاملا به رسمیت شناخته اهمیتشون رو نشون می‌ده، هرچند که شیوه پشتیبانی کردنش ممکنه یه مقدار عجیب باشه.
به نظر من پم‌باک تغییری کلی نکرده، اون سنتزی که گفتم اتفاق نیفتاده، بلکه فقط سعی کرده بعضی قسمت‌ها رو کمی کلی‌تر کنه که با سیستم‌های اجایل هم سازگار باشه.
اگه قصد دارین درک کاملی از نسخه آینده پم‌باک داشته باشین، باید سیستم‌های اجایل رو هم تا حدی بشناسین.
یکی دیگه از تحول‌های مهم یکی دو سال اخیر، اینه که PMI (موسسه مدیریت پروژه، که استاندارد پم‌باک رو هم تدوین می‌کنه و گواهی‌های PMP رو هم صادر می‌کنه)، گواهی جدیدی برای سیستم‌های اجایل در نظر گرفته. این هم قاعدتا نشونه دیگه‌ای از اهمیت پیدا کردن سیستم‌های اجایله.