داشتم مطلبی در وبلاگ رادمان که جناب آقای واحد نوشته بودند میخواندم و در ادامه به یادداشتهای خوانندگان رسیدم. یکی از یادداشتها توجه مرا به خود جلب کرد:
«به نظر من قیمت گذاری نرم افزار بسیار وابسته به متودولوژی مورد استفاده ما برای توسعه نرم افزار هستش ، طوری که بعضی از متودولوژی ها تلاش کاذبی رو برای توسعه یک نرم افزار به تیم توسعه تحمیل میکنند مثلا مستندات بسیار زیاد Rup و … و این زحمت اضافه بر روی قیمت گذاری از دید مدیر پروژه تاثیر خواهد داشت و افزایش قیمت در این حالت یک افزایش قیمت درست نخواهد بود ، از طرفی مشتری در اغلب مواقع تضاد آشکاری بین خروجی ارائه شده و قیمت پیشنهادی میبینه ، به نظر من تنها راه حل تخمین مناسب قیمت یک نرم افزار وارد کردن مشتری و یا فردی قابل اعتماد و مورد تایید سازمان و یا فرد درخواست دهنده به داخل تیم توسعه است که چنین راه حلی در روشهای Agile و متدهایی بسیار عالی همچون Scrum پیش بینی شده، در این روش ها از اونجایی که مشتری خودش داره روند پیشرفت پروژه رو میبینه و دائم در حال بحث و گفتگو و نظر دادنه دیگه نمیخواد برای قیمت گذاری چونه بزنیم و یا توجیهات دروغین ارائه بدیم ، دیگه نیازی نیست که مشتری بیچاره پول زحمت های کاذب ما رو بده که به هیچ قیمتی هم حاضر به ترک این زحمات نیستیم! ، در این روشها اساسا توسعه بر مبنای نیازهای مشتری نه بیشتر و نه کمتر انجام میشه و هیچ کار بدون کیفیت و اضافه ای در چرخه تولید نرم افزار انجام نمیگیره و این میشه کیفیت واقعی و هزینه ای که برای کیفیت واقعی محاسبه میشه ، یک هزینه واقعی نرم افزار هستش .»
مطمئن هستم که دوست عزیزمان (آقای سید ایوب) تجاربی دارند که بر اساس آن گفته ایشان درست خواهد بود. تجاربی که ممکن است ناشی از اجرا و بهکارگیری نادرست متدلوژی یا نشانگر اشکالات متدولوژیها باشد. دلم میخواست شرایطی بود تا نکاتی را درباره موارد اشاره شده دوست عزیزمان در این جا بیاورم، این کار نیاز به مقدمات بسیار طولانی دارد که از حوصله وبلاگ خارج است. اما ترجیح دادم چند نکته کلی را در مورد فرمایشات ایشان عرض کنم.
نکته اول: بسیاری از متدها به خصوص آنهایی که نام «چارچوب» را یدک میکشند مانند آریوپی و اسکرام، چیزی را دیکته نمیکنند بلکه با حفظ اصول، اجازه انتخاب میدهند. به عنوان مثال آر یو پی هیچ مستندی به شما دیکته نمیکند، آن چه به شما دیکته میکند، نگرشی است که از آن به عنوان روح حاکم بر آر یو پی یاد میشود که در همه متدهای نوین به شکلی وجود دارد(اصول حاکم بر فرایندهای نوین ایجاد نرمافزار).
نکته دوم: متدولوژی ابزار است و در انتخاب ابزار، تحلیل هزینه-منفعت نخستین گام است. اگر متدولوژیای برای پروژه انتخاب شده که با هزینه و زمان آن سازگاری ندارد، اشکال از انتخاب کننده است و نه متدولوژی. در انتخاب متدولوژی رویه «هر چه قدر پول بدی (در اینجا پول داری) همان قدر آش میخوری» اجر میشود و نه برعکس.به عنوان مثال انتخاب اکسپی در مقابل اسکرام به مراتب هزینه بیشتری به همراه دارد. اولی در حوزه تکنیکی ایجاد نرمافزار و دومی در حوزه مدیریت آن است. به همین دلیل است که حداقل در ایران تیمهای بیشتری ادعای کار با اسکرام را دارند تا اکسپی.
نکته سوم: در متدهای چابک اعتقاد بر این است «برآورد مبنایی برای تعهد نیست». این متدها مانند سایر متدهای تکرارپذیر، اعتقاد دارند که به دلیل ماهیت «عدم قطعیت» شرایط پروژهها، برآورد رفتار احتمالی دارد و در حین اجرا تصحیح میشود و تیم باید فرصت ارزیابی آن را داشه باشد و به همین علت است که نمیتواند مبنا قرار گیرد. در حالی که این موضوع با رویکرد مدیریت در ایران در تضاد است. مدیریت سازمان(اگر تیم مجری داخل شرکت باشد) یا کارفرما به دنبال تعهدات و الزاماتی است تا هزینه و زمان برآوردی رعایت شود. از این دیدگاه وارد شدن مشتری یا نماینده وی کمکی به خواستههای مدیریت نخواهد کرد و ناچاریم قبل از ورود مشتری یا نماینده وی «برای قیمت گذاری چونه بزنیم».
حال به یک نکته ظریف توجه کنید. همین دیدگاه در متدی مانند آریوپی نیز وجود دارد، چون روشی است تکرارپذیر (موضوع رفتار احتمالی برآوردُ در روشهای تکرارپذیر پوشش داه میشود). دو فاز اول دیدگاه مهندسی و عدم قطعیت دارد و دو فاز آخر دیدگاه تولیدی و قطعیت بیشتر.
نکته چهارم: موضوع حائز اهمیت این است که کاری را که قبلاْ انجام ندادهاید، نمیتوانید برآورد کنید. فرقی نمیکند کدام طرف میز باشید. چه بسیار جلسات مشترک کارفرما، مجری و ناظر(که اتفاقاْ همه مشخصات اشاره شده دوست عزیزمان را دارد) بر سر اندازهگیری حجم و زمان انجام یک کار به چالش کشیده شده است. اگر فرض را بر این بگذارید که در مناقصههای ایجاد نرمافزار، کارفرما به دنبال پیدا کردن پیمانکاری است که این کار را قبلاً انجام داده باشد، این پرسش مطرح میشود که آیا به لحاظ قلمرو مسأله، مشخصات تکنولوژیُ، افراد درگیر و پارامترهای دیگر، همه پروژههای به مناقصه گذاشته شده، مشابه قبلی داشتهاند؟ چند وقت پیش با تیمی کار میکردم و از آنها خواستم که برآورد خود را از کار (به لحاظ فلمرو مسأله، بسیار ساده) ارائه دهند، بندگان خدا گفتند نمیتوانیم، وقتی دلیلش را پرسیدم گفتند که به تکنولوژی ساخت محصول آشنایی ندارند، حق با آنها بود یا تیم باید عوض میشد یا گفتهشان پذیرفته.
نکته پنجم: وقتی تجربه کاری را نداشته باشید، حتی نمیتوانید برآوردها را ارزیابی و قبول کنید. بسیاری از کارهایی که برای افزایش کیفیت درونی نرمافزار انجام میدهیم برای مشتری و کاربر قابل لمس نیست. چه بسیار جملاتی شبیه به این جمله که «ما فقط گفتیم یک فیلد به فرم اضافه کنید و شما گفتید نیاز به اکس ماه زمان و ایگرگ تومان هزینه دارد» از کارفرمای آگاه به تولید نرمافزار شنیده شده است یا حتی از مدیران شرکتهای نرمافزاری شنیده شده است که « مگر چند تا فرم چقدر کار دارد که شما سه ماه است میگویید داریم معماری نرمافزار را انجام میدهیم». مدیر شرکت تولید نرمافزاری درد دل میکرد که سالها پیش یک فرم را روی کاغذ میکشیدیم و دو ساعت بعد، برنامهنویس فرم را انجام شده، تحویل میداد. الان همان فرم را میکشیم و یک ماه طول میکشد تا خروجی به ما نشان دهند.
نکته ششم: دوستی دارم که در صنعت ساختمانسازی کار میکند. همیشه حسرت میخوردم که چرا آنها میتوانند به راحتی برآورد هزینه کنند و ما نمیتوانیم. چند وقت پیش با هم صحبت میکردیم به نکته جالبی اشاره کرد. گفت چون قیمت مصالح روزانه مشخص و تعیین میگردد، دیگر نمیتوانم برآورد درستی داشته باشم. وقتی شرایط نامطمئن و غیرقابل پیشبینی شود، برآوردها نیز با واقعیتها فاصله خواهند گرفت. دوستی دیگری در همان صنعت که مجتمعسازی میکردند میگفت که به دلیل پرخطر بودن برآوردها، از چند وقت پیش با روش قیمت تمام شده به علاوه درصد سود کار میکنیم و نه مناقصهای مبتنی بر برآورد.
نکته هفتم: در دورههای آموزشی بازیای را شروع میکنم به نام «قرارداد مناقصه سیستم کتابخانه» یا «تولید پکیج کتابخانه». با ارائه توضیحات کلی و مبهم از همه میخواهم که برآورد زمان و هزینه ارائه کنند. به آنهایی که محافظه کار میشوند و با این استدلال که خواستهها دقیق نیست، پیشنهادی ارائه نمیکنند، به شوخی میگویم که باید کاسبی و شرکت خود را تعطیل کنید، چون اکثر پروژهها در کشور بدین شکل انجام میشود یا مجبورید که در ابتدای کار برآوردی از سرمایهگذاری برای پکیج داشته باشید.
آنهایی که قیمت و زمان پیشنهاد میکنند در دام میافتند، چرا که بعد از آن، تفاسیری از خواستهها ارائه میکنم که منجر به تغییر ماهیت پروژه میشود و آنها این بار نیز باید کاسبی خود را تعطیل کنند، چرا که زمان و قیمتی که پیشنهاد کرده بودند، برای انجام پروژه کافی نیست. این شبیه به اتفاقاتی است که در زندگی روزمره ما رخ میدهد.
نکته آخر: شاید کمی مضحک به نظر آید اما در دیدگاهم متدولوژیها، تکنولوژیها و ابزارها مانند فرزندانی هستند که هر چند خلقیات متفاوت و گاه متضاد دارند، اما همگی آنها دوست داشتنیاند.
از آقای سید ایوب هم عذرخواهی میکنم. همان طور که در ابتدا عرض کردم، مطمئن هستم که تجارب ایشان کاملاً درست و قابل استناد است. هدفم از این یادداشت این بود که شاید تجارب ایشان در همه شرایط قابل تعمیم نباشد. برای ایشان و آقای مهندس واحد بهترینها را آرزومندم.
گزیده:
ندارد.
علی واحد
۱۹ آذر ۱۳۹۰ در ۰۰:۰۰نوشته بسیار عالی بود. به جز نکات آموزنده موجود در کل بحث با آن جمله شما هم که در زمان شروع پروژه باید متدولوژی را درست انتخاب کرد بسیار موافقم. یکی از اشکالات ما آن است که می خواهیم همه قفل ها را با یک کلید باز کنیم و بعد چنانچه با مشکلی مواجه شدیم کلید را مقصر می دانیم نه انتخاب خودمان را…بگذریم.
واقعیتش آن است که دوست دارم نظر کاملتری از شما در زمینه قیمت گذاری نرم افزار و پرسشهای مطرح در ان داشته باشم، اگر فرصت کردید و در این زمینه نوشتید هم من و هم سایر خوانندگان وبلاگتان را مدیون خود نموده اید.
باز هم ممون!
—————————–
جناب آقای مهندس واحد
سلام،
در مورد قیمتگذاری پروژهها و محصولات نرمافزاری دانش و تجربه زیادی ندارم.
اگر فرصتی دست داد، حتماً اندک دانش و تجربهام را خواهم نوشت.
به امید دیدار
مهرداد
مجید
۱۹ آذر ۱۳۹۰ در ۰۰:۰۰مطالب و نکته های خوبی گفتید، برای من و شرکت خودم اموزنده بود
از بین این همه متدولوژی،یکی را انتخاب کردن بسیار مشکل هستش و فقط با تجربه و اطلاعات میشه یه روش خوب و بهینه رو انتخاب کرد
با عرض معذرت
من مشکلی داشتم در تحلیل و در قسمت طراحی کلاس ها،ایمیل زدم ولی جوابی نگرفتم
————————
سلام
بابت دیرکرد پاسخ پوزش میطلبم. قرار گذاشته بودم که آخر هفته پاسخ نامه شما را تهیه و ارسال کنم. مؤفق نشدم.
پاسخ آن را به زودی ارسال خواهم کرد.
سپاسگزارم.
مهرداد
سید ایوب
۲۰ آذر ۱۳۹۰ در ۰۰:۰۰سلام ،
با اینکه هنوز هم در مورد جزئیات برخی نکات ارائه شده حرفهایی برای گفتن دارم ولی چون مطالب مفیدی رو اشاره کردید ، فقط میتونم بگم بسیار ممنونم .
با تشکر /.
———————–
جناب آقای سید ایوب
سلام،
از لطف شما بسیار سپاسگزارم.
به امید دیدار
مهرداد
امیر نام آور
۲۰ آذر ۱۳۹۰ در ۰۰:۰۰از مطلب بسیار مفیدتون سپاسگزارم و از اینکه تجربیات ارزشمندتون رو با دیگران به اشتراک میگذارید …
——————————-
جناب آقای نام آور
سلام،
از ابراز لطف و محبت شما سپاسگزارم.
به امید دیدار
مهرداد
پویا
۲۱ آذر ۱۳۹۰ در ۰۰:۰۰استاد عزیز عالی بود،
به گمانم ما باید بین قیمت ارائه شده به مشتری برای یک سیستم و قیمت تمام شده (تنها در حیطه خود نرم افزار نه استقرارو …)آن تفاوت قایل شویم، گاه رعایت نکردن همان بایدهاو راهنمایی های متدولوژی ها و حتی پیش تر از آن اصول مهندسی نرم افزار در دراز مدت مشتری را دچار خسارت بیشتری می کند. الزاما متدولوژی ای مانند آر یو پی منجر به تولید نرم افزار گران تری از متدولوژی های چابک نمی شود
——————–
پویاجان سلام
ممنون از لطف شما.
مهرداد
مهدی فهمیده
۱۱ دی ۱۳۹۰ در ۰۰:۰۰سلام آقای مهندس مهرداد
خیلی مطالب خوبی ارائه کرده اید. در یک مورد جای شبهه برای من وجود دارد که بهتر است بررسی شود. چرا که در موضوع متدولوژی های توسعه نرم افزار به اندازه کافی صحبت های غیر فرمال هست و نباید بیشتر از آن به این کاستی دامن زد.
از نقطه نظر متدولوژی، شما در بند یک فرمودید که آر یو پی که هیچ مستندی را به شما دیکته نمیکند. در حالی که این صحیح نیست و اتفاقا این متدولوژی تولید مستندات زیاد به نوعی اجبار است. به بیان بهتر، چنانچه شما به قالب اسناد تولید شده در این متدولوژی نگاهی بیاندازید مشاهده میکنید که زنجیره ای از مدلسازی عملا وجود دارد و به صورت قید مطرح است. مگر آنکه مهندس فرایند یا متد، به دلایل موجهی بر حسب شرایط پروژه آن تولید آنرا تجویز نکند. به عنوان مثال شما در سند معماری نرم افزار به موارد کاربرد ارجاع میدهد. لذا نوعی اجبار و زنجیره مدلسازی مشهود است. لذا متدولوژی های آر یو پی، اپن از گونه متدهای سنگین هستند.
این سطح از اجبار، در خانواده متدولوژی های چابک دیده نمیشود و محدود به اصول کلی میشوند.
ضمنا، با توجه به موارد ذکر شده، چه راه حل عملی میتواند برای تخمین پروژه وجود داشته باشد؟
مهرداد
۱۲ دی ۱۳۹۰ در ۰۰:۰۰دوست عزیز، جناب آقای مهندس فهمیده
سلام، وقت به خیر؛
از لطف شما سپاسگزارم. از خواندن یادداشت شما خوشحال شدم و نظراتم را در زیر آوردهام، امیدوارم راهگشا باشد.
نکته اول:
با نظر شما در مورد چارچوبهای فرایندی مانند آریوپی موافق نیستم. ارجاع میدهم به فصل چهارم کتاب زیر از کرول و کراچن که در آن پروژهای ۵ روزه(یک هفتهای) و یک نفره با این متد انجام شده و در آن خبری از تشریفاتی که فرمودید، نیست.
Rational Unified Process Made Easy
نکته دوم:
هر چند با این نظر شما در این مورد که نحوه ارائه آریوپی تفکر تسلسل در محصولات کاری را القاء میکند(مفهوم بیدرزی در مهندسی متد)، اما آن چه نگران کننده است و قطعاً خود شما به عنوان متخصص این حوزه به آن برخوردهاید، اتکاء به محصولات کاری و توجه نکردن به دلایل وجودی آنها در متدهاست. به عنوان مثال، سند معماری و حتی ارتباط آن به موارد کاربرد در آریوپی مهم نیست، آن چه مهم و اجباری است «معماری کردن نرم افزار» است. همان طور که استحضار دارید، این یک اشتباه رایج است که سند معماری را معادل معماری کردن میانگارند. مثالی دیگر مورد داستان کاربر(یوزر استوری) است که ظاهر آن توجه میشود و نه به فلسفه وجودی آن(یکی از دوستان میگفت: داستان کاربر خیلی خوب است چون کلاً در چند خط خلاصه میشود، اما مورد کاربرد خوب نیست چون مجبور هستید که چند صفحه بنویسید!).
نکته سوم:
فرمایش شما که «این سطح از اجبار، در خانواده متدولوژی های چابک دیده نمیشود» کاملاً درست است، اما باید توجه داشت که متدولوژی در ذات خود اجبار و دیکته کردن را دارد، این موضوع شدت و ضعف دارد. متدهای چابک هم از این قاعده مستثنی نیستند، در برخی از آنها به خصوص آنهایی که به موضوعات فنی ایجاد نرمافزار میپردازند، این رویکرد نمایانتر است.
برای شما بهترینها را آرزومندم.
مهرداد
سینا
۲۲ اسفند ۱۳۹۰ در ۰۰:۰۰خوب بود …………………………………………………………………………