داشبورد خوب مجموعهای از نمودارهای زیبا نیست؛ یک سطح تصمیمگیری است. هر نمودار باید به یک سؤال مشخص پاسخ دهد و داده آن از workflow و fieldهایی بیاید که تیم بهطور منظم بهروزرسانی میکند.
داشبورد را با مخاطب طراحی کنید
تیم اجرا به کارهای امروز، blockedها و صف آماده نیاز دارد. مدیر پروژه به زمان چرخه، حجم کار و ریسک release نگاه میکند. مدیر ارشد به روند تحویل، ظرفیت و وضعیت پروژههای کلیدی نیاز دارد. یک dashboard واحد برای همه معمولاً برای هیچکس دقیق نیست.
پیش از انتخاب gadget، سؤالهای هر نقش را بنویسید و فقط شاخصهایی را نگه دارید که منجر به اقدام میشوند.
داده قابل اعتماد از JQL قابل اعتماد میآید
فیلترهای ذخیرهشده باید نام، مالک و تعریف روشن داشته باشند. عبارتهای JQL مبهم، statusهای مشابه و fieldهای آزاد باعث میشوند دو گزارش ظاهراً مشابه نتیجه متفاوت بدهند. برای فیلترهای مدیریتی، بازبینی دورهای و کنترل دسترسی را در نظر بگیرید.
اگر تاریخهای پروژه برای کاربران فارسیزبان خوانا نیست، پیش از گزارشسازی به تجربه نمایش تاریخ و تقویم کاری رسیدگی کنید؛ گزارش دقیق با ورودی مبهم اعتماد ایجاد نمیکند.
شاخصهای مفید برای شروع
برای شروع، تعداد کارهای باز، زمان چرخه، throughput، کارهای بدون مسئول، issueهای blocked و وضعیت release را اندازهگیری کنید. این مجموعه کوچک معمولاً از دهها شاخص پراکنده اطلاعات بیشتری برای بهبود میدهد.
شاخصها را با هدف و دوره گزارش همراه کنید. افزایش issueهای بستهشده بدون توجه به کیفیت یا بازگشت کار، بهتنهایی نشانه موفقیت نیست.
- Flow: زمان چرخه و throughput
- Risk: blocked، overdue و dependency
- Quality: reopen، defect و کار برگشتی
- Delivery: وضعیت release و scope change
گزارش را به گفتگو وصل کنید
در جلسه بازبینی، هر عدد باید به یک پرسش و اقدام بعدی وصل شود: چرا صف بررسی طولانی شده؟ کدام وابستگی release را تهدید میکند؟ چه تغییری در workflow یا ظرفیت لازم است؟ اگر dashboard فقط نمایش داده شود و تصمیمی از آن بیرون نیاید، نگهداری آن هزینه اضافی است.