قبل از ورود به بحث اصلي بگذاريد سه مثال به عنوان نمونه ذکر کنم:
مثال1: از شرکتي خصوصي، اوايل سال 82 براي خريد سيستم تلفن گويا با ما تماس گرفتند.جلساتي برگزار شد و در آن زمان خاص پروژه به مرز تاييد نهايي نزديک شد و پيش نويس قرارداد براي آنها ارسال گرديد تا قرارداد منعقد گردد. از اولين تماس تا آخرين تماس در اين بين چيزي در حدود 2 ماه زمان طول کشيد و در جلسات متعدد طرح اصلاح گرديد تا در نهايت طرح نهايي تصويب شد. از طرف شرکت خريدار هم ضرب الاجل تعيين شد که هر چه سريعتر کار انجام شود و با سرعت پيش نويس قرارداد بفرستيد تا کار زودتر اجرا شود. اما...... بعد از ارسال قرارداد مدت زمان طولاني سپري شد و خبري از آنها نشد! تماس هاي مکرر هم نتيجه نداد. تا اينکه چهار، پنج ماه بعد مجددا تماس گرفتند که تشريف بياريد براي جلسه فني!..... جلسه فني!!؟؟ بعد از اينهمه زمان باز هم جلسه فني!؟ ما هم گفتيم چشم. رفتيم. جلسه خوبي بود. معلوم شد تازه بعد از اينهمه وقت يک نفر ديگر هم بايد نظر بدهد. باز هم چند ماه گذشت. تااينکه روزي فکسي دريافت کرديم مبني بر دعوت به شرکت در مناقصه! بعد از اينهمه وقت تازه دعوت به شرکت در مناقصه. ايندفعه تصميم گرفتيم که در مناقصه شرکت نکنيم. اما به اصرار يکي از همکاران، فرمها را پرکرده ارسال کرديم. بازهم هيچ خبري نشد تا اسفند ماه 83 که از طرف آن شرکت آمدند براي بازديد . مجددا تمامي بحث هايي که قبلا شده بود مطرح شد و باز هم پيشنهاد ما از لحاظ فني تاييد شد. اما تا امروز هم هنوز خبري مبني بر قبول يا رد پيشنهاد ما دريافت نشده است!

مثال2: در اواخر سال 81 دعوت شديم به اجراي پروژه براي يکي از وزارتخانه هاي دولتي. بعد از جلسات متعدد در اواخر اسفند ماه به ما گفتند که پروژه را شروع کنيد و هر چه سريعتر پروژه را انجام دهيد. ما هم نيروها را به پروژه اختصاص داده و طراحي اوليه آن را انجام داديم. اما مديران اين وزارتخانه به دليل ترافيک آخر سال به ما گفتند که فعلا دست نگه داريد تا آغاز سال جديد. از 5 فروردين شروع کنيد. ما هم صبح روز 5 فروردين به آنجا مراجعه کرديم. نبودند! تا اينکه بعد از 15 فروردين آمدند. به ما گفتند فعلا صبر کنيد! مشکلي پيش آمده! حدود 5 الي 6 ماه مدام با آنها در ارتباط بوديم اما مي گفتند که شما پروژه را انجام مي دهيد اما فعلا صبر کنيد. تا اينکه در تماس هاي آخر به ما گفتند ببخشيد! خدمات کامپيوتر خود ما با ديدن طرح شما گفته است که خودش آن را مي سازد! (اين مشکل يکي از مشکلات ارائه پيشنهاد براي پروژه است (proposal) در آينده در مورد آفات ارائه پيشنهاد خواهم نوشت). امروز که شايد بيش از 2 سال و اندي از آن جريان مي گذرد هنوز هم آن پروژه اجرا نشده است!
مثال3: انتهاي سال 83 ، پروژه اي گرفتيم براي ايجاد يک سيستم خاص تلفن گويا. به کارفرما قول داديم که به لحاظ عجله اي که در بهره برداري از سيستم داشتند يک هفته اي کار را تحويل دهيم. با همت بچه ها، کار در زمان مشخص به پايان رسيد. اما نتوانسيتم بر خلاف انتظار در روزهاي پاياني سال نمايندگان کارفرما را پيدا کنيم. با شروع سال هم هنوز موفق نشده ايم پروژه را تحويل دهيم!
اين سه مورد و موارد بسياري نظير اين که شايد براي هر کس که دستي در توسعه نرم افزار در داخل کشور داشته باشد امري طبيعي و عادي به شمار مي رود و در طي کار خود بارها با اين مشکل مواجه شده است، مواردي که زمانبندي از جانب پيمانکار يا مجري رعايت شده است، اما کارفرما در طي يک برنامه مشخص پروژه را تحويل نمي گيرد و يا زمان آنقدر طولاني مي کند که اجراي پروژه مقرون به صرفه نباشد. مواري لزوم ارائه يک زمانبندي براي اجرا از طرف کارفرماي يک پروژه نرم افزاري را بيش از پيش الزامي مي کند.
بگذاريد از زاويه ديد ديگري به اين مساله نگاهي بياندازيم. معمولا در هنگام ارائه پيشنهاد کارفرما منتظر دريافت يک زمانبندي براي اجراي يک پروژه از طرف پيشنهاد دهنده مي ماند. در هنگام عقد قرارداد نيز نه تنها در متن قرارداد بلکه معمولا در پيوست ها نيز زمانبندي اجراي پروژه از طرف کارفرما ارائه شده و تبعيت از اين زمانبندي جزء تعهدات وي محسوب مي شود. هرچند اين زمانبندي در بسياري موارد مشمول تسامح و تساهل مي شود و به درستي رعايت نمي شود اما با اين وجود به عنوان يک ابزار کنترلي (بهتر بگويم ابزار فشار) به پيمانکار استفاده مي شود. در حاليکه براي يک کارفرماي سخت گير، چيزي جذاب تر از تحت فشار گذاردن مجري نيست!
در لزوم ارائه اين زمانبندي از جانب پيمانکار و تعهد داشتن به آن شک نداريم. امري است لازم و ضروري و بايستي با استفاده از متريک هاي تخمين مناسب، زمانبندي نزديک به واقعيت برآورد شده و سپس اجرا تحت آن زمانبندي کنترل شود. اما بايد بدانيم که بايستي يک زمانبندي نيز از جانب کارفرما براي اجراي پروژه تعريف شود.
اين زمانبندي که مي تواند توسط خود کارفرما و يا مشاور فنآوري اطلاعات و ارتباط وي تهيه شود به جاي پرداختن به زمانهاي اجراي پروژه، زمانبندي آغاز پروژه، تهيه فهرست نيازها و برگزاري مناقصه (يا هر مکانيسم ديگر) و در نهايت انتخاب مجري يا پيمانکار در ابتداي پروژه و سپس دريافت نسخه هاي مختلف سيستم از مجري در زمانهاي پيش بيني شده در زمانبندي وي و ارائه نظر در مورد آن در زمان مقرر و در نهايت زمانبندي تحويل نهايي پروژه و تسويه حساب با پيمانکار و از همه مهم تر زمانبندي پشتيباني نرم افزار را محور بحث قرار مي دهد.
به عبارت ديگر، کارفرما بايد بداند که براي تهيه يک سيستم نرم افزاري چه گامهايي بايد پيموده شود و براي همه اين گامها زمان تعيين کند تا بتواند در زمان مقرر، ضمن تهيه اين سيستم به تعهدات خود نيز عمل کرده باشد. همانگونه که به موقع تحويل دادن يک پروژه از طرف پيمانکار کاري پسنديده است و به نفع وي مي باشد، تحويل گرفتن به موقع يک پروژه نيز ، کارفرما را منتفع مي سازد.
ارائه اين نوع زمانبندي با نحوه تنظيم زمانبندي پروژه متفاوت است و بايستي موارد ديگري را به عنوان خطرات و يا ريسک هاي نرم افزاري در نظر گرفت و در مديريت و تحليل اين خطر ها (Risk Analysis) به آنها پرداخت.مواردي نظير نياز واقعي به داشتن چنين سيستمي ، بودجه و اعتبارات ، گلوگاههاي اداري که با بروکراسي زياد باعث اتلاف وقت مي شوند و ..... تهيه اين زمانبندي امري است که شايد به تجربه زيادي نياز دارد.
يکي از راه حل هاي رسيدن به چنين زمانبندي هايي اجراي طرح هاي راهبردي فنآوري اطلاعات و يا طرح هاي جامع فنآوري اطلاعات و ارتباطات (IT Master Plan) که پيشتر در مورد آنها نوشته بودم مي باشد. با داشتن يک ICT Master Plan مي توان مشخص کرد که چه پروژه را در چه زماني بايستي آغاز کرد و در چه زماني بايد به نتيجه رسيد. با تقسيم اين زمان هاي کلي مي توان زمانبندي جزئي اجراي يک پروژه را بدست آورد.
مجددا متذکر مي شود ارائه اين زمانبندي و حرکت طبق آن، ضمن ايجاد آسايش و امنيت براي مجريان و پيمانکاران، باعث مي شود ضمن بهره گيري مناسب از نيروي انساني و منابع کارفرما ، در نهايت محصول در زماني که واقعا به آن نياز دارد در سيستم عملياتي شود.
همين!