نحوه ارزیابی عملکرد تیم های چابک

انتهای اسپرینت چهار بود و جلسه بازبینی اسپرینت را انجام داده بودیم، زنگ تلفن به صدا در آمد، مدیر ارشد واحد ایران پشت خط بود.-“سلام، خوبی اسد؟”-“سلام، ممنون مهندس، شما خوبی؟”-“…اسپرینت تون خیلی عالی شده بود” (به حالت ذوق زده)-“چطور مهندس؟”-“جیرا رو چک کردم، Velocity بالاتر رفته بود، خیلی عالی، همینجوری ادامه بدید…”ما هم ذوق کردیم از تعریف و تمجید مهندس. آخر اسپرینت پنجم شد و یک بخشی از کارها باگ داشت یا بخشی از شرایط پذیرش مالک محصول محقق نشده بود. مالک محصول اصرار داشت که این ها را نپذیرد، و بالطبع امتیاز این آیتم ها به تیم تعلق نمی گرفت و تقریبا Velocity تیم نصف می شد. اما برای اینکه مهندس خوشحال بشه، التماس به مالک محصول که “تو رو خدا این ها را قبول کن و برای باقی مانده یک آیتم جدید تو جیرا ثبت می کنیم”.اتفاقی که از اسپرینت بعد ادامه داشت، Velocity بالا بود و مهندس خوشحال، و تمام تلاش تیم برای خوشحال نگه داشتن مهندس بود و چیزی که برای تیم مهم نبود شرایط پذیرش مالک محصول و نیاز واقعی مشتری ها بود.این داستانی که گفتم، تجربه واقعی ما از پروژه ای بود که قبلا اینجا در مورد آن نوشتم.یکی از سوالات همیشگی دوستان این است که چگونه تیم ها را ارزیابی کنیم؟ از چه شاخص هایی برای ارزیابی عملکرد نفرات یا تیم استفاده کنیم؟ یکی از محبوبترین این شاخص ها در تیم های چابک Velocity است. اما Velocity چه مشکلی دارد؟ و بهتر است از چه شاخص هایی استفاده کنیم؟علاوه بر داستان اولیه (منحرف کردن تیم از تمرکز بر روی مشتری و نیاز واقعی) یکی دیگر از مشکلات اندازه گیری Velocity بالا رفتن تخمین ها است. بدلیل اینکه Velocity یعنی رضایت ذی نفعان، پس عداد یا امتیازهایی که به کارها به عنوان تخمین داده میشد نیز به مرور افزایش پیدا می کرد.واقعیت در مورد اندازه گیریمردم را هر طوری اندازه بگیرید، همانگونه رفتار خواهند کردیابه من بگو که چگونه من را اندازه خواهی گرفت، تا بگویم چگونه رفتار خواهم کرددر یک کارخانه تولید میخ، گفتند پاداش بر اساس وزن میخ تولیدی خواهد بود، اندازه میخ های افزایش پیدا کرد. گفتند، پاداش بر اساس تعداد میخ ها است، اندازه میخ ها کوتاه تر شد ولی تعداد بالاتر رفت. مردم را هر طوری اندازه بگیرید، همانگونه رفتار خواهند کرد، پس خیلی مهم است که چه چیزی را اندازه بگیرید.اما واقعا در تیم توسعه چه چیزی را باید اندازه بگیریم؟یکی از قوانین مهم در تعیین شاخص اندازه گیری، یک بعدی نبودن آن است. یعنی با ارزیابی تنها یک شاخص، شما معمولا چیز خوبی بدست نخواهید آورد. در اینجا اصلا قصد من این نبود که بگویم Velocity بد است یا خوب.ولاسیتی - Velocity را می توان اندازه گرفت، می توان به عنوان شاخص از آن استفاده کرد، ولی به تنهایی کافی نیست.Output و Outcomeاوت پوت - Output یعنی میزان خروجی و Outcome (برآیند) میزان تاثیر کار. اگر تیم خروجی محور باشد، در نهایت تعدادی قابلیت تولید خواهند کرد که اهمیتی به مصرف یا تاثیر آن بر مشتری و بازار ندارند و صرفا در فکر افزایش سطح تولید هستند(کارخانه کلوچه سازی)، برآیند محور بودن بدنبال حداکثری سازی تاثیر خروجی بر روی بازار یا مشتریان است، شاید همان شعار قابلیت کم ولی تاثیر بیشتر.یک نکته مهم در مورد اوتکام یا برآیند این است، این برآیند حس و ذهنیتی است که کاربر یا مشتری نسبت به استفاده از خروجی شما خواهد داشت. در واقع شما نمی توانید آن را دستکاری کنید، تنها کاری که می توانید انجام بدهید این است که به نیازهای اساسی کاربر/مشتری توجه داشته باشید که با ارائه خروجی درست و به موقع و گرفتن بازخورد، بتوانید برای او برآیند مطلوب را خلق کنید..ارزش محور بودن به جای خروجی محور بودننرم افزار قابل استفاده اصلی ترین معیار سنجش پیشرفت استهمانطوری که در اصول بیانیه چابک خواندیم، اصلی معیار سنجش پیشرفت، نرم افزار قابل استفاده است. نرم افزاری که مشکل کسب کار یا مشتری را رفع کند. نرم افزاری که راه حل باشد نه اینکه سوپی از قابلیت ها.خیلی از نرم افزارهایی که ما می بینیم بیشتر شبیه یک سوپ یا آش هستند که همه چیز داخل آن ها است.اما چگونه در عمل میتوان توجه تیم را به سمت نرم افزار قابل استفاده برد؟یکی از روش هایی که در همین تیم استفاده کردیم، اضافه کردن یک فیلد با عنوان ارزش تجاری در جیرا بود، این فیلد توسط مالک محصول پر میشد. با توجه به این تغییر یکی از معیارهای تیم، تولید بیشترین ارزش تجاری در هر اسپرینت بود(البته توجه کنید که گفتیم یک بعدی نباید سنجش کنیم). شاید Velocity بالا رفته باشد ولی ارزش تجاری پایین بود، پس اوضاع تولید ما خوب نیست.وقتی Velocity و Business Value در کنار هم قرار می گیرند، می توانند باعث ایجاد تعادل Output و Outcome شوند.البته به غیر از اینها، شاخص های دیگری نیز هستند، مثلا تعداد باگ در هر نسخه، متریک های آنالیز کد(مثل کدهای تکراری)، Lead Time، انحراف تخمین و …، قبلا از استفاده از هر کدام باید در نظر بگیرید که هیچ یک از اینها به تنهایی کار نمی کنند و در نظر بگیرید که مردم را هر طوری اندازه بگیری همانطور رفتار خواهند کرد.چابک و موفق باشیداسد صفریاین نوشته قبلا در وبلاگ دنیای چابک منتشر شده بود