طراحی شبکه بخش 2: طراحی برای موفقیت کسب‌وکار

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

موفقیت کسب‌وکار (Business Success)

این بخش جنبه‌های اصلی مرتبط با نیازها و جهت‌گیری‌های کسب‌وکار را پوشش می‌دهد مواردی که به‌صورت فردی یا جمعی می‌توانند به‌طور مستقیم یا غیرمستقیم بر تصمیمات طراحی شبکه تأثیر بگذارند. بهترین نقطه‌ی شروع برای درک نیازها و الزامات کسب‌وکار، نگاه کردن به تصویر کلان (big picture) از یک شرکت یا سازمان و درک اولویت‌های تجاری، محرک‌های کسب‌وکار (business drivers) و نتایج تجاری (business outcomes) آن است. این موضوع به طراحان شبکه کمک می‌کند تا طراحی خود را هدایت کرده و موفقیت کسب‌وکار را تضمین کنند.

با این حال، بسته به نوع کسب‌وکار و متغیرهای متعدد دیگر، اهداف و نیازهای تجاری متفاوتی وجود دارد. همان‌طور که در شکل پایین آمده، در یک رویکرد از بالا به پایین (Top-Down Design Approach)، تقریباً همیشه الزامات، محدودیت‌ها و محرک‌ها (drivers) در لایه‌های بالاتر (مانند الزامات تجاری و برنامه‌ای) هستند که نیازها و جهت‌گیری‌های لایه‌های پایین‌تر را تعیین می‌کنند.

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

اولویت‌های تجاری (Business Priorities)

هر کسب‌وکاری مجموعه‌ای از اولویت‌های تجاری (business priorities) دارد که معمولاً بر پایه‌ی استراتژی‌های اتخاذشده برای دستیابی به اهداف تعیین می‌شوند. این اولویت‌ها می‌توانند بر برنامه‌ریزی و طراحی زیرساخت شبکه‌ی IT تأثیر بگذارند. بنابراین، طراحان شبکه باید از این اولویت‌ها آگاه باشند تا بتوانند طراحی خود را با آن‌ها همسو کنند و از این طریق ارزش تجاری (business value) ارائه دهند.

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

نمونه‌ای از اولویت تجاری می‌تواند امنیت (Security) باشد. اصطلاحات مختلفی می‌توانند برای این اولویت به کار روند، مانند Zero Trust Architecture، Cybersecurity Modernization یا چارچوب‌های مدیریت ریسک. مهم نیست اولویت تجاری چیست؛ هدف همیشه حفظ امنیت و تمامیت داده‌هاست. اگر امنیت به خطر بیفتد، کسب‌وکار نیز از بین می‌رود.

محرک‌های تجاری (Business Drivers)

اکنون که اولویت‌های تجاری را می‌دانیم، باید محدودیت‌ها و چالش‌هایی را که برای کسب‌وکار وجود دارد، شناسایی کنیم. به این‌ها محرک‌های تجاری (business drivers) گفته می‌شود. محرک‌های تجاری عواملی هستند که کسب‌وکار را مجبور به اقدام می‌کنند یعنی چرایی انجام یک کار. به‌عنوان مثال، ممکن است الزام به رعایت استانداردهای انطباقی (compliance standards) مانند HIPAA یا PCI DSS یک محرک تجاری باشد. این الزام کاملاً با اولویت امنیت مطابقت دارد، زیرا شرکت باید برای رعایت چنین استانداردهایی اقدام کند تا بتواند جریمه‌ها را کاهش داده یا از تعطیلی جلوگیری کند.
در این حالت، محرک تجاری می‌تواند به شکل «الزام به پیروی از استاندارد HIPAA» بیان شود.

HIPAA قانونی در آمریکا است که از حریم خصوصی و امنیت اطلاعات پزشکی افراد محافظت می‌کند.

نتایج تجاری (Business Outcomes)

نتیجه‌ی تجاری (business outcome) به معنای نتیجه‌ی نهایی است مانند صرفه‌جویی در هزینه، تنوع‌بخشی به کسب‌وکار، افزایش درآمد یا رفع یک نیاز خاص. در اصل، یک نتیجه‌ی تجاری همان هدفی است که کسب‌وکار در پی دستیابی به آن است.

برای مثال، در ادامه‌ی مثال قبلی، اگر محرک تجاری عبارت باشد از «الزام به رعایت HIPAA»، نتیجه‌ی تجاری می‌تواند به شکل «حفظ صحیح انطباق با HIPAA به‌منظور ادامه‌ی فعالیت سازمان» بیان شود.

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

قابلیت‌های تجاری (Business Capabilities)

پیش از آنکه وارد مسیر «راه‌حل‌یابی (solutionizing)» شویم کاری که بسیاری از مهندسان معمولاً زودتر از موعد انجام می‌دهند باید بدانیم که قابلیت‌های تجاری (business capabilities) چیست و چگونه در طراحی شبکه اعمال می‌شود. قابلیت‌های تجاری خودِ راه‌حل نیستند، بلکه چیزی هستند که از راه‌حل‌ها به‌دست می‌آید.

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

برای مثال، session-based security نمونه‌ای عالی از قابلیتی است که ممکن است کسب‌وکار برای رعایت استانداردهای انطباقی به آن نیاز داشته باشد. یک راه‌حل vendor-agnostic NAC (Network Access Control) می‌تواند این قابلیت را فراهم کند.

نمونه‌ای دیگر، Cisco Identity Services Engine (ISE) است که قابلیت session-based security را فراهم می‌کند و در واقع چندین قابلیت دیگر نیز علاوه بر آن ارائه می‌دهد.

قابلیت‌های تجاری به‌طور مستقیم با نتایج تجاری در ارتباط‌اند. به‌عنوان یک طراح شبکه باید بدانید که ممکن است چندین قابلیت با یک نتیجه مرتبط باشند و همچنین چندین نتیجه به یک قابلیت مرتبط شوند این حالت طبیعی و مورد انتظار است.

جدول ۲-۲ — نگاشت اولویت‌ها، محرک‌ها، نتایج و قابلیت‌های تجاری

اولویت‌ها (Priorities)	محرک‌ها (Drivers)	نتایج (Outcomes)	قابلیت‌ها (Capabilities)
Priority #1	Driver #1	Outcome #1	Capability #1, Capability #2
Priority #2	Driver #3	Outcome #2	Capability #1
Priority #3	Driver #4	Outcome #3	Capability #3, Capability #4
Priority #4	Driver #4	Outcome #4	Capability #4

تداوم کسب‌وکار (Business Continuity)

تداوم کسب‌وکار (Business Continuity – BC) به توانایی یک سازمان برای ادامه‌ی فعالیت‌های تجاری (به‌صورت معمولی) پس از بروز یک وقفه اشاره دارد مثلاً خرابی سیستم یا بلایای طبیعی مانند آتش‌سوزی در مرکز داده. بنابراین، کسب‌وکارها به مکانیزم‌ها یا روش‌هایی نیاز دارند تا بتوانند سطح تاب‌آوری (resiliency) خود را برای واکنش و بازیابی از چنین رویدادهایی تقویت کنند.

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

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

به‌طور مشابه، مکان بروز وقفه نیز بر میزان اهمیت و طراحی تأثیر می‌گذارد. برای مثال، قطعی در یکی از فروشگاه‌های کوچک در منطقه‌ای دورافتاده اهمیت کمتری دارد نسبت به قطعی در یکی از فروشگاه‌های بزرگ در یک شهر اصلی. به بیان دیگر، ملاحظات BC باید بر اساس ارزیابی ریسک (risk assessment) و تأثیر آن بر کسب‌وکار انجام شود، و این موضوع یکی از محرک‌های اصلی برای استفاده از فناوری‌ها و اصول طراحی شبکه با هدف دستیابی به اهداف تجاری است.

هدف نقطه بازیابی (Recovery Point Objective – RPO)

میزان داده‌ای که ممکن است در هنگام یک وقفه از دست برود تا پیش از بازیابی کسب‌وکار قابل قبول باشد را Recovery Point Objective (RPO) می‌گویند. آسیب ناشی از از دست رفتن داده می‌تواند مالی یا اعتباری باشد.

به‌عنوان مثال، اگر زیرساخت ابری (cloud-based infrastructure) برای مدت ۳۰ دقیقه قطع شود، تأثیر آن بر اعتبار برند بسیار بیشتر از تأثیر مالی خواهد بود. در مقابل، اگر یک شرکت مالی بزرگ تنها در یک مکان دچار قطعی شود، احتمالاً تأثیر اعتباری بیشتری نسبت به مالی خواهد داشت.

مقدار داده‌ی قابل‌پذیرش برای از دست رفتن در RPO معمولاً به‌صورت زمانی مشخص بیان می‌شود بر اساس آخرین نسخه‌ی پشتیبان (backup) که گرفته شده. برای مثال، اگر RPO برابر ۱۰ دقیقه باشد، یعنی شرکت می‌تواند حداکثر ۱۰ دقیقه داده را از دست بدهد و همچنان در حالت عملیاتی باقی بماند.

هدف زمان بازیابی (Recovery Time Objective – RTO)

RTO به مدت زمانی اشاره دارد که سیستم، شبکه یا منبع می‌تواند از کار افتاده باقی بماند بدون آنکه آسیب جدی به کسب‌وکار وارد شود. RTO همچنین شامل مدت زمانی است که برای بازیابی سیستم لازم است.

به‌عنوان نمونه، اگر یک شرکت ابری دچار وقفه‌ای ۱۰ دقیقه‌ای شود و RTO برابر ۲۰ دقیقه داشته باشد، شرکت می‌تواند در بازه‌ی تعریف‌شده سرویس را بازیابی کند. اما اگر همان شرکت در زمان اوج کاری (peak business demand) دچار قطعی ۲ ساعته شود، زیان وارده نمایی (exponential) خواهد بود.

انعطاف‌پذیری برای پشتیبانی از روندهای استراتژیک کسب‌وکار (Elasticity to Support the Strategic Business Trends)

Elasticity به میزان انعطاف‌پذیری یک طراحی اشاره دارد تا بتواند به تغییرات کسب‌وکار پاسخ دهد. تغییر در این زمینه می‌تواند به معنای رشد طبیعی (organic growth)، کاهش کسب‌وکار، ادغام (merger) یا تملک (acquisition) باشد.

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

برای افزایش انعطاف، می‌توان ماژول هسته‌ای (Core Module) را اضافه کرد تا طراحی Modular شود. در این صورت، اضافه یا حذف مکان‌ها یا ماژول‌ها بدون تأثیر بر سایر بخش‌ها انجام می‌شود. به این ترتیب، طراحی به‌اندازه‌ی کافی منعطف خواهد بود تا از اولویت‌ها، محرک‌ها و نتایج تجاری پشتیبانی کند.

فناوری اطلاعات به‌عنوان محرک نوآوری کسب‌وکار (IT as a “Business Innovation” Enabler)

در بازار امروزی، بسیاری از سازمان‌ها درک کرده‌اند که فناوری‌های IT می‌توانند باعث نوآوری و افزایش بهره‌وری مشتریان شوند. زمانی‌که فناوری به‌عنوان یک Business Enabler عمل کند، سازمان را قادر می‌سازد تا رقابت‌پذیری خود را افزایش دهد و رضایت مشتری را بهبود بخشد.

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

IT به‌عنوان «خدمت جدید» (IT as a “New” Utility)

در دهه‌ی گذشته، IT و به‌ویژه شبکه، به چیزی شبیه خدمات عمومی (Utility) مانند برق یا آب تبدیل شده است. این یعنی کاربران انتظار دارند دسترسی به اینترنت و اپلیکیشن‌های کسب‌وکار همیشه فراهم باشد، درست مثل وقتی که لامپ را روشن می‌کنیم.

به همین دلیل، طراحان شبکه باید مفهوم نیازهای نانوشته (Unstated Requirements) را درک کنند، نیازهایی که فرض بر این است همیشه برآورده می‌شوند. جدول ۲-۳ مقایسه‌ای از ریسک، پاداش و هزینه‌ی طراحی در گزینه‌های مختلف فراهمی (availability) شبکه ارائه می‌دهد.

جدول ۲-۳ — تحلیل ریسک تجاری در برابر پاداش و هزینه‌ی طراحی

تصمیم طراحی (Design Decision)	هزینه‌ی مرتبط (Associated Cost)	پیچیدگی طراحی (Design Complexity)	ریسک تجاری (Business Risk)	پاداش تجاری (Business Reward)
Single points of failure	کم؛ بدون هزینه‌ی اضافی برای Redundancy	کم	بسیار زیاد؛ احتمال وقوع outage بالا و تأثیر مستقیم بر درآمد و اعتبار	کم؛ صرفه‌جویی اولیه در هزینه
No single points of failure	متوسط؛ هزینه برای اجزای افزونه (redundant components) افزایش می‌یابد	زیاد	کم؛ طراحی طوری است که با وجود خرابی جزئی، کسب‌وکار همچنان کار کند	زیاد؛ هزینه‌ی اولیه بالاتر ولی تداوم عملکرد و درآمد
No dual points of failure	زیاد؛ نیاز به هزینه‌ی اولیه‌ی بالا برای طراحی کاملاً افزونه	بسیار زیاد	بسیار کم؛ طراحی به‌گونه‌ای است که حتی با دو خرابی هم سیستم فعال بماند	بسیار زیاد؛ پایداری بالا و بازده قابل‌توجه، اما نیازمند مهارت و نگهداری پیچیده

در نتیجه، می‌توان گفت گزینه‌ی “No single points of failure” بهترین تعادل بین هزینه، پیچیدگی و تداوم عملکرد را ارائه می‌دهد. رهبران کسب‌وکار بسته به ریسک‌پذیری خود ممکن است گزینه‌ی ارزان‌تر یا گزینه‌ی پرهزینه‌تر را برای تضمین پایداری انتخاب کنند. برای طراحان شبکه، درک ارتباط میان ریسک، پاداش و هزینه‌ی طراحی از مفاهیم بسیار کلیدی است.

پول، پول، پول (Money, Money, Money)

حدود ۹۰ درصد سازمان‌های تجاری، به‌منظور کسب سود (for-profit) فعالیت می‌کنند. این بدان معناست که تمرکز اصلی آن‌ها بر افزایش درآمد و کاهش هزینه‌ها به‌صورت هم‌زمان است.

برای مثال، ممکن است شرکتی با کاهش هزینه‌های سرمایه‌ای (Capital Expenses – CAPEX)، مانند ادغام چهار مرکز داده‌ی متعلق به خود در دو مرکز، تعداد ساختمان‌های تحت مالکیتش را کاهش دهد.

در مقابل، ممکن است شرکتی بر کاهش هزینه‌های عملیاتی (Operating Expenses – OPEX) تمرکز کند، مانند کاهش بودجه‌ی تبلیغات و بازاریابی.

هر دو نمونه‌ی CAPEX و OPEX را می‌توان نوعی سرمایه‌گذاری (Investment) دانست. برای مثال، ارتقای یک نرم‌افزار سازمانی می‌تواند منجر به کاهش هزینه‌ها یا افزایش درآمد شود. این بازده را بازگشت سرمایه (Return on Investment – ROI) می‌نامند.

ROI مفهومی است که مشخص می‌کند مزیت بالقوه‌ی حاصل از یک اقدام تجاری خاص چیست و آیا این مزیت از نظر مالی توجیه‌پذیر است یا نه.

ماهیت کسب‌وکار (The Nature of the Business)

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

علاوه بر این، برخی صنایع الزامات خاص خود را دارند؛ برای مثال، سازمان‌های سلامت ممکن است موظف به رعایت استاندارد IEC-80001-1 باشند.

برنامه‌ریزی (Planning)

ضرب‌المثلی معروف می‌گوید:

“اگر برنامه‌ای نداری، در واقع برای شکست برنامه‌ریزی کرده‌ای.”

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

“چرا (Why) این تصمیم طراحی گرفته می‌شود؟”

پرسیدن Why کلید طراحی‌ای است که با اهداف کوتاه‌مدت یا بلندمدت کسب‌وکار همسو باشد. Best Practices در طراحی شبکه باید همیشه در نظر گرفته شوند و هر زمان که ممکن است، اعمال گردند.

برای مثال، طراحی شبکه از ابتدا (Greenfield Design) معمولاً در شرکت‌های بزرگ رایج نیست؛ بلکه بیشتر در شبکه‌های جدید یا پروژه‌های SaaS رخ می‌دهد. در چنین پروژه‌هایی، پس از جمع‌آوری محرک‌ها (Drivers) و اهداف (Outcomes)، طراح شبکه باید گزینه‌های مختلفی برای رسیدن از نقطه‌ی A به B ترسیم کند و با تحلیل شرایط، تصمیم مناسب را اتخاذ کند.

ابزار تصمیم‌گیری (Decision Tree)

Decision Tree ابزاری مفید برای مقایسه‌ی گزینه‌های مختلف طراحی است. به‌عنوان مثال، طراح ممکن است بخواهد تصمیم بگیرد از کدام پروتکل Routing استفاده کند BGP یا IGP بر اساس توپولوژی شبکه یا سناریوی طراحی.

ماتریس تصمیم‌گیری (Decision Matrix)

Decision Matrix عملکردی مشابه Decision Tree دارد، اما ابعاد بیشتری را در تصمیم‌گیری وارد می‌کند. در این روش، اولویت‌های کسب‌وکار و نیازها در قالب جدول تحلیل می‌شوند.

جدول ۲-۴ — Decision Matrix

الزامات کسب‌وکار (Business Requirements)	اولویت (Priority)	گزینه طراحی ۱	گزینه طراحی ۲
صرفه‌جویی در هزینه (Cost Savings)	4	Moderate	Low
مقیاس‌پذیری (Scalable)	1	High	High
امنیت (Secure)	2	Low	High

در این مثال، گزینه‌ی طراحی ۲ مطلوب‌تر است، چون توازن بهتری بین الزامات و اولویت‌ها دارد.

رویکردهای برنامه‌ریزی (Planning Approaches)

برای موفقیت در طراحی شبکه، داشتن یک استراتژی برنامه‌ریزی منسجم ضروری است. دو رویکرد اصلی وجود دارد:

• Strategic Planning Approach: تمرکز بر اهداف بلندمدت دارد، مثلاً مهاجرت از شبکه‌ی ATM Legacy به MPLS برای یک سرویس‌دهنده.
• Tactical Planning Approach: تمرکز بر اهداف کوتاه‌مدت دارد، مثلاً ایجاد دسترسی موقت اینترنتی برای شرکای خارجی تا آماده شدن لینک اختصاصی.

توازن استراتژیک (Strategic Balance)

در هر سازمان، واحدهای مختلف کسب‌وکار وجود دارند هر کدام با استراتژی و ذی‌نفعان (Stakeholders) خاص خود. برای مثال:

• واحد IT بیشتر به نوآوری و کیفیت خدمات توجه دارد.
• واحد تدارکات (Procurement) بر کاهش هزینه تمرکز می‌کند.
• واحد بازاریابی بر جذب مشتری و نوآوری در تجربه‌ی کاربری متمرکز است.

یک طراح شبکه باید این اختلاف‌ها را درک کند تا بتواند بین اولویت‌های متضاد تعادل استراتژیک (Strategic Alignment) برقرار نماید.

نمونه‌ی موردی (Case Study)

فرض کنید یک فروشگاه زنجیره‌ای قصد دارد با هزینه‌ی پایین (Low CAPEX) تعداد سایت‌های دور (Remote Sites) خود را افزایش دهد.

دیدگاه IT:

• برنامه‌ی PoS فاقد قابلیت ذخیره‌سازی آفلاین است → نیازمند اتصال دائم به مرکز داده است.
• حجم ترافیک کم اما حساس است (Real-time).
• سایت‌های جدید باید به‌سرعت اضافه شوند.
• راه‌حل بهینه: استفاده از MPLS VPN برای WAN.

دیدگاه بازاریابی:

• قطعی شبکه منجر به ناتوانی در انجام تراکنش‌ها و آسیب به اعتبار برند می‌شود.
• راه‌حل بهینه: استفاده از لینک‌های Redundant با سرعت بالا.

دیدگاه مالی:

• هدف اصلی، صرفه‌جویی در هزینه‌ها است.
• راه‌حل بهینه: استفاده از یک لینک ارزان مانند Internet link برای برآورد نیاز پایه.

مدیریت پروژه (Project Management)

به عنوان یک طراح شبکه، لازم است درک کنیم پروژه‌ها چگونه مدیریت می‌شوند. این به این معنا نیست که باید خودمان مدیر پروژه باشیم یا مدیریت پروژه را بر عهده بگیریم، بلکه باید فرآیند اجرای پروژه‌ها و مزایا و معایب هر روش مدیریت پروژه را بشناسیم. این بخش، رایج‌ترین روش‌شناسی‌های مدیریت پروژه (Project Management Methodologies) و مزایا و معایب آن‌ها را بررسی می‌کند.

روش آبشاری (Waterfall Methodology)

چارچوب مدیریت پروژه‌ی آبشاری (Waterfall Project Management Framework) یک فرآیند خطی و ترتیبی (Sequential, Linear Process) را دنبال می‌کند و از لحاظ تاریخی، محبوب‌ترین روش مدیریت پروژه برای مهندسی نرم‌افزار و پروژه‌های IT بوده است. در این روش، هر مرحله پس از تکمیل مرحله‌ی قبلی آغاز می‌شود و معمولاً از ابزارهایی مانند نمودار گانت (Gantt Chart) برای نمایش تاریخ شروع، پایان، منابع تخصیص‌یافته، وابستگی‌ها و وضعیت کلی هر فعالیت استفاده می‌شود.

هنگامی که یکی از مراحل پروژه کامل شد، تیم پروژه به مرحله‌ی بعدی حرکت می‌کند. بازگشت به مراحل قبلی بدون شروع دوباره‌ی کل فرآیند ممکن نیست. پیش از ورود به هر مرحله، الزامات (Requirements) باید بازبینی و تأیید شوند.
به همین دلیل، فرآیند Waterfall به‌عنوان یک فرآیند خطی (Linear Process) شناخته می‌شود.

مزایای مدیریت پروژه به روش آبشاری (Advantages of Waterfall Project Management)

روش آبشاری برای پروژه‌هایی مناسب است که ساده، ثابت و بدون تغییر هستند. این روش ساختاری خطی دارد که درک آن آسان و مستندسازی در آن دقیق‌تر است.

۱. سهولت در مدیریت (Ease of Manageability)

از آنجا که Waterfall در همه‌ی پروژه‌ها از یک الگوی ثابت پیروی می‌کند، استفاده و درک آن آسان است. تیم پروژه نیازی به دانش یا آموزش خاص پیش از شروع ندارد. هر فاز خروجی‌های مشخص (Deliverables) و فرآیند بازبینی خاص خود را دارد، بنابراین کنترل و مدیریت پروژه ساده‌تر می‌شود.

۲. ساختار (Structure)

هر فاز در Waterfall دارای نقطه‌ی شروع و پایان است. این ویژگی به اشتراک پیشرفت با ذی‌نفعان (Stakeholders) کمک می‌کند و با تمرکز بر طراحی شبکه پیش از پیاده‌سازی، ریسک عدم تحقق مهلت‌ها کاهش می‌یابد.

۳. مستندسازی (Documentation)

در هر فاز، مستندسازی کامل انجام می‌شود که موجب درک بهتر طراحی شبکه و تصمیمات فنی می‌شود. این مستندات پایه‌ای محکم برای پروژه‌های آتی فراهم کرده و به ذی‌نفعان اجازه می‌دهد جزئیات هر فاز را به‌صورت شفاف بررسی کنند.

معایب روش آبشاری (Disadvantages of Waterfall)

بزرگ‌ترین محدودیت Waterfall، مقاومت در برابر تغییر (Change Adverse) در طول پروژه است. به دلیل ماهیت خطی آن، نمی‌توان بین فازها عقب و جلو رفت و اگر تغییری پیش‌بینی‌نشده رخ دهد، رفع آن هزینه‌بر و دشوار است.

۱. مقاومت در برابر تغییر (Change Adverse)

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

۲. تأخیر در تحویل راه‌حل (Solution Delivery is Late)

از آنجا که پروژه باید چندین فاز را طی کند تا به پیاده‌سازی برسد، مدیران کسب‌وکار دیرتر نتیجه‌ی واقعی را مشاهده می‌کنند.

۳. دشواری در جمع‌آوری نیازمندی‌ها (Requirements Gathering is Difficult)

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

روش‌شناسی‌های چابک (Agile Methodologies)

روش‌های چابک بر پایه‌ی رویکرد تکرارشونده و افزایشی (Incremental, Iterative Approach) بنا شده‌اند. برخلاف مدل Waterfall که برنامه‌ریزی عمیق در ابتدای پروژه انجام می‌شود، در Agile، الزامات پروژه می‌توانند در طول زمان تغییر کنند و بازخورد مستمر از ذی‌نفعان (Stakeholders) و رهبران کسب‌وکار تشویق می‌شود.

تیم‌های چند‌وظیفه‌ای (Cross-functional teams) در بازه‌های زمانی مشخص روی نسخه‌های مختلف یک محصول کار می‌کنند. این کار در قالب Backlog سازمان‌دهی می‌شود که بر اساس ارزش تجاری یا ارزش برای مشتری (Business or Customer Value) اولویت‌بندی می‌گردد. هدف هر Iteration، تولید یک نسخه‌ی کاری از محصول است.

در ابتدا Agile برای توسعه‌ی نرم‌افزار (Software Development) ایجاد شد. اما امروزه با تغییر جهت صنعت شبکه به سمت Automation و Orchestration، روش‌های Agile در حوزه‌هایی مانند:

• Infrastructure as Code (IaC)
• Network as Code
• استفاده از APIها برای خودکارسازی عملیات شبکه در مقیاس بزرگ
• و یکپارچه‌سازی فرآیندها با CI/CD Pipeline

کاربرد گسترده یافته‌اند. بنابراین طراحان شبکه نیز باید درک کنند که روش Agile چگونه کار می‌کند تا بتوانند تصمیمات طراحی مناسبی اتخاذ کنند، به‌ویژه در زمان‌هایی که شرکت‌ها از Agile Methodologies برای مدیریت پروژه‌های خود استفاده می‌کنند.

۱۲ اصل روش‌های چابک (12 Principles of Agile Methodologies)

مانیفست توسعه‌ی نرم‌افزار چابک (Manifesto for Agile Software Development) ۱۲ اصل زیر را برای هدایت تیم‌ها در اجرای پروژه‌ها با چابکی ارائه کرده است:

1. اولویت اصلی ما رضایت مشتری است از طریق تحویل مداوم و زودهنگام نرم‌افزار ارزشمند.
2. خوش‌آمد به تغییرات حتی در اواخر توسعه؛ فرآیند چابک تغییر را برای مزیت رقابتی مشتری در آغوش می‌گیرد.
3. تحویل مکرر نرم‌افزار قابل‌کاربرد از چند هفته تا چند ماه، با اولویت بازه‌های زمانی کوتاه‌تر.
4. همکاری روزانه‌ی کسب‌وکار و توسعه‌دهندگان در طول پروژه.
5. ساخت پروژه‌ها حول افراد باانگیزه و اعتماد به آن‌ها برای انجام کار.
6. ارتباط مؤثر چهره‌به‌چهره بهترین روش انتقال اطلاعات است.
7. نرم‌افزار در حال کار اصلی‌ترین معیار پیشرفت است.
8. توسعه‌ی پایدار: ذی‌نفعان و توسعه‌دهندگان باید قادر باشند سرعت ثابتی را به‌طور نامحدود حفظ کنند.
9. توجه مستمر به برتری فنی و طراحی خوب موجب افزایش چابکی می‌شود.
10. سادگی (Simplicity) هنر انجام بیشترین کار با حداقل تلاش.
11. بهترین معماری‌ها و طراحی‌ها توسط تیم‌های خودسازمان‌ده (Self-organizing Teams) ایجاد می‌شوند.
12. بازتاب منظم و بهبود مستمر: در فواصل زمانی منظم، تیم بر عملکرد خود تأمل می‌کند و برای اثربخشی بیشتر، آن را تنظیم می‌نماید.

مزایای Agile (Advantages of Agile)

روش Agile بر انعطاف‌پذیری، بهبود مستمر و سرعت تمرکز دارد. برخلاف Waterfall، Agile کاملاً پذیرای تغییر است و برای پروژه‌هایی که محیط پویا دارند، بسیار مناسب است.

۱. استقبال از تغییر (Change is Welcomed)

با وجود چرخه‌های کوتاه‌تر کاری، اضافه‌کردن تغییرات در طول پروژه آسان‌تر است. Agile به‌صورت مداوم کار را بازبینی و اولویت‌بندی مجدد می‌کند تا بتوان تغییرات جدید را سریعاً اعمال کرد (در حد چند هفته یا حتی چند روز).

۲. وضعیت نهایی نامشخص (Unknown Future State)

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

۳. تحویل سریع‌تر (Faster Delivery)

تقسیم پروژه به Iterationهای کوچک‌تر باعث می‌شود تیم بتواند روی بخش‌های با ارزش‌تر و قابل‌تحویل تمرکز کند.

۴. چرخه‌ی بازخورد (Feedback Loop)

Agile بازخورد مستمر از کاربران و اعضای تیم را در کل طول پروژه تشویق می‌کند، که این بازخوردها برای بهبود Iterationهای بعدی استفاده می‌شوند.

معایب Agile (Disadvantages of Agile)

در کنار مزایا، روش Agile چالش‌ها و محدودیت‌هایی نیز دارد. با اضافه شدن تغییرات مکرر، پیش‌بینی زمان اتمام پروژه دشوار می‌شود و مستندسازی گاهی در اولویت پایین‌تری قرار می‌گیرد.

۱. فقدان زمان‌بندی مشخص (Lack of Scheduling)

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

۲. نیاز به تیم‌های با مهارت بالا (Highly Skilled Teams)

تیم Agile باید شامل افراد خودانگیخته و ماهر باشد که نیاز به نظارت مداوم ندارند. همچنین اعضا باید با متدولوژی Agile مورد استفاده آشنا باشند.

۳. تعهد زمانی (Time Commitment)

برای موفقیت Agile، اعضای تیم باید کاملاً متعهد و درگیر پروژه باشند. همکاری مداوم و پایدار از سوی تمام اعضا ضروری است، و این می‌تواند برای پروژه‌های بلندمدت چالش‌برانگیز باشد.

۴. گسترش بی‌پایان محدوده (End Solution Creep)

از آنجا که Agile ذاتاً منعطف است، محصول نهایی ممکن است با طرح اولیه تفاوت زیادی پیدا کند. تغییرات پی‌درپی بر اساس بازخورد مشتری می‌تواند منجر به افزایش بی‌پایان محدوده‌ی پروژه (Scope Creep) شود، که خطر کاهش سود و افزایش هزینه‌ها را برای هر دو طرف به همراه دارد.

روش اسکرام (Scrum Methodology)

Scrum یکی از زیرمجموعه‌های Agile و از محبوب‌ترین چارچوب‌های فرآیندی برای پیاده‌سازی آن است. Scrum به‌عنوان یک مدل تکرارشونده (Iterative Model) برای مدیریت پروژه‌ها طراحی شده است.

در Scrum، نقش‌ها (Roles)، مسئولیت‌ها (Responsibilities) و جلسات (Meetings) به‌صورت مشخص و ثابت تعریف می‌شوند. برای مثال، Scrum از چهار مراسم (Ceremony) اصلی استفاده می‌کند که ساختار فرآیندی هر Sprint را تشکیل می‌دهند:

• Sprint Planning (برنامه‌ریزی اسپرینت)
• Daily Stand-Up (جلسات روزانه)
• Sprint Demo / Review (نمایش نتایج اسپرینت)
• Sprint Retrospective (بازنگری و بهبود عملکرد تیم)

مزایای Scrum (Advantages of Scrum)

Scrum یک چارچوب ساختاریافته و تجویزی (Prescriptive Framework) است که شامل نقش‌ها، مسئولیت‌ها و جلسات مشخص می‌باشد.

۱. شفافیت بیشتر (Increased Transparency)

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

۲. افزایش پاسخ‌گویی تیم (Increased Team Accountability)

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

۳. سهولت در سازگاری با تغییرات (Easy to Accommodate Changes)

با وجود اسپرینت‌های کوتاه و بازخورد مداوم، اعمال تغییرات در پروژه ساده‌تر می‌شود. برای مثال، اگر در حین یک Sprint نیاز به افزودن یک User Story جدید شناسایی شود، تیم می‌تواند آن را به Sprint بعدی منتقل کند.

۴. کاهش هزینه‌ها (Increased Cost Savings)

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

معایب Scrum (Disadvantages of Scrum)

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

۱. گسترش محدوده‌ی پروژه (Scope Creep)

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

۲. نیاز به تجربه‌ی Scrum (Requires Scrum Experience)

با توجه به تعریف دقیق نقش‌ها و مسئولیت‌ها، اعضای تیم باید با اصول Scrum آشنا باشند. در Scrum هیچ نقش مدیریتی سنتی وجود ندارد، بنابراین اعضای تیم باید مهارت فنی و تعهد بالا داشته باشند و در جلسات روزانه حضور مداوم داشته باشند.

۳. نقش نادرست Scrum Master (The Wrong Scrum Master Can Ruin Everything)

Scrum Master با Project Manager تفاوت دارد. او قدرت تصمیم‌گیری مستقیم ندارد، بلکه باید به تیم اعتماد کند. اگر Scrum Master بیش از حد کنترل‌گر باشد یا اعتماد نکند، پروژه شکست خواهد خورد.

۴. وظایف تعریف‌نشده منجر به خطا می‌شوند (Poorly Defined Tasks Can Lead to Inaccuracies)

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

روش کانبان (Kanban Methodology)

Kanban یک واژه‌ی ژاپنی به‌معنای «علامت دیداری» یا «کارت» است. روش‌شناسی Kanban یک چارچوب دیداری (Visual Framework) برای اجرای Agile است که نشان می‌دهد چه چیزی باید تولید شود، چه زمانی تولید شود و به چه میزان. Kanban تغییرات کوچک و تدریجی در سیستم موجود را تشویق می‌کند و نیازی به ساختار یا رویه‌ی از پیش‌تعیین‌شده ندارد. این روش را می‌توان به‌راحتی بر روی سایر متدولوژی‌های مدیریت پروژه‌ای که تا اینجا گفته شد، پوشش (Overlay) داد.

وقتی صحبت از مقایسه‌ی Kanban با Agile است، باید به یاد داشت که Kanban یکی از طعم‌های Agile است یعنی یکی از فریم‌ورک‌هایی که برای پیاده‌سازی توسعه‌ی نرم‌افزار چابک استفاده می‌شود.

Kanban Board ابزاری برای پیاده‌سازی روش Kanban در پروژه‌هاست. این بُرد از ستون‌هایی (یا Swim Lanes) تشکیل شده است. ساده‌ترین نوع Kanban Board سه ستون دارد:

• To Do (کارهایی که باید انجام شوند)
• Work In Progress (WIP) (کارهای در حال انجام)
• Done (کارهای انجام‌شده)

نمونه‌ی واقعی استفاده از Kanban

من شخصاً از یک Kanban Board فیزیکی استفاده می‌کنم. ستون‌های من شامل: To Do، Working و Completed هستند. در ستون Working، دو زیرستون Nested دارم: In Progress و Pending. در مواقعی که کاری متوقف می‌شود تا فعالیتی دیگر تکمیل شود، کارت مربوطه را در ستون Pending قرار می‌دهم تا بعداً بتوانم آن را ادامه دهم.

کارت‌های Kanban نمایانگر کارها هستند و هر کارت در ستون مربوطه قرار می‌گیرد که وضعیت فعلی کار را نشان می‌دهد. این کارت‌ها به‌صورت دیداری وضعیت پروژه را منتقل می‌کنند. در Kanban Board می‌توان از رنگ‌های مختلف برای دسته‌بندی فعالیت‌ها استفاده کرد.

مزایای Kanban (Advantages of Kanban)

ماهیت دیداری Kanban مزیت ویژه‌ای در اجرای Agile فراهم می‌کند. Kanban آسان برای یادگیری و درک، بهبوددهنده‌ی جریان کار و صرفه‌جو در زمان است.

۱. افزایش انعطاف‌پذیری (Increases Flexibility)

Kanban مدلی پویا و در حال تحول است که فاقد محدودیت زمانی مشخص است. وقتی کار جدیدی اضافه می‌شود، به‌صورت پویا در صف کارها قرار می‌گیرد و اولویت‌بندی می‌شود.

۲. کاهش اتلاف (Reduces Waste)

Kanban حول محور کاهش هدررفت منابع و زمان می‌چرخد. تیم‌ها تنها روی کارهای ضروری تمرکز می‌کنند و از انجام کارهای غیرضروری خودداری می‌ورزند.

۳. سادگی و سهولت یادگیری (Easy to Understand / KISS Principle)

ماهیت دیداری Kanban باعث می‌شود یادگیری و استفاده از آن بسیار ساده باشد. اصل KISS (Keep It Super Simple) در Kanban کاملاً رعایت می‌شود. تیم‌ها نیازی به یادگیری متدولوژی پیچیده‌ی جدید ندارند و Kanban به‌راحتی می‌تواند در کنار سایر سیستم‌ها اجرا شود.

معایب Kanban (Disadvantages of Kanban)

بسیاری از مشکلات مرتبط با Kanban به دلیل استفاده‌ی نادرست یا بیش‌ازحد پیچیده کردن Kanban Board به‌وجود می‌آیند. یک بُرد منسوخ یا شلوغ می‌تواند باعث سردرگمی، خطا و سوء‌تفاهم شود.

۱. قدیمی شدن بُرد (Outdated Board)

تیم باید متعهد شود که Kanban Board را به‌روز نگه دارد. در غیر این صورت، داده‌ها نادرست می‌شوند و اصلاح مسیر پروژه دشوار خواهد بود.

۲. پیچیدگی بیش‌ازحد (Overcomplicate the Board)

Kanban باید ساده، شفاف و خوانا باشد. اضافه کردن بیش‌ازحد ستون‌ها یا جزئیات، باعث آشفتگی می‌شود. به عنوان مثال، من در ابتدا بیش از ۱۰ ستون داشتم که باعث پیچیدگی زیاد شد. تجربه نشان داد که سادگی، کلید کارایی در Kanban است.

۳. فقدان زمان‌بندی مشخص (Lack of Timing)

یکی از شکایات رایج در Kanban این است که نمی‌توان پیش‌بینی کرد چه زمانی کارها تکمیل می‌شوند. چون ستون‌ها فقط فاز (To Do, WIP, Done) را نشان می‌دهند و بازه‌ی زمانی ندارند، بنابراین طول هر فاز دقیقاً مشخص نیست و تنها از طریق ردیابی متریک‌ها می‌توان حدوداً تخمین زد.

قوانین Kanban (Kanban Rules)

هر پروژه‌ی Kanban باید از قوانین زیر پیروی کند:

۱. Visualize

نمایش دیداری کارها روی بُرد به تیم کمک می‌کند تا وضعیت پروژه را درک کرده و مسیر پیشرفت را ببیند. این دید شفاف به تیم امکان می‌دهد مشکلات را زودتر شناسایی و برطرف کند.

۲. Limit Work

تعیین WIP Limit (محدودیت کار در حال انجام) برای هر ستون ضروری است. این کار از اضافه‌بار جلوگیری کرده و به تیم کمک می‌کند تمرکز بیشتری داشته باشد. مثلاً من قبلاً WIP = 10 داشتم که زیاد بود، اکنون WIP = 2 برایم مناسب‌تر است. افزودن محدودیت WIP باعث افزایش سرعت، تمرکز و انعطاف‌پذیری می‌شود.

۳. Manage the Card Flow

حرکت کارت‌ها در بُرد باید پایش و بهبود شود. هدف، رسیدن به جریان کاری سریع و روان است، نشانه‌ای از آنکه تیم به‌صورت مؤثر کار می‌کند.

۴. Reserve the Right to Improve

تیم باید همیشه حق بازنگری و بهبود فرآیند را داشته باشد. با بازبینی مداوم، تیم می‌تواند چرخه‌ی کاری را کوتاه‌تر کرده و کیفیت نتایج را افزایش دهد.

مقایسه‌ی روش‌های مدیریت پروژه (Project Management Methodology Comparison)

جدول ۲-۵ روش‌های مختلف مدیریت پروژه که در این فصل پوشش داده شدند را مقایسه می‌کند:

جدول ۲-۵: مقایسه‌ی روش‌های مدیریت پروژه

معیار (Criteria)	Waterfall	Agile	Scrum	Kanban
Scope Creep (گسترش محدوده)	احتمال وقوع پایین	معمولاً در بیشتر پروژه‌های Agile اتفاق می‌افتد	معمولاً در پروژه‌های Scrum اتفاق می‌افتد	—
Manageability (قابلیت مدیریت)	آسان	سخت	سخت	آسان
Structure (ساختار)	بسیار ساختارمند	بدون ساختار مشخص	بدون ساختار مشخص	ساختارمند
Documentation (مستندسازی)	الزامی و در هر فاز گنجانده می‌شود	الزامی نیست	الزامی نیست	الزامی نیست
Changes (تغییرات)	تغییرات خوشایند نیستند	تغییرات پذیرفته می‌شوند	تغییرات به‌راحتی اعمال می‌شوند	تغییرات به‌راحتی اعمال می‌شوند
Solution Delivery (تحویل راه‌حل)	دیر در فرآیند اتفاق می‌افتد	سریع‌تر	سریع‌تر	سریع‌ترین — تمرکز بر WIP limits برای تحویل سریع‌تر کار فعلی
Requirements Gathering (جمع‌آوری نیازمندی‌ها)	در ابتدا شناسایی می‌شوند؛ پیش‌بینی همه‌ی نیازها در مراحل اولیه سخت است	نیازها در طول پروژه شناسایی می‌شوند؛ پیش‌بینی زمان تکمیل دشوار است	نیازها در طول پروژه شناسایی می‌شوند؛ پیش‌بینی زمان تکمیل دشوار است	نیازها در طول پروژه شناسایی می‌شوند؛ پیش‌بینی زمان تکمیل دشوار است
Future / End State (وضعیت نهایی)	از ابتدا به‌وضوح تعریف می‌شود	در ابتدا تعریف نمی‌شود، در طول پروژه مشخص می‌گردد	در ابتدا تعریف نمی‌شود، در طول پروژه مشخص می‌گردد	—
Stakeholder Feedback (بازخورد ذی‌نفعان)	معمولاً فقط در مرحله‌ی جمع‌آوری نیازمندی‌ها اخذ می‌شود	بازخورد مداوم و در Iterationهای بعدی لحاظ می‌شود	بازخورد مداوم و در Iterationهای بعدی لحاظ می‌شود	بازخورد مداوم و در Iterationهای بعدی لحاظ می‌شود
Project Completion Date (تاریخ اتمام پروژه)	قابل شناسایی و برنامه‌ریزی آسان	سخت برای تعیین؛ تغییرات باعث جابجایی تاریخ می‌شوند	سخت برای تعیین؛ تغییرات باعث جابجایی تاریخ می‌شوند	دشوار، چون زمان پیگیری نمی‌شود
Teams (تیم‌ها)	ترکیبی از اعضای ماهر و نیمه‌ماهر؛ مسئولیت جمعی ضعیف	نیاز به تیمی کاملاً ماهر و آشنا به Agile دارد؛ پاسخ‌گویی تیمی محدود	نیاز به تیمی ماهر و آشنا به Scrum دارد؛ پاسخ‌گویی تیمی قوی‌تر	نیازی به دانستن متدولوژی خاص نیست؛ کار باید قابل مشاهده روی Kanban Board باشد
Time Commitment (تعهد زمانی)	منابع می‌توانند بین پروژه‌ها مشترک باشند	تمام منابع باید به پروژه اختصاص یابند	تمام منابع باید به پروژه اختصاص یابند	منابع باید تا زمان تکمیل کارت یا انتقال به وضعیت Pending روی آن متمرکز بمانند
Work Transparency / Visibility (شفافیت کار)	بدون شفافیت	شفافیت جزئی	شفافیت کامل	دید کامل نسبت به جریان کار

خلاصه (Summary)

در این فصل بر روی عناصر کسب‌وکار، اصطلاحات، و سبک‌های مدیریت پروژه تمرکز کردیم که هر طراح شبکه باید آن‌ها را بشناسد.

ما درباره‌ی اولویت‌های تجاری، محرک‌ها (Drivers)، خروجی‌ها (Outcomes)، و توانمندی‌ها (Capabilities) صحبت کردیم و توضیح دادیم چگونه هرکدام از آن‌ها بر نیازمندی‌های طراحی تأثیر می‌گذارند.

سپس به موضوعاتی مانند ریسک در برابر پاداش (Risk vs Reward)، ROI، CAPEX، OPEX و Business Continuity پرداختیم و بررسی کردیم این موارد چگونه تصمیم‌گیری در طراحی شبکه را تحت تأثیر قرار می‌دهند.

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

در نهایت، متدولوژی‌های رایج مدیریت پروژه از جمله Waterfall، Agile، Scrum و Kanban را مرور و مقایسه کردیم و مزایا و معایب هرکدام را از منظر معیارهای مختلف تحلیل نمودیم.

جمله‌ی پایانی:

Network designers must be the bridge between technology and the business.
Be the bridge, my friends!
ترجمه:
طراحان شبکه باید پل ارتباطی بین فناوری و کسب‌وکار باشند.
پل باشید، دوستان من!