بهره‌وری برنامه‌نویس‌ها رو چطور اندازه بگیریم؟
هوش مصنوعیخلاصهٔ کامل‌تر
ماجرا از یه کارتون ویروسی شروع میشه که ایتامار گیلاد تو لینکدین منتشر کرد و «AI-flex» رو دست انداخت؛ همون فرهنگی که آدم‌ها و شرکت‌ها به‌جای نتیجه، با میزان استفاده‌شون از AI پز می‌دن. یکی زیر پست پرسیده بود پس معیار درست برای برنامه‌نویس‌ها چیه، و نویسنده تو این مقاله سعی می‌کنه جواب بده.
اولین جواب‌های غلط سراغ سنجیدن کار و فعالیتن. نویسنده به یه مثال کلاسیک از دههٔ ۱۹۸۰ اشاره می‌کنه که IBM می‌خواست کار مایکروسافت رو با تعداد خط کد (KLOC) بسنجه، در حالی که یه برنامه‌نویس خوب ممکنه با خط کد کمتر پیاده‌سازی بهتری بده. کامیت، پول‌ریکوئست و حالا توکن مصرفی هم دقیقاً همون مشکل رو دارن؛ فقط فعالیت رو نشون می‌دن نه ارزش، و گاهی حتی با ارزش رابطهٔ معکوس دارن.
جواب غلط بعدی سنجیدن خروجیه. تو کارخونه هرچی بیشتر تولید کنی بهتره، پس طبیعیه که بخوایم توسعهٔ نرم‌افزار رو هم با تعداد فیچر یا استوری‌پوینت بسنجیم. ولی به گفتهٔ نویسنده اینجا این منطق می‌لنگه؛ یه پروژهٔ پرخروجی مثل Google+ ممکنه به هیچی نرسه، ولی یه کار کوچیک‌تر مثل WhatsApp یه صنعت رو زیر و رو کنه. اون از قول جف پتون می‌گه هدف ساختن بیشتر نیست، کم‌ساختن و بیشترکردن پیامد و اثره.
نویسنده سه دلیل می‌آره که چرا بهینه‌سازی برای خروجی مضره. اول عدم قطعیت: تست‌ها نشون می‌دن که ۳۳ درصد یا کمتر ایده‌ها موفقن، پس هرچی خروجی رو بالا ببری، دورریز و اتلاف رو هم بالا می‌بری. دوم انگیزه‌های منحرف: مهندس‌ها هوشمندن و وقتی بفهمن با خروجی سنجیده می‌شن، فقط برای همون بهینه می‌کنن و به هدف و استراتژی کاری ندارن.
سومین دلیل اثرهای سیستمیه: تمرکز روی خروجی باعث تورم محصول میشه (هرچی فیچر بیشتر، نگه‌داری سخت‌تر و گرون‌تر) و کارِ در جریانِ زیاد (WIP بالا) رو زیاد می‌کنه که خودش توان تیم، تمرکز، روحیه و پیامد رو پایین می‌آره. به گفتهٔ نویسنده این همون سرازیری‌ایه که آخرش به «بازنویسی بزرگ» ختم میشه.
پس جایگزین چیه؟ نویسنده می‌گه اصلاً این فرض که باید برنامه‌نویس‌ها رو جدا از بقیهٔ سازمان بسنجیم اشتباهه و از ذهنیت سنتی و بی‌اعتماد میاد. تو مدل مدرن، تیم‌های چندتخصصی هدف‌های مبتنی بر «پیامد» دارن (مثلاً کوتاه‌کردن زمان آنبوردینگ) و آزادن که با تحقیق و آزمایش بهش برسن. مهم‌ترین چیزی که باید سنجیده بشه اینه که تیم‌ها و شرکت چقدر به این هدف‌ها می‌رسن.
جمع‌بندی نویسنده اینه که سنجیدن کامیت، پول‌ریکوئست، توکن و حتی استوری‌پوینت اشکالی نداره و تو بعضی جاها مفیده، ولی این‌ها نمایندهٔ بدی برای ارزش‌آفرینی‌ان. به‌جای نگرانی از نرخ تولید برنامه‌نویس‌ها، بهتره نگران این باشیم که تیم و کسب‌وکار چقدر برای کاربر و شرکت ارزش می‌سازن؛ و حذف معیارهای بی‌معنی یه قدم اول خوبه.
نکات کلیدی:
- خط کد، کامیت، پول‌ریکوئست و توکن مصرفی فقط فعالیت رو می‌سنجن، نه ارزش واقعی
- حتی خروجی (تعداد فیچر و استوری‌پوینت) پیش‌بینی‌کنندهٔ ضعیف موفقیته
- بهینه‌سازی برای خروجی سه ضرر داره: اتلاف بیشتر، انگیزه‌های منحرف و اثرهای سیستمی مثل تورم محصول
- تو مدل مدرن، تیم‌های چندتخصصی هدف‌های مبتنی بر پیامد دارن، نه هدف‌های جدا برای هر دپارتمان
- به‌جای سنجیدن تک‌تک برنامه‌نویس‌ها، ارزش تولیدشده برای کاربر و کسب‌وکار رو بسنج
