از تخمین تا اجرا: روشی داده‌محور برای اندازه‌گیری و بهبود کارایی توسعه نرم‌افزار
چطور می‌توانیم عملکرد زمانی توسعه‌دهندگان نرم‌افزار را با مقایسه زمان تخمینی و واقعی تسک‌ها بررسی کنیم؟
مقدمه: مسئله اندازه‌گیری کارایی توسعه‌دهندگان
در این مقاله می‌خواهم روشی داده‌محور را که ما در آمولای برای بررسی عملکرد توسعه‌دهندگان نرم‌افزار استفاده کردیم و از نتایج آن رضایت داشتیم، تشریح کنم. این روش از دی‌ماه ۱۴۰۰ تا اردیبهشت ۱۴۰۴ با یکی از همکارانمان اجرا شد و به شکل معناداری به شفافیت و بهبود مسیر همکاری ما کمک کرد.
اصلاً مسئله چه بود؟
مسئله این بود که سنجش کارایی برنامه‌نویس‌ها چالش‌برانگیز و تا حدی مبهم است. شما به‌عنوان مدیر محصول یا مدیر پروژه، ابزار ساده و مستقیمی در اختیار ندارید که بتوانید با آن متوجه شوید یک توسعه‌دهنده نسبت به عملکرد قبلی خودش پیشرفت کرده است یا خیر.
در متدولوژی‌های چابک مثل Scrum، مفهومی به نام Story Point وجود دارد که برای تخمین نسبی حجم و پیچیدگی کارها و برنامه‌ریزی اسپرینت استفاده می‌شود. با بررسی تعداد Story Pointهای تکمیل‌شده در هر اسپرینت، می‌توان به شاخصی به نام Velocity رسید و ظرفیت تیم را در دوره‌های بعد بهتر پیش‌بینی کرد.
اما این روش برای مسئله‌ای که ما با آن مواجه بودیم، پاسخ کاملی نداشت.
اول اینکه Story Point اساساً برای برنامه‌ریزی و ارزیابی ظرفیت تیم طراحی شده است، نه اندازه‌گیری عملکرد تک‌تک اعضای تیم. استفاده از آن برای مقایسه مستقیم عملکرد افراد هم می‌تواند گمراه‌کننده باشد.
دوم اینکه پیاده‌سازی صحیح این فرایند به هماهنگی و نظم تیمی نیاز دارد. اگر نقش‌هایی مثل Scrum Master یا مدیر پروژه به‌درستی درگیر نباشند، تخمین‌گذاری، برگزاری جلسات و بررسی نتایج ممکن است به‌مرور کیفیت خودش را از دست بدهد.
بنابراین من در تیم نیازی را حس کردم: اینکه بتوانم عملکرد زمانی یک توسعه‌دهنده را با روشی ساده‌تر، شفاف‌تر و قابل‌اندازه‌گیری‌تر بررسی کنم؛ روشی که علاوه بر نشان دادن وضعیت فعلی، امکان مقایسه عملکرد فرد با گذشته خودش را هم فراهم کند.
ایده اصلی ساده بود: اگر برای هر تسک، پیش از شروع؛ زمان موردنیاز را تخمین بزنیم و بعد بتوانیم زمان واقعی فعالیت روی آن را اندازه‌گیری کنیم، می‌توانیم اختلاف این دو را بررسی کنیم. تکرار این فرایند در بازه‌های زمانی مختلف، به ما کمک می‌کند روندها را بشناسیم، تخمین‌ها را اصلاح کنیم و درباره مشکلات فرایند توسعه تصمیم‌های دقیق‌تری بگیریم.
در ادامه توضیح می‌دهم این روش چطور طراحی و اجرا شد.
۱. ایده اصلی: مقایسه زمان تخمینی و زمان واقعی
هسته اصلی روش ما بر یک مقایسه ساده استوار بود:
- قبل از شروع هر تسک، زمان موردنیاز برای انجام آن تخمین زده می‌شود.
- پس از انجام تسک، زمان فعالیت واقعی ثبت‌شده برای آن استخراج می‌شود.
- اختلاف این دو مقدار محاسبه و در بازه‌های زمانی مشخص بررسی می‌شود.
برای مثال فرض کنید توسعه‌دهنده‌ای تخمین می‌زند پیاده‌سازی یک قابلیت به ۶ ساعت زمان نیاز دارد. پس از اتمام کار، مشخص می‌شود که ۸ ساعت فعالیت روی آن ثبت شده است. در این حالت، ۲ ساعت بیشتر از تخمین زمان صرف شده است.
این اختلاف به‌خودی‌خود به معنی عملکرد ضعیف توسعه‌دهنده نیست. ممکن است نیازمندی‌ها مبهم بوده باشند، در حین کار مسئله پیش‌بینی‌نشده‌ای به وجود آمده باشد یا تخمین اولیه دقیق نبوده باشد. چیزی که اهمیت دارد، شناسایی و بررسی این اختلاف است.
به همین دلیل، هدف ما از این روش پیدا کردن مقصر نبود؛ بلکه می‌خواستیم فاصله بین برنامه‌ریزی و اجرای واقعی کار را بهتر بشناسیم. این روش فقط به عنوان یک سیستم فیدبک به توسعه دهنده و مدیر پروژه عمل میکرد.
۲. تعریف تسک‌های کوچک و تخمین توافقی
اولین قدم، تعریف درست تسک‌ها بود.
تسک‌ها در ابزار مدیریت پروژه ثبت می‌شدند و پیش از شروع هرکدام، مدیر پروژه و توسعه‌دهنده درباره زمان موردنیاز برای انجام آن به توافق می‌رسیدند. نکته مهم این بود که تخمین نهایی باید مورد تأیید خود توسعه‌دهنده هم قرار می‌گرفت.
در واقع، قرار نبود مدیر پروژه برای توسعه‌دهنده زمان تعیین کند. توسعه‌دهنده باید با توجه به شناختی که از مسئله، پیچیدگی فنی و راه‌حل احتمالی داشت، تخمین خودش را ارائه میکرد.
نکته بعدی، خرد کردن تسک‌ها بود.
تا حد امکان تلاش می‌کردیم تسک‌ها کوچک باشند و زمان تخمینی هرکدام از یک روز کاری بیشتر نشود. اگر کاری بزرگ‌تر بود، آن را به چند تسک کوچک‌تر تقسیم می‌کردیم و برای هر قسمت تخمین مستقلی در نظر می‌گرفتیم.
این کار چند مزیت داشت:
- تخمین‌گذاری برای کارهای کوچک‌تر ساده‌تر و دقیق‌تر است.
- بررسی اختلاف زمان تخمینی و واقعی در سطح هر تسک امکان‌پذیر می‌شود.
- تسک‌های بسیار بزرگ، که ممکن است چندین مسئله فنی متفاوت را در خود جای داده باشند، کمتر باعث مخدوش شدن تحلیل می‌شوند.
- پیدا کردن علت انحراف زمانی ساده‌تر می‌شود.
البته کوچک بودن تسک به‌تنهایی تضمین‌کننده تخمین دقیق نیست. هدف این بود که اندازه تسک‌ها تا حد امکان قابل‌مدیریت و قابل‌مقایسه باشد.
۳. ثبت زمان فعالیت و چرخه عمر تسک
برای اندازه‌گیری زمان واقعی، از ترکیب دو ابزار استفاده کردیم:
۱. ابزار مدیریت پروژه برای ثبت وضعیت و چرخه عمر تسک‌ها
۲. نرم‌افزار ManicTime برای ثبت فعالیت کاربر در نرم‌افزارهای مختلف
در ابزار مدیریت پروژه، توسعه‌دهنده وضعیت هر تسک را تغییر می‌داد:
- Open: تسک تعریف شده، اما هنوز شروع نشده است.
- In Progress: اجرای تسک شروع شده است.
- Completed: کار به پایان رسیده است.
با این تغییر وضعیت‌ها، زمان شروع و پایان هر تسک مشخص می‌شد.
از طرف دیگر، ManicTime فعالیت کاربر در نرم‌افزارهای مختلف را ثبت میکرد. برای مثال، فعالیت در محیط‌هایی مثل Unity، Visual Studio یا سایر ابزارهای مرتبط با توسعه نرم‌افزار قابل‌مشاهده بود.
ترکیب این دو منبع داده به ما کمک میکرد زمان فعالیت مرتبط با تسک‌ها را بررسی کنیم.
یک نکته مهم وجود دارد: ManicTime به‌تنهایی نمی‌داند توسعه‌دهنده در حال انجام کدام تسک است. این نرم‌افزار فعالیت در محیط‌های مختلف را ثبت می‌کند، در حالی که ابزار مدیریت پروژه چرخه عمر تسک را مشخص می‌کند. بنابراین برای تحلیل درست، باید اطلاعات این دو منبع را با هم تطبیق داد.
همچنین باید دقت کرد که زمان باز بودن یک تسک در وضعیت In Progress لزوماً معادل زمان کار واقعی روی آن نیست. ممکن است توسعه‌دهنده برای مدتی روی تسک دیگری کار کند یا فعالیتش را متوقف کرده باشد.
به همین دلیل، در این روش از اطلاعات چرخه عمر تسک برای تعیین محدوده زمانی و از داده‌های فعالیت برای محاسبه زمان صرف‌شده استفاده می‌شود.
نکته دیگری هم وجود دارد: زمان ثبت‌شده در نرم‌افزارهای توسعه الزاماً تمام زمان کار فکری و فنی توسعه‌دهنده نیست. ممکن است بخشی از طراحی راه‌حل، مطالعه مستندات، گفت‌وگوهای فنی یا بررسی مسائل در ابزارهای دیگر انجام شود. بنابراین باید این محدودیت را در تفسیر داده‌ها در نظر گرفت.
۴. لحاظ کردن دوباره‌کاری و رفع باگ در زمان تسک
یکی از بخش‌های مهم این روش، نحوه برخورد با تسک‌هایی بود که پس از تکمیل دوباره باز می‌شدند.
فرض کنید توسعه‌دهنده یک تسک را انجام داده و وضعیت آن به Completed تغییر کرده است. اما در بررسی بعدی مشخص می‌شود که بخشی از پیاده‌سازی مشکل دارد، باگ وجود دارد یا نتیجه با نیازمندی اولیه مطابقت ندارد.
در این شرایط، تسک دوباره باز می‌شود و توسعه‌دهنده باید اصلاحات لازم را انجام دهد.
در روش ما، زمان فعالیت مربوط به اصلاح و رفع مشکل نیز به زمان واقعی همان تسک اضافه می‌شد.
به نظرم این موضوع اهمیت زیادی دارد؛ چون اگر فقط زمان اولین پیاده‌سازی را در نظر بگیریم، ممکن است تصویری غیرواقعی از عملکرد توسعه‌دهنده به دست بیاوریم. یک تسک ممکن است در ابتدا خیلی سریع تکمیل شود، اما اگر بعداً چند ساعت برای اصلاح آن زمان صرف شود، این زمان هم بخشی از هزینه واقعی انجام آن کار است.
این سازوکار نوعی بازخورد کیفی هم ایجاد میکرد. توسعه‌دهنده می‌دانست که تحویل سریع یک تسک، اگر با کیفیت مناسب همراه نباشد، لزوماً به معنی صرفه‌جویی در زمان نیست.
البته نباید از این موضوع نتیجه گرفت که روش ما تمام ابعاد کیفیت نرم‌افزار را اندازه‌گیری می‌کند. کیفیت معماری، خوانایی کد، نگهداشت‌پذیری، امنیت یا مشکلاتی که خیلی دیرتر شناسایی می‌شوند، الزاماً در این شاخص منعکس نمی‌شوند.
اما دست‌کم بخشی از هزینه دوباره‌کاری و اصلاح پیاده‌سازی در محاسبات لحاظ می‌شود.
۵. شاخص‌های اندازه‌گیری: از گپ زمانی تا متوسط فعالیت روزانه
بعد از ثبت اطلاعات تخمین و زمان واقعی، نوبت به محاسبه شاخص‌ها می‌رسد.
ما چند شاخص اصلی را در گزارش‌های ماهانه بررسی می‌کردیم.
۵.۱. زمان تخمینی تسک‌ها (Estimated Tasks Time)
مجموع زمان تخمینی تمام تسک‌هایی که در دوره موردنظر تعریف و بررسی شده‌اند.
برای مثال، اگر در یک ماه ۲۰ تسک با مجموع تخمین ۱۰۰ ساعت داشته باشیم، مقدار Estimated Tasks Time برابر با ۱۰۰ ساعت خواهد بود.
۵.۲. زمان واقعی فعالیت روی تسک‌ها (Time On Tasks)
مجموع زمان فعالیت ثبت‌شده مرتبط با تسک‌ها در همان دوره.
اگر برای همان ۲۰ تسک، در مجموع ۱۱۵ ساعت فعالیت ثبت شده باشد، مقدار Time On Tasks برابر با ۱۱۵ ساعت خواهد بود.
۵.۳. اختلاف زمان تخمینی و واقعی (Gap)
شاخص اصلی ما اختلاف بین زمان تخمینی و زمان واقعی بود:
Gap = Estimated Tasks Time − Time On Tasks
تفسیر این شاخص به این صورت است:
- اگر مقدار Gap مثبت باشد، زمان واقعی کمتر از تخمین بوده است.
- اگر مقدار Gap منفی باشد، زمان واقعی بیشتر از تخمین بوده است.
- اگر مقدار Gap صفر باشد، زمان تخمینی و واقعی برابر بوده‌اند.
برای مثال:
| شاخص | مقدار |
|---|---|
| زمان تخمینی | ۱۰۰ ساعت |
| زمان واقعی | ۱۱۵ ساعت |
| Gap | ۱۵- ساعت |
در این مثال، ۱۵ ساعت بیشتر از تخمین زمان صرف شده است.
۵.۴. متوسط فعالیت روزانه
شاخص دیگری که در گزارش‌ها داشتیم، متوسط زمان فعالیت روزانه بود.
برای محاسبه آن، مجموع زمان فعالیت روی تسک‌ها را بر تعداد روزهای کاری ماه تقسیم می‌کردیم:
متوسط فعالیت روزانه = Time On Tasks ÷ تعداد روزهای کاری
این عدد به ما کمک میکرد روند فعالیت ثبت‌شده در ماه‌های مختلف را ببینیم.
البته این شاخص به‌تنهایی معیار بهره‌وری نیست. زیاد بودن ساعات فعالیت لزوماً به معنی خروجی بهتر نیست و کم بودن آن هم لزوماً به معنی عملکرد ضعیف نیست. این عدد بیشتر یک شاخص توصیفی برای بررسی روند فعالیت است.
۵.۵. تفاوت زمان تسک‌ها و زمان کل مشمول پرداخت
در گزارش‌های مالی، یک شاخص دیگر هم داشتیم: Total Time.
این مقدار فقط شامل زمان فعالیت روی تسک‌ها نبود. جلسات، مرخصی و سایر زمان‌هایی که طبق توافق مشمول پرداخت بودند نیز در آن لحاظ می‌شدند.
بنابراین باید بین دو مفهوم تفاوت قائل شویم:
- Time On Tasks: زمان فعالیت مرتبط با تسک‌های توسعه
- Total Time: مجموع زمان‌های مشمول پرداخت
این تفکیک اهمیت دارد؛ چون اگر هدف ما تحلیل کارایی زمانی تسک‌ها باشد، نباید زمان جلسات یا مرخصی را با زمان فعالیت توسعه مخلوط کنیم.
۶. تحلیل ماهانه و بررسی روندها
ما داده‌ها را به‌صورت ماهانه جمع‌آوری و بررسی می‌کردیم.
در پایان هر ماه، مدیر محصول و توسعه‌دهنده در کنار یکدیگر گزارش را بررسی می‌کردند. هدف این جلسه، صرفاً مشاهده اعداد نبود؛ بلکه باید مشخص می‌شد چرا در بعضی ماه‌ها اختلاف بین تخمین و زمان واقعی بیشتر شده است.
برای مثال، اگر در یک ماه زمان واقعی به شکل غیرمعمولی بیشتر از تخمین باشد، باید علت آن را بررسی کنیم.
ممکن است دلایل مختلفی وجود داشته باشد:
- نیازمندی‌ها به‌اندازه کافی شفاف نبوده‌اند.
- در حین توسعه، مسئله فنی پیش‌بینی‌نشده‌ای به وجود آمده است.
- تخمین اولیه بیش از حد خوش‌بینانه بوده است.
- تسک به‌درستی خرد نشده و چند کار متفاوت در قالب یک تسک قرار گرفته‌اند.
- بخشی از زمان صرف رفع باگ و دوباره‌کاری شده است.
- اطلاعات ثبت‌شده در ابزارها کامل نبوده‌اند.
این جلسه باید به یک گفت‌وگوی مشترک تبدیل شود، نه جلسه ارزیابی یک‌طرفه.
به‌نظرم یکی از مهم‌ترین ارزش‌های این روش همین است: به‌جای اینکه مدیر محصول بر اساس برداشت شخصی درباره عملکرد توسعه‌دهنده قضاوت کند، هر دو طرف درباره داده‌های واقعی صحبت می‌کنند و تلاش می‌کنند علت اختلاف‌ها را پیدا کنند.
نمودارهایی که برای تحلیل استفاده می‌کنیم
برای اینکه تحلیل ماهانه فقط به چند عدد محدود نشود، بهتر است داده‌ها را در قالب چند نمودار نمایش دهیم.
نمودار اول: کل total Time برای هر ماه به شکل جداگانه
در این نمودار، کل زمان گذاشته شده برای کار در هر ماه نمایش داده می‌شود. این نمودار کمک می‌کند توسعه دهنده و مدیر پروژه تصویر مشخصی از روند کلی فعالیت داشته باشند.
نمودار دوم: روند متوسط فعالیت روزانه
این نمودار نشان می‌دهد متوسط فعالیت ثبت‌شده روی تسک‌ها در هر روز کاری چقدر بوده است. بهتر است در کنار آن، میانگین متحرک سه‌ماهه هم نمایش داده شود تا نوسانات مقطعی کمتر باعث برداشت اشتباه شوند.
نمودار سوم: روند Gap ماهانه
به نظرم این نمودار مهم‌ترین نمودار این روش است.
با نمایش Gap در ماه‌های مختلف و مشخص کردن خط صفر، می‌توانیم روند اختلاف بین زمان تخمینی و واقعی را دنبال کنیم.
برای مثال، اگر در چند ماه متوالی Gap منفی باشد، می‌توانیم بررسی کنیم آیا تخمین‌ها به‌طور مداوم خوش‌بینانه هستند یا مسئله‌ای در فرایند توسعه وجود دارد.
از طرف دیگر، اگر در یک ماه مقدار Gap به شکل غیرعادی تغییر کند، باید علت آن را پیدا کنیم.
البته ماه‌هایی که اطلاعات ناقص دارند یا حجم تسک‌های ثبت‌شده در آن‌ها بسیار کم است، نباید بدون توضیح با ماه‌های عادی مقایسه شوند.
مثلا در نمودار بالا که یک نمودار واقعی هست، در مرداد و مهر 1403 که ریزش شدیدی داشتیم، بررسی کردیم و فهمیدیم نوع تسک‌ها تغییر کرده نسبت به ماه های پیش و برای ماه‌های بعدش برنامه ریزی کردیم که چطور قابل برآوردترشون کنیم و تا حد زیادی حل کردیم مشکل رو.
۷. استفاده از داده‌ها برای بهبود فرایند توسعه
ارزش اصلی این روش زمانی مشخص می‌شود که از داده‌ها برای بهبود استفاده کنیم.
برای مثال، فرض کنید بعد از چند ماه متوجه شویم که تخمین‌های توسعه‌دهنده به‌طور مداوم کمتر از زمان واقعی هستند.
این موضوع می‌تواند چند معنی داشته باشد:
- توسعه‌دهنده در تخمین پیچیدگی کارها دقت کافی ندارد.
- بخشی از کارهای جانبی در تخمین اولیه دیده نمی‌شوند.
- نیازمندی‌ها در زمان تعریف تسک به‌اندازه کافی شفاف نیستند.
- فرایند توسعه با وقفه‌ها یا دوباره‌کاری‌های زیادی همراه است.
در این شرایط، راه‌حل لزوماً افزایش زمان تخمین‌ها نیست. شاید باید نحوه تعریف تسک‌ها را اصلاح کنیم، نیازمندی‌ها را دقیق‌تر بنویسیم یا بخشی از مشکلات فنی و فرایندی را برطرف کنیم.
همچنین اگر در طول زمان ببینیم اختلاف بین تخمین و زمان واقعی کمتر شده است، می‌توانیم نتیجه بگیریم که دست‌کم دقت تخمین‌ها یا هماهنگی بین برنامه‌ریزی و اجرا بهتر شده است.
البته کاهش Gap به‌تنهایی اثبات‌کننده افزایش بهره‌وری نیست؛ ممکن است تخمین‌ها بیش از حد محافظه‌کارانه شده باشند. به همین دلیل، باید در کنار آن حجم و نوع کار، کیفیت خروجی و شرایط اجرای پروژه را هم در نظر گرفت.
۸. تعدیل نرخ ساعتی؛ تجربه‌ای جانبی در کنار سنجش عملکرد
در کنار تحلیل زمان تخمینی و واقعی، ما در بخشی از این فرایند از داده‌های به‌دست‌آمده برای محاسبه و تعدیل نرخ ساعتی پرداخت هم استفاده کردیم.
ایده این بود که اگر در طول زمان، توسعه‌دهنده بتواند تسک‌ها را با زمان واقعی کمتر از تخمین انجام دهد، این موضوع در محاسبه نرخ پرداختی ساعتی او هم منعکس شده و باعث افزایش پرداختی به وی شود. در مقابل، اگر زمان واقعی به شکل معناداری بیشتر از تخمین باشد، امکان بازنگری در نرخ پیشنهادی وجود داشته باشد.
برای این کار، در فایل محاسباتی خودمان سازوکاری تعریف کرده بودیم که بر اساس Gap و چند پارامتر مشخص، نرخ پیشنهادی را محاسبه میکرد.
اما به نظرم باید بین دو موضوع تفاوت قائل شویم:
۱. اندازه‌گیری و تحلیل کارایی زمانی
۲. استفاده از نتایج این تحلیل برای تصمیم‌های مالی
موضوع اول هسته اصلی روش است؛ موضوع دوم یک کاربرد جانبی و وابسته به توافق‌های همکاری است.
چرا این تفکیک مهم است؟
چون زمان واقعی بیشتر از تخمین، همیشه به معنی عملکرد ضعیف‌تر نیست. ممکن است مسئله‌ای پیش‌بینی‌نشده، تغییر نیازمندی‌ها یا پیچیدگی فنی خارج از کنترل توسعه‌دهنده باعث افزایش زمان شده باشد.
از طرف دیگر، سرعت بیشتر از تخمین هم لزوماً به معنی کیفیت بهتر نیست.
بنابراین اگر قرار باشد از این داده‌ها در تصمیم‌های مالی استفاده شود، باید علاوه بر Gap، کیفیت خروجی، شرایط تسک‌ها و علت انحراف هم بررسی شوند. همچنین بهتر است قواعد تعدیل از ابتدا شفاف، قابل‌پیش‌بینی و مورد توافق طرفین باشند.
در تجربه ما، این بخش بخشی از سازوکار پرداخت بود، اما پیشنهاد نمی‌کنم آن را شرط ضروری اجرای روش سنجش کارایی بدانیم.
۹. محدودیت‌ها و ملاحظات
هیچ شاخصی به‌تنهایی نمی‌تواند عملکرد یک توسعه‌دهنده نرم‌افزار را به‌طور کامل اندازه‌گیری کند. روش پیشنهادی من هم از این قاعده مستثنا نیست.
این روش عمدتاً کارایی زمانی نسبت به تخمین را بررسی می‌کند، نه تمام ابعاد بهره‌وری توسعه‌دهنده.
چند محدودیت مهم آن عبارت‌اند از:
۱. فعالیت ثبت‌شده با تمام زمان کار یکسان نیست.
ممکن است توسعه‌دهنده بخشی از زمان خود را صرف فکر کردن، طراحی راه‌حل، مطالعه یا گفت‌وگو کند. این فعالیت‌ها لزوماً در نرم‌افزارهای توسعه ثبت نمی‌شوند.
۲. کیفیت نرم‌افزار فقط با زمان دوباره‌کاری سنجیده نمی‌شود.
این روش بخشی از هزینه اصلاح باگ‌ها و مشکلات پیاده‌سازی را نشان می‌دهد، اما نمی‌تواند به‌تنهایی کیفیت معماری، خوانایی کد، امنیت یا نگهداشت‌پذیری را ارزیابی کند.
۳. همه تسک‌ها قابل‌مقایسه نیستند.
حتی اگر تسک‌ها کوچک باشند، ممکن است از نظر پیچیدگی، ابهام و ریسک تفاوت زیادی داشته باشند. بنابراین مقایسه ساده ساعات یا Gap بین تسک‌ها می‌تواند گمراه‌کننده باشد.
۴. تخمین‌ها ممکن است تحت تأثیر رفتار افراد قرار بگیرند.
اگر توسعه‌دهنده احساس کند تخمین‌های او مستقیماً مبنای قضاوت یا پرداخت قرار می‌گیرند، ممکن است به‌صورت ناخودآگاه تخمین‌های محافظه‌کارانه‌تری ارائه کند. این موضوع می‌تواند اعتبار شاخص‌ها را کاهش دهد.
۵. داده‌های ناقص می‌توانند نتیجه‌گیری را مخدوش کنند.
اگر وضعیت تسک‌ها به‌درستی ثبت نشود یا فعالیت‌های نرم‌افزاری به‌درستی به تسک‌ها نسبت داده نشوند، نتیجه محاسبات قابل‌اعتماد نخواهد بود.
به همین دلیل، پیشنهاد می‌کنم این روش در کنار سایر ابزارهای ارزیابی عملکرد استفاده شود، نه به‌عنوان تنها معیار تصمیم‌گیری درباره عملکرد توسعه‌دهندگان.
6. اصل این است که توسعه دهنده حس کنترل شدن نکند
اصل اساسی در اجرایی سازی این روش، این است که توسعه‌دهنده توجیه شود که این روش صرفا برای ارزیابی کلی عملکرد است و قرار نیست بر اساس آن قضاوت شود، بلکه قرار است یک نقشه از عملکرد توسعه دهنده و همچنین اشکالاتی که از سمت شرکت به وی تحویل می‌شود نمایش داده شود. در نهایت برخی از توسعه دهندگان با بودن ابزار کنترل زمان روی سیستمشان مشکل دارند، اگر این طور باشد، پافشاری بر این مسئله نتیجه عکس خواهد داد.
۱۰. جمع‌بندی: اندازه‌گیری برای بهبود، نه صرفاً ارزیابی
تجربه ما در آمولای نشان داد که می‌توان با ترکیب چند ابزار نسبتاً ساده، چارچوبی برای بررسی کارایی زمانی توسعه‌دهندگان ایجاد کرد.
در این روش، توسعه‌دهنده و مدیر پروژه پیش از شروع کار درباره زمان موردنیاز برای انجام تسک توافق می‌کنند. تسک‌ها تا حد امکان کوچک تعریف می‌شوند، فعالیت واقعی با کمک ابزارهای ثبت فعالیت اندازه‌گیری می‌شود و در پایان هر دوره، اختلاف بین زمان تخمینی و واقعی مورد بررسی قرار می‌گیرد.
اما چیزی که این روش را از یک سیستم ساده ساعت‌سنجی متمایز می‌کند، چرخه بازخوردی آن است.
ما صرفاً نمی‌خواستیم بدانیم یک توسعه‌دهنده چند ساعت کار کرده است. می‌خواستیم بفهمیم چرا یک کار بیشتر یا کمتر از انتظار زمان برده، چه مشکلاتی در فرایند توسعه وجود دارد و چطور می‌توانیم در دوره بعد بهتر عمل کنیم.
به نظرم مهم‌ترین اصل در استفاده از چنین روشی این است که داده‌ها باید به ابزاری برای گفت‌وگو و یادگیری تبدیل شوند، نه وسیله‌ای برای کنترل و مقصرشناسی.
اگر توسعه‌دهنده و مدیر محصول هر دو بتوانند به داده‌ها اعتماد کنند و درباره نتایج آن‌ها گفت‌وگوی سازنده‌ای داشته باشند، حتی یک روش ساده مبتنی بر تخمین و ثبت زمان هم می‌تواند به شفافیت و بهبود قابل‌توجهی در فرایند توسعه نرم‌افزار کمک کند.
این روش قرار نیست جایگزین Scrum، Story Point یا سایر چارچوب‌های مدیریت توسعه نرم‌افزار شود. بلکه می‌تواند در کنار آن‌ها، یک لایه تحلیلی دیگر برای بررسی عملکرد زمانی و بهبود دقت تخمین‌ها فراهم کند.
در نهایت، هدف از اندازه‌گیری عملکرد توسعه‌دهنده این نیست که صرفاً بفهمیم چقدر کار کرده است؛ هدف این است که بتوانیم شرایطی ایجاد کنیم که در آن، کارها بهتر تخمین زده شوند، باکیفیت‌تر انجام شوند و تیم در طول زمان یاد بگیرد و پیشرفت کند.
در انتها لازم است از آقای امیرحسین دورودیان، که همدلانه در این مسیر به عنوان توسعه دهنده همراه ما بود و به بهبود این مدل کمک کرد تشکر کنم.
