یک نمونه پروژه احداث سازه ساختمان که در نرم افزار های BIM مدل سازی شده که سه بعد آن 3d مدل هست و ۲ بعد دیگه پارامتر زمان و هزینه.
در این مدل سازی مدیران بصورت ملموسی روند مراحل ساخت، روند پیشرفت پروژه طی زمان و هزینه اجرا را مشاهده می کنند.
@Projectcontrolrtn
در این مدل سازی مدیران بصورت ملموسی روند مراحل ساخت، روند پیشرفت پروژه طی زمان و هزینه اجرا را مشاهده می کنند.
@Projectcontrolrtn
👍5👏1
اگر بخواهید در نمودار S-Curve بر اساس آخرین تاریخ گزارش ، درصد پیشرفت واقعی و برنامه ای پروژه بصورت داینامیک درج شود، فیلم آموزشی مذکور را مشاهده بفرمائید.
@Projectcontrolrtn
@Projectcontrolrtn
👏6❤3
مدیریت ادعا چیست؟:
ادعا يا Claim در استانداردهاي PMI به اين صورت تعريف شده است: تقاضائي از سوي يک طرف قرارداد در ازاي وجود دلايلي اصولا صحيح و يا به گمان متقاضي صحيح که معمولا بخاطر اقدامات، دستورات و يا تغييرات اعمالي نامنطبق با مفاد قرارداد پروژه از سوي طرف ديگر قرارداد بوجود آمده و از لحاظ اقتصادي بين طرفين قابل حل و فصل نمي باشد.
به عنوان مثال کارفرما مدعی است که پيمانکار از برنامه اجرائي و پيشرفت مورد انتظار پروژه فاصله قابل توجهي دارد و متناسب با شرايط عمومي و خصوصي پيمان، به دليل تاخير در بهره برداري آتي پروژه ادعاي خسارت مي نمايد. و يا پيمانکار مدعي است وضعيت پيشرفت پروژه همچنان بر اساس برنامه ريزي مصوب اوليه در جريان مي باشد.
در فرآيند مديريت پروژه تعاملاتي في مابين ادعا و تغيير(Change) وجود دارد.
در پروژه هاي ساخت، جبران خسارت معمولا از جنس پرداخت هزينه،کلیم مالی، تمديد زمان اجرا و کلیم زمانی يا ترکيبي از هر دو است. وجه تمايز تغيير و ادعا در عدم توافق و اجماع طرفين قرارداد در خصوص درستي يا نادرستي موضوع مي باشد. اگر در خصوص ادعا(که در ابتدا يک Issue محسوب ميگردد) طرفين به اجماع برسند، ادعا تبديل به تغيير(Change order) خواهد شد و در فرايند مديريت تغييرات پيگيري مي گردد. در غير اينصورت موضوع ادعا در فرآيند مديريت ادعا و در چارچوب ”مذاکره“، ”ميانجي گري“، ”حکميت“ و نهايتا ”دعوي قضائي“ حل و فصل خواهد شد.
يک مثال از تغيير در پروژه :پيمانکار ساختماني به دليل تاخير فراوان پيمانکار نصب مخزن در جريان ساخت(during construction) ادعاي خسارت هزينهاي نموده است. کارفرما با بررسي مستندات ارائه شده توسط پيمانکار و تطابق آنها با مفاد قراردادي، علاوه بر لحاظ متمم هاي هزينه اي، تمديد زماني قرارداد پيمانکار را نيز تاييد مي نمايد.
همچنين در فرآيند مديريت پروژه تعاملاتي في مابين ادعا و موضوعات(Issue) وجود دارد.
در ادبيات PMI، موضوع، به مفهوم هر موردي که في مابين برخي از ذي نفعان، محلي از مناقشه بوده و اجماع وجود نداشته باشد تلقي مي گردد. موضوعات حل و فصل نشده مي توانند منبعي براي طرح ادعاهاي آتي قلمداد گردند. کلیم به عنوان يکي از ابزارهاي قراردادي براي حل و فصل موضوعات زمان و هزينه مورد نظر مي باشد.
مثالي از Issue: ارتباط غيرحرفهاي و ناکارامد دستگاه نظارت و پيمانکار موجب کندي مکاتبات طرفين همچون ارائه گزارشات و اخذ تاييده ها شده است.
در الحاقيه ساخت استاندارد PMBOK، چهار فرآيند براي مديريت دعاوي تعريف شده است:
شناسايي دعوي: فرايندي که طي آن دعوي شناسايي و مستندسازي مي گردد.
کمي سازي دعوي: فرايندي که طي آن اثرات دعوي طرح شده بر اهداف پروژه و قرارداد اندازه گيري مي شود.
پيشگيري دعوي: فرايندي که طي آن سعي مي شود زمينه ها و بسترهاي ايجاد دعوي در پروژه کاهش يابد.
حل و فصل دعوي: فرايندي که طي آن دعوي از روشهاي متفاوتي همچون
مذاکره، ميانجي گري و حکميت و نهايتا دعوي حقوقي حل و فصل مي شود
@Projectcontrolrtn
ادعا يا Claim در استانداردهاي PMI به اين صورت تعريف شده است: تقاضائي از سوي يک طرف قرارداد در ازاي وجود دلايلي اصولا صحيح و يا به گمان متقاضي صحيح که معمولا بخاطر اقدامات، دستورات و يا تغييرات اعمالي نامنطبق با مفاد قرارداد پروژه از سوي طرف ديگر قرارداد بوجود آمده و از لحاظ اقتصادي بين طرفين قابل حل و فصل نمي باشد.
به عنوان مثال کارفرما مدعی است که پيمانکار از برنامه اجرائي و پيشرفت مورد انتظار پروژه فاصله قابل توجهي دارد و متناسب با شرايط عمومي و خصوصي پيمان، به دليل تاخير در بهره برداري آتي پروژه ادعاي خسارت مي نمايد. و يا پيمانکار مدعي است وضعيت پيشرفت پروژه همچنان بر اساس برنامه ريزي مصوب اوليه در جريان مي باشد.
در فرآيند مديريت پروژه تعاملاتي في مابين ادعا و تغيير(Change) وجود دارد.
در پروژه هاي ساخت، جبران خسارت معمولا از جنس پرداخت هزينه،کلیم مالی، تمديد زمان اجرا و کلیم زمانی يا ترکيبي از هر دو است. وجه تمايز تغيير و ادعا در عدم توافق و اجماع طرفين قرارداد در خصوص درستي يا نادرستي موضوع مي باشد. اگر در خصوص ادعا(که در ابتدا يک Issue محسوب ميگردد) طرفين به اجماع برسند، ادعا تبديل به تغيير(Change order) خواهد شد و در فرايند مديريت تغييرات پيگيري مي گردد. در غير اينصورت موضوع ادعا در فرآيند مديريت ادعا و در چارچوب ”مذاکره“، ”ميانجي گري“، ”حکميت“ و نهايتا ”دعوي قضائي“ حل و فصل خواهد شد.
يک مثال از تغيير در پروژه :پيمانکار ساختماني به دليل تاخير فراوان پيمانکار نصب مخزن در جريان ساخت(during construction) ادعاي خسارت هزينهاي نموده است. کارفرما با بررسي مستندات ارائه شده توسط پيمانکار و تطابق آنها با مفاد قراردادي، علاوه بر لحاظ متمم هاي هزينه اي، تمديد زماني قرارداد پيمانکار را نيز تاييد مي نمايد.
همچنين در فرآيند مديريت پروژه تعاملاتي في مابين ادعا و موضوعات(Issue) وجود دارد.
در ادبيات PMI، موضوع، به مفهوم هر موردي که في مابين برخي از ذي نفعان، محلي از مناقشه بوده و اجماع وجود نداشته باشد تلقي مي گردد. موضوعات حل و فصل نشده مي توانند منبعي براي طرح ادعاهاي آتي قلمداد گردند. کلیم به عنوان يکي از ابزارهاي قراردادي براي حل و فصل موضوعات زمان و هزينه مورد نظر مي باشد.
مثالي از Issue: ارتباط غيرحرفهاي و ناکارامد دستگاه نظارت و پيمانکار موجب کندي مکاتبات طرفين همچون ارائه گزارشات و اخذ تاييده ها شده است.
در الحاقيه ساخت استاندارد PMBOK، چهار فرآيند براي مديريت دعاوي تعريف شده است:
شناسايي دعوي: فرايندي که طي آن دعوي شناسايي و مستندسازي مي گردد.
کمي سازي دعوي: فرايندي که طي آن اثرات دعوي طرح شده بر اهداف پروژه و قرارداد اندازه گيري مي شود.
پيشگيري دعوي: فرايندي که طي آن سعي مي شود زمينه ها و بسترهاي ايجاد دعوي در پروژه کاهش يابد.
حل و فصل دعوي: فرايندي که طي آن دعوي از روشهاي متفاوتي همچون
مذاکره، ميانجي گري و حکميت و نهايتا دعوي حقوقي حل و فصل مي شود
@Projectcontrolrtn
❤6🙏2🔥1
نمونه ای کامل و کاربردی از قالب منشور پروژه برای پروژه های ساخت و نصب
در قالب فایل ورد و قابل ادیت
@Projectcontrolrtn
در قالب فایل ورد و قابل ادیت
@Projectcontrolrtn
🙏2❤1👍1
جزوه ای بسیار عالی آموزش پریماورا (p6 )به همراه پروژه تمرینی کاربردی
@Projectcontrolrtn
@Projectcontrolrtn
🙏3
توضیحات در خصوص انواع فعالیت در P6
انواع فعالیت در P6 تعریف میگردد ممکن است یکی از شش حالت زیر را داشته باشند، به عبارتی میتوان گفت شش نوع فعالیت در P6 قابل تعریف میباشد.
نوع فعالیت (Activity Type) مشخص میکند که چگونه بایستی محاسبات زمان و تاریخهای فعالیت انجام شود. به هر فعالیت یکی از این شش حالت زیر اختصاص داده میشود.
1. Task Dependent
2. Start Milestone
3. Finish Milestone
4. Resource Dependent
5. Level of Effort
6. WBS summary
نوع فعالیتها را در صفحه Activity Details در پنجره General در قسمت Activity Type میتوان تعیین نمود.
Task Dependent:
نرمافزار P6 بهطور پیشفرض حالت فعالیتها را به این صورت درنظر میگیرد. در این حالت زمانبندی مطابق با تقویم فعالیت صورت میگیرد. هنگامیکه چند منبع بهصورت همزمان بایستی روی یک فعالیت کار کنند، انتخاب این حالت ضروری میباشد.
Start Milestone:
مایلستونها دارای زمان صفر میباشند و برای نشاندادن شروع و پایان یک واقعه مهم و یا یک فاز در پروژه استفاده میشوند. از مایلستونها میتوان برای نشاندادنِ شروع و پایان پروژه، شروع و پایان فازهای اصلی، تاریخ عقد یک قرارداد مهم، تاریخ خرید یک کالای مهم، تاریخ اتمام یک کار مهم، تاریخ رسیدن به درصد پیشرفت مشخص در طول پروژه و… استفاده کرد. Start Milestone برای نشاندادن نقاط کلیدی که حالت شروع دارند استفاده میشود.
مانند تاریخ شروع پروژه ، تاریخ شروع طراحی ، تاریخ شروع راه اندازی و …
تفاوتی که در اینجا با نرم افزار MSP وجود دارد این است که با صفر کردن مدت زمان فعالیت (Original Duration)، فعالیت به مایلستون تبدیل نمیشود و میبایست نوع فعالیت (Activity Type) نیز به Start Milestone تغییر یابد. مشخصه مایلستون در نمودار گانت، لوزی مشکلی رنگ است.
Finish Milestone:
همانند مورد فوق و تنها برای مایلستونهایی که حالت پایان دارند استفاده میشود، مانند تاریخ پایان پروژه ، تاریخ تحویل موقت ، اتمام راه اندازی فاز یک ، اتمام ساخت مخازن و …
Resource Dependent:
منابعی که به این نوع از فعالیتها تخصیص داده شدهاند مطابق با تقویم منابع، زمانبندی میشوند و تقویم منابع بر تقویم فعالیتها ارجحیت دارد. زمان فعالیتها در این حالت بر اساس منابعی که در دسترس میباشد مشخص میگردد. از این نوع فعالیت زمانی استفاده میشود که منابع مختلف بتوانند بهصورت آزادانه و مستقل از یکدیگر روی یک فعالیت کار کنند.
Level of Effort:
زمان این نوع از فعالیتها به فعالیتهای پیشنیاز و پسنیاز خود وابسته است. این فعالیت با اولین فعالیت زیر مجموعه خود رابطه SS و پایان این فعالیت با آخرین فعالیت رابطه FF دارد.
مشخصه این نوع فعالیتها ، علامت ستاره درکنار Duration است.
برای این نوع فعالیتها نمیتوان قید زمانی تعریف کرد و در هنگام تسطیح منابع درنظر گرفته نمیشوند. برای مثال این نوع فعالیتها میتوان مثلاً به فعالیت Management یا Planning and Project Control اشاره نمود. در نمودار گانت این میله این فعالیتها کمی باریک تر از فعالیت های Task Dependent است. همچنین جهت نمایش این میله ها در نمای گانت، میبایست تیک Display آن در منوی Bar زده شده باشد.
WBS Summary:
مجموعهای از فعالیتها که با یک کد WBS مشترک تعریف میشوند را میتوان بهعنوان یک WBS Summary تعریف کرد. مثلا تمام فعالیتهایی که کد WBS آنها با حرف A شروع میشود مانند (A101,A2,…) را میتوان بهعنوان یک مجموعه و تحت یک فعالیت WBS Summary تعریف کرد، زمان فعالیت و تاریخ شروع و پایان WBS Summary را فعالیتهای زیرمجموعهی آن مشخص میکنند .
@Projectcontrolrtn
انواع فعالیت در P6 تعریف میگردد ممکن است یکی از شش حالت زیر را داشته باشند، به عبارتی میتوان گفت شش نوع فعالیت در P6 قابل تعریف میباشد.
نوع فعالیت (Activity Type) مشخص میکند که چگونه بایستی محاسبات زمان و تاریخهای فعالیت انجام شود. به هر فعالیت یکی از این شش حالت زیر اختصاص داده میشود.
1. Task Dependent
2. Start Milestone
3. Finish Milestone
4. Resource Dependent
5. Level of Effort
6. WBS summary
نوع فعالیتها را در صفحه Activity Details در پنجره General در قسمت Activity Type میتوان تعیین نمود.
Task Dependent:
نرمافزار P6 بهطور پیشفرض حالت فعالیتها را به این صورت درنظر میگیرد. در این حالت زمانبندی مطابق با تقویم فعالیت صورت میگیرد. هنگامیکه چند منبع بهصورت همزمان بایستی روی یک فعالیت کار کنند، انتخاب این حالت ضروری میباشد.
Start Milestone:
مایلستونها دارای زمان صفر میباشند و برای نشاندادن شروع و پایان یک واقعه مهم و یا یک فاز در پروژه استفاده میشوند. از مایلستونها میتوان برای نشاندادنِ شروع و پایان پروژه، شروع و پایان فازهای اصلی، تاریخ عقد یک قرارداد مهم، تاریخ خرید یک کالای مهم، تاریخ اتمام یک کار مهم، تاریخ رسیدن به درصد پیشرفت مشخص در طول پروژه و… استفاده کرد. Start Milestone برای نشاندادن نقاط کلیدی که حالت شروع دارند استفاده میشود.
مانند تاریخ شروع پروژه ، تاریخ شروع طراحی ، تاریخ شروع راه اندازی و …
تفاوتی که در اینجا با نرم افزار MSP وجود دارد این است که با صفر کردن مدت زمان فعالیت (Original Duration)، فعالیت به مایلستون تبدیل نمیشود و میبایست نوع فعالیت (Activity Type) نیز به Start Milestone تغییر یابد. مشخصه مایلستون در نمودار گانت، لوزی مشکلی رنگ است.
Finish Milestone:
همانند مورد فوق و تنها برای مایلستونهایی که حالت پایان دارند استفاده میشود، مانند تاریخ پایان پروژه ، تاریخ تحویل موقت ، اتمام راه اندازی فاز یک ، اتمام ساخت مخازن و …
Resource Dependent:
منابعی که به این نوع از فعالیتها تخصیص داده شدهاند مطابق با تقویم منابع، زمانبندی میشوند و تقویم منابع بر تقویم فعالیتها ارجحیت دارد. زمان فعالیتها در این حالت بر اساس منابعی که در دسترس میباشد مشخص میگردد. از این نوع فعالیت زمانی استفاده میشود که منابع مختلف بتوانند بهصورت آزادانه و مستقل از یکدیگر روی یک فعالیت کار کنند.
Level of Effort:
زمان این نوع از فعالیتها به فعالیتهای پیشنیاز و پسنیاز خود وابسته است. این فعالیت با اولین فعالیت زیر مجموعه خود رابطه SS و پایان این فعالیت با آخرین فعالیت رابطه FF دارد.
مشخصه این نوع فعالیتها ، علامت ستاره درکنار Duration است.
برای این نوع فعالیتها نمیتوان قید زمانی تعریف کرد و در هنگام تسطیح منابع درنظر گرفته نمیشوند. برای مثال این نوع فعالیتها میتوان مثلاً به فعالیت Management یا Planning and Project Control اشاره نمود. در نمودار گانت این میله این فعالیتها کمی باریک تر از فعالیت های Task Dependent است. همچنین جهت نمایش این میله ها در نمای گانت، میبایست تیک Display آن در منوی Bar زده شده باشد.
WBS Summary:
مجموعهای از فعالیتها که با یک کد WBS مشترک تعریف میشوند را میتوان بهعنوان یک WBS Summary تعریف کرد. مثلا تمام فعالیتهایی که کد WBS آنها با حرف A شروع میشود مانند (A101,A2,…) را میتوان بهعنوان یک مجموعه و تحت یک فعالیت WBS Summary تعریف کرد، زمان فعالیت و تاریخ شروع و پایان WBS Summary را فعالیتهای زیرمجموعهی آن مشخص میکنند .
@Projectcontrolrtn
❤7
روش های محاسبه بودجه اتمام BAC
روش های متفاوتی برای محاسبه بودجه اتمام پروژه وجود دارد.
حالت اول :
EAC= BAC/ CPI
در این حالت فرض می شود که شاخص عملکرد پروژه در آینده نیز همانند گذشته خواهد بود. به عبارت دیگر شاخص عملکرد هزینه پروژه همانند گذشته عمل می کند. در این حالت بودجه اتمام پروژه برابر با تقسیم BAC بر CPI خواهد بود. اگر شاخص هزینه برابر یک باشد بدان مفهوم است که نیازی به پیش بینی نخواهد بود و شما می توانید پروژه را مطابق بودجه پیش بینی شده به پایان برسانید.
حالت دوم: (BAC-EV)+EAC=AC
این حالت برای زمانی مفید است که می توانیم پروژه را مطابق زمان بندی به پایان برسانیم ولی افزایش هزینه ای اتفاق افتاده و مطمئن هستیم که دوباره تکرار نخواهد شد. و لذا می توانیم مطابق بودجه افزایش یافته مصوب ، پروژه را به پایان برسانیم.
حالت سوم :
زمانی پروژه بیش از بودجه مصوب هزینه کرده و از زمان بندی هم عقب افتاده و کارفرما هم تاکید دارد که پروژه باید در زمان مقرر تمام شود در این حالت باید از شاخص های CPI و SPI در براورد هزینه اتمام استفاده کرد. مناسب حال اکثر پروژه های ما در کشور ،
AC+(BAC-EV)/ CPI*SPI
@Projectcontrolrtn
روش های متفاوتی برای محاسبه بودجه اتمام پروژه وجود دارد.
حالت اول :
EAC= BAC/ CPI
در این حالت فرض می شود که شاخص عملکرد پروژه در آینده نیز همانند گذشته خواهد بود. به عبارت دیگر شاخص عملکرد هزینه پروژه همانند گذشته عمل می کند. در این حالت بودجه اتمام پروژه برابر با تقسیم BAC بر CPI خواهد بود. اگر شاخص هزینه برابر یک باشد بدان مفهوم است که نیازی به پیش بینی نخواهد بود و شما می توانید پروژه را مطابق بودجه پیش بینی شده به پایان برسانید.
حالت دوم: (BAC-EV)+EAC=AC
این حالت برای زمانی مفید است که می توانیم پروژه را مطابق زمان بندی به پایان برسانیم ولی افزایش هزینه ای اتفاق افتاده و مطمئن هستیم که دوباره تکرار نخواهد شد. و لذا می توانیم مطابق بودجه افزایش یافته مصوب ، پروژه را به پایان برسانیم.
حالت سوم :
زمانی پروژه بیش از بودجه مصوب هزینه کرده و از زمان بندی هم عقب افتاده و کارفرما هم تاکید دارد که پروژه باید در زمان مقرر تمام شود در این حالت باید از شاخص های CPI و SPI در براورد هزینه اتمام استفاده کرد. مناسب حال اکثر پروژه های ما در کشور ،
AC+(BAC-EV)/ CPI*SPI
@Projectcontrolrtn
👍1
دانلود رایگان نمونه فایل کامل لایحه تاخیرات شامل همه موادشرایط عمومی پیمان به انضمام نمودار همپوشانی موارد
@Projectcontrolrtn
@Projectcontrolrtn
❤3
تحویل شدنیها و روزمرگی
برگرفته از پروفایل برنامه ریزی و کنترل پروژه -نادر خرمی راد
میدونم که تا حالا خیلی در این مورد نوشتم، ولی واقعا به نظر من روزمرگی یکی از وحشتناکترین اتفاقهاییه که برای کسی میتونه بیفته و کسای زیادی رو میبینم که کارشون برنامهریزی و کنترل پروژهش و این کار براشون چیزی بیشتر از روزمرگی نیست.
شاید این ماجرا برای بعضیها مطلوب باشه که در این صورت دیگه به من ربطی نداره. با این حال خیلیها هم هستن که گرفتار روزمرگی میشن، در حالی که خودشون دوست ندارن و دلشون میخواد تغییرش بدن؛ مخاطب من اونها هستن. البته کسی که تو گروه اول باشه (علاقهمند به روزمرگی) اصولا خواننده سایت هم نیست.
یکی از بزرگترین قدمها برای مبارزه با روزمرگی اینه که تو کارتون تحویلشدنیهای مشخص داشته باشین. این ماجرا برای پروژهها هم مهمه: اینکه چطوری بتونیم یه محصول بزرگ رو به اجزای معنیدار کوچیک بشکنیم و به تدریج تکمیلشون کنیم. وقتی اجزا کوچک و در عین حال معنیدار باشن، تکمیل شدنشون پیشرفت واقعیمون رو نشون میده. این ماجرا برای پروژههای چابک خیلی مهمتر هم هست، چون با تحویلشدنیهای معنیدار بازخورد دریافت میکنیم و این بازخورده که ادامه کار رو مشخص میکنه.
تو زندگی حرفهایمون هم مسئله همینطوره. اگه تحویلشدنیهای مشخصی نداشته باشین، امکان و احتمال روزمرگی خیلی زیاد میشه. اگه بتونین تحویلشدنیهای مناسب برای خودتون بسازین، به احتمال زیاد میتونین از اون وضعیت نجات پیدا کنین و هم کار رو برای خودتون خوشایند کنین و هم به سرعت پیشرفت کنین. هر تحویلشدنی که تکمیل میشه هم چیزی بهتون اضافه میکنه و هم حس رضایت، توانایی، پیروزی، مفید بودن و خیلی حسهای خوب دیگه رو به وجود میاره. بد نیست اعتراف کنم که من اگه تو یه هفته هیچ تحویلشدنی واضحی تولید نکرده باشم واقعا و بدون شوخی افسرده میشم. ماجرا خیلی جدیه: زندگی من و سعادت من کاملا وابسته به این مفهومه.
برای اینکه منظورم برای زاویه دید یه کارشناس برنامهریزی و کنترل پروژه مشخصتر بشه چنتا مثال که الان به ذهنم میرسه رو میگم:
مثال ۱: فلانی تو شرکت همیشه از گزارشهای پیشرفت ناراضیه. فکر میکنه بیمصرفن. پروژه من اینه که گزارشی بسازم که برای این آدم مفید باشه و کاملا تاییدش کنه.
مثال ۲: اطلاعات همیشه دیر از کارگاه میرسه. هدف من الان اینه که هر طور شده راه حلی عملی پیدا کنم که این مشکل رو از بین ببره و امکانی رو فراهم کنه که اطلاعات همیشه به موقع برسه.
مثال ۳: فایلهام رو نمیتونم راحت پیدا کنم، به خصوص وقتی دنبال آخرین نسخه یه فایل میگردم. هدف من الان اینه که راه حلی برای این مشکل پیدا کنم، طوری که دیگه هیچوقت تو پیدا کردن فایلهام مشکل نداشته باشم.
مثال ۴: هر دفعه که گزارش پیشرفت تهیه میکنم باید کلی انرژی صرف فرستادنش برای آدمهای مختلف بکنم و آخرش هم گزارش به دست بعضیها نمیرسه و بعد از یه مدتی میان دنبالش میگردن. میخوام یه راه حل اساسی برای این مشکل پیدا کنم.
مثال ۵: با اینکه خیلی ساله با پریماورا/پراجکت کار میکنم، هنوز همه ریزهکاریهاش رو بلد نیستم. میدونم که یادگیری همه جزئیات خیلی سخته؛ ولی یه چیز کوچیک رو که میشه کاملا توش استاد شد. الان هدف من اینه که استاد مطلق بشم تو مفهوم تداخلهای زمانبندی نرمافزار.
مثال ۶: هدف من الان اینه که تو مدت دو هفته یه تحویلشدنی کاری خوب برای خودم پیدا کنم!
@Projectcontrolrtn
برگرفته از پروفایل برنامه ریزی و کنترل پروژه -نادر خرمی راد
میدونم که تا حالا خیلی در این مورد نوشتم، ولی واقعا به نظر من روزمرگی یکی از وحشتناکترین اتفاقهاییه که برای کسی میتونه بیفته و کسای زیادی رو میبینم که کارشون برنامهریزی و کنترل پروژهش و این کار براشون چیزی بیشتر از روزمرگی نیست.
شاید این ماجرا برای بعضیها مطلوب باشه که در این صورت دیگه به من ربطی نداره. با این حال خیلیها هم هستن که گرفتار روزمرگی میشن، در حالی که خودشون دوست ندارن و دلشون میخواد تغییرش بدن؛ مخاطب من اونها هستن. البته کسی که تو گروه اول باشه (علاقهمند به روزمرگی) اصولا خواننده سایت هم نیست.
یکی از بزرگترین قدمها برای مبارزه با روزمرگی اینه که تو کارتون تحویلشدنیهای مشخص داشته باشین. این ماجرا برای پروژهها هم مهمه: اینکه چطوری بتونیم یه محصول بزرگ رو به اجزای معنیدار کوچیک بشکنیم و به تدریج تکمیلشون کنیم. وقتی اجزا کوچک و در عین حال معنیدار باشن، تکمیل شدنشون پیشرفت واقعیمون رو نشون میده. این ماجرا برای پروژههای چابک خیلی مهمتر هم هست، چون با تحویلشدنیهای معنیدار بازخورد دریافت میکنیم و این بازخورده که ادامه کار رو مشخص میکنه.
تو زندگی حرفهایمون هم مسئله همینطوره. اگه تحویلشدنیهای مشخصی نداشته باشین، امکان و احتمال روزمرگی خیلی زیاد میشه. اگه بتونین تحویلشدنیهای مناسب برای خودتون بسازین، به احتمال زیاد میتونین از اون وضعیت نجات پیدا کنین و هم کار رو برای خودتون خوشایند کنین و هم به سرعت پیشرفت کنین. هر تحویلشدنی که تکمیل میشه هم چیزی بهتون اضافه میکنه و هم حس رضایت، توانایی، پیروزی، مفید بودن و خیلی حسهای خوب دیگه رو به وجود میاره. بد نیست اعتراف کنم که من اگه تو یه هفته هیچ تحویلشدنی واضحی تولید نکرده باشم واقعا و بدون شوخی افسرده میشم. ماجرا خیلی جدیه: زندگی من و سعادت من کاملا وابسته به این مفهومه.
برای اینکه منظورم برای زاویه دید یه کارشناس برنامهریزی و کنترل پروژه مشخصتر بشه چنتا مثال که الان به ذهنم میرسه رو میگم:
مثال ۱: فلانی تو شرکت همیشه از گزارشهای پیشرفت ناراضیه. فکر میکنه بیمصرفن. پروژه من اینه که گزارشی بسازم که برای این آدم مفید باشه و کاملا تاییدش کنه.
مثال ۲: اطلاعات همیشه دیر از کارگاه میرسه. هدف من الان اینه که هر طور شده راه حلی عملی پیدا کنم که این مشکل رو از بین ببره و امکانی رو فراهم کنه که اطلاعات همیشه به موقع برسه.
مثال ۳: فایلهام رو نمیتونم راحت پیدا کنم، به خصوص وقتی دنبال آخرین نسخه یه فایل میگردم. هدف من الان اینه که راه حلی برای این مشکل پیدا کنم، طوری که دیگه هیچوقت تو پیدا کردن فایلهام مشکل نداشته باشم.
مثال ۴: هر دفعه که گزارش پیشرفت تهیه میکنم باید کلی انرژی صرف فرستادنش برای آدمهای مختلف بکنم و آخرش هم گزارش به دست بعضیها نمیرسه و بعد از یه مدتی میان دنبالش میگردن. میخوام یه راه حل اساسی برای این مشکل پیدا کنم.
مثال ۵: با اینکه خیلی ساله با پریماورا/پراجکت کار میکنم، هنوز همه ریزهکاریهاش رو بلد نیستم. میدونم که یادگیری همه جزئیات خیلی سخته؛ ولی یه چیز کوچیک رو که میشه کاملا توش استاد شد. الان هدف من اینه که استاد مطلق بشم تو مفهوم تداخلهای زمانبندی نرمافزار.
مثال ۶: هدف من الان اینه که تو مدت دو هفته یه تحویلشدنی کاری خوب برای خودم پیدا کنم!
@Projectcontrolrtn
❤4👍2👏1