با سلام و درود، در اینجا در مورد RFP سعی کردم توضیخاتی را ارائه کرده باشم. قصدم رسیدن به اینجا بود که برای برون سپاری توسعه نرم افزار چگونه RFP تهیه کنیم. در ادامه در این مورد همراهتون خواهم بود. مرجع اصلی این نوشته اینجا می باشد.
مروری بر RFP
درخواست پروپوزال اولین قدم برای شروع بهنگام انتخاب طرف حساب برای انجام پروژه شما می باشد. یک RFP خوب، مشخصات کمپانی یا پروژه را تشریح می کند، نیازمندی های جزیی پروژه را برای محصول یا خدمت مورد نظر فراهم می کند و یک جدول زمانی نیز ارائه می دهد.
یک قالب RFP برای توسعه نرم افزار چه مواردی را باید داشته باشد:
- خلاصه ی اجرایی در مورد پروژه و نمای کلی شرکت
- محدوده و دامنه ی خدمات
- —- مدیریت پروژه
- —- زیر ساخت
- —- طراحی عملکردی
- —- الزامات محصول یا خدمت
- —- توسعه
- —- مدیریت محصول
- جدول زمانی
- ساختار پیشنهادی برای پشنهاد قیمت طرف قرارداد
- معیارهای انتخاب
حال به توضیح مفصل موارد فوق می پردازیم:
۱- خلاصه ی اجرایی در مورد پروژه و نمای کلی شرکت
همانطور که در حال نوشتن خلاصه پروژه هستید، اهداف، مقاصد پروژه، الزامات و محدودیت های پروژه را به روشی ساده و جامع ذکر کنید. اطلاعاتی در مورد مخاطبین هدف تان ارائه دهید. سعی کنید RFP حاوی اطلاعات مفید و به صورت فشرده باشد. احتمال زیاد شما این بخش را بعدا چندین مرتبه ویرایش کنید، اما مطمين شوید که RFP را با این بخش شروع کنید. چند پاراگراف در مورد شرکت و پیشینه آن مطرح کنید.
همین که اهداف پروژه را مطرح می کنید، ۲ چیز را در نظر بگیرید:
- هدف هر فعالیتی فراتر از محدوده آن فعالیت است. یعنی هدف از ایجاد یک وب-سایت ترویج درگاهی همه کاره و تعاملی با مشتریان شما می باشد و فقط محصول شما را نمی فروشد. هدف از طراحی پلتفرم B2B کاهش هزینه ها و افزایش گردش مالی از طریق اتوماسیون است و نه تنها توسعه نرم افزار برای تعامل با مشتریان تان. طرف قرارداد، نیاز به هدف حقیقی شما دارد تا بتواند یک راه حل متناسب با نیازهای شما ارائه دهد.
- مجموعه اهداف کمی (کمیت – مقداری) را بدست آورید، این اهداف می توانند نهایی و قابل دستیابی باشند یا فقط جهت توسعه تجارت شما را نشان دهند. برای مثال، جهت دو برابر کردن فروش در سال ۲۰۲۰ یا افزایش فروش حداقل ۲ برابری در هر سال. مهم نیست کدام گزینه را انتخاب کنید، فقط اطمینان حاصل کنید که می توانید پیشرفت را پیگیری کنید.
این قسمت از RFP بسیار مستقیم و مرتبط با استراتژی است. گرچه، این قسمت از اطلاعات، مهمترین اطلاعات هستند. مطمئن شوید که به سوالات زیر جواب داده شود:
- چه چیزی شرکت شما را منحصر به فرد می کند؟
- چه ایده ای را علاقه به پیاده سازی اش دارید؟
- آیا دیدی (vision) از پروژه دارید؟
- این پروژه چه ارزش هایی را به فرآیند های تجاری فعلی شرکت شما اضافه می کند؟
- نقاط ضعفی که قصد دارید بر آنها غلبه کنید چیست؟
- چرا راه حل فعلی شما کار نمی کند (در صورت وجود) ؟
برا کمک به طرف قرارداد و درک بهتر بیزینس شما، در ارائه اطلاعات حیاطی به آزادی رفتار کنید.
۲- محدوده و دامنه ی خدمات و خروجی
همین که وارد قسمت تکنیکال RFP شدیم، یه مقدار پیچیدگی ها شروع می شود. این قسمت، بزرگترین قسمت از ارائه درخوسات پیشنهاد شما برای توسعه نرم افزار شرکت تان می باشد. اطلاعات بیشتری را در این قسمت شما فراهم می کنید و محاسبه هزینه دقیقتری را از جانب طرف قرارداد خواهید گرفت.
مدیریت پروژه
در این بخش، سوالاتی در مورد روش شناسی (methodologies)، مشخصات مدیریت تیم که به صورت هایبرید باشد یا کار با مشتریان خارجه را مشخص می کنید.
گرچه رویکریدی جامع (one-size-fits-all) برای روش شناسی و مدل مشارکت وجود ندارد، در اینجا ما به عنوان طرف قرارداد، معتقدیم چرخه توسعه نرم افزار ( Software Development Lifecycle (SDLC) ) مبتنی بر اصول چابک (Agile) کارایی دارد. کلید چارجوب های Agile برای توسعه نرم افزار SCRUM و Kanban می باشد. در عین حال SAFe وLeSS نمونه هایی از اقتباس Agile برای پروژه های در مقیاس بزرگ می باشد. اینجا چیزی هایی که به نظر ما برای مدیریت پروژه مهم هستند و چیزهایی که شما در نظر خواهید گرفت را داریم:
- همگام سازی منظم با تمامی تیم های محصول. کیفیت ارتباطات در Agile مهم می باشد. در تکنیک SCRUM ارتباطات زیاد می باشد، مخصوصا ارتباطات ویدیويی، باید حتما از سرویسی که در این مورد کیفیت بالایی داشته باشد استفاده شود.
- هماهنگ کنند از طرف شرکت محلی در سَمت شرکت توسعه دهنده، برای تیم های بزرگ، پیشنهاد میشه شرکت سفارش دهنده یک رابط یا مدیر پروژه در شرکت توسعه دهنده داشته باشد.
- تاکید روی مستند سازی پروژه. اگر مستندات پروژه وجود ندارد، استخراج الزامات و مستندات توسط طرف قرارداد باید انجام شود یا تیم سومی وجود دارد؟
- تمرین های CI/CD و تست اتوماسیون، برای ساده سازی مراحل تحویل، بهره برداری و تست فرآیند ها به عنوان بخشی از همکاری در پروژه، بسیار مهم هستند.
زیرساخت
شما با پرسش های زیر در مورد رویکرد طرف قرارداد برای مورد قابلیت اطمینان بودن، امنیت اطلاعات و امنیت فیزیکی مطمين می شوید:
۱- شرکت شما دارای چه زیر ساختی می باشد؟
برای مثال در شرکت X ، دو اتاق سرور محافظت شده با دسترسی محدود وجود دارد.سه لینک دو گانه اینترنت، دو لینک داده بین دفاتر شرکت، رپلیکا و همانند سازی داده و نسخه پشتیبان وجود دارد.
۲- چه نوع محافظتی از نرم افزار انجام می شود؟
برای توسعه دهنده ها اجباری است که از آنتی ویروس های سطح دامین کنترل شده استفاده کنند. همچنین از Network Attack Blocker روی تمامی ایستگاه های کاری استفاده شود، اصول محدود سازی نرم افزار، سیستم پیشگری از نفوذ (IPS) در ورودی ها، ضد هرزنامه و …
۳- چگونه از حقوق مالکیت معنوی حمایت می شود؟
۴- امنیت داده و قابلت اطمینان چگونه تامین می شود؟
الزامات محصول
این مهم هست که الزانات عملکردی را جدا از غیر-عملکری قرار دهید. در برخی موارد الزامات محصول همان داستان های کاربر هستند. درادامه چند قالب مناسب که می توانید در RFP به هنگام لیست کردن الزامات محصول از آنها استفاده کنید، آورده شده است:
- کاربر محور (User-centered) : کاربر باید بتواند [عمل][شرایط] —- (برای مثال، خریدار باید بتواند محصولات را در لیست علاقه مندی هایش قرار دهد )
- محصول محور (Product-centered) : محصول باید [عمل][هدف/مفهوم/جابه‌جایی]—- (برای مثال: سیستم پردازش سفارش باید در مورد سفارش جدید به مدیر اطلاع دهد.)
- بر محور بهینه سازی (Optimization-centered): کاربر نیاز نیست که [عمل][هدف/شرایط محیطی] —-( برای مثال: خریدار نیاز ندارد که سفارش را با مرکز تلفن تایید کند)
- بر محور شیء (Object-centered): شیء باید دارای خصوصیات زیر باشد [لیست]—- (برای مثال: سفارش باید دارای این خصوصیات باشد: اطلاعات کاربر، آدرس تحویل، لیست محصولات سفارش)
- بر محور فرآیند (Processes-centered) :این ضروری است که [عمل][شیء][شفافسازی/ شرایط] —- (برای مثال: ضروری است که سفارشات با ERP هر یک ساعت همگام شوند )
برای پروژه تعیین نقش برای مدیریت الزامات و آنالیز ها ضروری است. پیشنهاد می شود از طرف قرارداد در مورد متخصصانت زیر برای پروژه تان پرسش شود:
- کارشناسان موضوع مورد بحث ــــ افرادی که بیزینس شرکت طرف قرارداد را با بیزینس شما متصل می کنند و در مورد نقشه راه، طراحی محصول و … با شما مشارکت می کند.
- تحلیلگرهای عملکردی ــــ
- طراحان UX ــــ
- متخصصان فنی ــــ
طراحی عملکردی
در RFP شما می توانید در مورد جزییات طراحی بپرسید و انتظارات خودتان از طراحی عنملکردی را تشریح کنید.
طراحی عملکردی بخشی از مدیریت الزامات و فرآیند پردازش جزییات می باشد. هر الزاماتی باید از جنبه های مختلف بررسی شود، از جمله اینکه چگونه روی UX تاثیر می گذارد، معمولا طرف قرارداد ها یک از موارد زیر را ارائه می دهند:
- تعریف UI/UX مبتنی بر الزامات اولیه بیزینس
- سازگاری UX با الزمات جدید بیزینس که وارد پروژه می شوند
- بررسی و بهبود UX ـــ در برخی موارد تغییرات کوچک در خیلی از جاهای UX در کل منجر به تغییر بزرگ می شود، پس در مواردی بعد داز چند مرحله اجرایی کردن نیاز به UX-refactoring می باشد.
توسعه
در این بخش نوبت یه زمانی رسیده که سوالاتی در مورد ابزارهای مدیریت پروژه وگردش کاری تحویل عمومی نرم افزار پرسیده می شود.
ابزار مدیریتی مانند Trello و Jira یا Rallyمی باشد. گردش کاری توسعه مانند Git. خروجی معمول فاز توسعه، سورس کد، اسکریپت، اسناد توسعه و تبصره های انتشار می باشد.
از اسناد سورس کد باید با قوانین بررسی کننده استایلِ کُدِ مورد نظر(corresponding code style checker) و بررسی دستی و منظم کد، اطمینان حاصل شد.
تضمین کیفیت
شما احتمالا خواهان اطلاع در مورد اصول تضمین کیفیت طرف قرارداد هستید. باید از جنبه های زیر سوال مطرح کنید:
- چطور روی گردش های کاری بیزینس تست انجام می شود
- ارتباط بین تیم های داخلی و خارجی چگونه می باشد.
- رویکرد برای ابزار و معیار های استفاده شده جهت تست اتوماسیون.
مدیریت محصول
اینجا طرف قرارداد از شما انتظار دارد که مشخص کنید مدیران محصول شما چگونه در توسعه نرم افزار مشارکت می کنند (ساخت الزامات بیزینس، برنامه ریزی، جلسات UX/UI، جلسات QA و …).
۳ – جدول زمانی پاسخ RFP
تصویر فوق نشون میده که جدول زمانی RFP شما به چه شکل خواهد بود. توجه کنید که اگر پروژه شما پیچیده می باشد، شرکت خارجی که باید جواب RFP شما را بدهد، باید به میزان کافی وقت داشته باشد. دادن زمان به آنها منجر به این میشه که حدسیات دقیقتری داشته باشید و برآورد مالی دقیقتری به شما ارائه دهند.
۴ – ساختار توصیه شده برای پیشنهاد مالی طرف قرارداد
گنجاندن این بخش در RFP تان، می تواند مقایسه پیشنهادات دریافتی را تسهیل کند.علاوه بر اطلاعات پایه، مانند خلاصه اطلاعات اجرایی و اطلاعات پیش زمینه از طرف قرارداد، از آنها بخواهید سند ساهتاری شامل داده های زیر فراهم کنند:
- ساختار کمپانی، تاییدیه ها، موقعیت دفترها
- اطلاعات در مورد فرآیند های آنها (چگونه پروژه ها را مدیریت می کنند، چگونه کیفیت را کنترل می کنند، از چه ابزاری استفاده می کنند)
- شایستگی تیم (تجربه، رزومه، ارتباطات)
- دید تکنیکال از پروژه (تکنولوژی ها، معماری)
- برنامه پروژه (مراحل و بازه های زمانی)
- آنالیز ها و برنامه برای پشتیبانی پروژه و بهبود های مداوم
- ارزیابی بودجه (هزینه های پایه پروژه، نرخ متخصصان، هزینه پشتیبانی پروژه، هزینه های اضافی احتمالی و غیره)
- لیستی از مشتریان
یک RFP خوب برای توسعه نرم افزار معمولا شامل دو مرحله می باشد:
مرحله اول ، مرحله مقدماتی است. در این مرحله، شرکت طرفین قراردادی را انتخاب می کند که پتانسیل انجام چنین نوع پروژه ای را داشته باشد. برای پیدا کردن این موضوع، شرکت از طرفین قرارداد نمونه کارها، پروژه ها و اطلاعات عمومی در مورد شرکت هایشان می خواهد.
مرحله دوم، جزیی تر می باشد. شرکت جزییات پروژه را به اشتراک می گذارد، و در مورد پیشبینی هزینه، جدول زمانی، دید تکنیکال از پروژه و شبیه این موارد سوال می پرسد. این کمک می کند تا طرفیت قرارداد سنجیده و تعدادشان کمتر شود.
یک عکس اینفوگرافی مانند در زیر مشاهده می کنید که ۸ راهنمایی برای نوشتن درخواست پروپوزال را ارائه داده است:
