قالب پیشنهادنامه پروژههای نرمافزاری
«نقشه راه چند مرحلهای در تدوین پروپوزال، از درک مسئله تا تضمین موفقیت پروژه»
در گذشته گفتیم که سازمانها برای کمک گرفتن از شرکتهای نرمافزاری اقدام به «انتشار 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. معرفی شرکت
این بخش برخلاف بخشهای قبل، اختصاص به یک پروژه و پیشنهاد جاری ندارد. در واقع یک سری اطلاعات عمومی را در مورد شرکت پیشنهاددهنده ارائه میکند.
مشتری در این بخش علاقهمند است از «خطوط تجاری» شرکت مطلع شود و با یافتن جایگاه این پروژه در خطوط تجاری شرکت میزان انگیزه و جدیت خود را برای انجام این پروژه تخمین بزند. همچنین «سن»، «سوابق»، «مقیاس» و «توان مالی» شرکت، دستاوردهای مهمش و مجوزها و جوایزی که دریافت کرده به تصمیمگیری مشتری کمک میکند.
مقالات مرتبط
سید جمالالدین پیشوایی
رئیس هیئت مدیره و مدیر فنی علاقهمند به معماری راهحلهای نرمافزاری
اگر این موضوع در سازمان شما به یک چالش تبدیل شده...
تیم اعوان میتواند در ارزیابی معماری و زیرساخت فعلی شما همراه باشد. تجربه ما در پروژههای بانکی و... برای همین موقعیتها جمعآوری شده است.