در واقع OKR برنامه عملیاتی است که پروژه شما برای اجرای موفقیت آمیز به آن نیاز دارد. هنگامی که درک روشنی از نتیجه آن پیدا کردید، می توانید به راحتی نقشه راه را برای دستیابی به آن ترسیم کنید.
در مدیریت پروژه وظایف کاملا مشخص هستند و صرفا باید انجام شوند. اما این وظایف در واقع به شما نمی گویند که آیا “کارهای درست” را انجام میدهید یا خیر. این اهداف OKR است که به شما می گوید چه چیزی مناسب است یا چه کاری برای شرکت شما مناسب است.
اما OKR ها چرخه های هدف کوتاه تر را در بر میگیرند، که به تیم ها امکان می دهد خود را با تغییر وفق دهند و خطرات و اتلاف را کاهش دهند.
برای اطمینان از اینکه تیم شما به طور موثر کار می کند، مدیران پروژه باید در راستای همسان سازی و ابلاغ اهداف شرکت سرمایه گذاری کنند. با یک مثال این تفاوت را واضح تر میبینیم.
وظایفی که برای راه اندازی یک محصول جدید انجام می شود:
این وظایف فقط مجموعه عبارات مبتنی بر عمل هستند. آنها هیچ معیاری را برای پیگیری رشد در نظر نمیگیرند.
مدیریت پروژه تنها به لیست کردن تعدادی اقدام های عملیاتی میپردازد اما در نهایت این که آیا این اقدامات به انجام شدن پروژه منجر شده اند یا نه را بررسی نمیکنند.
در صورتی که بر عکس OKR معیار هایی را مورد سنجش قرار میدهد که با رسیدن به آن نتایج هدف اصلی محقق میشود. حال هدفی با عنوان “تولید یک محصول جدید” تعریف میکنیم.
KR1 : جذب 4 سرمایه گذار برای پروژه
KR2 : جذب 200 دنبال کننده جدید در فضای مجازی
KR3 : صحبت با 2 خرده فروش و 5 توزیع کننده
پس از مقایسه وظایف و OKR ها، بدیهی است که OKR ها به پروژه شما وضوح و ساختار می دهند.
نتایج کلیدی در اینجا اقدامات استراتژیک است، در حالی که وظایف ذکر شده فقط اقدامات بود. شما آنها را کنترل نمی کنید.
مدیریت پروژه با انجام یک پروژه تحت محدودیت های زمانی، ارزشی و بودجه تعیین شده کار می کند. اگر نتیجه خود را می دانید، می توانید به راحتی از آن استفاده کنید و یک برنامه عملیاتی تهیه کنید.
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
آیا تا به حال در مورد جادوی مدیریت پروژه چابک یا Agile فکر کرده اید؟ بیایید به برخی از مزایای باورنکردنی آن نگاه کنیم:
🤝 همکاری و ارتباطات بهتر = پیشرفت سریعتر و انعطاف پذیری بیشتر
مدیریت پروژه چابک ارتباطات بهتر را میان اعضای تیم تقویت میکند و راه را برای حل مشکلات و تصمیمگیری سریعتر هموار میکند. چگونه؟ از طریق فرهنگ جلسات مکرر و دموکراتیک مانند اسکرام روزانه، که در آن همه وضعیت خود را به اشتراک می گذارند و شناسایی و غلبه بر موانع به یک نسیم تبدیل می شود.
🌐 ارتباط بهتر با مشتری = ارزش مشتری بیشتر و همسویی تجاری
در مدیریت پروژه چابک، مشتریان نهایی ذینفعان یکپارچه هستند. با درگیر کردن زودهنگام و اغلب آنها، تیم ها بینش ارزشمندی را به دست می آورند و از همسویی با نیازهای مشتری و ارائه حداکثر ارزش اطمینان حاصل می کنند.
🗂️ سازماندهی و در مسیر ماندن
مهارت Agile در تقسیم اهداف بزرگ به بخشهای قابل مدیریت، به تیمها این امکان را میدهد که سازماندهی شوند، وظایف را اولویتبندی کنند و به طور مداوم ضربالاجلها را رعایت کنند. تمرکز روی یک کار در یک زمان، دام های چندوظیفه ای مانند اشتباهات و اتلاف وقت را از بین می برد.
مدیریت پروژه چابک فقط یک روش نیست. این یک تغییر دهنده بازی برای تیم هایی است که به دنبال کارایی، همکاری و مشتری مداری هستند! طرز فکر چابک را بپذیرید و پروژه های خود را به ارتفاعات جدیدی ارتقا دهید!
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
1️⃣ تیم پویا خود را جمع آوری کنید
اعضای تیم را همسو با محدوده پروژه انتخاب کنید و آنها را در چارچوب چابکی انتخابی خود آموزش دهید. به یاد داشته باشید، Agile در تصمیم گیری مشارکتی پیشرفت می کند، بنابراین درگیر کردن زودهنگام تیم شما بسیار مهم است. نقش ها، مسئولیت ها را تعیین کنید و کارگاه های عملی برگزار کنید تا مطمئن شوید همه در یک صف هستند.
2️⃣ نقشه راه چابک یا بک لاگ محصول خود را بسازید
دموکراسی کلیدی است! نقشه راه چابک شما باید اهداف پروژه در سطح بالا را منعکس کند. کارکنان خط مقدم که روزانه با مشتریان در تعامل هستند را درگیر کنید - بینش آنها بسیار ارزشمند است. این رویکرد مشترک دیدگاه های متنوع را تضمین می کند و پایه و اساس یک سفر موفق چابک را تنظیم می کند.
3️⃣ نیازهای اولیه را با ورودی دقیق کشف کنید
به کارشناسان حوزه خود گوش دهید! فرقی نمیکند این «بک لاگ محصول» اسکرام باشد یا رویکرد دیگری، تیم خود را در تقسیم پروژه به محصولات کوچکتر و کاربر محور مشارکت دهید. این مرحله برای درک سلسله مراتب ایده آل اهداف و نقاط عطف بسیار مهم است.
4️⃣ اولین چرخه توسعه را آغاز کنید
سرعت و سازگاری در هسته چابکی است. بهجای پیشبینی هر نیاز، بر برنامهریزی یک «ارائه محصول» قابل دستیابی تمرکز کنید که بینشهایی را در مورد محدوده پروژه ارائه میدهد. اجازه دهید تیم شما به سرعت وارد عمل شود و فلسفه چابک را برای انطباق با نیازهای در حال تغییر بپذیرد.
5️⃣ مرور، تکرار، تکرار!
تکمیل چرخه اول پایان نیست. این یک ایست بازرسی برای تأمل است. پیشرفت خود را مرور کنید، تغییرات در حوزه، اولویت های مشتری و وابستگی های کار را در نظر بگیرید. نسخه بعدی خود را برنامه ریزی کنید و آن را تکرار کنید. طبیعت پویا Agile را بپذیرید، جایی که بهبود مستمر یک هنجار است.
🚀 آماده پذیرش طرز فکر چابک هستید؟ سفر چابک شما با یک تیم مشارکتی، یک نقشه راه کاربر محور، بینش متخصص، چرخه های توسعه تکراری و تعهد به بهبود مستمر آغاز می شود.
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from مدرسه مدیریت پروژه و ساخت
شرکت Oracle آخرین بروزرسانی نرم افزار (Primavera P6 Professional (PPM را با نسخه 23.12 منتشر کرد.
♻️به مدرسه مدیریت پروژه بپیوندید👇
@project_school
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from مدرسه مدیریت پروژه و ساخت
Please open Telegram to view this post
VIEW IN TELEGRAM
🔹جالبه بدونین طبق نظرسنجی که انجام شده، ۳۷٪ پروژهها به دلیل ناواضح بودن و مشخص نبودن هدف شکست میخورن! وقتی هدف پروژهای شفاف نباشه، افراد گیج میشن، منابع بهدرستی اختصاص داده نمیشن و مسیر مشخص نیست. در نهایت همه اینها باعث شکست پروژه میشن.
🔸بعد از اون ارتباط و تعامل ضعیف چیزیه که منجر به شکست پروژهها میشه. این تعامل ضعیف ممکنه بین کل تیم باشه یا در لایه مدیریتی و بین رهبران و مدیران پروژه اتفاق بیفته. اما چه عوامل دیگهای باعث شکست یه پروژه میشن؟ توی این پست توضیح دادیم.
منبع: تکرسا
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from مدرسه مدیریت پروژه و ساخت
⭕️ در مدیریت پروژه چابک اما، با حضور فرایندها و مفاهیم جدیدی مانند کارتیمی و تعاملات تیمی، تحویل خروجی های کارا، تعامل هرچه بیشتر با مشتری، پاسخگویی سریع به تغییرات، تحویل خروجی ارزشمند به مشتری یا کارفرما، برنامه ریزی تطبیقی و متغیر و در نهایت، مدیریت ریسک چابک، معایب متدولوژی آبشاری به حداقل خود می رسد. در مدیریت پروژه چابک، مدیر پروژه وجود ندارد و همه تیم با هم، خود را موظف به پاسخگوئی در خصوص خروجی های پروژه می دانند.
افراد تیم چابک، از همکاری در کنار هم لذت برده و به مرامنامهای که از ابتدا باهم تهیه میکنندو به منشور کار تیمی پایبند هستند.
✍️ دکتر احمدزاده
✅ به مدرسه مدیریت پروژه بپیوندید👇
➡️ @project_school
افراد تیم چابک، از همکاری در کنار هم لذت برده و به مرامنامهای که از ابتدا باهم تهیه میکنندو به منشور کار تیمی پایبند هستند.
✍️ دکتر احمدزاده
Please open Telegram to view this post
VIEW IN TELEGRAM
⭕️ کنترل تغییرات
به عنوان یک مدیر پروژه حرفه ای، شما باید کسی باشید که همه تغییرات در محدوده پروژه را کنترل می نماید. خزش از محدوده، پروژه را می کشد. محدوده پروژه را از قبل تهیه نمایید و سپس آن را به صورت هفتگی بازبینی نمایید، تا این اطمینان حاصل شود که شما کار تصویب نشده¬ای را به هیچ وجه انجام نمی دهید. قطعا مشتری تغییراتی را در طول پروژه درخواست می نماید. همیشه تسلیم این درخواست ها نشوید. بر اصول خود پایدار باشید و هنگامی که تغییری درخواست گردید، زمان یا بودجه بیشتری را درخواست نمایید تا آن را بررسی نمایید. به یاد داشته باشید که تعداد تغییرات درخواست شده از شما اهمیتی ندارد، به دلیل آن که همیشه شما را به خاطر تاخیر و یا افزایش هزینه مواخذه می نمایند. بنابراین در صورت مشاهده هر گونه تغییر آن را کنترل نمایید.
✅ به مدرسه مدیریت پروژه بپیوندید👇
➡️ @project_school
به عنوان یک مدیر پروژه حرفه ای، شما باید کسی باشید که همه تغییرات در محدوده پروژه را کنترل می نماید. خزش از محدوده، پروژه را می کشد. محدوده پروژه را از قبل تهیه نمایید و سپس آن را به صورت هفتگی بازبینی نمایید، تا این اطمینان حاصل شود که شما کار تصویب نشده¬ای را به هیچ وجه انجام نمی دهید. قطعا مشتری تغییراتی را در طول پروژه درخواست می نماید. همیشه تسلیم این درخواست ها نشوید. بر اصول خود پایدار باشید و هنگامی که تغییری درخواست گردید، زمان یا بودجه بیشتری را درخواست نمایید تا آن را بررسی نمایید. به یاد داشته باشید که تعداد تغییرات درخواست شده از شما اهمیتی ندارد، به دلیل آن که همیشه شما را به خاطر تاخیر و یا افزایش هزینه مواخذه می نمایند. بنابراین در صورت مشاهده هر گونه تغییر آن را کنترل نمایید.
Please open Telegram to view this post
VIEW IN TELEGRAM
⭕️ چرا پروژه را فاز بندی میکنیم ؟
✍️ مهدی معینی
تعریف فاز بر اساس استاندارد PMBOK® :
به مجموعه ایی از فعالیتهای پروژه که به صورت منطقی با هم در ارتباط هستند و با انجام آن فعالیتها یک یا چند محصول و یا خدمت قابل تحویل ارائه گردد فاز می گوییم.
واضح است که به هیچ عنوان نمیتوان کلیه جزئیات و پروژه را با دقت بالا از ابتدا تا انتها پروژه به صورت یکباره برنامه ریزی کرد و تا انتها مطابق برنامه اولیه پیش رفت بلکه همواره پروژه به روش پیشرفت تدریجی یا Progressive Elaborate برنامه ریزی و اجرا میشود. رویکرد برنامه ریزی Progressive Elaborate به این معناست که برنامه ریزی پروژه یک فعالیت یکباره و در ابتدای کار نیست و همواره باید با برنامه بروز و هماهنگ با عملکرد تیم پروژه، مسیر حرکت پروژه را اصلاح کرد.
مطابق چرخه دکتر دمینگ در واقع برنامه ریزی، اجرا، کنترل و اقدام اصلاحی به صورت متوالی و پشت سرهم و چندین بار در طول پروژه اتفاق خواهد افتاد.
به عنوان مثال شروع پروژه مانند شروع حرکت در مسیری پر از مه است که فقط فاصله اندکی جلوتر از ما قابل دیدن است و به همان اندازه هم برنامه ریزی با جزییات انجام میشود و با حرکت به جلو جزییات بیشتری آشکار میشود و برنامه ریزی دقیق تری انجام میشود و البته همواره مسیر اصلی و اهداف اصلی مشخص هستند و مسیر حرکت را اصلاح میکنند.
لازم به ذکر است در پروژه هایی که زمان کوتاهی دارند و یا دستاوردهای پروژه قابل تفکیک و جداسازی نیست بهتر است فازبندی انجام نشود و پروژه در یک فاز انجام گیرد. ولی اگر پروژه های بلند مدت را فاز بندی نکنیم در برنامه ریزی و اجرا به مشکلات متعددی مانند انحراف شدید از برنامه اولیه و تغییر چند باره خط مبنای پروژه (Baseline) پروژه برخورد خواهیم کرد. و در واقع فاز بندی پروژه را به قسمتهای کوچکتر و قابل مدیریت تر تقسیم کرده است که برنامه ریزی و کنترل را سهل تر مینماید.
چرا به نقطه پایان هر فاز و شروع فاز جدید و چرا در هر فاز پروژه باید تمامی گروههای فرآیندی اجرا گردند؟
شاید به یاد بیاورید پروژه هایی را که در سازمانها شروع میشوند و بنا بر دلایلی در میانه راه بدون هیچ دستاوردی متوقف میشوند و از آن پروژه ها فقط لیستی از هزینه های تحمیل شده به سازمان باقی میماند و یا پروژه هایی که در سازمانها در حال اجرا هستند و از منابع سازمان به مدت طولانی استفاده میکنند ولی در حال حاضر با استراتژی ها و سیاست های سازمان تضاد دارند و توقف این گونه پروژه ها مفید تر از ادامه آنهاست.
راهنمای ®PMBOK راه حل فاز بندی پروژه را جهت جلوگیری از ایجاد وضعیت های مشابه، وضعیت فوق ارائه میدهد و بر اجرای کلیه گروههای فرآیندی در تمامی فازها اصرار دارد. به طور مثال یکی از کارهای ابتدایی و آغازین پروژه صدور “منشور پروژه” (Project Charter) است، که به منزله تایید رسمی پروژه توسط سازمان و حکم مدیر پروژه می باشد و به پروژه رسمیت میدهد مطابق سطور فوق می بایست در ابتدای هر فاز مجددا منشور پروژه صادر شود و به تایید ذینفعان کلیدی پروژه برسد . اجرای این نکته ساده در پروژه ها و در ابتدای هر فاز در صورت لزوم باعث جلوگیری از ادامه پروژه های غیر ضروری و مخالف اهداف استراتژی های سازمانی خواهد شد و در صورت صدور منشور پروژه (Project Charter) جلب تعهد و حمایت مدیریت ارشد را در پی خواهد داشت که در روند اجرای پروژه تاثیر به سزایی دارد. به همین دلیل که امکان دارد شروع فاز جدید پروژه با عدم تایید سازمان به نقطه پایان پروژه تبدیل شود به این نقطه “کیل پوینت” (Kill Point) گویند. و همچنین در صورت تصمیم بر توقف پروژه به هر دلیلی در پایان فاز می بایست کلیه فرآیندهای اختتامیه برای آن فاز انجام گیرد یعنی به طور مثال کلیه دستاوردهای پروژه به صورت رسمی تحویل شود و اسناد مدارک لازم تهیه شود و “درسهای آموخته” (Lesson Learned) نیز ثبت شود. تا در صورت ادامه پروژه در آینده و فاز بعدی بتوان ازاین دستاوردها استفاده کرد و یا با رویکرد (Progressive Elaborate) کل پروژه را برنامه ریزی نمود.
✅ به مدرسه مدیریت پروژه بپیوندید👇
➡️ @project_school
✍️ مهدی معینی
تعریف فاز بر اساس استاندارد PMBOK® :
به مجموعه ایی از فعالیتهای پروژه که به صورت منطقی با هم در ارتباط هستند و با انجام آن فعالیتها یک یا چند محصول و یا خدمت قابل تحویل ارائه گردد فاز می گوییم.
واضح است که به هیچ عنوان نمیتوان کلیه جزئیات و پروژه را با دقت بالا از ابتدا تا انتها پروژه به صورت یکباره برنامه ریزی کرد و تا انتها مطابق برنامه اولیه پیش رفت بلکه همواره پروژه به روش پیشرفت تدریجی یا Progressive Elaborate برنامه ریزی و اجرا میشود. رویکرد برنامه ریزی Progressive Elaborate به این معناست که برنامه ریزی پروژه یک فعالیت یکباره و در ابتدای کار نیست و همواره باید با برنامه بروز و هماهنگ با عملکرد تیم پروژه، مسیر حرکت پروژه را اصلاح کرد.
مطابق چرخه دکتر دمینگ در واقع برنامه ریزی، اجرا، کنترل و اقدام اصلاحی به صورت متوالی و پشت سرهم و چندین بار در طول پروژه اتفاق خواهد افتاد.
به عنوان مثال شروع پروژه مانند شروع حرکت در مسیری پر از مه است که فقط فاصله اندکی جلوتر از ما قابل دیدن است و به همان اندازه هم برنامه ریزی با جزییات انجام میشود و با حرکت به جلو جزییات بیشتری آشکار میشود و برنامه ریزی دقیق تری انجام میشود و البته همواره مسیر اصلی و اهداف اصلی مشخص هستند و مسیر حرکت را اصلاح میکنند.
لازم به ذکر است در پروژه هایی که زمان کوتاهی دارند و یا دستاوردهای پروژه قابل تفکیک و جداسازی نیست بهتر است فازبندی انجام نشود و پروژه در یک فاز انجام گیرد. ولی اگر پروژه های بلند مدت را فاز بندی نکنیم در برنامه ریزی و اجرا به مشکلات متعددی مانند انحراف شدید از برنامه اولیه و تغییر چند باره خط مبنای پروژه (Baseline) پروژه برخورد خواهیم کرد. و در واقع فاز بندی پروژه را به قسمتهای کوچکتر و قابل مدیریت تر تقسیم کرده است که برنامه ریزی و کنترل را سهل تر مینماید.
چرا به نقطه پایان هر فاز و شروع فاز جدید و چرا در هر فاز پروژه باید تمامی گروههای فرآیندی اجرا گردند؟
شاید به یاد بیاورید پروژه هایی را که در سازمانها شروع میشوند و بنا بر دلایلی در میانه راه بدون هیچ دستاوردی متوقف میشوند و از آن پروژه ها فقط لیستی از هزینه های تحمیل شده به سازمان باقی میماند و یا پروژه هایی که در سازمانها در حال اجرا هستند و از منابع سازمان به مدت طولانی استفاده میکنند ولی در حال حاضر با استراتژی ها و سیاست های سازمان تضاد دارند و توقف این گونه پروژه ها مفید تر از ادامه آنهاست.
راهنمای ®PMBOK راه حل فاز بندی پروژه را جهت جلوگیری از ایجاد وضعیت های مشابه، وضعیت فوق ارائه میدهد و بر اجرای کلیه گروههای فرآیندی در تمامی فازها اصرار دارد. به طور مثال یکی از کارهای ابتدایی و آغازین پروژه صدور “منشور پروژه” (Project Charter) است، که به منزله تایید رسمی پروژه توسط سازمان و حکم مدیر پروژه می باشد و به پروژه رسمیت میدهد مطابق سطور فوق می بایست در ابتدای هر فاز مجددا منشور پروژه صادر شود و به تایید ذینفعان کلیدی پروژه برسد . اجرای این نکته ساده در پروژه ها و در ابتدای هر فاز در صورت لزوم باعث جلوگیری از ادامه پروژه های غیر ضروری و مخالف اهداف استراتژی های سازمانی خواهد شد و در صورت صدور منشور پروژه (Project Charter) جلب تعهد و حمایت مدیریت ارشد را در پی خواهد داشت که در روند اجرای پروژه تاثیر به سزایی دارد. به همین دلیل که امکان دارد شروع فاز جدید پروژه با عدم تایید سازمان به نقطه پایان پروژه تبدیل شود به این نقطه “کیل پوینت” (Kill Point) گویند. و همچنین در صورت تصمیم بر توقف پروژه به هر دلیلی در پایان فاز می بایست کلیه فرآیندهای اختتامیه برای آن فاز انجام گیرد یعنی به طور مثال کلیه دستاوردهای پروژه به صورت رسمی تحویل شود و اسناد مدارک لازم تهیه شود و “درسهای آموخته” (Lesson Learned) نیز ثبت شود. تا در صورت ادامه پروژه در آینده و فاز بعدی بتوان ازاین دستاوردها استفاده کرد و یا با رویکرد (Progressive Elaborate) کل پروژه را برنامه ریزی نمود.
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from مدرسه مدیریت پروژه و ساخت
⭕️ سطوح مختلف شکست کار
ساختارهای شکست کار به دو سطح اصلی تقسیم میشوند: سطح مدیریتی / سطح فنی؛ که هر کدام از آنها خود دارای سطوح دیگری هستند.
شکستن تعداد سطوح ساختار شکست کار به اندازه پروژه و پیچیدگی های آن بستگی دارد و تا آنجا پیش می رود که نه بیش از حد ریز شود و نه آنقدر کم باشد که نتوان آن را کنترل کرد.
♻️ به مدرسه مدیریت پروژه بپیوندید👇
@project_school
ساختارهای شکست کار به دو سطح اصلی تقسیم میشوند: سطح مدیریتی / سطح فنی؛ که هر کدام از آنها خود دارای سطوح دیگری هستند.
شکستن تعداد سطوح ساختار شکست کار به اندازه پروژه و پیچیدگی های آن بستگی دارد و تا آنجا پیش می رود که نه بیش از حد ریز شود و نه آنقدر کم باشد که نتوان آن را کنترل کرد.
♻️ به مدرسه مدیریت پروژه بپیوندید👇
@project_school
⭕️ چرخه حیات پروژه به دسته های کلی زیر تقسیم بندی می شود:
♻️ چرخه حیات پیش بینی شده یا برنامه محور (Predictive یا Plan-Driven): یک رویکرد سنتی بوده که کارهای پروژه با توجه به اینکه چندین بار در پروژه های مشابه قبلی اجرا شده است، در یک فرآیند متوالی و قابل پیش بینی انجام می شود.
♻️چرخه حیات تکراری (Iterative): معمولا محدوده کلی پروژه در فازهای آغازین مشخص بوده ولی برآورد زمان و هزینه پروژه به طور مرتب اصلاح می شود.
♻️چرخه حیات افزایشی (Incremental): رویکردی است که اقلام کامل شده را به گونه ای تحویل می دهد که مشتری بتواند به سرعت و فوریت از آن استفاده کند.
♻️چرخه حیات تطبیقی یا چابک (Adaptive یا Agile): رویکردی است که از ویژگی های چرخه حیات Iterative و Incremental به منظور اصلاح اقلام پروژه و تحویل آنها بصورت سریع و پشت سرهم (مکرر) استفاده می کند .
♻️چرخه حیات ترکیبی (Hybrid): استفاده از یک نوع چرخه حیات برای کل پروژه ضروری نمی باشد بلکه می توان اجزاء و ویژگی رویکردهای سنتی (Predictive ) و چابک (Agile) را برای رسیدن به اهداف پروژه، با یکدیگر ترکیب کرد
✅ به مدرسه مدیریت پروژه بپیوندید👇
➡️ @project_school
♻️ چرخه حیات پیش بینی شده یا برنامه محور (Predictive یا Plan-Driven): یک رویکرد سنتی بوده که کارهای پروژه با توجه به اینکه چندین بار در پروژه های مشابه قبلی اجرا شده است، در یک فرآیند متوالی و قابل پیش بینی انجام می شود.
♻️چرخه حیات تکراری (Iterative): معمولا محدوده کلی پروژه در فازهای آغازین مشخص بوده ولی برآورد زمان و هزینه پروژه به طور مرتب اصلاح می شود.
♻️چرخه حیات افزایشی (Incremental): رویکردی است که اقلام کامل شده را به گونه ای تحویل می دهد که مشتری بتواند به سرعت و فوریت از آن استفاده کند.
♻️چرخه حیات تطبیقی یا چابک (Adaptive یا Agile): رویکردی است که از ویژگی های چرخه حیات Iterative و Incremental به منظور اصلاح اقلام پروژه و تحویل آنها بصورت سریع و پشت سرهم (مکرر) استفاده می کند .
♻️چرخه حیات ترکیبی (Hybrid): استفاده از یک نوع چرخه حیات برای کل پروژه ضروری نمی باشد بلکه می توان اجزاء و ویژگی رویکردهای سنتی (Predictive ) و چابک (Agile) را برای رسیدن به اهداف پروژه، با یکدیگر ترکیب کرد
Please open Telegram to view this post
VIEW IN TELEGRAM
⭕️ مدیر محصول و مالک محصول
✅ وظایف مدیر محصول:
🔘 با انجام تحقیقات کاربر و رونمایی از بینشهای مهم، نیازهای کاربران را کشف میکند.
🔘چشم انداز و استراتژی بلند مدت محصول را ایجاد میکند.
🔘تیم را در مورد یک نقشه راه محصول منسجم هماهنگ کند.
🔘 ویژگیهایی را در محصول به کار ببندد که باعث رضایت مشتریان میشود.
🔘تیم، شرکا و ذینفعان خارجی را برای اطمینان از همسویی در مورد استراتژی و جهت کلی محصول، قانع کند.
✅ وظایف مالک محصول
🔘 تنها شخصی است که مسئولیت محصول عقب مانده را بر عهده دارد.
🔘 دردسرها و مشکلات مشتری را به داستانهای قابل استفاده کاربر تبدیل میکند، داستانهای کاربر را در اولویت قرار میدهد و داستانهای کاربر را در پس زمینه محصول مرتب میکند.
🔘 فرآیندهای تولید را میسازد و اولویتبندی میکند تا اطمینان حاصل شود که تیم توسعه نسبت به انجام کار بعدی آگاهی کامل دارد.
🔘در کلیه جلسات چابک و اسکرام شرکت میکند تا اطمینان حاصل کند که کار توسعه با نقشه راه تعیین شده توسط مدیر محصول مطابقت دارد.
🔘 صدای مشتری را به تیم توسعه انتقال میدهد.
✅ به مدرسه مدیریت پروژه بپیوندید👇
➡️ @project_school
✅ وظایف مدیر محصول:
🔘 با انجام تحقیقات کاربر و رونمایی از بینشهای مهم، نیازهای کاربران را کشف میکند.
🔘چشم انداز و استراتژی بلند مدت محصول را ایجاد میکند.
🔘تیم را در مورد یک نقشه راه محصول منسجم هماهنگ کند.
🔘 ویژگیهایی را در محصول به کار ببندد که باعث رضایت مشتریان میشود.
🔘تیم، شرکا و ذینفعان خارجی را برای اطمینان از همسویی در مورد استراتژی و جهت کلی محصول، قانع کند.
✅ وظایف مالک محصول
🔘 تنها شخصی است که مسئولیت محصول عقب مانده را بر عهده دارد.
🔘 دردسرها و مشکلات مشتری را به داستانهای قابل استفاده کاربر تبدیل میکند، داستانهای کاربر را در اولویت قرار میدهد و داستانهای کاربر را در پس زمینه محصول مرتب میکند.
🔘 فرآیندهای تولید را میسازد و اولویتبندی میکند تا اطمینان حاصل شود که تیم توسعه نسبت به انجام کار بعدی آگاهی کامل دارد.
🔘در کلیه جلسات چابک و اسکرام شرکت میکند تا اطمینان حاصل کند که کار توسعه با نقشه راه تعیین شده توسط مدیر محصول مطابقت دارد.
🔘 صدای مشتری را به تیم توسعه انتقال میدهد.
Please open Telegram to view this post
VIEW IN TELEGRAM
⭕ بیانیه کار یا (Statement Of Work (SOW
سندی است که در فاز آغازین پروژه تولید شده و توضیحات سطح بالا و اطلاعات کلی پروژه را بیان می کند تا با مطالعه آن همه ذینفعان و اعضای تیم پروژه بتوانند واقعاً آنچه را که از پروژه انتظار می رود درک کنند.
⭕ بیانیه محدوده یا Project Scope Statement
سندی است که جزئیات بیشتری از آنچه در SOW پروژه بیان شده بود را به همراه محدودیت ها و فرضیات پروژه، ارائه می دهد و این سند ممکن است در طول چرخه حیات پروژه هنگامی که شناخت بیشتری نسبت به الزامات، محدودیت ها، جزئیات و … جمع آوری شد، به تدریج تکمیل شود.
در این بیانیه به موارد زیر اشاره می شود:
اهداف پروژه
محدوده پروژه
محدوده محصول
الزامات
مرزبندی
اقلام قابل تحویل
معیارهای پذیرش
محدودیت ها
فرضیات
میل استون ها
نحوه برآورد هزینه
مشخصات فنی
الزامات مدیریت پیکربندی
الزامات تائیدی
✅ به مدرسه مدیریت پروژه بپیوندید👇
➡️ @project_school
سندی است که در فاز آغازین پروژه تولید شده و توضیحات سطح بالا و اطلاعات کلی پروژه را بیان می کند تا با مطالعه آن همه ذینفعان و اعضای تیم پروژه بتوانند واقعاً آنچه را که از پروژه انتظار می رود درک کنند.
⭕ بیانیه محدوده یا Project Scope Statement
سندی است که جزئیات بیشتری از آنچه در SOW پروژه بیان شده بود را به همراه محدودیت ها و فرضیات پروژه، ارائه می دهد و این سند ممکن است در طول چرخه حیات پروژه هنگامی که شناخت بیشتری نسبت به الزامات، محدودیت ها، جزئیات و … جمع آوری شد، به تدریج تکمیل شود.
در این بیانیه به موارد زیر اشاره می شود:
اهداف پروژه
محدوده پروژه
محدوده محصول
الزامات
مرزبندی
اقلام قابل تحویل
معیارهای پذیرش
محدودیت ها
فرضیات
میل استون ها
نحوه برآورد هزینه
مشخصات فنی
الزامات مدیریت پیکربندی
الزامات تائیدی
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from بانک کتاب PMBOOKS
cover
#مدیریت_برنامه #مدیریت_پروژه
دانلود
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM