احسان رضایی

یک توسعه دهنده، شاید هم نه.

عدم موفقیت پروژه های نرم افزاری قسمت اول

در دست نوشته ها , / تاریخ ارسال 1398/07/08 - 17:55 / 0 نظر / 49 بازدید / آخرین ویرایش 1398/09/16 - 13:37

fail

اجازه بدین قبل از شروع این موضوع آماریُ خدمتتون ارائه بدم.

در سال 2016 تخمین زده شد حدود 21 میلیون توسعه دهنده حرفه ای نرم افزار در سراسر دنیا فعالیت میکنن. با این حال:

75 درصد مدیران فناوری پیش بینی میکنن پروژه های نرم افزاری اونها شکست میخوره.

- در پروژه های موفق، کمتر از یک سوم اونها با بودجه و زمان مشخص شده به پایان میرسن.

سعی میکنم در مورد رایج ترین خطاها بنویسم. خوشحال میشم تجربه ی خودتون رو به اشتراک بذارین تا این موضوع رو کاملتر کنم. موارد زیر خطاهایی هست که من بهشون فکر میکنم:

1) داشتن شور، اشتیاق، امید و انگیزه. اما تخصص نه!

فرآیند تولید نرم افزار یک فرآیند پیچیده است، اینکه سرشار از شور، اشتیاق، امید و انگیزه هستین اما تخصص لازم برای مدیریت تیم نرم افزاریُ ندارین یعنی نباید درش دخالت کنید. اگر پروژه تون به میزان قابل توجهی بزرگ هست به پیدا کردن مدیر فکر کنید نه مدیریت. اجازه بدین باهاتون رو راست باشم. اگر برنامه نویسی کار کرده باشین، مخصوصا یک مقدار جزئی. شما بسیار خطرناک هستین! این مدل افراد معمولا علاوه بر دخالت در مدیریت پروژه، راه حل های فنی هم میدن! که خب در درجه اول آزار دهنده است و در درجه دوم به احتمال خیلی زیاد اشتباهه. و اگر افراد تیم قدرت نه گفتن رو نداشته باشن حتی اگر هم راه حل فنی و پیشنهادی رو اعمال نکنن باعث دخالت بیش از حد شما در پروژه خواهند شد. این در حالی است که در صورت عدم تخصص مدیریت فنی تنها باید نیاز خودتون رو به تیم ارجاع بدین نه چیز دیگه ای.

2) آسمون باز شده فلان برنامه نویس افتاده توی دامن شما!

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

بیشتر مشکل عدم مشورت در مورد مسائل فنی و اتکا و اعتماد به یک نفر بود. به نظر من برنامه نویس در حد سطح و اندازه ای باید در مورد کارهایی که انجام میده توضیح داشته باشه. 

مدیر باید از روند توسعه پروژه، صحت کارها و... مطلع باشه و چقدر خوبه این بین یک ذهن سوم به عنوان مشاور کنار دستتون توضیح بده در فرآیند تولید نرم افزار چه اتفاقی داره میوفته. از واژه ذهن سوم استفاده کردم به دو دلیل. اول اینکه توسعه دهنده ی اصلی روی کارش تمرکز حداکثری داشته باشه و کمتر کار حاشیه ای مثل توضیح دادن اینکه چرا مدت زیادی برای تحلیل فلان ماژول گذاشته شده بده. و دوم، به شدت معتقدم کسی که املا مینویسه 1000 بار هم از روی املاش بخونه نمیتونه غلط هاشُ پیدا کنه! پس مشاور فنی هم برای شما و هم برای تیم میتونه مفید باشه و درصد خطا رو کاهش بده.

اضافه کنم قرار نیست مشاور وقت زیادی با شما باشه. شاید روزانه یک ساعت کفایت کنه. از افراد با تجربه میتونید چنین تقاضایی رو داشته باشین.

نگرانی آخر من در این باره موضوع وحشتناکی به نام سلیقه است. اعمال سلیقه در پروژه وابستگی میاره. جای اون به تیم یادآوری کنید از استاندارد ها پیروی کنن. به عنوان مثال سبک کدنویسی رو در نظر بگیرید، هیچ قانون سخت گیرانه ای در مورد پیروی من از سبک کدنویسی فریمورکی که ازش استفاده میکنم وجود نداره اما اگر چنین کاریُ انجام بدم، اعضای جدید میتونن با مطالعه مستندات فریمورک به راحتی سورس های قدیمی رو توسعه بدن. در مقابل فرض کنید یک سبک و سیاق سلیقه ای عمدتا مستند نشده چه فاجعه ای میتونه به بار بیاره.

3) از دست دادن زمان و بودجه.

یادتون باشه تا ابد وقت ندارین، به جرات میگم زمان در تمام پروژه ها بسیار مهمه. هر چقدر بیشتر کارتون طول بکشه احتمال شکست طرح شما هم بیشتر خواهد شد. زمان زیاد یعنی هزینه ی زیاد. بالاخره شما در این مدت برای دفتر، لوازم و تیم هزینه کردین. هر روز چنین کاریُ انجام میدین. ممکن هست به دلایل زیادی کار شما طول بکشه. در بهترین حالت تصور میکنیم شما با یک گروه متخصص مشغول انجام کارتون هستین بدون حتی 1 درصد خطا! اما پروژه ی بزرگی دارین و چند سال طول میکشه تا به نتیجه برسین. بعد از چند سال بازار ثبات خودش رو حفظ کرده؟‌ جای شما هنوز هم خالیه یا رقبا زحمت پر کردنش رو کشیدن؟ اصلا کسی چه میدونه توی بازار چه خبره! ممکنه پروژتون جواب نده! پیشنهاد من این هست که سریع تر وارد بازار بشین. یک محصول حداقلی برای سنجش بازار و دریافت بازخورد برای شما کفایت میکنه. لازم نیست تمام فیچر ها رو به همراه داشته باشه. پروژه رو به مرور تکمیل کنید. به نظر من ورود سریع به بازار از تلف شدن وقت و هزینه به شدت جلوگیری میکنه. مخصوصا برای پروژه هایی که آینده روشنی ندارن.

4) مقاومت در برابر تغییر.

دکتر اسپنسر جانسون، نویسنده کتاب چه کسی پنیر من را برداشت، فرق بین آدم‌ها و موش‌ها را این طور توصیف می‌کنه:

وقتی یک موش حس می‌کند تلاش‌هایش به نتیجه نمی‌رسد، روش خود را عوض می‌کند، اما وقتی آدم‌ها حس می‌کنند کاری که انجام می‌دهند به نتیجه نمی‌رسد، عصبانی و خسته می‌شوند و دوست ندارند روش خود را عوض کنند. حتی گاهی اگر کسی راهکار تازه‌ای را به آنها نشان دهد، حالت دفاعی به خود می‌گیرند و می‌گویند: «من همیشه این کار را همین طور انجام داده‌ام. «یا» من آدمی این مدلی هستم.» در اصل این آدم‌ها از پذیرفتن راهکار تازه و انجام آن می‌ترسند و حس می‌کنند ترسشان به این معناست که دیگر روش‌ها اشتباه است. 

مقاومت در برابر تغییر در ذات انسان هاست. یکی از خصوصیات مدیر خوب مقاومت در برابر مقاومت در برابر تغییر هست! آغوش تغییر و شروع تجربه های جدید میتونه تاثیر زیادی در کار شما داشته باشه.

5) عدم درک و تصور صحیح از بازار.

قانون عدم قطعیت در پروژه های نرم افزاری میگه اون چیزی که واقعا نیاز دارین با اون چیزی که توی ذهن یا کاغذتون هست کاملا متفاوت خواهد بود! عدم درک و تصور صحیح از بازار و شناخت و گفتگو با کاربر نهایی یا مشتری تضمینی برای شکست پروژه ی شماست. شما میبایست تصویری شفاف از نیاز مشتری داشته باشین. اینکه مشتری چه نیازی داره و البته در حال حاضر چطور اون رو برطرف میکنه مهمه. نکته ی قابل تامل در این بخش اینه که باید هنگام گفتگو با مشتری مراقب باشین گاهی اوقات اون نمیتونه نیازش رو به شما منتقل کنه یا از طرح پیشنهادی شما فقط به خاطر اینکه ناراحتتون نکنه استقبال خواهد کرد. در این صورت شما بیش از اندازه به کارتون امیدوار خواهید شد و از نتیجه یک انتظار بسیار غیر واقعی خواهید داشت.

6) نداشتن یک مدیر پروژه ی خوب.

مهم نیست تیم شما چقدر مهارت داره. نبود مدیر پروژه ی خوب باعث آشفتگی در تیم میشه. نبود مدیریت قوی برای هدایت تیم منجر به یک محصول متوسط میشه همراه با تاخیر زیاد در تحویل پروژه. 

7) عدم سرمایه گذاری برای پیشرفت تخصص تیم و نیرو های جدید.

ندونستن نقاط قوت و ضعف اعضا میتونه شما رو هنگام اختصاص دادن وظایف به اونها دچار مشکل کنه. سرمایه گذاری برای پیشرفت و توانمندی اعضا با اجازه دادن به اونها برای فعالیت در قسمت هایی که نقطه ی قوتشون هست میتونه شما رو به سمت موفقیت در پروژه ببره.

از طرفی اوضاع جالبی نیست! خیلی از بچه ها مهاجرت کردن و شرکت ها به سختی دنبال پر کردن جای خالی اونا هستنن. اگر به دنبال جذب نیرو رفته باشین حتما به این نتیجه رسیدین که بسیار کار سختی هست. کم کم داریم و باید به سمت پرورش نیرو حرکت کنیم.

در ادامه تصمیم ندارم این موضوع رو باز کنم و فقط کوتاه مینویسم، مهمتر از پرورش نیرو حفظ اون هست. سرمایه یک مدیر تنها سود از پروژه یا به طور کلی آورده های مالی نیست، متخصصین و افرادی هستن که با اونها کار میکنه. یعنی شما هنگام از دست دادن یک نیروی خوب ضرر و زیان بسیاری متحمل خواهید شد.

تمام.

پیشنهاد

ارسال نظر