نکاتی درباره تحویل دادن پروژه‌های نرم‌افزاری

تحویل دادن پروژه نرم‌افزاری ممکنه ساده یا پیچیده باشه. مهمه بتونیم حس اعتماد رو ایجاد کنیم و شفافیت لازم در مورد مراحل تحویل و بعد از تحویل وجود داشته باشه

در سراسر اینترنت کلی نوشته و مطلب پیدا می‌کنید که به شما یاد می‌دن چطور با هر زبان و تکنولوژی که نیاز دارین یک نرم‌افزار بنویسید ولی کمتر آموزشی پیدا می‌کنید که درباره تحویل دادن پروژه‌های نرم‌افزاری به شما چیزی یاد بده.

به طور کلی شرکت‌ها و تیم‌های نرم‌افزاری دو نوع پروژه نرم‌افزاری کلی به عنوان خروجی می‌تونن ارائه بدن: پکیج‌های نرم‌افزاری که معمولاً مشتری خاصی نداره و برای عموم مشتریان (چه در یک حوزه اختصاصی و چه در یک حوزه عمومی) تولید می‌شن. نمونه پکیج‌های نرم‌افزاری می‌شه مثلاً به نرم‌افزارهایی مثل AutoCad یا Photoshop‌ که در حوزه اختصاصی تولید شدند یا نرم‌افزاری مثل KMPlayer که در حوزه عمومی‌تری تولید شده اشاره کرد.

نوع دوم خروجی تیم‌ها، ارائه نرم‌افزار به سفارش مشتری هست. در این مدل شما باید خروجی کارتون رو به یک شخص یا شرکت یا سازمان تحویل بدید. موضوع این نوشته بیشتر درباره این مدل هست.

وقتی شما دارین یک پکیج نرم‌افزاری تولید می‌کنین، بر حسب روشی که برای نیازسنجی و دریافت نیازهای عموم مشتریانتون استفاده کردید یک feature set دارید که به شما می‌گه این نسخه از نرم‌افزارتون چه قابلیت‌هایی باید داشته باشه. تیم برنامه‌نویسی شما این قابلیت‌ها رو به نرم‌افزارتون اضافه می‌کنه و بالاخره بعد از یک پروسه تست‌های مختلف شما یک نسخه جدید رو release‌ می‌کنین.

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

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

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

خلاصه صحبت‌های بالا این هست که وقتی یک نرم‌افزار به سفارش مشتری تولید می‌کنید مشتری درخواست‌های متنوعی رو به شما ارائه می‌ده و آخر همه درخواست‌ها شما باید یک نرم‌افزار مطابق میل مشتری بهش تحویل بدید. حالا می‌رسیم به نکات بحث شیرین تحویل نرم‌افزار.

نکاتی درباره تحویل دادن نرم‌افزار

  • سعی کنید کلیه توافقاتی که با مشتری بر سر اجزای مختلف نرم‌افزار دارید رو مکتوب کنید. این کار هم به شما کمک می‌کنه که بدونید چی دارید تولید می‌کنید و هم به مشتری که بدونه در نهایت چی می‌خواد تحویل بگیره. وقتی یک مجموعه قابلیت مکتوب به صورت یک چک لیست داشته باشید خیلی راحت‌تر و سریع‌تر می‌تونید نرم‌افزارتون رو تحویل بدید.
  • پیرو مورد بالا، توافقات و صورتجلسات کارهایی که بر عهده شما یا مشتری هست رو به صورت ریز بنویسید. مثلاً اگر قرار هست نرم‌افزار شما بخشی به نام گزارشات داشته باشه، به جای اینکه فقط بنویسید گزارشات مدیریتی، دقیقاً نام و نوع گزارشات و فیلدهایی که در اون‌ها استفاده می‌شه رو مستند کنید. در واقع یک سند نیازمندی‌های نرم‌افزار باید تولید کنید که در موردش در نوشته دیگه‌ای توضیح خواهم داد.
  • برای کارهای خودتون و مشتری deadline‌ بگذارید. بدون تاریخ مشخص، هیچ کاری در هیچ زمانی به اتمام نخواهد رسید.
  • اگر نرم‌افزارتون امکان ورود اطلاعات داره، قبل از اینکه به مشتری تحویل بدید، چند تا داده sample وارد کنید. دقت کنید که این داده‌ها به صورت متون غیرقابل فهم نباشند (مثلاً ترتیب کلیدهای کیبورد مثل asd 123123 نباشه!) و ترجیحاً با معنی باشند. این‌طوری مشتری اطمینان پیدا می‌کنه که نرم‌افزار براش قابل استفاده هست.
  • برای اینکه موقع تحویل سرخ و سفید نشید، قبل از تحویل، حتماً کارتون رو خوب تست کنید! این مساله بدیهی به نظر می‌رسه ولی خب خیلی وقت‌ها ازش غفلت می‌شه. این مورد به خصوص اگر کار شما یک کار دیزاین در وب هست، خیلی خیلی مهم می‌شه که مثلاً سازگاری خروجی کارتون رو در مرورگرهای مختلف چک کنید.
  • بعد از نصب و تنظیم اولیه نرم‌افزار در محیط مشتری، یک صورتجلسه تحویل موقت یا تحویل اولیه امضاء کنید. به مشتری اطمینان بدید که این صورتجلسه به معنی تحویل نهایی کار نیست و فقط به این خاطر هست که مشخص بشه کار انجام و نصب شده.
  • در صورتجلسه تحویل موقت، یک مهلت مشخص به مشتری بدید تا نرم‌افزار شما رو بررسی و تایید کنه.
  • درخواست‌هایی که بعد از تحویل موقت، از طرف مشتری برای شما ارسال می‌شه رو به سه دسته تقسیم کنید: درخواست‌های (نیازمندی‌ها) جدید، باگ، سوالات. باگ‌ها رو برطرف کنید و به سوالات مشتری پاسخ بدید، اما نیازمندی‌ها و قابلیت‌های جدید درخواستی توسط مشتری رو به ارائه نسخه بعدی از نرم‌افزار (که بر حسب نوع قرارداد شما با مشتری می‌تونید به خاطرش از مشتری پول هم دریافت کنید) منوط کنید.
  • درخواست‌های بعد از تحویل موقت رو فقط تا زمان مشخصی قبول کنید. درخواست‌هایی که بعد از اون زمان ارسال می‌شوند رو برای اجرای در قالب گارانتی یا پشتیبانی (که می‌تونه قراردادهای جداگانه‌ای هم داشته باشه) برنامه‌ریزی کنید. البته باگ‌های critical از این قاعده مستثنا هستند.
  • برای رفع درخواست‌های مطرح شده بعد از تحویل موقت یک زمان‌بندی به مشتری ارائه کنید. این به معنی تحویل دو مرحله‌ای کل کار هست. با رفع موارد مطرح شده در تحویل موقت، شما عملاً وارد فاز تحویل دائم می‌شوید. مجدداً تاکید می‌کنم که درخواست‌های مشتری بعد از تحویل موقت رو فقط تا تاریخ خاصی (که در صورتجلسه تحویل موقت مشخص می‌شه) قبول کنید.
  • بعد از تحویل دادن نرم‌افزار به مشتری، صورتجلسه تحویل ایجاد و امضا کنید و حتماً‌ مشخص کنید که چه کسی مسئول backup‌گیری از نرم‌افزار و داده‌هاش هست: شما یا مشتری؟
  • به مشتری اطمینان بدید که تحویل دائم نرم‌افزار به این معنی نیست که به امان خدا رهاش می‌کنید! بلکه می‌تونه در قالب قرارداد خدمات پشتیبانی، اگر مایل باشه مجدداً از خدمات شما استفاده کنه.

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