یادم میاد در یکی از شرکت‌ها به عنوان مدیر ارشد فناوری یا همون CTO مشغول بودم. از زمانی که اونجا رفته بودم سعی کردم انواع زیرساخت‌های لازم رو فراهم کنم. از راه‌اندازی version control تا agile board. یک روز به طور اتفاقی متوجه شدم تعداد pull requestهای تیم به هزار رسیده. خوشحال شدم که تونستیم توی این زمانِ کم اینقدر به صورت تیمی خوب کار کنیم. من هم سریع نون خامه‌ای سفارش دادم و به کل شرکت شیرینی دادم. تا اینجاش خوب بود اما وقتی وارد اتاق تیم‌های دیگه می‌شدم و بهشون شیرینی تعارف می‌کردم ازم می‌پرسیدن:
-- مناسبتش چیه؟
-- امروز هزارمین pull request رو توی تیم دادیم
-- خب این چی هست؟ چه نفعی داره؟ به چه دردی می‌خوره؟
-- خب یکم سخته توضیحش ....... :-(
از مدت‌ها قبل مقاله مارتین فاولر (یا به قول ویکی‌پدیا، مارتین فولر) رو باز کرده بودم و اون هم همینجوری در کنار انبوه تب‌های گوگل کروم -که قرار بود در آینده‌ای نزدیک بخونمشون- انتظار می‌کشید که خونده بشه. همه هم که می‌دونیم این تب‌های کروم عزیز با رم سیستم چی کار می‌کنن. یه روز تصمیم گرفتم همه رو ببندم -و البته همین کار رو هم کردم- اما دلم نیومد این یه مقاله رو نخونده ببندم. چند روز دیگه هم بهش مهلت دادم و باز گذاشتمش تا بالاخره امروز تونستم برم سراغش.
مقاله، مقاله کوتاهیه و من هم نمی‌خوام چیز زیادی بهش اضافه کنم (اتفاقا دارم خلاصش هم می‌کنم). آقای فاولر در این مقاله عقیده داره، برای سنجش عملکرد یک تیم نرم‌افزار باید به جای سنجش خروجیِ محض (Output)، مثل تعداد خطوط کد، تعداد User Story انجام شده یا حتی میزان Story Point باید رفت سراغ سنجش چیز مهمتری به نام Outcome. من خیلی خوب نمی‌تونم این کلمه رو ترجمه کنم اما فرقش با output در اینه که outcome به «نتیجه» نگاه می‌کنه. بذارید یه مثال بزنم. تیم نرم‌افزاری الف، در یک مدت کوتاه تونسته به تعداد انگشتان دو دست، فیچرِ دهن‌پر کن روی محصول قرار بده. در مقابل تیم نرم‌افزاری ب، نتونسته این تعداد فیچر رو برسونه. بیاید همه چیز رو برابر بگیریم. مثل اندازه فیچرها، تعداد نفرات یا شرایط عمومی حاکم بر تیم.
خب به نظر تیم الف بهتر از تیم ب کار کرده. اما آقای فاولر میگه یکم دقیق‌تر نگاه کنید. آیا این فیچرها تونستن ارزشی رو برای مشتری یا سازمان خلق کنن؟ آیا تونستن باعث بشن کاربر راحت‌تر با محصول کار می‌کنه؟ فروش بیشتر شده؟ هزینه‌ها کاهش پیدا کردن؟ اگر هیچ‌کدوم از این‌ها اتفاق نیفتاده، نه تنها تیم الف بهتر از تیم ب نبوده بلکه بدتر هم عمل کرده. چون محصول رو با ده تا فیچر ناکارامد و به درد نخور شلوغ کرده و باعث شده بعدن اضافه کردن فیچرهای اساسی و مهم مشکل‌تر بشه. اینجاست که ایشون میگه برای ارزیابی، باید outcome اندازهگیری بشه، نه output.
یه تعریفی که از outcome میاره اینه: outcome باید منجر به تغییر در رفتار کاربر یا مشتری بشه به طوری که این تغییرات نتایج خوبی برای سازمان داشته باشه. outcomeهایی که در ارتباط با ارزش مشتری هستن (مثل ضریب اطمینان ماشین ظرف‌شویی) به outcomeهایی که مربوط به ارزش کسب‌وکار ما هستن (مثل هزینه‌های تعمیرات در مدت گارانتی) اولویت داره.
خب به نظر منطقی میاد. اما بدون چالش هم نیست. چالش اول اینه که یه مقدار ارزیابی outcome سخت به نظر می‌رسه. خیلی اوقات ما با مفهومی مثل «رضایت مشتری» مواجه میشیم که خیلی شهودی به نظر میاد. اما خب یه لحظه صبر کنید. واقعا اندازهگیری output راحته؟ هممون تجربه اندازهگیری بر حسب story point رو داریم. تیم‌ها گاهی به storyهای اسپرینت قبلی خودشون هم story pointهای متفاوت میدن. حالا چه برسه که افراد جدیدی بخوان اون رو انجام بدن (که این نشون میده story point قابلیت تکرار پذیری بالایی نداره). یا مثلا بیاید بگیم که تعداد خطوط کد (LOC) رو بشمریم. به نظر ساده است اما حقیقتا تا حالا تونستید با این همه ابزاری هم که وجود داره اون‌ها رو بشمرید؟ چه کدهایی رو توسعه‌دهنده نوشته؟ کدوم‌ها رو ابزارهای WYSIWYG یا scaffolding ایجاد کردن؟ اما در مقابل همه سازمان‌ها به راحتی می‌تونن نتایج مالی سازمان (outcome) رو محاسبه و ارزیابی کنن!
چالش دیگه مربوط به منطبق کردن outcome به تیم نرم‌افزاریه. خود آقای فاولر یه مثال میزنه. یه تیم کنترل کیفی در یک زنجیره تامین رو در نظر بگیرید که قراره به کمک یک نرم‌افزار، کیفیت کالاها در هر قسمت از زنجیره رو کنترل کنن. اگر تعداد کالاهایی که توسط مشتری نهایی مرجوع میشن رو به عنوان عامل ارزیابی در نظر بگیریم چقدر از تقصیرها گردن تیم نرم‌افزار میفته؟ چقدرش مربوط به روال‌های کنترل کیفی و چقدرش مربوط به اهمال‌کاری اعضای تیم کنترل کیفی میشه؟ الان مثلا از کجا میشه فهمید تغییر زبان برنامه‌نویسی که به تازگی در تیم نرم‌افزاری اتفاق افتاده چقدر موثر بوده؟
به هرحال اون‌طور که از شواهد بر میاد آقای فاولر بر این عقیده است که این مشکلات نباید باعث بشه شما برید سراغ اندازهگیری چیز اشتباه (output). میگن «هرچی رو اندازهگیری کنی همون رو به دست میاری». حتی می‌ارزه اگر بگیم «هرچی رو تلاش کنی اندازهگیری کنی همون رو به دست میاری»! اگر بریم سراغ اندازهگیری چیزهای اشتباه، تیم هم تلاش می‌کنه تا در اون چیزهای اشتباه بهتر و بهتر بشه.
نظر منِ امیر شیبانی اینه که آقای فاولر حرف بسیار درستی میزنه. بازیکن نوک حمله‌ای که نتونه گل بزنه اما چهل هزارتا روپایی بزنه فایده‌ای نداره. اما شاید نشه یک تیم رو فقط از یک جهت ارزیابی کرد. شاید هدف نهاییِ تمام تیم‌های نرم‌افزاری سوددهی یا ایجاد ارزش برای مشتری و کاربر باشه اما همیشه اهداف کوتاه‌مدتش این چیزا نیست. یعنی حتمن یه سری KPI خواهد داشت که قابل ارزیابی با outcome نیستن. شاید باید output و outcome رو با هم سنجید. یک تیم نرم‌افزاری باید در ابعاد مختلف ارزیابی بشه که صددرصد بعضی از این ابعاد نسبت به بعضی‌های دیگه مهم‌ترن. اما نمیشه همیشه تک‌بعدی هم به قضیه نگاه کرد.
منبع:
