1- درخواستهای کل در مقابل درخواست های باز TOTAL TICKETS VS. OPEN TICKETS
تعدادی مهم از کارهای حل نشده جمع شده ممکن است یک مشکل را در سیستم یا عاملها ترجمه کند. به همین دلیل مهم است که آن را در ارتباط با سایر شاخص ها (حجم کار پرسنل ، مهلت آنها و غیره) که در مثال ما کنار گذاشته شده است ، کنترل کنید. به لطف نرم افزارها KPI مدرن به راحتی می توانید نسبت درخواست های باز به حل شده را ردیابی کنید ، ضمن اینکه مهمترین درخواست های باز را زیر نظر دارید تا کارهای خود را به موقع انجام دهید. همچنین می توانید با گزینه های مختلف فیلتر برای تاریخچه درخواست کار کنید ، و به عنوان مثال توسط یک پروژه خاص یا توسط یک تیم یا کارمند جداگانه فیلتر کنید.
شاخص های عملکرد
نسبت درخواست های باز نسبت به درخواست های تکمیل شده را با گذشت زمان برای پروژه های مختلف ، تیم ها یا کارمندان کنترل کنید و بهینه سازی بالقوه را در سیستم درخواست خود پیدا کنید.
بنابراین ، به عنوان مثال ، اگر یک میز خدمات به طور متوسط 200 درخواست در روز تحویل می گیرد و میانگین عقب مانده روزانه 10 درخواست است ، میانگین بلاک مانده پایان روز 5٪ از حجم درخواست است (10 درخواست باز در پایان روز ÷ 200 درخواست متوسط در روز = 5٪ از حجم درخواست روزانه).
2- متوسط زمان رسیدگی AVERAGE HANDLE TIME
این IT KPI معیار اصلی برای هر مدیر IT است - بلکه همچنین برای کارمندان - و به شما کمک می کند تا وظایف ، پروژه ها و دوزهای برنامه ریزی شده خود را کنترل کنید. با تجزیه و تحلیل سرعت های گذشته خود ، می توانید حجم کار هر کارمند را بهینه کنید. در مثال خود به کنار ، ما در مورد یک دو سرعت 5 روزه صحبت می کنیم. می بینیم که نانسی وظایف خود را در حداکثر سرعت 5 روزه به پایان رسانده است ، معمولاً پس از 3.7 روز ، و کار سنگینی ندارد. اما پائولا به ندرت می تواند در عرض 5 روز به وظایف خود عمل کند. بنابراین شما باید دلایل آن را تجزیه و تحلیل کنید: آیا این به دلیل مدیریت بد برنامه ریزی است ، یا آیا پائولا مهارت لازم برای انجام آن کار را ندارد؟ به طور کلی ، متوسط زمان رسیدگی برای همه کارمندان 5.5 روز است که هنوز در چارچوب است.
شاخص های عملکرد
سرعتهای ورزشی خود را در فاصله زمانی دلخواه (یک هفته ، دو هفته ، چهار هفته و غیره) تجزیه و تحلیل کنید و بار کاری همه اعضای تیم را بهینه کنید. سپس می توانید میانگین زمان رسیدگی را با دقت بیشتری برنامه ریزی کنید و از این رو مهلت های پروژه خود را کنترل بیشتری کنید.
برای محاسبه میانگین زمان رسیدگی ، کل زمان مکالمه را با کل زمان نگهداری اضافه کنید ، سپس ACW را اضافه کنید. در آخر ، این تقسیم را بر تعداد کل تماس ها برای دریافت AHT تقسیم کنید. AHT را می توان در هر نماینده ، هر بخش یا کل سازمان ارزیابی کرد.
ACW میانگین زمان کار پس از تماس با اضافه کردن کل زمان صرف شده توسط یک نماینده خاص (یا تیم) در یک بازه زمانی مشخص و تقسیم مجموع بر تعداد کل تماس ها در یک بازه زمانی مشابه اندازه گیری می شود
3- تعداد اشکالات بحرانی NUMBER OF CRITICAL BUGS
مشکل پشتیبانی فناوری اطلاعات (برنامه ریزی نشده) چرخه زمان تعداد دقایق لازم برای حل یک مشکل پشتیبانی فناوری اطلاعات مربوط به حادثه برنامه ریزی نشده (خرابی سخت افزار ، خرابی چاپگر ، خرابی سرور ، خرابی اتصال و غیره) را از زمان ورود کارمند پشتیبانی فناوری اطلاعات اندازه گیری می کند در محلی که کار باید انجام شود تا زمانی که حادثه برطرف شود. مقدار نسبتاً زیاد برای این معیار معمولاً به چند عامل متداول مربوط می شود ، از جمله فرآیندهای ناکارآمد و غیراستاندارد حل حادثه (به عنوان مثال ، ردیابی اسناد ضعیف مشتری ، ارتباط ناکارآمد مشتری درمورد آنچه قبلاً برای حل این مسئله تلاش شده است ، عدم رسیدن به مکان آماده شده برای حل مسئله ، و غیره) ، و زیر بخش فناوری اطلاعات از آموزش و عملکرد کارکنان پشتیبانی می کند. در نتیجه هر یک از این عوامل می تواند ظرفیت سازمانی را کاهش دهد ، بهره وری کارمندان را به تأخیر بیندازد ، هزینه های مربوط به مشکلات را افزایش دهد و احتمال وقوع دوباره کاری و خطاها را افزایش دهد.
تعداد دقایق لازم برای حل یک مشکل پشتیبانی IT غیر برنامه ریزی شده مربوط به حادثه (خرابی سخت افزار ، خرابی چاپگر ، خرابی سرور ، قطع اتصال و غیره) ، از زمان ورود کارمند پشتیبانی فناوری اطلاعات به مکانی که کار باید انجام شود تا زمانی که حادثه برطرف شود.
برای محاسبه این KPI از دو مقدار استفاده می شود: (1) تعداد دقیقه مورد نیاز برای حل یک بلیط پشتیبانی / خدمات IT برنامه ریزی نشده و (2) تعداد کل بلیط های پشتیبانی / خدمات IT برنامه ریزی نشده که در مدت زمان مشابه حل شده اند. حادثه های شامل کار غیر برنامه ریزی شده ای است که نیاز به تماس فیزیکی یک کارمند پشتیبانی فناوری اطلاعات به یک یا چند دستگاه دارد. مشکل های حادثه ای شامل خرابی یا رفع سخت افزار ، خرابی دستگاه ، خرابی اتصال و غیره است. بلیط ها وقتی بسته می شوند که مشکل پشتیبانی حل شود بدون اینکه توسط کارمندان پشتیبانی برای مدت زمان دیگری که توسط شرکت مشخص شده دوباره باز شود. در این محاسبه زمان لازم برای رسیدن کارمند پشتیبانی فناوری اطلاعات به محل کار را محاسبه نکنید.
(جمع دقایق لازم برای حل حوادث غیرمترقبه) / تعداد کل حوادث غیرمترقبه حل شده
4- زمان خرابی سرور SERVER DOWNTIME
مرکز سرور IT KPI عالی برای مدیریت عملکرد سرور است. این مدت زمانی است که زیرساخت IT شما کار نمی کند و کار نکردن را ردیابی می کند. زمان خاموش می تواند برنامه ریزی شود: برای تعمیر و نگهداری ، به روزرسانی یا راه اندازی مجدد سیستم ، که برای زیرساختی با عملکرد مناسب ضروری است. با این وجود ، هنگام خرابی سیستم ، توقف غیرمترقبه نیز می تواند غیرمنتظره باشد - و در این لحظه ، شما باید یک طرح پاسخ به خاموشی داشته باشید که به طور کارآمد طراحی شده باشد تا آن زمان توقف پیش بینی نشده را به حداقل برساند. می توانید این معیار IT را به صورت ماهانه یا سه ماهه یا سالانه بسنجید - اما هرچه بیشتر ، بهتر است ، بنابراین اگر زمان های مشخصی در این زمان وجود داشته باشد می توانید با دقت بیشتری ردیابی کنید و ریشه های اصلی را بیشتر بشناسید به راحتی.
شاخص های عملکرد
می توانید زمان خرابی را در دقیقه و در کنار زمان کار به صورت درصد اندازه گیری کنید. داشتن یک ساعت کاری بیش از 99،9٪ خوب به حساب می آید و مطلوب است.
در دسترس بودن = Uptime ÷ (Uptime + downtime)
این دارایی در مدت یک ماه 200 ساعت کار کرد. این دارایی همچنین به دلیل خرابی دو ساعت بدون برنامه ریزی و 8 ساعت خرابی برای PM های هفتگی داشته است. این برابر با 10 ساعت از کار افتاده کل است.
5- زمان تعمیر MEAN TIME TO REPAIR
میانگین زمان تعمیر KPI IT است که با محاسبه زمان بین شروع یک حادثه تا لحظه رفع آن اندازه گیری می شود. این شامل زمان تشخیص ، زمان ثابت سازی ، تراز بندی ، کالیبراسیون ، آزمایش و زمان انتظار برای بازگشت به چرخه معمول است. این یک معیار عملکرد IT با قابلیت اطمینان است زیرا اندازه گیری میزان مهارت یک تیم در مواجهه ، پاسخ دادن و ترمیم یک مشکل را ارزیابی می کند. مثالهای IT KPI ، زمان متفاوتی را برای تعمیر با توجه به ماهیت آنها (مشکلات DNS ، خرابی سخت افزار ، ...) و زمان نیاز به عیب یابی سازمان می دهند: به این ترتیب ، شما نه تنها می دانید که کجا باید کارکنان بیشتری را برای آدرس دهی اختصاص دهید مسائل ، بلکه همچنین چقدر طول می کشد تا انجام این کار این برای برنامه ریزی پیش رو مهم است.
شاخص های عملکرد
با دانستن اینکه کدام موضوعات ظاهر می شوند و برای چه مدت ، می توانید فرایندها و استراتژی های استاندارد را برای مقابله با آنها در صورت بروز بهتر ایجاد کنید و با گذشت زمان تکامل را معیار قرار دهید.
برای محاسبه MTTF ، تعداد کل ساعات کار را بر کل دارایی های مورد استفاده تقسیم کنید. محاسبه MTTF با تعداد بیشتری دارایی به نتیجه بیشتری منجر می شود زیرا MTTF میانگین زمان شکست را نشان می دهد .
6- مشکلات و نواقص مجدد REOPENED TICKETS
خلاصه برجسته ترین معیارهای عملکرد فناوری اطلاعات بدون تمرکز بر روی مشکلات بازگشایی ، کامل نخواهد شد. این اساساً نشان می دهد که نحوه کار ، معمولاً بازخورد یا اشکال ، چقدر موثرتر است و نیازی به بازگشایی اضافی ندارد. اگر تیم عملکرد خوبی داشته باشد ، مشکلات کمتری تکرار می شوند و تلاش شما برای بهبود مثبت خواهد بود. برای بهبود عملکرد تیم ، خوب است که به مرور این معیار را ردیابی کنید و ببینید کدام ماه ها مشکلات بازگشایی شده بیشتری را به ارمغان آورده اند. هدف این است که سیستم تا حد ممکن تمیز و اعداد در انتهای پایین طیف باشد.
شاخص های عملکرد
تعداد نواقص بازگشایی شده را به مرور پیگیری کنید و با تیم صحبت کنید تا ببینید چه اتفاقی در برخی از افزایش ها در داده های معیار شما رخ داده است.
درخواستهای خدمات بسته در یک بازه زمانی مشخص .
معیاری است که برای نشان دادن تعداد دفعات رفع مشکلات حل و فصل یا بسته استفاده می شود. (وضعیت مشکلات از حالت حل شده / بسته به باز تغییر یافت )
درصد درخواست های خدمات بسته که مجدداً باز شده اند (و بنابراین در ابتدا طبق نظر مشتری حل نشده اند) ، نسبت به درخواست های خدمات بسته در یک بازه زمانی مشخص.
7- صحت تخمین ها ACCURACY OF ESTIMATES
در بسیاری از سناریوهای IT ، توسعه دهندگان برای انجام یک کار باید زمان کافی را تخمین بزنند. بسیار دشوار است که هر بار 100٪ به درستی تخمین بزنید ، اما نکته این است که تا آنجا که ممکن است نزدیک باشید. از دست دادن تاریخ راه اندازی به دلیل افزایش تعداد اشکالاتی که توسعه دهندگان باید با آنها روبرو شوند ، در حوزه IT رایج است و برای آمادگی بهتر برای آینده ، به پیگیری منظم نیاز دارد. در اینجا نیز داشتن یک وظیفه "فقط" منطقی خواهد بود: این فقط یک کار کوچک است ، فقط 10 دقیقه طول می کشد تا آن را حل کنید ، نباید زمان زیادی را صرف کنید ، و غیره باعث تأخیر و مهلت از دست رفته از آنجا که توسعه دهندگان می توانند به راحتی زمان لازم برای تمرکز بر روی مسئله را دست کم بگیرند.
شاخص های عملکرد
کارایی کار را با درصد کنترل کنید و آن را توسط اعضای تیم تقسیم کنید تا بدانید کدام کارها باعث تخمین های نادرست شده اند و دلیل آن را بررسی کنید.
8- موارد پشتیبانی برای هر کارمند باز می شود Support Tickets Opened per Employee
موارد پشتیبانی باز شده برای هر کارمند ، کارایی کارمندان پشتیبانی را برای حل و فصل مسائل IT برای سایر کارمندان اندازه گیری می کند. مقدار کم برای این KPI ممکن است نشان دهد که کارمندان پشتیبانی زمان زیادی را صرف حل و فصل موارد خدمات شخصی می کنند یا زمان زیادی را برای کارهای اداری کم ارزش دیگر صرف می کنند. عملکرد ضعیف (به عنوان مثال ، مقدار کم) برای این KPI همچنین می تواند به افزایش نیرو در عملکرد پشتیبانی فناوری اطلاعات مرتبط باشد (به عنوان مثال ، بار کاری با سطح کارکنان مطابقت ندارد).
تعداد کل موارد پشتیبانی دسک تاپ کارمندان باز شده بر تعداد کارکنان مسئول پردازش و حل بلیط های پشتیبانی در مدت زمان مشابه تقسیم می شود.
روشهای پیش بینی دقیق کار برای بهینه سازی سطح کارکنان داخلی
مسائل و دلایل اصلی را برای کاهش زمان وضوح و جلوگیری از موارد تکراری ثبت کنید
برای کاهش زمان چرخه ، موارد را بر اساس فوریت و پیچیدگی امتیاز دهید.
برای محاسبه این KPI از دو مقدار استفاده می شود: (1) تعداد کلی موارد پشتیبانی که توسط کارکنان در یک دوره زمانی خاص باز شده است و (2) تعداد کل کارکنان پشتیبانی فناوری اطلاعات که برای شرکت در مدت زمان مشابه کار می کنند. برای این محاسبه ، موارد پشتیبانی فناوری اطلاعات باید شامل حوادث و درخواست های خدمات باشند. حوادث رویدادهای برنامه ریزی نشده مانند خرابی اتصال ، عملکرد بد دستگاه یا رفع سخت افزار است. درخواست های خدمات رویدادهای برنامه ریزی شده ای مانند به روزرسانی دستگاه ، به روزرسانی نرم افزار و غیره است. به عنوان هر کارمندی که فعالیت های پشتیبانی فناوری اطلاعات کاربر نهایی و یا تعمیر و نگهداری کارکنان شرکت را انجام می دهد ، کارمندان پشتیبانی را حساب کنید.
تعداد کل موارد پشتیبانی فناوری اطلاعات باز شده / تعداد کل کارکنان پشتیبانی فناوری اطلاعات
9- هزینه برون سپاری فناوری اطلاعات به عنوان درصدی از هزینه کل فناوری اطلاعات
هزینه برون سپاری فناوری اطلاعات به عنوان درصدی از هزینه کل فناوری اطلاعات ، سطح برون سپاری را که توسط عملکرد IT برای به حداکثر رساندن کارایی عملیات خود استفاده می شود ، اندازه گیری می کند. ارزش نسبتاً زیاد برای این KPI نشان می دهد که بخش IT ممکن است کمبود نیرو داشته باشد یا اینکه کارکنان بخش دانش کافی برای اداره طیف وسیعی از پروژه ها یا وظایف IT را ندارند. درصد بالایی از هزینه های فناوری اطلاعات اختصاص داده شده به برون سپاری همچنین می تواند بر روحیه کارکنان تأثیر منفی بگذارد ، زیرا این احساس وجود دارد که موقعیت های آنها توسط فروشندگان شخص ثالث جایگزین می شود. اگرچه مقدار کم برای این KPI ترجیح داده می شود ، بودجه های برون سپاری فناوری اطلاعات بر اساس استراتژی شرکت است و سرمایه گذاری در منابع خارجی فناوری اطلاعات می تواند به کاهش ریسک کمک کند ، تمرکز کارکنان به سمت اهداف استراتژیک شرکت تغییر یابد و در طولانی مدت می تواند به پس انداز هزینه کمک کند.
کل هزینه مربوط به برون سپاری انجام شده توسط بخش فناوری اطلاعات بر کل هزینه انجام شده توسط بخش فناوری اطلاعات در همان بازه زمانی تقسیم شده است ، به عنوان یک درصد.
روشهای پیش بینی دقیق کار برای بهینه سازی سطح کارکنان داخلی
برای کاهش هزینه های پرسنل و بهبود دقت / بهره وری ، از ابزارهای مدیریت ذخیره سازی خودکار استفاده کنید
برای دستیابی به صرفه جویی در هزینه یا کاهش هزینه ها ، به طور منظم قراردادهای فروشنده فناوری اطلاعات را ارزیابی و مذاکره مجدد کنید
کارمندان متقابل را آموزش دهید تا چندین وظیفه را در عملکرد IT مدیریت کنند
برای محاسبه این KPI از دو مقدار استفاده می شود: هزینه های بخش IT شامل نیروی کار ، برنامه ها ، امنیت ، سخت افزار ، نرم افزار ، زیرساخت شبکه ، هزینه های مرکز داده ، هزینه امکانات ، دستگاه های کاربر نهایی و غیره است. هزینه های برون سپاری باید شامل هر کاری باشد که توسط شخص ثالث انجام شود و به طور معمول توسط بخش IT استهلاک را در این محاسبه قرار ندهید. برون سپاری فن آوری را که مربوط به بخش فناوری اطلاعات نیست (شامل حقوق و دستمزد ، حساب های قابل پرداخت ، مرکز تماس و غیره) نکنید.
(هزینه برون سپاری فناوری اطلاعات / هزینه کل بخش فناوری اطلاعات) * 100
10- زمان تعمیر Mean Time To Repair
میانگین زمان تعمیر ، توانایی عملکرد IT را برای پاسخگویی و حل یک سیستم یا خرابی برنامه یا قطع سرویس ، اندازه گیری می کند و اطمینان حاصل می کند که وضوح تصویر برای همه ایستگاه های کاری ، دستگاه ها ، سرورها و غیره ارائه می شود. نشان می دهد که رویه های پاسخ عملکرد IT وجود ندارد و یا اینکه سیستم ها به گونه ای ساخته نشده اند که اشکال زدایی و بازیابی سریع را تسهیل کند. مقدار زیاد برای میانگین زمان تعمیر نیز می تواند تأثیر قابل توجهی در عملیات روزمره تجارت داشته باشد (به عنوان مثال دسترسی به داده های مهم شرکت یا سوابق مشتری) ، که می تواند به رابطه شرکت با مشتریان آسیب برساند.
میانگین زمان مورد نیاز برای تعمیر سیستم یا برنامه به عملکرد کامل پس از خرابی (به عنوان مثال قطع شدن سرویس) ، اندازه گیری شده از زمان وقوع خرابی تا زمان اتمام تعمیر و پخش آن برای همه مکان های مورد نیاز (سرورها ، دستگاه ها ، ایستگاه های کاری و غیره).
کارمندان آموزش متقابل دارند تا در ساعات اوج مصرف انواع مختلف مسائل را حل کنند
عملکرد IT برای رفع خرابی های سیستم در صورت بروز ، به اندازه کافی کارمند است
مسائل و دلایل اصلی را برای کاهش زمان وضوح و جلوگیری از بلیط های تکراری ثبت کنید
دستورالعمل های محاسبه KPI مدت زمان تعمیر
از زمان دو رویداد برای بدست آوردن زمان برای تعمیر استفاده می شود: (1) زمانی که خرابی سیستم رخ داده است ، و (2) زمانی که سیستم پس از خرابی به عملکرد کامل خود بازگردانده شده است (یعنی تعمیر شده است). زمان تعمیر تفاوت این دو زمان است. به منظور بدست آوردن مقدار متوسط (به عنوان مثال ، متوسط) برای زمان تعمیر ، مجموع زمان را برای تعمیر در تمام سیستم های مورد بررسی در نظر بگیرید و آن را بر تعداد تعمیرات انجام شده در آن سیستم تقسیم کنید. فقط تعمیرات به دنبال خرابی سیستم باید در این محاسبه لحاظ شود. خرابی باید به عنوان هر نمونه ای که یک سیستم باید به دلیل یک مسئله مهم متوقف شود ، محاسبه شود. این KPI باید بر اساس نوع سیستم (بحرانی ، پشتیبانی یا مشتری روبرو) تقسیم بندی شود تا زمینه و ارتباط عملیاتی هر تجزیه و تحلیل مرتبط بهبود یابد.
مجموع زمان تعمیر برای همه سیستم ها / تعداد تعمیراتی که در طول دوره معاینه در همه سیستم ها انجام شده است.
11- محاسبه بازگشت سرمایه پروژه های IT
بخشی اساسی در هر سازمانی است ، اما نباید با هزینه سلامت مالی شرکت شما کار کند. ابتکارات جدید IT همیشه پر از پتانسیل است ، اما واقعیت های هزینه ای همیشه با مزایایی که از آنها می گیرید همسو نیستند. اندازه گیری میزان بازگشت سرمایه برای پروژه های IT می تواند به شما کمک کند تا استراتژی فنی خود را بهتر برنامه ریزی کنید ، و به شما این امکان را می دهد که از ابتکارات ، پروژه ها و فناوری هایی که دوره خود را طی کرده اند یا هزینه بیش از حد هزینه های اضافی شرکت شما را دارند ، صرف نظر کنید. از نظر انتقادی ، ROI IT می تواند به شما در کاهش هزینه ها ، جلوگیری از هزینه ها و یافتن مناطقی برای بهبود کارایی قیمت (مانند ارائه دهندگان تعویض) کمک کند.
برای اندازه گیری میزان بازگشت سرمایه برای پروژه های IT ، ابتدا باید داده هایی مربوط به هزینه های شما در هر پروژه یا سرمایه گذاری و همچنین درآمد حاصل از آنها داشته باشید. محاسبه استاندارد ROI IT به شرح زیر است:
ROI = ((درآمد - هزینه های سرمایه گذاری) / هزینه های سرمایه گذاری) * 100
به طور کلی ، شما می خواهید درصد ROI شما بیشتر باشد. با این حال ، لازم به ذکر است که استفاده از ROI همیشه برای هر هزینه IT ایده آل نیست ، از جمله فعالیت هایی مانند جایگزینی تجهیزات خراب ، پروژه های کوتاه مدت که می تواند در چند روز انجام شود ، یا جنبه های مربوط به هزینه های لازم برای پروژه های IT استفاده کنید.
ROI با تقسیم منافع بر هزینه سرمایه گذاری اندازه گیری می شود. هرچه بالاتر بهتر البته. اندازه گیری آن به مرور زمان مهم است تا تکامل آن را ببینید ، که باید به سمت بالا باشد.
12- Sprint Burndown
تیم های چابک پیشرفت خود را به صورت دو سرعت انجام می دهند. یک مرکز سرعت دویدن اندازه گیری می کند که تیم در طول دو سرعت چه کارهایی را انجام داده است. نمودار Sprint Burndown یک ابزار اندازه گیری بصری است که کار تمام شده در هر روز را با توجه به میزان پیش بینی شده برای سرعت فعلی نشان می دهد. این شفافیت در مورد عملکرد فعلی را فراهم می کند و در صورت دستیابی به موقع به هدف Sprint یا اینکه تیم مجبور است اقدامات بیشتری برای سرعت بخشیدن به پایان فعالیت های باقی مانده بدست آورد ، امکان تخمین آسان را فراهم می کند. میزان پیشرفت یک تیم "سرعت" نامیده می شود. میزان کار را در نقاط مختلف تکمیل شده در هر سرعت بیان می کند. یک قانون برای محاسبه سرعت این است که فقط مواردی که در پایان سرعت حداکثر تکمیل می شوند محاسبه می شوند. شمارش کارهای نیمه تمام (مثلاً فقط کدگذاری - فاقد تست) کاملاً ممنوع است.
چه مزایایی دارد؟
تقارن با سرعت برای آگاهی دادن به تیم در مورد مسدود کردن راه ها بسیار مناسب است.
با اندازه گیری میزان سرعت انجام ، می توانید بررسی کنید که آیا تیم شما پیش بینی خود را برآورده می کند یا خیر.
با استفاده از نمودار تجزیه سرعت ، تیم می تواند پیشرفت خود را مدیریت کند. اگر تیم متوجه شود که ممکن است به هدف نرسد ، اعضای تیم می توانند اقدامات مناسب را برای ادامه مسیر انجام دهند.
چطور اندازی گیری می کنید؟
تیم های چابک از نمودارهای Sprint burndown برای تجسم گردش کار خود استفاده می کنند. نمودار دارای یک محور x است که نشان دهنده زمان است و یک محور y است که نشان دهنده میزان کار باقی مانده برای انجام است. می توانید زمان را بر حسب ساعت یا نقاط موضوعات در دست اقدام اندازه گیری کنید. یا می توانید به آمار خود فکر کنید. هدف اصلی در اینجا این است که تمام کارهای پیش بینی شده تا پایان مراحل تمام شود.
شما یک محور عمودی خواهید دید که نقاط وظایف را نشان می دهد. محور افقی زمان را نشان می دهد. خط قرمز در نمودار نشان دهنده میزان کار باقی مانده در دو سرعت است. خط خاکستری خط کار واقعی است. اگر خط قرمز زیر خط خاکستری باشد ، این بدان معنی است که تیم در مسیر درست است. با این حال ، اگر خط قرمز بالاتر از خط خاکستری باشد ، این بدان معناست که پروژه از برنامه زمان بندی شده عقب است.
به طور معمول ، تیم ها از نمودارهای دو محوره دو سرعته با نسبت زمان نمایش داده شده به تعداد وظایف انجام شده و انجام نشده استفاده می کنند.
13- Release Burndown
Release burndown نمای کلی از روند انتشار نرم افزار را دارد. این شبیه به انجام حداکثر در سرعت است ، اما دامنه آن بزرگتر است. این به تیم ها کمک می کند تا بررسی کنند که آیا آنها می توانند محصول را در یک تاریخ خاص عرضه کنند یا خیر. اگر متوجه شوند که از برنامه عقب مانده اند ، می توانند تاخیر را به کاربران و سهامداران اطلاع دهند. یا در غیر این صورت ، می توانند دامنه کار برای عرضه به موقع محصول را کاهش دهند. نمودار Burndown نمایشی گرافیکی از کار باقیمانده در برابر زمان است. این نمودار معمولاً در پروژه‌های چابک توسعه نرم‌افزار استفاده می‌شود، البته می‌توان از آن در پروژه‌هایی که پیشرفت قابل اندازه‌گیری در زمان دارند نیز استفاده کرد.
در نمودار Burn-down معمولاً در محور افقی، زمان و در محور عمودی، حجم کاری باقیمانده نمایش داده می‌شود. این نمودار برای پیش‌بینی اینکه کارها در چه زمانی تکمیل می‌شوند مفید است. در اسکرام‌های روزانه، تیم توسعه Sprint Burn-down را به روزرسانی می‌کنند و کار باقی‌مانده‌ی روز را ترسیم می‌کنند. با توجه به دلایل زیر، نمودار Burndown برای تیم توسعه ضروری است.
نظارت بر تغییرات محدوده پروژه
نگه‌داشتن تیم در برنامه زمان‌بندی
مقایسه کار برنامه‌ریزی شده در برابر پیشرفت تیم
ارائه تصویر جامعی از پروژه پیش از شروع آن
تسهیل ارتباطات مشتری با تعیین ساده و واضح انتظارات
کمک به ارزیابی پیشرفت هنگام ارزیابی موانع یا کارهای جدید
چه مزایایی دارد؟
می توانید سرعت کار تیم شما را از طریق پرونده های عقب مانده بررسی کنید.
شما می توانید از چگونگی تأثیر کار اضافه و حذف شده در پیشرفت تیم خود مطلع شوید.
پیش بینی کنید که تیم برای تکمیل کار به چه تعداد سرعتی نیاز دارد.
چطور اندازی گیری می کنید؟
تقسیم زمان انتشار با استفاده از نموداری که مشابه نمودار تجزیه سرعت است ، اندازه گیری می شود. تفاوت در این است که اکنون ، محور افقی نشان دهنده سرعت ها و محور عمودی نشان دهنده کار باقیمانده است (روزها ، ساعت ها یا نقاط وظایف).
به عنوان مثال تیم در ابتدا چهار سرعت و 43 امتیاز داستانی تنظیم کرده است. در طی این چهار سرعت ، تیم تعداد وظایف را از 43 وظیفه به 26 مورد کاهش داده است. تیم همچنین پیش بینی کرده است که عرضه این محصول هفت سرعت دیگر خواهد داشت که در مجموع 11 مسابقه خواهد داشت.
گام ۱- تخمین زمانی کارها
در ساده‌ترین حالت، می‌توان با تقسیم ساعات در دسترس به تعداد روز، می‌توان به ۱۶ ساعت زمان در هر روز دست یافت. به‌منظور ایجاد یک نمودار Burndown باید داده‌های زمانی را به‌صورت روزانه و متوالی ثبت کرد؛ به این ترتیب که در پایان روز اول، ۶۴ ساعت دردسترس باقی می‌ماند (یعنی ۱۶ – ۸۰)، در پایان روز دوم، ۴۸ ساعت باقی می‌ماند (یعنی ۱۶ – ۶۴) و به همین ترتیب تا روز پایانی:
گام ۲- محاسبه پیشرفت واقعی
بعد از شروع کار، زمان‌های واقعی تخصیص‌یافته به کارها مشخص شده و می‌توان در پایان هر روز مقدار زمان باقیمانده را ثبت کرد.
گام ۳- مقایسه نهایی و رسم نمودار Burndown
با استفاده از مقایسه پیشرفت پیش‌بینی‌شده و پیشرفت واقعی کارها براساس زمان که در دو گام پیش حاصل شدند، می‌توان به داده‌های نهایی برای رسم نمودار Burndown دست یافت. این نمودار معمولا در قالب نمودار خطی و با مقایسه تلاش‌های پیش‌بینی‌شده و واقعی رسم می‌گردد.
14- زمان چرخه Cycle Time
زمان چرخه معیاری است که مدت زمانی را که تیم برای انجام یک کار صرف می کند اندازه گیری می کند.
تعداد روزها (سرعت ، ساعت ، ماه) بین تاریخ شروع و تاریخ اتمام را حساب کنید.
چه مزایایی دارد؟
این اطلاعات در مورد عملکرد کلی تیم را فراهم می کند.
این امکان را برای تخمین اتمام کارهای آینده فراهم می کند.
می توانید متوجه هرگونه تنگنا و کندی روند کار شوید.
چطور اندازی گیری می کنید؟
زمان چرخه برابر است با تاریخ پایان منهای تاریخ شروع. به عنوان مثال ، اگر تیم از اول دسامبر کار خود را شروع کند و در 10 دسامبر به پایان برسد ، زمان چرخه 9 روز است.
اگر تیم از اول دسامبر کار خود را شروع کند و کار را در همان روز به پایان برساند ، زمان چرخه شما صفر بلکه یک بار نخواهد بود. برای پروژه هایی که در همان روز شروع و به پایان می رسند ، زمان چرخه برابر است با تاریخ پایان منهای تاریخ شروع 1+.
می توانید روزها را با هفته ها ، ساعت ها یا حتی دو سرعت عوض کنید.
استفاده از نمودارهای زمان چرخه را برای تجسم گردش کار خود در نظر بگیرید. این نمودارها نشان می دهد که یک مسئله در مقایسه با روز تکمیل چه مدت طول کشیده است.
به عنوان مثال ، بیایید به نمودار زیر نگاه کنیم. در محور x می توانید تاریخ بسته شدن کار را ببینید و در محور y نیز می توانید زمان صرف شده را مشاهده کنید. محافل سبز وظایفی است. یک دایره جامد مجموعه ای از مسائل را نشان می دهد ، در حالی که یک دایره باز یک مسئله را نشان می دهد. خط قرمز نشان دهنده زمان متوسط چرخه و خط آبی نشان دهنده زمان متوسط چرخه نورد است.
هدف نهایی این است که تیم دارای چرخه ثابت برای موارد کاری باشد که دارای مقادیر داستانی مشابه هستند. مقادیر پایین به این معنی است که تیم به طور موثر کار می کند ، در حالی که مقادیر بالاتر ممکن است گلوگاه های روند کار را نشان دهد.
15- سرعت تیم Team Velocity
Velocity یکی دیگر از معیارهای مهندسی KPI چابک است که میزان کار یک تیم را در طول سرعت حرکت اندازه گیری می کند. مقدار کار معمولاً در نقاط پروژه یا ساعت اندازه گیری می شود.
دارندگان محصولات از سرعت برای محاسبه سرعت کار یک تیم از طریق تعداد عقب مانده استفاده می کنند. شاخص سرعت برای هر تیم منحصر به فرد است و شما نباید سرعت را در بین تیم ها مقایسه کنید.
به عنوان مثال ، بگذارید بگوییم که شما می خواهید 300 مورد وظایف را در موارد عقب مانده کامل کنید. شما می دانید که تیم توسعه ، به طور متوسط ، حدود 50 امتیاز وظیفه را در هر تکرار کامل می کند. با در دست داشتن این اطلاعات ، می توانید پیش بینی کنید که تیم برای انجام کارهای مورد نیاز به شش تکرار نیاز دارد.
چه مزایایی دارد؟
برای پیش بینی بسیار مفید است.
این می تواند به برنامه ریزی حرکت های آینده کمک کند.
این می تواند به شما کمک کند که تیم را مسدود کنید یا اینکه تغییرات روند شما موثر است.
چطور اندازی گیری می کنید؟
اگر تیم پایداری در محل خود داشته باشید ، با اندازه گیری حداقل 5-7 سرعت سرعت موفق به ایجاد یک سرعت متوسط خواهید شد. اگر سرعت دوی معمول شما هفتگی است و تیم در طول مدت پنج هفته 250 امتیاز را کسب می کند ، میانگین سرعت شما 50 امتیاز در هفته است.
نوارهای آبی نشان دهنده تعهد است و نوارهای سبز نشان دهنده کار واقعی انجام شده است. در قسمت شماره 1 ، تیم 16 نقطه را برنامه ریزی کرد و 16 نقطه را تکمیل کرد. این نشان می دهد که تخمین آنها درست بوده است. با این حال ، در قسمت دوم ، تیم 19 نقطه را برنامه ریزی کرد اما فقط 12 امتیاز را تکمیل کرد. این نشان می دهد که دفعه بعد ، آنها باید برنامه خود را کاهش دهند.
جریان ناسازگار شاخصی است که شما در پیشرفت مشکل دارید و باید تغییرات ایجاد کنی
تا آنجا که KPI های مهندسی پیش می روند ، سرعت معیار مهمی است ، اما درگیر تعقیب یک عدد همیشه بالاتر نباشید. سرعت به چند دلیل می تواند از افزایش جلوگیری کند. ماهیت آن ، تعریف نقطه حرکت می تواند تغییر کند ، و باعث تغییر سرعت شما شود. با گذشت زمان ، تیم شما ، در حالت ایده آل ، حتی بیشتر به یک واحد تبدیل می شود. تیم شما با تجربه تر و حرفه ای تر خواهد شد. آنها مهارت های جدیدی را فرا خواهند گرفت. آنها بیشتر به یکدیگر اعتماد خواهند کرد. و گرچه این محصول به کیفیت بالاتری از محصول منتقل می شود ، اما لزوماً سرعت شما را افزایش نمی دهد.
گفته می شود ، "خوب" نسبت به تیم شما است. سرعت برای تعیین محل مشکلات و اندازه گیری دقیقاً نحوه پیشرفت در چرخه عمر پروژه ها و تیم شما مفید است. به جای تمرکز روی یک تعداد روزافزون ، بر ایجاد یک عملکرد ثابت و با کیفیت تمرکز کنید. با این کار می توانید پروژه های آینده خود را با دقت بیشتری برنامه ریزی کنید.
در طرف دیگر سکه ، اگر سرعت ناسازگار باشد ، این می تواند نشانه ای باشد که روند شما باید بهبود یابد. با تیم خود مشاهده و بررسی کنید. آیا آنها همکاری می کنند؟ آیا آنها احساس می کنند بیش از حد کار می کنند؟ آیا نکات داستانی شما می تواند تعریف بیشتری داشته باشد؟ سرعت می تواند یکی از مفیدترین KPI ها باشد ، اما به یاد داشته باشید که به درستی روی آن تمرکز کنید.
16- جریان تجمعی Cumulative Flow
جریان تجمعی وضعیت تیکت های شما را در یک بازه زمانی مشخص می کند. این نشان دهنده تغییر تیکت های شما از یک وضعیت به وضعیت دیگر است که پروژه شما پیشرفت می کند.
چه مزایایی دارد؟
برای شناسایی گلوگاه ها مفید است.
به تیم ها کمک می کند تا اطمینان حاصل کنند که جریان کار ثابت است.
این به شما نشان می دهد که گردش کار شما چقدر ثابت است.
این به شما کمک می کند درک کنید چگونه می توانید روند خود را قابل پیش بینی تر کنید.
چطور اندازی گیری می کنید؟
ساده ترین راه برای اندازه گیری گردش کار تجمعی استفاده از نمودارها است. آنها سه معیار مهم مهندسی نرم افزار جریان شما را شامل می شوند ، از جمله زمان چرخه ، توان عملیاتی و کار در حال انجام.
بیایید به نمودار زیر نگاه کنیم. محور x افقی زمان را نشان می دهد ، در حالی که محور y عمودی موارد کار را نشان می دهد. رنگ های مختلف نشان دهنده حالت های مختلف گردش کار است. اگر باند ها به طور موازی در حال پیشرفت هستند ، به این معنی است که توان شما پایدار است. این نشان می دهد که تعداد کارهای جدیدی که وارد کار شما می شوند همانند تعداد کارهایی است که از آن خارج می شوند.
اگر یک باند به سرعت در حال باریک شدن است ، به این معنی است که ظرفیت شما بیش از نیاز شما است. شما باید ظرفیت را برای بهینه سازی جریان تغییر مکان دهید.
اگر یک باند به سرعت در حال گسترش است ، به این معنی است که کارتهای بیشتری نسبت به تکالیفی که از آن خارج می شوند ، وارد مرحله مربوطه می شوند.
از نمودارها برای تجسم مهمترین شاخصهای توسعه نرم افزار مانند کار در حال انجام ، چرخه زمانی و توان استفاده کنید.
با استفاده از نمای گرافیکی گردش کار ، به راحتی می توان در چه مرحله ای وظایف بیشتری ظاهر شد و اینکه آیا تیم می تواند از پس این حجم کار برآید. از طرف دیگر ، کاملاً مشخص است که در کجا توان عملیاتی بیش از حد معمول است.
17- نقص در نرخ فرار Defect escape rate
فرض بر این است که این شاخص نشان می دهد که چه تعداد نقص در طی مراحل توسعه و در مرحله آزمایش شناسایی شده است. نرخ فرار از نقص برای شناسایی میزان موارد شناسایی شده پس از تولید یک برنامه نرم افزاری استفاده می شود ، که به عنوان نرخ فرار از نقص شناخته می شود. نرخ فرار از نقص بالاتر نشانگر این است که فرایندهای آزمایش یا ابزارهای تست خودکار مورد استفاده وجود دارد.
هرچه این شاخص پایین تر باشد ، بهتر است. با نرخ پایین ، تیم تضمین می کند یک کد با کیفیت بالا دریافت می کند.
نحوه اندازه گیری:
تحلیل کنید که در چه مرحله ای از نقص توسعه ظاهر شده است.
دریابید که نقص در بین همه پروژه هایی که تیم وظیفه آنها دارد ، چند بار اتفاق می افتد.
نسبت نقص شناسایی شده به نقص رفع شده چقدر است؟
فواید:
با هر پروژه ، متخصصان موضوعی ظرفیت خود را برای مدیریت هر چه بیشتر نقص ها تقویت می کنند.
هر یک از اعضای تیم می تواند با تنظیم تعداد و پیشرفت کارها ، گردش کار را بهتر بهینه کند.
