نوشته‌ها

بایدهای مدیریت پروژه: پارادوکس استخدام مهارت یا استعداد!

بایدهای مدیریت پروژه: پارادوکس استخدام مهارت یا استعداد! (قسمت سوم)

پارادوکس استخدام مهارت یا استعداد: چگونه یک توسعه دهنده یا متخصص خوب را شناسایی کنیم!

بایدهای مدیریت پروژه - عکس

در ادامه قسمت دوم پست “بایدهای مدیریت پروژه: پارادوکس استخدام مهارت یا استعداد!”، این قسمت به موضوع چگونگی شناسایی یه توسعه دهنده یا متخصص خوب می‌پردازه.

مدیران پروژه نرم افزاری می‌­دانند که موفقیت پروژه به داشتن برنامه نویسان خوب بستگی دارد. حالا چطور افراد مناسب رو در انبوه متقاضیان تشخیص دهیم؟

مدیران پروژه نرم افزاری

 

پیشنهاد شماره 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 می‌تونن برای مستندسازی الزامات با استفاده از این روش استفاده بشن.

به محض این که مجموعه کوچکی از الزامات مشخص شدن، توسعه نرم‌افزار می‌تونه آغاز بشه

 

💡 فرآیندهای توسعه چابک را دنبال کن!بایدهای مدیریت پروژه: سادگی را بر پیچیدگی ترجیح دهید!

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

این چرخه، با تعریف “مجموعه کوچکی از الزامات”، “تولید یک نمونه اولیه” و “دریافت بازخورد”، تضمین می‌کنه که همه ذینفعان پروژه همیشه در یک سطح هستن و همه با آنچه در حال جریانه، راحت باشن. با پیروی از این تکنیک‌ها، هر پروژه نرم‌افزاری می‌تونه به یک نتیجه موفقیت آمیز برسه. مخصوصا زمانی که موفقیت در قالب مشتری راضی و نرم‌افزاری کارا تعریف شده باشه که دلیل و چرایی که بخاطرش پروژه تعریف شده را برآورده کرده باشه.

 

خلاصه اینکه:

سادگی تصادفی اتفاق نمی‌افته. نیازه که به صورت فعالانه ترویج داده بشه. پیچیدگی زمانی اتفاق می‌افته که بهش توجه نکنی.

بایدهای مدیریت پروژه: سادگی را بر پیچیدگی ترجیح دهید!

 

 

©️ توجه: کلیه حقوق این پست مربوط به شرکت راهبران سیستم رستاک بوده و کپی، نقل قول و یا چاپ مطالب در سایت‌ها، شبکه های اجتماعی و یا بصورت کتاب و جزوه بدون ذکر منبع پیگرد قانونی دارد.