هوش مصنوعی تیم شما را دو برابر سریع‌تر نخواهد کرد.
مهندسان نرم‌افزار همیشه به دنبال راهی برای ساده‌تر کردن سیستم‌ها یا افزایش سرعت تحویل بوده‌اند.
وسوسه‌ی دستیابی به راه‌حل‌های جادویی (Silver Bullets) ریشه در تمایل انسان به شکستن مسائل پیچیده به اجزای کوچک‌تر دارد. جدیدترین «گلوله‌ی نقره‌ای» هم‌ژن هوش مصنوعی مولد (Generative AI) است؛ فناوری‌ای که در صورت بهره‌برداری مؤثر، نویدبخش افزایش چشم‌گیر بهره‌وری است. با این حال، اغلب مدیران مهندسی تاکنون تنها بهبودهای اندکی در سطح بهره‌وری مشاهده کرده‌اند؛ رقمی در حدود ۰ تا ۱۰ درصد. طبق تازه‌ترین گزارش رهبری مهندسی LeadDev. در عمل، بیشتر توسعه‌دهندگان با موانع سیستمی، فرآیند‌های کند و انزوای دانش در بخش‌های مختلف مواجه‌اند.
به جای آنکه سازمان‌های مهندسی را صرفاً مانند کدبیس‌هایی برای دست‌کاری و اصلاح تصور کنیم، باید آن‌ها را به عنوان نظام‌های به‌هم‌پیوسته در نظر بگیریم. با ترسیم روابط میان تیم‌ها، فرآیند‌ها و جریان‌های اطلاعاتی، رهبران می‌توانند محدودیت‌هایی را شناسایی کنند که مانع از تحقق وعده‌های هوش مصنوعی در زمینه‌ی چند برابر کردن بهره‌وری می‌شوند.
مهندسی فقط درباره‌ی فناوری نیست، بلکه ترکیبی از انسان‌ها و فناوری است.
درک سیستم‌ها چیزی بیش از یک نگاه کلی و کلان به مسأله موجود است و «تفکر سیستمی» صرفاً به معنای «کلان‌تر اندیشیدن» نیست.
به گفته‌ی «دونلا می‌دوز» (Donella Meadows)، نویسنده‌ی تفکر سیستمی:
«یک سیستم صرفاً مجموعه‌ای تصادفی از اشیاء نیست، بلکه مجموعه‌ای به‌هم‌پیوسته از عناصر است که به‌طور منسجم سازمان یافته‌اند تا به نتیجه‌ای مشخص دست یابند.» در بنیادی‌ترین سطح، یک سیستم/نظام، باید از سه جزء تشکیل شود: عناصر، ارتباط میان آن‌ها و یک هدف یا کارکرد.
به عنوان مثال؛ ماسه‌های ساحل یک سیستم نیستند، چون هرچند عناصر زیادی وجود دارد، اما آن‌ها به هم پیوند ندارند و کارکرد یا هدفی را دنبال نمی‌کنند. اما اندام‌های گوارشی شما یک سیستم هستند؛ زیرا هر تغییری در عناصر یا نحوه‌ی ارتباط‌شان، به تغییر کارکرد کلی نظام می‌انجامد.
بیشتر رهبران مهندسی معمولاً کل سیستم را نادیده می‌گیرند و فقط روی یک بخش تمرکز می‌کنند. تفکیک اجزا مفید است، چون زمانی که عناصر را تجزیه کنیم، درک نحوه‌ی کنار هم قرار گرفتن آن‌ها و شیوه‌های مختلف سازمان‌دهی‌شان آسان‌تر می‌شود. اما این فقط شبیه به تفکر سیستمی است، نه خود آن. مهندسی هم جنبه فنی دارد و هم اجتماعی، و یک سیستم فنی-اجتماعی را نمی‌توان به کد تقلیل داد.
اگر دقیق‌تر نگاه کنیم، انواع مختلفی از ارتباط‌ها را می‌بینیم:
- ارتباطاتی که درون تیم مهندسی وجود دارند مانند ارتباط میان افراد، فرآیند‌ها، ابزار و شاخص‌ها
- و ارتباطاتی فراتر از تیم مهندسی مانند ارتباط با تیم‌های محصول، مالی، پشتیبانی مشتری، فروش، و حتی ارتباط با کاربران.
اینجاست که ایرادات در رویکرد راه حل جادویی بودن هوش مصنوعی آشکار می‌شوند. وقتی یک سیستم برای عملکرد درست به عناصر، ارتباطات و اهداف نیاز دارد، افزودن یک عنصر جدید (حتی اگر هوش مصنوعی باشد) به تنهایی برای جهش بهره‌وری بصورت بنیادین، کافی نیست. اگر تیم‌ها خواهان تحول بنیادین باشند، باید هم عناصر و هم ارتباطات را تغییر دهند.
چگونه سیستمی بسازیم که هوش مصنوعی در آن کارآمد باشد
پتانسیل هوش مصنوعی مولد برای سرعت‌بخشیدن به تحویل نرم‌افزار بسیار زیاد است. اما پذیرش شتاب‌زده‌ی آن، مانند دستورالعمل‌های اجباری بدون داشتن استراتژی روشن، این پتانسیل را تهدید می‌کند. در تغییرات بزرگ، همیشه لاک‌پشت است که از خرگوش پیشی می‌گیرد.
رویکرد مبتنی بر نتایج
سرعت تنها یکی از عناصر یک سازمان مهندسی کارآمد است. ساخت سریع محصولی پر از باگ یا محصولی که نیاز کاربران را برآورده نکند، موفقیت محسوب نمی‌شود.
ابتدا، باید از گرفتار شدن در بحث‌های صرفاً فنی پرهیز کرد. Copilot بهتر است یا Cursor؟ Claude بهتر است یا نسخه‌ی جدید ChatGPT؟ این مقایسه‌ها باعث می‌شوند نگاه کلی فدای جزئیات شوند.
به جای تمرکز افراطی بر ابزارهای خاص، بهتر است بر نتایج مطلوب در طول جریان ارزش متمرکز شویم و از همان نقطه، فرآیند را به‌صورت معکوس بازطراحی و تکرار کنیم.
«نیکو کنر»، کارشناس رهبری تغییر، می‌گوید: «یک استراتژی برای تغییر سیستم باید مشخص کند چگونه توجه درست را هم به مسیر بلندمدت معطوف کنیم و هم به کارهایی که امروز، با شرایط و منابع موجود می‌توان انجام داد.»
در این مسیر، باید دقت کنید که چطور مواردی که واقعاً ارزشمند هستند را اندازه گیری کنید. به عنوان مثال، شمار درخواست‌های pull (PR) شاید با استفاده از هوش مصنوعی اهمیت کمتری داشته باشد، چون ظرفیت دیگر گلوگاه اصلی نیست. اما سازمان‌های بزرگ که به سرعت بالا عادت ندارند، ممکن است هنگام تلاش برای حرکت سریع‌تر، با مشکلات کیفیت و امنیت روبه‌رو شوند. در این نقطه این معیارها اهمیت بیشتری پیدا می‌کنند.
دریافت و پاسخ
فشار مدیران بالادستی باعث شده بسیاری از مدیران فنی و رهبران شرکت‌ها استفاده‌ی گسترده از ابزارهای هوش مصنوعی را به سرعت الزامی کنند.
«انیل دش»، مدیرعامل پیشین شرکت Glitch، می‌گوید:
«آیا رئیس‌تان تا به حال برایتان یادداشتی فرستاده که حتماً باید از تلفن هوشمند استفاده کنید؟ یا در ارزیابی عملکردتان شرط کرده باشند که حتماً از Slack استفاده کنید؟ وقتی مردم شروع به استفاده از ایمیل، وب و صفحه‌گسترده‌ها کردند، مجبور به اثبات میزان استفاده خود از تکنولوژی‌های جدید نبودند». اما بسیاری از رهبران مهندسی به جای اعتماد به توسعه‌دهندگان، تغییرات را از بالا تحمیل می‌کنند.
بهتر است تغییرات را به‌صورت تدریجی و آزمایشی وارد کنید و واکنش سیستم را ببینید. ابتدا تیم‌هایی را شناسایی کنید که بیشترین سود را از هوش مصنوعی می‌برند و ابتدا آن را با آن‌ها آزمایش کنید، سپس گسترش دهید. یادگیری تدریجی بسیار مؤثرتر و پایدارتر از تحمیل تغییر، به تحول سازمانی منجر خواهد شد.
لایه‌بندی سیستم‌های سریع و کند
شتاب در پذیرش هوش مصنوعی می‌تواند «شوک سیستمی» ایجاد کند. یعنی بعضی بخش‌ها سود ببرند اما بخش‌های دیگر آسیب ببینند. به گفته‌ی «استوارت برند»، می‌توان سیستم‌ها را به لایه‌های مختلف تقسیم کرد که هر کدام «نرخ تغییر و مقیاس اندازه و زمان» متفاوتی دارند.
مثلاً تیم محصول ممکن است بر افزایش سرعت انتشار تمرکز کند، در حالی که تیم امنیت، برای اطمینان از ایمنی سیستم، روند کار را کندتر پیش می‌برد. این تنش، یکی از ویژگی‌های یک سیستم سالم است، نه نقص آن.
اگر همه‌ی تیم‌ها مجبور شوند هوش مصنوعی را با یک زمان‌بندی و عمق یکسان بپذیرند، این توازن برهم می‌خورد. پژوهش شرکت Uplevel در سال گذشته نشان داد که پس از پیاده‌سازی GitHub Copilot، تعداد باگ‌ها در درخواست‌های Pull (PR) تا ۴۱٪ افزایش یافت. در یک سیستم پیچیده، نمی‌توان سرعت تغییر را ناگهان بالا برد، بی‌آنکه هزینه‌ها و عواقب آن را پذیرفت.
کار موازی
سیستم‌ها پایدار هستند، اما این به معنای سکون آن‌ها نیست. همان‌طور که «الکس دانکو»، مدیر محصول Shopify، می‌گوید:
«اگر بخواهید متغیری را تغییر دهید، هر قدر هم تلاش کنید، به محض رها کردن آن، سیستم به وضعیت اولیه باز می‌گردد.»
تغییر سیستم نیازمند تلاش مداوم و هم‌زمان برای تغییر همه‌ی اجزای اصلی است. این یعنی باید افراد مختلفی را که برای تغییر نیاز دارید، گرد هم آورید و همه به طور هم‌زمان روی سیستم فشار بیاورند، آن هم برای مدت طولانی.
برای چنین تلاشی، سازمان‌ها به افراد زیادی نیاز دارند که مدت‌ها با هم همکاری کنند و بدانند برای چه چیزی تلاش می‌کنند.
روش Uplevel بر بررسی این موضوع تأکید دارد که چگونه شیوه‌های کاری یک سازمان می‌توانند در ساختار آن ریشه‌دار شوند — و همین درک عمیق است که اجازه می‌دهد مسائل اجتماعی–فنی، راه‌حل‌های اجتماعی-فنی خود را آشکار کنند. شاخص‌های سطح پایین یا دستورات سطح بالا کافی نیستند؛ تغییر واقعی از رهبران آغاز می‌شود، اما نیازمند مشارکت و هم‌نویسی توسعه‌دهندگان نیز هست تا همه در نتیجه سهیم و به آن متعهد باشند.
رهبران فنی به عنوان ناظر، نه فرمانده
در سال ۱۹۹۲، توسعه دهنده‌ای به نام «جک دبلیو. ریوز»، نوشت:
«طراحی نرم‌افزار تمرینی است در مدیریت پیچیدگی‌ها. این پیچیدگی در خود طراحی نرم‌افزار وجود دارد، در ساختار سازمانی شرکت نمود پیدا می‌کند، و در کل صنعت نیز وجود دارد.»
مدیریت پیچیدگی به تفکر سیستمی نیاز دارد و نقش رهبر فنی این است که در این پیچیدگی مسیر درست را پیدا کند، نه اینکه با اعلام «اولویت با هوش مصنوعی است» مسیر تحول را کوتاه کند.
رهبری مهندسی به همان اندازه که درباره‌ی مهندسی کد است، درباره‌ی مهندسی سازمان‌های موفق نیز هست. رهبرانی که بیشترین بهره را از ظرفیت هوش مصنوعی خواهند برد، کسانی هستند که نقش آن را در سیستم‌های زیرساختی تیم‌هایشان درک کنند و شکل دهند.
