نحوه نوشتن RFP نرم افزار به صورت اصولی و کامل

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

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

نحوه نوشتن RFP نرم افزار به صورت اصولی و کامل

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

تفاوت RFP «خرید محصول» با RFP «توسعه سامانه»

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

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

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

توجه داشته باشید که تنها برگزاری تشریفات مناقصه کافی نیست؛ سند RFP باید معماری مطلوب سازمان را ترسیم کند.

جدول مقایسه RFP «خرید محصول» با RFP «توسعه سامانه»:

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

اجزای ضروری یک RFPاستاندارد (چک لیست فنی)

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

شرح دقیق نیازمندی های عملیاتی (Functional):

نیازهای عملیاتی هنگام نوشتن RFP نرم افزار شامل مواردی مانند اهداف کلی پروژه، بودجه، مستندات فنی مناقصه، زمانبندی، برنامه ریزی پروژه و … می شوند. با توجه به این موضوع بهتر است زمانی که RFP نرم افزار را تنظیم می کنید، تقاضای جزئیات کنید.

به طور مثال شرح خدمات توسعه نرم افزار (SOW) بخواهید. این شرح خدمات، اطلاعات مربوط به کار، زمان، منابع و چگونگی انجام کار را در اختیار شما قرار می دهد.

نیازمندی های غیر عملیاتی (Non-Functional):

از دیگر اجزای ضروری RFP می توان به نیازمندی های غیرعملیاتی اشاره داشت. این اجزا می توانند نیازهای عملکردی را پوشش دهند و احتمال اجرای آن ها را بالا ببرند. Security (امنیت)، Performance (کارایی در ترافیک بالا)، پشتیبانی و همچنین Scalability (مقیاس‌پذیری) مهم ترین نیازهای غیرعملیاتی RFP هستند.

اجزای ضروری یک RFP استاندارد (چک‌لیست فنی)

تله ی «قفل شدگی پیمانکار» (Vendor Lock-in) و راه فرار

یکی از مهلک‌ترین اشتباهات در فرآیند خرید نرم‌افزار، نادیده گرفتن استراتژی خروج است. بسیاری از سازمان‌ها ناخواسته وارد دالانی می‌شوند که انتهای آن تله‌ی «قفل شدگی پیمانکار» یا همان Vendor Lock-in است؛ وضعیتی که در آن تغییر تامین‌کننده به دلیل هزینه‌های سرسام‌آور مهاجرت، عملاً غیرممکن می‌شود. اما ریشه‌ی این گرفتاری کجاست؟ اغلب در همان خشت اول، یعنی سند RFP.

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

بهترین راهکارهایی که برای جلوگیری از قفل شدگی (Vendor Lock-in) می توانید مورد استفاده قرار دهید، عبارتند از:

تحویل سورس کد (Source Code) کامل:

حتما این موضوع را مورد توجه قرار دهید که هنگام نوشتن RFP نرم افزار، تمامی منابع و کد مبدا در اختیار شما قرار بگیرد. این موضوع در بهبود عملکرد اپلیکیشن و پیاده سازی اطلاعات روی آن نقش بسیار مهمی دارد. از طرفی این کدها شامل رابط کاربری (UI)، تنظیمات، منطق برنامه (Logic) و … می شوند.

استفاده از تکنولوژی‌های استاندارد و مدرن:

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

مستندات کامل دیتابیس:

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

تله‌ی «قفل شدگی پیمانکار» (Vendor Lock-in) و راه فرار

معیارهای امتیازدهی به پیمانکاران (جدول ارزیابی)

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

ویژگی	امتیاز
سابقه در پروژه‌های مشابه دولتی	30 امتیاز
معماری پیشنهادی و تکنولوژی	30 امتیاز (شرکت های قدیمی که از تکنولوژی های قدیمی استفاده می کنند، این امتیاز را دریافت نمی کنند.)
مالکیت سورس و انتقال دانش	20 امتیاز
قیمت	20 امتیاز (هرگز کیفیت را فدای قیمت ارزان نکنید.)

معیارهای امتیازدهی به پیمانکاران (جدول ارزیابی)

نتیجه گیری و قدم بعدی

بسیاری از سازمان‌ها دچار این خطای استراتژیک می‌شوند که RFP را صرفاً یک «تشریفات اداری» می‌پندارند و با کپی‌برداری از قالب‌های آماده یا اسناد قدیمی، سعی در تسریع فرآیند مناقصه دارند. اما مدیران باتجربه فناوری اطلاعات به‌خوبی می‌دانند که این سند، «DNA سامانه آینده» سازمان است. صرف زمان و دقت کارشناسی برای تدوین یک RFP دقیق، هزینه نیست؛ بلکه سرمایه‌گذاری هوشمندانه‌ای است که جلوی ریسک‌های بزرگی همچون «قفل‌شدگی پیمانکار» (Vendor Lock-in)، عدم تطابق با فرآیندها و شکست پروژه را در همان گام نخست می‌گیرد. فراموش نکنید که کیفیت خروجی نهایی، دقیقاً به اندازه کیفیت ورودی‌های RFP شما خواهد بود.

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