قالب پیشنهادنامه پروژه‌های نرم‌افزاری

بسم الله الرحمن الرحیم

در گذشته گفتیم که سازمانها برای کمک گرفتن از شرکتهای نرم‌افزاری اقدام به « انتشار RFP» یا Request For Proposal می‌کنند. در ادامه داستان می‌خواهیم ببینیم مشتری دوست داره در پیشنهادنامه‌هایی که شرکتها بهش میدن چه چیزهایی ببینه. یکی از وظایف ما در تیم چکاپ شرکت اعوان، اینه که به سازمانها کمک کنیم مجری پروژه‌هاشون رو انتخاب کنند. در ماه‌های اخیر ده‌ها پیشنهاد رو برای چندین سازمان مختلف بررسی کردیم. طی این تجربه متوجه شدیم وجود بخشهایی زیر در پیشنهادنامه‌ها، روی امتیازدهی تاثیر قابل توجهی دارند.

1. خلاصه مدیریتی

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

2. بیان مساله

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

3. راهکار پیشنهادی

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

4. جدول تطبیق

در RFP مجموعه‌ای از خدمات، کارکردها (Functionalities) و ملزومات فنی مورد درخواست قرار گرفته. در جدول تطبیق پیشتیبانی از تک تک این موارد، تعیین وضعیت میشه. آیتم‌هایی که به طور کامل انجام خواهد شد با FC (مخفف Full Compliance) و مواردی که انجام نخواهد شد با NC (مخفف Non-Compliance) و مواردی که تا حدودی انجام می شوند با PC (مخفف Partial Compliance) برچسب می‌خورند. ذکر توضیح برای مواردی که کامل پوشش داده نمیشن (یعنی PCها) ضروریه. در سایر موارد هم اگر ابهامی در تفسیر بندهای RFP می‌بینید یا با پیش‌فرضهای خاصی اعلام وضعیت کردید از ذکر توضیح دریغ نکنید.

5. متدلوژی

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

6. برنامه زمانی

در چه گام‌هایی قراره پروژه به ثمر برسه؟ در هر گام قراره چه فعالیت‌هایی انجام و چه خروجی‌هایی تحویل بشه. مشتری توقع داره که برنامه زمانی، قیود زمانی اعلام شده در RFP رو نقض نکنه. مثلاً اگر قید شده «بعد از ۳ ماه اولین نسخه زیر بار عملیاتی بره»، همه پیش‌نیازهای تحقق این هدف، باید قبل از ۳ ماه در برنامه گنجانده بشه.

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

7. نیروهای کلیدی

افراد شاخصی که قراره بار پروژه رو به دوش بکشند اینجا معرفی میشن. بعضی‌ها اسم همه پرسنل شرکت یا حتی دوستان و آشنایان رو بدون اینکه ضرورتاً نقشی در پروژه آتی داشته باشند، ذکر می‌کنند که صادقانه و مفید نیست. لازمه راجع به هر کدوم از فراد «سمت در شرکت» و «مسئولیت در پروژه» مشخص شده باشه. هر فرد چقدر از وقتش رو در شرکت پیشنهاد دهنده حضور داره؟ چقدر از اون رو صرف این پروژه خواهد کرد؟ میزان «سابقه کاری» شخص و میزان «سابقه‌اش در شرکت» هم حس دقیق‌تری از وزن اون شخص در پروژه ایجاد میکنه.

8. سوابق مرتبط

در این بخش، پروژه های قبلی شرکت که به این پروژه شباهت دارند رو لیست کنید. خوبه به ازای هر پروژه، «توضیحی مختصر»، «تاریخ‌های مهم» مثلاً تاریخ شروع، تاریخ پایلوت یا تاریخ عملیاتی‌سازی و «نقطه تماس با نماینده مشتری» رو ذکر کنید. تبعاً لازمه وجه شباهت هر کدوم از موارد با این پروژه شفاف بشه. مثلاً شباهت در موضوع، مقیاس یا فناوری.

9. برنامه ریزی منابع انسانی

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

10. هزینه

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

11. معرفی شرکت

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

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