آیا هوش مصنوعی تیم را سریعتر میکند؟
سازمانی برای کل تیم فنیاش ابزار دستیار کدنویسی میخرد. شش ماه بعد مدیر میپرسد: چقدر سریعتر شدیم؟
و معمولاً هیچکس جواب ندارد. چون کسی عدد «قبل» را ثبت نکرده، و چون بیشتر سنجههای در دسترس، چیز اشتباهی را میسنجند.
احساس سرعت با سرعت واقعی یکی نیست
نکتهای که مطالعات این حوزه مکرر نشان دادهاند: برنامهنویسانی که این ابزارها را استفاده میکنند، احساس میکنند سریعتر شدهاند — حتی وقتی نشدهاند.
دلیلش قابل فهم است. کار خستهکننده کمتر شده، مرحلهٔ «صفحهٔ خالی» حذف شده، و کد سریعتر روی صفحه ظاهر میشود. اینها همه لذتبخشاند و با تحویل زودتر یکی نیستند.
پس نظرسنجی رضایت، معیار خوبی برای این تصمیم نیست. رضایت مهم است — برای ماندگاری تیم — ولی سؤال شما این نبود.
چرا سرعت کدنویسی کل ماجرا نیست
در پروژهٔ نرمافزاری واقعی، نوشتن کد شاید سی تا چهل درصد زمان باشد. بقیه:
- فهمیدن نیازمندی و رفتوبرگشت با کسبوکار
- طراحی و تصمیمگیری
- بازبینی
- تست و رفع باگ
- جلسه و هماهنگی
- استقرار و پشتیبانی
اگر سرعت کدنویسی دو برابر شود، کل پروژه حدود بیست درصد سریعتر میشود — نه دو برابر. و آن بیست درصد هم فقط وقتی محقق میشود که چیزی دیگری کند نشده باشد.
آن شرط آخر مهم است: اگر حجم کد بالا برود و ظرفیت بازبینی ثابت بماند، گلوگاه از کدنویسی به بازبینی منتقل میشود و کل زمان تحویل ممکن است حتی بیشتر شود.
سنجههایی که گمراه میکنند
خطوط کد. بدترین سنجهٔ ممکن، و با این ابزارها بدتر — چون تولید کد بیشتر ارزان شده. کد بیشتر یعنی نگهداری بیشتر، نه ارزش بیشتر.
تعداد کامیت.
درصد کدی که ابزار تولید کرده. عددی که فروشندهٔ ابزار دوست دارد و هیچ ارتباطی با نتیجه ندارد.
احساس تیم، به دلیلی که بالا گفتیم.
سرعت تیم بر اساس امتیاز کار، چون واحدش تعریفشده نیست و بهمرور تورم میگیرد.
سنجههایی که واقعاً چیزی میگویند
چهار عدد. اینها به نتیجه وصلاند نه به فعالیت:
۱. زمان از شروع کار تا رسیدنش به دست کاربر. کل چرخه، نه فقط کدنویسی. تنها عددی که مستقیماً به کسبوکار وصل است.
۲. تعداد کارهای تمامشده در هر دوره — با تعریف اتمام ثابت. اگر تعریف اتمام روشن نباشد، این عدد بیمعناست، به دلیلی که در تعریف اتمام کار گفتیم.
۳. نرخ باگ برگشتی. چند درصد کارها بعد از تحویل دوباره باز میشوند؟ اگر سرعت بالا رفته و این هم بالا رفته، سود واقعی صفر است — فقط کار را جابهجا کردهاید.
۴. زمان بازبینی. اگر کد بیشتری تولید میشود، بازبینی گلوگاه میشود. پایش این عدد، زودترین هشدار است.
و یک سنجهٔ کیفی که ارزش دارد: زمان راهافتادن عضو جدید. اگر این عدد بهتر شده، ابزار واقعاً در انتقال دانش کمک کرده.
چطور واقعاً اندازه بگیریم
مسئله این است که در سازمان واقعی، گروه کنترل ندارید — همه ابزار را دارند.
روشی که عملی است:
۱. سه ماه پیش از شروع، چهار سنجهٔ بالا را ثبت کنید. بدون این، هر عددی بعداً بیمبنا است. این تنها کاری است که اگر انجام ندهید، دیگر قابل جبران نیست.
۲. تدریجی راه بیندازید. یک تیم اول، بقیه بعد. مقایسهٔ بین تیمها ناقص است و از هیچ بهتر.
۳. سه ماه صبر کنید پیش از قضاوت. ماه اول همیشه کندتر است — یادگیری هزینه دارد.
۴. به تفکیک نوع کار نگاه کنید. انتظار نداشته باشید همهجا یکسان باشد. معمولاً کار قالبی و تکراری بیشترین بهبود را نشان میدهد و کار طراحی هیچ — که دقیقاً همان تفکیکی است که در دستیار کدنویسی گفتیم.
هزینهای که در محاسبه باید بیاید
طرف دیگر معادله، که معمولاً فراموش میشود:
- هزینهٔ اشتراک، ضربدر تعداد نفرات، ماهانه.
- زمان یادگیری در ماههای اول.
- زمان بازبینی اضافه، اگر حجم کد بالا رفته.
- بدهی فنی، اگر کدی وارد شده که کسی کامل نفهمیده.
- زمان صرفشده روی خروجیهای غلط.
آن قلم آخر واقعی است و کمتر دیده میشود: کدی که تولید میشود، منطقی به نظر میرسد، و یک ساعت بعد معلوم میشود راه اشتباهی بوده.
چارچوب کامل محاسبه در بازگشت سرمایهٔ نرمافزار — و همان قاعده اینجا هم برقرار است: صرفهجویی زمانی که به کار بیشتر یا نیروی کمتر تبدیل نشود، پول صرفهجوییشده نیست.
جواب صادقانه
از آنچه تا امروز دیدهایم:
بهبود واقعی وجود دارد و از ادعای فروشندگان کمتر است. چیزی در حد ده تا بیست درصد در زمان تحویل، برای تیمهایی که درست به کارش گرفتهاند.
توزیعش یکنواخت نیست. کار قالبی بهشدت سریعتر، کار طراحی تقریباً بدون تغییر.
و برای بعضی تیمها منفی بوده — آنهایی که ظرفیت بازبینی را بالا نبردند و کدی وارد کردند که بعداً هزینهاش را دادند.
عاملی که تفاوت را میسازد، ابزار نیست. انضباط بازبینی است.
پس اگر تصمیم دارید این سرمایهگذاری را بکنید، هزینهٔ افزایش ظرفیت بازبینی را هم در همان بودجه ببینید. و اگر یک کار را انتخاب میکنید: همین امروز عدد «قبل» را ثبت کنید، حتی اگر هنوز تصمیم نگرفتهاید.