ارتباط هزینه ساخت نرم‌افزار با متدولوژی

داشتم مطلبی در وبلاگ رادمان که جناب آقای واحد نوشته بودند می‌خواندم و در ادامه به یادداشتهای خوانندگان رسیدم. یکی از یادداشتها توجه مرا به خود جلب کرد:
«به نظر من قیمت گذاری نرم افزار بسیار وابسته به متودولوژی مورد استفاده ما برای توسعه نرم افزار هستش ، طوری که بعضی از متودولوژی ها تلاش کاذبی رو برای توسعه یک نرم افزار به تیم توسعه تحمیل میکنند مثلا مستندات بسیار زیاد Rup و … و این زحمت اضافه بر روی قیمت گذاری از دید مدیر پروژه تاثیر خواهد داشت و افزایش قیمت در این حالت یک افزایش قیمت درست نخواهد بود ، از طرفی مشتری در اغلب مواقع تضاد آشکاری بین خروجی ارائه شده و قیمت پیشنهادی میبینه ، به نظر من تنها راه حل تخمین مناسب قیمت یک نرم افزار وارد کردن مشتری و یا فردی قابل اعتماد و مورد تایید سازمان و یا فرد درخواست دهنده به داخل تیم توسعه است که چنین راه حلی در روشهای Agile و متدهایی بسیار عالی همچون Scrum پیش بینی شده، در این روش ها از اونجایی که مشتری خودش داره روند پیشرفت پروژه رو میبینه و دائم در حال بحث و گفتگو و نظر دادنه دیگه نمیخواد برای قیمت گذاری چونه بزنیم و یا توجیهات دروغین ارائه بدیم ، دیگه نیازی نیست که مشتری بیچاره پول زحمت های کاذب ما رو بده که به هیچ قیمتی هم حاضر به ترک این زحمات نیستیم! ، در این روشها اساسا توسعه بر مبنای نیازهای مشتری نه بیشتر و نه کمتر انجام میشه و هیچ کار بدون کیفیت و اضافه ای در چرخه تولید نرم افزار انجام نمیگیره و این میشه کیفیت واقعی و هزینه ای که برای کیفیت واقعی محاسبه میشه ، یک هزینه واقعی نرم افزار هستش .»

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

نکته اول: بسیاری از متدها به خصوص آنهایی که نام «چارچوب» را یدک می‌کشند مانند آریوپی و اسکرام، چیزی را دیکته نمی‌کنند بلکه با حفظ اصول، اجازه انتخاب می‌دهند. به عنوان مثال آر یو پی هیچ مستندی به شما دیکته نمی‌کند، آن چه به شما دیکته می‌کند، نگرشی است که از آن به عنوان روح حاکم بر آر یو پی یاد می‌شود که در همه متدهای نوین به شکلی وجود دارد(اصول حاکم بر فرایندهای نوین ایجاد نرم‌افزار). 

نکته دوم: متدولوژی ابزار است و در انتخاب ابزار، تحلیل هزینه-منفعت نخستین گام  است. اگر متدولوژی‌ای برای پروژه انتخاب شده که با هزینه و زمان آن سازگاری ندارد، اشکال از انتخاب کننده است و نه متدولوژی. در انتخاب متدولوژی رویه «هر چه قدر پول بدی (در اینجا پول داری) همان قدر آش می‌خوري» اجر می‌شود و نه برعكس.به عنوان مثال انتخاب اکس‌پی در مقابل اسکرام به مراتب هزینه بیشتری به همراه دارد. اولی در حوزه تکنیکی ایجاد نرم‌افزار و دومی در حوزه مدیریت آن است. به همین دلیل است که حداقل در ایران تیم‌های بیشتری ادعای کار با اسکرام را دارند تا اکس‌پی.

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

نکته چهارم: موضوع حائز اهمیت این است که کاری را که قبلاْ انجام نداده‌اید، نمی‌توانید برآورد کنید. فرقی نمی‌کند کدام طرف میز باشید. چه بسیار جلسات مشترک کارفرما، مجری و ناظر(که اتفاقاْ همه مشخصات اشاره شده دوست عزیزمان را دارد) بر سر اندازه‌گیری حجم و زمان انجام یک کار به چالش کشیده شده است.  اگر فرض را بر این بگذارید که در مناقصه‌های ایجاد نرم‌افزار، کارفرما به دنبال پیدا کردن پیمانکاری است که این کار را قبلاً انجام داده باشد، این پرسش مطرح می‌شود که آیا به لحاظ قلمرو مسأله، مشخصات تکنولوژیُ، افراد درگير و  پارامترهای دیگر، همه پروژه‌های به مناقصه گذاشته شده، مشابه قبلی داشته‌اند؟ چند وقت پیش با تیمی کار می‌کردم و از آنها خواستم که برآورد خود را از کار (به لحاظ فلمرو مسأله، بسیار ساده) ارائه دهند، بندگان خدا گفتند نمی‌توانیم، وقتی دلیلش را پرسیدم گفتند که به تکنولوژی ساخت محصول آشنایی ندارند، حق با آنها بود يا تيم بايد عوض مي‌شد يا گفته‌شان پذيرفته.

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

 نکته ششم: دوستی دارم که در صنعت ساختمان‌سازی کار می‌کند. همیشه حسرت می‌خوردم که چرا آنها می‌توانند به راحتی برآورد هزینه کنند و ما نمی‌توانیم. چند وقت پیش با هم صحبت می‌کردیم به نکته جالبی اشاره کرد. گفت چون قیمت مصالح روزانه مشخص و تعیین می‌گردد، دیگر نمی‌توانم برآورد درستی داشته باشم. وقتی شرایط نامطمئن و غیرقابل پیش‌بینی شود، برآوردها نیز با واقعیتها فاصله خواهند گرفت. دوستي ديگري در همان صنعت كه مجتمع‌سازي مي‌كردند مي‌گفت كه به دليل پرخطر بودن برآوردها، از چند وقت پيش با روش قيمت تمام شده به علاوه درصد سود كار مي‌كنيم و نه مناقصه‌‌اي مبتنی بر برآورد.

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

نکته آخر: شاید کمی مضحک به نظر آید اما در دیدگاهم متدولوژی‌ها، تکنولوژی‌ها و ابزارها مانند فرزندانی هستند که هر چند خلقیات متفاوت و گاه متضاد دارند، اما همگی آنها دوست داشتنی‌اند. 

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

گزیده:
ندارد.