بیشتر افراد در مورد توسعه نرم افزار با تفکر خطی فکر می کنند. آنها مانند رابطه علت و معلول یا عمل و عکس العمل، از یک نقطه شروع کرده و در نقطه مشخص دیگری متوقف می شوند.
توسعه نرم افزار هیچ گاه به این آسانی نیست. مسیر شروع تا پایان مستقیم از A به B نیست. این مسیر بیشتر شبیه به این است که از نقطه A شروع می کنید، در سراشیبی یک تپه از میان گزنه های تیغ دار ادامه می گذرید، به دریا برخورد می کنید، توسط نهنگ خورده می شوید، در یک جزیره دور افتاده بیمار می شوید، 6 ماه فقط با خوردن موز زنده می مانید، بعد متوجه می شوید که در آن طرف جزیره یک اقامتگاه با امکانات فراوان وجود داشته است. در نهایت نرم افزار را دقیقا با امکاناتی که مشتری آن را درخواست کرده به او ارائه می دهید در حالی که آنها حالا متوجه شده اند که این امکانات را نمی خواهند و درخواست هایشان تغییر کرده است.
توسعه نرم افزار مانند رابطه A برابر B نیست و هیچ چیز به سادگی چیزی که ابتدا به نظر می رسد، نمی باشد. مشکلاتی که امروز پیش می آید ناشی از راه حل هایی است که روزهای گذشته ارائه شده است. به روزرسانی کد در یک قسمت باعث می شود تا در قسمتی دیگر مشکلی پیش بیاید در حالی اصلا فکر نمی کردید که رابطه ای بین آنها وجود داشته باشد.
جابجا کردن مشکلات به جای حل کردن آنها
بیشتر راه حل ها مشکلات را به جای دیگر یا زمانی در آینده منتقل می کنند. سرعت، فشار، افراد، احساسات و عدم درک باعث می شود که افراد نسبت به وضعیت واکنش نشان بدهند. واکنش باعث می شود که تفکر صحیح کنار گذاشته شده و راه حل ساده انتخاب شود که در حال حاضر به درستی کار می کند.
توسعه نرم افزار یک سیستم و یک روند خلاق است که باید در آن با تفکر همه جانبه برای مشکلات راه حل بدهید و سعی نکنید مشکلات را پنهان نمایید. تفکر ساده A با B برابر است منبع خیلی از مشکلات و دردسرها در پروژه های نرم افزاری برای مشتریان، مدیران و توسعه دهندگان نرم افزار است.
چرا A برابر با B نیست
A برابر با B نیست چون ساده کردن مشکلات اغلب باعث می شود که فقط علائم و عوارض های آن را مخفی کرده یا مشکل را به جای دیگر یا زمان دیگری انتقال می دهد.
در تفکر خطی مشکلات به این صورت دیده می شوند که مشکلی به نام رویداد A رخ داده است. این مشکل اعث شده تا رویداد B ایجاد شود. مقصر فلان توسعه دهنده است. از این روند استفاده کنید تا از رخ دادن رویداد جلوگیری شود.
تفکر ساده شبیه این موارد می تواند باشد:
مهلت انجام در حال اتمام است و به موقع کار انجام نمی شود، برنامه نویس اضافه کنیم تا توسعه سریع تر انجام شود.
یک باگ در نرم افزار پیدا شده است. آخرین توسعه دهنده ای که کد را تغییر داده مقصر است.
پروژه باید در یک سال تمام می شد در حالی که دو سال طول کشید. تحلیل تیم توسعه اشتباه بوده و حالا پول بیشتری می خواهد در حالی مقصر خودشان هستند.
توسعه سریع بدون مستندسازی برای حال حاضر عالی است اما در آینده یا در زمانی که افراد تیم را ترک می کنند، این مساله باعث بی نظمی و سردرگمی می شود. شناسایی مشکلات در یک برنامه در حال اجرا با نگاه کردن به کد، یک زندگی سرتاسر استرس برای توسعه دهندگان است.
دلایل متعددی برای مانند طراحی اشتباه باعث می شود تا اینکه یک پروژه با تاخیر روبرو شود. اما هیچگاه تاخیر یک پروژه فقط به خاطر یک دلیل نیست. در بسیاری از موارد طراحی نرم افزار در طول زمان با بروز نیازهای جدیدی به سیستم اضافه می شوند، دچار مشکل می گردد.
راه حل های ساده علائم مشکلات را رفع کرده و آنها را به جای دیگر منتقل می کنند. مثال معمول اضافه کردن توسعه دهنده برای پروژه ای که تاخیر دارد، ریشه مشکل از دست دادن مهلت ها را شناسایی نمی کند. اضافه کردن توسعه دهنده بیشتر به یک پروژه ای که دچار مشکل است ممکن است باعث شود که تاخیر بیشتر شده و هزینه ها افزایش یابد.
