فصل هفتم: سنجش بهره‌وری مهندسی

تا حالا فکر کردید وقتی یک شرکت بزرگ فناوری مثل گوگل توسعه پیدا می‌کند، چطور می‌فهمد که برنامه‌نویس‌هایش واقعاً دارند سریع‌تر و بهتر کار می‌کنند؟ آیا اضافه کردن افراد بیشتر به تیم‌ها همیشه به معنی پیشرفت سریع‌تر است یا هزینه‌های پنهان دیگری دارد؟

این مباحث در فصل هفتم از کتاب «مهندسی نرم‌افزار در گوگل» نوشتهٔ تیتوس وینترز، تام مانشریک و هایروم رایت بررسی شده است و به ما نشان می‌دهد چطور می‌توان بهره‌وری نیروی انسانی را با داده‌های دقیق ارزیابی کرد.

اولین ایده این است که وقتی سازمان‌ها بزرگ می‌شوند، هزینه‌های ارتباطی به صورت غیرخطی رشد می‌کنند و اضافه کردن نیروی انسانی جدید، لزوماً به همان نسبت کارایی را بالا نمی‌برد. برای حل این مشکل، سازمان باید روی افزایش بهره‌وری تک‌تک مهندسان تمرکز کند تا بتواند بدون بزرگ کردن بیش از حد سازمان، مقیاس‌پذیری (Scalability) را حفظ کند؛ یعنی توانایی سیستم و سازمان در رشد کردن بدون افت کیفیت عملکردی.

ایدهٔ دوم این است که پیش از شروع هر سنجشی، باید با یک فرآیند غربالگری مطمئن شویم که اندازه ‌گیری واقعاً ارزش هزینه کردن وقت و انرژی را دارد. اگر نتایج مثبت یا منفی قرار نباشد تغییری در تصمیم‌گیری‌های مدیریتی ایجاد کند، جمع‌آوری داده‌ها تنها اتلاف وقت است و هیچ کمکی به بهبود مهندسی نرم‌افزار (Software Engineering) نمی‌کند، که به معنای مهندسی ساختن و نگهداری نرم‌افزار در طول زمان است.

ایدهٔ سوم استفاده از چارچوب هدف، سیگنال و متریک جی‌اس‌ام است که جلوی گمراه شدن تیم‌ها را می‌گیرد. برای نمونه، هدف یک نتیجهٔ مطلوب کلی است، سیگنال نشان می‌دهد که چطور می‌فهمیم به آن هدف رسیده‌ایم و متریک شاخص قابل‌ اندازه‌گیری دقیقی است که به عنوان نمایندهٔ آن سیگنال عمل می‌کند.

ایدهٔ چهارم در نظر گرفتن تمام ابعاد پنج‌گانهٔ بهره‌وری با کمک کلمهٔ کلیدی کَنتس است که شامل کیفیت کد، توجه و تمرکز مهندسان، پیچیدگی ذهنی، سرعت و ریتم کاری، و رضایت شغلی می‌شود. برای نمونه، اگر تیم‌ها فقط روی سرعت کار تمرکز کنند و کیفیت یا رضایت را نبینند، در نهایت با افت شدید کیفیت روبه‌رو خواهند شد.

ایدهٔ پنجم ترکیب داده‌های کمی و کیفی است که کمک می‌کند خطاهای ابزارهای خودکار شناسایی شوند. مثلاً در گوگل مشخص شد که خیلی از زمان‌های ثبت‌شده برای ساخت پروژه مربوط به ابزارهای خودکار بوده و مهندس اصلاً منتظر آن‌ها نبوده است، موضوعی که با استفاده از بازبینی کد (Code Review) بررسی تغییرات کد توسط همکاران پیش از ادغام، به درک دقیق‌تر رفتارهای انسانی کمک می‌کند.

پیشنهاد من به عنوان میزبان این است که وقتی خواستید کارایی تیم فنی خود را بسنجید، هرگز از متریک‌ها برای ارزیابی تک‌تک افراد استفاده نکنید زیرا این کار فقط باعث دستکاری داده‌ها می‌شود، بلکه همیشه تأثیر تجمعی ابزارها و فرآیندها بر کل تیم را بررسی کنید.

امیدوارم این روایت از تجربهٔ گوگل به شما کمک کرده باشد نگاه دقیق‌تری به سنجش بهره‌وری در تیم‌های خود داشته باشید.