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