https://virgool.ir/feed/@ahmadi.hadiطراح و معمار نرم‌افزار | دانشجوی مدل‌ها و سیستم‌هاfa2026-11-11 07:21:15https://files.virgool.ir/upload/users/4031491/avatar/2XiMfp.jpghttps://virgool.ir/@ahmadi.hadihttps://virgool.ir/santez/کمیته-ها-چگونه-اختراع-می-کنند-نوشته-ملوین-کانوی-nt4incqgthijمشخصاتعنوان اصلی: ?How Do Committees Inventنویسنده: Melvin E. Conwayانتشار اولیه: مجله Datamation – آوریل ۱۹۶۸فایل PDF مقاله اصلیفایل PDF نسخه ترجمهمقدمه - یادداشتی از وب‌سایت شخصی نویسنده (لینک)در سال ۱۹۶۷، مقاله‌ای با عنوان «کمیته‌ها چگونه اختراع می‌کنند؟» به نشریه Harvard Business Review ارائه دادم. این مقاله از سوی HBR رد شد، به این علت که از نظر آن‌ها، من موفق به اثبات فرضیه‌ام نشده بودم. سپس آن را برای نشریه Datamation، که در آن زمان مهم‌ترین مجله حوزه IT بود، فرستادم و آن‌ها مقاله را در آوریل ۱۹۶۸ منتشر کردند.تز اصلی مقاله را می‌توان به این صورت بیان کرد:«هر سازمانی که اقدام به طراحی یک سیستم (در معنای وسیع کلمه) می‌کند، ناگزیر طرحی ارائه می‌دهد که ساختارش بازتابی از ساختار ارتباطی همان سازمان است.»آقای Fred Brooks در کتاب زیبا و تاثیرگذارش به نام The Mythical Man-Month، به این مقاله و ایده اشاره کرد و آن را «قانون Conway» نام‌گذاری کرد. این عنوان به مرور رایج و ماندگار شد. این مفهوم نخستین‌بار در دنیای نرم‌افزار مطرح شد، اما به این حوزه محدود نمی‌شود.در ادامه، بخشی از محتوای Wikipedia درباره این قانون را می‌خوانید:قانون Conway نه به‌عنوان یک شوخی یا گفته‌ای رمزآلود، بلکه به‌عنوان یک مشاهده‌ی معتبر جامعه‌شناختی مطرح شده است. بر اساس این اصل، دو ماژول نرم‌افزاری (مثلاً A و B) تنها زمانی می‌توانند به‌درستی با یکدیگر ارتباط برقرار کنند که طراح و توسعه‌دهنده A با طراح و توسعه‌دهنده B در تعامل باشند. در نتیجه، ساختار Interfaceهای یک سیستم نرم‌افزاری به‌طور اجتناب‌ناپذیر با ساختار اجتماعی سازمانی که آن را ایجاد کرده، هم‌راستا خواهد بود.Brooks به این نکته پی برد که این قانون در نظریه‌های مدیریتی نیز پیامدهای مهمی دارد. یکی از این پیامدها در مقاله اینطور مطرح شده است:از آنجا که نخستین طراحی معمولاً بهترین گزینه ممکن نیست، حتی ممکن است لازم باشد ماهیت و تعریف کلی سیستم تغییر کند. بنابراین، انعطاف‌پذیری سازمان برای دستیابی به یک طراحی مؤثر، اهمیت زیادی دارد.با نگاهی به گذشته، به‌نظر می‌رسد که دلیل رد مقاله توسط HBRبیشتر نشان‌دهنده اختلاف‌نظر در درک معنای «اثبات» باشد تا نقدی واقعی بر محتوای مقاله.گرچه معمولا به این قانون در حوزه مهندسی نرم‌افزار اشاره می‌شود، اما کاربرد آن بسیار گسترده‌تر است. از شما دعوت می‌کنم مقاله را بخوانید، و سپس در اطراف خود به دنبال کاربردهایش بگردید. این روزها، نمونه‌ای که ذهن من را درگیر کرده، مسائل اجتماعی گسترده‌ای است که فقر در آمریکا را در بر می‌گیرد: کمبود کار، مسکن، آموزش، و خدمات سلامت و بهداشتی.پس از خواندن مقاله، به این فکر کنید که ساختارهای مختلف دولتی ما، چگونه بر شیوه‌ی مواجهه آن‌ها با این سیستم تأثیر می‌گذارند.کمیته‌ها چگونه اختراع می‌کنند؟ نوشته Melvin E. Conway - آوریل 1968آن نوع فعالیت فکری که اجزای گوناگون را به یک کلِ مفید تبدیل می‌کند، طراحی یک سیستم نامیده می‌شود. فرقی نمی‌کند که این فعالیت مربوط به طراحی یک سامانه‌ی تسلیحاتی بزرگ باشد، یا ارائه پیشنهادی برای حل یک معضل اجتماعی، و یا حتی نوشتن یک نرم‌افزار؛ در نهایت، فعالیت کلی تا حد زیادی یکسان است.معمولاً هدف سازمانی که طراحی را انجام می‌دهد، ایجاد و تدوین سندی منسجم شامل مجموعه‌ای از اطلاعات ساختاریافته و یکپارچه است. این مجموعه اطلاعات را می‌توان طراحی سیستم (System Design) نامید. طراحی معمولاً به سفارش یک سرمایه‌گذار انجام می‌شود که هدفش راه‌اندازی یا توسعهٔ یک فعالیت با تکیه بر آن است. برای مثال، یک نهاد دولتی ممکن است تصمیم بگیرد قانونی وضع کند تا از تکرار یک فاجعه جلوگیری شود. در نتیجه، تیمی را مأمور می‌کند تا آن فاجعه را بررسی و تحلیل کند. یا یک شرکت تولیدی که قصد عرضه‌ی محصولی جدید را دارد، فرآیندی را برای برنامه‌ریزی و تعریف ویژگی‌های محصول تدوین می‌کند.سازمانی که طراحی را انجام می‌دهد ممکن است در اجرای طرح و ساخت سیستم نقش داشته یا نداشته باشد. برای مثال، در امور دولتی معمولا سیاست‌هایی وجود دارد که مانع از اجرای طرح توسط همان گروه طراح می‌شود، اما در صنایع خصوصی این موضوع معمولا برعکس است.این که طراح بداند خود باید طرح‌هایش را اجرا کند یا این وظیفه بر عهده‌ی دیگران است، ممکن است بر برخی از تصمیم‌های او هنگام طراحی اثر بگذارد. بخش بزرگی از فرآیند طراحی نیازمند تصمیم‌گیری‌های مداوم است. بسیاری از این انتخاب‌ها ممکن است صرفاً در حوزه طراحی نباشند، بلکه تصمیمات شخصی‌ای باشند که طراح درباره‌ی آینده‌ی خود می‌گیرد. همان‌طور که در ادامه این مقاله خواهیم دید، در یک نظام مدیریتی سنتی و متعارف، برخی عوامل ممکن‌ است طراح را به سمت انتخاب‌هایی سوق دهند که اهداف سرمایه‌گذار را تضعیف کند یا حتی زیر سوال ببرد.[1]مراحل طراحیمراحل ابتدایی یک فرآیند طراحی، بیشتر از اینکه به سیستم بپردازند، بر سازمان‌دهی و ساختاردهی خود فرآیند طراحی متمرکز هستند. فعالیت اصلی طراحی تنها پس از عبور از مراحل کلیدی و نقاط عطف اولیه ممکن می‌شود. برخی از این موارد عبارتند از:درک Boundary ها و مرزهای موجود، هم برای فعالیت طراحی و هم برای سیستمی که قرار است طراحی شود. این مرزها ممکن است توسط سرمایه‌گذاران و یا واقعیت‌های جهان تعیین یا اعمال شوند.کسب درک اولیه از ساختار سیستم به‌منظور تخصیص صحیح وظایف طراحی به گروه‌های مرتبط.در ادامه خواهیم دید که تشکیل و سازمان‌دهی تیم طراحی، در واقع به معنای گرفتن برخی تصمیم‌های طراحی پیش از شروع کار است. در هر شکل از سازمان‌دهی تیم طراحی، برخی گزینه‌های طراحی به دلیل نبود مسیرهای ارتباطاتی (Communication Path) لازم، عملاً قابل پیگیری یا اجرای مؤثر نخواهند بود. بنابراین، هر تیم طراحی که سازمان‌یافته و دارای ساختار مشخصی باشد، ناگزیر دچار نوعی سوگیری خواهد بود.وقتی ساختار تیم طراحی مشخص شد، می‌توان کارها و وظایف مختلف را بین زیرگروه‌ها تقسیم کرد. هر بار که بخشی از طراحی به فردی واگذار می‌شود، حوزه‌ی کاری و تصمیم‌گیری‌اش محدودتر شده و فقط روی همان بخش مشخص متمرکز می‌شود. در نتیجه‌ی این تمرکز محدود، برخی گزینه‌های طراحی حتی فرصت ارزیابی یا اجرا پیدا نمی‌کنند و در نتیجه گزینه‌های قابل انتخاب کمتر می‌شوند.به محض تعیین حوزه و محدوده‌ی فعالیت‌ها، چالش هماهنگی (Coordination) میان اجزای مختلف نمایان می‌شود. هماهنگی میان تیم‌های مختلف ممکن است باعث کاهش بازدهی فردی شود، اما بدون این هماهنگی، ادغام کارهای مستقل در قالب یک طرح یکپارچه و هماهنگ امکان‌پذیر نیست.طراحی یک سیستم در چارچوب مراحل کلی زیر پیش می‌رود:تعیین Boundaryها و مرزها بر اساس اصول و قوانین پایه (Ground Rules)انتخاب یک مفهوم و ایده‌ی اولیه برای سیستم.سازمان‌دهی فعالیت طراحی و تخصیص وظایف بر اساس مفهوم و ایده اولیه سیستم.ایجاد هماهنگی میان مسئولیت‌های محول‌شده.ادغام و یکپارچه‌سازی بخش‌های مختلف طراحی در قالب یک طراحی واحد.فعالیت‌های طراحی همیشه دقیقاً به همان ترتیبی که در این لیست آمده‌اند اجرا نمی‌شوند. برای مثال، در صورت کشف یک مفهوم جدید و بهتر، فرآیند طراحی ممکن است مورد بازبینی قرار گرفته و مجدداً سازمان‌دهی شود. اگرچه این عدم قطعیت بخشی از ماهیت طراحی است، اما معمولاً خوشایند نیست و کنار گذاشتن طرح قبلی معمولاً تصمیمی دردناک و پرهزینه محسوب می‌شود. مرور تجربه‌های گذشته نشان می‌دهد که این الگو بارها تکرار شده و در نتیجه‌ی آن، چنین مشاهداتی به‌طور مکرر گزارش شده‌اند: «هرگز زمان کافی برای انجام صحیح یک کار نیست، اما همیشه فرصت برای انجام دوباره‌ی آن (اصطلاحا دوباره کاری) وجود دارد.»سیستمِ طراحی شدههر سیستم پیچیده از مجموعه‌ای از زیرسیستم‌ها تشکیل شده است که با یکدیگر در ارتباط و وابستگی متقابل قرار دارند. برای توصیف آنچه درون یک سیستم اتفاق می‌افتد، لازم است هم رابطه‌ی سیستم با دنیای بیرون و هم ساختار داخلی زیرسیستم‌ها و ارتباطات میان آن‌ها مشخص شود. اگر ساختار را یک سطح پایین‌تر بررسی کنیم، همین قاعده درباره‌ی هر زیرسیستم هم صدق می‌کند، زیرا هر زیرسیستم خود می‌تواند به‌عنوان یک سیستم مستقل در نظر گرفته شود. کار را می‌توان آن‌قدر ادامه داد تا به سیستمی برسیم که درک آن بدون نیاز به تجزیه‌ی بیشتر ممکن باشد.مثال‌ها. یک سامانه‌ی حمل‌ونقل عمومی بین‌قاره‌ای از اجزایی مانند اتوبوس‌ها، قطارها، هواپیماها، مسیرهای ویژه، پارکینگ‌ها، تاکسی‌ها، ترمینال‌ها و سایر زیرساخت‌ها تشکیل شده است. در اینجا با سیستمی ناهمگن (Heterogeneous) و چندوجهی روبرو هستیم که زیرسیستم‌های آن بسیار گوناگون و متنوع هستند. برای مثال در سطح پایین‌تر، هواپیما خود شامل زیرسیستم‌هایی برای سازه و بدنه هواپیما، نیروی پیشران، توزیع انرژی، ارتباطات و جانمایی محموله‌ها و بارها است. همینطور در یک سطح پایین‌تر، سیستم پیشران هواپیما شامل بخش‌هایی مانند تامین سوخت، احتراق و راه‌اندازی موتور است.شاید در ابتدا چندان واضح به نظر نرسد، اما نظریه یا تئوری نیز در واقع یک سیستم است. تئوری با دنیای بیرون و رویدادهای آن مرتبط است و باید آن‌ها را توضیح دهد یا دست‌کم با آن‌ها در تضاد نباشد. یک تئوری از تئوری‌های کوچک‌تری تشکیل شده که باید همانند اجزای یک سیستم، به‌صورت منسجم و هماهنگ به یکدیگر مرتبط باشند. بررسی سقوط یک هواپیما تلاشی برای تدوین تئوری یا نظریه‌ای به منظور توضیح یک حادثه پیچیده است. این تئوری می‌تواند شامل مجموعه‌ای از تئوری‌ها باشد که مسیر پرواز هواپیما، مکالمات رادیویی، نحوه‌ی صدمه‌دیدگی و ارتباط هواپیما با اشیای پیرامون در لحظه‌ی وقوع حادثه را توضیح می‌دهند. هر یک از این‌ تئوری‌ها به نوبه‌ی خود روایتی مستقل است که می‌توان آن را به جزئیات دقیق‌تر شکافت و تا سطح کوچک‌ترین شواهد تحلیل کرد.گراف‌های خطی. در شکل ۱، از یک گراف خطی برای به تصویر کشیدن یک سیستم استفاده شده است—ساختاری شبیه به Tinker-Toy [2] که در آن Branch ها در قالب خطوط و Node ها در قالب دایره‌ها به هم متصل‌ شده‌اند. هر Node یک زیرسیستم محسوب می‌شود که از طریق Branch‌ها با سایر زیرسیستم‌ها در ارتباط است. هر زیرسیستم نیز شامل ساختاری است که می‌تواند به همین صورت به تصویر کشیده شود. Interfaceها کانال و مسیر ارتباطی بین زیرسیستم‌ها را نشان می‌دهند. به بیان دیگر، Interface همان درگاه یا نقطه‌اتصال است که ارتباط بین دو Node را برقرار کرده و یک Branch را ایجاد می‌کند. [3]شکل 1برقراری ارتباط بین این دوگراف خطی ابزاری مفید و کارآمد است که فرمی یکسان برای دو موجودیت موردنظر ما ارائه می‌کند: سازمانی که طراحی می‌کند و سیستمی که طراحی می‌شود. این موضوع را می‌توان در شکل ۱ با جایگزینی واژه‌های زیر نشان داد:عبارت «سیستم» را با «کمیته» جایگزین کنید. System → Committeeعبارت «زیرسیستم» را با «زیرکمیته» جایگزین کنید. Subsystem → Subcommitteeعبارت «رابط» را با «هماهنگ‌کننده» جایگزین کنید. Interface → Coordinatorدرست مانند سیستم‌ها، گروه‌های طراحی نیز در سطوح مختلف قابل بررسی هستند. برای مثال، دولت فدرال نمونه‌ای بارز از یک سازمان طراحی است که پیچیدگی‌های آن می‌تواند توجه هر مهندس سیستمی را به خود جلب کند. دولت فدرال مثال جالبی برای نشان دادن شباهت دو مفهوم مورد بررسی است، زیرا هم یک سازمان طراحی است (که قوانین، معاهدات و سیاست‌ها را طراحی می‌کند) و هم یک سیستم طراحی‌شده است (که قانون اساسی، سند طراحی اولیه‌ی آن محسوب می‌شود).یک رابطه‌ی ساده. اکنون می‌توانیم به پرسش اصلی این مقاله بپردازیم: آیا رابطه‌ای مشخص و قابل پیش‌بینی بین گراف سازمان طراحی و گراف سیستم طراحی‌شده وجود دارد؟ بله. این رابطه بسیار ساده است و حتی در برخی موارد این ساختارها کاملا یکسان هستند. به اثبات زیر توجه کنید:بیایید به‌طور تصادفی یک سیستم و سازمان طراحی آن را انتخاب کنیم. سپس سطحی از پیچیدگی آن سیستم را انتخاب کنیم که امکان ترسیم گراف برای آن وجود داشته باشد (انتخاب تصادفی به این دلیل انجام می‌شود که در صورت اثبات مسئله، نتیجه برای تمامی سازمان‌های طراحی و سطوح مختلف پیچیدگی قابل تعمیم خواهد بود). شکل ۲ مدلی ارائه می‌دهد که صرفاً جهت درک بهتر موضوع طراحی شده و می‌توان اظهارات زیر را به آن نسبت داد.به ازای هر Node در سیستم، می‌توان تیمی را در سازمان طراحی شناسایی کرد که مسئول طراحی آن بوده است. برای مثال در این تصویر، تیم x’ مسئول طراحی زیرسیستم x بوده است. با تعمیم این روند، هر Nodeدر سیستم را می‌توان به یک Node متناظر در سازمان طراحی مرتبط کرد. توجه داشته باشید که این قاعده الزاما یک-‌به-‌یک نیست؛ به این معنا که ممکن است یک تیم، مسئول طراحی دو زیرسیستم مختلف باشد.شکل 2 - ساختار یک سیستم (چپ) ساختار سازمانی که آن را طراحی کرده است (راست) جالب است که می‌توان این موضوع را درباره‌ی Branchها نیز مطرح کرد. دو Node (برای مثال xو y) از سیستم را در نظر بگیرید. این دو Node یا از طریق یک Branch به یکدیگر متصل‌اند، یا هیچ‌گونه ارتباطی میان آن‌ها وجود ندارد؛ به بیان دیگر، در عملکرد سیستم، یا با هم تعامل دارند یا کاملاً مستقل عمل می‌کنند. در صورت وجود ارتباط، تیم‌هایی که این Nodeها را طراحی کرده‌اند، باید درباره‌ی مشخصات Interface مذاکره کرده و به توافق رسیده باشند تا ارتباط بین دو Node در سازمان طراحی امکان‌پذیر شود (لزوما تیم‌های متفاوت نیستند و ممکن است یکی باشند). از سوی دیگر، اگر دو Nodeدر سیستم به هم متصل نباشند، به این معناست که این دو زیرسیستم هیچ ارتباطی با یکدیگر ندارند. بنابراین، نیازی به تعامل و مذاکره بین تیم‌های طراحی آن‌ها نبوده و در نتیجه، ارتباطی میانشان شکل نمی‌گیرد.[4]تا اینجا چه فهمیدیم؟ دیدیم که بین ساختار یک سیستم و ساختار سازمان طراحی‌کننده‌ی آن، ارتباط تنگاتنگی وجود دارد. اگر هر زیرسیستم را یک تیم مستقل طراحی ‌کند (که چندان نادر هم نیست)، ساختار تیم‌های طراحی و ساختار سیستم کاملا یکسان خواهند بود. در صورتی که یک تیم مسئول طراحی چندین زیرسیستم باشد، ساختار سازمان نسخه‌ای فشرده‌شده‌ از ساختار سیستم خواهد بود. به این معنا که زیرسیستم‌هایی که در اختیار یک تیم هستند، در ساختار سازمان در یک Node ادغام می‌شوند.این نوع رابطه‌ که ساختار را میان دو مجموعه حفظ می‌کند، با عنوان Homomorphism یا هم‌ریختی[5] شناخته می‌شود. به بیان ریاضی، می‌توان گفت که بین گراف خطی یک سیستم و گراف خطی سازمانی که آن سیستم را طراحی می‌کند، هم‌ریختی وجود دارد.سیستم‌ها انعکاسی از گروه‌های طراحی خود هستندطراحان باتجربه می‌دانند که هیچ طرحی‌ بهترین و کامل‌ترین طرح نیست و دیر یا زود کسی طراحی بهتری برای برای انجام همان کار ارائه خواهد داد. به بیان دیگر، در نظر گرفتن طرحی به‌عنوان بهترین راه‌حل، نادرست و گمراه‌کننده است؛ مگر اینکه آن را در چارچوب فضا، زمان، دانش و فضای مسئله بررسی کنیم. پذیرش این واقعیت باید در طراحان سیستم نوعی تواضع ایجاد کند، چرا که مرور تاریخ یا تجربه‌های پیشین نشان می‌دهد که همیشه می‌توان راه بهتری پیدا کرد.پیشرفت کامپایلرهای زبان‌های برنامه‌نویسی FORTRAN و COBOL نمونه‌ای بارز از این موضوع است. در اواسط دهه‌ی پنجاه میلادی، زمانی که نسخه‌های اولیه‌ی این زبان‌ها معرفی شدند، کامپایلرهای آن‌ها حتی از ابر کامپیوترهایی که باید روی آن‌ها اجرا میشدند نیز پیچیده‌تر و دست‌وپاگیرتر بودند. امروزه، این کامپایلرها جزو یادگارهای تاریخی محسوب می‌شوند و طراحی آن‌ها هیچ شباهتی به کامپایلرهای پیشرفته‌ امروزی ندارد. (جالب است بدانیم که پیشرفت‌های بزرگ در طراحی کامپایلرها، دقیقاً زمانی رخ داد که افراد جدیدی پا به این حوزه گذاشتند. در ابتدا تیم‌های تحقیقاتی کوچک دانشگاهی وارد شدند و بعد از آن شرکت‌های نرم‌افزاری مستقل، در حالی که تا قبل از آن، این حوزه تقریباً در انحصار سازندگان کامپیوتر بود.)اگر بپذیریم که همواره چندین گزینه‌ی طراحی متفاوت می‌توانند یک نیاز مشخص را برآورده سازند، این پرسش مطرح می‌شود که آیا ساختار سازمان طراحی در انتخاب یکی از آن‌ها نقشی ایفا می‌کند؟ بله. اگر فرض Homomorphism یا هم‌ریختی که قبل‌تر مطرح کردیم صحیح باشد، نمی‌توان این تاثیر را انکار کرد. اگر یک سازمان در ساختار ارتباطی خود منعطف نباشد، هر طرحی که ارائه کند، تصویر و ردپایی از ساختار خودش را خواهد داشت. هرچه سازمان بزرگتر باشد، انعطاف‌پذیری کمتری خواهد داشت و این پدیده آشکارتر خواهد شد.مثال‌ها. یک شرکت تحقیقاتی برنامه داشت تیمی هشت‌نفره را به توسعه‌ی کامپایلرهای COBOL و ALGOL اختصاص دهد. بعد از تخمین‌های اولیه درباره‌ی پیچیدگی و زمان مورد نیاز، پنج نفر به پروژه‌ی COBOL و سه نفر به پروژه‌ی ALGOL اختصاص داده شدند. نتیجه این بود که کامپایلر COBOL شامل پنج مرحله پردازش بود و کامپایلر ALGOLشامل سه مرحله.دو واحد نظامی، توسط ستاد فرماندهی کل موظف شدند تا یک سیستم تسلیحاتی مشترک را برای نیازهای خود توسعه دهند. بعد از تلاش فراوان، آن‌ها در نهایت یک کپی از چارت سازمانی‌شان تهیه کردند. (شکل 3)شکل 3 - یک سامانه تسلیحاتی نظامییک سیستم کامپیوتری در حال اجرا را تصور کنید که مشغول حل یک مسئله است. در یک نگاه کلی، این سیستم از سه بخش اصلی تشکیل شده است: سخت‌افزار، نرم‌افزارهای سیستمی و نرم‌افزارهای کاربردی. (برای مثال، یک نرم‌افزار حسابداری که روی یک سیستم‌عامل نصب شده و روی یک سخت‌افزار اجرا می‌شود.) (شکل 4) هر یک از این زیرسیستم‌ها توسط گروه خاصی طراحی شده‌اند: مهندسان سخت‌افزار، برنامه‌نویسان سیستمی و برنامه‌نویسان نرم‌افزارهای کاربردی. (موارد نادری که در یک سیستم، سخت‌‎افزار و نرم‌افزار به طور موثر و هماهنگ با هم کار می‌کنند، معمولا در شرکت‌هایی اتفاق می‌افتد که برنامه‌نویسان و مهندسان سخت‌افزار نیز همکاری و هماهنگی خوبی دارند.)شکل 4 – Homomorphism بین یک سیستم کامپیوتری و سازمان طراحی آن. (تصویر از مقاله اصلی)مدیریت سیستم – System Managementدر طول فرآیند توسعه، سیستم‌های بزرگ بیشتر از سیستم‌های کوچک دچار ازهم‌گسیختگی (Disintegration) ساختاری می‌شوند. این موضوع در سیستم‌های پیچیده اطلاعاتی نظامی که طی دوازده سال گذشته توسعه یافته‌اند، کاملاً مشهود است؛ سیستم‌هایی که از پیچیده‌ترین ساخته‌های بشر به شمار می‌روند. برای مقابله با این مشکل، فعالیتی به نام «مدیریت سیستم» شکل گرفته است. حال بیایید ببینیم مفاهیمی که تا اینجا بررسی کردیم، چگونه می‌توانند به مدیریت سیستم کمک کنند.چرا سیستم‌های بزرگ دچار ازهم‌گسیختگی می‌شوند؟ این فرآیند در سه مرحله رخ می‌دهد. دو مرحله‌ی نخست را می‌توان کنترل کرد، اما مرحله‌ی سوم تاثیر و پیامد مستقیم Homomorphism است:اولین مرحله، زمانی است که طراحان متوجه می‌شوند که با یک سیستم بسیار بزرگ روبه‌رو هستند. این موضوع در کنار فشارهای داخلی سازمان، باعث می‌شود آن‌ها در برابر وسوسه‌ی استفاده از نیروی انسانی زیاد در فرآیند طراحی، مقاومتی نشان ندهند.در گام بعد، مشکلات ناشی از روش‌های مدیریتی متداول و نادرست، باعث ازهم‌گسیختگی و اختلال در ساختار ارتباطی آن سازمان می‌شود.در مرحله‌ی سوم، هم‌ریختی یا Homomorphism وارد شده و ازهم‌گسیختگی به‌وجودآمده در سازمان را در ساختار سیستم منعکس می‌کند.بیایید ابتدا تمایل به اضافه کردن بیش از حد نیروی انسانی در فرآیند طراحی را بررسی کنیم. زمانی که پیچیدگی سیستم از حد درک طراح فراتر می‌رود، به‌طور طبیعی وسوسه می‌شود ناچار می‌شود برخی کارها را به دیگران واگذار کند. این لحظه، نقطه‌ی عطفی در مسیر طراحی است، به‌ویژه زمانی که از طراحان اولیه سخن می‌گوییم—کسانی که ایده‌ها و مفاهیم اولیه‌ی سیستم را شکل می‌دهند و تأثیر چشم‌گیری بر ساختار کلی فرآیند طراحی دارند. در این لحظه، یا طراح موفق می‌شود پیچیدگی سیستم را به سطح قابل درکی کاهش دهد، یا اینکه کنترل از دستش خارج می‌شود. اگر فشار زمانی و محدودیت بودجه وجود داشته باشد، نتیجه تقریباً از قبل معلوم است.یک مدیر به خوبی می‌داند که اگر پروژه به‌موقع تمام نشود و او از تمامی منابع در اختیارش استفاده نکرده باشد، ممکن است به سوء‌مدیریت متهم شود. این فشار، بار زیادی بر دوش طراحان می‌گذارد. احتمالا آن‌ها ترجیح دهد که خودشان به تنهایی (منظور در تیم‌های کوچک‌تر) با طراحی درگیر شوند، اما به آن‌ها گفته می‌شود که ریسک این کار بیش از حد بالاست. در نتیجه، مجبور می‌شود بخشی از کار را به دیگران بسپارد تا از منابع بیشتری استفاده کند.مثال زیر، نمونه‌ای دیگر است از شرایطی که در آن اولویت‌های مدیریتی ممکن است با یکپارچگی سیستم در تضاد قرار گیرد:مدیری را درنظر بگیرید که باید یک کار طراحی مهم و سخت را به یک پیمانکار واگذار کند. او دو گزینه پیش رو دارد: یک سازمان کوچک و نوپا که رویکردی به‌ظاهر جذاب را با هزینه‌ای به‌مراتب کمتر از بودجه‌ی تخصیص‌یافته پیشنهاد داده، و یک شرکت باسابقه اما سنتی که مبلغی «واقع‌بینانه‌تر» (به کنایه) درخواست کرده است. مدیر به خوبی می‌داند که در صورت ناکامی شرکت کوچک، مسئولیت شکست به گردن او خواهد افتاد؛ در حالی‌که ناکامی شرکت‌ بزرگ و باسابقه احتمالا به سختی پروژه نسبت داده می‌شود، نه ضعف مدیریت او.اما مشکل کجاست؟ بخش زیادی از مشکل به شیوه‌ی تفکری برمی‌گردد که در حسابداری سنتی برای ارزیابی منابع استفاده می‌شود. بر اساس این تفکر، واحد اندازه‌گیری منابع، پول است و همه‌ی منابع باید با مقیاسی سنجیده شوند که بتوان آن را به پول و دلار تبدیل کرد. وقتی صحبت از نیروی انسانی باشد، میزان منابع صرف‌شده برابر است با تعداد ساعت‌های کاری هر فرد ضرب‌در نرخ دستمزد ساعتی او، که در نهایت به ازای افراد محاسبه می‌شود.قانون پارکینسون[6] نقش مهمی در تخصیص بیش از حد منابع به فرآیند طراحی دارد. تا زمانی که جایگاه و قدرت یک مدیر به میزان بودجه‌‌ای که در اختیار دارد وابسته باشد، او تمایل به گسترش سازمان خود خواهد داشت که رویکردی نادرست در مدیریت سیستم محسوب می‌شود. باید توجه داشت زمانی که تیمی شکل بگیرد، به ناچار مورد استفاده قرار خواهد گرفت و برای آن کار تراشیده خواهد شد. شاید بتوان گفت که یکی از اصلی‌ترین دلایل ضعف بسیاری از سیستم‌های موجود همین است که تیم‌هایی که نیاز به کار داشته‌اند، صرفاً برای بقا و ادامه‌ی فعالیت خود دست به تعریف پروژه و کار زده‌اند.مرحله‌ی دوم ازهم‌گسیختگی، بروز اختلال در ساختار ارتباطی سازمان طراحی است که بلافاصله پس از واگذاری وظایف و کارها آغاز می‌شود. طبق اصول اولیه‌ی احتمال، تعداد مسیرهای ارتباطی ممکن در یک سازمان تقریباً برابر با نصف مربع تعداد افراد آن است [7]. حتی در سازمان‌های نسبتا کوچک نیز لازم است که ارتباطات محدود شوند تا افراد بتوانند مقداری «کار» انجام دهند. بنابراین، تحقیقاتی که به بهبود روش‌های ارتباطی بین طراحان کمک کنند، می‌توانند تأثیر بسزایی در مدیریت سیستم‌ها داشته باشند.شیوه‌های مدیریتی متداول، محدودیت‌هایی برای پیچیدگی ساختار سازمانی تعیین می‌کنند که مشابه ساختار اداری یک سازمان نظامی است. برای مثال، هر فرد باید حداکثر یک مافوق و تقریبا هفت زیردست داشته باشد. هرچه پروتکل‌های سازمانی ارتباطات را بیشتر در چارچوب مسیرهای رسمی و سلسله‌مراتبی قرار دهند، ساختار ارتباطی سازمان شباهت بیشتری به ساختار اداری آن پیدا خواهد کرد. این یکی از دلایلی است که سیستم‌های طراحی شده توسط سازمان‌های نظامی، به ساختار سلسله‌مراتبی آن‌ها شباهت زیادی دارند.نتیجه‌گیریایده‌ی اصلی مقاله این است که سازمان‌هایی که سیستم (به معنای گسترده‌ای که در این مقاله استفاده شده) طراحی می‌کنند، ناگزیر طراحی‌هایی انجام‌ می‌دهند که بازتابی از ساختار ارتباطی خودشان است. دیدیم که این واقعیت تاثیرات مهمی بر مدیریت طراحی سیستم دارد. مهم‌ترین نتیجه این تحلیل، یافتن معیاری برای ساختاربندی تیم‌های طراحی است: فرآیند طراحی باید بر اساس نیازهای ارتباطی سازمان‌دهی شود.البته این معیار خود می‌تواند مشکلاتی ایجاد کند، زیرا «نیاز به ارتباط» موضوعی وابسته به زمان است و به ایده و مفهومی بستگی دارد که در آن لحظه برای سیستم تعریف شده است. از آنجا که طرح اولیه تقریبا هیچوقت بهترین طراحی ممکن نیست، احتمال دارد که مفهوم سیستم در گذر زمان دستخوش تغییر شود.در نتیجه، انعطاف‌پذیری سازمان نقشی حیاتی در ایجاد یک طراحی مؤثر دارد. باید راه‌هایی برای تشویق و ترغیب مدیران طراحی به حفظ سازمان‌های کوچک و انعطاف‌پذیر پیدا کرد. همچنین، لازم است فلسفه‌ای در مدیریت طراحی سیستم‌ها شکل بگیرد که این تصور غلط را کنار بگذارد که افزودن نیروی انسانی به‌طور مستقیم موجب افزایش بهره‌وری می‌شود. پرورش چنین نگرشی، سوالات مهمی را درباره‌ی ارزش منابع و تکنیک‌های ارتباطی به‌دنبال دارد؛ پرسش‌هایی که لازم است پیش از پیشرفت‌های تکنولوژی به آن‌ها پاسخ داده شود.پاورقی[1] در کتاب The New Industrial State اثر John Kenneth Galbraith می‌توان تحلیلی جامع‌تر دربارهٔ رفتار سازمان‌های طراح سیستم یافت. فصل ششم این کتاب با عنوان «The Technostructure» به‌طور خاص قابل توجه است.[2] نوعی اسباب‌بازی که از میله‌ها و قطعات متصل‌کننده تشکیل شده و قابلیت ساخت سازه‌های مختلف را دارد.[3] واژگانی مثل Branch (شاخه) ، Node (گره) و Interface (رابط) جزء عبارات تخصصی در نظر گرفته شده و ترجمه نشده‌اند.[4] این ادعا را می‌توان به شیوه‌های گوناگونی تفسیر کرد. از یک سو، ممکن است موضوعی ساده و کم‌اهمیت تلقی شود که به تعریف «مذاکره معنادار» بستگی دارد. از سوی دیگر، ممکن است بازتاب این واقعیت باشد که گروه‌های طراحی، جز در شرایط کاملاً ضروری، به‌ندرت حاضر می‌شوند از طرح خود صرف‌نظر کنند تا نیازهای گروهی دیگر را برآورده سازند.[5] گروه واژه‌گزینی. جواد میرشکاری، ویراستار. دفتر سوم. فرهنگ واژه‌های مصوب فرهنگستان. تهران: انتشارات فرهنگستان زبان و ادب فارسی. شابک ۹۶۴-۷۵۳۱-۵۰-۸ (ذیل سرواژهٔ هم‌ریختی)[6] C. Northcote Parkinson, Parkinson's Law and Other Studies in Administration (Boston, Houghton Mifflin, 1957)[7] با توجه به این جمله، تعداد کل مسیرهای ارتباطی میان N نفر، با فرمول "N به توان ۲، تقسیم بر ۲" محاسبه می‌شود. به‌عنوان مثال، در یک تیم 6 نفره، تعداد مسیرهای ارتباطی بین افراد برابر با 18 است. اما باید به این نکته توجه داشت که این فرمول دقیق نیست و نویسنده تنها برای بیان ساده مسئله از آن استفاده کرده است. این فرمول مقدار مسیرهای ارتباطی را بیش از حد برآورد می‌کند، زیرا هم ارتباط هر فرد با خودش را در نظر می‌گیرد و هم هر مسیر ارتباطی را دو بار می‌شمارد (برای مثال یک بار ارتباط علی با رضا و یک بار ارتباط رضا با علی). فرمول "N ضربدر N منهای ۱، تقسیم بر ۲" فرمول دقیق‌تری است که این موارد را نیز لحاظ می‌کند. به همین دلیل، در یک تیم ۶ نفره، تعداد مسیرهای ارتباطی ۱۵ است، نه ۱۸. لازم به ذکر است که با افزایش تعداد افراد، اختلاف بین دو فرمول بیشتر می‌شود.هادی احمدیهادی احمدیMon, 26 May 2025 22:24:21 +0330