پراجکت بهتر است یا پریماورا؟
مبانی مقایسه
برخی کارشناسان به پراجکت به عنوان نرم افزار برنامه ریزی و کنترل پروژه علاقه دارند و برخی به پریماورا. از این بین گروهی از کارشناسان به نرمافزار مورد علاقه خود تعصب زیادی دارند و این مسئله آغازی است بر این بحث طولانی، که پراجکت بهتر است یا پریماورا.
پیش از هر چیز باید مسئله مهمی را در نظر داشت. Primavera Project Management نرمافزاری سازمانی است، در حالی که نسخههای معمولی پراجکت اینگونه نیستند. اگر قرار باشد قابلیتهای سازمانی مبنای مقایسه قرار گیرند، باید پریماورا را با پراجکت سرور، که نسخه سازمانی نرمافزار برنامهریزی و کنترل پروژه مایکروسافت است، مقایسه کرد. در این نوشته به قابلیتهای غیر سازمانی توجه میشود. منظور از برنامهریزی و کنترل پروژه غیر سازمانی، تلاشی است که در راستای مدیریتِ مستقلِ پروژهها انجام میشود. در سیستمهای سازمانی به ترکیبِ پروژههای متعددی که در یک سازمان انجام میشود و قابلیتهای کارِ گروهی توجه میشود.
کدامیک بهتر است؟
پریماورا | پراجکت |
شناوری را float | پراجکت slack. |
قید ALAP در پریماورا شناوری آزاد را صفر میکند | قید ALAP در پراجکت شناوری کل را صفر میکند |
همپوشانی روابط را میتوان در پراجکت بر حسب درصد نیز وارد کرد | |
پریماورا اجازه ایجاد بیشتر از یک رابطه را بین دو فعالیت میدهد | |
فارسینویسی در پریماورا “کمی” سختتر از پراجکت است. | |
فلسفه WBS در پریماورا و پراجکت یکسان نیست، هرچند که تفاوت عملیاتی چندانی ایجاد نمیکند | فلسفه WBS در پریماورا و پراجکت یکسان نیست، هرچند که تفاوت عملیاتی چندانی ایجاد نمیکند |
سیستمهای گزارشدهیِ نسخههای قدیمی پراجکت ضعیفتر از پریماورا بود، ولی این اختلاف در نسخههای جدید کمتر شده است؛ هرچند که وضعیتِ فعلی هر دو نرمافزار در گزارشدهی بسیار ضعیف و عملا برای بسیاری از نیازها غیر قابل استفاده است. | |
پراجکت با نرمافزارهای آفیس همنشینی بهتری دارد. | |
رابط کاربر پراجکت بهتر از پریماورا است. | |
میتوان در پریماورا هر تعداد فیلد که لازم است ساخت. | پراجکت محدود به تعدادی فیلد اختصاصی است |
فیلدهای از پیش آماده پریماورا به مراتب بیشتر از پراجکت است | کاربران پراجکت در صورت نیاز باید چنان قابلیتهایی را با فیلدهای اختصاصی بسازند |
فرمولنویسی در پراجکت سادهتر و انعطافپذیرتر است. | |
و پریماورا چنین امکانی ندارد. | پراجکت به قابلیت ماکرونویسی (برنامهنویسیVBA) مجهز است |
پراجکت امکانات بیشتری در roll-up (خلاصهسازی) دارد | |
میتوان در پریماورا مایلستونهای پیشرفت(step) ساخت هرچند که قابلیتهای تعریف شده برای مایلستونیهای پیشرفت پریماورا ناقصتر از آن هستند که آن را عملیاتی کنند. | در پراجکت چنین امکانی وجود ندارد (کاربر باید در این حالت فعالیت را به زیرفعالیتهایی خرد کند). |
منابع راهنمای پریماورا بسیار کم هستند | منابع راهنمای پراجکت (کتابها، مقالات و سایتها، به زبانهای مختلف) بسیار زیاد |
پراجکت در ایران عمومیت بیشتری دارد و در نتیجه استفاده از آن در شرکتهایی که با شرکتهای مختلف سر و کار دارند سادهتر است. | |
نمیتوان در پراجکت فعالیتهای level of effort به سبک پریماورا ساخت؛ ولی واقعیت این است که میتوان چنین فعالیتهایی ساخت. | میتوان در پراجکت فعالیتهای level of effort به سبک پریماورا ساخت؛ ولی واقعیت این است که میتوان چنین فعالیتهایی ساخت. |
متاسفانه توجه به این مسایل، اهمیت بحث را کاهش میدهد. واقعیت دیگر این است که بسیاری از کارشناسان و دستاندرکاران برنامهریزی و کنترل پروژه به هیچکدام از این دو نرمافزار و از آن مهمتر به اصول و مفاهیم بنیادین این علمِ کاربردی، به اندازه کافی مسلط نیستند و نمیتوانند تواناییهای بالقوه هیچکدام از آنها را بالفعل کنند. بسیاری از اقدامات انجام شده در حوزه برنامهریزی و کنترل پروژه به اندازه کافی عملیاتی نیست و بیشتر به نقاشی میمانند. شاهدی بر این مدعا، این است که دستاندرکاران عقیده دارند برنامه مناسب برنامهایست که هزینه و منبع داشته باشد. ولی وارد کردن هزینه و منبع در حالتی که قرار نیست عملیاتی شوند، چه فایدهای دارد؟ در اکثریت مطلق برنامههایی که منبع و هزینه دارند میتوان فیلدهایی متنی ساخت، مقدارهای هزینه و منابع را به آنها منتقل کرد، و فیلدهای اصلی آنها را خالی باقی گذاشت، بدون اینکه عملکرد برنامه تغییری کند. این مسئله نشان میدهد که وجودِ این دادهها در برنامه هیچ نقشی ندارند. دیگر فرقی ندارد که این تابلوی نقاشی در پراجکت ترسیم شده باشد، در پریماورا، در اکسل یا در فتوشاپ. در این مواقع یا قضاوت کارشناسانهای که اضافه شدنِ این دادهها را اجباری قلمداد میکند یا کارشناسی که آنها را پیادهسازی میکند، یا سازمانی که حاکم بر این مسایل است، مقصر و ناآگاه است.
به عقیده من، آنچه در حوزه مدیریت پروژه ایران اهمیت دارد، این است که مشکلاتِ زیربنایی حل شوند. دستاندرکاران و کارشناسان باید آگاهتر شوند، شرکتها باید سازماندهی بهتری یابند و آنگاه میتوان از نرمافزارهای برنامهریزی و کنترل پروژه استفاده بهتری کرد. آن زمان است که اندکی تفاوت در قابلیتهای نرمافزارها تعیین کننده میشود و چنین بحثهایی جای طرح پیدا میکنند.