تأسیس ۲۰۰۸ · نسخهٔ دیجیتال · 19 ژوئن 2026

SMB IT Journal

منبع فناوری اطلاعات برای کسب‌وکارهای کوچک

فارسی
معماری

حالا چه کار کنم؟ برنامه‌ریزی برای تغییرات طراحی

اغلب با موقعیت‌هایی روبرو می‌شوم که باید درباره طراحی سیستم‌ها، برنامه‌ها و معماری‌ها با افراد صحبت کنم. و بسیاری از اوقات این بحث خیلی دیر اتفاق می‌افتد و طرح‌ها یا کاملاً پیاده‌سازی شده‌اند یا به صورت ناقص. این می‌تواند بسیار ناامیدکننده باشد اگر طرح در حال اجرا برای وضعیت موجود ایده‌آل تشخیص داده نشود.

احساس ناامیدی که در چنین موقعیتی ایجاد می‌شود را درک می‌کنم، اما این چیزی است که ما در حوزه IT باید به طور منظم با آن روبرو شویم و مدیریت سازنده این واکنش یک مهارت کلیدی IT است. ما باید هم از نظر فنی و هم از نظر احساسی بر این موقعیت تسلط پیدا کنیم. نباید از آن فلج شویم؛ این یک موقعیت طبیعی است که هر متخصص IT به طور منظم با آن مواجه می‌شود. نباید دلسردکننده یا فلج‌کننده باشد، اما کاملاً قابل درک است که می‌تواند اینطور احساس شود.

یک دلیل اصلی که این موقعیت را این‌قدر اغلب تجربه می‌کنیم این است که IT یک حوزه گسترده با متغیرهای فراوانی است که در هر موقعیتی باید در نظر گرفته شوند. همچنین یک حوزه بسیار خلاقانه است که رویکردهای متعدد و قابل قبول برای هر مسئله‌ای وجود دارد. اینکه حتی یک گزینه «بهترین» واحد وجود داشته باشد نادر است. معمولاً گزینه‌های رقابتی بسیاری وجود دارند. گاهی اوقات این‌ها بسیار به هم نزدیکند، گاهی این گزینه‌ها به شدت متفاوتند و مقایسه معنادار آن‌ها را بسیار دشوار می‌کنند.

دلیل کلیدی دیگر این است که عوامل تغییر می‌کنند. این می‌تواند به این دلیل باشد که تکنیک‌ها یا اطلاعات جدیدی آشکار می‌شوند، محصولات جدید عرضه می‌شوند، محصولات به‌روزرسانی می‌شوند، قیمت‌ها تغییر می‌کنند یا نیازهای کسب‌وکار نزدیک به یا حتی در طول فرآیندهای تصمیم‌گیری و طراحی تغییر می‌کنند. این نرخ تغییر چیزی نیست که ما، به عنوان متخصصان IT، امیدوار باشیم بتوانیم کنترل کنیم. این چیزی است که باید بپذیریم و با آن به بهترین شکل ممکن کنار بیاییم.

چیز دیگری که اغلب نادیده گرفته می‌شود این است که راه‌حلی که در زمان تصمیم‌گیری ایده‌آل بوده، اگر همان تصمیم امروز گرفته می‌شد، ممکن است ایده‌آل نباشد. این به هیچ وجه نقصی در طراحی اصلی نیست، اما دیده‌ام که بسیاری از افراد به آن به گونه‌ای واکنش نشان می‌دهند که گویی نقص است. رایج‌ترین سناریویی که در آن این رفتار را می‌بینم، بیزاری از استفاده از RAID 5 در طراحی ذخیره‌سازی مدرن است، در حالی که RAID 6 و RAID 10 به دلایل خوبی جایگزین‌های محبوب هستند. اما این بیزاری از RAID 5 که از حدود ۲۰۰۹ رایج شده، همیشه وجود نداشت و از اواسط دهه ۱۹۹۰ تا تقریباً پایان دهه ۲۰۰۰، RAID 5 نه تنها قابل استفاده بود، بلکه اغلب بهترین راه‌حل برای نیازهای فنی و تجاری بود. با این حال بسیاری از مردم RAID 5 را به درستی به عنوان گزینه‌ای ضعیف امروز می‌بینند اما این بیزاری جدید را به سیستم‌هایی که مدت‌ها پیش طراحی و پیاده‌سازی شده‌اند اعمال می‌کنند. این منطقی نیست و صرفاً یک واکنش احساسی است.

بارها از من پرسیده شده که پس از اتخاذ تصمیمات طراحی کمتر از ایده‌آل چه باید کرد. «حالا چه کار کنم؟»

یادگیری اینکه وقتی کمال دیگر گزینه‌ای نیست (انگار که واقعاً بود، تمام IT درباره مصالحه است) چه باید کرد، یک مهارت بسیار مهم است. اولین چیزهایی که باید با آن‌ها مقابله کنیم مشکلات احساسی هستند زیرا این‌ها همه چیز دیگری را تضعیف می‌کنند. باید تلاش کنیم به عقب قدم بگذاریم، وضعیت را بپذیریم و منطقی عمل کنیم. آخرین چیزی که می‌خواهیم این است که یک وضعیت غیرایده‌آل را بدتر کنیم.

پذیرش اینکه هیچ طراحی کامل نیست، هیچ راهی برای همیشه درست کردن همه چیز وجود ندارد و مقابله با این موضوع تنها بخشی از کار در IT است، اولین قدم است. قدمی به عقب بردارید، نفس عمیق بکشید. اینقدر بد نیست. این یک موقعیت منحصر به فرد نیست. هر متخصص IT که طراحی می‌کند دائماً با این موضوع روبرو است.

قدم بعدی ارزیابی وضعیت است. الان کجا هستیم؟ در بسیاری از موارد پیاده‌سازی انجام شده و کاری برای انجام دادن نیست. وضعیت ایده‌آل نیست، اما آیا بد است؟ اغلب بزرگترین اشتباهی که می‌بینم افراد با آن مواجه می‌شوند در یک طرح قبلاً پیاده‌سازی شده این است که هزینه‌اش بیش از حد بوده - معمولاً راه‌حل‌های «بهتر» بهتر نیستند چون سریع‌تر یا قابل اطمینان‌تر هستند بلکه بهتر هستند چون ارزان‌تر، آسان‌تر یا سریع‌تر برای پیاده‌سازی بودند.

مواردی وجود دارد که یک طرح پیاده‌سازی شده به اندازه کافی نیازهای تجاری اعلام شده را برآورده نمی‌کند. خوشبختانه این کمتر رایج است. در این صورت باید تغییراتی ایجاد کنیم تا نیازهای تجاری خود را برآورده کنیم. این ممکن است پرهزینه یا پیچیده باشد. اما اوضاع ممکن است به اندازه‌ای که به نظر می‌رسد بد نباشد.

اولین قدم پس از اینکه در موقعیتی هستیم که راه‌حلی پیاده‌سازی کرده‌ایم که نیازهای تجاری را برآورده نمی‌کند، ارزیابی مجدد نیازهای تجاری است. این به معنای تحریف نیازها برای تطبیق با آنچه سیستم ما می‌تواند انجام دهد نیست، اصلاً. اما زمان خوبی است تا برگردیم و ببینیم آیا نیازهای اصلی اعلام شده واقعاً معتبر هستند یا اینکه به اندازه کافی بررسی نشده‌اند.

قدم دوم ایجاد یک خط پایه فناوری جدید است. این یک قدم بسیار مهم برای جلوگیری از افتادن IT در دام مغالطه هزینه‌های از دست رفته است. بسیار رایج است که هر کسی، و این منحصر به IT نیست، به زمان و پول صرف شده برای یک پروژه نگاه کند و فرض کند که ادامه دادن در مسیر اصلی، هر چقدر هم که احمقانه باشد، راه درست است زیرا منابع زیادی در آن مسیر صرف شده است. اما این البته منطقی نیست؛ چگونگی رسیدن به وضعیت کنونی بی‌ربط است. آنچه مرتبط است ارزیابی نیازهای فعلی بخش و شرکت و بررسی راه‌حل‌ها، فناوری‌ها و منابع موجود است.

یک مثال خوب از مغالطه هزینه‌های از دست رفته در بازی شطرنج است. با هر حرکت مهم است که تمام حرکت‌های موجود، خطرات و استراتژی‌ها را دوباره ارزیابی کنیم زیرا حرکت‌هایی که برای رسیدن به وضعیت کنونی استفاده شده‌اند هیچ تأثیری بر اینکه کدام حرکت‌ها در آینده منطقی هستند ندارند.

این همان چیزی است که ما باید در IT انجام دهیم. وضعیت کنونی ما، وضعیت کنونی ماست. برای برنامه‌ریزی استراتژیک مهم نیست که چه اتفاقی افتاده تا به این حالت رسیدیم. ما فقط به آن تصمیمات و هزینه‌ها در فرآیند بررسی پس از رویداد اهمیت می‌دهیم تا بفهمیم تصمیم‌گیری کجا ممکن است شکست خورده باشد.

متأسفانه باید فرآیندهای برنامه‌ریزی خود را دوباره شروع کنیم اما این بار با، فرض می‌کنیم، چیزهای بیشتری برای کار کردن. اما این اجتناب‌ناپذیر است. در بدترین موارد، بودجه‌ها دیگر در دسترس نیستند و منابعی برای رفع طرح معیوب و دستیابی به اهداف تجاری لازم وجود ندارد. مصالحه گاهی ضروری است.

پس از اینکه به وضعیتی رسیدیم که کمبودهای خود را برطرف کرده‌ایم، چه با پذیرش اینکه بیش از حد هزینه کرده‌ایم، کمتر از انتظار عمل کرده‌ایم یا تنظیم کرده‌ایم تا نیازها را برآورده کنیم، فرصتی داریم تا به فرآیندهای تصمیم‌گیری خود برگردیم و آن‌ها را بررسی کنیم. با انجام این کار امیدواریم که به عنوان افراد رشد کنیم و، در صورت امکان، در سطح سازمانی از اشتباهات خود بیاموزیم.

آخرین قدمی که می‌توانیم انجام دهیم شروع فرآیند تصمیم‌گیری برای طراحی جایگزینی برای پیاده‌سازی فعلی در اسرع وقت، پس از اتمام بررسی فرآیند تصمیم‌گیری، است. این لزوماً به این معنی نیست که باید قصد داشته باشیم در آینده نزدیک پول خرج کنیم یا طرح‌های خود را تغییر دهیم. اصلاً. اما با بسیار فعال بودن در تصمیم‌گیری می‌توانیم سعی کنیم از مشکلات گذشته اجتناب کنیم.

با فرآیندهای خوب و منطقی و درک خوب از مراحلی که در مورد طراحی یا پیاده‌سازی سیستم‌های کمتر از ایده‌آل باید انجام شوند، می‌توانیم از اشتباهات بازیابی کنیم و نه تنها در اکثر موارد در کوتاه مدت از آن‌ها بازیابی کنیم بلکه می‌توانیم سازمان را از همان اشتباهات در آینده محافظت کنیم.

برچسب‌خوردهdesign planning technical debt

آگهی

SMB IT Journal — the IT resource for small business