پيشتر ها در زمينه موارد ابتدايي پروژه (اعم از نوشتن RFP ، مناقصه، زمانبندي پروژه و ....) نوشته هايي در  وبلاگ گذاشته بودم. امروز مي خواهم چند جمله اي در مورد تحويل پروژه و بايد ها و نبايد هاي آن صحبت کنم. مطمئن هم هستم که نوشته کامل و يا علمي نخواهد شد. اگر باز بدقول نشوم، در نوشته هاي تکميلي به اين مطلب خواهم پرداخت.
اما چرا این موضوع؟ اين روزها به طرق مختلف درگير قسمتي از زمان يک پروژه هستم که آن را مي شود بخش پاياني و موقع تحويل پروژه دانست. زماني که پيمانکار کار خود را تمام شده مي داند و مايل است محصول توليد شده را به کارفرما تحويل دهد. مايل نيستم از لغت پايان يا اختتام استفاده کنم، چون به نظر من هيچ پروژه اي تمام نمي شود. به قول معروف، چرخه عمر نرم افزار بينهايت است.بگذريم. در پروژه اي به عنوان مشاور، وظيفه دارم به عنوان به کارفرما کمک کنم که پروژه اش را از مجري آن تحويل گيرد و در جاي ديگري به عنوان پيمانکار سعي مي کنم که کار خودمان را با مشتري آن نهايي کرده و وارد فاز پشتيباني شويم، از سوي ديگر در يک مساله داخلي رادمان، بايد کارهايي را از کساني که به آنها به صورت out source پروژه داده ايم تحويل بگيرم. پس به نوعي با سه نقش درگير هستم. پس بگذاريد از سه زاويه ديد، کارفرما، مشاور و پيمانکار اين مساله را باز کنم.

-کارفرما يا مشتري:
خريدار و سفارش دهنده يک نرم افزار در دو نقش بايد پروژه را تحويل گيرد، به عنوان مشتري (مدير) که بابت آن پول داده است و قرارداد را امضاء کرده است (خريدار واقعي) و کسي که با نرم افزار خريداري شده ارتباط مستقيم دارد و با آن کار مي کند (کاربر) به عبارت ديگر مدير سفارش دهنده براي برآورده ساختن نياز سازمان خود اقدام به درخواست يک نرم افزار نموده که پس از آماده شدن توسط کارمندان وي مورد استفاده قرار مي گيرد. هر دوي اين گروه بايستي در فرآيند تحويل نرم افزار حضور فعال داشته باشند. در هر دو نقش، مشتری بایستی موارد زیر را در زمان تحویل گرفتن پروژه مد نظر قرار دهد:
1- مطابقت نرم افزار تحویل شده با مشخصات اولیه قرارداد.
2- اطمینان پیدا کردن از صحت عملکرد بخش های مختلف با انجام شبیه سازی ها و یا آزمایش با داده های واقعی
3- تحویل گرفتن کامل بخش ها اعم از نرم افزار و پایگاه داده برای امکان نصب مجدد (در صورت وجود در قرارداد)
4- تحویل گرفتن کامل آموزش های کاربری و مدیریتی مطابق با زمانی که در قرارداد برای آنها مشخص شده است.
5- عدم تغییر نیاز و یا تحمیل سلیقه های شخصی به گروه برای تحویل (به عبارت دیگر باید فقط آن چیز که مجری متعهد شده است را تحویل بگیرد، نه آنکه سعی کند آن چیزی را که می خواهد و یا دوست دارد تحویل بگیرد. در این صورت، زمان تحویل پروژه معمولا بسیار طولانی و در نهایت پروژه را منجر به شکست می کند، که این به ضرر هر دو طرف می باشد.)

- مشاور:
مشاور به عنوان نیروی کمکی کارفرما وظیفه دارد به وی در زمان تحویل پروژه نظرات مشاوره ای و تخصصی بدهد. شاید یکی از وطایف مهم مشاور در همین بخش باشد. مشاور باید به شکلی بدون آنکه منافع کارفرما در خطر واقع شود، بین خواسته های وی و آن چیزی که آماده شده است تعدیل برقرار کند. در این بین موارد زیر باید مورد توجه قرار گیرند.
1- مطابقت مشخصات نرم افزار با خواسته های طرح شده در سند اولیه پروژه (برای مثال RFP)
2- انجام کنترل های کیفی روی محصول تحویل شده مطابق با مشخصات درخواست شده
3- مطابقت مواد قانونی قرارداد ها اعم از زمان، نوع تحویل، آموزش کاربران، نوع پشتیبانی و مشخصات محصول
4- مصالحه بین کارفرما و پیمانکار در موارد مورد اختلاف، برای مثال در زمانی که اختلافی در مورد یک بخش خاص از محصول وجود دارد، با بررسی دقیق، طرف حق را تشخیص داده و وی را توجیه نماید. چنانچه کارفرما بیش از میزان واقعی نیاز مطرح کند باید نیاز وی را تعدیل کند و چنانچه پیمانکار کمتر از میزان واقعی تحویل دهد، وی را مجبور به انجام تغییرات
5- آزمایش فنی بخش های مختلف و انجام امور اعتبار سنجی (Validaton) و وارسی (Verification) برای اطمینان پیدا کردن از کامل و صحیح بودن همه بخش ها
6- تشخیص نیازهای جدید و کمک به عقد قراردادهای تکمیلی، افزایش قرارداد جاری و یا خدمات پس از فروش برای رفع نیازهای مهم و جدید کارفرما

- پیمانکار و یا فروشنده:
کسی که نرم افزار را تولید کرده و یا آن را به یک مشتری به فروش می رساند، شاید سخت ترین کار همه زمان پروژه را در زمان تحویل آن داشته باشد.بایستی نیاز مشتری (مطابق با مشخصات اولیه پروژه) را در قالب محصول نهایی به صورت کامل و صحیح تحویل دهد. اغلب اشتباهی که صورت می گیرد آن است که پیمانکار بدون آن که خود از کامل بودن و صحیح بودن نرم افزار اطلاع داشته باشد، سعی می کند آن را با عجله تحویل دهد. شاید در مواردی به دلیل عدم خریدار و یا مشاور وی این روش جواب بدهد اما اغلب نه تنها باعث تحویل سریع نمی گردد، بلکه به دلیل تشخیص خطا ها در این مرحله، مدام درگیری با خریدار پیش آمده و موجب تکرار شکست ها و ناراحتی هایی می شود که حتی ممکن است باعث شود پروژه به شکست منجر شود. در این زمینه ذکر موارد زیر ضروری است:
1- انجام فرآیند های تست به صورت مجزا و تست های جامعیتی برای همه نرم افزار برای اطمینان پیدا کردن از کامل بودن و صحیح بودن نرم افزار پیش از تحویل به مشتری
2- تطابق مشخصات نرم افزار با موارد مورد تقاضا پیش از درخواست تحویل گرفتن
3- ارائه آموزش های کاربری و مدیریتی نرم افزار به صورت کامل به کاربران واجد شرایط
4- کمک به تشخیص نیازهای جدید و ارائه زمان و هزینه انجام آنها به کارفرما
5- انجام بازبینی های دوره ای در زمان تحویل برای تشخیص و رفع خطاهایی که پیدا کردن آنها توسط خریدار سخت و یا در آن فاز غیر ممکن است. برای مثال تست گزارشات جمع بندی شده و یا آماری، تهیه نسخه های پشتیبان از نرم افزار و ....
6- عدم مخفی سازی مشکلات محصول، مشکلات محصول هر چقدر زودتر تشخیص و رفع شوند، هزینه کمتری برای خود وی دارند. این اشتباه وحشتناکی است که این موارد را با تصور اینکه فعلا در موردش هزینه نکنیم تا بعد، به تعویق بیاندازید.

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

همین!