چی می خواست چی شد
شرح تصویر
این اتفاق در خیلی از پروژه‌های توسعه سیستم‌ها رخ داده است. در ادامه توضیحی از هر یک از مراحل فوق برای کسانی که با مراحل توسعه سیستم آشنا نیستند ارائه می‌شود.
● طوری که مشتری توضیح داد:
معمولاً مشتری از آنچه واقعاً نیاز دارد آگاهی کاملی ندارد. او فکر می‌کند که آگاهی لازم را دارد. او ویژگی‌هایی را در نظر می‌گیرد که هرگز از آنها استفاده نخواهد کرد. او این ویژگی‌ها را لازم می‌داند برای اینکه می‌ترسد بعداً آنها را اضافه نکند.
● طوری که مدیر پروژه فهمید:
مسئول پروژه معمولاً برخی جزئیات کلیدی را اشتباه می‌فهمد. این اشتباهات اغلب باعث می‌شود که پروژه غیر قابل استفاده شود و خیلی از نکات آن، مبهم یا خنده‌دار شوند.
● طوری که تحلیل گر طراحی کرد:
تحلیل گر مجبور است طوری طراحی کند که اشتباهات مسئول پروژه را برطرف نماید. یک راه معمول حذف برخی از بخش‌ها و ویژگی‌هاست به گونه‌ای که بتواند با طرح فعلی کار کند.
● طوری که برنامه‌نویس نوشت:
برنامه‌نویسان معروف به نفهمیدن ویژگی‌های ضروری یک پروژه هستند. آنها موارد را دقیقاً مو به مو پیاده‌سازی می‌کنند، گاهی اوقات.
● طوری که مشاور بازرگانی توصیف کرد:
ایل و تبار بازاریابی کابوس مهندسان هستند. آنها ویژگی‌های مربوط به شیک بودن و راحتی پروژه را به مشتری القاء می‌کنند و هیچ توجهی به شرایط واقعی و عملی ندارند.
● طوری که پروژه مستند شد:
مستند سازی چیزی است که بعداً به فکر آن می‌افتند یا اینکه هرگز انجام نمی‌شود.
● چیزی که اجرا شد:
گاهی اوقات ماهها روی ویژگی‌های خاصی کار می‌کنیم که متوجه شویم این ویژگی‌ها به مشتری ارائه نشده‌اند زیرا آنها در عمل کار نکردند، مجری نفهمیده که آن ویژگی‌ها چگونه کار می‌کنند یا کسی دیگری تصمیم گرفته است که آنها انجام نشوند.
● قیمتی که به مشتری اعلام شد:
چی فکر کردی! نرم‌افزار گران است. هزینه تمام اشتباهات و نقایص باید در پروژه منظور شود.
● طوری که پشتیبانی شد:
«به نظر تو اگر این ویژگی را اضافه کنیم باعث نمی‌شود که مشتری تقاضای پشتیبانی فنی کند». فکر می‌کنم لازم باشد این قسمت را حذف کنیم. سرانجام پروژه با ارائه ویژگی‌های اولیه پایان می‌یابد.
● چیزی که مشتری واقعاً نیاز داشت:
خیلی آسان تر بود اگر می‌توانستیم نیاز را به درستی تشخیص دهیم. اما هرگز این کار را انجام نمی‌دهیم . . .
