شرح تصوير:

اين اتفاق در خيلي از پروژه‌هاي توسعه سيستم‌ها رخ داده است. در ادامه توضيحي از هر يك از مراحل فوق براي كساني كه با مراحل توسعه سيستم آشنا نيستند ارائه مي‌شود.

● طوري كه مشتري توضيح داد:

معمولاً مشتري از آنچه واقعاً نياز دارد آگاهي كاملي ندارد. او فكر مي‌كند كه آگاهي لازم را دارد. او ويژگي‌هايي را در نظر مي‌گيرد كه هرگز از آنها استفاده نخواهد كرد. او اين ويژگي‌ها را لازم مي‌داند براي اينكه مي‌ترسد بعداً آنها را اضافه نكند.

● طوري كه مدير پروژه فهميد:

مسئول پروژه معمولاً برخي جزئيات كليدي را اشتباه مي‌فهمد. اين اشتباهات اغلب باعث مي‌شود كه پروژه غير قابل استفاده شود و خيلي از نكات آن، مبهم يا خنده‌دار شوند.

● طوري كه تحليل گر طراحي كرد:

تحليل گر مجبور است طوري طراحي كند كه اشتباهات مسئول پروژه را برطرف نمايد. يك راه معمول حذف برخي از بخش‌ها و ويژگي‌هاست به گونه‌اي كه بتواند با طرح فعلي كار كند.

● طوري كه برنامه‌نويس نوشت:

برنامه‌نويسان معروف به نفهميدن ويژگي‌هاي ضروري يك پروژه هستند. آنها موارد را دقيقاً مو به مو پياده‌سازي مي‌كنند، گاهي اوقات.

● طوري كه مشاور بازرگاني توصيف كرد:

ايل و تبار بازاريابي كابوس مهندسان هستند. آنها ويژگي‌هاي مربوط به شيك بودن و راحتي پروژه را به مشتري القاء مي‌كنند و هيچ توجهي به شرايط واقعي و عملي ندارند.

● طوري كه پروژه مستند شد:

مستند سازي چيزي است كه بعداً به فكر آن مي‌افتند يا اينكه هرگز انجام نمي‌شود.

● چيزي كه اجرا شد:

گاهي اوقات ماهها روي ويژگي‌هاي خاصي كار مي‌كنيم كه متوجه شويم اين ويژگي‌ها به مشتري ارائه نشده‌اند زيرا آنها در عمل كار نكردند، مجري نفهميده كه آن ويژگي‌ها چگونه كار مي‌كنند يا كسي ديگري تصميم گرفته است كه آنها انجام نشوند.

● قيمتي كه به مشتري اعلام شد:

چي فكر كردي! نرم‌افزار گران است. هزينه تمام اشتباهات و نقايص بايد در پروژه منظور شود.

● طوري كه پشتيباني شد:

«به نظر تو اگر اين ويژگي را اضافه كنيم باعث نمي‌شود كه مشتري تقاضاي پشتيباني فني كند». فكر مي‌كنم لازم باشد اين قسمت را حذف كنيم. سرانجام پروژه با ارائه ويژگي‌هاي اوليه پايان مي‌يابد.

● چيزي كه مشتري واقعاً نياز داشت:

خيلي آسان تر بود اگر مي‌توانستيم نياز را به درستي تشخيص دهيم. اما هرگز اين كار را انجام نمي‌دهيم...

برگرفته از سایت MgtSolution.Com