ویرگول
ورودثبت نام
آرتا مکبری
آرتا مکبریصاحب محصول و اجایل کوچ
آرتا مکبری
آرتا مکبری
خواندن ۶ دقیقه·۲ ماه پیش

مدیریت ذی‌نفعان در اسکرام: از «چرایی» تا یک برنامهٔ پایدار برای در جریان نگه‌داشتن همه

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

در مقاله از ترجمه «فرآورده» برای «Increment» یا تکه‌محصول نهایی اسپرینت که DOD است، استفاده شده است.

مدیریت ذی‌نفعان چیست و چرا در اسکرام مهم است؟

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

چه چیزهایی در اسکرام ذی‌نفعان را «مطلع» نگه می‌دارد؟

۱) اسپرینت ریویو: صحنهٔ اصلی مشارکت

اسپرینت ریویو رویدادی مشارکتی است؛ در آن، اسکرام تیم «فرآورده انجام‌شده» را نشان می‌دهد، با ذی‌نفعان گفتگو می‌کند و بک‌لاگ محصول را بر اساس یادگیری‌ها سازگار می‌نماید. ریویو «دادگاهِ تأیید/رد» توسط PO یا صرفاً «دمو» نیست؛ محل تصمیم مشترک دربارهٔ «گام بعدی» است. نمایش کارِ ناتمام در ریویو باعث سوءبرداشت و انتظارات غلط می‌شود.

نکتهٔ مهم: انتشار ارزش می‌تواند قبل از ریویو هم رخ دهد؛ ریویو «دروازهٔ انتشار» نیست.

۲) مصنوعات شفاف و «DOD» شفاف

  • بک‌لاگ محصولِ شفاف (هدف محصول، اقلام، ترتیب) منبع واحد حقیقت است و باید برای مشاهدهٔ ذی‌نفعان قابل‌دسترس باشد.

  • تنها تکه‌محصولی یک Increment یا فرآورده است که با تعریف Done یا سند مکتوب DOD» همخوان باشد؛ همین شفافیت از سوء‌تفاهم دربارهٔ وضعیت کار جلوگیری می‌کند.

۳) نقش‌ها؛ چه کسی چه می‌کند؟

  • Product Owner نمایندهٔ نیازهای بسیاری از ذی‌نفعان است، بک‌لاگ را شفاف و مرتب (Ordered) نگه می‌دارد و ارزش را بیشینه می‌کند.

    • «Ordering» یعنی چیدنِ آیتم‌ها در ترتیبِ یگانه‌ای که نشان می‌دهد «بعدی‌ها کدام‌اند». این چیدمان می‌تواند بر پایه‌ ارزش، ریسک، وابستگی، اندازه و… باشد، اما خروجی‌اش یک لیست مرتب‌شده است که تیم بداند دقیقاً چه چیزهایی جلوترند.

  • Scrum Master تسهیلگر تجربه‌گرایی و همکاری با ذی‌نفعان (به‌درخواست/نیاز) است و اطمینان می‌دهد رویدادها مؤثر و در تایم‌باکس بمانند.

  • Developers فرآورده «Done» را ارائه می‌کنند و دربارهٔ ریسک‌ها/محدودیت‌های فنی شفاف‌اند — کلید اعتماد ذی‌نفعان.

ضدالگوهای رایج (و چرا خطرناک‌اند)

  • حذف ذی‌نفعان از ریویو: نبود بازخورد واقعی باعث حرکت محصول در مسیر غلط و قضاوت «اسکرام کار نمی‌کند» می‌شود.

  • ریویوِ «قاضی‌محور» توسط PO: نشانهٔ کمبود ارتباط مستمر و کاشت بذر کینه در تیم است؛ بازبینی باید گفت‌وگوی مشترک شکل دهد.

  • نمایش کارِ ناتمام: ذی‌نفعان برداشت اشتباه می‌کنند و بعد از انتشار ناامید می‌شوند—اعتماد می‌ریزد.

یک «برنامهٔ همیشگیِ ساده» برای مدیریت ذی‌نفعان

هدف: سبک‌وزن، منطبق با راهنمای ۲۰۲۰، قابل اجرا در هر محصول.


الف) شناسایی و بخش‌بندی

با PO یک کارگاه ۶۰ دقیقه‌ای برگزار کنید:

  1. همهٔ ذی‌نفعان محتمل را طوفان‌فکری کنید (بودجه‌دهندگان، واحدهای درگیر، کاربران کلیدی، پشتیبانی، عملیات، رگولاتوری و…).

  2. هر نفر را در یکی از سه دسته بگذارید: الزامی برای ریویو / در جریان بمانند / رصد شوند.
    این دسته‌بندی را هر چند اسپرینت یک‌بار بازبینی کنید؛ ترکیب ذی‌نفعان در طول عمر محصول تغییر می‌کند.

پرسش‌های محرک برای کشف ذی‌نفعان پنهان: پول از کجا می‌آید؟ چه کسی کار/فرآیندش تغییر می‌کند؟ چه کسی اگر مطلع نباشد عصبانی می‌شود؟

ب) قرارداد شفافیت و کانال‌ها

  • منبع واحد حقیقت: لینک مشاهدهٔ بک‌لاگ محصول + هدف محصول برای ذی‌نفعان.

  • تعریف Done عمومی (یک پاراگراف + چک‌لیست) تا همه بدانند «کامل» یعنی چه؛ هر ریترو آن را بهتر کنید.

  • کادنس ارتباطی:

    • اسپرینت ریویو (الزامی‌ها حضور، دعوت باز برای بقیه).

    • One-Pager پساریویو: هدف اسپرینت، چه «Done» شد، تصمیم‌های کلیدی، اثر بر بک‌لاگ/هدف محصول.

    • دمو/رهاسازی بین‌اسپرینتی وقتی فرآورده آمادهٔ انتشار است.

پ) ریتم و انتظارات روشن

  • طول اسپرینت را طوری تعیین کنید که تیم و ذی‌نفعان بتوانند به‌صورت سالم تا بازخورد بعدی صبر کنند (نه کوتاهِ مختل‌کننده، نه بلندِ کم‌ارتباط). اسپرینت «ضربان» اطلاع‌رسانی است.

  • دعوت‌نامهٔ ریویو شامل هدف محصول/اسپرینت، لینک بک‌لاگ و ۲ سؤال: «چه چیزی تغییر کند؟ چه ادامه یابد؟».

ت) نقش‌ها و تعهدات

  • PO: مالک نقشهٔ ذی‌نفعان، اطمینان از حضور درست در ریویو، و به‌روزرسانی بک‌لاگ بر اساس بازخورد.

  • SM: تسهیل همکاری با ذی‌نفعان، مثبت و مؤثر نگه‌داشتن رویدادها، زدودن موانع سازمانی.

  • Developers: ارائهٔ و شفاف‌سازی ریسک/کیفیت.

ث) سنجه‌های سادهٔ موفقیت

  • حضور و تنوع ذی‌نفعان در ریویو.

  • بازخوردهای اعمال‌شده (اقلام بک‌لاگ که منشأشان ریویو است).

  • شگفتی صفر: غافلگیری ذی‌نفع/PO در ریویو به سمت صفر میل کند. (این‌ها سنجه‌های «کیفیّتِ همکاری»اند، نه خروجی‌محورِ صرف).

تاکتیک‌های کاربردی برای ارتباطات روزمره

  • ۳۰ دقیقه «ساعت مشاورهٔ PO» در هفته برای پرسش‌های خارج از ریویو؛ به کاهش ایمیل‌های پراکنده کمک می‌کند. (همسو با نقش PO و شفافیت جریان کار).

  • نشانگر «آماده برای بازخورد» در برد: هر زمان بخشی از کار به کیفیت Done نزدیک شد، یک بازدید آد-هوک با ذی‌نفع مرتبط بگیرید. (شفافیت + یادگیری زودهنگام).

  • قواعد ساده برای خبرنامهٔ پساریویو: یک صفحه، بدون KPIهای وَنمودی؛ فقط ارزش تحویلی، ریسک‌ها، تصمیم‌ها و «بعدی چیست؟»

ساختار پیشنهادی یک‌صفحهٔ پساریویو

(کپی/پیست کنید و هر اسپرینت پرش کنید)

1. هدف اسپرینت (۱ خط): چرا این اسپرینت را انجام دادیم؟ (همسو با Sprint Goal).

2. ارزش تحویلی (۳–۵ گلوله): چه چیزی «Done و قابل‌استفاده» شد و برای کدام کاربر/شاخصِ نتیجه چه اثری دارد؟ (از «ویژگی‌ها» به «نتایج» ترجمه کنید).

3. شواهد/یادگیری‌ها (۱–۳ نکته): بازخورد کاربر/بازار، داده‌های استفاده، فرضیه‌هایی که رد/تأیید شد. (ورودی سازگاری بک‌لاگ).

4. ریسک‌ها و وابستگی‌های فعال (حداکثر ۳): چه چیزهایی بر ارزش/برنامهٔ انتشار اثر می‌گذارد و مالک ریسک کیست؟

5. تصمیم‌های کلیدی این ریویو: چه تصمیم‌هایی با ذی‌نفعان گرفته شد و چرا (مثلاً تغییر اولویت، توقف/آغاز ابتکار).

6. «بعدی چیست؟» (Next): مهم‌ترین تغییرات در بک‌لاگ/هدف محصول و تمرکز اسپرینت بعد. لینک به بک‌لاگ شفاف.

7. مخاطبان و اقدام‌ها: چه کسی باید چه کاری انجام دهد و تا کی؟ (Assigned → Due).

نکته: اگر چیزی «Done» نیست، اینجا نیاورید؛ نمایش یا گزارش کار نیمه‌کاره شفافیت را مخدوش می‌کند.

مدیریت ریسک «انتظارات»: فقط Done را نشان دهید

تلاش برای «خشنودسازی کوتاه‌مدت» با نمایش کار نیمه‌کاره، دیر یا زود به بدفهمی و بی‌اعتمادی ختم می‌شود. اصل طلایی: در ریویو فقط کار Done را نشان دهید؛ اگر چیزی به انتشار نرسید، صادقانه دلایل را توضیح دهید و اثرش بر هدف محصول/اسپرینت را شفاف کنید.

اگر زمینهٔ شما «پیچیده» است، چگونه برنامه را پیاده کنید؟ (Cynefin)

تعامل با ذی‌نفعان معمولاً پیچیده است؛ پاسخ درست از دلِ آزمایش‌های کوچک و بازخورد بیرون می‌آید، نه نسخهٔ همگانی. پیشنهاد چند آزمایش کم‌هزینه برای دو اسپرینت آینده:

  1. دو سؤال ثابت در ریویو (۵ دقیقه پایانی): «چه ارزشی واقعاً دریافت شد؟» و «اگر یک چیز را تغییر دهیم، چیست؟» → موفقیت = افزایش اقلامِ ناشی از بازخورد در بک‌لاگ.

  2. بازبینی فهرست ذی‌نفعان هر ۳ اسپرینت با سه‌دسته‌بندی فوق → موفقیت = کاهش «شگفتی» در ریویو.

  3. کارت «سیگنال ریسک» روی برد برای اعلان سریع مواردی که ممکن است به نادانیِ ذی‌نفعان بینجامد (مثلاً وابستگی بیرونی) → موفقیت = مکالمات زودهنگام‌تر با ذی‌نفع مرتبط.

چک‌لیست سریع اجرا

  • ذی‌نفعان را شناسایی و در سه دسته بخش‌بندی کرده‌ایم.

  • بک‌لاگ محصول و هدف محصول برای مشاهدهٔ ذی‌نفعان در دسترس است.

  • تعریف Done مشترک داریم و در ریترو تکاملش می‌دهیم.

  • دعوت‌نامهٔ ریویو شامل هدف/لینک/پرسش‌های راهنما است.

  • بعد از ریویو یک One-Pager می‌فرستیم (ارزش تحویلی، تصمیم‌ها، «بعدی چیست»).

  • فقط کار Done را نشان می‌دهیم؛ بدون «دموی امیدبخش» برای کار نیمه‌کاره.

جمع‌بندی

  • هدف مدیریت ذی‌نفعان در اسکرام: تقویت چرخهٔ تجربه‌گرایی از طریق شفافیتِ مصنوعات، ریویوی مشارکتی، و فرآورده‌های DOD شده.

  • نقش‌ها روشن‌اند: PO نمایندهٔ نیازهای بسیاری از ذی‌نفعان و مالک بک‌لاگ؛ SM تسهیل‌گر همکاری و تجربه‌گرایی؛ Developers ارائه‌دهندهٔ فرآورده DOD شده و شفافیت فنی.

  • برنامهٔ همیشگی: شناسایی/بخش‌بندی، قرارداد شفافیت، کادنس ثابت، نقش‌های روشن، سنجه‌های ساده—و چون زمینه پیچیده است، آن را با آزمایش‌های کوچک تنظیم کنید.

موفقیتمدیریت ذینفعان
۴
۰
آرتا مکبری
آرتا مکبری
صاحب محصول و اجایل کوچ
شاید از این پست‌ها خوشتان بیاید