گلوگاه جدید توسعهٔ نرمافزار
هوش مصنوعیخلاصهٔ کاملتر
تو این مقالهٔ استکاورفلو اومده که خیلی از تیمهای مهندسی درست همهکار رو میکنن — ابزار هوش مصنوعیِ مناسب رو انتخاب میکنن، همه رو راه میندازن و بهرهوری فردی هم بالا میره — ولی بعد یه مدت میبینن سرعت واقعی تیم عوض نشده. سرعت اسپرینت همونه، کارها همونجای قبلی گیر میکنن و اون ظرفیت اضافهای که قرار بود آزاد شه، یه جایی داره بلعیده میشه.
نویسنده این رو با «نظریهٔ محدودیتها» توضیح میده: هر سیستم یه گلوگاه داره و تا یکی رو باز میکنی، گلوگاه بعدی سبز میشه. سالها خودِ نوشتن کد گلوگاه اصلی بود و ابزارهایی مثل اسپرینت و استوریپوینت برای مدیریت همین محدودیت ساخته شدن. حالا به قول یکی از مدیران مهندسی Intuit، هزینهٔ هر خط کد تقریباً ارزونترین چیز تو توسعهٔ نرمافزار شده.
به گفتهٔ نویسنده گلوگاه جدید سر و صدا نمیکنه، فقط هر اسپرینت سرِ همون جاها پیدا میشه. اول تعریف نیازمندیها: وقتی کد ارزونه، هزینهٔ یه اسپکِ مبهم بالا میره، چون ایجنت دقیقاً همون چیزی رو میسازه که گفتی. بعد تحویل طراحی: وقتی تغییر UI تقریباً مجانیه، منتظرموندن برای طرحِ کامل فقط تأخیر اضافه میکنه. و بازبینی کد که با دوبرابرشدن خروجی، خودش تبدیل به گلوگاه میشه.
یه گلوگاه مهم دیگه بیرون خود تیمه: وقتی مهندسی سریعتر از محصول، طراحی، حقوقی و امنیت حرکت میکنه، کارِ آمادهٔ تحویل رو قفسه میمونه تا فرایندهای تأییدی که هیچوقت برای این سرعت طراحی نشده بودن برسن. مشکل اینه که تغییرِ فرایند بینواحدیه؛ میتونی به مهندسها بگی ابزار جدید بردارن، ولی نمیتونی به تیم محصول دستور بدی روشِ کشف نیازمندیش رو عوض کنه.
راهی که نویسنده پیشنهاد میده منفجرکردنِ کل ساختار نیست، بلکه بازبینیِ نقطهبهنقطهست. برای هر مرحله باید پرسید: این برای رفعِ کدوم محدودیت ساخته شده و اون محدودیت هنوز هست؟ تعریف «آمادهٔ ساخت» باید سبکتر شه، فاصلهٔ ایده تا آزمایش کوتاه شه، و اصطکاکِ بینواحدی هم مثل یه مسئلهٔ مهندسیِ جدی دیده شه، نه چیزی که بعداً بهش میرسیم.
نکات کلیدی:
- هوش مصنوعی گلوگاهِ نوشتن کد رو باز کرده، ولی گلوگاه از بین نرفته؛ فقط جابهجا شده.
- بهرهوری فردیِ بالاتر لزوماً یعنی سرعت بیشترِ تیم نیست.
- گلوگاه جدید معمولاً تو نیازمندیها، تحویل طراحی، بازبینی و هماهنگی بینواحدیه.
- بهجای عوضکردن ابزار، باید خودِ فرایند رو مرحلهبهمرحله بازطراحی کرد.
