بایدها و نبایدها در ارائه پروپوزال
کسب و کار دیجیتال

بایدها و نبایدها در ارائه پروپوزال

۱ 977

در اسفند ۸۸ در وب سایت بزرگ برنامه نویس به موجب سوال یکی از دوستان در مورد “شیوه ارائه طرح پیشنهادی نرم افزار”  توضیحاتی هر چند مجمل دادم که خوندنش خالی از لطف نیست:

Proposal رو باید بر اساس RFP یا Request For Proposal ای که از مشتری میگیرین تهیه کنید.
RFP از اهمیت زیادی برخوردار هست چون پیش نیاز Proposal هست و شما بر اساس اون هست که طرحتون رو ارائه میکنین. در RFP کلیاتی که مد نظر مشتری هست نوشته میشه. به نظر من RFP اولیه اگه اصولی نوشته شده باشه تا بیست درصد از حدود پروژه رو مشخص میکنه که این درصد باید حداقل به ۴۰ برسه.
معمولا مشتری توانایی و دید تهیه RFP خوب رو نداره. اون در مورد امکانات پروژه نهایت یه پاراگراف میتونه بنویسه و صرفا کلیات قضیه رو میبینه! اگه منظور از این کلیات مشخص نشه مطمئنا در برآورد قیمت و زمانبندی پروژه دچار مشکل میشین. و البته ذهنیت مشتری در تهیه RFP چیز غریب الوقوعی نیست شما وقتی میخوای بری مثلا بنز بخری هم دقیقا همین حالت رو داری مگر اینکه بری جزئیات مدل ها رو بررسی کنی. شما بعنوان مشاور می بایست به مشتری در هرچه کامل تر شدن RFP کمک کنید و حد و حدود پروژه رو تو جلساتی که با مشتری میذارین تعیین کنید و این موارد رو مکتوب کنید. معمولا تو این جلسات مطالبی که توسط مشتری بیان میشه سازماندهی خاصی نداره و هر چیزی که به ذهنش میرسه بیان میکنه. توسعه و طبقه بندی این موارد به تجربه ی شما برمیگرده که بتونین ذهن مشتری رو متناسب با امکانات پروژه و دیدی که شما از آینده کار دارین متمرکز کنین. مثلا میتونین یه فرم اولیه طراحی کنید و در اون یه سری سوالات در مورد پروژه از مشتری بپرسین و بعد روی این موارد بحث کنید و امکانات رو بسط بدین. تعامل شما با مشتری خیلی مهم هست و اگر میخواین پروژه رو بگیرین به این موارد حتما توجه کنید. حتی اگه مبلغ قرارداد ۱۰۰ تومن هست باز کارتون رو جدی بگیرین. اعتماد مشتری رو تو این جلسات هست که میتونید جلب کنید. در سیستم های نرم افزاری معمولا جا برای توسعه و شاخ و برگ دادن به امکانات زیاد هست اصلا به این فکر نکنید ممکنه مشتری به این امکانات نیاز نداشته باشه شما پیشنهاداتی که میتونین عملی کنین و احساس میکنین میتونه مفید باشه بیان کنید. حتما مثال هایی از نمونه کارهای قبلی تون رو برای مشتری عنوان کنین تا بهتر بتونه با موضوع آشنا شه.
بعد از اینکه به یه RFP نسبتا خوب رسیدین حالا یه وقتی رو از مشتری بگیرین برای ارائه طرح پیشنهادی یا همون Proposal.
اون چیزی که باید در Proposal باشه بسته به شرایط پروژه میتونه متفاوت باشه ولی کلیاتش اینا هستن:

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

خیلی از دوستان در مورد قید کردن خدمات پشتیبانی نرم افزار در پروپوزال سوال می پرسن در جواب باید بگم فقط اشاره ای به خدمانت پشتیبانی کنید کافی هست چون در صورت لزوم در قرارداد اصلی میتونید بهش بپردازید. پشتیبانی به نوع پروژه و مبلغ قرارداد بستگی داره. مثلا میتونید ۲ماه پشتیبانی رایگان داشته باشین. بسته به نوع و شرایط پروژه، بطور میانگین حدود ۲۰ درصدِ مبلغ قرارداد تعرفه پشتیبانی یکساله هست(این ۲۰ درصد کاملا نسبی و تقریبی هست) منتها مستقیما لزومی نداره اینو به مشتری بگین! بعضی پروژه ها کار زیادی در پشتیانی ندارن ولی بعضی ها چرا کار زیادی میبرن تقریبا مشخص هست و در تعیین قیمت تاثیر داره.
قبل ار قرارداد چارچوب خدمات پشتیبانی رو به مشتری توضیح بدین طوریکه توقع نداشته باشه چون پول پشتیانی داده شما بعد از ۴ماه یه پروژه دیگه براش بنویسین! جزئیات خدمات پشتیبانی رو هم حتما در قرارداد مکتوب کنید.
پ.ن: بعنوان یه استراتژی غیر منصفانه، متاسفانه بعضی از شرکت ها قیمت رو پایین میدن و در قرارداد، بند پشتیبانی رو ذکر میکنن و توش اینجوری مینویسن که قیمت خدمات پشتیانی طبق توافق اعلام میشه و تحت عنوان متمم این قرارداد پس از توافق طرفین امضاء میشه. مشتری هم اغلب به این بند زیاد گیر نمیده بعد قیمت پشتیانی رو بالا میدن و چون کار مشتری هم گیره مجبور میشه قرارداد ببنده.

موفق باشید.

در باره نویسنده / 

حمیدرضا متقیان

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

یک دیدگاه

  1. سارا ۱۳۹۰-۰۸-۰۸ در ۵:۲۵ ق.ظ - 

    ممنون

ارسال پاسخ

ایمیل شما نمایش داده نمی‌شود. موارد مورد نیاز علامتگذاری شده است *

*

code

عضویت در خبرنامه

نوشته های تصادفی

  • 5 افسانه Agile

    ۵ افسانه Agile

    بی شک برای استفاده از هر روش جدیدی دلایلی وجود دارد.  یکی از این دلایل می تواند برتری نقاط قوت روش جدید نسبت به روش فعلی باشد. اما آیا همیشه اینطور است؟ اگر شما به یکی از دلایل ذیل می خواهید به اجایل مهاجرت کنید باید بدانید که دچار افسانه زدگی Agile شده اید! این…

  • 24 تله ی رایج در اسکرام

    ۲۴ تله ی رایج در اسکرام (بخش اول)

    همونطور که می دونید اسکرام محبوب ترین متد Agile است اما انجام صحیح اسکرام کار ساده ای نیست! برای این که شما هم بتونید اسکرام را درست پیش ببرید مواظب باشید در این تله ها گرفتار نشین. ۱ افراط در مقدمه­ سازی و برنامه ریزی. قبل از شروع هر اسپرینت در اسکرام نیازی نیست مته…

  • the-internet-of-things

    آینده در دستان اینترنت اشیاء (IoT)

    Internet Of Things تحولی در آینده اینترنت است که مسلماً کسب و کار نرم افزار رو بسیار پر رونق تر و در عین حال فراگیرتر می کنه.  فرض کنید به خرید رفتید و خیلی راحت از یخچال خونتون استعلام میکنید که چه چیزهایی رو باید خریداری کنید؛ نیم ساعت قبل از اومدنتون میتونید سیستم تهویه…