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