انجمن برنامه نویسان البرز

تبلیغات

نکته ای در باب شکست فنی یک پروژه


به یاد دارم سال هایی که بچه بودیم، یکی از کارتون های مورد علاقه ما پت و مت بود. آنها همیشه یک کار را انجام میدادند و تهش وقتی با هم دست میدادند، یکهو همه چیز خراب میشد. در باب شکست فنی یک پروژه هم این مشکل پت و متی وجود دارد!

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

شکست فنی یک پروژه به چه معنی است؟

بیشتر ما این تصور را داریم که شکست فنی یک پروژه نرم افزاری به این معنی است که ما به جایی برسیم که نتوانیم پروژه را تمام کنیم. این تعریف غلط نیست. اما معمولا بیشتر شکست های نرم افزاری، در این مرحله رخ نمیدهند.

در یک تعریف کلی و بسیار ساده، هر وقت که نرم افزاری در چرخه حیاتش به بن بست برسد، شکست خورده است. این بن بست میتواند تعاریف بسیاری داشته باشد: عدم موفقیت در فروش. هزینه های نگهداری بیشتر از سود. مشکلات فنی غیر قابل حل در زمان بهره برداری و …

شکست فنی یک پروژه در چه مرحله ای رخ میدهد؟

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

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

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

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

چرا ایرادات نرم افزارها در مرحله تحویل به مشتری نمایان میشوند؟

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

رویه های منسوخ گذشته را دور بریزید

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

نکته مهم تر این که در بیشتر شرکت ها، حتی روش های آبشاری هم پیاده سازی نمیشوند و کلا همه چیز به سلیقه برنامه نویس بستگی دارد.

کم اهمیت شمردن مسئولیت ها

تا امروز که این مقاله را مینویسم، ر هیچ سازمان و ارگانی کار نکرده ام که به مسئولیت کارشناسان کنترل پروژه اهمیتی بدهد! هر وقت که بحث تست محصول تولید شده به میان آمده است، با دیالوگ هایی از این قبیل روبرو شده ام: “برای تست، کارآموز هم کافیه”  – “قصد نداریم برای تست، هزینه ای بدیم”- “بچه های فروش تستش میکنن دیگه” – “بچه های پشتیبانی وظیفه تست هم دارند” – “خود برنامه نویس باید کدشو تست کنه”

برای درک بهتر این موضوع، در گوگل سرچ کنید Software Testing Company و ترجمه فارسی این عبارت را هم سرچ کنید. قضاوت با شما.

مسئولیت هایی که در دنیای نرم افزار هستند و کم اهمیت شمرده میشوند، محدود به تست نیستند. در یک پروژه نرم افزار، کارشناسان بسیاری درگیر هستند که معمولا برای کاهش هزینه ها، آنها را فاکتور میگیریم یا از میان مبتدیان انتخابشان میکنیم. غافل از اینکه وقتی هزینه نگهداری نرم افزار تا ۹۰% هزینه تولید بالا میرود، پولی که از جیب ما میرود، از مجموع حقوق چندین ماه این افراد هم بیشتر است. مسئولیت هایی نظیر UI designer و کارشناس UX و …

متکی بودن سازمان به افراد

یکی از معایبی که استفاده از رویه های منسوخ، حذف مسئولیت ها و استفاده از میتدیان به وجود میآورد، اتکای بیش از حد یک سازمان به اشخاص است. یک مثال ساده: استیو جابز فوت کرد و اپل هنوز به کارش ادامه میدهد. اگر اپل در ایران بود، قطعا ورشکسته میشد. در طول تجارب کاری ام،بسیار زیاد دیده ام که وقتی افراد، سازمانی را ترک میکنند -خصوصا برنامه نویسان- سازمان زمین میخورد. اتکای بیش از حد به افراد، ما حصل عدم استفاده از برنامه ریزی های درست است. یک مثال خیلی خیلی ساده: وقتی کدی بر اساس اصول SOLID نوشته نشده باشد، طبیعی است که با استعفای برنامه نویسی که کدرا نوشته، برنامه نویس بعدی پیر میشود تا از کار سر در بیاورد.

ایزوله بودن تیم تولید از مشتری

عنوان این بخش گویای همه چیز است. ما نرم افزار را تولید میکنیم و وقتی تمام شد، به سراغ مشتری میرویم. اما در متدولوژی های Agile داستان، روش دیگری دارد. در طول تولید دائما با مشتری در تعامل هستیم.

تست در حین تولید

آنقدر از خواص تست ها و خصوصا Unit Testing گفته ام که دیگر توضیحش را ضروری نمیبینم.

نبود مسئولیت های کلیدی

در چرخه تولید نرم افزار، تعدادی مسئولیت های کلیدی وجود دارد که هیچ یک از آنها را نداریم. Tester و تحلیل گر و کارشناس UI و UX و Product Owner و Scrum Master تنها تعدادی از این افراد هستند. طبیعی است وقتی تمام مسئولیت ها به گردن برنامه نویس باشد، نتیجه به دست آمده، مطلوب نخواهد بود.

تخمین غلط نیازمندی ها و زمانبندی

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

نبود قانون کپی رایت

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

نبود مستندات

این مشکل را همه میشناسیم اما وقتی پای حل کردنش به میان می آید، فقط مثل طوطی یک کلمه را تکرار میکنیم: “UML”

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

تفکیک مسئولیت ها

این موضوع درد مشترک خیلی از سازمانهاست. مدیران با افتخار سینه سپر میکنند و میگویند: “مابه افرادی نیاز داریم که خوشان از پس خودشان بر بیایند. سازمان را به دست بگیرند و مثل آچار فرانسه باشند”.

این حرف در ظاهر قشنگ هست اما ترجمه فارسی ترش این است: “از آنجایی که ما میخواهیم پول کمی خرج کنیم، ترجیح میدهیم کسانی را استخدام کنیم که اطلاعاتشان به اندازه یک اقیانوس باشد. حتی اگر عمق این اقیانوس ۲۰ سانتی متر باشد!”

تفکیک مسئولیت ها، کیفیت انجام هر قسمت از کاررا به طرز چشمگیری افزایش خواهد داد.

تکیه بر شنیده های بی ارزش و مدگرایی

حداقل ۱۰ تا مصاحبه کاری داشته ام که شرکتی آگهی استخدام مدیر پروژه Agile/Scrum داده. در حین مصاحبه دیده ام که شرکت، مسئول تست ندارد. اسکرام مستر ندارد. گرافیست ندارد. طراح UI ندارد و و و. سوالی که همیشه برای من پیش می آید این است که پس این شرکت از اسکرام چه میداند؟ و اگر چیزی نمیداند، چطور به این نتیجه رسیده است که باید بر طبق اصول اسکرام کار کند. و حتی اگر قصد تغییر دارد و میخواهد اسکرام محور باشد، چرا اصرار به استفاده از رویه های پیشین دارد و هیچ چیزی را تغییر نمیدهد. تمام این سوالات یک جواب بیشتر ندارند: بیشتر ما با تکیه بر شنیده ها و بدون اطلاعات و بر اساس مد گرایی، دستبه کار میشویم.

نرم افزار، حاصل یک هنر دست جمعی است

سازمانی را در نظر بگیرید که به صورت تیمی کار میکند. این سازمان ۱۰ محصول نرم افزاری دارد. یک تیم ۱۰ نفره از برنامه نویسان هم دارد که هریک مسئولیت یک محصول را بر عهده دارند. سوال اینجاست: “آیا این مفهوم کار تیمی است؟” از نظر من این سازمان به جای داشتن یک تیم ۱۰ نفره، در واقع ۱۰ تیم یک نفره دارد.

مفهوم Agile چیزی غیر از این است. یکی از اصلی ترین اصولی که در Agile وجود دارد، کار تیمی به مفهوم واقعی آن است. این مفهوم تا آنجا پیش میرود که در یک تیم اسکرام، ما مسئولیتی را مشخصا به یک برنامه نویس خاص، منتصب نمیکنیم. بلکه هر یک از اعضای تیم، از لیست کارهایی که باید انجام شود، یکی را بر میدارد و انجام میدهد. رویایی است نه؟

محصولی که حاصل یک تفکر دست جمعی باشد، بسیار بسیار قوی تر است.

 

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

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

 




کلمات کلیدی :

نظر بدهید

2 دیدگاه برای “نکته ای در باب شکست فنی یک پروژه

  • سید مصطفی شاه امیری گفته
    ۱۱ مهر ۹۶

    بسیار مقاله زیبا بود، با بیان ساده و دلنشین

    • علیرضا صبوئی گفته
      ۱۱ مهر ۹۶

      مصطفی عزیزم. ممنونم از تعریفتون