سخنران: Andrew Harmel-Law
رویداد: Global Software Architecture Summit (GSAS) 2024
لینک ویدئو: https://www.youtube.com/watch?v=aMKUr5b8Fnw
اندرو هارمللا در این سخنرانی در اجلاس جهانی معماری نرمافزار در بارسلونا، سراغ موضوعی میرود که یکی از مهمترین بخشهای معماری است: نه «چه تصمیمی بگیریم»، بلکه «چطور و توسط چه کسی تصمیم گرفته شود».
هارمللا از تعریف شروع میکند: به قول گریدی بوچ، معماری همان «تصمیمهای مهم طراحی» است و اهمیت را «هزینه تغییر» میسنجد. پس هر جا تصمیمی گرانبرگشت گرفته میشود، دارد معماری اتفاق میافتد؛ چه معماری رسمی در اتاق باشد چه نباشد. او سپس دو الگوی سنتی تصمیمگیری را کالبدشکافی میکند. الگوی اول «برج عاج» است: معمار یا کمیته معماری تصمیم میگیرد و تیمها اجرا میکنند. این الگو گلوگاه میسازد، تصمیمها را از واقعیت کد دور میکند و توسعهدهندگان را به مجریان بیانگیزه تبدیل میکند. الگوی دوم واگذاری کامل به تیمهای خودمختار است که در عمل به ناسازگاری، دوبارهکاری و ازدسترفتن تصویر کلان میانجامد. نکته ظریف سخنرانی این است که هر دو الگو در یک چیز مشترکاند: جریان یادگیری و اطلاعات را قطع میکنند.
پیشنهاد او «فرایند مشورت» است با یک قاعده ساده اما رادیکال: هر کسی میتواند تصمیم معماری بگیرد، به شرط آنکه پیش از تصمیم، با دو گروه مشورت کند — کسانی که از تصمیم اثر میپذیرند و کسانی که در آن موضوع تخصص دارند. مشورت الزامی است اما تبعیت از آن نه؛ تصمیمگیرنده پس از شنیدن، خودش تصمیم میگیرد و مسئولیتش را میپذیرد. این فرایند با چند سازوکار پشتیبان کامل میشود: ثبت تصمیمها در قالب ADR (سوابق تصمیم معماری)، جلسه هفتگی «انجمن مشورتی معماری» برای گفتوگوی شفاف، و اصول فنی تیممحور که چارچوب تصمیمها را میسازند. هارمللا تأکید میکند که هدف، تصمیمِ «بینقص» نیست؛ هدف تصمیمگیری سریع، برگشتپذیر و یادگیرنده است، چون در سیستمهای اجتماعیفنی، بازخورد سریع از کمالگرایی ارزشمندتر است.
چیزی که این سخنرانی را از یک بحث فرایندی خشک نجات میدهد، درک عمیق هارمللا از روانشناسی سازمان است. او صادقانه میگوید سختترین بخش این تحول، فنی نیست؛ ترس توسعهدهنده از پذیرش مسئولیت و ترس معمار از واگذاری قدرت است. به نظرم این دقیقترین توصیف از وضعیت بسیاری از سازمانهای ماست، جایی که «تأیید معماری» به آیینی زمانبر تبدیل شده که نه کیفیت میآورد و نه چابکی. نکته دیگری که برایم جالب بود، پیوند این ایده با مفهوم جریان (Flow) است: در دنیایی که تحویل مداوم و تیمهای محصولمحور استاندارد شدهاند، تصمیمگیری متمرکز آخرین گلوگاه باقیمانده است. هارمللا در واقع میگوید معماری هم باید مثل استقرار، «توزیعشده» شود؛ و معمار بهجای دروازهبان، باید تسهیلگر و باغبان زمینه تصمیمگیری باشد.
پیادهسازی این ایدهها لازم نیست انقلابی باشد. قدم اول که همین امروز قابل اجراست، جدیگرفتن ADRهاست: هر تصمیم مهم، در یک سند کوتاه با زمینه، گزینهها و نتیجه ثبت شود و در مخزن کد کنار خود کد زندگی کند. قدم دوم، راهاندازی یک جلسه مشورتی دوهفتگی است که در آن تصمیمهای در جریان مطرح میشوند؛ نه برای تأییدگرفتن، بلکه برای شنیدن دیدگاهها. برای تیمهایی که اغلب ساختارهای سلسلهمراتبی دارند، شاید شروع تدریجی بهتر جواب بدهد: ابتدا دامنه مشخصی از تصمیمها (مثلاً انتخاب کتابخانهها و طراحی APIهای داخلی) به تیمها واگذار شود و با بلوغ فرهنگ مشورت، دامنه گسترش یابد. تجربهٔ سازمانهایی که این مسیر را رفتهاند نشان میدهد کیفیت تصمیمها نهتنها افت نمیکند، بلکه بهخاطر نزدیکی تصمیمگیرنده به مسئله، بهتر هم میشود.
این سخنرانی یادآوری میکند که معماری نرمافزار پیش از آنکه مجموعهای از دیاگرامها باشد، مجموعهای از تصمیمهاست؛ و کیفیت یک سیستم در بلندمدت، تابع کیفیتِ «فرایند» تصمیمگیری آن است. درس کلیدی: تصمیمگیری را به نزدیکترین نقطه به مسئله ببرید، مشورت را اجباری و اطاعت را اختیاری کنید، و همهچیز را شفاف ثبت کنید. برای هر معمار یا مدیر فنی که حس میکند خودش گلوگاه سازمانش شده، این ویدیو میتواند نقطهٔ شروع یک تغییر جدی باشد.
اين مطلب، بخشی از تمرينهای درس معماری نرمافزار در دانشگاه شهيد بهشتی است.
