RFP خوب چه اجزایی دارد؟

avatar
محمد دهقانی ۲۶ خرداد ۱۴۰۱icn_time زمان مورد نیاز برای مطالعه : 6 دقیقه

RFP در کدام مرحله از سفارش نرم‌افزار ایجاد می‌شود؟

اولین مرحله از تولید یک نرم‌افزار باکیفیت دریافت "درخواست پیشنهاد" صحیح است، این درخواست پیشنهاد یا RFP اگر به صورت دقیق و با اجزا قابل فهم تدوین نشده باشد عموما خشت اول کج نهاده شده و مراحل بعدی تولید نرم‌افزار نیز به انحراف کشیده خواهد شد.

در این مقاله سعی دارم تا تجربیات شخصی خودم را در خصوص اجرایی که یک پیمانکار در RFP شما به دنبال آن می‌گردد را نام برده و تشریح نمایم.


RFP چیست؟

RFP مخفف کلمه Request For Porposal است، که در ترجمه روان به "درخواست پیشنهاد" ترجمه می‌شود، زمانی که در صنعت نرم‌افزار از این واژه استفاده می‌کنیم منظورمان "درخواست پیشنهاد برای تولید نرم‌افزار" است.


کاربرد (ار.اف.پی) چیست؟

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

به همین دلیل است که مراحل توسعه یک پروژه نرم‌افزاری به مراتب پیچیده‌تر است و نیاز به افراد خبره و همچنین متدولوژی صحیح راهبری پروژه در این خصوص می‌باشد.

توسعه RFP صحیح و استاندارد کمک می‌کند تا سایر اسناد بالادستی پروژه از تعریف صحیحی برخوردار شوند، همچنین داشتن یک RFP دقیق و مهندسی شده به پیمانکاران این اجازه را می‌دهد تا با کمترین ریسک ممکن نسبت به ارائه نظرات خود در خصوص پروژه اقدام نمایند.


چرا توصیه می‌شود حتما قبلا از شروع مکاتبه با پیمانکار نرم‌افزار  (Request For Porposal) خوبی آماده کرده باشید؟

بارها و بارها تجربه کرده‌ام که افراد سفارش پروژه نرم‌افزار را شبیه یک سفارش خرید می‌بینند، مثلا "یک نرم‌افزار مثل دیوار" چقدر هزینه خواهد داشت؟

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

بنابراین اولین گام صحیح در تولید یک نرم‌افزار خوب این است که بتوانیم با موفقیت RFP با کیفیتی را آماده کنیم.

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


چگونه یک RFP (درخواست پیشنهاد نرم‌افزار سفارشی) خوب  و قابل فهم بنویسم؟

راهنمای تهیه RFP (Request For Porposal)

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

مسئله RFP را شفاف کنید.
زمانی که یک درخواست برای توسعه محصول نرم‌افزاری سفارشی تهیه می‌کنید لازم است تا به صورت کاملا شفاف تعیین کرده باشید که "مسئله" اصلی شما یا سازمان شما چیست که قرار است با تولید نرم افزار این مسئله حل شود.

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

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

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

در یک پروژه دیگر این موضوع بر سر مشتریان اتفاق افتاد؛ به دلیل اینکه واضح نبود محصول کدام دسته از مشتریان را هدف قرارداده است دو دپارتمان داخلی شرکت همواره بر سر مالکیت و صاحب نظری اختلاف نظر عمیق داشتند.

بنابراین، در ابتدا مشخص کنید چه کسی یا کسانی نهایتا می‌خواهد از این نرم‌افزار استفاده کنند.

محدوده پروژه را مشخص کنید و کمترین ویژگی‌های محصول نرم‌افزاری قابل قبول را تعریف کنید.

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

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

بازیگران اصلی پروژه را معرفی کنید.

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

عنوان و خلاصه‌ای از فرایندهای نرم‌افزار را تشریح کنید.

در این بخش از RFP به این فرایندهای اصلی و فرعی را نام ببرید؛ اگر جزئیات بیشتری از این فرایندها بیان کنید تخمین دقیق‌تری از پروژه به شما ارائه خواهد شد.

فرضیات پروژه را با دقت ثبت کنید.

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

از بیان محدودیت‌ها غافل نشوید.

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

نیازمندی‌های غیرعملکردی را تشریح کنید.

نیازمندی‌های غیرعملکردی در نرم‌افزار، آن دسته از نیازمندی‌هایی هستند که مستقیما به یک ویژگی خاص اشاره نمی‌کنند؛ در اصل به این سوال پاسخ می‌دهند که نرم‌افزار چطور باید کار کند؟

بنابراین مسائلی نظیر؛ امنیت، سرعت، تعداد کاربر همزمان و ... در این حیطه طبقه‌بندی می‌شوند.

شاخص‌ها و معیارهای پذیرش شرکت پیمانکار را تعریف کنید.

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

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

از بیان بازه زمانی مد نظر اجتناب نکنید.

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



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



  • favourite0 پسندیده
  • chat0 نظر

دیدگاه خود را در مورد این مطلب بنویسید
نظرات (0 نفر)
icon-chat-addافزودن نظر

چت آنلاین با پشتیبانی ردمنت

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