دو محور کلیدی نقش مالک محصول در محصول‌های چندتیمی: مدیریت ذی‌نفعان و حفظ تمرکز تیم‌ها

یک مالک محصول، چند تیم اسکرام: الگوی بهینه هدایت بدون مداخله‌گری

این مقاله بر پایه مقاله «Self-organize to Higher Performance» در سازمان اسکرام نوشته شده است که پیشنهاد می‌کنم ترجمه آن را بخوانید.

این مقاله اولین بار در اجایل گپ منتشر شده است و این یک نسخه کپی از آن است.

وقتی چند تیم اسکرام، یک محصول و یک PO دارند

فرض کن سازمان از یک تیم اسکرام رشد کرده و حالا چند تیم اسکرام دارد که همه روی یک محصول مشترک کار می‌کنند؛

• یک Product Owner برای کل محصول،
• یک Product Backlog مشترک،
• چند تیم اسکرام خودگردان که خودشان تصمیم می‌گیرند چه‌کسی روی چه چیزی کار کند و حتی چطور بین تیم‌ها تقسیم شوند.

در این بافتار، اگر PO اشتباه عمل کند و هدف محصول را شفاف‌سازی نکند، بکلاگ مشترک با «آیتم‌های مرتب‌شدهٔ مرتبط با اهداف استراتژیک» نسازد و یا با دخالت کردن در «چگونه ساختن محصول» از خودگردانی تیم حمایت نکند، به‌سرعت همه‌چیز به سمت آشوب رفته و ذینفعان ناامید شده و حمایت خود را کمرنگ می‌کنند که به‌صورت مدیریت از بالا و تخصیص وظایف و … می‌تواند نمود پیدا کند. این شرایط منجر به کشتن بهبود تدریجی،‌ خلاقیت، انعطاف‌پذیری و بهره‌وری تیم خواهد شد.

نقش مالک محصول در اسکرام ۲۰۲۰ در یک جمله

طبق راهنمای اسکرام ۲۰۲۰، مالک محصول مسئول حداکثر کردن ارزش محصول ناشی از کار تیم اسکرام است؛
ابزار اصلی او برای این کار: هدف محصول و بکلاگ محصول.

در این نگاه، مالک محصول مسئول «چیستی» و «چرایی» است،
و تیم‌های خودگردان مسئول «چگونه».

تیم خودگردان اسكرام

یک تیم خود گردان اسكرام بررسی می‌کند که آیا در مسیر درستی قرار دارد یا نه، در صورت خارج شدن از مسیر اقدام می‌کند، خودش تصمیم می‌گیرد که چگونه کار کند، تعارضات درون تیم اسکرام را حل می‌کند، و مشکلات داخلی تیم را برطرف می‌نماید. این به این معناست که، به‌طور کلی، مدیران — حتی اگر در ساختار حضور داشته باشند — نباید به تیم اسکرام بگویند چه کاری انجام دهد یا مشخص کنند کدام عضو تیم باید برای حل یک مشکل جدا شود، چه به‌صورت مستقیم و چه غیرمستقیم. اگر مدیرانی وجود دارند، بهتر است نقش رهبری الهام بخش و نه کنترل‌گر را ایفا کنند.

تعریف بافتار: چند تیم، یک محصول، چالش خودگردانی

در این وضعیت:

• همه تیم‌ها از یک Product Backlog مشترک تغذیه می‌کنند؛
• هر تیم Sprint Backlog خودش را می‌سازد؛
• اسکرام از تیم‌ها انتظار دارد خودشان ساختار و همکاری‌شان را طراحی کنند (چه‌کسی در کدام تیم باشد، چه تیمی کدام بخش محصول را جلو ببرد، و حتی در صورت نیاز خودشان دوباره سازماندهی شوند).

سؤال کلیدی این است:
مالک محصول در چنین شرایطی چطور باید رفتار کند تا هم ارزش محصول حداکثر شود، هم خودگردانی تیم‌ها تضعیف نشود؟

۱. ساختن و نگه‌داشتن «چرا» و «چیستی» مشترک

اولین کمک بزرگ محصول این است که:

• چشم‌انداز (Vision) محصول را به شکلی زنده، ساده و مکرر برای همه تیم‌ها روایت کند؛
• یک هدف محصول شفاف تعریف کند که:
  • چند اسپرینت را پوشش بدهد،
  • و برای همه تیم‌ها، به‌عنوان «نقطه‌ مقصد» مشترک قابل فهم باشد.

این کار باعث می‌شود:

• هر تیم به‌جای طراحی جهان مستقل خودش، بداند به کدام «جهت کلی» حرکت می‌کند؛
• خودگردانی به‌جای هرج‌ومرج، تبدیل به تصمیم‌گیری آگاهانه در یک چارچوب مشترک شود.

مالک محصول رهبر محصول است، نه مدیر کار تیم‌ها.

۲. طراحی بکلاگ برای چند تیم، بدون تبدیل شدن به مدیر پروژه

در این بافتار، بکلاگ محصول باید طوری طراحی شود که:

• آیتم‌ها حول دستاورد یا Outcome و مسئله باشند، نه فقط تسک‌های ریز فنی؛
• برای چند تیم، قابل موازی‌سازی باشد؛ یعنی شکستن آیتم‌ها طوری انجام شود که چند تیم بتوانند هم‌زمان روی ابعاد مختلف یک هدف کار کنند؛
• ترتیب و الویت یا Ordering براساس ارزش، ریسک و یادگیری باشد، نه براساس این‌که «کدام تیم وقت خالی دارد».

نکته ظریف:
مالک محصول نباید بگوید «این آیتم برای تیم A، آن یکی برای تیم B».
او باید:

• اهمیت و منطق هر آیتم را شفاف کند؛
• وابستگی‌های آیتم‌ها را با همکاری تیم‌ها در جلسات پالایش روشن کند؛
• و بعد اجازه بدهد خود تیم‌ها، با توجه به تخصص و ظرفیت‌شان، تصمیم بگیرند چه‌چیزی را بردارند.

اینجاست که خودگردانی روی شانه‌های شفافیت می‌ایستد.

۳. محافظت از خودگردانی: دخالت نکردن در «چگونه»

در مدل اسکرام ۲۰۲۰، تیم‌ها خودگردان یا Self-Managing هستند:
خودشان تصمیم می‌گیرند چه‌کسی روی چه کار کند، چگونه سازمان پیدا کنند، و در صورت نیاز چگونه ساختارشان را تغییر دهند.

در جلسات تیم‌سازی (مثلاً وقتی می‌خواهند از دو تیم به سه تیم تبدیل شوند، یا مسیر کاملاً جدیدی در محصول پیش آمده)، مالک محصول باید:

• فقط جهت محصول، هدف محصول و اولویت‌ها را توضیح دهد؛
• سؤال‌هایی از جنس «آیا این ساختار به شما کمک می‌کند سریع‌تر به هدف محصول برسید؟» مطرح کند؛
• اما از تصمیم‌گیری دربارهٔ ترکیب تیم‌ها، نقش‌گذاری ریز و جا‌به‌جایی افراد، خودداری کند.

مرز حساسی است:
اگر مالک محصول از نقش واقعیش به «مدیر منابع انسانی تیم‌ها» تبدیل شود،
خودگردانی در همان لحظه خفه می‌شود.

۴. ساختن یک چرخهٔ تجربه‌گرایی مشترک برای همه تیم‌ها

در بافتار چند تیمی، Sprint Review یا نقد اسپرینت و بازخورد محصولی، اگر خوب طراحی نشود، به چند دموی پشت سر هم تبدیل می‌شود که هیچ‌کس در آن «تصویر کلی» را نمی‌بیند.

اینجا مالک محصول باید:

• برای محصول دستاوردهای قابل اندازه‌گیری تعریف کند (زمان تحویل، رضایت مشتری، کاهش خطا و…)،
• Sprint Review را حول این سؤال ببندد:
  • «در این اسپرینت، مجموع کار این چند تیم چه تغییری در محصول و نتایج مشتری ایجاد کرد؟»
• بازخورد مشتری و ذی‌نفعان را به هدف محصول و ترتیب بکلاگ برگرداند.

وقتی تیم‌ها به‌طور منظم:

• نتیجه‌ کار مشترک‌شان را می‌بینند،
• داده‌های واقعی را لمس می‌کنند،
• و اثر تصمیم‌های خودشان را روی محصول حس می‌کنند،

خودشان هم لحظه‌ نیاز به تغییر ساختار، تمرکز یا شیوه‌ همکاری را تشخیص می‌دهند؛
و آن‌جا است که خودگردانی به بلوغ می‌رسد: تیم‌ها بدون دستور از مدیریت یا ذینفعان کلیدی در رترو یا نقد اسپرینت تصمیم به تیم‌سازی دوباره‌ می‌گیرند.

۵. مدیریت ذی‌نفعان و محافظت از فضای تمرکز تیم‌ها

وقتی چند تیم روی یک محصول واحد کار می‌کنند، ذی‌نفعان (واحدها، مدیران، مشتریان داخلی) عادت دارند:

• به‌دنبال «تیم خودشان» بگردند؛
• افراد «قوی‌تر» را برای نیازهای خودشان جذب کنند؛
• و هر کدام هدف محصول خودشان را تعریف کنند.

نقش مالک محصول در این‌جا حیاتی است:

• درگاه واحد ورود درخواست‌ها به بکلاگ محصول باشد؛
• همه ذی‌نفعان را به زبان هدف محصول و ارزش مشترک برگرداند؛
• اجازه ندهد فشارهای متناقض، مستقیم و پراکنده، تمرکز تیم‌ها را بشکند.

مالک محصول این‌جا هم‌زمان:

• نماینده محصول نزد ذی‌نفعان است،
• و محافظ تیم‌ها در برابر فشارهای ناهم‌سو با ریتم خودگردان توسعه تیم‌ها.

۶. هم‌صدایی با Scrum Masterها، به‌جای تصاحب نقش آن‌ها

در این بافتار، اسکرام مستر مسئول است:

• چارچوب‌های خودگردانی را تعریف و حفظ کنند؛
• جلسات خودسازماندهی و رترو را تسهیل کنند؛
• به تیم‌ها کمک کنند واقعا تجربه‌گرا و خود گردان بمانند.

اگر مالک محصول بخواهد هم‌زمان نقش اسکرام مستر را هم بازی کند، توازن به هم می‌خورد.
به‌جای آن، باید با اسکرام مستر ائتلافی شفاف بسازد:

• مالک محصول: تمرکز بر «ارزش، هدف محصول و بکلاگ»،
• اسکرام مستر: تمرکز بر «فرآیند، بهره‌وری تیم‌ها و خودگردانی».

جمع‌بندی: مالک محصول به‌عنوان معمار ارزش و فضای خودگردانی

در محیطی که:

• چند تیم اسکرام یک محصول مشترک را توسعه می‌دهند،
• همه از یک Product Backlog تغذیه می‌کنند،
• و از آن‌ها انتظار می‌رود خودگردان واقعی را تمرین کنند،

مالک محصول بیش از آن‌که «مدیر کار» باشد، معمار دو چیز است:

1. معمار ارزش
   • با هدف محصول شفاف،
   • بکلاگ مشترک مرتب‌شده بر اساس ارزش،
   • و چرخه‌ تجربه‌گرایی که نتایج را مرتب به تصمیم‌های بعدی متصل می‌کند.
2. معمار فضای خودگردان
   • با پرهیز آگاهانه از دخالت در How و ترکیب تیم‌ها،
   • حفاظت از تیم‌ها در برابر فشارهای پراکنده‌ ذی‌نفعان،
   • و همکاری نزدیک با اسکرام مسترها برای ساختن فرایندی که تیم‌ها در آن بتوانند خودشان ساختار، تمرکز و روش کارشان را تنظیم کنند.

وقتی مالک محصول این دو نقش را با ظرافت نگه دارد، چند تیم روی یک محصول، به‌جای رقابت و آشوب، تبدیل می‌شوند به یک سیستم زنده‌ یادگیرنده که می‌تواند:

• خود را مطابق با تغییر اولویت‌ها دوباره سازماندهی کند،
• و در عین حال، ارزش محصول را به شکلی قابل اندازه‌گیری افزایش دهد.

این‌جا است که اسکرام از «یک چارچوب جلسات» به شیوه‌ کار و فکر کردن تبدیل می‌شود.