مبین رنجبر » تجارت نرم افزار

این پروژه می شود فلان میلیون تومان!

نوشته شده توسط مبین رنجبر در ۲۵ دی ۱۳۹۲

software-licensing

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

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

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

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

  1. الگوریتمی:  که با فرمول و محاسبات ریاضی هزینه را تعیین می کند.
  2. غیرالگوریتمی: که کاری با فرمول و محاسبات ندارد.

 

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

در اینجا به بررسی خلاصه وار دست کم دو مورد از روش های غیرالگوریتمی می پردازیم:

Expert Judgment Method یا روش قضاوت متخصص :

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

مراحل تخمین این روش به صورت زیر است:

الف.هماهنگ کننده مختصصین را با جزئیات و فرم مخصوص تخمین آشنا می کند.

ب.متخصصین فرم ها را به صورت ناشناس تکمیل می کنند.

ج.هماهنگ کننده با متخصصین تشکیل جلسه می دهند و در رابطه با موارد تخمینی با یکدیگر بحث می کنند.

د.هماهنگ کننده خلاصه نتیجه تخمین را به صورت فرم های تکراری آماده سازی و توزیع می کند.

ی.متخصصین بار دیگر فرم ها را به صورت ناشناس پر میکنند و مراحل ۴ و ۵ را تا زمان مناسب تکرار می شوند.

روش تخمین با مقایسه

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

مراحل تخمین با استفاده از این روش به صورت زیر است:

الف.درک خصوصیات پروژه خواسته شده.

ب.انتخاب شبیه ترین پروژه که در پایگاه داده مربوط به خصوصیات ذخیره می شود.

ج.یافتن تخمین نهایی برای پروژه از میان پروژه مشابه.

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

مدل کوکومو (COCOMO)

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

  1. به خوبی مستند شده است و توسط ابزارهای تجاری پشتیبانی می شود.
  2. به طور گسترده استفاده و ارزیابی شده است.

 

جدول زیر معایب و مزایای روش های متداول هر دو گروه را به طور خلاصه شرح داده است:

روش

نوع

مزایا

معایب

COCOMO

الگوریتمی

نتایج روشن، بسیار مرسوم

داده های زیادی نیاز است، برای همه پروژه ها مناسب نیست.

Expert Judgment

غیر الگوریتمی

پیش بینی سریع، پذیرفته شدن در پروژه های خاص

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

Function Point

الگوریتمی

مستقل از زبان،نتایج اش از معیار SLOC بهتر است.

مکانیزه کردن آن سخت است،کیفیت خروجی در آن مورد توجه قرار نمیگیرد.

Analogy

غیرالگوریتمی

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

اطلاعات بسیار زیادی از پروژه های گذشته نیاز است،در بعضی موقعیت ها هیچ پروژه مشابه ای وجود ندارد

Parkinson

غیرالگوریتمی

با تجربیات در ارتباط است.

عادات و کارهای نامناسب را شدت می بخشد.

Price to Win

غیرالگوریتمی

اغلب قرارداد می خواهد.

عموما اضافه کاری را بیشتر می کند.

Top-Down

غیرالگوریتمی

جزئیات حداقلی از پروژه نیاز است،معمولا برای اجرا سریعتر و راحت تر است،تمرکز در سطح سیستم

اساس انتزاعی دارد، از پایداری کمی برخوردار است.

Bottom-up

غیرالگوریتمی

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

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

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

در پایان به طور خلاصه باید بگویم که برای تمامی محصولات و پروژه ها نمی توان یک روش را انتخاب کرد.

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

 

 

منابع

Software Engineering (8th Edition), Ian Sommerville

Performance Analysis of the Software Cost Estimation Methods:A Review, International Journal of Advaned Research in Computer Science and  Software Engineering, Volume 3, Issue 7, July 2013

بزرگ‌داده:داستان یک ملاقات

نوشته شده توسط مبین رنجبر در ۱۷ آذر ۱۳۹۲

A Story of Big Data:Introduction from Mobin Ranjbar

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

نوشته شده توسط مبین رنجبر در ۲۱ آبان ۱۳۹۲

با درود فراوان

خوب هستی مبین جان ؟

من همیشه پیگیر فعالیت ها و زحمات شما در حوزه استارتاپ ها هستم به امید موفقیت های بیشتر دوست عزیز .

 آقا یکی از مشکلاتی که استارتاپ ها دارند این هست که اگه صاحب ایده برنامه نویس نباشه برای پیدا کردن یک برنامه نویس حرفه ای با اخلاق حرفه ای (بد قول نباشه ، حرفه ای باشه و روی مباحث کارش فوق العاده مسلط داشته باشه ، سرقت ایده یا سورس کد نکنه و …) بسیار بسیار در کشور ما سخت است . من با بیش از ۴ برنامه نویس در این ۲ سال کار کردم که بسیار اذیتم کردند .

 

مدتی پیش ایمیلی دریافت کردم با متنی که در بالا آمده و به دلیل کمبود وقت و حجم بالای ایمیل ها شاید کمی دیر شده باشد ولی فکر کردم شاید بهتر باشد به پیشنهاد این دوست عزیز عمل کنم و جواب این ایمیل را در یک پست مستقل بنویسم.

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

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

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

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

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

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

داستان یک برنامه نویس که از علم بازاریابی چیزی نمی دانست

نوشته شده توسط مبین رنجبر در ۱۸ آبان ۱۳۹۲

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

وقتی که نوشتن آن برنامه تمام شد با افتخار اعلام کردم “بلاخره راه اندازی شد”.اعلام کردم یعنی اینکه دقیقا این عبارت را توییت کردم.

در زیر لیست کارهای مرتبطی که بعد از راه اندازی اتفاق افتاد را می توانید بخوانید:

  • روی وب سایت معرفی به روزترین اپلیکیشن ها قرار گرفت.

عکس العمل من: اوه عالیه! در عرض دو روز ۴۰ بار دانلود شد.

  • به وبلاگ ها و وب سایت هایی که اپلیکیشن ها را مورد ارزیابی قرار میدهند ایمیل زدم.

نتیجه: پاسخی نگرفتم.

  • یکی از شرکت هایی که اپلیکیشن مشابه را داشت در اکانت توییترش ما را معرفی کرد.
  • بسیاری از تست کنندگان نرم افزار در مورد این اپلیکیشن توییت کردند و گفتند:

اوه پسر! محشره.

  • درخواست های همکاری زیادی گرفتم و با توجه به میزان فروشی که کسب کرده بودم تصمیم گرفتم فروشگاه آنلاین خودم را راه اندازی کنم.

در روز پنجم فروشگاه را راه اندازی کردم و یک فرم ثبت نام هم برای اپلیکیشن پیاده سازی کردم.

نتیجه در روز هشتم: هیچ فروشی نداشتم.

  • کد پرداخت ۵۰ درصدی تولید کردم و به افراد زیادی دادم.

هر کسی که درخواست کرده بود یک کد تخفیف گرفت.

  • فهمیدم که سایت من اصلا روی گوگل لیست نشده است.

پس تصمیم گرفتم که ابزار مدیریتی داشته باشم و سایتم را بر روی گوگل ثبت کردم.

  • اپلیکیشن من در فروشگاه معتبر آنلاین شرکت Atlassian معرفی شد.
  • در روز هفتم باز هم به وبلاگ ها و وب سایت ها ایمیل زدم.

نتیجه: بازهم پاسخی نگرفتم.

  • در روز هشتم وب سایت ۲۲۹۱ بازخورد گرفت.
  • اکانت توییتر اپلیکیشن حالا ۳۸ دنبال کننده دارد.

در کل توانستم با همه این راه ها ، ۱۱ تا از این اپلیکیشن بفروشم.مردم منتظر بودند که نسخه آزمایشی نرم افزار تمام شود؟ یا اینکه اصلا اپلیکیشن را پاک کرده اند؟ نمی دانم.

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

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

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

اسلاید “استارتاپ زیر صفر” ، آشنایی با استارتاپ ها به زبان ساده

نوشته شده توسط مبین رنجبر در ۲۷ شهریور ۱۳۹۲

Smooth Introduction To Startups – استارتاپ زیر صفر،آشنایی با استارتاپ ها به زبان ساده from Mobin Ranjbar

در سایت های دیگر

نوشته شده توسط مبین رنجبر در ۱۳ مرداد ۱۳۹۲

در این پست تمامی مقالات و ویدیو هایی که تاکنون در سایت های دیگر از من منتشر شده را می توانید مشاهده کنید :

وب سایت تجارت نرم افزار

وب سایت آی کلاب

وب سایت دنیای چابک متعلق به موسسه اسکرام ایران

و همچنین بعضی از مقالاتی که بالا ذکر شد در «مدرسه کسب و کارهای نوپا کاریا» هم از طریق لینک های زیر قابل دسترس هستند:

ویدیو ها :

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

نوشته شده توسط مبین رنجبر در ۷ مرداد ۱۳۹۲

این ویدیو که ترجمه زیرنویس آن را انجام داده ام شدیدا توصیه می شود که تماشا کنید