مديريت پروژه

[اوبالیت به بو]

سلام
هدف از احداث اين تايپيك بحث درباره مديريت پروژه هستش كه دوستان مي تونن تجربياتشون رو در پروژه هاي مختلف اينجا بيان كنن. تايپيك خوبي ميشه اگر دوستان فعاليت مفيد داشته باشن و نظراتشون رو بيان كنن.
خواهشي كه از دوستان دارم اين هستش كه در اين تايپيك فقط راهكار ارائه بدن و اگر سوالي دارن مي تونن لينك پست مربوط به بحث اين تايپيك رو در سوالشون قيد كنن و در تايپيك جداگانه بپرسن.

با توجه به اينكه تعداد كاربراني كه در اين بخش فعاليت مي كنن كم هستش نميشه انتظار داشت تايپيك داراي پست هاي زياد باشه اما مطالبي كه دوستان مي تونن درباره اون بحث كنن به شرح زير هستش:

• آغاز پروژه
  
  • جمع آوري اطلاعات پروژه
  • نيازمندي هاي پروژه
  
  
• عوامل موفقيت پروژه
• عوامل شكست پروژه
• روش های جمع اوری اطلاعات
  
  • شفاهي
  • كتبي
  • عملي
  • آموزشي
  • ... {با پيشنهادات شما تكميل مي شود}
  
  
• طراحی انواع دیاگرام های مهندسی نرم افزار
• مدیریت پروژه
• نمودار گانت
• WBS
  
  • مفهوم ساختار شكست
  • پياده سازي WBS {ترجيحاً آموزش عملي}
  • مديريت WBS
  • چگونه به تيم تحليل و برنامه نويس خود شكست رو آموزش بديم؟ {تجربه شكست}
  
  
• نرم افزارهای مرتبط
• تجزيه و تحليل
• مديريت زمان
• مديريت تيم برنامه نويسي و برخورد با تحليل گران
  
  • ساختار يا الگوي سازماني
  • شناسايي يا آشنايي يا كسب اطلاعات از مهارت هاي تيم (تحليل گران و برنامه نويسان)
  • تشكيل تيم
  • مديريت بحث ها (اختلافات و نقطه نظرات)
  • اهميت ارتباط در پروژه ها
  • هدايت تيم
  • جلسات گروهي
  • ايجاد انگيزه در بين افراد
  • مديريت يا هدايت؟ كدام درست است
  • ... {با پيشنهادات شما تكميل مي شود}
  
  
• قيمت گذاري
  
  • عوامل اصلي تعيين بودجه
  • نحوه تخمين زدن قيمت يا بودجه
  • بودجه در پايان پروژه {كمبود يا سود}
  • مخارج
  
  
• كتابهاي موجود در زمينه IT، مديريت پروژه و مهندسي صنايع
  
  • مهندسي IT
  • مهندسي صنايع
  • مديريت
    
    • مديريت IT
    • مديريت مالي
    • مديريت بازرگاني
    
    
  
  
• و...

در پايان مطالب و در يك تايپيك جداگانه يك پروژه مديريت، تحليل و طراحي خواهد شد و اين تايپيك پيوست خواهد شد.

مطالبي رو كه در اين تايپيك مي خونيد بسيار ساده هستن و همه ما با اونها آشنايي داريم و بارها و بارها اونها رو خونديم و شنيديم اما هيچ وقت بهش توجه نمي كنيم.

مفاهيم:

• كلياتي از مديريت پروژه

آغاز پروژه:

• شروع يك پروژه IT - قسمت 1

• شروع يك پروژه IT - قسمت 2
• تدوين منشور يا چشم انداز پروژه - قسمت 1
• تدوين منشور يا چشم انداز پروژه - قسمت 2
• تدوين منشور يا چشم انداز پروژه - قسمت 3 {توجه به چند نكته خيلي مهم}
• پيش بيني زماني براي آموزش

طرح و برنامه ريزي پروژه:

• چند نكته

عوامل موفقيت پروژه:

• عوامل موفقيت پروژه - قسمت 1
• عوامل موفقيت پروژه - قسمت 2

عوامل موفقيت پروژه:

• عوامل شكست در پروژه - اولين پروژه به صورت تحليل (سيستم انبارداري)
• عوامل شكست در پروژه - به روز رساني سيستم هاي قديمي و جايگزيني آهنها با سيستم هاي جديد
• عوامل شكست در پروژه - به نقل از خبرنامه مدیریت پروژه و كتاب مدیریت موفق پروژه های IT

مديريت تيم برنامه نويسي و برخورد با تحليل گران:

• اهميت ارتباط در پروژه ها

[اوبالیت به بو]

عوامل، روش ها و تكنيك هاي زيادي وجود داره كه باعث ميشه يك پروژه با موفقيت به اتمام برسه. معمولاً در تحليل يك پروژه نرم افزاري يك سري آيتم ها وجود داره كه ميان روي اونها فكر و بررسي مي كنن و با گذاشتن جلسات مداوم و خوب راهكارهايي رو پيشنهاد مي دن و بر اساس اون عمليات هاي سيستم رو اولويت بندي مي كنن. اين اولويت بندي باعث ميشه تا مدير يا مديران پروژه زمان انجام عمليات رو تخمين بزنن و در انتها زمان اتمام اتمام پروژه رو بدست ميارن. اما در طول اين مدت مديران و تحليل گران پروژه چگونه كار مي كنن؟ چي باعث ميشه كه تمامي كار ها روي اصول و برنامه از پيش تعيين شده انجام بشه؟ يك مدير پروژه موفق و خوب چه ويژگي هاي بايد داشته باشه و چه نكاتي رو بايد رعايت كنه تا در كارش موفق بشه؟
مطالب اين تايپيك بر اساس تجربه خيلي خيلي اندك من در اين كار هستش و من هم دنبال مسلط شدن روي اين مفاهيم هستم. روي اين موضوع كمي بحث مي كنيم و منتظر نظرات شما هستم.
1- استفاده از ابزارها و نرم افزارهاي مديريت پروژه:
پوشيده نيست كه استفاده از نرم افزارهاي قدرتمند مديريت پروژه مي تونه كمك شاياني به ادامه روند يك پروژه داشته باشه. شايد ساده ترين نرم افزاري كه بشه باهاش كار تحليل رو شروع كرد نرم افزار MS Project بسته نرم افزاري Office باشه. البته خوب خيلي ضعيف هستش و جوابگوي پروژه هاي بزرگ نيست اما براي افراد بي تجربه و جواني مثل بنده مي تونه خيلي چيزها رو آموزش بده. يا نرم افزار CCPM+ كه براي تعيين زمان بندي پروژه هستش. نرم افزار project-MTA براي رسم نمودار و نرم افزار Project-PSP براي رسم WBS پروژه و خيلي نرم افزار هاي كاربردي ديگه كه من نمي شناسمشون(!)
2- پذيراي مرحله جديد بودن:
براي من اين اتفاق افتاده كه زماني كه تحليل رو به پايان رسوندم در حين پياده سازي كار مجبور شدم كه ساختار پروژه رو تغيير بدم يعني بر خلاف تحليلي كه انجام دادم عمليات هاي جديدي رو به سيستم اضافه كنم. معمولاً تيم تحليل يك پروژه هر چقدر هم قوي و با تجربه باشن ولي بازهم در هنگام زمان بندي پروژه يك زماني رو براي Itertate احتمالي در نظر مي گيرن تا بعداً با كمبود وقت و بالا رفتن هزينه مواجه نشن. پس بايد تيم خودش رو براي يك مرحله جديد آماده كنه يك جرقه يا فكر نو مي تونه مسير يك پروژه رو به طور كلي عوض كنه.
3- توانايي انتقاد كردن و مورد اتقاد قرار گرفتن:
معمولاً اگر دقت كرده باشين معلمان يا استادان دوست دارن كه دانشجو كلاسشون ارشون سوال كنه. اين سوال كردن دانشجو اين نويد رو به استاد مي ده كه درسي رو كه داده دانشجو بهش دقت كرده يعني در كلاس حضور داشته. پس بايد آماده جوابگويي به سوال دانشجو باشه چون ممكنه اين سوال كردن ها باعث ايجاد بحث يا جرو بحث(!) در كلاس بشه و بعداً انتقادهايي صورت بگيره. اين موضوع در همه جا صادق هستش در كار، در جلسات، در مديريت و ...
"پس يك تحليل گر در تيم تحليل بايد در جلسات حضور موثر داشته باشه و بتونه انتقاد كنه و يك مدير خوب كسي هست كه به اين انتقاد گوش بده و در برابر اين انتقاد يك راهكار از انتقاد كننده بطلبه و البته از انتقاد ناراحت نشه."

[اوبالیت به بو]

4- رويه مديريتي داشتن:
يك مدير خوب كسي نيست كه سبيل پر پشت يا چهره غضبناك داشته باشه تا همه ازش بترسن. كسي نيست كه فقط دستور مي ده يا تلفن اتاق/اطاق رو ببنده تا كسي مزاحمش نشه كسي هستش كه با تمامي كارمنداش با دقت صحبت مي كنه و هميشه دنبال يك خلاقيت در كارش هست دنبال يك فكر يا ايده نو براي جلو رفتن كار.
داشتن روحيه مديريتي براي يك مدير باعث ميشه تا كارمندانش با مديرشون احساس راحتي كنن و ازش نترسن و با يك خيال راحت ايده ها و طرح هاشون رو ارائه بدن.
5- استفاده بهينه از زمان:
كار يا قشنگ تر بگيم پروژه اي كه توسط يك كارفرما پيشنهاد ميشه نبايد بيشتر از حد معمول طول بكشه تا كارفرما خسته بشه. خوب اينجا ايران هستش و اصلاً براي كارفرما تحليل و UseCase و... مهم نيست تقصيري هم نداره چون نمي تونه اين موضوع رو درك كنه كه داره روي پروژه پيشنهاد شدش كار مي شه. پس براي اينكه خسته نشه ما بايد در كمترين زمان پروژه رو آماده كنيم. در Elecomp امسال كه من شركت كردم از يكي از برنامه نويسان شركت x سوال كردم كه چقدر براي زمان يك عمليات تويه ايران شركت ها ما سرمايه گذار مي كنن؟ جوابي كه داد اين بود كه وقتي يك عمليات با تحليل ها و نموداراش در اختيار من قرار ميگيره توش نوشته كه تاريخ شروع : 7/10/1387 ساعت شروع 9 صبح تاريخ پايان عمليات ساعت 16 همان روز و اگر من كار رو تا قبل از ساعت 4 بعد از ظهر تحويل ندم من جريمه ميشم. مثلاً از حقوقم كسر مي كنن يا مرخصي نمي دن و ...
براي اينكه اين اتفاق نيوفته بهترين راه حل اين هست كه در حين كار حاشيه نريم. يعني در جلسات تحليل بحث هاي غير ضرروي رو وسط نكشيم.
جلسات رو دسته بندي كنيم تا نظم در كار حفظ بشه و تقسيم كار رو براي تيم تحليل فراموش نكنيم.
6- موثر در جلسات:
بهتر هستش كه قبل از شروع جلسه مدير و تحليل گر خودش رو Update كنه و بعد در جلسه شركت كنه.
7- تصميم گيري:
يك مدير موفق در تصميماتش كمتر دچار اشتباه ميشه يعني در يك زمان خاص بهترين تصميم رو ميگيره. مثلاً در تيم تحليل اختلاف نظري وجود داره (مثلاً مجله برنامه نويس) و هر كدوم از تحليل گران يك راهي رو پيشنهاد مي كنن كه اتفافاً راه هر دو تحليل گر درست و خوب هستش و دلايلشون هم كاملاً منطقي و درست هستش و به ادامه روند پروژه خيلي كمك مي كنه اما خوب مدير بايد كاري كنه كه نه سيخ بسوزه نه كباب و يك تصميم درست بگيره. اين تصميم درست مي تونه به نفع هر كدوم از طرفين يا نظر هر دو طرف باشه يا اصلاً مخالفت كنه!
8- جلسات خوب و مفيد:
راستش من زياد تو جلسات شركت نكردم و نمي دونم كه يك جلسه واقعاً خوب چه جلسه اي هستش اما جلسه اي رو كه بنده خودم دوست دارم كه باشه اين هستش كه :

1. خشك نباشه.
2. اجباري نباشه
3. نتيجه داشته باشه.
4. كمي هم مهربانانه و دوستانه باشه. (اخلاقيات و روحيات و عرفان و معرفت و ...)

9- تجربه:
هر پروژه اي يه سري درس هايي به آدم مي ده كه مي تونه در كارهاي ديگه خيلي بهش كمك كنه. يك مدير و تحليل گر خوب و موفق از اول موفق نبوده. شكست خورده و از شكستش درس گرفته. رويه شكستش خيلي فكر كرده و ساعتها با خودش خلوت كرده كه چرا مثلاً اين پروژه به بن بست رسيد.
پس استفاده از مديران و تحليل گران با تجربه خيلي مي تونه به درست جلو رفتن پروژه كمك كنه.
يك قانوني هست كه باعث ميشه هر پروژه اي با موفقيت به پايان برسه اون هم قانون ت ت ت. توكل، تعمق و تفكر.
اميدوارم كه دوستان هم در اين بحث ها شركت كنند و روش ها و راهكار هاشون رو ارائه بدن.

[Mamdos]

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

- تولیدکننده‌ی نرم‌افزار، در ابتدای پروژه کارفرما را از پیچیدگی‌های توسعه‌ی نرم‌افزار و فرق‌هایی که با پروژه‌های معمولی دارد آگاه نمی‌کند. در نتیجه کارفرما با توجه به پیش‌فرض‌های ذهنی‌اش انتظاراتی از تولیدکننده خواهد داشت که احتمالاً بعداً باعث اختلاف می‌شود. مثلاً باید تولیدکننده‌ی نرم‌افزار به کارفرما بگوید که معمولاً چه مشکلاتی در پروژه‌های نرم‌افزاری پیش می‌آید و این که بیشتر پروژه‌های نرم‌افزاری موفقیت‌آمیز نیستند. اگر کارفرما از اول راجع به مشکل خزش نیازمندی‌ها (Requirements Creep) بداند، وسط پروژه پیمانکار را با درخواست‌های جدیدش کلافه نمی‌کند و منجر به اختلافات جدید نمی‌شود.

- تولیدکننده‌ی نرم‌افزار، مشکلات مذکور را به کارفرما می‌گوید ولی کارفرما آن‌ها را باور نمی‌کند! بلکه فکر می‌کند که پیمانکار دارد ناز می‌کند تا قیمت بالاتر بدهد! حل این مشکل هم وظیفه‌ی سازنده‌ی نرم‌افزار است. سازنده‌ی نرم‌افزار باید اعتماد کارفرما را جلب کند. مثلاً می‌تواند منابع دیگر (مثلاً کتب و وب‌گاه‌های مهندسی نرم‌افزار) را به کارفرما نشان بدهد، یا مثلاً گزارش‌های معروف CHAOS از گروه استندیش را که می‌گویند به طور متوسط دو سوم پروژه‌های نرم‌افزاری موفقیت‌آمیز نیستند به او نشان بدهد.

- این مشکل را که دیگر همه می‌دانند: عدم تعیین دقیق نیازمندی‌ها در ابتدا، در اصل یک مشکل ارتباطی است. یعنی ذهنیت کارفرما از نرم‌افزار با آنچه که در ذهن نرم‌افزارساز می‌گذرد فرق دارد. این وظیفه‌ی نرم‌افزارساز است که انتظارات کارفرما را با تعیین دقیق نیازمندی‌ها تنظیم کند.

- در داخل تیم‌ها هم مشکلات ارتباطی زیادی وجود پیش می‌آیند. مثلاً طراح و تحلیل‌گر در مورد قالب مستندات تحلیل و حتی چگونگی تفسیر آن‌ها از ابتدا هماهنگ نمی‌کنند، و بعد از تحویل به طراح، طراح خوشش نمی‌آید و یا با تحلیل‌گر اختلاف پیدا می‌کند (این چیه به من دادی؟!! به هیچ دردی نمی‌خوره! چرا فلان چیز رو نداره؟! اینجاش اشتباهه! اصلاً تو تحلیل بلد نیستی!) یا این که مستندات تحلیل را نادیده می‌گیرد و خودش عملاً یک بار دیگر تحلیل را انجام می‌دهد!

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

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

به طور خلاصه چند راهکار را برای حل مشکلات ارتباطی می‌توان شمرد:
۱. مشکلاتی را که احتمال می‌دهید نمی‌توانید حل کنید هر چه زودتر فاش کنید. حتی اگر بتوانید، بهتر است همه‌ی مشکلات را فاش کنید. سعی کنید فرهنگی در تیم و سایر ذی‌نفعان به وجود بیاورید که از این کار استقبال کند.
۲. همه چیز را از اول با همه در جریان بگذارید، به خصوص ریسک‌ها را. حتی این موضوع را که ممکن است سوء تفاهم‌هایی رخ دهد در اول کار مطرح کنید و راه حل برایش بدهید.
۳. همیشه خود را جای طرف مقابل بگذارید تا بفهمید که او چه انتظاراتی از شما دارد، چه دیدی نسبت به شما دارد و چه اطلاعات نادرستی ممکن است داشته باشد. مثلاً خودتان را جای کارفرما بگذارید تا بفهمید که او چه درباره‌ی شما فکر می‌کند و چه انتظاراتی از پروژه دارد. این طوری می‌توانید راه حلی بدهید که هم به نفع شما باشد و هم به نفع طرف مقابل. این کار باعث می‌شود که اعتماد ایجاد شود و مطمئن باشید که این در نهایت به نفع شما خواهد بود. خودتان را به این کار عادت دهید و سعی کنید به بقیه هم این کار را آموزش دهید.
۴. هیچ وقت به یکبار گفتن چیزی اکتفا نکنید. همیشه ممکن است افراد موضوعی را فراموش کنند، خوب گوش نکرده باشند و حواسشان نبوده باشد، برایشان خوب جا نیفتاده باشد یا بدون این که به شما بگویند مخالف باشند و قبول نکرده باشند. مطمئن باشید این موضوع برای خودتان هم ممکن است اتفاق بیفتد و ربطی به احمق یا فراموشکار بودن افراد ندارد. سعی کنید مطالب (به خصوص مطالب مهم را) کاملاً روشن و با روش‌هایی مانند تصویر و اسلاید منتقل کنید تا کاملاً در ذهن افراد نقش ببندد. اگر لازم است، مطالب را در فواصل زمانی تکرار کنید. البته مواظب باشید افراد احساس نکنند که با آن‌ها مثل احمق‌ها رفتار می‌شود؛ می‌توانید برای حل این مشکل هم از اول با همه هماهنگ کنید که برای پیشگیری از چنین مشکلاتی چنین کاری لازم است. هیچ وقت، هیچ وقت و هیچ وقت کسی را به خاطر فراموش کردن یا نفهمیدن چیزی تحقیر نکنید.
۵. سعی کنید بین ذی‌نفعان (افراد تیم، کارفرما، مشاور و ...) یک جو اعتماد و صمیمیت به وجود بیاورید، و به مسائلی که ممکن است به این جو آسیب بزند حساس باشید و آن‌ها را در اولین فرصت حل کنید.
۶. تا جایی که می‌توانید درستکار و صادق باشید.

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

[اوبالیت به بو]

عواملي كه باعث شد در اولين پروژه انبارداري شكست بخورم:

1. جمع آوري اطلاعات
   
   • عدم درك صحيح از سيستم انبارداري
   • آموزش غلط (يادگيري اشتباه)
   • عدم وجود جلسه براي مشورت يا تامل بر نظر ديگران
2. تجزيه و تحليل
   
   • سناريو ناقص
   • عدم شناخت كافي از نيازمندي هاي كاربر يا ارباب رجوع(!)
   • عدم آشنايي با الگوهاي طراحي
3. طراحي
   
   • بدليل وجود يك سناريو ناقص:
     
     • UseCase هاي اشتباه
     • Class Diagram هاي اشتباه
     • Sequence Diagram هاي اشتباه
   • طراحي اشتباه Data Base بدليل عدم آشنايي با فيلدهاي موجود در Class Diagram

به نظر خودم مهمترين عاملي كه باعث شد به طور كامل پروژه اولم Fail بشه طراحي نامناسب Data Base بود و بعد سناريو. چون اگر سناريو ناقص باشه بازم ميشه پروژه رو جمع كرد(استثنا) نهايتش اينه كه زمان Iterate زياد ميشه.

[Elham_gh]

دوست عزيز obalitjoOon
با اجازتون من هم چند دليل ديگر شكست پروژه رو عنوان كنم.
اين دلايل در مورد پروژه هايي صدق مي كنه كه مي خوان سيستمي رو جايگزين سيستم قبلي كنند.
الف-آناليستها و طراحان چنين پروژه اي توجه ندارند كه كه سيستم جديدشون بايد:

1- حداقل تمام امكانات سيستم گذشته رو داشته باشه.
2- اشكالات سيستم قبلي رو نداشته باشه
3- از سيستم قبلي راحت تر و ساده تر باشه

ب- كه خيلي مهم است و من ديدم كه اكثرا بهش توجه نمي كنند:اطلاعات سيستم قبلي
اكثر تيمهاي تحليل و طراحي به ميزان اهميت اطلاعات سيستم قبلي توجه ندارند و آن رو جزو كارهاي ثانوي يا نهايي مي گذارند.
در صورتيكه همين اطلاعات ممكن پروژه رو fail كنه. به جرأت مي تونم بگم 80% چنين پروژه هايي كه سيستم موجود رو مي خوان با سيستم جديد جايگزين كنند به خاطر همين مسئله fail مي شوند. بررسي وضعيت موجود ساختار اطلاعات و نحوه انتقال و پالايش اطلاعات از ريسكهاي پروژه و از مراحل اوليه كار است. اين كه تيم كارشناس اطلاعات رو بررسي كنند. مشكلات آن را بشناسند و براي بر طرف كردن آنها راه حلي پيدا كنند.

موفق باشيد

[Elham_gh]

و باز با اجازه obalitjoOon ، چند علل شكست پروژه از منابع مختلف:

خبرنامه مدیریت پروژه:

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

برگرفته از کتاب "مدیریت موفق پروژه های IT"
امیر صدیقی مرداد هشتاد و چهار

چرا پروژه های IS شکست می خورند؟ - ۲

انتظار غیر معقول کاربران از یک سیستم اطلاعاتی
یکی از دلایل شکست پروژه های IS است
به طور معمول، عوامل اصلی شکست در پروژه های IS به شرح زیرند :

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

الف – 1 ) عدم تسلط کافی بر خواسته ها از سوی سازمان : گاه مشخصات خواسته ها تعریف جدیدی برای واژه "خلاصه" ارائه می کند. در یک نمونه واقعی، متن سندی که توسط مدیریت ارشد تهیه شده بود و چیزی بیش از علاقه وی به خواسته ای را بیان نمی کرد از دوعبارت کوتاه تشکیل شده بود: "پیاده سازی سیستم صدور صورتحساب با استفاده از اوراکل "

این نمونه مثال خوبی از دو نوع شکست معمول است. اول عدم پرداختن به جزئیات در تعیین خواسته ها، "یک سیستم صدور صورت حساب" می تواند برای افراد مختلف دارای معانی متفاوت باشد. پایه و اساس فعالیتهای سیستم باید مبتنی بر خواسته های واضح و مشخص باشد.

دوم "با استفاده از اوراکل"، پیداست که راه حل در این مثال توسط سازمان مشخص شده است. شاید در جلسه ای با حضور تامین کننده (فروشنده سیستم نرم افزاری) از کاربران نیز دعوت شود و آنها پس از آن برای دیدن نمایش برجسته ای از آنچه در بخش آنها به حقیقت خواهد پیوست، اشتیاق نشان دهند. البته کاربران درپروژه دارای نقشی حیاتی هستند، و در همه حال باید به نظرات آنها احترام گذاشت، ولی نقش آنها این نیست که راه حل تکنیکی و پلات فرم اجرایی را تعیین کنند.

الف – 2 ) عدم وجود فهرست خواسته ها : دامنه پروژه در تعیین مدت زمان و هزینه آن، عاملی کلیدی است. همچنین شاخص خوبی برای میزان تاثیر پروژه بر سازمان پس از اجرا می باشد. اغلب پروژه های IS به سرمایه قابل ملاحظه ای نیاز داشته و می توانند موجب آشفتگی گسترده ای در سازمان شوند. وجود فهرست کامل خواسته ها و قطعیت بر لزوم اجرای آنها و درستی آنها می بایست قبل از آغاز پروژه تعیین گردیده باشد. عموما در آغاز پروژه چنین فهرستی موجود نیست و موجب وجود خطا در محاسبه زمان، و بودجه موردنیاز می گردد.

الف – 3 ) تغییر خواسته ها : شکست در مدیریت خواسته ها منجر به شکست پروژه های بسیاری شده است. از کوچکترین پروژه های IS تا بزرگترین آنها، در صورتی که سازمان نتواند در تمامی اجزای خود بر خواسته ها توافق کند، و یا با تغییر کادر مسئول خواسته هایش تغییر کند، احتمال شکست پروژه افزایش می یابد. خواسته هایی که به طور مکرر تغییر می کنند، از دلایل افزایش هزینه های پروژه ها هستند. نقش کمرنگ سیستم و گاه فقدان چهارچوب مستند و مدون در سازمانهای که موجب اعمال سلیقه شخصی در روند کاربردهای سازمانی است و با تغییر سیاستگذار یا تغییر دیدگاه وی نیازهای سیستمی سازمان را دگرگون می سازد، از مهمترین دلایل شکست پروژهای IS است. سازمانهای موفق، با بها دادن به سیستم به جای افراد، از اعمال سلیقه های شخصی در اجرای پروژه های IS جلوگیری می کنند.

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

الف – 5 ) رهبری ضعیف : گمان نکنید پروژه ای که صرفا در آن مدیریتی صورت می گیرد، پروژه ای موفق است، پروژه های موفق بجای مدیریت افراطی ، نتیجه رهبری قوی هستند. مدیریت و رهبری مطالبی متفاوت هستند.

ب - برنامه ریزی ضعیف پروژه
عدم برنامه ریزی صحیح پروژه علتی مشترک برای بسیاری از پروژه های می باشد. یکی از رایجترین خطاهایی که در طی فرآیند برنامه ریزی صورت می پذیرد، این است که فرض می شود منابع پروژه در تمام مدت زمان پروژه در دسترس قراردارند. (یعنی هر دقیقه ای از روز صرف کار بر روی پروژه می شود) در عمل در یک پروژه IS نیروی موثری که صرف پروژه می شود بسیار پائین تر است. در برنامه ریزی میزان بهره برداری 80% از منابع، یک حداکثر است. ( مقدار حداکثر 80% برای جامعه آمریکایی محاسبه شده است، و در کشور ما این میزان بسیار کمتر است.)

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

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

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

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

ذ‌ - طرح توجیهی ضعیف
پروژه ای که قرار است موفقیت آمیز باشد، باید دارای یک طرح توجیهی قوی با منافع (مالی) قابل سنجش برای توجیه بازار سرمایه ای باشد که برای اجرای آن در نظر گرفته شود. طرح توجیهی باید بوضوح از راهبردهای تجاری و IT سازمان پشتیبانی کند. عدم وجود طرح توجیهی که بر اساس دلایل مستدل و مبتنی بر واقعیتهای سازمان و منافع آن تعریف شده باشد، منجر به آغاز پروژه هایی که منافع واقعی سازمان را دنبال نمی کنند، می گردد.

ر ‌- انتظار معجزه از IS
برخی کاربران و مدیران از IS انتظار معجزه دارند. عدم توجه به این اصل که IS مولد دانش نیست و خلاء دانش و تجربه هرگز، توسط نرم افزار جبران نمی گردد، موجب نارضایتی آنها می گردد. دانش از ذهنهای پویای انسانهای خبره و متخصص سرچشمه می گیرد. IS ابزاری قدرتمند در دست انسان متخصص جهت نیل به اهداف وی در مدیریت اطلاعات و تسریع تصمیم گیری است. خواسته های پیچیده، دور از دسترس همراه با رویکرد "بیگ بنگ" و خلق الساعه به پیاده سازی نیز از این دسته درخواستها می باشد.

ببخشيد كه رشته نوشته هاي شما رو قطع كردم..

[اوبالیت به بو]

اول از هر چيزي يه تعريفي از پروژه داشته باشيم:
پروژه: به هركاري كه در زمينه IT در يك سازمان، شركت، نهاد يا ارگاني انجام ميشه پروژه مي گويند.
قبل از آغاز هر پروژه اي به عنوان يك مدير پروژه بايد به اين نكته توجه داشته باشيم كه الزامات يك پروژه چيه. يعني چي مي خوان از ما و ما چي مي خوايم از كار. حالا براي اينكه الزامات رو بشناسيم بايد با افرادي كه در پروژه درگير هستن گفتگو كنيم. فرض كنيد يك آژانس تاكسي مي خواد يك نرم افزاري رو براي مديريت خودش تهيه كنه. ما به عنوان مدير پروژه بايد يك ديد كاملي از سيستم داشته باشيم. از تك تك رانندگان سوال كنيم كه كارشون چيه با چه كساني سر و كله(!) مي زنن يا از كسي كه تلفن ها رو جواب مي ده درباره كارش سوال كنيم و حتي اگر لازم شد خودمون به عنوان راننده آژانس مدتي كار كنيم يا تلفن ها رو جواب بديم.(كاري كه من كردم و اسمش رو نوعي خلاقيت گذاشتم) به هر حال بايد سيستم رو دقيق بشناسيم. قطعاً اين كار به موفقيت پروژه شما كمك مي كنه.
هميشه سعي كنيد در مسير حركت پروژه قرار داشته باشيد. آقاي Joseph Phillips در كتاب IT Managment Project - on trackfrom Start to Finish مثال خيلي قشنگي مي زنه:

Imagine your favorite archeologist maneuvering through a labyrinth of pitfalls, poison darts, and teetering bridges to retrieve a golden statue. In the movies, there’s always some fool who charges past the hero straight for the booty and gets promptly beheaded. Don’t be that guy. Before you can rush off toward the goal of any given project, you’ve got to create a clear, cobarnamenevise path to get there.

اين مسير حركت آقاي Joseph Phillips همون رانندگي و تلفن جواب دادن من در آژانس هستش. به محض اينكه شما بفهمين چه چيزي براي سيستم نياز دارين بدونين كه پروژه شما شروع شده.
در مرحله دوم بايد هدف رو ببينيم. براي چي داره اين سيستم براي سازمان يا شركت مورد نظر پياده سازي ميشه؟ آيا باعث سود دهي به اون شركت ميشه؟ دنبال چه چيزي هستيم؟ و از اين دست سوالات ...
در مرحله سوم بايد نتيجه كار رو ببينيم. آيا واقعاً نتيجه اي حاصل ميشه؟ آيا مي تونيم پايان رو ببينيم. هميشه از دوستانم كه كار مديريت مي كنن مي شنديم كه مي گفتن "زماني يك تيم تحليل موفق هستش كه تمام اعضا نتيجه نهايي رو بدونن و بتونن اون رو ببينند". دروغ نگم معني حرفشون رو نمي فهميدم اما وقتي خودم در پروژه انبارداري به شكست خوردم متوجه منظورشون شدم. من هيچ ديدي نسبت به سيستم انبارداري نداشتم. نمي دونستم قرار هست چه كاري انجام بشه. و نرم افزار من به چه دردي مي خوره. حالا اگر بخوام يك كاري رو انجام بدم هميشه پايان كار رو مي بينم.
(هميشه به كساني كه كنكور دارن مي گن كه سختيش رو تو اين 1 سال ميكشي اما آخرش كه قبول شدي ستگي از تنت در ميره)

[Elham_gh]

دوست عزيز ، چرا ديگه ادامه نمي ديد؟

[اوبالیت به بو]

صحبت كردن، نوشتن، خواندن كتابهاي مرتبط و مقالات مختلف و غيره و غيره راحت هستش. در واقع گفتنش آسونه اما عمل كردنش سخت. يكي از اين مراحل سخت كه در قسمت قبل بهش اشاره شد مرحله سوم يعني دونستن نتيجه كار هستش.
اكثر كارفرماها دوست دارن نرم افزاري رو كه باهاش كار مي كنن تمام نيازهاشون رو برآورده كنه. خوب اين كارفرماها در مشاغل و حرفه هاي مختلفي مشغول فعاليت هستند و قطعاً يك تيم نرم افزاري نمي تونه از ابتدا اطلاعاتي دقيقي از تمامي مشاغل داشته باشه و اين نياز احساس مي شه كه جلساتي رو با مديران، كارمندان و به طور كلي كاربران نهايي پروژه داشته باشن. تمام اين جلسات به اين دليل برگزار ميشه كه تيم تحليل بتونه يك ديد كاملي نسبت به كار داشته باشه تا بتونه منشور پروژه رو تدوين كنه.
درباره منشور پروژه حتماً بحث خواهد شد.
با مقدمه فوق ناخداگاه اشاره ميشه به همون مطلبي كه همه ازش يك ترسي در ابتداي كار دارن و اونهم مرحله جمع آوري اطلاعات.
روشي رو كه همه ازش استفاده مي كنن و بسيار فراگير هست در بين تيم هاي تحليل اين هستش كه با تمام افراد ذي نفع صحبت مي كنن. يك مدير پروژه بايد با تمامي افراد ذي نفع (الزاماً نه همه) صحبت كنه و اونها رو از نتيجه كار مطلع كنه و به اونها بگه كه چقدر اين سيستم جديد مي تونه در كار روزانه اونها بهشون كمك كنه. به عنوان مثال برخي افراد هستند كه دقيقاً مثل فسيل مي مونن(!) يعني دوست دارن كه با همون روش هاي قديمي كه در ابتدا باهاشون آشنا شدن كار كنن و هيچ احتياجي نمي بينن كه سطح كاريشون رو ارتقا بدن براي همين وقتي مدير پروژه باهاشون شروع به صحبت مي كنه و ازشون اطلاعاتي راجب كار مي خواد شروع به دروغ گفتن مي كنن. چون مي ترسن اگر سيستم جديد جايگزين بشه شغلشون رو از دست مي دن. اينجاست كه يك مدير پروژه بايد مهارت ارتباط رو داشته باشه تا بتونه افراد فسيل رو متعاقد كنه كه باهاش همكاري كنن و اطلاعات لازم رو در اختيارش قرار بدن چون اين سيستم قرار هست كه به نفع اون كاربر كار كنه.
پس روش اول شد صحبت يا ارتباط كلامي با افراد ذي نفع.
اما روشي رو جديداً من از يكي از اساتيد ياد گرفتم كه بسيار زيبا و در عين حال كمك كننده براي جمع آوري اطلاعات هستش و به شما هم استفاده از اين روش رو توصيه مي كنم چون جواب مي ده. اون روش هم اين هستش كه يك نظر سنجي رو از طريق اينترنت يا اينترانت اون سازمان يا شركت برگزار كنيم. حال اگر ما استثنا رو هم در نظر بگيريم و فرض كنيم امكان دسترسي به اينترنت در اون سازمان فراهم نبود مي تونيم يك سيستم ساده رو طراحي كنيم و چند لحظه وقت مبارك كارمندان عزيز و محترم رو بگيريم و ازشون بخوايم كه در تكميل اين بانك اطلاعاتي به ما كمك كنن. اگر به شكل زير دقت كنيد متوجه منظور من خواهيد شد:

اما اين سيستم به نظر من يك ايرادي داره. ايرادش هم اينه كه شايد باعث ايجاد يك ترسي در بين كارمندان بشه و اين ترس ناشي از بردن نام اونها در نظر سنجي باشه. براي همين من خودم پيشنهاد مي كنم كه يك بانك اطلاعاتي ديگه هم تهيه بشه با اين تفاوت كه احتياجي به نوشتن نام نباشه. به شكل زير توجه كنيد:

[سیمین ابراهیمی]

با تشکر از مطالب دوست گرامی
در مدیریت پروژه به قسمت زیر اشاره کرده اید:
قيمت گذاري

• عوامل اصلي تعيين بودجه
• نحوه تخمين زدن قيمت يا بودجه
• بودجه در پايان پروژه {كمبود يا سود}
• مخارج

می شود لطف کنید در این مورد خاص منابعی که می تواند کمک کند را ارائه دهید.یا در مورد مثال زیر مورد بالا را پیاده کنید؟
پروژه نوشتن سیستم اداره یک مدرسه شامل قسمت های زیر:
1-امور اداری
2-امور آموزشی
3-سرویس دهی
4-امور مالی
5-حضورو غیاب ودستمزد
که شامل بر حدود 200 منو با 30 جدول پایگاه داده و WEB BASE که این پروژه فاقد پیاده سازی بستر سخت افزاری می باشد.

[سیمین ابراهیمی]

خیلی به نکته مهمی اشاره کردی ،با توجه به اینکه خیلی ساده به نظر می یاد ولی خیلی مهم بود و به دردم خورد

[Elham_gh]

گويا اين تايپيك به دوستاني كه شغلشون برنامه نويسي هست بي حرمتي كرده و شغل اونها رو بي اهميت نشون داده در صورتي كه ما در اينجا درباره اهميت تحليل در توليد يك كالا كه اسمش نرم افزار هستش صحبت مي كنيم نه بي اهميت جلوه دادن برنامه نويسي و برخي از همين دوستان لطف كردن و از طريق Yahoo Messenger من رو مورد لطف و عنايت قرار دادن. به هرحال پاسخ اين دوستان دوستان برنامه نويس در اين پست داده شده و هر بحثي دارن مي تونن در تايپيك هاي ديگه به اون بپردازن و اونجا كمي مهربانانه تر و مودبانه تر به اين موضوع بپردازن نه در Chat!
برنامه نويسي شغل شريفي است...

من كه متوجه نشدم چرا دوستان برنامه نويس با مطالب شما مشكل داشتند اما حيف است كه بحث نيمه كاره بمونه.پس لطفا ادامه بدين

[Elham_gh]

دوست عزيز obalitjoOon ، شايد جاي اين مطلب از لحاظ ترتيب اينجا نباشه . پس لطفا خودتون اونو در جاي مناسب قرار بدين و يا اگه لازم باشه تفكيك كنيد .

نكته بعد اينكه من واقعا يادم نيست مطلب رو از كجا اورودم، من فايلشو داشتم ، به هر جهت منبع اصلي Wikipedia است.

تاریخچه مدیریت پروژه
مدیریت پروژه در زمینه های گوناگون کاربردی شامل ساختمان سازی،مهندسی ودفاعی گسترش یافته است. در ایالات متحده امریکا،پدر مدیریت پروژه، هنری گانت (Henry Gant)است که به عنوان پدر علم برنامه ریزی وروشهای کنترل نیز شناخته شده است. شهرت او به چند عامل بستگی داشته است: اول به خاطر استفاده از گانت چارت که یکی از ابزارهای کنترل پروژه محسوب می شود .دوم به خاطر همکاری با Fredrick Winslow Taylor در تئوری علمی مدیریت ودر نهایت شهرت او به علت مطالعاتش بر روی کار ومدیریت ساختمان کشتی نیروی دریائی بوده است.او در بسیاری از موارد از جمله استفاده از ساختار دسته بندی کسب وکار(WBS)وهمچنین تخصیص منابع پیشگام بوده است.
سالهای 1950به عنوان شروع مدیریت پروژه جدید شناخته شده است. در امریکا در اوایل سال 1950 پروژه ها غالبا به طور خاص براساس گانت چارت وبا روشها وابزارهای غیر رسمی مدیریت می شدند. درآن زمان دو مدل ریاضی برای جدول زمان بندی وجود داشت:
1-فن ارزیابی و بازنگری برنامه یا PERT (Program Evaluation and Review Technique ) که توسط Booz-Alen وHamilton ابداع شد.
2-روش مسیر بحرانیCPM )Critical Path Method)-این روش با مشارکت دو انجمن Du Pont وRemington Rand به منظور مدیریت پروژه های تعمیر ونگهداری طراحی شد.این روشهای ریاضی به سرعت در بسیاری از شرکتهای خصوصی گسترش یافت. در همان زمان روشهای برآورد قیمت تمام شده،مدیریت هزینه واقتصاد مهندسی توسط Hans Lang ودیگران در حال گسترش بود. درسال1965،انجمن مهندسین هزینه امریکا (که در حال حاضرانجمن بین المللی AACEمی باشد وهدفش پیشبرد علم مهندسی هزینه است)توسط اولین کاربران مدیریت پروژه وانجمن متخصصین برنامه ریزی وبرنامه زمان بندی،برآورد هزینه وکنترل زمان-هزینه تأسیس شد.AACE فعالیتهایش را ادامه داد ودرسال 2006اولین وکاملترین روش برایPORTFOLIO(اوراق بهادار)وبرنامه ریزی ومدیریت پروژه را منتشر کرد.(ساختار کامل مدیریت هزینه) در سال 1969،انستیتو مدیریت پروژهPMI)) به منظور سرویس دهی به صنعت مدیریت پروژه تشکیل گردید.فرضیه PMIاین است که علیرغم کاربردهای گسترده مدیریت پروژه در حوزه های مختلف از پروژه های صنعت نرم افزاری گرفته تا صنعت ساختمان سازی ابزار وروشهای آن مشترک هستند. در سال1981،PMI تصمیم گرفت که یک کتابچه راهنما برای شناخت مدیریت پروژه (راهنمای PMBOK)منتشر کند این کتابچه شامل استانداردها وراهنمائی های عملی است که در بحث های تخصصی کاربرد فراوانی دارد. در سال 1967،انجمن بین المللی مدیریت پروژه IPMA در اروپا تأسیس شد وآن هم به نوبه خود دستخوش تحولات وپیشرفت هائی گردید و انجمن ICB( Competence Baceline Institute)را تأسیس کرد.تاکید این انجمن بر روی تجارب قابل اعتماد،مهارت های شخصیو تشخیص صلاحیت می باشد.هر دوی این انجمن ها در حال حاضر در تهیه وتنظیم استاندارد ISO برای مدیریت پروژه می باشند.

تعاریف
PMBOK( که به عنوان انستیتو مدیریت پروژه می باشد)مدیریت پروژه را این گونه تعریف می نماید:مدیریت پروژه ابزاری برای شناخت ،مهارت وروش های فنی است تا فعالیتهای پروژه را به نیازهای اصلی (اهداف)پروژه برساند. PRINCE2برنامه ریزی،نظارت وکنترل همه جانبه پروژه وبرانگیختن تمام افراد مرتبط با پروژه به منظور موفقیت پروژه یعنی دست یابی به اهداف پروژه در زمان مشخص ،باقیمت مشخص،کیفیت مشخص وراندمان مشخص PROJECTپروژه یک کار موقتی با تاریخ خاتمه مشخص است که به منظور ایجاد یک محصول منحصر به فرد ویا خدمات مشخص انجام می شود- هدف از اجرای پروژه برآورده کردن ایده ها ویانیازها می باشد DIN69901(سازمان آلمانی جهت استاندارد سازی) مدیریت پروژه یک سری وظائف کامل ،روش ها وابزاری است که در طی اجرای پروژه به کار گرفته می شود.
مرجع مقالات مدیریت پروژه http://www.ghadirtrain.com مدیریت پروژه نام آوران غدیر

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

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

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

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

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

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

دیدگاهها
دیدگاههای متفاوتی برای مدیریت فعالیتهای پروژه وجود داردازجمله : سرعت،تعامل، پیشرفت وفازبندی فارغ از نوع دیدگاه مورد استفاده با عنایت وتوجه خاصمی بایست نتایج،اهداف و وظائف ومسئولیتهای همه افراد مرتبط با پروژه از جمله سهامداران را به طور واضح روشن وشفاف ساخت.

دید گاه سنتی
دیدگاه سنتی 5 مرحله پشت سرهم را برای تکمیل پروژه ضروری می داند.در این دیدگاه لازم است ابتدا 5 مولفه یک پروژه (4 فاز +مرحله کنترل)را در مراحل پیشرفت پروژه تشخیص دهیم.
1- مرحله اولیه پروژه
2- برنامه ریزی یا فاز طراحی
3- اجرای پروژه یا فاز اجرائی
4- نظارت پروژه وسیستم های کنترل
5- فاز تکمیل پروژه
لازم به ذکر است که نیازی نیست در همه پروژه ها این 5 مرحله به اتمام برسد. مثلاً در بعضی پروژه ها ممکن است فاز برنامه ریزی ویا نظارت وجود نداشته باشد ودر بعضی پروژه ها مراحل 2و3و4 چندین بار تکرار شود. در خیلی از صنایع از این چند مرحله استفاده می کنند. به طور مثال در طراحی معماری با مصالح بنائی (آجر وملات) پروژه ها از مراحلی چون پیش طراحی، طراحی تصوری (ادراکی)،طراحی شماتیک، طراحی توسعه ونقشه کشی ساختمان و... استفاده می کنند. در نرم افزارهای توسعه،این دیدگاه غالبا به عنوان آبشار توسعه شناخته می شوند.

مختصری در باره Enterprise Project Management 2007
شرکت Microsoft در راستاي تکميل و توسعه قابليت هاي نرم افزار MS Project و به منظور ارائه يک راه‌حل جامع مديريت پروژه به مشتريان مجموعه محصولات نرم افزاري را به همراه چارچوب پياده سازي آنهاEIF(Enterprise Implementation Framework) در سازمان ها ارائه داده است. اين خانواده محصولات نرم افزاري شامل موارد زير هستند:
‎
• Microsoft Project Professional 2007
• Microsoft Project Server 2007
• Microsoft Project Web Access 2007
• Microsoft Sharepoint Services 2007
• Microsoft SQL server and Analysis services 2007
• Microsoft Project Portfolio Server 2007

براي همه سازمان هايي که MS Project را به دليل کاربر پسند بودن، سهولت استفاده و قابليت هاي يکپارچگي با مجموعه Office براي پاسخگويي به نياز برنامه ريزي و کنترل پروژه انتخاب کرده¬اند و به دنبال توسعه همکاري اطلاعاتي تيم پروژه، کنترل مدارک پروژه و مديريت قوي¬تر منابع و گزارش¬گيري ساده¬تر و سريع تر از وضعيت پروژه¬هايشان هستند راه حل جامع مديريت پروژه EPM راه حل ايده¬آل و قابل اعتماديست که کاهش ريسک پروژه و افزايش بازگشت سرمايه (ROI) را به همراه خواهد داشت.

منابع
سایت مدیریت پروژه ایران
پیاده سازی راهکار مدیریت پروژه جامع EPM
آموزش Project Server
برگرفته از «http://fa.wikipedia.org/wiki/%D9%85%...88%DA%98%D9%87

[اوبالیت به بو]

متاسفانه تويه ايران همه ي افرادي كه در حوزه IT فعاليت مي كنن(چه برنامه نويس، چه مدير، چه تحليل گر و چه...) از يه چيزي گله مي كنن و اون هم اين كه چرا بازار نرم افزار اينجوريه؟ چرا اونجوريه؟ چرا كسي به نرم افزار توجه نمي كنه؟ چرا همه كار مارو دست كم ميگيرن؟ و از اين قبيل سوالات.
تنها پاسخي كه من بي تجربه مي تونم بدم اينه كه مشكل خود شما هستيد. شما كار خودتون رو دست كم ميگيريد. شما خودتون به فرآيند توليد نرم افزار اهميت نميدين. كافيه فقط روند ساخت اين برنامه رو خودتون ملاحظه كنيد. اگر ما به تحليل اهميت بديم، اگر ما نمودارها رو جدي بگيريم، اگر ما مستندات نرم افزار رو براش ارزش بذاريم قطعاً ديگران نيز به كار ما ارزش قائل خواهند بود. اگر به نرم افزار فقط به ديد برنامه نويسي نگاه كنيم هيچ وقت موفق نخواهيم شد. بارها شده كه سر قيمت پروژه اختلافاتي پيش اومده يا اينكه قيمت پايين باعث دلسردي برنامه نويس از كارش بشه. نمونش در تالار مباحث مربوط به ارزیابی نرم افزار كاملاً مشهود هست.
منشور پروژه چيست؟
منشور پروژه يا چشم انداز پروژه يه سندي هستش كه حالت روحي رواني داره. اكثر ما اين تجربه برامون پيش اومده كه پروژه هامون دچار Iterate شده، يا در ميانه هاي راه با كمبود بودجه مواجه شديم، يا وسط كار دلسرد شديم يا حوصلمون سر رفته و ... شيطونه ديگه كاريش نميشه كرد.
منشور پروژه در واقع نوعي اعتبار و حس مسئوليت پذيري نسبت به پروژه هستش. شايد با مثال كمي راحت تر بتونم اين مطلب رو بگم:
سناريو: سايت Barnamenevis.ORG مي خواد سرورهاي خودش رو جابه جا كنه و مي خواد به جاي كار با 3 سرور با 5 سرور كار كنه و سرورهاش مجهز به سيستم عامل Windows باشن.
حالا ببينيد كه منشور پروژه چقدر زيباست و چقدر لذت مي بره ادم از كار مديريت پروژه.

پروژه: ارتقاي تعداد سرورها و همچنين ارتقاي سيستم عامل آنها به Server 2003
صاحب پروژه: DelphiAssistant
مدير پروژه: obalitjoOon
تيم پروژه: علی کشاورز ، Elham_gh ، Identifier
هدف پروژه: ارتقاي تعداد سرورهاي سايت از 3 سرور به 5 سرور و مجهز كردن سيستم عامل همه سرورها به ويندوز Server 2003 تا پايان فروردين 1388
توضيحات مربوط پروژه: از پنج سال پيش كه سايت برنامه نويس راه اندازي شد، اين سايت با وجود مشكلات زيادي كه از بابت سرورها تحمل كرده است روند روبه رشد بسيار خوبي داشته است و به پيشرفت هاي چشمگيري رسيده است. در ابتدا سرورهاي شماره 1 و شماره 3 اين سايت با سيستم عامل Novell و سرور شماره 2 اين سايت با سيستم عامل NT كار كرده است. اما به دليل پيشرفت تكنولوژي صاحب سايت تصميم به افزايش كارايي و قدرت سايت گرفته اند، لذا براي يكپارچه سازي سيستم عامل هاي سرورها تصميم به مجهز كردن تنها يك سيستم عامل واحد يعني Server 2003 گرفته اند. كاربران اين سايت از فرسوده بودن و از رده خارج بودن سرورهاي اين سايت ناراضي مي باشند و صاحب سايت اين زمان را بهترين فرصت براي ارتقاي سرورهاي خود مي داند. وي مي خواهد كه سرورهاي سايت مجهز به تكنولوژي استفاده از چند پردازنده ها باشند و از امنيت بالايي برخوردار باشند تا در صورت حملات افراد نادان(!)‌سايت در امان باشد. از نظر ما بهترين سيستم عامل براي سرورها ويندوز Server 2003 مي باشد زيرا اين سيستم عامل امنيت بالايي دارد و باعث افزايش سرعت در سايت و جلوگيري از ترافيك هاي احتمالي مي شود.
منابع پروژه:

• بودجه: يكصد ميليارد ريال
• تست ازمايشي به مدت 1 ماه

نتايج:

• تهيه، تنظيم و نصب 5 سرور با مشخصات مذكور
• نصب سيستم عامل ويندوز Server 2003 بر روي تمامي سرورها
• تحويل پروژه به صاحب سايت

تاريخ هاي مهم:

• بهمن 1387: به دليل آغاز سال نو شمسي بهتر است هر چه زودتر جهت خريداري سرورهاي مذكور اقدام شود و حداكثر تا پايان هفته چهارم اين ماه سرورها نصب گردند.
• نيمه اول اسفند 1387: نصب سيستم عامل ويندوز Server 2003 تا پايان پانزدهم اين ماه بر روي تمامي سرورهاي نصب شده.
• نيمه دوم اسفند 1387: به دليل آغاز عيد نوروز و تعطيلات بهاره اين سايت از تاريخ 15 اسفند تا اواسط ماه فروردين سال 1388 تعطيل مي باشد و اين بهترين فرصت جهت تست امنيت و قدرت پردازش سايت مي باشد.
• نيمه دوم فروردين 1388: تحويل پروژه به صاحب سايت

زيبا نبود؟ چند نفر اين كار رو انجام مي دن؟ چقدر به اين اطلاعات اهميت ميديم؟ كافيه به دقت متن بالا رو بخونيم.

1. بودجه كاملاً مشخص هستش يعني قبل از شروع كار بودجه مشخص شده.
2. امكان نداره پروژه با كمبود زمان مواجه بشه چون همه چيز از قبل برنامه ريزي شده.
3. صاحب سايت به هيچ عنوان داخل كار ما دخالت نمي كنه چون همه چيز به ما سپرده شده
4. يه سري اطلاعات جزئي از سايت داريم و مي دونيم كه اين پروژه يه پروژه مهمي هستش چون قيد شده كه اين سايت پيشرفت خوبي داشته و رشد چشمگيري داشته پس مجبوريم اهميت بديم به كار و من به عنوان مدير پروژه وظيفه مهمي دارم.
5. معلوم هست كه سايت معتبري هستش چون رويه امنيت خيلي تاكيد شده. پس من به عنوان مدير پروژه وظيفه مهمي دارم.
6. سايتي هستش كه به كاربراش خيلي اهميت مي ده و مي خواد كه كاربراش با سرعت بالا تويه سايت حركت كنند. پس من به عنوان مدير پروژه وظيفه مهمي دارم.
7. سرورهاي سايت مي خوان كه به روز رساني بشن و چون سايت معتبري هست من و تيمم بايد تمام تلاشمون رو بكنيم تا بهترين سخت افزار ممكن رو براي سايت تهيه كنيم.
8. بايد براي جلب رضايت صاحب پروژه، پروژه رو سر وقت تحويل بديم و تا جاي كه مي تونيم در هزينه ها صرفه جويي كنيم تا سود بيشتري رو از اين پروژه ببريم.
9. پروژه نتيجه داره يعني مي دونم كه قراره چي كار بايد انجام بدم.
10. هدف هام مشخص هستش پس نبايد نگران مساله ديگه اي باشم.
11. و...

اين پست رو چندين بار بخونيم. ضرر نمي كنيم. كاملاً مشخص هستش كه با منشور پروژه ميشه خيلي از مشكلات رو حل كرد. حس مسئوليت، اتحاد تيمي، صرفه جويي در هزينه ها، عدم اتلاف وقت، ايجاد روحيه تيمي، ايجاد فضاي شاد و دلگرم كننده براي اعضا، جلب رضايت مشتري، سود بيشتر و ... مي تونه با رعايت خيلي از اين مسائل به تيم تذريق بشه به شرطي كه از خودمون شروع كنيم و اينقدر به گله و شكايت از اين و اون نپردازيم.

كافيه به پروژه هاي بزرگ عمراني مثل سد سازي، ساختمان سازي، مخابرات و غيره نگاه كنيم. چرا اونها اينقدر براشون اعتبار داده ميشه؟ چون پيمانكاران پروژه به كارشون اهميت مي دن و براش احترام مي ذارن.

[Elham_gh]

obalitjoOon گرامي،ممنون از مطالب خوانديتون.
مطلبي كه بايد در كنار مطالب كاربرديتون مطرح كنم اينه كه يك سهم مهمي از منشور پروژه به ريسكهاي پروژه تعلق دارد. نديد گرفتن اين ريسكها ، پروژه را با بحران مواجه خواهد كرد.
يعني بند شناسايي ريسكها و تعيين ميزان اهميت آنها و بند برنامه زمانبندي حمله به ريسكها رو نبايد فراموش كرد.

بازم ممنون

[alimokhlesi]

با تشکر از اوبالیت عزیز
لازم به ذکره به چند نکته کوچیک اشاره کنم
البته من به اندازه دوستان تجربه و علم کافی ندارم ولی اون چیزی که به ذهنم میرسه رو میگم تا دوستان کمکم کنن:
چشم انداز پروژه می تونه به همراه خودش یه چیزی شبیه به WBS داشته باشه یعنی مراحل انجام کار توش مشخص بشه تا مدیر یا مدیران پروژه راه رفتن تارسیدن به هدف براشون واضح تر باشه. صرف مشخص کردن اهداف و ارائه ی حس مسئولیت پذیری نمی تونه کافی باشه . دلیلش هم واضحه . اگه راه مشخص نباشه هر مدیری به طبع فکر و درک خودش برنامه ریزی انجام پروژه رو پیاده می کنه و این قطعا پروژه رو با چالش جدی مواجه می کنه
تعیین خط و روش انجام کار (این چیزی برخلاف تعیین معماری سیستم است) کمک میکنه تا مدیران بعدی یا مدیران جدیدی که قراره به پروژه اضافه بشن بدونن قراره چی کار کنن و از چه راهی به هدف برسن.
بررسی منابع در کنار ریسک پذیری پروژه بسیار با اهمیته. منابع مالی ، انسانی ، زمانی و... می تونن رو پروژه تاثیرات زیادی بزارن. به عنوان مثال شما دارید برای یک وزارتخانه برنامه می نویسید .ممکن بر اثر یک تصمیم که در معادلات سیاسی گرفته میشه ساختار برنامه ریزی شما تحت تاثیر کمبود منابع زمانی قرار بگیره.یا مثلا یکی از افراد پروژه به هر دلیلی (فوت و...) دیگه نتونه با شما همکاری داشته باشه.
نکته دیکه سینک یا هماهنگ نبود اجزای انجام دهنده پروژه است برای خودش یک داستان طول دراز داره که قطعا مدیران پروژه باهاش برخورد داشتن ( مثلا سناریوی ناقص یا کسی که در منصب خودش انقدر قدرت پیدا کرده که به سادگی با تحرکاتش کل پروژه رو تحت تاثیر قرار میده).در نتیجه سیستم خوب مدیریت میشه که مستقل از اجزا باشه
به علاوه کج سلیقگی های مدیران ارشد مالی واداری خودش نیز مزیدی است بر دلایل شکست پروژه . معمولا مدیران همیشه در همه ی کارا دخالت می کنن (شاید می خوان بگن ما هم هستیم ).
.....

[اوبالیت به بو]

چند روز بود كه فكر مي كردم در پست جديد چه چيزي رو بنويسم و بعد به اين فكر افتادم كه يه مساله كوچيكي رو كه خودم به تازگي جرقش به ذهنم خورد رو مطرح كنم. اكثر ما به صورت تك نفره پروژه ميگيريم يا نهايت تيممون 2 يا 3 نفر بيشتر نيست. وقتي يه پروژه اي رو تحويل ميگيريم بايد در زمان بندي پروژه يك زماني رو براي تحقيق يا آموزش درباره اون مساله در نظر بگيريم. من يه مثالي رو عرض مي كنم:
فرض كنيد آقاي بنده نوعي مثلاً obalitjoOon تا حالا كار وب انجام نداده و تاحالا پروژه هاي تحت ويندوزي نوشته. يك روزي يه جا يه نفر ازش يه وب سايت مي خواد و اين آقا پروژه رو قبول مي كنه. چه اتفاقي مي افته؟ اينجاست كه بايد يه زماني رو حتماً بايد براي آموزش خودش در نظر بگيره. شايد يكي از دلايلي كه اين آقا رفت PHP ياد گرفت همين بود. شايد مبلغ زيادي رو هم نگرفت چون اون چيزي رو كه مي خواست نشد، نه 3 لايه بود، نه OO بود، مدام SQL Injection مي شد (و ميشه)، RegEx استفاده نشده بود و از حلقه ها و شرط ها استفاده شده بود ... اما بالاخره بايد از يه جايي شروع مي كرد و چه بهتر كه با يه پروژه شروع به يادگيري يه زبان يا تكنولوژي بكنيم. كار خطرناكي هستش اما بايد ريسك كرد. بترسيد و اقدام كنيد اما اقدام كنيد.
اين آقا بايد يه زماني رو بايد صرف يادگيري يه زبان برنامه نويسي تحت وب مي كرد و حالا بايد زماني رو براي آموزش تكنيك ها و مباحث امنيت بكنه. اينها همه وقت هستن. ساعتها، روزها، ماه ها و ...
بايد براي موانع فكري كرد و براشون برنامه ريزي دقيقي رو در نظر گرفت.

مديريت پروژه همين چيزهاي ساده هستش.

[accpascal]

من متاسفانه دیر وارد شدم
نکات بسیار مفیدی از دوستان آموختم جند نکته کوچک هم من اضافه می کنم
1 - صحبت از پروژه است خوب هر پروژه ای هدف یا اهدافی دارد که مهمترین قدم در موفقیت بار بودن پروژه شناخت کافی از هدف می باشد
بنظر من طرح ریزی پروژه همیشه از آخر شروع می شود و تولید آن از اول
اگر هدف را به میزان کافی بشناسی می توانی راه رسیدن به آنرا بهتر پیدا کنی!
2 - تقسیم بندی پروژه به پروژه های کوچکتر یا اینکه شکستن هدف به اهداف اولیه یا ثانویه و . . .
3 - حالا وقت برداشتن گامهای اولیه است که این سخنان فلسفی تبدیل به روشهای علمی بشود

[m_test]

ممنون میشم راجع به ریسک های ی پروژه نرم افزاری هم صحبت بشه
اگه سیستمش انبار داری باشه ملموس تر هست
مثلا با عنوان ریسکهای موجود در تولید نرم افزار سیستم انبار
با تشکر

[alborztranslate]

گروه ترجمه تخصصی البرز لیست مقالات ترجمه شده مدیریت و همچین جدیدترین مقالات ترجمه شده isi مدیریت را در سایت خود جهت دانلود قرار داده' علاقه مندان میتوانند به سایت "گروه ترجمه تخصصی البرز " مراجعه کرده و به دانلود مقاله های ترجمه شده اقدام کنند.