اندکی در مورد مدیریت پروژه - قسمت اول

مطلب پایین در مورد مدیریت پروژه است که این حقیر نوشته ام .

مدیریت در این سطح ها انجام خواهد شد :
* Project Scope Management
Project Time Management *
Project Cost Management *
Project Quality Management *
Project Human Resource Management *
Project Risk Management *
Project Integration Management*

توضیح مختصر و در حد معلومات خودم در مورد Term های بالا , Scope یعنی مشخص کردن محدوده سیستم , که این محدوده رابطه مستقیمی با Time و Cost داره که این سه تا با هم یک مثلث آهنی رو تشکیل میدهند , چنانکه اگر دامنه پروژه بزرگ بشه پس زمان و هزینه بیشتری در پی خواهد داشت .

و اونای دیگه هم که معلومند .

به طور خلاصه مراحل در یک پروژه نرم افزاری به صورت زیر است :
Initiating: همان مرحله نیت کردن است . در این مرحله شما نیت می کنید که فلان پروژه رو شروع کنید .  البته خوده این بخش نیت کردن خودش عالمیه ,  اگر عمری باشه حتما ریز به ریز توضیح خواهم داد .

Planning: طرح ریزی و تصمیم گیری اینکه این پروژه چگونه کامل خواهد شد .

Executing : بعد از طرح ریزی , تیم کاری مشغول به کار خواهند شد .

Controlling: تیم کاری توسط مدیر (ها) کنترل می شوند .

Closing : همان بهشت برین .

البته بین مراحل Planning و Controlling و Executing ممکن است Iteration باشد .

هر یک از مراحل رو می توان به صورت جداگانه در نظر گرفت, یعنی : PDCA : Plan-Do-Check-Act

PLAN: برای یک بخش طرح ریزی انجام می دهید . این همون بخش planning بود که قبلا اشاره شد .

Do : طرح تون رو پیاده سازی می کنید . این همون Executing بود که قبلا اشاره شد .

Check : اینم مثل همون بخش کنترل است که گفته شد .

Act : ممکن است بخواهید بهبودی در روند اجرای این پروسه بدهید , به عبارت دیگر این مرحله , مرحله بازنگری است . و برگشت به نقطه Plan دوباره .

موفق باشید

چرا نرم‌افزارها می‌میرند؟

این مطلب پایین برگرفته شده است از دیدگاهی در مجله شبکه می باشد .

اشاره : معمولاً وقتی سازمان یا شرکتی نرم‌افزاری را سفارش می‌دهد، هیچ‌گاه به این موضوع فکر نمی‌کند که ممکن است قبل از تحویل گرفتن آن، نرم‌افزار او بمیرد و از آن محصول نتواند استفاده کند. یا اگر نرم‌افزار را سالم تحویل بگیرد باز هم به این موضوع فکر نمی‌کند که این نرم‌افزار روزی می‌میرد.
معمولاً وقتی سازمان یا شرکتی نرم‌افزاری را سفارش می‌دهد، هیچ‌گاه به این موضوع فکر نمی‌کند که ممکن است قبل از تحویل گرفتن  آن، نرم‌افزار او بمیرد و از آن محصول نتواند استفاده کند. یا اگر نرم‌افزار را سالم تحویل بگیرد باز هم به این موضوع فکر نمی‌کند که این نرم‌افزار روزی می‌میرد. سازمان‌های بزرگ هزینه‌های قابل‌توجهی را صرف خرید تجهیزات IT از سخت‌افزار گرفته تا نرم‌افزار و تجهیزات شبکه‌ای می‌کنند و نکته قابل توجه این‌که بیشترین درصد خرابی و مشکلات از آن نرم‌افزار است، اما به راستی چرا این‌گونه است؟ چرا در اکثر پروژه‌های نرم‌افزاری کشورمان این مشکل دیده می‌شود؟ تجربه شخصی من برای پاسخ دادن به این سؤالا‌ت، عدم توجه به هشت نکته مهم را دخیل می‌داند:  1- یکی از مشکلات پروژه‌های نرم‌افزاری نداشتن برنامه کاری یا داشتن برنامه زمان‌بندی غیرحقیقی است. به عنوان مثال، در حالی که نظر کارشناسی این است که مدت زمان اتمام پروژه با توجه به اجزای آن چهار ماه طول خواهد کشید، شما به عنوان مدیر پروژه نرم‌افزاری نباید قول بدهید که پروژه دو ماه دیگر به اتمام می‌رسد. این کار باعث خواهد شد به دلیل کمبود وقت کیفیت نرم‌افزار کم شود.  2- به‌کارگیری نرم‌افزاری که کیفیت پایینی داشته باشد حتماً با شکست روبه‌رو می‌شود. تصور کنید که روی اجزای سیستم‌های نرم‌افزاری آزمایش کاملی صورت نگیرد و از روش‌های آزمایش مکرر در هنگام برنامه‌نویسی استفاده نشود. اگر نیازهای کاربران (نه به صورت کامل بلکه جزئی) تغییر کند سیستم دیگر نمی‌تواند قابل استفاده باشد.  3- نباید فکر کنیم اتفاق خارق‌العاده‌ای رخ می‌دهد و کاربران سیستم همان‌گونه که ما به آن‌ها می‌گوییم، با سیستم رفتار می‌کنند. شاید ورود اطلاعات زیاد و رفتارهای مختلف کاربران در سیستم تأثیر داشته باشد و باعث شود نتیجه خوبی از پروژه نگیریم.  4- اگر چه تغییر کلی نیازهای کاربران پروژه نرم‌افزاری را با مشکل روبه‌رو می‌کند، اما باور کنید که کاربران نیازهای جدیدی خواهند داشت. بهتر است در پروژه‌های نرم‌افزاری از روش‌های آبشاری قدیمی استفاده نکنیم و از روش‌های نوین مانند test driven development بهره بگیریم. (برای اطلاعات بیشتر به این نشانی مراجعه کنید)  5- در پروژه‌های نرم‌افزاری از نیروهای آزموده و حرفه‌ای استفاده کنیم. اگر چه نیروهای غیرحرفه‌ای می‌توانند برنامه‌های کوچکی تولید کنند، اما پروژه‌های نرم‌افزاری بزرگ هم به تخصص و تجربه زیادی نیاز دارند. به صرف این‌که فردی تنها تحصیلات دانشگاهی عالی در رشته نرم‌افزار دارد نمی‌توان گفت که می‌تواند عضوی از تیم پروژه باشد. در انتخاب نیروهای پروژه دقت کنید، چون دلیل از بین رفتن اغلب پروژه‌های نرم‌افزاری استفاده از نیروهای غیرمتخصص است.  6- برخی از کاربران سیستم که خود به استفاده از سیستم راغب نبودند و سرپرستشان آن‌ها را مجبور می‌کرد از سیستم استفاده کنند، در مقابل سیستم و نرم‌افزار مقاومت می‌کردند و می‌خواستند همچنان به صورت دفتری کار خود را انجام دهند، زیرا به نظر آن‌ها استفاده از سیستم‌های نرم‌افزاری حیطه وظایف آن‌ها را محدود می‌کند و نمی‌گذارد آن‌ها در انجام وظایف کوتاهی کنند (یا به عبارتی از زیر کار در بروند). شاید هم هنوز به نرم‌افزارها اعتماد ندارند و بر این گمانند که مغزشان در امور محاسباتی از کامپیوتر بهتر کار می‌کند.  7- کاربران اصلی سیستم در طول مراحل طراحی نرم‌افزارها حضور ندارند، به همین دلیل است که وقتی نرم‌افزار آماده می‌شود می‌خواهند آن را تغییر دهند. کار آن‌ها مانند این موضوع است که تنها اندازه‌های خود را به خیاط بدهیم و بگوییم حوصله پرو را نداریم. حاصل کار شاید لباسی باشد که اندازهِ شما باشد، اما به احتمال خیلی زیاد کارایی کافی را نخواهد داشت.  8- فرض کنید نرم‌افزار عاری از اشکال است و در اختیار کاربر قرار می‌گیرد. حال اگر کاربر به دلیلی وقت خود را صرف ایرادگیری از سیستم کند یا اطلا‌عات مورد نیاز را به آن وارد نکند پروژه نرم‌افزاری به نتیجه نخواهد رسید. برخی از کاربران سیستم فکر می‌کنند که وظیفه برنامه‌نویس وارد کردن اطلاعات به سیستم است. در کشورهای صنعتی درصد مشکلات پروژه‌های نرم‌افزاری بسیار کمتر از کشور ما است. تجربه به ما نشان داده که تقریباً بیست‌درصد از پروژه‌های نرم‌افزاری کوچک و حدود ده تا پانزده درصد از پروژه‌های نرم‌افزاری بزرگ مشکل دارند. در واقع این پروژه‌ها آنقدر مشکل دارند که نمی‌توان آن‌ها را اصلاح کرد. جالب‌تر این‌که برخی از مدیران پروژه‌های نرم‌افزاری که پروژه‌‌هایشان با مشکل روبه‌رو می‌شود، نمی‌خواهند این واقعیت را بپذیرند که نرم‌افزارشان مرده است و دیگر نمی‌توان کاری برایش انجام داد. به عنوان مثال، حدود دو سال پیش در یکی از سازمان‌های دولتی به وسیلهِ گروهی که تخصص نرم‌افزاری نداشته و تنها فنی بودند سیستمی طراحی شد و تیم نرم‌افزاری مسئولیت اجرای آن را به عهده گرفت. بعد از آماده سازی محصول کاربر سیستم تغییرات زیادی در سیستم به وجود آورد که ساختار کلی آن را تغییر داد و هنوز بعد از این همه مدت هیچ‌گاه سیستم عملیاتی نشده است. نمی‌توانیم تمامی اشکالات را به کاربر یا مدیر پروژه نسبت بدهیم. به نظر من اگر بتوانیم تمامی هشت نکته‌ای را که در بالا اشاره شد، در نظر بگیریم، درصد کمتری از پروژه‌های نرم‌افزاری ما با شکست روبه‌رو می‌شوند.

آموزش تصویری کورس مدیریت پروژه

با سلام,

Tags : Project Management Training Video , PMP Course PASS, PMP Video , Learn PM , PMP , مدیریت پروژه , آموزش

CBT Nuggets - Project Management Professional (Training Vid)

CBT Nuggets - Project Management Professional (Training Video)

PMP Certification Package
Project Management Professional
$300.00 - Includes 30 Videos

Trainer: Steve Caseley (Trainer Comments)
Running Time: 15 Hours

Certification information from Project Management Institute [

Contents: Project Management Professional Exam-Pack for PMP certification

- What is Project Management
- The PMP and how to prepare for the Exam
- Project Life Cycle
- Project Organizational Structures
- Project Scope Definition
- Project Scope Management
- Project Schedule Definition
- Project Schedule Management
- Project Budget Definition
- Project Budget Management
- Using ******oft Project to create a Project Schedule
- Project Quality Management
- Project Human Resource Management
- Project Communications Management
- Project Communications in Action
- Project Risk Identification
- Project Risk Analysis
- Project Risk Management
- Project Procurement Management
- Using ******oft Project to manage a Project Schedule
- Earned Value Analysis
- Creating Network Diagrams
- How to implement a PMO
- Project Initiation
- Project Planning
- Project Executing
- Project Monitoring and Control
- Project Closing
- Project Management Professionalism
- Project Integration Management

More Information About this Training...