چندی پیش داشتم فصل اول کتاب Facilitating Professional Scrum Teams رو مرور میکردم. چیزی که برام جالب بود، این بود که نویسنده چطور بدون پیچیدگی، روی سه موضوع کلیدی برای ساختن یک تیم اسکرامی واقعی تمرکز کرده بود—سه موضوعی که خیلی وقتها در عمل، از قلم میافتن.
فرض کنید یک تیم قراره با هم قایقسواری کنن. اگر هر کسی پاروی خودش رو بهتنهایی بزنه، قایق شاید حرکت کنه، ولی نه هماهنگ، نه سریع، و نه به مقصد درست. حالا اگه قبلش با هم به توافق برسن که کی سکان رو بگیره، کی ریتم رو تنظیم کنه و کی مسئول سرعت باشه، احتمال اینکه با انرژی کمتر، نتیجهی بهتری بگیرن خیلی بیشتره.
توی تیمهای اسکرامی هم همین قاعده صادقه. تیمهایی که قراره در محیطی پیچیده و تغییرپذیر کار کنن، فقط با داشتن تسکبرد و برگزاری رویدادهای اسکرام، تیم نمیشن. این فصل به سه موضوعی میپردازه که پایهی ساختن تیمهای واقعی هستن—پایههایی که نبودشون باعث میشه خروجی تیم، هم کند بشه و هم ناهماهنگ.
۱. توافق، قبل از هر اقدامی
تیم بودن یعنی فراتر رفتن از همکاری ساده. یعنی تعریف کردن روابط کاری، انتظارات، و حتی نوع تعامل در لحظات تنش. توافقنامهی تیمی (Team Working Agreement) شاید در ظاهر فقط چند خط روی یک تخته باشه، ولی در عمل نقش راهنمای رفتاری تیم رو داره.
وقتی تیمی در ابتدای مسیرش برای نوع تصمیمگیری، نحوه بازخورد دادن، یا نحوه ورود به گفتوگوهای دشوار با هم توافق کنه، در واقع برای خودش حاشیهی امن میسازه. نه از نوع امنیت روانی کلیشهای، بلکه یک چارچوب مشخص که وقتی اختلافی پیش اومد، بتونن بهش برگردن و بگن: «ما قبلاً در موردش به این توافق رسیدیم.»
این توافقنامه قرار نیست ثابت بمونه. مثل کد نرمافزار، گاهی باید ریفکتور بشه. اما اصل ماجرا اینه که تیمی که در مورد رابطهها و تعاملاتش حرف نزده، سخت میتونه عملکرد هماهنگ و پایداری داشته باشه.
۲. هدف، نه فقط برای مدیر محصول
برخلاف «Sprint Goal» که برای یک بازهی کوتاهمدت طراحی شده، Product Goal مثل چراغ دریاییه؛ چیزی که به کل تیم جهت میده. داشتن یه Product Goal مشخص کمک میکنه تیم بدونه که هر تصمیم، هر اولویتبندی، و حتی هر مکثی، باید به چه چیزی خدمت کنه.
برای مثال، اگه هدف تیم «افزایش نرخ بازگشت کاربران» باشه، حتی انتخاب بین دو فیچر که هر دو مفید به نظر میان، با نگاه به این هدف راحتتر میشه. این وضوح، فقط برای مدیر محصول نیست؛ باید به بخشی از DNA کل تیم تبدیل بشه. وقتی توسعهدهندهها، طراح، و تستر هم این هدف رو بدونن، اتفاقهای بهتری توی جزئیات تصمیمگیریها میافته.
۳. ذینفع، فقط کسی نیست که جلسه میاد
یکی از مهمترین نکاتی که نویسنده بهش اشاره میکنه، اینه که تعامل با ذینفعان نباید فقط محدود به جلسات رسمی مثل Sprint Review باشه. شفافیت واقعی زمانی اتفاق میافته که تیم و ذینفعان در طول مسیر با هم در ارتباط باشن، نه فقط در ایستگاههای از قبل تعیینشده.
خیلی وقتها ذینفعان واقعی پروژه، کسانی هستن که مستقیماً روی تصمیمات روزانه اثر نمیذارن، اما خروجی تیم رو استفاده میکنن یا ازش تأثیر میگیرن. کاربر نهایی، تیم پشتیبانی، تیم بازاریابی، یا حتی فروش، همه میتونن نقش مهمی داشته باشن. اگر این افراد دیده نشن، تیم ممکنه در خلأ تصمیم بگیره و بعداً با بازخوردهایی روبهرو بشه که جهتگیری کل محصول رو زیر سوال ببرن.
ایجاد تعامل منظم، دعوت به بازخورد غیررسمی، و حتی مشارکت دادن بعضی از این ذینفعان در جلسات بازبینی یا Refinement، کمک میکنه محصولی ساخته بشه که فقط خوب کار نمیکنه، بلکه برای کسانی که استفادهاش میکنن هم واقعاً ارزشمنده.
جمعبندی
این سه مورد—توافق در تعاملات تیمی، هدف روشن برای کل مسیر، و تعامل واقعی با ذینفعان—شاید ساده به نظر بیان، ولی دقیقاً چیزهایی هستن که نبودشون در تیمهای زیادی باعث فرسایش، ابهام و دوبارهکاری میشه.
توی دنیای پیچیدهی امروز که سرعت تغییر زیاده و تمرکز سخته، داشتن این سه پایه کمک میکنه تیم بتونه هم با سرعت حرکت کنه و هم با معنا. چون همونطور که در قایقرانی دیدیم، هماهنگی، حتی از قدرت عضلات هم مهمتره.
