نوشته های Farokh Hasanzadeh

خلاصه فصل هفت کتاب (Thinking in Systems: A Primer)

Farokh Hasanzadeh — Thu, 10 Sep 2026 22:02:43 +0330

زندگی در جهانی از سیستم‌هاایده اصلی فصلMeadows در فصل‌های قبل توضیح می‌دهد که سیستم‌ها چگونه کار می‌کنند، چرا ما را غافلگیر می‌کنند و کجا می‌توانیم در آنها مداخله کنیم.اما در فصل ۷ سؤال مهم‌تری مطرح می‌کند:اگر جهان واقعاً از سیستم‌های پیچیده تشکیل شده، ما چگونه باید در آن زندگی و تصمیم‌گیری کنیم؟پاسخ او این است که باید فروتن‌تر، صبورتر، انعطاف‌پذیرتر و بیشتر آماده‌ی یادگیری باشیم.۱. با سیستم‌ها بجنگیم یا آنها را بشناسیم؟یکی از اشتباهات رایج این است که تصور کنیم می‌توانیم سیستم را کاملاً کنترل کنیم.مثلاً می‌گوییم:«اگر فقط این متغیر را تغییر بدهیم، همه‌چیز درست می‌شود.»اما سیستم‌ها:بازخورد دارند،تأخیر دارند،غیرخطی هستند،خودشان را تطبیق می‌دهند،و اجزای مختلفشان روی یکدیگر اثر می‌گذارند.بنابراین بهتر است به جای اینکه دائماً تلاش کنیم سیستم را کنترل کنیم، ابتدا تلاش کنیم آن را بفهمیم و با آن کار کنیم.۲. ذهنیت خودمان بخشی از سیستم استیکی از مهم‌ترین نکات فصل این است که:ما بیرون از سیستم نیستیم؛ خودمان هم بخشی از سیستم هستیم.وقتی درباره یک سیستم تصمیم می‌گیریم، تصمیم ما وارد همان سیستم می‌شود و دوباره روی خودمان اثر می‌گذارد.مثلاً:انسان → مصرف منابع → تغییر محیط زیست → تغییر شرایط زندگی انسانپس نمی‌توانیم همیشه خودمان را «ناظر بی‌طرف» بدانیم.این موضوع باعث می‌شود خودآگاهی بخش مهمی از تفکر سیستمی باشد.۳. اطلاعات را دنبال کن، نه فقط اعداد رادر سیستم‌ها، اطلاعات نقش بسیار مهمی دارد.گاهی مشکل این نیست که اطلاعات وجود ندارد؛ مشکل این است که:اطلاعات به فرد مناسب نمی‌رسد،با تأخیر می‌رسد،اطلاعات مهم پنهان می‌شود،یا افراد نمی‌دانند چگونه از آن استفاده کنند.بنابراین یک سؤال سیستمی مهم این است:چه کسی چه چیزی را می‌داند و چه کسی از آن بی‌خبر است؟شفاف‌تر شدن جریان اطلاعات می‌تواند رفتار سیستم را تغییر دهد.۴. دنبال «مقصر» نباشیم؛ ساختار را ببینیمتفکر معمولی اغلب می‌گوید:«چه کسی باعث این مشکل شد؟»تفکر سیستمی می‌پرسد:«چه ساختاری باعث شده این رفتار به وجود بیاید؟»مثلاً اگر کارکنان یک سازمان عملکرد ضعیفی دارند، ممکن است مشکل فقط تنبلی آنها نباشد.شاید:سیستم پاداش اشتباه باشد،اهداف اشتباه باشند،اطلاعات ناقص باشد،مدیران بازخورد مناسبی ندهند،یا فشارهای سیستم رفتار خاصی را ایجاد کنند.پس به جای سرزنش افراد، باید ساختار تولیدکننده رفتار را بررسی کنیم.۵. «عدد درست» همیشه مسئله را حل نمی‌کندما انسان‌ها به عددها علاقه داریم:رشد اقتصادیفروشسودنمرهتولیدتعداد مشتریاما یک عدد ممکن است فقط شاخص باشد، نه خود واقعیت.مثلاً اگر هدف مدرسه فقط افزایش نمرات باشد، ممکن است مدرسه کاری کند که نمرات بالا بروند ولی یادگیری واقعی افزایش پیدا نکند.بنابراین باید دائماً بپرسیم:آیا چیزی که اندازه می‌گیریم واقعاً همان چیزی است که برایمان اهمیت دارد؟۶. هدف‌های ساده برای سیستم‌های پیچیده خطرناک‌اندسیستم‌های پیچیده معمولاً چند هدف هم‌زمان دارند.مثلاً یک شهر باید:اقتصادی باشد،محیط زیست را حفظ کند،قابل زندگی باشد،حمل‌ونقل مناسب داشته باشد،عدالت اجتماعی داشته باشد.اگر فقط یک هدف را بیشینه کنیم، ممکن است به اهداف دیگر آسیب بزنیم.بنابراین تفکر سیستمی به ما یاد می‌دهد که بهینه‌سازی یک بخش را با بهبود کل سیستم اشتباه نگیریم.۷. «مقاومت» همیشه دشمن نیستگاهی وقتی سیستم در برابر تغییر مقاومت می‌کند، تصور می‌کنیم سیستم خراب است.اما Meadows می‌گوید این مقاومت ممکن است اطلاعات مهمی درباره ساختار سیستم به ما بدهد.اگر چند بار یک سیاست را اجرا کنیم و سیستم دوباره به وضعیت قبلی برگردد، باید بپرسیم:چه بازخوردی دارد ما را به وضعیت قبلی برمی‌گرداند؟در نتیجه مقاومت سیستم می‌تواند به ما نشان دهد که کجا باید ساختار را تغییر دهیم.۸. با عدم قطعیت کنار بیاییمسیستم‌های پیچیده را نمی‌توان همیشه با دقت پیش‌بینی کرد.بنابراین به جای اینکه انتظار داشته باشیم:«مدل من دقیقاً آینده را پیش‌بینی کند»بهتر است بپرسیم:«اگر این فرض درست باشد، چه اتفاقی ممکن است بیفتد؟»یعنی مدل را به عنوان ابزار یادگیری ببینیم، نه یک دستگاه پیشگویی.۹. آزمایش کوچک بهتر از پیش‌بینی بزرگدر سیستم‌های پیچیده، گاهی بهتر است به جای اجرای یک تغییر بسیار بزرگ، تغییرات کوچک و قابل برگشت انجام دهیم.سپس:اقدام → مشاهده → یادگیری → اصلاح → اقدام بعدیاین همان چیزی است که می‌توان آن را یادگیری تطبیقی دانست.یعنی سیستم را تغییر بدهیم و هم‌زمان از واکنش آن یاد بگیریم.۱۰. فروتنی یکی از مهم‌ترین مهارت‌های تفکر سیستمی استMeadows در نهایت به یک پیام بسیار انسانی می‌رسد:ما نمی‌توانیم همه چیز را بدانیم.در سیستم‌های پیچیده همیشه:چیزهایی هست که نمی‌بینیم،پیامدهایی هست که پیش‌بینی نکرده‌ایم،روابطی وجود دارد که هنوز نمی‌شناسیم.پس متفکر سیستمی باید آماده باشد که بگوید:«ممکن است اشتباه کنم.»این جمله نشانه ضعف نیست؛ یکی از پایه‌های یادگیری است.۱۱. مهم‌ترین توصیه‌های Meadowsمی‌توان پیام‌های فصل را این‌طور خلاصه کرد:🔹 سیستم را بشناس، نه اینکه فقط آن را کنترل کنی.🔹 به ساختارها نگاه کن، نه فقط رویدادها.🔹 به بازخوردها و تأخیرها توجه کن.🔹 اطلاعات را شفاف کن.🔹 شاخص را با هدف واقعی اشتباه نگیر.🔹 بهینه‌سازی یک بخش را با بهبود کل اشتباه نکن.🔹 از آزمایش و یادگیری نترس.🔹 برای عدم قطعیت آماده باش.🔹 فروتن باش؛ مدل ذهنی تو خودِ واقعیت نیست.🔹 خودت را بخشی از سیستم بدان.خلاصه خیلی کوتاه فصل ۷فصل هفتم می‌گوید تفکر سیستمی فقط مجموعه‌ای از ابزارها نیست؛ یک شیوه زندگی و نگاه کردن به جهان است.در جهان سیستم‌ها، ما نمی‌توانیم همه‌چیز را کنترل یا دقیقاً پیش‌بینی کنیم. باید:مشاهده کنیم → ساختار را بفهمیم → مداخله کنیم → نتیجه را ببینیم → یاد بگیریم → خودمان را اصلاح کنیم.🧠 خلاصهدر سیستم‌های پیچیده، به جای تلاش برای کنترل کامل سیستم، باید ساختار، بازخوردها و اطلاعات را بفهمیم، با فروتنی مداخله کنیم و از واکنش سیستم یاد بگیریم.⭐ جمله کلیدی کل کتاباگر بخواهیم پیام کل کتاب را در یک جمله جمع کنیم:برای تغییر رفتار یک سیستم، فقط به اجزای آن نگاه نکن؛ ساختار روابط، بازخوردها، اهداف و ذهنیت‌هایی را ببین که رفتار سیستم را تولید می‌کنند.

خلاصه فصل ششم کتاب (Thinking in Systems: A Primer)

Farokh Hasanzadeh — Thu, 10 Sep 2026 21:55:37 +0330

فصل ۶: نقاط اهرمیایده اصلی فصل چیست؟Meadows می‌گوید وقتی می‌خواهیم یک سیستم را تغییر دهیم، همه تغییرات به یک اندازه مؤثر نیستند.مثلاً اگر یک کارخانه مشکل آلودگی دارد، می‌توانیم:مالیات بیشتری وضع کنیم،مقدار تولید را محدود کنیم،اطلاعات بهتری درباره آلودگی منتشر کنیم،قوانین را تغییر دهیم،یا حتی هدف اصلی سیستم را تغییر دهیم.اما این مداخلات قدرت یکسانی ندارند.نقطه اهرمی (Leverage Point) جایی در ساختار سیستم است که با تغییر نسبتاً کوچک، می‌توان رفتار سیستم را به شکل قابل‌توجهی تغییر داد.۱۲ نقطه اهرمی MeadowsMeadows این نقاط را تقریباً از کم‌قدرت‌ترین به قدرتمندترین مرتب می‌کند.حالا مهم‌ترین‌ها را ساده توضیح دهیم.۱۲. تغییر پارامترها و اعداداین ساده‌ترین نوع مداخله است.مثلاً:افزایش مالیاتکاهش یارانهافزایش حقوقتعیین سقف تولیدتغییر نرخ بهرهمشکل اینجاست که پارامترها معمولاً قدرت اهرمی کمی دارند.مثلاً اگر ساختار یک سیستم اقتصادی مشکل دارد، صرفاً تغییر نرخ مالیات ممکن است مشکل اصلی را حل نکند.نکته مهم:ما معمولاً عاشق تغییر اعداد هستیم، چون قابل مشاهده و قابل اندازه‌گیری‌اند؛ اما اغلب مشکل در ساختار سیستم است، نه در اعداد آن.۱۱. اندازه بافرهابافر یعنی چیزی که نوسانات را جذب می‌کند.مثلاً:موجودی انبارذخیره آبذخایر مالیظرفیت بیمارستانبافر بزرگ می‌تواند سیستم را پایدارتر کند.اما بافر بزرگ همیشه بهتر نیست؛ چون ساختن آن هزینه دارد.مثال:اگر یک فروشگاه موجودی بسیار کمی داشته باشد، کوچک‌ترین اختلال در تأمین کالا باعث کمبود می‌شود. افزایش موجودی می‌تواند سیستم را مقاوم‌تر کند.۱۰. ساختار جریان‌های مادیاینجا دیگر فقط مقدار منابع مهم نیست، بلکه نحوه حرکت منابع در سیستم مهم است.مثلاً در یک شهر:تولید → حمل‌ونقل → مصرف → زبالهاگر ساختار این جریان تغییر کند، رفتار کل سیستم می‌تواند تغییر کند.مثلاً به جای اینکه زباله مستقیماً دفع شود:مصرف → جمع‌آوری → تفکیک → بازیافت → استفاده مجددساختار متفاوتی ایجاد می‌شود.۹. تأخیرهایکی از عوامل مهم رفتار عجیب سیستم‌ها، تأخیر زمانی است.مثلاً اگر دولت امروز تصمیمی بگیرد ولی نتیجه آن دو سال بعد ظاهر شود، ممکن است قبل از دیدن نتیجه، چند تصمیم دیگر هم بگیرد.در نتیجه ممکن است سیستم دچار:نوسانبیش‌واکنشیکمبودمازادشود.مثال ساده:اگر کشاورز امروز بذر بکارد، محصول فوراً ظاهر نمی‌شود. اگر هر روز به دلیل ندیدن محصول تصمیم خود را تغییر دهد، سیستم دچار مشکل می‌شود.۸ و ۷. بازخوردهااین قسمت بسیار مهم است.حلقه بازخورد منفیتمایل دارد سیستم را متعادل و پایدار کند.مثلاً:دمای بالا → کولر بیشتر کار می‌کند → دما پایین می‌آید.اگر قدرت این حلقه افزایش یابد، سیستم بهتر می‌تواند خودش را اصلاح کند.حلقه بازخورد مثبتتغییر را تقویت می‌کند.مثلاً:مشتری بیشتر → فروش بیشتر → درآمد بیشتر → تبلیغات بیشتر → مشتری بیشتراین می‌تواند باعث رشد سریع شود.بنابراین یکی از اهرم‌های قدرتمند این است که ببینیم:کدام حلقه بازخورد را باید تقویت یا تضعیف کنیم؟۶. جریان اطلاعاتاین یکی از اهرم‌های مهم Meadows است.سؤال اصلی:چه کسی چه اطلاعاتی را دارد و چه کسی ندارد؟گاهی لازم نیست قانون جدیدی ایجاد کنیم؛ فقط باید اطلاعات درست را در زمان مناسب به فرد مناسب برسانیم.مثلاً اگر کارخانه‌ای آلودگی تولید می‌کند ولی مدیران و مصرف‌کنندگان از میزان واقعی آن اطلاع ندارند، ایجاد یک سیستم شفاف گزارش‌دهی می‌تواند رفتار سیستم را تغییر دهد.اطلاعات خودش می‌تواند یک اهرم باشد.۵. قوانین سیستمقوانین مشخص می‌کنند:چه چیزی مجاز است؟چه چیزی ممنوع است؟چه کسی قدرت تصمیم‌گیری دارد؟چه کسی پاداش می‌گیرد؟چه کسی هزینه می‌دهد؟بنابراین تغییر قوانین می‌تواند بسیار قدرتمندتر از تغییر اعداد باشد.مثلاً اگر ساختار پاداش یک سازمان فقط کارمندانی را تشویق کند که «سریع‌تر» کار می‌کنند، ممکن است کیفیت قربانی سرعت شود.اگر معیار پاداش تغییر کند، رفتار سیستم هم تغییر می‌کند.۴. خودسازمان‌دهیاین یکی از قدرتمندترین نقاط اهرمی است.یعنی اجازه دهیم سیستم بتواند:یاد بگیرد،آزمایش کند،خودش را اصلاح کند،ساختارهای جدید ایجاد کند،با شرایط جدید سازگار شود.مثلاً یک سازمانی که کارکنانش اجازه ندارند هیچ روش جدیدی را امتحان کنند، ظرفیت خودسازمان‌دهی کمی دارد.در مقابل، سازمانی که اجازه آزمایش و یادگیری می‌دهد، می‌تواند خود را با محیط تغییر دهد.پیام مهم:گاهی به جای اینکه خودمان سیستم را طراحی کنیم، باید توانایی سیستم برای طراحی خودش را افزایش دهیم.۳. اهداف سیستماین نقطه بسیار مهم است.اگر هدف سیستم اشتباه باشد، حتی اگر سیستم بسیار کارآمد باشد، ممکن است نتیجه اشتباه تولید کند.مثلاً اگر هدف یک مدرسه فقط این باشد:«بیشترین نمره امتحان»ممکن است دانش‌آموزان یاد بگیرند فقط برای امتحان درس بخوانند.اما اگر هدف:«یادگیری عمیق و توانایی حل مسئله»باشد، رفتار کل سیستم آموزشی تغییر می‌کند.پس گاهی نباید بپرسیم:«چطور سیستم را کارآمدتر کنیم؟»بلکه باید بپرسیم:«این سیستم دقیقاً برای چه هدفی طراحی شده است؟»۲. پارادایم ذهنیاز اینجا Meadows وارد سطح عمیق‌تری می‌شود.پارادایم یعنی باورهای بنیادی ما درباره اینکه جهان چگونه کار می‌کند.مثلاً اگر باور داشته باشیم:«طبیعت فقط منبعی برای استفاده انسان است.»طراحی سیستم اقتصادی ما احتمالاً بر استخراج و مصرف بیشتر منابع متمرکز خواهد شد.اما اگر باور کنیم:«انسان بخشی از یک اکوسیستم وابسته به طبیعت است.»ممکن است کل ساختار تصمیم‌گیری تغییر کند.بنابراین گاهی مشکل در قانون یا ساختار نیست؛ مشکل در نحوه نگاه ما به واقعیت است.۱. فراتر رفتن از پارادایم‌هااز نظر Meadows قدرتمندترین نقطه اهرمی این است که بتوانیم حتی از پارادایم‌های خودمان هم فاصله بگیریم.یعنی بتوانیم بگوییم:«ممکن است چارچوب فکری‌ای که با آن جهان را می‌بینم، تنها یکی از چارچوب‌های ممکن باشد.»این یعنی انعطاف فکری.در این حالت فرد یا جامعه می‌تواند:باورهای بنیادی خود را زیر سؤال ببرد،دیدگاه‌های متفاوت را بررسی کند،در چارچوب قبلی گرفتار نشود،و در صورت لزوم کل مدل ذهنی خود را تغییر دهد.نکته بسیار مهم فصلMeadows یک نکته جالب دارد:ما معمولاً سراغ اهرم‌های ضعیف می‌رویم، چون آسان‌ترند.مثلاً:«بودجه را تغییر بده.»«مالیات را تغییر بده.»«یک قانون جدید بنویس.»اما تغییر:اطلاعات → قوانین → اهداف → پارادایممی‌تواند بسیار عمیق‌تر باشد.یک مثال برای فهم کل فصلفرض کنیم یک دانشگاه فقط می‌خواهد تعداد مقالات منتشرشده را افزایش دهد.اهرم ۱۲:پاداش هر مقاله را بیشتر کنیم.اهرم ۶:اطلاعات بیشتری درباره کیفیت مقالات منتشر کنیم.اهرم ۵:قوانین ارتقا را تغییر دهیم.اهرم ۳:هدف دانشگاه را از «تعداد مقاله» به «تولید دانش باکیفیت و اثرگذار» تغییر دهیم.اهرم ۲:پارادایم را تغییر دهیم:«موفقیت علمی = تعداد خروجی‌ها»به:«موفقیت علمی = یادگیری، دانش و اثر واقعی»می‌بینیم که هرچه به سمت بالای فهرست می‌رویم، مداخله بنیادی‌تر می‌شود.خلاصه امتحانی فصل ۶اگر بخواهی فصل را خیلی سریع برای امتحان مرور کنی:نقطه اهرمی = نقطه‌ای در ساختار سیستم که تغییر آن می‌تواند رفتار کل سیستم را تغییر دهد.۱۲ اهرم از ضعیف به قوی:پارامترها → بافرها → جریان‌های مادی → تأخیرها → بازخورد منفی → بازخورد مثبت → اطلاعات → قوانین → خودسازمان‌دهی → اهداف → پارادایم → فراتر رفتن از پارادایمسه نکته طلایی:تغییر اعداد معمولاً ساده است، اما اهرم ضعیفی است.تغییر ساختار، اطلاعات، قوانین و اهداف می‌تواند بسیار قدرتمندتر باشد.عمیق‌ترین تغییر، تغییر پارادایم ذهنی است.یک جمله برای حفظ کردن:هرچه از «اعداد و پارامترها» به سمت «ساختار، اهداف و پارادایم» برویم، مداخله سخت‌تر اما بالقوه قدرتمندتر می‌شود.

خلاصه فصل پنجم کتاب (Thinking in Systems: A Primer)

Farokh Hasanzadeh — Thu, 10 Sep 2026 21:53:42 +0330

System Traps … and Opportunities«دام‌های سیستم‌ها... و فرصت‌ها»مدوز می‌گوید بسیاری از مشکلاتی که در سازمان‌ها، اقتصاد، سیاست، محیط‌زیست و زندگی روزمره می‌بینیم، اتفاقات تصادفی نیستند؛ بلکه نتیجه‌ی ساختارهای تکرارشونده‌ی سیستم‌ها هستند. این ساختارها را می‌توان «System Archetypes» یا الگوهای بنیادی سیستم نامید. نکته امیدوارکننده این است که اگر ساختار دام را بشناسیم، می‌توانیم آن را تغییر دهیم.ایده اصلی فصل در یک جملهاگر یک سیستم دائماً نتیجه بدی تولید می‌کند، فقط افراد را مقصر ندان؛ ساختاری را پیدا کن که افراد را به تولید آن نتیجه سوق می‌دهد.مدوز تأکید می‌کند که سرزنش کردن افراد، فشار بیشتر برای اجرای سیاست، یا دستکاری‌های سطحی معمولاً مشکل ساختاری را حل نمی‌کند. راه‌حل واقعی، تغییر ساختار سیستم است.۱. دام اول: Policy Resistanceمقاومت سیاستی — «راه‌حل‌هایی که شکست می‌خورند»این همان چیزی است که در فصل چهارم هم به آن اشاره کردیم، اما اینجا خیلی عمیق‌تر توضیح داده می‌شود.فرض کن چند گروه مختلف در یک سیستم، هدف‌های متفاوتی دارند.هر گروه تلاش می‌کند وضعیت را به نفع خودش تغییر دهد.مثلاً:دولت می‌خواهد قیمت‌ها را پایین بیاورد.تولیدکننده می‌خواهد سود بیشتری داشته باشد.مصرف‌کننده قیمت پایین‌تر می‌خواهد.کارگر دستمزد بالاتر می‌خواهد.هرکس منطقی رفتار می‌کند.اما مجموع این رفتارهای منطقی می‌تواند نتیجه‌ای ایجاد کند که هیچ‌کس نمی‌خواهد.این همان Policy Resistance است.مثال سادهدولت می‌گوید:«قیمت مسکن زیاد است؛ باید کمک مالی بیشتری به خریداران بدهیم.»کمک مالی:→ قدرت خرید مردم ↑→ تقاضا ↑→ قیمت خانه ↑در نتیجه ممکن است سیاستی که برای ارزان‌تر کردن مسکن طراحی شده، خودش قیمت را بالا ببرد.راه‌حل مدوزبه جای اینکه فقط فشار بیشتری به سیستم وارد کنیم:اهداف بازیگران مختلف را پیدا کن و ساختاری ایجاد کن که این اهداف کمتر با یکدیگر تضاد داشته باشند.او حتی پیشنهاد می‌کند انرژی‌ای که صرف مقاومت می‌شود، برای پیدا کردن هدف مشترک بزرگ‌تر استفاده شود.۲. دام دوم: Tragedy of the Commonsتراژدی منابع مشترکاین یکی از معروف‌ترین دام‌های سیستم‌هاست.فرض کن یک چراگاه مشترک داریم.هر دامدار می‌تواند یک گاو دیگر وارد چراگاه کند.برای هر فرد:گاو بیشتر → سود بیشتراما هزینه‌ی اضافه‌چرانی بین همه تقسیم می‌شود.بنابراین هر دامدار با خودش می‌گوید:«اگر من یک گاو دیگر اضافه کنم، سودش برای من است؛ ولی ضررش بین همه تقسیم می‌شود.»پس همه همین کار را می‌کنند.نتیجه:چراگاه بیش از حد استفاده می‌شود → منابع از بین می‌روند → همه ضرر می‌کنند.نکته ظریفهیچ‌کدام از دامداران لزوماً آدم بدی نیستند.اتفاقاً هرکدام کاملاً منطقی رفتار می‌کنند.مشکل در ساختار سیستم است.یعنی:رفتار عقلانی فردی می‌تواند نتیجه‌ای غیرعقلانی برای کل سیستم ایجاد کند.راه‌های خروج از این داممدوز سه راه اصلی مطرح می‌کند:۱. آموزش و اقناعمردم بفهمند که استفاده بیش از حد چه پیامدی دارد.۲. خصوصی‌سازیمنبع را به بخش‌هایی تقسیم کنیم تا فرد هزینه‌ی رفتار خودش را بیشتر احساس کند.۳. Regulation — تنظیم و قانون‌گذاریبرای استفاده از منبع، قواعد مشترک تعیین کنیم.مثلاً:سهمیهمجوزمالیاتمحدودیت مصرفجریمهمدوز نشان می‌دهد که هدف اصلی این قوانین باید بازگرداندن Feedback گمشده باشد؛ یعنی فرد اثر واقعی استفاده خودش از منبع را ببیند.۳. دام سوم: Drift to Low Performanceلغزش تدریجی به عملکرد پاییناین دام خیلی خطرناک است چون معمولاً ناگهان اتفاق نمی‌افتد.سیستم کم‌کم بدتر می‌شود.مثلاً:سال اول:کیفیت = ۹۰٪سال بعد:۸۸٪بعد:۸۵٪بعد:۸۲٪اما چون هر تغییر کوچک است، کسی بحران را احساس نمی‌کند.در نتیجه استاندارد ما هم پایین می‌آید.یعنی:عملکرد ↓→ انتظار ↓→ فاصله بین عملکرد و انتظار کمتر می‌شود→ فشار برای اصلاح ↓→ عملکرد دوباره ↓این یک Reinforcing Loop است.اسم دیگر این دام:Eroding Goals«فرسایش اهداف»یعنی به جای اینکه عملکرد را بالا ببریم، هدف را پایین می‌آوریم تا با عملکرد ضعیف سازگار شود.مثال خیلی سادهفرض کن یک شرکت زمانی پاسخ مشتریان را در ۲۴ ساعت می‌داد.بعد شد:۴۸ ساعت → «اشکالی ندارد.»بعد:۷۲ ساعت → «شرایط سخت شده.»بعد:یک هفته → «همه شرکت‌ها همین‌طورند.»در نهایت سازمان دیگر حتی به یاد نمی‌آورد که زمانی عملکرد بسیار بهتری داشته است.راه خروج:استاندارد عملکرد را به یک مرجع مستقل و قابل‌اعتماد متصل کن، نه اینکه استاندارد را با عملکرد فعلی تنظیم کنی.۴. دام چهارم: Escalationتشدید رقابتساختار این دام خیلی ساده است:من کمی جلو می‌افتم → تو باید بیشتر جلو بیفتی → من دوباره بیشتر → تو دوباره بیشتر...یعنی:A ↑ ↓ B ↑ ↓ A ↑↑ ↓ B ↑↑ ↓ ...این یک Reinforcing Loop است.مثال معروف: مسابقه تسلیحاتیکشور A:«کشور B سلاح بیشتری دارد.»پس سلاح بیشتری می‌سازد.کشور B:«کشور A سلاح بیشتری ساخته.»پس خودش هم سلاح بیشتری می‌سازد.A دوباره واکنش نشان می‌دهد...و این چرخه ادامه پیدا می‌کند.نکته جالب:هر دو طرف خودشان را قربانی طرف مقابل می‌دانند.اما از دید سیستم:هر دو طرف در حال تقویت همان حلقه‌ای هستند که باعث مسابقه شده است.این فقط درباره جنگ نیستهمین ساختار را می‌توان در:جنگ قیمت‌هارقابت سیاسیتبلیغاترقابت ثروتشبکه‌های اجتماعیرقابت سازمانیدید.مثلاً:شرکت A قیمت را پایین می‌آورد→ شرکت B قیمت را پایین می‌آورد→ A دوباره پایین می‌آورد→ B دوباره...تا جایی که هر دو شرکت ممکن است سودشان را از دست بدهند.راه خروجمدوز دو راه اصلی پیشنهاد می‌کند:۱. از مسابقه خارج شویعنی عمداً حلقه تقویت‌کننده را قطع کن.۲. قواعد جدید ایجاد کنیعنی یک Balancing Loop بساز که رقابت را محدود کند.۵. دام پنجم: Success to the Successful«موفقیت، موفقیت بیشتری می‌آورد»این دام زمانی ایجاد می‌شود که:برنده‌ی دور اول، منابع بیشتری برای برنده شدن در دور بعدی دریافت کند.مثلاً:موفقیت→ پول بیشتر→ امکانات بیشتر→ موفقیت بیشتر→ پول بیشتر→ ...این یک Reinforcing Loop است.مثالدو دانش‌آموز داریم.دانش‌آموز A امکانات آموزشی بیشتری دارد.→ نمره بهتر می‌گیرد.نمره بهتر:→ فرصت‌های بهترفرصت بهتر:→ امکانات بیشترو دوباره:→ نمره بهتردر نهایت فاصله بیشتر و بیشتر می‌شود.در اقتصاد هم همین اتفاق می‌افتدثروت:→ سرمایه بیشتر→ درآمد بیشتر→ ثروت بیشتردر نتیجه ممکن است سیستم به سمت:Winner takes moreحرکت کند.مدوز برای خروج از این دام پیشنهادهایی مثل:تنوع‌بخشیمحدود کردن تمرکزایجاد فرصت برای بازندگانهموار کردن زمین بازیرا مطرح می‌کند.۶. دام ششم: Shifting the Burden to the Intervenorانتقال بار به مداخله‌گر — یا Addictionاین یکی خیلی مهم است.فرض کن یک سیستم مشکل دارد.یک نفر یا سازمان وارد می‌شود و مشکل را برای سیستم حل می‌کند.در کوتاه‌مدت:مشکل ↓اما سیستم یاد نمی‌گیرد خودش مشکل را حل کند.بنابراین دفعه بعد:وابستگی ↑و دوباره مداخله‌گر باید وارد شود.بعد:وابستگی بیشتر → توانایی داخلی کمتر → نیاز بیشتر به مداخله‌گرو این تبدیل به یک چرخه می‌شود.مثال سادهفرض کن یک مدیر همیشه مشکلات کارکنانش را خودش حل می‌کند.کارمند:«این مشکل را چه کار کنم؟»مدیر بلافاصله تصمیم می‌گیرد.کارمند یاد نمی‌گیرد تصمیم بگیرد.دفعه بعد:«باز هم مدیر بگوید چه کار کنم.»در نهایت:مدیر بیش‌ازحد درگیر + کارمند وابستهراه خروجبه جای اینکه فقط علامت مشکل را برطرف کنیم، باید توانایی خود سیستم را برای حل مشکل تقویت کنیم.مدوز می‌گوید مداخله‌گر باید در نهایت کاری کند که سیستم بتواند بدون او مسئله را حل کند و سپس کنار برود.سؤال‌های مهم:چرا مکانیسم طبیعی اصلاح مشکل کار نمی‌کند؟چه چیزی جلوی آن را گرفته؟چطور می‌توانیم توانایی خود سیستم را افزایش دهیم؟۷. دام هفتم: Rule Beatingدور زدن قوانینگاهی قانونی وضع می‌کنیم، اما افراد راهی پیدا می‌کنند که:قانون را ظاهراً رعایت کنند ولی هدف قانون را دور بزنند.مثلاً قانون می‌گوید:سرعت بیشتر از ۱۰۰ ممنوع.راننده فقط وقتی پلیس را می‌بیند سرعت را کم می‌کند.پس:Rule followedاما:Goal not achievedاین تفاوت خیلی مهم است.رعایت قانون ≠ تحقق هدف قانونمدوز مثال‌های مختلفی از این پدیده در سیاست‌گذاری و اقتصاد می‌آورد.۸. دام هشتم: Seeking the Wrong Goalهدف اشتباهاین یکی از خطرناک‌ترین دام‌هاست.اگر هدف سیستم را اشتباه تعریف کنیم، سیستم ممکن است باورنکردنی خوب کار کند تا به نتیجه اشتباه برسد.مثلاً اگر بگوییم:«هدف آموزش = نمره آزمون»سیستم بهینه می‌شود برای:نمره بالانه لزوماً:یادگیری واقعییا اگر بگوییم:«هدف امنیت ملی = مقدار پول خرج‌شده برای ارتش»سیستم پول بیشتری برای ارتش تولید می‌کند، اما الزاماً امنیت بیشتر ایجاد نمی‌کند.مدوز می‌گوید باید مراقب باشیم:Effort را با Result اشتباه نگیریم.۹. چرا این دام‌ها مهم‌اند؟چون نکته مشترک همه آن‌ها این است:افراد لزوماً رفتار احمقانه‌ای ندارند.اغلب افراد دارند:در چارچوب اطلاعات، انگیزه‌ها و محدودیت‌های خودشان منطقی رفتار می‌کنند.اما:رفتار منطقی افراد + ساختار بد سیستم = نتیجه بداین همان چیزی است که مدوز می‌خواهد ما ببینیم.🧩 همه دام‌ها را یکجا ببیندامساختار اصلینتیجهPolicy Resistanceاهداف متضادتغییر بسیار سختTragedy of the Commonsسود فردی، هزینه جمعینابودی منبع مشترکDrift to Low Performanceکاهش تدریجی استانداردافت مداومEscalationرقابت تقویت‌کنندهمسابقه بی‌پایانSuccess to the Successfulبرنده منابع بیشتری می‌گیردتمرکز و نابرابریShifting the Burdenحل علامت به‌جای ریشهوابستگیRule Beatingدور زدن قواعدهدف محقق نمی‌شودWrong Goalشاخص اشتباه به‌عنوان هدفسیستم نتیجه اشتباه تولید می‌کند🎯 مهم‌ترین نکته فصل: «دام = فرصت»مدوز عمداً کلمه Opportunities را به عنوان دوم فصل اضافه کرده است.چرا؟چون وقتی ساختار دام را بشناسیم، می‌توانیم ساختار را برعکس کنیم.مثلاً:Policy Resistanceاهداف متضاد → هدف مشترک پیدا کنTragedy of Commonsمصرف فردی بدون هزینه واقعی → Feedback واقعی ایجاد کنDrift to Low Performanceهدف دائماً پایین می‌آید → استاندارد مستقل حفظ کنEscalationرقابت تقویت‌کننده → حلقه را قطع کنSuccess to the Successfulبرنده منابع بیشتری می‌گیرد → فرصت‌ها را متعادل کنShifting the Burdenسیستم وابسته می‌شود → توانایی داخلی را تقویت کنRule Beatingقانون دور زده می‌شود → هدف واقعی را بررسی کنWrong Goalشاخص با هدف اشتباه گرفته شده → هدف واقعی را تعریف کن🧠 یک مثال ترکیبی برای فهم فصلفرض کن یک دانشگاه می‌خواهد رتبه‌اش را بالا ببرد.می‌گوید:«هرچه مقاله بیشتر، دانشگاه بهتر.»پس بودجه و پاداش را بر اساس تعداد مقاله می‌دهد.اساتید:→ مقاله‌های بیشتری تولید می‌کنند.اما ممکن است:→ کیفیت پژوهش کاهش پیدا کند.→ همکاری بین‌رشته‌ای کم شود.→ پژوهش‌های کوتاه و کم‌عمق افزایش پیدا کند.→ افراد فقط چیزهایی را پژوهش کنند که سریع‌تر مقاله می‌شوند.یعنی دانشگاه وارد دام:Wrong Goalشده است.اگر استادان موفق‌تر بودجه بیشتری بگیرند و به مرور امکانات بیشتری جمع کنند:Success to the Successfulهم ایجاد می‌شود.اگر مدیران هر بار مشکل پژوهشی را خودشان حل کنند:Shifting the Burdenایجاد می‌شود.و اگر هر دانشکده برای گرفتن بودجه بیشتر با دانشکده‌های دیگر رقابت کند:Escalationممکن است شکل بگیرد.یعنی:یک سیستم واقعی می‌تواند هم‌زمان در چند دام گرفتار باشد.⭐ خلاصه خیلی فشرده فصل ۵اگر بخواهم کل فصل را در ۸ جمله خلاصه کنم:بسیاری از مشکلات پایدار، نتیجه‌ی ساختار سیستم هستند نه اشتباه یک فرد.وقتی بازیگران مختلف هدف‌های متفاوت دارند، سیستم ممکن است در برابر تغییر مقاومت کند.منابع مشترک بدون Feedback مناسب می‌توانند به تراژدی منابع مشترک منجر شوند.استانداردهای پایین می‌توانند به‌تدریج عادی شوند و سیستم را به سمت عملکرد ضعیف ببرند.رقابت بین دو بازیگر می‌تواند به یک حلقه‌ی تشدیدکننده و مخرب تبدیل شود.موفقیت اولیه می‌تواند منابع بیشتری برای موفقیت بعدی ایجاد کند و نابرابری را تشدید کند.کمک مداوم به سیستم ممکن است توانایی خودش برای حل مسئله را ضعیف و وابستگی ایجاد کند.برای خروج از دام، باید ساختار Feedback، انگیزه‌ها، اطلاعات و اهداف را تغییر داد—not فقط فشار بیشتری به سیستم وارد کرد. 🔑 و اگر فقط یک چیز از فصل ۵ یادت بماند:وقتی یک مشکل بارها و بارها با وجود تلاش‌های زیاد برمی‌گردد، احتمالاً مشکل از «آدم‌ها» نیست؛ باید دنبال ساختاری بگردی که آن مشکل را دائماً تولید می‌کند.این فصل در واقع پلی است به فصل ششم: Leverage Points؛ یعنی حالا که فهمیدیم سیستم‌ها در چه دام‌هایی گرفتار می‌شوند

خلاصه فصل چهارم کتاب (Thinking in Systems: A Primer)

Farokh Hasanzadeh — Thu, 10 Sep 2026 21:52:14 +0330

Why Systems Surprise Us«چرا سیستم‌ها ما را غافلگیر می‌کنند؟»در فصل‌های قبل یاد گرفتیم سیستم چیست، Feedback چگونه کار می‌کند و سیستم‌های خوب چه ویژگی‌هایی دارند. این فصل یک قدم مهم‌تر می‌رود و توضیح می‌دهد چرا با وجود اینکه فکر می‌کنیم یک سیستم را می‌شناسیم، باز هم نتیجه‌ی اقداماتمان اغلب غیرمنتظره می‌شود.پیام اصلی فصل: ما معمولاً سیستم‌ها را به شکل خطی و ساده می‌بینیم، در حالی که رفتار واقعی آن‌ها از روابط، حلقه‌های بازخورد، تأخیرها و ساختارهای پیچیده به وجود می‌آید.**۱. مشکل اصلی: ما دنیا را خطی می‌بینیمذهن انسان دوست دارد روابط را این‌گونه تصور کند:A → B → Cمثلاً:مالیات را کم می‌کنیم → مردم پول بیشتری دارند → اقتصاد بهتر می‌شود.یا:قیمت را پایین می‌آوریم → مردم بیشتر خرید می‌کنند → فروش بیشتر می‌شود.اما سیستم‌ها معمولاً این‌قدر ساده نیستند.در یک سیستم:A روی B اثر می‌گذارد، B روی C، C دوباره روی A و...یعنی:A → B → C ↑ ↓ └───────┘همین حلقه‌ها می‌توانند نتایج کاملاً متفاوتی ایجاد کنند.۲. علت و معلول همیشه نزدیک به هم نیستندیکی از اشتباهات بزرگ ما این است که فکر می‌کنیم علت باید نزدیک به معلول باشد.مثلاً اگر امروز:قیمت بنزین افزایش پیدا کردممکن است بلافاصله بگوییم:«پس مردم کمتر رانندگی می‌کنند.»اما شاید اثر واقعی افزایش قیمت، بعد از ماه‌ها یا سال‌ها ظاهر شود:افزایش قیمت→ مردم خودروهای کم‌مصرف‌تر می‌خرند→ ترکیب خودروها تغییر می‌کند→ مصرف سوخت تغییر می‌کندبنابراین:بین علت و نتیجه ممکن است فاصله‌ی زمانی زیادی وجود داشته باشد.این همان Delay است که در فصل ۲ دیدیم.۳. سیستم‌ها معمولاً «غیرخطی» هستنداین یکی از مفاهیم اصلی فصل است.در یک رابطه خطی، مثلاً:دو برابر ورودی → دو برابر خروجیاما در سیستم‌های پیچیده، چنین چیزی تضمین‌شده نیست.ممکن است:دو برابر فشار → ده برابر نتیجهیا:ده برابر تلاش → تقریباً هیچ نتیجه‌ایباشد.مثالفرض کن یک دریاچه مقدار محدودی آلودگی را می‌تواند جذب کند.تا یک نقطه:آلودگی بیشتر → تغییر کمی در اکوسیستماما بعد از عبور از یک آستانه:آلودگی کمی بیشتر → فروپاشی شدید اکوسیستمیعنی رابطه خطی نیست.۴. Threshold — آستانهسیستم‌ها گاهی تا مدت‌ها ظاهراً خوب کار می‌کنند، اما وقتی از یک آستانه عبور کنند، رفتارشان ناگهان تغییر می‌کند.مثلاً:وضعیت سیستم خوب ────────────────┐ │ ↓ Threshold │ ↓ بد ────────────────┘این موضوع در:محیط زیستاقتصادجمعیتسلامت اکوسیستم‌هابازارهاسازمان‌هابسیار مهم است.نکته:ممکن است سیستم مدت زیادی مقاوم به نظر برسد، ولی در واقع به یک نقطه بحرانی نزدیک شده باشد.۵. محدودیت‌ها رفتار سیستم را تعیین می‌کنندما اغلب روی چیزی تمرکز می‌کنیم که بیشتر در دسترس است.مثلاً می‌گوییم:«اگر سرمایه بیشتری داشته باشیم، تولید را افزایش می‌دهیم.»اما شاید مشکل اصلی سرمایه نباشد.ممکن است محدودیت واقعی:نیروی انسانیمواد اولیهانرژیظرفیت کارخانهبازارآبزمانباشد.این یعنی:رشد معمولاً توسط محدودکننده‌ترین عامل تعیین می‌شود.مثلاً اگر یک کارخانه ۱۰۰ میلیون دلار سرمایه داشته باشد ولی آب کافی نداشته باشد، اضافه کردن پول الزاماً تولید را افزایش نمی‌دهد.۶. قانون «محدودکننده» را فراموش نکنفرض کن یک سیستم برای رشد به سه چیز نیاز دارد:سرمایه + نیروی انسانی + مواد اولیهاگر:سرمایه = زیادنیروی انسانی = زیادمواد اولیه = کمباشد،مواد اولیه تبدیل به Limiting Factor می‌شود.پس افزایش سرمایه و نیروی انسانی ممکن است تقریباً هیچ اثری نداشته باشد.این یکی از دلایلی است که:بهینه‌سازی یک قسمت از سیستم الزاماً عملکرد کل سیستم را بهتر نمی‌کند.۷. بهینه‌سازی یک قسمت ممکن است سیستم را بدتر کنداین ایده در کتاب خیلی مهم است.فرض کن در یک بیمارستان، هدف بخش اورژانس این باشد:«هر بیمار را در سریع‌ترین زمان ممکن از اورژانس خارج کنیم.»اگر این هدف را بیش از حد دنبال کنیم، ممکن است:بیماران سریع‌تر ترخیص شوند،اما بخش‌های دیگر بیمارستان تحت فشار قرار بگیرند،تشخیص ناقص شود،بیماران دوباره برگردند.در نتیجه:عملکرد یک بخش ↑اما:عملکرد کل سیستم ↓مدوز به این نوع نگاه هشدار می‌دهد.Suboptimization یعنی یک جزء را بهینه کنیم و کل سیستم را بدتر کنیم.۸. سیستم‌ها هدف‌های متعددی دارندیک سیستم واقعی معمولاً فقط یک هدف ندارد.مثلاً یک شرکت ممکن است هم‌زمان بخواهد:سود را افزایش دهد،کیفیت را حفظ کند،هزینه را کاهش دهد،کارکنان را نگه دارد،مشتری را راضی نگه دارد،رشد کند.این اهداف گاهی با هم تعارض دارند.اگر فقط یکی را بهینه کنیم، ممکن است دیگری آسیب ببیند.پس:نباید یک شاخص را با کل عملکرد سیستم اشتباه بگیریم.۹. شاخص‌ها همیشه واقعیت را نشان نمی‌دهندیکی از نکات ظریف فصل این است که ما معمولاً چیزی را که قابل اندازه‌گیری است با چیزی که واقعاً مهم است اشتباه می‌گیریم.مثلاً در آموزش:نمره امتحان ↑ممکن است نتیجه بگیریم:«یادگیری بهتر شده.»اما شاید دانش‌آموز فقط برای امتحان حفظ کرده باشد.پس:Indicator ≠ Realityشاخص فقط یک نماینده از واقعیت است.اگر بیش از حد روی شاخص تمرکز کنیم، ممکن است افراد یاد بگیرند شاخص را بهینه کنند، نه خود سیستم را.۱۰. «قانون گودارت» و خطر شاخص‌هایکی از ایده‌های مهم این بخش این است:وقتی یک شاخص تبدیل به هدف شود، دیگر لزوماً شاخص خوبی باقی نمی‌ماند.مثلاً اگر به معلمان بگوییم:«موفقیت مدرسه بر اساس نمره آزمون است.»ممکن است سیستم به سمت:آموزش برای امتحانحرکت کند.نمره بالا می‌رود، اما لزوماً یادگیری واقعی بالا نرفته است.این یک نمونه از:Perverse Incentiveاست؛ یعنی انگیزه‌ای که ظاهراً برای بهبود سیستم طراحی شده، اما رفتارهایی ایجاد می‌کند که در نهایت سیستم را خراب می‌کنند.۱۱. سیستم‌ها به «ساختار» واکنش نشان می‌دهند، نه به نیت مااین جمله را خیلی خوب به خاطر بسپار:Good intentions do not guarantee good outcomes.ممکن است سیاست‌گذار واقعاً بخواهد یک مشکل را حل کند.اما اگر ساختار سیستم را درست نفهمیده باشد، مداخله او می‌تواند نتیجه معکوس بدهد.مثلاً:هدف: کاهش ترافیکراه‌حل: ساختن بزرگراه جدیدابتدا:ترافیک ↓اما بعد:بزرگراه بهتر→ رانندگی جذاب‌تر→ افراد بیشتری خودرو استفاده می‌کنند→ سفرهای بیشتری شکل می‌گیرد→ ترافیک دوباره ↑این همان چیزی است که Systems Thinking می‌خواهد به ما نشان دهد:سیستم می‌تواند به مداخله‌ی ما پاسخ دهد و خودش را دوباره تنظیم کند.۱۲. Policy Resistance — مقاومت سیاستیاین مفهوم خیلی مهم است.گاهی افراد مختلف در یک سیستم، هرکدام سعی می‌کنند سیستم را در جهت مطلوب خودشان تغییر دهند.اما سیستم از طریق Feedbackها در برابر این تغییر مقاومت می‌کند.مثلاً:دولت می‌خواهد قیمت مسکن را پایین بیاورد.→ سیاستی برای افزایش عرضه ایجاد می‌کند.اما:عرضه ↑→ تقاضا از مناطق دیگر وارد می‌شود→ قیمت زمین ↑→ هزینه ساخت ↑→ اثر سیاست کمتر می‌شود.یعنی سیستم در برابر مداخله مقاومت می‌کند.مدوز می‌گوید این مقاومت لزوماً به معنای «بد بودن افراد» نیست؛ اغلب ساختار خود سیستم باعث آن است.۱۳. چرا سیستم‌ها رفتار غیرمنتظره دارند؟مدوز چند دلیل اصلی را کنار هم قرار می‌دهد:۱. Feedback Loopsحلقه‌های بازخورد۲. Delaysتأخیرها۳. Nonlinearityروابط غیرخطی۴. محدودیت منابعLimits۵. اهداف متعددMultiple goals۶. ساختارهای سلسله‌مراتبیHierarchy۷. Adaptationتوانایی سیستم برای سازگار شدنهمه این‌ها باعث می‌شوند:مداخله ساده → نتیجه پیچیده۱۴. «رویداد» را با «الگو» اشتباه نگیریممدوز می‌گوید یک اشتباه مهم این است که فقط اتفاقات منفرد را ببینیم.مثلاً:«امسال قیمت‌ها افزایش پیدا کرد.»این یک Event است.اما Systems Thinking می‌پرسد:«چرا طی ۱۰ سال گذشته قیمت‌ها مرتباً افزایش یافته‌اند؟»اینجا به Pattern می‌رسیم.و سپس سؤال مهم‌تر:«چه ساختاری باعث ایجاد این الگو شده است؟»اینجا به System Structure می‌رسیم.پس سه سطح داریم:Event ↓ Pattern ↓ System Structureو هرچه پایین‌تر برویم، به علت‌های بنیادی‌تر نزدیک می‌شویم.۱۵. مثال ساده برای این سه سطحفرض کن فروش یک شرکت کاهش پیدا کرده.Event:فروش این ماه کم شده.Pattern:فروش طی دو سال مرتباً در حال کاهش است.Structure:محصول قدیمی شده،تحقیق و توسعه کم شده،مشتریان اطلاعات کافی ندارند،پاداش مدیران کوتاه‌مدت است،سرمایه‌گذاری بلندمدت کاهش یافته.حالا می‌توانیم مشکل واقعی را ببینیم.اگر فقط Event را ببینیم، ممکن است بگوییم:«تخفیف بدهیم!»اما اگر Structure را ببینیم، شاید بفهمیم:سیستم نوآوری شرکت خراب شده است.۱۶. یکی از مهم‌ترین درس‌های فصل: «ساختار رفتار را تولید می‌کند»مدوز تأکید می‌کند:برای فهمیدن رفتار یک سیستم، به ساختارش نگاه کن.اگر یک سیستم دائماً رفتار خاصی را تکرار می‌کند، احتمال زیادی وجود دارد که مشکل در:ساختار Feedbackهاباشد، نه در یک اتفاق منفرد یا یک فرد خاص.به همین دلیل، تغییر افراد بدون تغییر ساختار ممکن است مشکل را حل نکند.۱۷. چرا پیش‌بینی سیستم‌ها سخت است؟چون ما معمولاً:مدل ذهنی ساده‌ای از سیستم داریم.مثلاً:«اگر X را زیاد کنیم، Y هم زیاد می‌شود.»اما سیستم واقعی ممکن است:X ↑ → Y ↑ → Z ↓ → Feedback → X ↓باشد.بنابراین پیش‌بینی ما اشتباه می‌شود.مدوز می‌گوید به جای اینکه بیش از حد به پیش‌بینی دقیق آینده اعتماد کنیم، بهتر است:سناریوهای مختلف و رفتار احتمالی سیستم را بررسی کنیم.یعنی به جای:«سال آینده دقیقاً چه اتفاقی می‌افتد؟»بپرسیم:«اگر این روند ادامه پیدا کند، چه رفتارهایی ممکن است ظاهر شوند؟»۱۸. مدل ذهنی ما بخشی از مشکل استاین قسمت بسیار مهم است.سیستم‌ها فقط پیچیده نیستند؛ ذهن ما هم سیستم را ساده‌سازی می‌کند.ما معمولاً:چیزهای نزدیک را مهم‌تر می‌بینیم،تأخیرها را نادیده می‌گیریم،روابط غیرخطی را خطی فرض می‌کنیم،دنبال یک علت واحد می‌گردیم،به رویدادها بیشتر از الگوها توجه می‌کنیم.بنابراین یکی از موانع اصلی Systems Thinking:خودِ مدل ذهنی ماست.🧠 نقشه ذهنی فصل ۴ WHY SYSTEMS SURPRISE US │ ┌──────────────┼──────────────┐ ↓ ↓ ↓ Feedback Delays Nonlinearity │ │ │ ↓ ↓ ↓ Unexpected Oscillation Thresholds behavior │ ↓ Policy Resistance │ ↓ Suboptimization │ ↓ Wrong intervention │ ↓ Unintended consequences🎯 خلاصه امتحانی فصل ۴اگر فقط ۱۲ نکته بخواهی:سیستم‌ها معمولاً خطی نیستند.علت و معلول می‌تواند فاصله زمانی زیادی داشته باشد.Delay می‌تواند باعث نوسان و نتایج غیرمنتظره شود.سیستم‌ها ممکن است Threshold داشته باشند.افزایش یک ورودی لزوماً خروجی را به همان نسبت افزایش نمی‌دهد.رفتار سیستم اغلب توسط محدودکننده‌ترین عامل تعیین می‌شود.بهینه‌سازی یک جزء می‌تواند کل سیستم را بدتر کند.شاخص قابل‌اندازه‌گیری همیشه معادل واقعیت نیست.تبدیل یک شاخص به هدف می‌تواند رفتارهای مخرب ایجاد کند.سیستم‌ها می‌توانند در برابر سیاست‌ها Policy Resistance نشان دهند.برای فهم مشکل باید از Event → Pattern → Structure حرکت کنیم.مهم‌ترین علت غافلگیری ما، نادیده گرفتن Feedback، Delay، Nonlinearity و Structure است.⭐ مهم‌ترین پیام فصل ۴اگر بخواهیم چهار فصل اول را به هم وصل کنیم:فصل ۱:سیستم چیست؟↓فصل ۲:سیستم‌ها چگونه با Feedback رفتار می‌کنند؟↓فصل ۳:چه چیزی باعث می‌شود سیستم‌ها تاب‌آور و سازگار باشند؟↓فصل ۴:پس چرا با وجود همه این‌ها، سیستم‌ها ما را غافلگیر می‌کنند؟و پاسخ مدوز تقریباً این است:چون ما معمولاً به رویدادهای قابل مشاهده نگاه می‌کنیم، در حالی که رفتار سیستم توسط ساختارهای عمیق‌تر، حلقه‌های بازخورد، تأخیرها، محدودیت‌ها و روابط غیرخطی ایجاد می‌شود.یک فرمول ذهنی برای فصل ۴:Event → Pattern → Structure → Feedback → Behavior

خلاصه فصل سوم کتاب (Thinking in Systems: A Primer)

Farokh Hasanzadeh — Thu, 10 Sep 2026 21:49:53 +0330

چرا سیستم‌ها این‌قدر خوب کار می‌کنند؟ایده اصلی در یک جملهسیستم‌های خوب فقط به این دلیل خوب کار نمی‌کنند که پایدارند؛ آن‌ها توانایی برگشتن بعد از اختلال، تغییر دادن ساختار خود و سازمان‌دهی شدن در سطوح مختلف را دارند.مدوز می‌گوید اگر فقط دنبال ثبات یا بهره‌وری باشیم، ممکن است دقیقاً ویژگی‌هایی را از بین ببریم که سیستم را در بلندمدت سالم نگه می‌دارند.۱. Resilience — تاب‌آوریاولین ویژگی یک سیستم خوب، تاب‌آوری است.تاب‌آوری یعنی:سیستم وقتی با یک شوک، اختلال یا تغییر مواجه می‌شود، بتواند خودش را بازیابی کند و به عملکردش ادامه دهد.مثلاً بدن انسان را تصور کن.بدن دائماً با:تغییر دماکمبود یا زیادی غذابیماریآسیبمیکروب‌هامواجه می‌شود.اما معمولاً خودش را تنظیم می‌کند و به وضعیت قابل‌قبولی برمی‌گرداند.این یعنی Resilience.۲. تاب‌آوری با «ثبات» یکی نیستاین یکی از مهم‌ترین نکات فصل است.ممکن است فکر کنیم:«هرچه یک سیستم کمتر تغییر کند، سیستم بهتری است.»مدوز می‌گوید نه لزوماً.یک سیستم ممکن است ظاهراً بسیار ثابت باشد، اما در واقع بسیار شکننده شده باشد.مثلاً جنگلی را تصور کن که برای افزایش تولید چوب، تقریباً همه‌ی گونه‌های مختلف آن حذف شده‌اند و فقط یک نوع درخت باقی مانده است.از بیرون:سیستم منظم و قابل پیش‌بینی است.اما اگر یک آفت مخصوص آن درخت وارد شود:کل جنگل ممکن است آسیب ببیند.چرا؟چون تنوع و مسیرهای جایگزین از بین رفته‌اند.پس:Stability ≠ Resilienceثبات یعنی وضعیت فعلی زیاد تغییر نکند.تاب‌آوری یعنی اگر تغییر بزرگی اتفاق افتاد، سیستم بتواند خودش را بازیابی کند.۳. تاب‌آوری از Feedbackهای متعدد می‌آیددر فصل ۲ دیدیم که Feedback Loopها رفتار سیستم را کنترل می‌کنند.اینجا مدوز یک قدم جلوتر می‌رود:یک سیستم بسیار تاب‌آور معمولاً فقط یک حلقه بازخورد ندارد.بلکه چندین حلقه دارد که:از مسیرهای مختلف کار می‌کنند،در مقیاس‌های زمانی مختلف عمل می‌کنند،و اگر یکی شکست خورد، دیگری می‌تواند وارد عمل شود.مثلاً بدن انسان فقط یک مکانیسم دفاعی ندارد.سیستم ایمنی، ترمیم بافت، تنظیم دما، تنظیم قند خون و ده‌ها مکانیسم دیگر هم‌زمان فعالیت می‌کنند.بنابراین:Redundancy یا وجود مسیرهای جایگزین، می‌تواند تاب‌آوری را افزایش دهد.۴. یک سیستم می‌تواند برای بهره‌وری بیشتر، تاب‌آوری خود را قربانی کنداین قسمت خیلی کاربردی است.فرض کن یک کارخانه می‌خواهد هزینه انبارداری را کاهش دهد.پس تصمیم می‌گیرد:«هیچ موجودی اضافی نگه نداریم؛ هر چیزی دقیقاً زمانی برسد که لازم است.»این همان Just-in-Time است.مزیت:هزینه کمتر + بهره‌وری بیشتراما مشکل:اگر حمل‌ونقل مختل شود، سوخت کم شود یا سیستم کامپیوتری خراب شود:کل زنجیره تولید ممکن است متوقف شود.یعنی:Productivity ↑ولی:Resilience ↓مدوز دقیقاً به همین تضاد اشاره می‌کند.۵. مثال مهم: کشاورزیفرض کن کشاورزی می‌خواهد بیشترین محصول ممکن را تولید کند.او ممکن است:فقط یک گونه محصول بکارد،آفت‌کش زیاد استفاده کند،تنوع زیستی را کاهش دهد،همه چیز را برای حداکثر تولید بهینه کند.در کوتاه‌مدت:Productivity ↑اما سیستم ممکن است در برابر یک بیماری یا تغییر اقلیمی بسیار آسیب‌پذیر شود.در مقابل، یک سیستم متنوع ممکن است در شرایط عادی کمی کم‌بازده‌تر باشد، ولی در برابر شوک‌ها بهتر دوام بیاورد.پس مدوز می‌گوید:یک سیستم را فقط بر اساس خروجی فعلی آن ارزیابی نکن؛ ظرفیت آن برای ادامه دادن در شرایط نامطمئن را هم ببین.۶. تاب‌آوری یک «فضای مانور» ایجاد می‌کندمدوز برای توضیح Resilience از تصویر یک فلات/سطح استفاده می‌کند.یک سیستم تاب‌آور فضای زیادی برای حرکت دارد.یعنی اگر شرایط تغییر کند، سیستم می‌تواند کمی بالا و پایین شود بدون اینکه سقوط کند.اما وقتی تاب‌آوری از بین می‌رود:سیستم تاب‌آور: _________ / \ _____/ \_____ فضای مانور زیاد سیستم شکننده: /\ _______/ \_______ فضای مانور بسیار کمسیستم شکننده ممکن است مدت‌ها کاملاً عادی به نظر برسد.اما یک روز:یک شوک نسبتاً کوچک → سقوط بزرگو این نکته مهم است:از دست رفتن تاب‌آوری ممکن است تا لحظه‌ی شکست قابل مشاهده نباشد.۷. Self-Organization — خودسازمان‌دهیویژگی دوم سیستم‌های قدرتمند:Self-Organizationیعنی سیستم بتواند:ساختار جدید ایجاد کند،خودش را تغییر دهد،یاد بگیرد،متنوع شود،پیچیده‌تر شود،و راه‌های جدیدی برای ادامه حیات پیدا کند. یک مثال خیلی سادهیک دانه را تصور کن.داخل یک دانه یک «نقشه کامل و دقیق از درخت» به شکل یک ساختمان آماده وجود ندارد.اما وقتی شرایط مناسب فراهم شود:دانه → ریشه → ساقه → برگ → درختسیستم خودش ساختار جدید ایجاد می‌کند.این Self-Organization است.مثال‌های دیگر:کودک یاد می‌گیرد صحبت کند.یک جامعه برای حل یک مشکل دور هم جمع می‌شود.یک اکوسیستم در طول زمان شکل می‌گیرد.فناوری‌های جدید به وجود می‌آیند.تکامل زیستی اتفاق می‌افتد. ۸. Self-Organization یعنی «قوانین ساده → ساختارهای پیچیده»یکی از ایده‌های زیبای این فصل این است که:برای ایجاد یک ساختار بسیار پیچیده، لزوماً به یک دستورالعمل بسیار پیچیده نیاز نداریم.مدوز به نمونه‌هایی مثل:دانه برفکریستالسرخستکامل موجودات زندهاشاره می‌کند.ساختار نهایی ممکن است فوق‌العاده پیچیده باشد، در حالی که قواعد اولیه نسبتاً ساده‌اند.پس پیچیدگی همیشه به معنی «دستورالعمل پیچیده» نیست.۹. مشکل: سازمان‌دهی بیش از حداما اینجا یک تناقض جالب داریم.Self-Organization به:آزادی + آزمایش + تنوع + امکان خطانیاز دارد.اما سازمان‌ها معمولاً برای افزایش بهره‌وری می‌گویند:«همه باید دقیقاً همین کار را انجام دهند.»این کار ممکن است در کوتاه‌مدت کارآمد باشد.اما اگر:خلاقیت محدود شود،تنوع از بین برود،آزمایش ممنوع شود،توانایی سیستم برای تکامل و سازگاری کاهش پیدا می‌کند.۱۰. مثال خیلی خوب: آموزشیک سیستم آموزشی را تصور کن.اگر هدف فقط این باشد:«همه دانش‌آموزان دقیقاً یک جواب بدهند.»سیستم احتمالاً:کنترل‌پذیرترمی‌شود.اما اگر به دانش‌آموزان اجازه بدهیم:سؤال بپرسند،آزمایش کنند،اشتباه کنند،روش‌های مختلف را امتحان کنند،سیستم:خلاق‌تر و خودسازمان‌ده‌ترمی‌شود.مدوز هشدار می‌دهد که گاهی برای رسیدن به نظم و بهره‌وری کوتاه‌مدت، توانایی سیستم برای خلق چیزهای جدید را نابود می‌کنیم.۱۱. Hierarchy — سلسله‌مراتبویژگی سوم:Hierarchyسیستم‌های پیچیده معمولاً از سیستم‌های کوچک‌تر تشکیل شده‌اند.مثلاً:سلول ↓ بافت ↓ اندام ↓ بدن ↓ خانواده ↓ جامعه ↓ کشور ↓ سیستم جهانیهر سطح، مجموعه‌ای از زیرسیستم‌های سطح پایین‌تر است.۱۲. چرا Hierarchy مفید است؟فرض کن یک شرکت ۱۰۰ هزار کارمند داشته باشد.اگر همه کارکنان مستقیماً با مدیرعامل در ارتباط باشند، سیستم بسیار ناکارآمد می‌شود.پس:CEO ↓ Managers ↓ Teams ↓ Individualsهر سطح بخشی از کار هماهنگی را انجام می‌دهد.این باعث می‌شود:اطلاعات بهتر مدیریت شود،تصمیم‌گیری سریع‌تر شود،هر بخش بتواند روی کار خودش تمرکز کند.مدوز می‌گوید اگر ارتباطات بین سطوح درست طراحی شوند، تأخیر اطلاعات کاهش می‌یابد و سیستم هم کارآمدتر و هم تاب‌آورتر می‌شود.۱۳. مثال ساعت‌سازها ⌚مدوز داستان دو ساعت‌ساز را مطرح می‌کند:Tempusساعت را یک‌جا و به صورت یکپارچه می‌سازد.اگر وسط کار مجبور شود آن را زمین بگذارد:ساعت از هم می‌پاشد و باید از ابتدا شروع کند.Horaساعت را به چند بخش کوچک‌تر تقسیم می‌کند.هر بخش را جداگانه می‌سازد و بعد بخش‌ها را به هم وصل می‌کند.اگر کارش قطع شود:فقط همان بخش کوچک تحت تأثیر قرار می‌گیرد.پس ساختار سلسله‌مراتبی باعث می‌شود سیستم:قابل مدیریت‌تر + مقاوم‌ترباشد.۱۴. اما Hierarchy هم می‌تواند خراب شوداینجا مدوز یک هشدار مهم می‌دهد:هدف لایه‌های بالاتر باید این باشد که لایه‌های پایین‌تر بتوانند وظیفه خودشان را بهتر انجام دهند.یعنی:مدیریت باید در خدمت سیستم باشد، نه اینکه سیستم را خفه کند.مثلاً در یک تیم فوتبال:اگر بازیکن‌ها دائماً منتظر دستور مربی باشند و مربی بخواهد تک‌تک حرکات را کنترل کند، ممکن است تیم نتواند به اتفاقات لحظه‌ای واکنش نشان دهد.پس یک سیستم خوب نیاز دارد به:Central coordinationهماهنگی مرکزیاما هم‌زمان:Local autonomyاستقلال محلیمدوز این تعادل را بسیار مهم می‌داند.۱۵. وقتی زیرسیستم هدف خودش را جایگزین هدف کل می‌کنداین یکی از مهم‌ترین هشدارهای فصل است.فرض کن هدف دانشگاه:آموزش و تولید دانشباشد.اما دانشجو فکر کند:«هدف من فقط گرفتن نمره بالا است.»آن وقت ممکن است:تقلب کند،حفظ‌کردن را جای یادگیری بگذارد،فقط دنبال سؤال امتحان باشد.در این حالت:هدف زیرسیستم با هدف کل سیستم متفاوت شده است.مدوز نمونه‌های مشابهی برای شرکت‌ها، بدن انسان و سازمان‌ها مطرح می‌کند.۱۶. مثال سرطاندر بدن:هدف سلول‌ها باید در خدمت کل بدن باشد.اما اگر یک سلول بگوید:«هدف من فقط تکثیر بیشتر خودم است.»شروع می‌کند به رشد کنترل‌نشده.نتیجه:Cancerیعنی یک زیرسیستم، هدف خودش را بر هدف کل سیستم مقدم کرده است.این مثال نشان می‌دهد که:سیستم خوب نیازمند هماهنگی بین اهداف سطوح مختلف است.۱۷. سه ویژگی اصلی فصل را کنار هم بگذاریمحالا تصویر کامل فصل مشخص می‌شود:1. Resilienceسیستم بتواند بعد از شوک برگردد.2. Self-Organizationسیستم بتواند خودش را تغییر دهد و تکامل دهد.3. Hierarchyسیستم بتواند با تقسیم شدن به سطوح و زیرسیستم‌ها پیچیدگی را مدیریت کند.مدوز در پایان فصل می‌گوید این سه ویژگی از دلایل اصلی عملکرد خوب سیستم‌های پویا هستند.🧠 یک مثال واحد برای فهم هر سهفرض کن یک جنگل داریم.Resilience 🌳اگر آتش‌سوزی کوچکی رخ دهد، جنگل بتواند دوباره رشد کند.Self-Organization 🌱گونه‌ها خودشان در طول زمان با شرایط جدید سازگار شوند و ترکیب جدیدی از اکوسیستم ایجاد شود.Hierarchy 🌲سلول → گیاه → گروه گیاهان → اکوسیستم → منطقههر سطح وظایف خودش را دارد و با سطوح دیگر تعامل می‌کند.اگر ما جنگل را بیش از حد «بهینه» کنیم:فقط یک نوع درخت بکاریم،همه آفات را حذف کنیم،همه چیز را کنترل کنیم،ممکن است:بهره‌وری کوتاه‌مدت ↑ولی:Resilience ↓و:Self-Organization ↓🎯 خلاصه امتحانی فصل ۳اگر فقط ۱۰ نکته از فصل را بخواهی:سیستم‌های خوب فقط «پایدار» نیستند؛ تاب‌آور هستند.Resilience یعنی توانایی سیستم برای جذب شوک و بازیابی.ثبات ظاهری لزوماً به معنی تاب‌آوری نیست.Feedbackهای متعدد و مسیرهای جایگزین، تاب‌آوری را افزایش می‌دهند.افزایش بهره‌وری کوتاه‌مدت می‌تواند تاب‌آوری بلندمدت را کاهش دهد.Self-Organization یعنی سیستم بتواند ساختار و رفتار جدید ایجاد کند.خودسازمان‌دهی به تنوع، آزادی و آزمایش نیاز دارد.Hierarchy یعنی سیستم از زیرسیستم‌های متصل در سطوح مختلف تشکیل شده است.سلسله‌مراتب خوب باید بین هماهنگی مرکزی و استقلال محلی تعادل ایجاد کند.سیستم زمانی خوب کار می‌کند که Resilience + Self-Organization + Hierarchy را حفظ کند. ⭐ پیام اصلی فصلاگر بخواهم کل فصل ۳ را در یک جمله بگویم:برای ساختن یک سیستم خوب، فقط به این فکر نکن که امروز چقدر کارآمد و منظم است؛ ببین آیا فردا هم می‌تواند خودش را حفظ کند، از شوک‌ها جان سالم به در ببرد و خودش را با شرایط جدید تطبیق دهد.

خلاصه فصل دوم کتاب (Thinking in Systems: A Primer)

Farokh Hasanzadeh — Thu, 10 Sep 2026 21:20:37 +0330

بازدیدی کوتاه از باغ‌وحش سیستم‌ها» A Brief Visit to the Systems Zooایده اصلی فصل در یک جملهسیستم‌هایی که ساختار بازخوردی مشابه دارند، حتی اگر ظاهرشان کاملاً متفاوت باشد، می‌توانند رفتارهای مشابهی داشته باشند.مثلاً یک جمعیت انسان، یک اقتصاد صنعتی و حتی موجودی یک فروشگاه در ظاهر هیچ شباهتی به هم ندارند؛ اما اگر ساختار Stock + Flow + Feedback آن‌ها را بررسی کنیم، الگوهای مشترکی پیدا می‌کنیم.۱. چرا «باغ‌وحش سیستم‌ها»؟مدوز به جای اینکه فقط درباره‌ی سیستم‌ها به شکل انتزاعی صحبت کند، چند سیستم مشخص را مثل حیوانات یک باغ‌وحش معرفی می‌کند.این مثال‌ها شامل مواردی مثل:ترموستاتجمعیتاقتصاد و سرمایهموجودی فروشگاهاقتصاد نفتصنعت ماهیگیریهستند.هدف این نیست که فقط همین مثال‌ها را یاد بگیریم؛ بلکه باید الگوی پشت آن‌ها را ببینیم.۲. سیستم اول: ترموستاتترموستات یک مثال ساده از دو حلقه‌ی Balancing است.فرض کن دمای مطلوب اتاق ۱۸ درجه باشد.اگر:دمای اتاق < دمای مطلوب→ بخاری روشن می‌شود→ دما افزایش پیدا می‌کند.وقتی دما بالا رفت:→ بخاری خاموش می‌شود.این یک حلقه‌ی متعادل‌کننده است.اما یک حلقه‌ی دیگر هم وجود دارد:اتاق → انتقال گرما به بیرون → کاهش دمای اتاقبنابراین دو حلقه با هم رقابت می‌کنند:بخاری → دما را بالا می‌برددر مقابل:محیط بیرون → دما را پایین می‌آورداگر هوا خیلی سرد شود یا عایق‌بندی ساختمان ضعیف باشد، حلقه‌ی خروج گرما می‌تواند قوی‌تر شود و بخاری دیگر نتواند دما را به هدف برساند.نکته مهمیک سیستم ممکن است چند حلقه‌ی بازخورد داشته باشد که هم‌زمان در جهت‌های مختلف آن را می‌کشند.و اینکه کدام حلقه قوی‌تر باشد، رفتار سیستم را تعیین می‌کند.مدوز این مفهوم را Shifting Dominance می‌نامد:یعنی ممکن است در یک زمان یک حلقه غالب باشد و بعداً حلقه‌ی دیگری غالب شود.۳. تأخیر یا Delay؛ یکی از مهم‌ترین مفاهیم فصلاین قسمت واقعاً مهم است.فرض کن می‌خواهی دمای خانه را تنظیم کنی، اما بین تصمیم تو و اثر آن روی دما تأخیر وجود دارد.تو بخاری را روشن می‌کنی، اما اثرش چند دقیقه بعد ظاهر می‌شود.اگر در این فاصله دوباره تصمیم بگیری:«هنوز سرد است، پس بیشترش کنم!»ممکن است وقتی اثر تصمیم اول ظاهر شد، خانه بیش از حد گرم شود.این مسئله در سیستم‌های واقعی بسیار رایج است.اطلاعات دیر می‌رسد و اقدامات هم دیر اثر می‌کنند.۴. سیستم جمعیت: Reinforcing + Balancingمدوز سپس یک سیستم بسیار مهم را معرفی می‌کند:Populationجمعیت یک Stock است.دو Flow اصلی دارد:Births → افزایش جمعیتDeaths → کاهش جمعیتحلقه‌ی تولد یک Reinforcing Loop است:جمعیت بیشتر→ افراد بیشتری برای تولیدمثل→ تولدهای بیشتر→ جمعیت بیشتراما مرگ‌ومیر یک Balancing Loop است:جمعیت بیشتر→ مرگ‌های بیشتر→ کاهش جمعیتپس رفتار جمعیت به این بستگی دارد که کدام حلقه قوی‌تر باشد.اگر:Births > Deaths→ جمعیت رشد می‌کند.اگر:Deaths > Births→ جمعیت کاهش می‌یابد.اگر:Births = Deaths→ جمعیت تقریباً ثابت می‌شود.این حالت سوم همان Dynamic Equilibrium است.۵. یک نکته خیلی مهم: «غالب شدن حلقه‌ها»مدوز می‌گوید رفتار سیستم لزوماً همیشه یکسان نمی‌ماند.مثلاً جمعیت ممکن است ابتدا:رشد کند → رشد سریع‌تر شود → بعد رشد کند شود → ثابت شودچرا؟چون قدرت نسبی حلقه‌های بازخورد در طول زمان تغییر می‌کند.در ابتدا:Reinforcing Loop > Balancing Loopبعد:Reinforcing Loop ≈ Balancing Loopدر نهایت:Reinforcing Loop = Balancing Loopو سیستم به تعادل می‌رسد.پس:برای فهم رفتار یک سیستم، فقط خود حلقه‌ها را نبین؛ ببین در طول زمان کدام حلقه غالب می‌شود.۶. اقتصاد و جمعیت از نظر ساختاری شبیه‌اند!این یکی از جذاب‌ترین نکات فصل است.مدوز نشان می‌دهد که جمعیت و سرمایه‌ی اقتصادی ساختار مشابهی دارند.جمعیت:تولد → رشدمرگ → کاهشسرمایه:سرمایه‌گذاری → رشد سرمایهاستهلاک → کاهش سرمایهدر هر دو:یک حلقه‌ی تقویت‌کننده برای رشدویک حلقه‌ی متعادل‌کننده برای کاهشوجود دارد.بنابراین:سیستم‌هایی با ساختار بازخوردی مشابه، رفتارهای مشابه تولید می‌کنند—even اگر ظاهرشان کاملاً متفاوت باشد.این از مهم‌ترین اصول کل کتاب است.۷. سیستم موجودی فروشگاه و مشکل تأخیریکی از بهترین مثال‌های فصل، نمایندگی فروش خودرو است.فرض کن یک نمایندگی می‌خواهد همیشه به اندازه‌ی ۱۰ روز فروش، خودرو در انبار داشته باشد.اگر فروش افزایش پیدا کند:فروش بیشتر↓موجودی کمتر↓سفارش بیشتر↓تحویل خودرو↓موجودی بیشتردر نگاه اول سیستم منطقی است.اما مدوز سه نوع Delay وارد سیستم می‌کند:۱. Perception Delayمدتی طول می‌کشد تا بفهمیم فروش واقعاً تغییر کرده.۲. Response Delayبعد از فهمیدن تغییر، مدتی طول می‌کشد تا واکنش نشان دهیم.۳. Delivery Delayبعد از سفارش نیز مدتی طول می‌کشد تا کالا برسد.۸. نتیجه تأخیرها: Oscillationاینجا اتفاق جالبی رخ می‌دهد.فروش بالا می‌رود.نمایندگی سفارش می‌دهد.اما خودروها هنوز نرسیده‌اند.پس موجودی بیشتر پایین می‌رود.مدیر فکر می‌کند:«پس باید بیشتر سفارش بدهم!»بعد ناگهان همه‌ی سفارش‌های قبلی می‌رسند.حالا موجودی بیش از حد زیاد می‌شود.مدیر سفارش را کم می‌کند.اما سفارش‌های قبلی هنوز در راه‌اند...و این چرخه ادامه پیدا می‌کند:کمبود → سفارش زیاد → مازاد → سفارش کم → کمبود → ...این همان Oscillation / نوسان است.نکته بسیار مهم:تأخیر در یک حلقه‌ی Balancing می‌تواند باعث نوسان سیستم شود.۹. جالب‌تر: سریع‌تر عمل کردن همیشه بهتر نیست!این قسمت از فصل بسیار مهم است.مدیر نمایندگی برای حل نوسان تصمیم می‌گیرد:«باید سریع‌تر واکنش نشان بدهم.»اما وقتی واکنش را بیش از حد سریع می‌کند، نوسان شدیدتر می‌شود.یعنی:Action سریع‌تر ≠ نتیجه بهتردر این سیستم، حتی کندتر کردن واکنش می‌تواند سیستم را پایدارتر کند.این یک درس بزرگ Systems Thinking است:راه‌حل شهودی ما ممکن است دقیقاً خلاف چیزی باشد که سیستم نیاز دارد.۱۰. سیستم نفت: رشد با یک محدودیتبعد مدوز وارد سیستم‌های پیچیده‌تر می‌شود.فرض کن یک شرکت نفتی داریم.ابتدا:سرمایه بیشتر→ استخراج بیشتر→ سود بیشتر→ سرمایه‌گذاری بیشتر→ سرمایه بیشتراین یک Reinforcing Loop است.اما نفت یک منبع تجدیدناپذیر است.پس:استخراج بیشتر→ نفت کمتر→ استخراج سخت‌تر→ سود کمتر→ سرمایه‌گذاری کمتر→ رشد کمتراین یک Balancing Loop است.۱۱. مشکل رشد نماییاینجا مدوز یک نکته‌ی بسیار مهم مطرح می‌کند:اگر چیزی با نرخ نمایی رشد کند، حتی یک منبع بسیار بزرگ هم ممکن است خیلی سریع‌تر از تصور ما مصرف شود.مثلاً در مدل کتاب، ذخیره‌ای که در ابتدا برای حدود ۲۰۰ سال کافی به نظر می‌رسد، به دلیل رشد سریع استخراج می‌تواند خیلی زودتر به نقطه‌ی اوج استخراج برسد و بعد سقوط کند.پس:«منبع زیاد است» الزاماً به معنی «زمان زیادی داریم» نیست.چون باید نرخ رشد مصرف را هم در نظر گرفت.۱۲. یک نکته مهم درباره رشدمدوز نشان می‌دهد که وقتی یک سیستم به منبع تجدیدناپذیر وابسته است:رشد سریع‌تر → مصرف سریع‌تر → محدودیت زودتر → سقوط شدیدترپس سؤال فقط این نیست:«چقدر منبع داریم؟»بلکه باید بپرسیم:«با چه سرعتی داریم آن را مصرف می‌کنیم؟»و حتی مهم‌تر:«هدف سیستم چیست؟»اگر هدف، بیشترین سود در کوتاه‌ترین زمان باشد، رفتار سیستم کاملاً متفاوت خواهد بود با حالتی که هدف، دوام اقتصادی برای مدت طولانی باشد.۱۳. سیستم ماهیگیری: منبع تجدیدپذیردر مثال بعدی، منبع دیگر نفت نیست؛ ماهی است.ماهی می‌تواند دوباره تولید شود.پس:ماهی بیشتر→ تولیدمثل→ ماهی بیشتربنابراین یک حلقه‌ی Reinforcing برای بازسازی منبع داریم.اما:ماهیگیری بیشتر→ ماهی کمتر→ سود کمتر→ سرمایه‌گذاری کمتر در ناوگان→ ماهیگیری کمتریک Balancing Loop ایجاد می‌کند.۱۴. اما تکنولوژی می‌تواند نتیجه را بدتر کند!این شاید یکی از جالب‌ترین مثال‌های فصل باشد.فرض کن صنعت ماهیگیری تکنولوژی جدیدی پیدا می‌کند که پیدا کردن ماهی را بسیار آسان‌تر می‌کند.در نگاه اول:تکنولوژی بهتر = خوباما در سیستم:تکنولوژی بهتر→ ماهیگیری مؤثرتر→ ماهی کمتر→ فشار بیشتر روی جمعیت ماهی→ کاهش شدید منبعاگر تکنولوژی بیش از حد کارآمد شود، ممکن است ماهی‌ها تقریباً نابود شوند و در نهایت خود صنعت ماهیگیری هم فروبپاشد.مدوز این را نمونه‌ای از:High Leverage, Wrong Directionمی‌داند.یعنی:اهرم قدرتمندی پیدا کرده‌ایم، اما آن را در جهت اشتباه کشیده‌ایم.این ایده در فصل‌های بعدی کتاب اهمیت بیشتری پیدا می‌کند.🧠 حالا کل فصل را در یک نقشه ذهنی ببین SYSTEMS ZOO │ ┌──────────────┼──────────────┐ │ │ │ Thermostat Population Economy │ │ │ Balancing R + B loops R + B loops │ │ │ Delays Growth/decline Growth/decline │ ↓ Inventory │ Delays │ ↓ Oscillations │ ↓ Resource Systems ↙ ↘ Nonrenewable Renewable Oil Fish │ │ Depletion Overharvesting │ │ └───────┬───────┘ ↓ Limits to Growth🎯 ۱۰ نکته‌ای که از فصل ۲ باید یاد بگیری⭐ مهم‌ترین پیام فصل ۲اگر فصل اول می‌گفت:«سیستم‌ها از Stock، Flow و Feedback ساخته شده‌اند.»فصل دوم یک قدم جلوتر می‌رود و می‌گوید:«حالا با نگاه کردن به همین ساختارها می‌توانی رفتار سیستم را در طول زمان بفهمی.»یعنی وقتی با یک مسئله مواجه شدی، فقط نپرس:«چه اتفاقی افتاده؟»بپرس:«چه حلقه‌هایی باعث شده‌اند این اتفاق به وجود بیاید؟ کدام حلقه در حال حاضر غالب است؟ چه تأخیرهایی وجود دارد؟ و سیستم با چه محدودیتی روبه‌رو خواهد شد؟»

خلاصه فصل اول کتاب (Thinking in Systems: A Primer)

Farokh Hasanzadeh — Thu, 10 Sep 2026 21:07:28 +0330

مبانی تفکر سیستمیایده‌ی اصلی فصل در یک جملهبرای فهمیدن یک مسئله، فقط به اجزای آن نگاه نکن؛ ببین اجزا چگونه به هم متصل‌اند و کل سیستم برای چه هدفی کار می‌کند.مدوز می‌گوید یک سیستم صرفاً «مجموعه‌ای از چیزها» نیست؛ بلکه مجموعه‌ای از اجزای به‌هم‌پیوسته است که در کنار هم رفتار و کارکرد مشخصی ایجاد می‌کنند.۱. سیستم دقیقاً چیست؟هر سیستم سه جزء اصلی دارد:۱. Elements — اجزاچیزهایی که سیستم را تشکیل می‌دهند.۲. Interconnections — ارتباطاتروابط و جریان‌هایی که اجزا را به هم وصل می‌کنند.۳. Function/Purpose — کارکرد یا هدفچیزی که سیستم در مجموع به دنبال انجام دادن یا حفظ کردن آن است.مثلاً یک دانشگاه:اجزا → دانشجو، استاد، ساختمان، کتابخانه، مدیرارتباطات → قوانین، امتحان، بودجه، ارتباط استاد و دانشجو، جریان اطلاعاتهدف → تولید، حفظ و انتقال دانشنکته‌ی مهم این است که سیستم بیشتر از مجموع اجزای خودش است.اگر فقط تک‌تک اجزای دانشگاه را بشناسیم، لزوماً نمی‌فهمیم دانشگاه چگونه رفتار می‌کند.۲. «اجزا» همیشه مهم‌ترین قسمت نیستندیکی از مهم‌ترین پیام‌های فصل این است:ما معمولاً بیش از حد روی عناصر قابل مشاهده تمرکز می‌کنیم.مثلاً اگر یک سازمان عملکرد بدی دارد، اولین واکنش ممکن است این باشد:«آدم‌های خوبی نداریم؛ باید افراد را عوض کنیم.»اما از دیدگاه تفکر سیستمی باید بپرسیم:قوانین سازمان چیست؟پاداش‌ها چگونه تعیین می‌شوند؟چه اطلاعاتی به افراد می‌رسد؟چه چیزی باعث می‌شود افراد این‌گونه تصمیم بگیرند؟هدف واقعی سیستم چیست؟مدوز می‌گوید گاهی با عوض کردن تمام افراد، ساختار اصلی سیستم تقریباً دست‌نخورده باقی می‌ماند و همان رفتار دوباره تولید می‌شود.۳. سه جزء را از نظر اهمیت چطور ببینیم؟مدوز یک نکته‌ی بسیار مهم دارد:Elements ← معمولاً کم‌اهمیت‌ترInterconnections ← مهم‌ترPurpose ← اغلب مهم‌ترینمثال معروف کتاب فوتبال است.اگر تمام بازیکنان یک تیم فوتبال را عوض کنیم، هنوز فوتبال داریم.اما اگر قوانین بازی را عوض کنیم، سیستم بسیار متفاوت می‌شود.و اگر هدف بازی را عوض کنیم، باز هم رفتار سیستم می‌تواند کاملاً تغییر کند.بنابراین:برای تغییر پایدار یک سیستم، فقط آدم‌ها و اجزا را تغییر نده؛ روابط و هدف سیستم را هم بررسی کن.۴. هدف واقعی سیستم را از حرف‌هایش نفهم؛ از رفتار آن بفهماین یکی از جذاب‌ترین نکات فصل است.ممکن است یک سازمان بگوید:«هدف ما حفاظت از محیط‌زیست است.»اما اگر در عمل تقریباً هیچ بودجه، نیروی انسانی یا تصمیمی برای حفاظت از محیط‌زیست اختصاص ندهد، از دیدگاه مدوز باید به رفتار سیستم نگاه کنیم، نه شعار آن.پس:Purpose ≠ چیزی که سیستم می‌گوید می‌خواهد انجام دهدبلکه بیشتر:Purpose ≈ چیزی که رفتار مداوم سیستم نشان می‌دهد که واقعاً دنبال می‌کند.این ایده برای تحلیل سازمان‌ها، سیاست‌گذاری، اقتصاد و حتی زندگی شخصی بسیار قدرتمند است.۵. Stock و Flow — موجودی و جریانبعد از تعریف سیستم، مدوز وارد یکی از مهم‌ترین مفاهیم کتاب می‌شود:Stock = موجودی/انباشتچیزی که در یک لحظه در سیستم وجود دارد و قابل اندازه‌گیری است.مثلاً:پول حساب بانکیجمعیتآب داخل مخزنموجودی کالاچوب داخل جنگلاعتمادبه‌نفسامیدFlow = جریانچیزی که باعث افزایش یا کاهش Stock می‌شود.مثلاً:حساب بانکیدرآمد → Flow ورودیهزینه → Flow خروجیپول موجود → Stockیا:جنگلرشد درختان → ورودیقطع درختان + مرگ طبیعی → خروجیمقدار چوب موجود → Stock۶. مثال فوق‌العاده‌ی وان حمام 🛁مدوز برای توضیح این موضوع از یک مثال ساده استفاده می‌کند.فرض کن:آب داخل وان = Stockشیر آب = Inflowفاضلاب = Outflowسه حالت داریم:اگر:Inflow > Outflowآب وان زیاد می‌شود.اگر:Outflow > Inflowآب وان کم می‌شود.اگر:Inflow = Outflowسطح آب ثابت می‌ماند.اما نکته‌ی جالب اینجاست:آب می‌تواند جریان داشته باشد ولی سطح آب ثابت بماند.این همان چیزی است که مدوز آن را Dynamic Equilibrium می‌نامد.۷. چرا Stock خیلی مهم است؟چون Stock فوراً تغییر نمی‌کند.اگر شیر آب را ناگهان باز کنیم، آب وان در همان لحظه پر نمی‌شود.یعنی:Flow می‌تواند سریع تغییر کند، اما Stock معمولاً با تأخیر تغییر می‌کند.این موضوع در دنیای واقعی بسیار مهم است.مثلاً:آلودگی آب‌های زیرزمینی ممکن است سال‌ها طول بکشد تا ایجاد شود.اما پاک شدن آن هم ممکن است دهه‌ها طول بکشد.جمعیت یک کشور یک‌شبه دو برابر نمی‌شود.یک اقتصاد هم نمی‌تواند در چند روز تمام زیرساخت‌های قدیمی خود را عوض کند.پس Stockها مثل بافر یا ضربه‌گیر عمل می‌کنند.۸. یک اشتباه رایج: فقط به ورودی نگاه کردنما معمولاً وقتی می‌خواهیم یک Stock را افزایش دهیم، به افزایش Inflow فکر می‌کنیم.اما گاهی کاهش Outflow همان نتیجه را می‌دهد.مثلاً برای افزایش ذخیره نفت:راه اول: کشف نفت بیشترراه دوم: مصرف نفت کمترهر دو می‌توانند Stock نفت موجود را افزایش دهند.یا برای افزایش تعداد کارکنان یک شرکت:راه اول: استخدام بیشترراه دوم: کاهش استعفا و اخراجاین یک نکته‌ی خیلی مهم در حل مسئله است:برای تغییر یک موجودی، فقط به این فکر نکن که چه چیزی باید بیشتر وارد شود؛ ببین چه چیزی باید کمتر خارج شود.۹. Feedback Loop — حلقه‌ی بازخورداز اینجا فصل وارد یکی از اصلی‌ترین مفاهیم تفکر سیستمی می‌شود.Feedback Loop یعنی تغییری در یک Stock ایجاد می‌شود، آن تغییر اطلاعاتی ایجاد می‌کند و این اطلاعات باعث تغییر Flow می‌شود؛ Flow دوباره Stock را تغییر می‌دهد.یعنی:Stock → Information → Decision → Flow → Stockمدوز می‌گوید بسیاری از رفتارهای سیستم‌ها از همین حلقه‌ها به وجود می‌آیند.۱۰. دو نوع Feedback اصلیA. Balancing Feedback — بازخورد متعادل‌کنندههدفش این است که سیستم را به سمت یک هدف یا وضعیت مطلوب برگرداند.مثلاً:دمای مطلوب اتاق = ۲۲ درجهاگر دما پایین بیاید:→ بخاری روشن می‌شود→ دما بالا می‌روداگر دما بیش از حد بالا برود:→ بخاری خاموش می‌شود→ دما پایین می‌آید.پس این حلقه در برابر تغییر مقاومت می‌کند و سیستم را به سمت هدف می‌برد.به زبان ساده:تغییر → سیستم واکنش نشان می‌دهد → تغییر را خنثی می‌کند۱۱. Reinforcing Feedback — بازخورد تقویت‌کنندهاین یکی برعکس است.در اینجا تغییر اولیه باعث تغییر بیشتر در همان جهت می‌شود.مثلاً پول در بانک:پول بیشتر↓سود بیشتر↓پول بیشتر↓سود بیشتر↓پول بسیار بیشتراین یک حلقه‌ی تقویت‌کننده است.همین ساختار می‌تواند باعث:رشد سریعرشد جمعیترشد اقتصادیگسترش یک مهارتیا برعکس، سقوط و فروپاشیشود.مدوز به آن نوعی snowball effect نگاه می‌کند:چیزی که در حال زیاد شدن است، باعث می‌شود خودش سریع‌تر زیاد شود.۱۲. تفاوت دو نوع حلقه را این‌طور حفظ کننوع Feedbackکار اصلی نتیجه Balancing کاهش انحراف از هدف ثبات Reinforcing تقویت تغییر موجود رشد یا سقوط شتاب‌گیرندهمثلاً:ترموستات → Balancingسود بانکی → Reinforcing۱۳. مهم‌ترین تغییر ذهنی فصلتفکر عادی معمولاً این شکلی است:A باعث B می‌شود.اما Systems Thinking می‌گوید:A روی B اثر می‌گذارد، اما B هم از طریق حلقه‌های بازخورد روی A اثر می‌گذارد.یعنی به جای دیدن یک زنجیره‌ی خطی علت و معلول، باید دنبال حلقه‌ها و الگوهای تکرارشونده بگردیم.🧠 اگر بخواهم فصل ۱ را خیلی ساده کنممدوز در فصل اول تقریباً می‌گوید:دنیا پر از سیستم است.برای فهم یک سیستم، چهار سؤال بپرس:1. اجزای سیستم چیست؟Elements2. این اجزا چگونه به هم وصل‌اند؟Interconnections3. سیستم واقعاً چه چیزی را دنبال می‌کند؟Purpose4. چه چیزی باعث می‌شود رفتار سیستم در طول زمان تغییر کند؟Stocks + Flows + Feedbackو مهم‌تر از همه:به جای اینکه فقط بپرسی «چه کسی باعث این اتفاق شد؟»، بپرس «چه ساختاری باعث می‌شود این اتفاق مرتباً تولید شود؟»این در واقع قلب تفکر سیستمی است.🎯 خلاصه‌ی کوتاه فصل ۱اگر بخواهی فقط ۱۰ نکته از فصل را یاد بگیری:System = Elements + Interconnections + Purposeسیستم بیشتر از مجموع اجزای خود است.اجزا معمولاً قابل مشاهده‌ترین بخش سیستم‌اند، اما لزوماً مهم‌ترین نیستند.روابط بین اجزا رفتار سیستم را شکل می‌دهند.هدف واقعی سیستم را باید از رفتار آن استنباط کرد.Stock چیزی است که انباشته شده.Flow چیزی است که Stock را افزایش یا کاهش می‌دهد.Stockها به دلیل تأخیر، مثل بافر عمل می‌کنند.Balancing feedback سیستم را به سمت هدف می‌برد.Reinforcing feedback تغییر را تقویت می‌کند و می‌تواند به رشد یا فروپاشی شتاب‌گیرنده منجر شود.

Agile Software Engineer

Farokh Hasanzadeh — Fri, 25 Oct 2024 11:43:32 +0330

An Agile Software Engineer is a software developer who works within an Agile framework, applying Agile principles and practices to enhance the development process. Here’s a closer look at the role:Key ResponsibilitiesCollaborative Development: Work closely with cross-functional teams, including product owners, designers, and testers, to deliver high-quality software.Iterative Development: Participate in iterative development cycles (sprints), delivering functional increments of software regularly.Continuous Improvement: Engage in retrospectives to reflect on the team's performance and identify areas for improvement.Adaptability: Be flexible in adapting to changing requirements and priorities based on feedback from stakeholders and users.Testing and Quality Assurance: Embrace practices such as Test-Driven Development (TDD) and Continuous Integration/Continuous Deployment (CI/CD) to ensure code quality.User-Centric Design: Focus on delivering value to users, ensuring that features meet user needs and enhance the user experience.Skills RequiredTechnical Proficiency: Strong knowledge of programming languages, frameworks, and tools relevant to the project.Agile Methodologies: Familiarity with Agile frameworks (e.g., Scrum, Kanban) and principles outlined in the Agile Manifesto.Collaboration Skills: Excellent communication and teamwork skills to work effectively with diverse team members.Problem-Solving: Ability to troubleshoot issues and come up with effective solutions quickly.Adaptability: Willingness to learn and adopt new technologies and methodologies as needed.Benefits of Agile Software EngineeringFaster Delivery: Agile practices enable quicker releases, allowing for rapid feedback and iteration.Higher Quality: Continuous testing and integration lead to more reliable and stable software.Increased Flexibility: Teams can pivot and adapt to changes in the project or market demands more readily.Enhanced Team Morale: Empowerment and collaboration foster a positive team environment, boosting motivation and engagement.ConclusionAgile Software Engineers play a crucial role in modern software development by embracing collaboration, adaptability, and continuous improvement. Their focus on delivering value and quality makes them essential in Agile teams, leading to more successful software projects.

تیم‌های خودسازمانده

Farokh Hasanzadeh — Fri, 25 Oct 2024 11:35:12 +0330

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

Agile for Developers

Farokh Hasanzadeh — Fri, 18 Oct 2024 15:13:52 +0330

In Agile development, there are several key subjects and concepts that developers should be familiar with to effectively participate in Agile projects. These topics range from Agile principles and methodologies to specific practices, tools, and communication strategies. Here’s a breakdown of the main subjects a developer should know about in Agile:1. Agile Principles and ManifestoAgile Manifesto: Developers should be familiar with the four values and twelve principles outlined in the Agile Manifesto, as they guide Agile practices:Values:Individuals and interactions over processes and tools.Working software over comprehensive documentation.Customer collaboration over contract negotiation.Responding to change over following a plan.Principles:Customer satisfaction, adaptive planning, continuous delivery, simplicity, technical excellence, etc.2. Agile Frameworks and MethodologiesScrum:Sprints: Time-boxed iterations where a small increment of work is delivered.Roles: Scrum Master, Product Owner, and Development Team.Artifacts: Product Backlog, Sprint Backlog, Increment.Events: Sprint Planning, Daily Standup, Sprint Review, Sprint Retrospective.Kanban:Visual management of tasks with a focus on continuous flow.Work-in-progress (WIP) limits to control bottlenecks.Extreme Programming (XP):Emphasis on engineering practices such as Test-Driven Development (TDD), Pair Programming, Continuous Integration (CI).Lean:Focuses on reducing waste, increasing efficiency, and delivering value more quickly.3. Backlog ManagementProduct Backlog: A prioritized list of user stories, bugs, and features that need to be worked on. Developers should know how to:Break down large features into smaller tasks.Estimate and prioritize tasks using techniques like Story Points.Sprint Backlog: Tasks selected for the current sprint. Developers should understand how to commit to and deliver on these tasks.4. User Stories and Acceptance CriteriaUser Stories: Developers should understand how to work with user stories, which are simple descriptions of a feature from the user’s perspective. Example format:cssCopy codeAs a [type of user], I want [some goal] so that [some reason].Acceptance Criteria: Clearly defined conditions that must be met for the story to be considered "done". Developers should work with Product Owners to ensure clarity and testability.5. Estimation TechniquesStory Points: Developers should know how to estimate the relative complexity or effort of user stories using points.Planning Poker: A collaborative estimation technique where team members assign story points to user stories.Velocity: A metric used to measure how much work a team can complete during a sprint, important for planning future sprints.6. Continuous Integration (CI) and Continuous Delivery (CD)Developers should be familiar with CI/CD pipelines that automate the building, testing, and deployment of software to ensure quick and reliable delivery.Understanding the importance of frequent commits to the repository and the need for automated testing (unit, integration, and functional tests).7. Test-Driven Development (TDD)TDD involves writing tests before writing code to define how the code should behave. Developers should be comfortable:Writing unit tests.Using frameworks like JUnit, NUnit, or Jest for testing.Refactoring code while keeping tests green.8. Pair Programming and Code ReviewsPair Programming: A practice where two developers work together at one workstation. Developers should be open to collaborative coding and providing real-time feedback.Code Reviews: Participating in code reviews to ensure quality and share knowledge across the team.9. Definition of Done (DoD)Developers should align on the Definition of Done, which includes the criteria that a user story or task must meet before it is considered complete (e.g., passing tests, code reviewed, documentation updated, etc.).10. Refactoring and Technical DebtRefactoring: Continuous improvement of the codebase to keep it clean and maintainable without changing its behavior.Technical Debt: Understanding when to prioritize refactoring over feature development to avoid accumulating too much technical debt, which can slow down future development.11. Collaboration and CommunicationDaily Standups: A short daily meeting where the team discusses what was done, what will be done, and any blockers.Sprint Planning: Developers should be involved in planning what work will be included in the sprint.Sprint Retrospectives: Regular reflection sessions to discuss what went well, what didn’t, and how the team can improve.Collaboration Tools: Familiarity with tools like Jira, Trello, or Asana for task management, and Slack or Microsoft Teams for communication.12. Agile MetricsBurn-down Charts: A visual representation of work remaining in a sprint, helping teams track progress.Cycle Time/Lead Time: Metrics to measure how long it takes for a task to go from start to finish.Velocity: Understanding how velocity is used to gauge the team's capacity and plan future sprints.13. Self-Organizing TeamsIn Agile, teams are often self-organizing, meaning developers have a say in how work is allocated and executed. Developers should take initiative and participate in decision-making.14. Incremental and Iterative DevelopmentIncremental Development: Delivering small, working increments of the product that add value.Iterative Development: Constantly revisiting and improving the product based on feedback.15. Agile MindsetEmbracing change: Developers should understand the importance of being flexible and ready to adapt to changes in requirements.Continuous Improvement: Always seeking to improve both the product and the process through retrospectives and feedback loops.Summary:For developers to excel in Agile, they should focus on both technical practices (like TDD, CI/CD, and refactoring) and Agile-specific practices (like backlog management, working with user stories, estimation, and participating in Scrum events). Additionally, embracing Agile principles like collaboration, continuous improvement, and adaptability is crucial for success.

Proof of Concept (PoC)

Farokh Hasanzadeh — Tue, 01 Oct 2024 17:51:30 +0330

Proof of Concept (PoC) یا اثبات مفهوم یک نمونه اولیه یا مدل اولیه است که برای تایید امکان‌پذیری یک ایده یا مفهوم استفاده می‌شود. هدف اصلی PoC این است که نشان دهد یک ایده یا فناوری خاص به‌درستی کار می‌کند و می‌تواند به مرحله عملیاتی برسد، بدون نیاز به توسعه کامل یا پیاده‌سازی تمام جزئیات.اهداف و کاربردهای PoC:تایید امکان‌پذیری: بررسی این که آیا ایده یا فناوری از نظر فنی امکان‌پذیر است یا خیر.شناسایی چالش‌ها: مشخص کردن مشکلات و چالش‌های احتمالی قبل از ورود به فاز تولید.کاهش ریسک: کمک به کاهش ریسک‌های فنی و تجاری با بررسی نتایج پیش از سرمایه‌گذاری سنگین.جلب اعتماد ذی‌نفعان: نمایش قابلیت ایده به سرمایه‌گذاران، مدیران، یا مشتریان برای جلب اعتماد و تصمیم‌گیری بهتر.تعیین قابلیت گسترش‌پذیری: بررسی این که آیا ایده یا محصول می‌تواند با حجم بیشتر و در شرایط واقعی نیز کار کند یا خیر.تفاوت PoC با Prototype و MVP:PoC (اثبات مفهوم): یک آزمایش کوچک و محدود است که فقط بررسی می‌کند آیا ایده از لحاظ فنی ممکن است یا نه.Prototype (نمونه اولیه): یک مدل یا نسخه ابتدایی از محصول است که به‌طور کامل یا بخشی از عملکرد محصول نهایی را شبیه‌سازی می‌کند تا طراحی و تعاملات آزمایش شوند.MVP (حداقل محصول قابل عرضه): نسخه‌ای از محصول است که فقط دارای ویژگی‌های اساسی است و برای عرضه به کاربران واقعی و دریافت بازخورد مورد استفاده قرار می‌گیرد.مثال‌هایی از Proof of Concept:نرم‌افزار: تیم توسعه یک نرم‌افزار می‌تواند یک PoC کوچک از یک ویژگی خاص ایجاد کند، مثلاً اتصال یک نرم‌افزار به یک API خارجی برای اطمینان از اینکه یکپارچه‌سازی به‌درستی انجام می‌شود.سخت‌افزار: یک شرکت تولیدکننده سخت‌افزار ممکن است نمونه‌ای از یک قطعه الکترونیکی را بسازد تا مطمئن شود فناوری مورد استفاده در مقیاس بزرگ قابل تولید است.استارتاپ‌ها: در کسب‌وکارهای نوپا، PoC اغلب برای جذب سرمایه‌گذار استفاده می‌شود، به این صورت که استارتاپ نشان می‌دهد ایده یا محصول آن‌ها به‌طور عملیاتی امکان‌پذیر است و می‌تواند به یک محصول تجاری تبدیل شود.نتیجه PoC:اگر PoC موفق باشد، پروژه وارد مراحل بعدی مثل توسعه نمونه اولیه (Prototype) یا حداقل محصول قابل عرضه (MVP) می‌شود. اگر PoC موفقیت‌آمیز نباشد، شرکت یا تیم ممکن است ایده را بازنگری کرده یا به دنبال راه‌حل‌های جایگزین باشد.

Definition of Done (DoD)

Farokh Hasanzadeh — Tue, 01 Oct 2024 17:47:50 +0330

در توسعه نرم‌افزار و روش‌های Agile (مثل اسکرام و کانبان)، Definition of Done (DoD) یا تعریف انجام‌شده یک معیار است که تعیین می‌کند چه زمانی یک وظیفه (Task)، داستان کاربر (User Story)، یا ویژگی (Feature) به‌صورت کامل انجام‌شده و آماده تحویل یا انتشار است.اهداف و اهمیت Definition of Done:شفافیت: تیم توسعه دقیقاً می‌داند چه زمانی یک کار تمام شده است.کیفیت: تضمین می‌کند که تمام جنبه‌های کیفیت (مثل تست‌ها، مستندسازی، و رفع باگ‌ها) در نظر گرفته شده‌اند.یکپارچگی تیم: تعریف مشخص از "تمام شدن" باعث می‌شود همه اعضای تیم روی یک استاندارد واحد توافق داشته باشند.موارد رایج در Definition of Done:در DoD معمولاً چندین مرحله مختلف شامل می‌شود تا از تکمیل و کیفیت کار اطمینان حاصل شود. برخی از این موارد عبارتند از:کدنویسی کامل شده باشد.تمام تست‌های واحد (Unit Tests) نوشته و پاس شده باشند.کد بازبینی (Code Review) شده باشد.کد در محیط آزمایشی (Staging) مستقر شده باشد.تمام مستندات لازم (مثل راهنما یا مستندات API) به‌روز شده باشند.تست‌های پذیرش کاربر (User Acceptance Testing) پاس شده باشند.هیچ باگ بحرانی یا مهمی باقی نمانده باشد.تفاوت Definition of Done و Acceptance Criteria:Acceptance Criteria (معیارهای پذیرش) معیارهایی هستند که برای هر داستان کاربر یا ویژگی تعریف می‌شوند تا نشان دهند که نیازمندی‌های آن داستان کاربر به‌درستی پیاده‌سازی شده‌اند.Definition of Done یک استاندارد عمومی است که روی تمام کارها یا ویژگی‌های پروژه اعمال می‌شود و تعیین می‌کند که چه زمانی هر وظیفه به طور کامل انجام شده است.مثال از یک Definition of Done:یک تیم توسعه می‌تواند DoD خود را به‌صورت زیر تعریف کند:کد نوشته شده و بازبینی شده.تمام Unit Test ها پاس شده‌اند.کد روی محیط stage یا sandbox مستقر شده و تست‌های سیستمی پاس شده‌اند.مستندات به‌روزرسانی شده‌اند.هیچ باگ بحرانی وجود ندارد.محصول آماده انتشار است.این تعریف باعث می‌شود که تمام تیم روی معیارهای کیفیت توافق داشته باشند و کارهای ناقص یا نیمه‌تمام به تحویل داده نشوند.

ببینیم React Fiber چیه و چکار می کنه؟

Farokh Hasanzadeh — Sat, 20 Jul 2024 12:25:49 +0330

خب React Fiber یک تغییر معماری اصلیه که در React 16 معرفی شد و هدفش کارآمدتر کردن و درک آسان‌تر کتابخونه است. این نشون دهنده تغییر قابل توجهی از الگوریتم اصلی تطبیق React هست که بر اساس یک مدل single thread و concurrent برای به روز رسانی DOM بود. معماری Fiber، رندر asynchronous و رویکردی جزئی‌تر را برای مدیریت به‌روزرسانی‌ها معرفی می‌کند که امکان عملکرد و تجربه کاربری بهتری رو فراهم می‌کنه.مفاهیم کلیدی React Fiberنودهای Fiberدر قلب معماری فیبر، نودهای فیبر قرار دارن. هر کامپوننت در یک برنامه ری اکت دارای یک نود فیبر مرتبطه که حاوی اطلاعاتی در مورد نحوه به روز رسانی کامپوننت هست. این شامل نوع کار (به عنوان مثالlayout و painting)، کامیت بودن آن در صفحه و موقعیت آن در درخت کامپوننت ها است.class MyComponent extends React.Component { render() { return

Hello, world!

; } }در این مثال، MyComponent یک نود فیبر متناظر داره که نحوه رندر کردن این کامپوننت را توضیح می‌ده.واحدهای کاری یا Work Unit هافرآیند به روز رسانی UI به واحدهای کوچکتر به نام "کار" (work) تقسیم می شود. سه نوع کار وجود دارد:اول Reconciliation: تعیین اینکه چه چیزی بین DOM مجازی و DOM واقعی تغییر کرده است.دوم committing: اعمال تغییرات در DOM.سوم Rendering: در حال آماده سازی به روز رسانی بعدی.هر واحد کار رو می تونیم به صورت ناهمزمان(asynchronous) برنامه ریزی و اجرا کنیم و عملکرد را به ویژه برای برنامه های پیچیده بهبود بدیم.برنامه ریز یا Schedulerبرنامه ریز یا Scheduler بخش کلیدی معماری فیبره. اجرای واحدهای کاری را مدیریت می کنه و اونها را بر اساس فوریت و اهمیت اونها اولویت بندی می کنه. این به ری اکت اجازه می‌ده تا به‌روزرسانی‌های مهم‌تر رو تا زمانی که به‌روزرسانی‌های مهم‌تر پردازش نشده‌اند، به تعویق بندازه، و باعث کاهش jank و بهبود عملکرد درک شده می‌شه.حالت همزمان یا Concurrent Modeیکی از هیجان انگیزترین ویژگی های فعال شده توسط معماری فیبر، concurrent mode هست. این حالت به ری اکت اجازه می‌ده تا بدون مسدود کردن رشته اصلی(main thread)، پردازش به‌روزرسانی‌ها رو آغاز کنه، که منجر به ایجاد انیمیشن‌ها و تعاملات روون‌تر می‌شه. همچنین ویژگی‌های جدیدی مانند برش زمان (time slicing) را فعال می‌کنه، که در آن وظایف طولانی‌ مدت به تکه‌های کوچک‌تری تقسیم می‌شن که میشه اون‌ها رو قطع کرد و دوباره شروع کرد و از فریز شدن برنامه در طول محاسبات سنگین یا درخواست‌های شبکه جلوگیری کرد.چطور کار می کنه؟وقتی که یه تغییر حالت در یک برنامه ری اکتی رخ می ده، مراحل زیر با استفاده از معماری Fiber انجام می شود:اصلاح یا Reconciliation: ری اکت با مقایسه DOM مجازی فعلی با DOM جدید ایجاد شده پس از تغییر حالت شروع می شه. این فرآیند مشخص می کند که چه بخش هایی از DOM باید به روز شود.ایجاد درختان فیبر: برای هر کامپوننت، ری اکت یک درخت فیبر ایجاد می کند که نمایشی از سلسله مراتب component هاست. این درخت به مدیریت وضعیت و چرخه حیات هر component کمک می کنه.زمان‌بندی کار: بر اساس تفاوت‌های موجود در حین reconcilation، ری اکت موارد کاری را زمان‌بندی می‌کنه. این موارد نشان دهنده وظایف مورد نیاز برای به روز رسانی UI هستند، مانند رندر مجدد کامپوننت ها یا اعمال انتقال CSS.اجرای کار: Scheduler این موارد کاری را به صورت ناهمزمان اجرا می کنه و اطمینان حاصل می کنه که به روز رسانی های با اولویت بالا قبل از موارد با اولویت پایین تر تکمیل می شن.انجام تغییرات: زمانی که همه موارد کاری پردازش شدن، ری اکت تغییرات را در DOM انجام می ده و اونها را برای کاربر قابل مشاهده می کنه.نتیجهری اکت فایبر، نشان دهنده یک تحول بزرگ در معماری ری اکت هست و مفاهیمی مانند نودهای فیبر، واحدهای کاری، Scheduler و Concurrent Mode را معرفی می کنه. React Fiber با تقسیم فرآیند رندر به قطعات کوچکتر و قابل مدیریت و اجرای آنها به صورت ناهمزمان، عملکرد، پاسخگویی و تجربه توسعه دهنده را بهبود می بخشه. همونطور که ری اکت به تکامل خود ادامه می دهد، درک معماری فیبر برای ساخت برنامه های کاربردی وب کارآمد و مقیاس پذیر اهمیت فزاینده ای پیدا می کنه.

فرق بین compile و transpile چیه؟

Farokh Hasanzadeh — Sun, 30 Jun 2024 16:06:23 +0330

کامپایل و ترانسپایل دو مفهوم اساسی در توسعه نرم افزار هستن که نقش مهمی در تبدیل کد قابل خواندن توسط انسان(human-readable code) به فرمتی قابل اجرا توسط ماشین ها یا سایر محیط های زمان اجرا دارن. این دو اگرچه شباهت‌های مشترکی دارن، اما اهداف مشخصی را دنبال می‌کنن و در زمینه‌های مختلف مورد استفاده قرار می‌گیرن.کامپایلینگ (compiling) چیه؟کامپایل به فرآیند کلی ترجمه کد منبع (source code) نوشته شده در یک زبان به زبان دیگر اشاره داره. به طور خاص، کامپایلرها کد نوشته شده در زبان های سطح بالا را که دارای درجه انتزاعی (abstraction) بالاتری نسبت به کد ماشین هستند، به زبان اسمبلی سطح پایین یا کد ماشین تبدیل می کنن. این تبدیل سطح انتزاع (abstraction) را کاهش می ده و کد رو مستقیماً توسط سخت افزار رایانه قابل اجرا می کنه.ترانسپایلینگ (transpiling) چیه؟ترانسپایلینگ، میشه گفت، شکل خاصی از کامپایل هست که در اون کد منبع (source code) به زبان دیگری ترجمه می‌شود که سطح انتزاعی (abstraction) مشابهی را حفظ می‌کند. برخلاف کامپایلرها که سطوح انتزاع (abstraction) را کاهش می دهند، ترانسپایلرها سطح انتزاع زبان اصلی را حفظ می کنند. به این معنا که کد خروجی در یه زبان سطح بالا باقی می ماند، البته احتمالاً متفاوت از کد منبع.تفاوت های اساسی شون چیه؟سطح انتزاع(abstraction level): هدف کامپایلرها کاهش سطح انتزاع با تبدیل کدهای سطح بالا به کد ماشین سطح پایین یا زبان اسمبلی هست. با این حال، ترانسپایلرها با تبدیل کد از یک زبان سطح بالا به زبان دیگر، همان سطح انتزاع رو حفظ می کنن.موارد استفاده: کامپایلرها به شکل گستردای در زبان های برنامه نویسی سنتی مانند C، C++ و جاوا استفاده می شن، جایی که هدف بهینه سازی عملکرد و سرعت اجرا هست. از طرف دیگه، ترانسپایلرها معمولاً در توسعه وب مدرن استفاده می‌شن و به توسعه‌دهندگان اجازه می‌دهند تا کد را به زبان‌های جدیدتر و رساتر بنویسن (مانند ES6+ JavaScript) که می‌تونن به نسخه‌های قدیمی‌تر و با پشتیبانی گسترده‌تر (مانند ES5) برای سازگاری گسترده‌تر ترجمه بشن.مثلا:تبدیل کد جاوا به دستورات زبان اسمبلی نمونه ای از کامپایل هست. تبدیل کد جاوا به کد ++C به عنوان نمونه ای از ترنسپایل عمل می کنه.مفهوم کاربردیدرک تمایز بین کامپایل و ترانسپایل برای توسعه دهندگان، به ویژه کسانی که با فناوری های وب مدرن کار می کنن، خیلی مهمه. ابزارهایی مثل Babel و TypeScript ترانسپایلرهای محبوبی هستن که به توسعه دهندگان اجازه می دهند کد را به زبان های پیشرفته (مانند TypeScript یا ES6+) بنویسن و اون را برای سازگاری با مرورگرهای قدیمی تر به جاوا اسکریپت ES5 منتقل کنن. این فرآیند به توسعه دهنده ها اجازه میده تا از مزایای ویژگی های زبان جدیدتر و در عین حال پشتیبانی گسترده از مرورگر استفاده کنن.به طور خلاصه، در حالی که هم کامپایل و هم ترانسپایل شامل تبدیل کد از شکلی به شکل دیگر است، اما در اهداف و سطوح انتزاع درگیر با هم تفاوت دارن. هدف کامپایلرها کاهش انتزاع برای کارایی و عملکرد هست، در حالی که ترانسپایلرها سطوح انتزاعی را برای سازگاری و سهولت توسعه حفظ می کنن.

مروری بر استفاده از وب فونت، svg و svg sprite

Farokh Hasanzadeh — Wed, 15 May 2024 13:00:22 +0330

پیش از این برنامه نویس ها "سیستم های آیکون" شون رو با استفاده از PNG Sprite ها، فونت آیکون ها، فایل های PNG یا SVGمستقل و غیره پیاده سازی می کردن. همه این راه حل ها مزایا و معایب خودش رو داشت. چند تا از این روش های رو پایین ببینیم.وب فونت:از یکی از معروفترین مرجع های وب فونت ها می توان به fontawesome اشاره کرد.استفاده از کلاس راه حل متداول استفاده از وب فونت هاست.svg:یک فرمت گرافیکی بر اساس وکتور و با فرمت XML است. این فرمت با عوض شدن اندازه یا زوم، کیفیت خود را از دست نمی دهد.Svg sprites:این فرمت مجموعه از آیکون های svg را در یک فایل svgجمع می کند. هر آیکون یک آیدی منحصر به فرد دارد که برای دسترسی به آن می توان از آن آیدی استفاده کرد. برای تعریف هر svg زیر مجموعه sprite می بایست از symbol استفاده کرد و برای استفاده از آن می بایست از تگ use استفاده کرد.این روزها مقایسه SVG Sprite ها و فونت آیکون هاست که اهمیت بیشتری داره.بقیه گزینه ها رو معمولا دیگه این روزا استفاده نمی کنیم. چرا چون مثلا برای دریافت هر SVG مستقل باید یه درخواست جداگونه زد. وقتی حجم فایل هر SVG کوچیک باشه، خب این خیلی عملکرد بالاتری داره که ما با یه درخواست مجموعه ای از SVG ها رو دریافت کنیم و بعدش هم کش کنیم. مشکلی که PNG داره اینه که با تغییر سایز کیفیت خودش رو از دست میده و نمی تونه گزینه خوبی برای آیکون باشه.و اما مقایسه بین SVG Sprite ها و فونت آیکون ها:سایز:فونت آیکون ها معمولا سایز کمتری نسبت به SVG Sprite ها دارن. اما اینم در نظر بگیرین اگر کتابخونه فونت آیکونی که استفاده می کنیم شامل تعداد زیادی فونت بشه، صرفه جویی چندانی نخواهیم داشت.برنده: فونت آیکون هاتجربه کاربری:هم فونت آیکون ها و هم SVG Sprite ها می تونن با اولین درخواست سمت مرورگر کش بشن و دفعات بعد ازشون استفاده بشه.برنده: نامشخصقابل استفاده بودن (Accessibility):یکی از بهترین مزایای SVG در مقابل وب فونت ها، پشتیبانی اون ها از گزینه های Accessibility است. SVG از Element های موجودی شبیه و <desc> است که برای screen reader ها و text browser ها قابل دسترسی است. علاوه بر این، SVG ها به عنوان یک تصویر شناخته میشن نه یه متن.برنده: SVG Spriteسفارشی سازی:شما سایز و رنگ هر دو رو می تونید با استایل دهی تنظیم کنید. SVG در کنار این ها قابلیت متحرک بودن و چند رنگی بودن هم داره. برنده: SVG Spriteپشتیبانی مرورگر:فونت آیکون های بسیار وسیع در مرورگرها مخصوصا مرورگرهای قدیمی استفاده میشن. SVG Sprite ها، در مرورگرهای مدرن خیلی خوب پشتیبانی میشن اما مرورگرهای قدیمی مثل IE8 ازشون پشتیبانی نمیکنه.برنده: فونت آیکون ها </article> </main></body></html>