برگزاری دوره آموزشی مدیریت مالی
نام دوره : دوره آموزشی مدیریت مالی برای مدیران غیر مالی
شرکت : گروه ماموت
زمان : آبان 1401
مدرس : خانم مهندس آرزو گودرزی
تعداد مخاطبین : 18 نفر
نام دوره : دوره آموزشی مدیریت مالی برای مدیران غیر مالی
شرکت : گروه ماموت
زمان : آبان 1401
مدرس : خانم مهندس آرزو گودرزی
تعداد مخاطبین : 18 نفر
در ادامه قسمت دوم پست “بایدهای مدیریت پروژه: پارادوکس استخدام مهارت یا استعداد!”، این قسمت به موضوع چگونگی شناسایی یه توسعه دهنده یا متخصص خوب میپردازه.
مدیران پروژه نرم افزاری میدانند که موفقیت پروژه به داشتن برنامه نویسان خوب بستگی دارد. حالا چطور افراد مناسب رو در انبوه متقاضیان تشخیص دهیم؟
پیشنهاد شماره 1: با متخصصان حاضر در شرکت خودتون مشورت کنید.
قبل از مصاحبه با کاندیداهای جدید، با بهترین متخصصان خودتون تو اون حوزه کاری که قرار هست نیرو استخدام کنید، (مثلا بهترین برنامه نویس) صحبت کنید.
از اونها بخواین دانش خاص مورد نیاز شرکت و تیم رو دوباره توضیح بدهند. آیا تجربه بلند مدت یک نوع برنامه نویسی خاص، متدولوژی خاص، مجموعه ابزارهای خاص، یا دانش خاصی (مثلا تجربه در صنایع دفاعی یا بخش داروسازی) اولویت داره یا اجباری ست؟
پیشنهاد شماره 2: دانش مورد نیاز را ارزیابی کنید.
مصاحبهها رو با آزمونهای آکادمیک، با حضور خودتون و نمایندگان مورد اعتماد تیمتون ترکیب کنید. یک مهندس نرم افزار خوب میتونه خطاهای “ماک” را سریع و بدون هیچ استرسی رفع کنه. اون میتونه کد دیگران رو بخونه و هدف اون رو بدون داشتن مستندات یا ترجمه، بفهمه. وقتی که با یک مشکل برنامه نویسی مواجه میشه، باید بتونه اون رو تشخیص بده و در نهایت بتونه هم به زبان برنامه نویسی و هم به زبان مناسب برای ذینفعانی که با فناوری اطلاعات آشنا نیستند، کد نوشته شده یا مشکل رو توصیف کنه.
فرضیه: همه ما موقع استخدام افراد ماهر، فکر میکنیم داشتن دانش بیشتر، امتیاز بیشتری داره.
«بیشتر » یعنی چقدر؟ چطور «بیشتر» رو تعریف کنیم؟ شاید یک متقاضی دانش بسیار خوبی داشته باشد، اما همین فرد ممکنه هنوز ظرافت لازم رو برای بهکارگیری مؤثر اون نداشته باشه.یک فارغ التحصیل یا یک برنامه نویس تازه آموزش دیده ممکنه زمان مواجهه با یک پروژه واقعی، سخت تلاش کنه تا دانش آکادمیک به دست اومده حین آموزشهای خودش رو به کار بگیره. ولی زمانی که ددلاینها، زمان پروژه رو برای پیدا کردن راه حل فشرده میکنه و پای ذینفعان و فشارهای شدید کارفرما در میان باشه، شما بیشتر به تجربه به جای دانش خام نیاز دارید.
تجربه دانش ما رو در طول زمان صیقل میده و آنرا پخته تر و بی نقص تر میکنه
پیشنهاد شماره 3: یک کار آزمایشی هر چند کوچک ازش بخواهید.
از متقاضی شغل (برنامه نویس) بخواهید کدی رو توسط شما و تیمتون بنویسه. پس از تجزیه و تحلیل کد و صحبت با توسعه دهندگان مورد اعتماد خودتون، متوجه خواهید شد که آیا رویکرد و سبک این شخص برای تیم شما مناسب هست یا نه.رفتار فرد نسبت به کار، همکاران، کارفرمایان و ذینفعان رو زیر نظر داشته باشید.
تجربه شخصی:
تو یه دورهای با یه توسعه دهنده که اسم مستعارش “سشوار” بود، کار کردم. وقتی ناراحت میشد، میتونست با فریادهاش موهای مردم رو خشک کنه. اون یک برنامه نویس عالی بود ولی برای یک تیم پروژه مضر بود.
همون جور که دنیا داره به سمت روشهای توسعه چابک پیش میره، ارتباطات متقابل عملکردی و مهارتهای نرم اهمیت بیشتری پیدا میکنه.
جمع بندی – زمان استخدام، این دستورالعملهای ساده رو در نظر داشته باشید:
با متقاضیان برای دانش صحیح و بروز، متدولوژی، مجموعه ابزارها و آشنایی اونها با این صنعت مصاحبه و در نهایت انتخاب کنید.
توانایی اونها در به کارگیری دانششون در محل کارتون رو بررسی کنید.
مهارتهای ارتباطی و اجتماعی متقاضیان رو بررسی کنید.
به دنبال نگرش و رفتار صحیح نسبت به کار باشید (تعادل بین تمایل به ایجاد محصولات درجه بالا و در عین حال پذیرفتن محدودیتهای پروژه). آیا شواهد مستندی وجود داره که نشون بده اونها میتونن محصولاتی رو تولید کنن که در راستای هدف، به موقع و در چارچوب بودجه باشد؟
حرف آخر (پارادکس استخدام مهارت یا استعداد):
✍️ مهم نیست که متقاضی شما چقدر با شخصیت و ماهره! همیشه اعتبار مدارک اونها رو استعلام کنید.
✍️ رزومهشان را با کارفرمایان سابق بررسی کنید، چون روشهای دقیق استخدام میتونه از بسیاری از مشکلات آینده جلوگیری کند.
در ادامه قسمت اول پست “بایدهای مدیریت پروژه: پارادوکس استخدام مهارت یا استعداد!”، این قسمت به موضوع استفاده از توسعه دهندگان ماهر در مقایسه با توسعه دهندگان معمولی یا متوسط می پردازه.
باید بدانیم و بپذیریم که توسعهدهندگان حرفهای نرم افزار، خیلی بهرهورتر از توسعهدهندگان معمولی هستند. در واقع، برخی از آمارها می گویند که توسعه دهندگان واقعاً خوب چندین مرتبه – میشه گفت 10 برابر – بهتر از توسعه دهندگان ضعیف هستند. نکته اصلی اینه که
یک برنامه نویس ماهر فقط کمی بهتر از یک برنامه نویس معمولی نیست؛ تفاوتشون از زمین تا آسمونه
اما این چه معنا و مفهومی میتونه داشته باشه برای مدیران تازه کار یک پروژه نرم افزاری که در حال برنامه ریزی برای توسعه یک محصول هستند؟ مدیران به اشتباه فکر میکنند که اگر نتونید بهترین و باهوشترین توسعه دهندگان رو استخدام کنید، باز هم میتونید از توسعه دهندگان متوسط یا معمولی استفاده کرده و به هدفتان برسید. اما توسعه نرم افزار مثل حفر خندق نیست که حتی با ضعیفترین حفارها هم بتونید یک چاله بکنید.
در توسعه نرم افزار، چیزی که امروز برنامه نویسی شد، میشه پایه و اساس برای فردا. اگر نرم افزار شما توسط توسعه دهندگان معمولی پایه ریزی شده باشه، به محض ورود توسعه دهندههای حرفهای، باید قبل از هرچیزی به عقب برگردند و ایرادات و نواقص قبلی را برطرف کنند (که کم هم نیستند!). استخدام توسعهدهندگان معمولی، سرعت (Velocity) تیم پروژه رو کاهش میده.
اغلب، حذف یک کارمند ضعیف از تیم، مفیدتر از اضافه کردن یک کارمند خوب هست
تازه، واقعیت اینه که اضافه کردن افراد به یک پروژه تأخیردار، حتی ممکنه انجام اون پروژه رو بیشتر به تعویق بندازه. مدیران پروژه نرم افزاری بی تجربه ممکنه فقط به این دلیل که با افزایش تعداد کارگر، بارگیری کامیون ها سریعتر انجام میشه، تصور کنند که استخدام برنامه نویس بیشتر، زمان لازم برای تکمیل پروژه نرم افزاری را کوتاه میکنه! این کار فایدهای نداره! اینکار زمان بره، چراکه برنامه نویسان قدیمی باید برای به روز و مطلع کردن نفرات جدید وارد میدان بشن و در این مدت کار خودشون رها میشه به امان خدا!
در ضمن، تعداد کانالهای ارتباطی پروژه هم با اضافه شدن هر نفر به تیم به صورت نمایی زیاد میشه. چطوری؟! یک تیم دو نفره، یک کانال ارتباطی داره. تیم 3 نفره، 3 کانال. تیم 4 نفره، 6 نفر. تیم 12 نفره 66 کانال ارتباطی داره.میبینید که تعداد کانالهای راتباطی با اضافه شدن آدمها به طور تصاعدی زیاد میشه که فرمولش هم n(n-1)/2 هست. به عنوان مدیر پروژه با داشتن یک تیم 12 نفره باید 66 کانال ارتباطی یا رابطه رو مدیریت و اداره کنید. حالا اگه بخاطر عقب ماندن کارها یک نفر دیگه را به تیم اضافه کنید، تعداد 78 کانال ارتباطی برای نظارت خواهید داشت و این یعنی با اضافه شدن یک نفر به تیم 12 نفری، در واقع 12 کانال ارتباطی جدید به پروژه اضافه کردید که خودش یک عامل مهم افزایش پیچیدگی پروژه هست!
توسعه نرم افزار با توسعه دهندگان معمولی، 2 افسانه پروژه را برملا میکنه:
🧨 اول اینکه میتونید زمان پروژه رو با افزودن افراد، کوتاه کنید.
🧨 دوم اینکه توسعه دهندههای معمولی کدهای معمولی (همراه با باگ) و با سرعت متوسط تولید میکنند. در حقیقت توسعه دهندههای معمولی باعث کاهش بهره وری کلی و طولانی شدن بیش از حد پروژه میشن.
حالا راه حل چیه؟
💡 اول: به توسعه دهندگان حرفهای ابزار قدرتمند بدید. با این کار سریعتر نرم افزاری با کیفیت بالاتر به دستتون میرسه.
💡 دوم: داشتن آدم هایی با کارایی و مسؤلیت کم به پروژهها کمکی نمیکنه و تازه! مراقبت و نگهداری از توسعه دهندگان ضعیف، بهره وری توسعه دهندگان حرفهای (که نیروهای اصلی و حیاتی هستند) را هم کم میکنه. نرم افزار بسیار پیچیدهتر از اونی هست که به یک فرآیند خط مونتاژ در تولید تبدیل و تشبیه بشه.
اگه توسعه سریعتر نرم افزار می خواهید، پول بیشتر را برای استخدام و پرورش توسعه دهندگان عالی نرم افزار خرج کنین. مطمئن باشید که هم در کوتاه مدت و هم در درازمدت (برای نگهداری و بازبینی کدها)، نتیجه آنرا خواهید دید.
پارادوکس استخدام مهارت یا استعداد!
قسمت اول: به جای مهارت، به دنبال استعداد برای تیمتون باشید.
قبلا نفرات رو مثل بقیه شرکتها فقط بر اساس مهارت استخدام میکردم. تا این که یک روز یه نفر از آدمایی که باهاش مصاحبه میکردم آب سردی رو سرم ریخت و این باعث شد تغییر کنم.
دنبال این بودم که یک قهرمان جدید رو به تیمم اضافه کنم. یک نفر با سالها تجربه در تو یه شرکت بزرگ و معتبر. وقتی به رزومه آقای قهرمان نگاه کردم، گفتم خودشه. اون تو تمام مهارتهای مختلف حداقل شش سال تجربه داشت. اگر میتونستم سر حقوق هم باهاش به توافق برسم، کارم دیگه راحت میشد.
قهرمان برای مصاحبه اعلام آمادگی کرد و اومد. ما در مورد پروژهای که قصد انجامش رو داشتیم صحبت کردیم و به این نتیجه رسیدم که بهترین گزینه برای این کار آقای قهرمان است. مطمئن بودم که همه چیز داره خوب پیش میره که یهو متوجه شدم که نمیتونم اونو شکار کنم. مصاحبه رو قطع کردم و ازش پرسیدم که چه اتفاقی افتاده؟ بهش گفتم که برای این موقعیت عالی است اما به نظر میرسه تمایلی به این کار نداره.
می دونی جوابش چی بود؟ جوابش این بود: “اگه میخواستم چیزی رو که تو شش سال گذشته انجام دادم رو دوباره انجام بدم، همون جای قبلی خودم میموندم. شنیدم شما قصد انجام یه تعداد پروژه جالب نرم افزاری رو دارین و یه شانس برای یادگیری و ترقی دیدم.”
همون جا متوجه شدم که استخدام بر مبنای مقایسه و تطابق”رزومه دربرابر مهارت” کاهلی بزرگیه که یک مدیر میتونه تو تشکیل تیم خودش انجام بده.
من و همکارانم وارد صنعت فناوری نوین شدیم چون میخواستیم تو این زمینه پیشرو باشیم. هیچ کدوم از ما نمیخواستیم شغلمون رو صرف همون مهارتهایی کنیم که تو دانشگاه یاد گرفتیم. برای همین وارد این بازی شدیم چون همیشه هدفمون ورود به جبهه جدید و یادگیری فناوریهای جدید است.
ولی خوب تو این مسیر مشکلاتی پیش اومد که متوجه شدم ما برای رشد کارکنان خودمون سرمایه گذاری را متوقف کرده ایم. ما به دنبال استعداد جدید نبودیم. فقط دنبال مهارتی خاص و از قبل آماده، بودیم. اما حالا به همه میگم که:
اگر کارفرمایی به دنبال استخدام مهارت خاصی بود، منظور اون از این حرف اینه که “ما قصد سرمایه گذاری روی شما را نداریم”
پیشنهاد من به افرادی که دنبال ساختن یک تیم قوی هستند اینه که:
استعدادها رو شکار کنید و نه مهارتها را
برای تشکیل تیم توسعه چابک خود باید دنبال چه استعدادهایی باشیم؟ به نظر من مهارتهای مهد کودکی خوب:
🧸 آیا با دیگران خوب سازش میکنه؟
🧸 تو بازی کردن خوش اخلاقه؟
🧸 آیا اسباب بازیهای خودش رو بعد از بازی جمع میکنه؟
🧸 اصلا برای تجربههای جدید هیجان داره؟
🧸 آیا یادگیری رو دوست داره؟
من میتونم مهارت رو یاد بدهم. در واقع، تو محیط تیم چابک، یادگیری فناوری، سریع و آسونه.
ولی یاد دادن به یک بزرگسال که چطوری خوش اخلاق باشه خیلی سخت و شاید هم نشدنی باشه!
استخدام استعداد به جای مهارت کار هوشمندانهای تو تشکیل یه تیم هست. ولی من میخوام با افرادی کار کنم که حاضرند کنار من به سمت تکنولوژی هیجان انگیز آینده جلو برند.
من میگم توی دکمههای مایکروویو یک دکمه اهمیت داره: “افزودن یک دقیقه“
برای جوشاندن یک فنجان آب برای قهوه، سه بار فشارش میدم. برای ذوب کردن پنیر یک بار. برای گرم کردن نان، یک بار دکمه “افزودن یک دقیقه” رو فشار میدم و بعدش کافیه درب ماکروویو را پس از 15 ثانیه باز کنم.
شاید به نظر برسه که “مایکروویو یک دکمهای” جایی در ذهن کمیتهی طرحریزی نداشته باشه اما نظر من متفاوته. میتونم از امکانات مایکروویوم که هرگز استفاده نشده این نتیجه رو بگیرم که کمیتهی طرحریزی، پیچیدگی را بر سادگی ترجیح داده. البته ممکنه اونها “پیچیدگی” رو با مفهوم”پر از ویژگیها” جایگزین و یا پوشش بدن.
هرگز هیچ فردی با هدف ساخت محصولی پیچیده شروع به کار نمیکنه. پیچیدگی به طور تصادفی به وجود میاد.
فرض کن من یک تکه پیتزای سرد دارم که میخوام گرمش کنم. براساس دستورالعمل سازنده، باید دکمه “منو” را فشار بدم. حالا گزینههای “پخت سریع” یا “گرم کردن مجدد” رو میبینم (وای! خیلی گرسنمه، نمیدونم گزینه “پخت سریع”، سریعتره یا گزینه “گرم کردن مجدد”؟)
تازه! مرحله بعد سوال و جواب با مایکروویو ادامه داره! انتخاب از بین گزینههای “نوشیدنی”، “پاستا”، “پیتزا”، “بشقاب غذا”، “سس” یا “سوپ” هستش. (“پیتزا” را انتخاب میکنم، هرچند داخل بشقابه و روی اون سس ریختم!)
تازه حالا باید یکی از گزینههای”1 برش”، “2 برش”، “3 برش”، یا “4 برش” را انتخاب کنم! نمیدونم این بازجویی چقدر طول میکشه! اینجاست که دیگه بیخالش میشم و دکمه کنسل رو میزنم و میرم سراغ همون دکمه “افزودن یک دقیقه”. خلاص.
خب این موضوعات چه ارتباطی به ساخت و توسعه نرمافزار داره؟!
تا جایی که به من مربوط میشه، وبسایت آمازون فقط یک دکمه داره: “خرید با یک کلیک”. البته که در خرید اول از این وبسایت باید آدرس و شماره کارت اعتباری خودم را وارد میکردم، اما الان به اندازه یک کلیک با خرید فوری فاصله دارم! مگه نه؟!
نرمافزارها به طور کلی مشکلات پیچیده را حل میکنند. سوال اینه که چه میزان از این پیچیدگی رو به کاربر نهایی تحمیل میکنی؟ آیا نرمافزارت پیچیدگی رو بیشتر میکنه؟ نرمافزار عالی عموما پیچیدگیهایی داره. شما به عنوان یک مدیر پروژه نرمافزاری، پیچیدگی را کاهش میدید یا افزایش؟
بهترین مدیر پروژه، پیچیدگی را برای همه طرفهای ذینفع (برنامه نویسان، کاربران نهایی، مدیران) حذف میکنه و هیچ وقت پیچیدگی رو افزایش نمیده.
🚦 از آنجایی که کاربران نهایی نیازهای به ظاهر متناقضی ایجاد میکنند، وظیفهتون کمک به رفع آنهاست و نه این که این نیازها رو کورکورانه به توسعه دهندگان انتقال بدید.
🚦 از آنجایی که سازندگان نرم افزار، دلایل فنی مبهمی را برای ناتوانی در انجام یک الزام بیان میکنند، وظیفه شما اینه که پیچیدگی رو کم کنید و اطلاعات کافی به کاربران نهایی ارایه بدید تا به آنها در انتخاب مسیر متفاوت کمک کنید.
راستی!
📍 استفاده از اپلیکیشن مدنظر شما چقدر ساده است؟
📍 چقدر آسونه که یک ویژگی جدید به برنامه خودت اضافه کنی؟
📍 درخواست یک ویژگی جدید چه میزان ساده است؟
📍 گزارش یک مشکل (باگ) برای رفع آن چطور؟
📍 استقرار نسخه جدید نرم افزار چطور؟ شاید برگشتن به نسخه قبلی به این دلیل که نسخه جدید مشکل دارد را ترجیح میدهید!
ذینفعان پروژه اغلب موضوعات را بیشتر از آنچه باید باشه پیچیدهتر می کنند که یکی از دلایل رایج شکست پروژههای نرمافزاریه. تیم پروژه باید بتونن اهداف و کارهای پروژه رو کامل تجسم کنن. اگرچه، ذینفعان میتوانند تو ذهنشون پروژه رو تو چند مرحله ساده و جادویی انجام بدن. اونا فکر میکنند که به سرعت و به راحتی به راه حل نهایی میرسن، مهم هم نیست چقدر پیچیده باشه.
ذینفعان نباید یک پروژه نرمافزاری را به یک هیولای صلب، غول پیکر و انعطاف ناپذیر تبدیل کنن. در عوض، اونا باید به تیم فناوری اطلاعات اجازه بدن تا پروژه رو شبیه یک پیاز بسازن و تو هر لایه بلوغش رو افزایش بدن. جایگزین دیگهای براش در دنیای واقعی نیست. باوجود کامل بودن الزامات، همیشه تغییر وجود داره.
اگر نرمافزارتون به اندازه کافی انعطاف پذیر نیست که بتونه به سرعت با نیازهای در حال تغییر سازگار بشه، این پروژه حتی قبل از شروعش مرده.
برای ساده نگه داشتن چیزها، این نکات کلیدی رو به خاطر داشته باش:
💡 الزامات را ساده کن!
تحلیلگران کسب و کار اغلب راه حل خاصی را که به ذهنشون میرسه رو با نیاز واقعی مشتری بر اساس یک نیاز تجاری قاطی میکنن. با این که نیاز واقعی ممکنه بسیار ساده باشه، شاید شکاف ارتباطی بین تحلیلگران کسب و کار و برنامه نویسان/ توسعه دهندگان، به خاطر این وجود داشته باشه که هیچ کدومشون واقعاً نمیدونه دیگری چه میکنه.
تحلیل گران کسب و کار الزامات رو با شکلهای نمودار درختی تعریف میکنن. الزام اصلی، هدف ساده و بدیهی کل پروژه است. الزامات کلانتر در شاخههای بالاتر به الزامات کوچکتر در شاخههای کوچک سطح پایین شکسته میشوند. این روند در نمودار درختی تا زمانی تکرار میشه که هر الزام به صورت واضح مشخص شده باشه. نرمافزارهای Mind-map میتونن برای مستندسازی الزامات با استفاده از این روش استفاده بشن.
به محض این که مجموعه کوچکی از الزامات مشخص شدن، توسعه نرمافزار میتونه آغاز بشه
💡 فرآیندهای توسعه چابک را دنبال کن!
به محض شناسایی مجموعه کوچکی از الزامات، تیم توسعه میتونه فوری نمونهسازی رو شروع کنه. هنگامی که نمونه اولیه در دسترس باشه، ذینفعان میتونن آزمایش کنن و بازخورد ارائه بدن. بازخورد مشتری تضمین میکنه که الزامات دقیق هستند و همچنین به شناسایی شکافهایی که در الزامات ایجاد شده است کمک میکنه. شکافها به نیازمندیهای جدید تبدیل میشن، توسعه دهندگان دوباره نمونه سازی میکنن و این چرخه ادامه پیدا میکنه. هر چرخه باید تا حد امکان کوتاه باشه- معمولا بیش از دو تا سه هفته نیست.
این چرخه، با تعریف “مجموعه کوچکی از الزامات”، “تولید یک نمونه اولیه” و “دریافت بازخورد”، تضمین میکنه که همه ذینفعان پروژه همیشه در یک سطح هستن و همه با آنچه در حال جریانه، راحت باشن. با پیروی از این تکنیکها، هر پروژه نرمافزاری میتونه به یک نتیجه موفقیت آمیز برسه. مخصوصا زمانی که موفقیت در قالب مشتری راضی و نرمافزاری کارا تعریف شده باشه که دلیل و چرایی که بخاطرش پروژه تعریف شده را برآورده کرده باشه.
خلاصه اینکه:
سادگی تصادفی اتفاق نمیافته. نیازه که به صورت فعالانه ترویج داده بشه. پیچیدگی زمانی اتفاق میافته که بهش توجه نکنی.
©️ توجه: کلیه حقوق این پست مربوط به شرکت راهبران سیستم رستاک بوده و کپی، نقل قول و یا چاپ مطالب در سایتها، شبکه های اجتماعی و یا بصورت کتاب و جزوه بدون ذکر منبع پیگرد قانونی دارد.
فیلم کوتاه حضور رستاک در شانزدهمین کنفرانس بین المللی مدیریت پروژه با دو ارائه جناب آقای مهندس روزبه کتب زاده با عنوان “پروژه ها در تاب و تاب چابکی” و جناب آقای دکتر علی واحدی با عنوان “هفت شاه کلید کار تیمی” که مورد استقبال زیاد شرکت کنندگان عزیز قرار گرفت. کلیپ زیر مروری کوتاه بر حضور رستاک در این کنفرانس و با حضور گرم شما میباشد.
✍️ همیشه بزرگترین سرمایه رستاک، حمایت و همراهی همیشگی شما عزیزان بوده و از لطف و محبت و بازخوردهای فوق العاده پرانرژی که به ما دادید بینهایت متشکریم.💐🙏
شرکت راهبران سیستم رستاک همچون سالهای گذشته در شانزدهمین کنفرانس بین المللی مدیریت پروژه حضور یافت و دو ارائه عالی را که مورد استقبال زیاد شرکت کنندگان قرار گرفت را تقدیم دوست داران و علاقمندان مدیریت پروژه نمود:
📍 ارائه جناب آقای مهندس روزبه کتب زاده با عنوان “پروژه ها در تاب و تاب چابکی”:
سالهاست رویکرد چابک (اجایل) به عنوان یکی از رویکردهای جذاب و موفق در دنیای پروژه ها مطرح شده و شرکتهای بسیاری یا در حال استفاده از آن هستند، یا سعی دارند از آن در پروژه های خود استفاده کنند. اما مثل هر مفهوم جدید، در مورد اجایل نیز تفسیرها، تعابیر و اقدامات اشتباه زیادی به نام اجایل مطرح شده، مانند: “اجایل نیازمند برنامه ریزی و مستندات نیست” و یا “اجایل صرفا در پروژه های نرم افزاری قابل استفاده است”. در این ارائه ضمن برشمردن این “اشتباهات رایج” به موارد زیر نیز پرداخته شد:
• آیا اجایل به تنهایی کافیست؟
• چگونه بفهمیم اجایل مناسب پروژه ما هست؟
• اجایل و پروژه های غیر نرم افزاری
• نمونه های موفق و ناموفق
📍 ارائه جناب آقای دکتر علی واحدی با عنوان “هفت شاه کلید کار تیمی”:
چرا برخی تیمها همواره به عملکرد بالا دست مییابند در حالی که سایر تیمها که ظاهراً فرقی با آنها ندارند، برای نتیجه گرفتن جان میکَنند؟ اصلاً آیا هاله تقدسی که سالهاست بر گرد تیمها شکل گرفته درست است؟ اصلاً تیم “واقعی” به چگونه تیمی میگوییم؟ سازمان یک تیم موفق چگونه ساختاری دارد؟ روش تصمیمگیری در تیمهای موفق چگونه است؟ پاسخ سوالات فوق را به زبان ساده و در هفت پرده نمایش بررسی کردیم.
✍️ همیشه بزرگترین سرمایه رستاک، حمایت و همراهی همیشگی شما عزیزان بوده و از لطف و محبت و بازخوردهای فوق العاده پرانرژی که به ما دادید بینهایت متشکریم.💐🙏
Learning to Fly: Practical knowledge management from some of the world’s leading learning organizations
جوامع علمى و تجارى هر دو بر این باورند که سازمانها با قدرت دانش مىتوانند برترىهاى بلندمدت خود را در عرصههاى رقابتى حفظ کنند و دانشمندان در تحقیقات خود دریافتهاند که مدیریت دانش برخلاف مدیریتهاى دیگر زودگذر نیست، بلکه اثرات ماندگارى دارد. شرایط و فضاى رقابتى سازمانها بیش ازپیش پیچیده و به سرعت درحال تغییر است؛ به گونهاى که سرعت تغییر در بیشتر سازمانها به مراتب بیشتر از سرعت توان پاسخگویى و تطبیق آنهاست. تغییرات مستمر دانش نیز وضعیت عدم تعادل جدیدى را براى سازمانها به وجود آورده است. در این میان تنها سازمانهایى مىتوانند به حیات خود ادامه دهند که قادر باشند مزیت رقابتى خود را حفظ کنند. به نظر اندیشمندان این عرصه حفظ مزیت رقابتى و بقاى سازمان به کمک مدیریت دانش امکان پذیر است.
جوامع علمى و تجارى هر دو بر این باورند که سازمانها با قدرت دانش مىتوانند برترىهاى بلندمدت خود را در عرصههاى رقابتى حفظ کنند
در این کتاب کریس کالیسون و جف پارسل، تجربه هاى خود را در گسترة وسیعى از سازمان هاى پیشرو و یادگیرنده در مدیریت دانش به اشتراك گذاشته اند. این کتاب تمرینى کاربردى و عملگرایانه همراه با رهنمودها و اشاراتى است که به مدیران کمک مى کند تا مدیریت دانش را در کوتاه ترین زمان به اجرا درآوردند.
کتاب یادگیرى پرواز ، مرجعى مناسب از تجربههاى مدیران دانش سازمانهاى مختلف و در عرصههاى مختلف است و راه حل عملى به کاربستن مدیریت دانش براى رسیدن به موفقیتهاى سریع و ملموس را نشان مى دهد. این کتاب راهنمایى اندیشمندانه و قابل اجرا براى مدیریت دانش تدارك دیده است.
این کتاب توسط کریس کالیسون و جف پارسل نگاشته شده و انتشارات Capstone در لندن در سال 2004 و در 332 صفحه به چاپ رسانده است. کتاب حاضر را حمیدرضا مهربد، افسانه شیخ محمدى، امید اصغرزاده و مریم اصغرزاده ترجمه کرده اند.
انتشارات فرهنگ رسا این کتاب را در 289 صفحه در قطع وزیرى در سال 1394 منتشر کرده است.
این پادکست قسمت سوم از سری پادکستهای “هفت عادت مردمان مؤثر” (Seven Habits of Highly Effective People) با بیان دکتر علی واحدی دیز هست که به اصل بنیادین دوم “پارادایم و تأثیر آن بر زندگیمان” میپردازد.
کار کردن روی منش به معنای همسو سازی پارادایمهای شخصی با اصول جهانی است. پارادایم عینکی است که بوسیله آن دنیا را تماشا میکنیم. پارادایم، چارچوب فکری و ذهنی هر فرد است که از طریق آن واقعیتهای محیط پیرامون را تحلیل و توصیف میکند. پارادایم شامل اصول بنیادین هر فرد است که منش و سیرت فرد را میسازد. عادتهایی که در ذهن ما شکل گرفته و رفتارهایمان از آن نشأت میگیرد، مستقیما تحت تاثیر پارادایمی است که در ذهنمان نقش بسته است. منشأ کلیدی و سرچشمه بسیاری از مشکلات و همچنین تحولات ما بر طرز فکر و نقشه ذهنی ما یعنی پارادایم مرتبط است!
چقدر زیبا میگه حضرت مولانا:
پیش چشمت داشتی شیشهی کبود ز آن سبب عالم کبودت مینمود
گر نه کوری این کبودی دان ز خویش خویش را بد گو، مگو کس را تو بیش
ذخیرهها از جمله موضوعاتی هستند که دربسیاری از پروژههای ما مغفول واقع شده و به همین دلیل هم جایگزین بد آن پدینگ یعنی “دست بالاگرفتن” در برآوردها بیشتر شنیده شده است. با تعریف درست ذخیرهها میتوان هم شفاف بود و هم صادق. هم برآورد منطقی داشت و هم در عین حال ذخیرهای برای روز مبادا. در این پادکست قصد داریم شما را با انواع ذخیره ها (Types of Reserve) در مدیریت پروژه حرفهای آشنا کنیم.
با تعریف درست ذخیرهها میتوان هم شفاف بود و هم صادق. هم برآورد منطقی داشت و هم در عین حال ذخیرهای برای روز مبادا.
🤗 راستی اگه دوست داشتید یک ویدئو از دوران جوانی من 🤓 در مورد انواع ذخیره ها ببینید، ویدئوی زیر را ملاحظه بفرمایید.
ممنون از اینکه همراه ما هستید 💐 و ما را از سوالات و نظرات خود آگاه میکنید.🙏
آدرس : تهران، بلوار مرزداران ، بين اشرفی اصفهانی و يادگارامام، شماره 178 ، مجتمع نگين آسمان بلوک C ، طبقه 4 ، واحد 15
ایمیل:
info[at]rsrastak[dot]com
تلفکس:
44220680 | 44220699 | 44256532