پرش به مطلب اصلی

معمار یا گلوگاه؟

· ۱۱ دقیقه مطالعه
مهدی مالوردی
مهدی مالوردی
مهندس نرم‌افزار و نویسندهٔ این سایت

یکی از سؤال‌هایی که بارها در نقش لید از من پرسیده شده، چیزی شبیه این بوده است:

برای این بخش از کدام راه برویم؟

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

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

در ظاهر داشتم به تیم کمک می‌کردم؛ در عمل داشتم تیمی می‌ساختم که برای جلو رفتن به حضور من نیاز داشت.

اگر برای هر تصمیم معماری باید منتظر تأیید یک نفر بمانیم، احتمالاً با یک معمار قدرتمند طرف نیستیم؛ با یک گلوگاه طرفیم. گلوگاهی که شاید خودش هم آن را آگاهانه نساخته باشد.

تفاوت معماری متمرکز بر یک تصمیم‌گیرنده با تصمیم‌گیری توزیع‌شده میان تیم‌ها

مشخصات سخنرانی

عنوان: Facilitating Software Architecture: Empowering Teams to Make Architectural Decisions
سخنرانان: اندرو هارمل‌لا (Andrew Harmel-Law) و سونیا ناتانزون (Sonya Natanzon)
مجموعه: GOTO Book Club، دسامبر ۲۰۲۴
ویدئو: تماشای سخنرانی در یوتیوب

وقتی معمار، خودش جلوی معماری را می‌گیرد​

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

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

مشکل از جایی شروع می‌شود که «دیدن تصویر بزرگ» آرام‌آرام به «تصمیم‌گرفتن درباره‌ی همه‌چیز» تبدیل می‌شود.

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

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

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

گلوگاه‌ها همیشه آدم‌های کنترل‌گر نیستند

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

قرار نیست تصمیم‌ها را رها کنیم​

جایگزینی که هارمل‌لا پیشنهاد می‌کند، کنارکشیدن معمار و رهاکردن تیم‌ها نیست. حرفش این نیست که هرکس هر تصمیمی خواست بگیرد و بعد اسمش را استقلال بگذارد. ایده‌ی اصلی، «فرایند مشورت» (Advice Process) است.

در این مدل، هرکسی می‌تواند یک تصمیم معماری بگیرد؛ به شرطی که قبل از تصمیم با دو گروه مشورت کند:

  1. کسانی که درباره‌ی موضوع تجربه و دانش دارند.
  2. کسانی که از نتیجه‌ی تصمیم تأثیر می‌گیرند.

تصمیم‌گیرنده مجبور نیست نظر همه را اجرا کند و قرار هم نیست برای رسیدن به اجماع بی‌پایان صبر کند. اما باید نظرهای مرتبط را بشنود، بده‌بستان‌ها را بفهمد و مسئولیت تصمیمش را بپذیرد.

این تفاوت مهمی با تأییدگرفتن دارد. در مدل تأیید، اختیار هنوز دست یک نفر است و تیم فقط درخواست می‌دهد. در فرایند مشورت، اختیار دست کسی است که به مسئله نزدیک‌تر است؛ اما تصمیم او از گفت‌وگو و دانش جمعی عبور می‌کند.

مشورت یعنی قبل از تصمیم، آدم‌های درست را وارد گفت‌وگو کنیم؛ نه اینکه تصمیم را به رأی‌گیری عمومی بگذاریم.

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

اما بعد از چند بار، جنس سؤال‌ها عوض شد. به‌جای «کدام راه را برویم؟» بیشتر می‌شنیدم: «این گزینه‌ها را بررسی کرده‌ایم، با این دو نفر هم حرف زده‌ایم و با توجه به این بده‌بستان‌ها این مسیر را پیشنهاد می‌کنیم.» هنوز ممکن بود نظر من متفاوت باشد، اما دیگر تنها کسی نبودم که زمینه، گزینه‌ها و ریسک‌ها را می‌دید.

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

کد ریویو؛ جایی که هر روز تمرینش می‌کنیم​

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

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

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

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

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

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

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

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

برای من، این شاید روشن‌ترین معیار نقش معمار باشد: بعد از مدتی، تعداد تصمیم‌هایی که بدون حضور او درست گرفته می‌شوند بیشتر شده یا کمتر؟

پس معمار دقیقاً چه‌کار می‌کند؟​

وقتی قرار نیست معمار همه‌ی تصمیم‌ها را خودش بگیرد، ممکن است به نظر برسد نقشش کم‌رنگ شده است. اتفاقاً برعکس؛ کارش سخت‌تر و مهم‌تر می‌شود.

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

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

معمار به‌عنوان تسهیل‌کننده

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

اعتماد، بخش سخت ماجراست​

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

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

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

جایی که با سخنرانی فاصله می‌گیرم​

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

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

به نظرم نکته‌ی اصلی این نیست که «معمار تصمیم نگیرد». نکته این است که معمار نباید مالک پیش‌فرض همه‌ی تصمیم‌ها باشد. اگر هر تصمیمی، مستقل از اندازه و ریسکش، باید از یک میز عبور کند، آن میز دیر یا زود به گلوگاه تبدیل می‌شود.

یک معیار ساده

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

منابع

این مطلب، بخشی از تمرینهای درس معماری نرم‌افزار در دانشگاه شهیدبهشتی است