اولین چیزی که معمولا به ذهن همه ما میرسد این است که: حجم کار باقی مانده در بک لاگ محصول را بر میانگین velocity تقسیم کنیم و یک تاریخ قطعی ارائه می‌دهیم. مثلا: «بر اساس میانگین ۲۰ story point در هر اسپرینت، این پروژه ۱۰۰ پوینتی در ۵ اسپرینت تمام می‌شود.» و درست در همین لحظه، واقعیت از راه می‌رسد. یک برنامه نویس کلیدی بیمار می‌شود. یک باگ غیرمنتظره خودش را نشان می‌دهد. یکی از نیازمندی‌ها پیچیده‌تر از چیزی بود که فکر می‌کردیم. ناگهان، پیش‌بینی «۵ اسپرینتی» ما، بیشتر شبیه یک حدس خوش‌بینانه به نظر می‌رسد تا یک تخمین مبتنی بر داده که حالا باید پاسخگوی آن نیز باشیم.

مشکل اینجاست که تخمین تک‌نقطه‌ای (single-point estimate) اکثرا به ما دروغ می‌گویند. این نوع تخمین زدن، مهم‌ترین واقعیت کار ما را نادیده می‌گیرد: تغییرپذیری (variability).

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

Monte Carlo Simulation یا شبیه سازی مونت کارلو چیست؟ تصور کنید توانایی تیم شما در انجام کارها، مانند یک تاس خاص و چندوجهی است. روی هر وجه این تاس، به جای اعداد ۱ تا ۶، عددی نوشته شده که نشان‌دهنده حجم کاری است که تیم شما واقعاً در یکی از اسپرینت های گذشته انجام داده است. عملکرد واقعی و تاریخی شما – با تمام روزهای خوب، بد و معمولی- در این تاس گنجانده شده است.

بیایید این موضوع را با یک مثال عملی بررسی کنیم.

سناریو: «پروژه ققنوس»

• هدف: ما باید «پروژه ققنوس» را که ۸۵ استوری پوینت کار باقیمانده دارد را تحویل دهیم.
• سؤال: «چند اسپرینت طول می‌کشد تا پروژه تمام شود؟»
• داده‌های ما: ما به عملکرد تیم در ۱۰ sprint گذشته نگاه می‌کنیم. این تاریخچه ماست:
  • تعداد استوری پوینتهایی که تیم ما در هر اسپرینت تکمیل کرده، به این صورت بوده است: { 18, 25, 15, 21, 23, 12, 19, 28, 17, 20 }

این مجموعه اعداد، همان «تاس» مخصوص ماست. به تغییرپذیری دقت کنید. ما یک اسپرینت عالی با ۲۸ پوینت و یک اسپرینت سخت با تنها ۱۲ پوینت داشته‌ایم. میانگین حدود ۲۰ است، اما استفاده از میانگین به تنهایی، این حقیقت مهم را پنهان می‌کند.

حالا، بیایید از مونت کارلو برای پیش‌بینی آینده استفاده کنیم.

مرحله ۱: اجرای یک شبیه‌سازی (یک بار انداختن تاس)

ما قصد داریم یک آینده احتمالی را برای پروژه ققنوس شبیه‌سازی کنیم. برای این کار، در هر اسپرینت «تاس می‌اندازیم» (یعنی به صورت تصادفی یک عدد از مجموعه داده‌هایمان انتخاب می‌کنیم) و آن را از کل کار باقیمانده کم می‌کنیم.

• Sprint 1: تاس را می‌اندازیم و عدد ۲۱ می‌آید.
  • کار باقیمانده: ۸۵ – ۲۱ = ۶۴ پوینت.
• Sprint 2: دوباره تاس می‌اندازیم و ۱۵ می‌آید. (یک اسپرینت کندتر)
  • کار باقیمانده: ۶۴ – ۱۵ = ۴۹ پوینت.
• Sprint 3: دوباره می‌اندازیم و ۲۸ می‌آید. (یک اسپرینت فوق‌العاده!)
  • کار باقیمانده: ۴۹ – ۲۸ = ۲۱ پوینت.
• Sprint 4: دوباره می‌اندازیم و ۱۹ می‌آید.
  • کار باقیمانده: ۲۱ – ۱۹ = ۲ پوینت
• Sprint 5: دوباره تاس می‌اندازیم. هر عددی که بیاید کار را تمام می‌کند.
  • کار باقیمانده: ۰.
• در این یک واقعیت شبیه‌سازی‌شده، پروژه ۵ اسپرینت طول کشید.

اما اگر یک دور بدشانسی می‌آوردیم چه؟ یا یک دوره خوش‌شانسی مطلق؟ آن یک نتیجه به تنهایی کافی نیست تا سرنوشت پروژه را به آن گره بزنیم.

مرحله ۲: تکرار این بازی برای ۱۰,۰۰۰ بار

اینجاست که کامپیوتر کار سنگین را برای ما انجام می‌دهد. یک شبیه ساز مونت کارلو این بازی ساده را بارها و بارها تکرار می‌کند:۱۰,۰۰۰ بار، ۵۰,۰۰۰ بار یا حتی بیشتر. هر بار، به صورت تصادفی از داده‌های تاریخی شما نمونه‌برداری می‌کند و ثبت می‌کند که چند اسپرینت طول کشید تا ۸۵ پوینت تکمیل شود.

پس از اجرای هزاران شبیه‌سازی، ما به مجموعه‌ای غنی از نتایج احتمالی دست پیدا می‌کنیم.

مرحله ۳: تحلیل هزاران نتیجه

کامپیوتر حالا لیستی از ۱۰,۰۰۰ پاسخ مختلف را به ما می‌دهد. این لیست ممکن است چیزی شبیه به این باشد:

• پروژه در ۳ اسپرینت تمام شد: ۵۰۰ بار
• پروژه در ۴ اسپرینت تمام شد: ۲,۵۰۰ بار
• پروژه در ۵ اسپرینت تمام شد: ۴,۵۰۰ بار
• پروژه در ۶ اسپرینت تمام شد: ۱,۸۰۰ بار
• پروژه در ۷ اسپرینت تمام شد: ۷۰۰ بار

از نظر بصری، این نتایج اغلب شبیه به یک هیستوگرام نمایش داده می‌شوند، که در آن بلندترین ستون، محتمل‌ترین نتیجه را نشان می‌دهد.

این نمودار به تنهایی بسیار مفیدتر از یک عدد است! ما می‌توانیم ببینیم که اتمام پروژه در ۵ محتمل‌ترین حالت است، اما ۴ و ۶ sprint هم کاملاً امکان‌پذیر هستند.

مرحله ۴: تبدیل نتایج به احتمالات

در این مرحله ما این شمارش‌ها را به احتمالات تبدیل می‌کنیم. از داده‌ها می‌پرسیم: «چند درصد از شبیه‌سازی‌ها در X اسپرینت یا کمتر به پایان رسیدند؟»

• اتمام در ۳ اسپرینت یا کمتر: ۵۰۰ / ۱۰,۰۰۰ = ۵٪ شانس
• اتمام در ۴ اسپرینت یا کمتر: (۵۰۰ + ۲,۵۰۰) / ۱۰,۰۰۰ = ۳۰٪ شانس
• اتمام در ۵ اسپرینت یا کمتر: (۳,۰۰۰ + ۴,۵۰۰) / ۱۰,۰۰۰ = ۷۵٪ شانس
• اتمام در ۶ اسپرینت یا کمتر:(۷,۵۰۰ + ۱,۸۰۰) / ۱۰,۰۰۰ = ۹۳٪ شانس
• اتمام در ۷ اسپرینت یا کمتر:(۹,۳۰۰ + ۷۰۰) / ۱۰,۰۰۰ = ۱۰۰٪ شانس

حالا به چیزی که در دست دارید نگاه کنید. شما یک سؤال ساده را به یک پیش‌بینی قدرتمند و مبتنی بر داده تبدیل کرده‌اید.

گفتگوی جدیدی که می‌توانید آغاز کنید

به جای ارائه یک تاریخ قطعی و شکننده، که باعث ایجاد انتظارات غیر واقعی بشود، می‌توانید با اطمینان وارد جلسه با ذی‌نفعان شوید و بگویید:

• «ما عملکرد واقعی تیم را در ۱۰ اسپرینت گذشته تحلیل و هزاران شبیه‌سازی را اجرا کردیم. بر اساس این داده‌ها:
  • ما با اطمینان ۷۵٪ می‌توانیم بگوییم پروژه ققنوس در ۵ اسپرینت یا کمتر به پایان می‌رسد.
• اگر بخواهیم یک ذره محتاطانه عمل کنیم (مثلا به مشتری بیرونی میخواهیم یک زمان بدهیم)، با اطمینان ۹۳٪ پروژه در ۶ اسپرینت یا کمتر تمام خواهد شد.»
• نکته کلیدی: معمولا سطح اطمینان بالا (مثلا ۹۰ درصد) زمانی استفاده می شود که با دینفعان بیرونی تعامل دارید و بهتر هست زمانی که ارایه میدهید محتاطانه باشد چرا که هزینه ناامید کردن آنها معمولا زیاد است.

این رویکرد، بازی را کاملاً تغییر می‌دهد. چرا؟

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

۲. قابل دفاع است: وقتی کسی پیش‌بینی شما را به چالش می‌کشد، می‌توانید بگویید: «این نظر شخصی من نیست. این یک پیش‌بینی آماری بر اساس عملکرد اثبات‌شده تیم ماست.»

۳. تصمیم‌گیری بهتر را ممکن می‌سازد: بحث از «آیا این تاریخ درست است یا غلط؟» به «ما با چه سطحی از ریسک راحت هستیم؟» تغییر می‌کند. اگر شانس ۷۵٪ برای یک ددلاین مهم کافی نیست، کسب‌وکار می‌تواند یک گفتگوی معنادار درباره کاهش دامنه کار یا تخصیص منابع بیشتر برای افزایش قطعیت داشته باشد.

۴. انجام آن به طرز شگفت‌آوری ساده است: نیازی به داشتن دکترای آمار ندارید. بسیاری از ابزارهای Agile (پلاگین‌های Jira، ActionableAgile، Kanbanize) این قابلیت را به صورت داخلی دارند. حتی می‌توانید یک نسخه ساده از آن را در یک اکسل بسازید.

بخش دوم: اما اگر تیم ما از Story Point استفاده نکند چه؟

مثال «پروژه ققنوس» که با استوری پوینت بررسی کردیم، بسیار قدرتمند بود. اما یک سؤال مهم پیش می‌آید: «تیم ما با Story Point کار نمی‌کند، یا تخمین‌های ما چندان دقیق نیست. آیا ما نمی‌توانیم از این روش استفاده کنیم؟»

خبر خوب این است که شما مطلقاً به Story Point نیاز ندارید. قدرت شبیه سازی مونت کارلو در واحد اندازه‌گیری شما نیست؛ بلکه در استفاده از داده‌های تاریخی و واقعی شماست. شما می‌توانید به جای تخمین زدن، فقط بشمارید. اینجاست که مفهومی به نام Throughput وارد می‌شود.

Throughput: هنر شمردن کارهای انجام‌شده

Throughput به ساده‌ترین شکل ممکن، یعنی تعداد کارهایی که تیم در یک بازه زمانی مشخص (مثلاً یک هفته یا یک sprint) به پایان می‌رساند.

این کارها می‌توانند User Story، تسک، باگ یا هر آیتم کاری دیگری باشند. شما دیگر نگران این نیستید که یک آیتم “۵ پوینتی” است یا “۸ پوینتی”. فقط می‌پرسید: «آیا تمام شد؟ بله یا خیر.» و در پایان بازه زمانی، تعداد آیتم‌های تمام‌شده را می‌شمارید.

بیایید ببینیم این رویکرد در عمل چگونه کار می‌کند.

سناریو جدید: «پروژه عقاب»

• هدف: ما باید «پروژه عقاب» که شامل ۴۰ آیتم کاری (User Story و تسک) در بک لاگ است را تحویل دهیم.
• سؤال:«چند هفته طول می‌کشد تا این پروژه تمام شود؟»
• داده‌های ما: این بار به جای شمارش استوری پوینت، تعداد آیتم‌هایی که تیم در ۱۰ هفته گذشته تکمیل کرده را بررسی می‌کنیم.
  • Throughput هفتگی تیم ما به این صورت بوده است: `{ 5, 8, 4, 7, 5, 9, 6, 8, 4, 6 }`

این مجموعه اعداد، «تاس» جدید ما برای پیش‌بینی است. هر وجه این تاس، نماینده تعداد کارهایی است که تیم در یک هفته معمولی به پایان رسانده است. همانطور که می‌بینید، یک هفته عالی با ۹ آیتم و هفته‌های کندتر با ۴ آیتم داشته‌ایم.

حالا، دوباره بازی Monte Carlo را اجرا می‌کنیم.

اجرای شبیه‌سازی با Throughput

روند دقیقاً مانند قبل است:

1. یک شبیه‌سازی: کامپیوتر به صورت تصادفی از داده‌های Throughput ما نمونه‌برداری می‌کند. مثلاً هفته اول `۷`، هفته دوم `۴`، هفته سوم `۹` و… این کار را آنقدر ادامه می‌دهد تا مجموع آیتم‌ها به ۴۰ برسد و تعداد هفته‌های مورد نیاز را ثبت می‌کند.
2. هزاران شبیه‌سازی: کامپیوتر این بازی را ۱۰,۰۰۰ بار تکرار می‌کند و نتایج هزاران آینده ممکن را جمع‌آوری می‌کند.
3. تبدیل به احتمالات: در نهایت، نتایج به صورت احتمالات به ما ارائه می‌شود. مثلاً خروجی شبیه‌سازی برای «پروژه عقاب» ممکن است به این شکل باشد:

• اتمام در ۴ هفته یا کمتر: ۱۰٪ شانس
• اتمام در ۵ هفته یا کمتر:۴۵٪ شانس
• اتمام در ۶ هفته یا کمتر:۸۵٪ شانس
• اتمام در ۷ هفته یا کمتر:۹۸٪ شانس

اکنون شما می‌توانید با همان اطمینان به سراغ ذی‌نفعان بروید و بگویید: «بر اساس تعداد آیتم‌هایی که تیم ما به صورت هفتگی تکمیل می‌کند، ما با اطمینان ۸۵٪ می‌توانیم بگوییم که پروژه در۶ هفته یا کمتر به پایان می‌رسد.»

همانطور که می‌بینید، منطق کار هیچ تغییری نکرد. تنها چیزی که عوض شد، واحد اندازه‌گیری ما بود: از تخمین (Story Point) به شمارش (Throughput).

مقایسه دو رویکرد: Story Point در مقابل Throughput

خب، کدام رویکرد بهتر است؟ حقیقت این است که هیچ‌کدام بر دیگری برتری ذاتی ندارند. بهترین انتخاب کاملاً به زمینه کاری، فرهنگ و ماهیت فعالیت‌های تیم شما بستگی دارد. بیایید تفاوت‌های عملی این دو را بررسی کنیم.

رویکرد Story Point حول محور ارزش گفتگو و مدیریت تغییرپذیری می‌چرخد. استوری پوینت واحدی برای سنجش زمان نیست؛ بلکه تخمینی نسبی از تلاش، پیچیدگی و عدم قطعیت است. نقطه قوت اصلی آن در خودِ فرآیند برنامه‌ریزی نهفته است. وقتی یک تیم بحث می‌کند که کاری ۵ پوینتی است یا ۸، اعضا ناچار می‌شوند فرضیات پنهان را آشکار کنند، ریسک‌ها را بشناسند و به درکی مشترک از کار برسند. همین ویژگی، استوری پوینت را برای تیم‌هایی که با کارهایی با اندازه‌های بسیار متنوع سر و کار دارند- از یک اصلاح کوچک ۱ پوینتی گرفته تا یک فیچر بزرگ ۱۳ پوینتی- بسیار مؤثر می‌سازد. با این حال، نقطه ضعف آن، ماهیت ذهنی (subjective) آن است. چیزی که یک نفر ۵ پوینت در نظر می‌گیرد، ممکن است از دید دیگری ۸ پوینت باشد. این ذهنیت می‌تواند به بحث‌های طولانی منجر شود و اگر به درستی استفاده نشود، ممکن است به اشتباه به ساعت ترجمه شده یا به ابزاری برای سنجش عملکرد افراد تبدیل شود که این امر هدف اصلی آن را تضعیف می‌کند.

از سوی دیگر، رویکرد Throughput بر پایه عینیت (objectivity) و سادگی بنا شده است. Throughput شمارشی مستقیم و انکارناپذیر از آیتم‌های تمام‌شده است. یک کار یا تمام شده یا نشده؛ جایی برای بحث وجود ندارد. این رویکرد نیاز به جلسات زمان‌بر تخمین را از بین می‌برد و به تیم اجازه می‌دهد تا بیشتر بر روی توسعه تمرکز کند. این یک سنجه خالص از نرخ تحویل تیم است. با این حال، دقت آن به یک فرض کلیدی وابسته است: اینکه آیتم‌های کاری شما اندازه‌ای تقریباً مشابه داشته باشند. اگر بک لاگ شما ترکیبی از Epic های غول‌پیکر و تسک‌های بسیار کوچک باشد، یک شمارش ساده می‌تواند گمراه‌کننده باشد. هفته‌ای که تیم یک فیچر عظیم را تکمیل می‌کند ممکن است Throughput کمتری نسبت به هفته‌ای داشته باشد که ده تسک کوچک را به پایان می‌رساند، حتی اگر در هفته اول ارزش بیشتری تحویل داده شده باشد. بنابراین، Throughput برای تیم‌های بالغی که در شکستن کارهایشان به قطعات کوچک و هم‌اندازه مهارت دارند، بهترین عملکرد را دارد.

در نهایت، انتخاب بین این دو، انتخاب یک «متریک درست» نیست، بلکه پیدا کردن یک معیار معنادار و باثبات برای تیم شماست. اگر تیم شما از گفتگوهای فنی عمیق که در جلسات تخمین شکل می‌گیرد ارزش کسب می‌کند و با کارهای بسیار متنوعی روبروست، استوری پوینت ابزاری قدرتمند است. اما اگر تیم شما فرآیندی ساده‌تر را ترجیح می‌دهد، در تقسیم کار به قطعات کوچک مهارت دارد و برای یک معیار کاملاً عینی ارزش قائل است، به احتمال زیاد Throughput انتخاب مناسب‌تری خواهد بود.

شما از چه شیوه برای تخمین زدن و مهم تر از آن برای برنامه ریزی ارایه و تحویل پروژه استفاده می کنید؟

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

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

اینجاست که به نظرم، اولین و مهم‌ترین قدم برای هر تغییری، «احترام به گذشته» است. قبل از اینکه چشم‌انداز آینده را ترسیم کنیم، باید بپذیریم که وضعیت فعلی چرا و چگونه شکل گرفته است. باید به آدم‌ها نشان دهیم که تلاش‌هایشان را دیده‌ایم و می‌فهمیم که مسیری که تا اینجا آمده‌اند، ارزشمند بوده است.

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

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

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

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

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

شما تجربه‌ای از یک تغییر موفق یا ناموفق در محیط کارتان دارید؟ خوشحال می‌شوم در موردش بشنوم.

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

حالا محاسبات شرکت‌ها کاملاً تغییر کرده است. واقعیت جدید، دورانی از موشکافی، بهره‌وری و تمرکز بی‌رحمانه بر «بازگشت سرمایه» (ROI) است.

در این فضای جدید، چیزی به اسم «نقش تشریفاتی» یا «لوکس» دیگر وجود خارجی ندارد. موج تعدیل نیروها در سال‌های ۲۰۲۳ و ۲۰۲۴ کاملاً استراتژیک بود؛ شرکت‌ها موقعیت‌هایی را هدف گرفتند که از زنجیره ارزش‌آفرینی مستقیم دور بودند. امروز، سازمان‌ها در حال ادغام مسئولیت‌ها هستند و از هر کارمندی انتظار بیشتری دارند. این پدیده را می‌توان «ادغام بزرگ» (The Great Consolidation) نامید.

پیام بازار شفاف است: هر نقشی باید تأثیر مستقیم خود را بر کسب‌وکار نشان دهد. اگر نتوان ارزش یک موقعیت شغلی را به زبان ساده و قابل‌فهم برای کسب‌وکار توضیح داد، آن موقعیت در خطر است. این همان بستری است که راه را برای ظهور رهبرانی باز کرده که فقط فرآیندها را مدیریت نمی‌کنند، بلکه «مالک» نتایج هستند.

پررنگ تر شدن نقش Agile Delivery Manager؛ مالکیت سرتاسری زنجیره ارزش

اما درست در دل همین فشار و تغییرات، آمارهای آگهی شغلی نشان می دهد که نقش Delivery Manager نه تنها دوام آورده، بلکه اهمیت بیشتری هم پیدا کرده است. هرچند این نقش هم نسبت به قله‌ی حبابی سال ۲۰۲۲ کاهش داشته، اما تقاضا برای آن بسیار پایدارتر بوده است. چرا؟ چون این نقش دقیقاً برای همین محیط اقتصادی جدید ساخته شده است.

مدیران حس میکنند نقش Delivery Manager پاسخی است به مهم‌ترین سؤالی که امروز آنها از خود می‌پرسند: «چه کسی مسئولیت تحویل ارزش از نقطه شروع تا پایان را بر عهده دارد؟»

نقش Delivery Manager همانند یک «رهبر ارکستر» است. وظیفه او این است که:

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

آیا این همان مدیر پروژه قدیمی با یک نام جدید است؟

این یک سؤال بسیار مهمی است. در نگاه اول، تمرکز بر روی زمان‌بندی و نتیجه‌ نهایی ممکن است شبیه به بازگشت به مدیریت پروژه سنتی به نظر برسد. اما یک تفاوت بنیادین در طرز فکر و روش اجرا وجود دارد.

تفاوت کلیدی اینجاست: مدیر پروژه، یک پروژه را مدیریت می‌کند؛ Delivery Manager، تحویل ارزش را در یک چارچوب مدرن و Agile رهبری می‌کند. او یک نقشه خشک و غیرقابل تغییر را به تیم‌ها تحمیل نمی‌کند؛ بلکه نقش «چسبی» را ایفا می‌کند که تیم‌های مختلف را به هم متصل نگه می‌دارد تا اطمینان حاصل شود تلاش جمعی آن‌ها به یک نتیجه یکپارچه و تأثیرگذار برای کسب‌وکار منجر می‌شود.

تحلیل شما از بازار کار چیست؟ به نظر در آینده کاری چه نقش هایی پررنگ تر یا کم رنگ تر خواهند شد؟

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

راستش را بخواهید، سال‌ها کلمه‌ی «مقاومت» ورد زبان خودم هم بود. هر وقت تیمی یک ایده‌ی جدید را با آغوش باز نمی‌پذیرفت یا فردی در مورد یک تغییر سوال‌های زیادی می‌پرسید، اولین برچسبی که در ذهنم آماده بود، همین بود: «مقاومت در برابر تغییر». اما مدتی است که نگاهم به این موضوع کاملاً عوض شده است. امروز معتقدم چیزی که ما به سادگی به آن «مقاومت» می‌گوییم، در واقع یک «واکنش» (Response) است؛ واکنشی که نه تنها منفی نیست، بلکه گنجینه‌ای از اطلاعات ارزشمند را در خود پنهان کرده است.

چرا این «واکنش» یک گنج است؟

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

• دانش تاریخی: آن فرد احتمالاً تلاش‌های مشابهی را در گذشته به یاد می‌آورد که با شکست مواجه شده‌اند. او دلایل آن شکست‌ها را می‌داند: دلایلی که شاید در هیچ سندی ثبت نشده باشند و فقط در حافظه‌ی سازمانی افراد قدیمی تیم وجود دارند.
• شناخت عمیق فنی: شاید او می‌داند که این تغییر جدید با یک بخش قدیمی و حساس سیستم (Legacy Code) تداخل دارد و می‌تواند باعث بروز مشکلات جدی شود. این جزئیاتی است که اغلب در طراحی‌های سطح بالا دیده نمی‌شود.
• ریسک‌های پنهان: او ممکن است ریسک‌هایی را ببیند که از چشم ما پنهان مانده است. مثلاً اینکه این تغییر چقدر تیم پشتیبانی را درگیر می‌کند یا چقدر کاربران نهایی را تحت تأثیر قرار می‌دهد.

این فرد در واقع دارد به ما سیگنال‌های رایگان و ارزشمندی می‌دهد. او مثل یک سیستم هشدار اولیه عمل می‌کند که می‌تواند ما را از افتادن در چاله‌هایی که خودمان نمی‌بینیم، نجات دهد.

وقتی برچسب «مقاومت» می‌زنیم، چه اتفاقی می‌افتد؟

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

۱. کانال اطلاعات را می‌بندیم: وقتی به کسی می‌گوییم «تو مقاوم هستی»، در واقع داریم به او می‌گوییم: «نگرانی‌های تو بی‌اهمیت است و من علاقه‌ای به شنیدنشان ندارم.» در این حالت، آن فرد دیگر دانش و تجربیاتش را با ما به اشتراک نخواهد گذاشت.

۲. جبهه‌گیری ایجاد می‌کنیم: این برچسب، فضا را از یک گفتگوی سازنده به یک تقابل «ما در برابر آن‌ها» تبدیل می‌کند. ما به عنوان صاحبان ایده در یک سمت قرار می‌گیریم و فرد «مقاوم» در سمت دیگر. از این نقطه به بعد، هدف دیگر پیدا کردن بهترین راه‌حل نیست، بلکه غلبه بر طرف مقابل است.

۳. به جای جذب، دفع می‌کنیم: وقتی با فشار بیشتری سعی می‌کنیم ایده را پیش ببریم تا «مقاومت» را بشکنیم، نتیجه‌ی معکوس می‌گیریم. آدم‌ها ذاتاً در برابر فشار، واکنش دفاعی نشان می‌دهند. هر چه بیشتر هل بدهیم، آن‌ها بیشتر عقب می‌روند.

این برچسب زدن از یک فرض خطرناک نشأت می‌گیرد: «ایده‌ی من بی‌نقص است و هر کس با آن مخالفت کند، یا نمی‌فهمد، یا نیت خوبی ندارد.» این طرز فکر، دقیقاً نقطه‌ی مقابل ارزش‌های اجایل مانند همکاری، بازخورد و یادگیری مداوم است.

راه حل چیست؟ از قضاوت به کنجکاوی شیفت کنید

پیشنهاد من بسیار ساده است: دفعه‌ی بعد که با چنین واکنشی روبرو شدید، کلمه‌ی «مقاومت» را از ذهن خود پاک کنید و به جای آن، حس کنجکاوی‌تان را روشن کنید. به جای قضاوت، سوال بپرسید:

• «ممنون که این نکته را گفتی. می‌شه بیشتر توضیح بدی که چه چیزی نگرانت می‌کنه؟»
• «تجربه‌ی قبلی که بهش اشاره کردی خیلی جالب هست. به نظرت چه چیزی باعث شد اون دفعه موفق نشیم؟»
• «تو چی می‌بینی که شاید من ندیده باشم؟ بزرگ‌ترین ریسک از نظر تو چیه؟»

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

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

نظر شما در مورد این موضوع چیست؟ چرا فکر میکنید افراد در مقابل تغییرات مقاومت میکنند؟

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

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

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

۱. آماده‌سازی فضا و تعیین تمرکز
به جای اینکه وارد جلسه شویم و بپرسیم «خب، در مورد چی حرف بزنیم؟»، بهتر است از قبل یک «موضوع» یا «تمرکز» برای جلسه مشخص کنیم. این کار باعث می‌شود بحث‌ها پراکنده نشوند. مثلاً یک روز قبل از جلسه از تیم بپرسیم: «بچه‌ها، این اسپرینت حس می‌کنم روی کیفیت کدها چالش داشتیم، موافقید در جلسه فردا روی این موضوع تمرکز کنیم؟» یا «به نظرتون چطوره این جلسه را به نحوه همکاری‌مون با تیم بیزینس اختصاص بدیم؟». داشتن یک تمرکز مشخص، نصف راه است.

۲. جمع‌آوری داده (و نه فقط احساسات!)
مرحله «چه چیزهایی خوب بود/بد بود؟» معمولاً به جمع‌آوری احساسات شخصی محدود می‌شود. این خوب است، اما کافی نیست. داده‌های عینی و واقعی، بحث را از «من فکر می‌کنم» به «واقعیت این است» تغییر می‌دهد. مثلاً اگر تمرکز ما روی کیفیت است، می‌توانیم تعداد باگ‌های گزارش‌شده در این اسپرینت را بررسی کنیم. اگر موضوع سرعت تحویل کارهاست، می‌توانیم به نمودار «زمان چرخه» (Cycle Time) نگاهی بیندازیم. ترکیب داده‌های عینی (مثل اعداد و ارقام) با داده‌های ذهنی (احساسات و نظرات اعضای تیم) یک تصویر کامل و قدرتمند به ما می‌دهد.

۳. پیدا کردن ریشه و ایجاد بینش
این مهم‌ترین و معمولاً نادیده‌گرفته‌شده‌ترین مرحله است. اینجا جایی است که ما فقط به مشکلات اشاره نمی‌کنیم، بلکه به دنبال چرایی آن‌ها می‌گردیم. فرض کنید داده‌ها نشان می‌دهد که زمان انجام کارها طولانی شده. به جای اینکه فقط بگوییم «باید سریع‌تر کار کنیم»، از خودمان می‌پرسیم «چرا کارها طول کشید؟». شاید به این نتیجه برسیم که نیازمندی‌ها در اواسط کار تغییر می‌کردند، یا شاید متوجه شویم که بین اعضای تیم هماهنگی کافی برای Code Review وجود نداشت. این «آها!» یا همان لحظه رسیدن به بینش، جایی است که جرقه‌های تغییر واقعی زده می‌شود.

۴. تصمیم‌گیری برای یک اقدام کوچک و مشخص
لازم نیست دنیا را تغییر دهیم. بر اساس بینشی که به دست آوردیم، فقط و فقط یک آزمایش کوچک و قابل‌اندازه‌گیری برای اسپرینت بعدی انتخاب می‌کنیم. تأکید روی «یک» و «آزمایش» است. اگر چند اقدام همزمان انتخاب کنیم، احتمالاً به هیچ‌کدام نمی‌رسیم. و اگر به آن به چشم یک «آزمایش» نگاه کنیم، فشار روانی کمتری حس می‌کنیم. مثلاً: «بیایید برای اسپرینت بعدی، هر درخواست Code Review را در کمتر از ۴ ساعت بررسی کنیم و نتیجه را در بازنگری بعدی ببینیم.» این یک اقدام مشخص، عملی و قابل‌سنجش است.

۵. جمع‌بندی و واگذاری مالکیت به تیم
در پایان، مسئولیت این آزمایش نباید روی دوش مدیر یا اسکرام‌مستر باشد. این تصمیمِ «تیم» است و خود تیم باید مالک آن باشد. یکی از بهترین کارهایی که دیده‌ام بعضی تیم‌ها انجام می‌دهند این است که اقدام انتخاب‌شده را روی یک برگه بزرگ می‌نویسند و در جایی که در معرض دید همه باشد نصب می‌کنند. این کار به همه یادآوری می‌کند که ما به عنوان یک تیم، یک تعهد کوچک برای بهتر شدن به خودمان داده‌ایم. یادم می‌آید در یکی از تیم‌ها، جلسات بازنگری ما آنقدر بی‌اثر شده بود که اعضای تیم با بی‌میلی در آن شرکت می‌کردند. تصمیم گرفتیم این ساختار پنج مرحله‌ای را امتحان کنیم. اولین جلسه سخت بود، چون عادت به تفکر عمیق و داده‌محور نداشتیم. اما کم‌کم اوضاع عوض شد. جلسات ما کوتاه‌تر، متمرکزتر و پرانرژی‌تر شدند. و مهم‌تر از همه، بعد از هر جلسه حس می‌کردیم که یک قدم کوچک اما واقعی رو به جلو برداشته‌ایم.

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

و برعکس، اگر ظرفیت لوله اول را به ۲۰ لیتر برسانیم و لوله دوم همان ۵ لیتر باقی بماند، خروجی چقدر است؟ باز هم ۵ لیتر.

کاربرد این مثال در دنیای واقعی

یک سازمان، مجموعه‌ای از همین لوله‌های به هم پیوسته است. فرآیند کار از تیم محصول به تیم طراحی، سپس به مهندسی، و در نهایت به فروش و بازاریابی می‌رسد. هر کدام از این تیم‌ها همانند یک «لوله» هستند با ظرفیت مشخص.

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

وقتی خروجی کل سیستم کم است، اولین و ساده‌ترین واکنش، فشار آوردن است. جلسات بیشتر، گزارش‌های بیشتر، تهدید به اضافه‌کاری. اما این کار، مثل فشار آوردن به ابتدای یک سیستم لوله‌کشی معیوب است. آب از جایی نشت می‌کند، لوله‌ها می‌ترکند، اما خروجی بیشتر نمی‌شود.

راه حل چیست؟

• تنگ‌ترین لوله یا همان «گلوگاه» (Bottleneck) را پیدا کنید. همیشه قبل از گلوگاه، حجم زیادی از کارهای نیمه‌تمام انباشته می‌شود. این کاری است که شما بعنوان یک مدیر می‌توانید انجام بدهید، اما کارمندان نمی‌توانند چرا که آنها معمولا درگیر کار روزمره خودشان هستند و توجهی به کل پایپ لاین ندارند.
• ظرفیت گلوگاه را افزایش دهید. منابع، آموزش یا ابزارهای بهتری در اختیار آن تیم قرار دهید. تمام تمرکزتان را روی بهبود ظرفیت همین یک لوله بگذارید. وقت و پول را برای گشاد کردن لوله‌هایی که گلوگاه نیستند، هدر ندهید. این کار در بهترین حالت بی‌فایده است و در بدترین حالت، باعث می‌شود حجم کار بیشتری پشت گلوگاه انباشته شود.
• ورودی به گلوگاه را مدیریت کنید. شاید لازم باشد از تیم‌های قبلی بخواهید کمی خروجی خود را کم کنند تا گلوگاه زیر کار بی انتها غرق نشود. هیچ تیمی داوطلبانه این کار را نمی‌کند. این تصمیم از بالای زنجیره باید گرفته شود.
• وقتی گلوگاه جدیدی پیدا شد، تمرکز را جابجا کنید. وقتی ظرفیت یک لوله را زیاد می‌کنید، به احتمال زیاد یک لوله دیگر در سیستم تبدیل به تنگ‌ترین لوله می‌شود. هنر شما این است که دائماً در حال شناسایی و رفع گلوگاه‌های جدید باشید.

این بخش برداشتی آزادی از نوشته کنت بک بود

یک اعتراف شخصی

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

نتیجه‌گیری

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

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

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

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

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

اما تقریباً همیشه شکست می‌خوریم. چرا؟ چون زمین را آماده نکرده‌ایم. فرهنگ سازمانی، مهارت‌های تیم، فرآیندهای موجود و حتی طرز فکر ما، همان «خاک» است. اگر این خاک برای پذیرش تغییر آماده نباشد، بهترین و بزرگ‌ترین ایده‌ها هم در آن ریشه نمی‌دوانند.

راه حل، شاید در پیروی از منطق طبیعت باشد. به جای تلاش برای یک تغییر بزرگ و ناگهانی، باید بپرسیم: آن «گیاه پیشگام» در محیط ما چیست؟ آن کوچک‌ترین، ساده‌ترین و جان‌سخت‌ترین تغییری که می‌توانیم همین امروز ایجاد کنیم و شرایط را حتی به اندازه‌ی یک ذره، بهتر کند، چیست؟

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

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

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

چند هفته‌ای درگیر بود. شب‌ها تا دیروقت می‌نشست و روی یک فرآیند جدید کار می‌کرد. نمودار می‌کشید، پاورپوینت‌های قشنگ طراحی می‌کرد و برای تمام جزئیات، راه‌حل پیش‌بینی کرده بود. روزی که قرار بود طرحش را ارائه بدهد، با انرژی و هیجان وارد جلسه شد. با شور و حرارت، اسلایدها را یکی‌یکی توضیح داد و از مزایای این شیوه جدید گفت. کارش که تمام شد، با لبخندی حاکی از رضایت به ما نگاه کرد و گفت: «خب، این طرحی بود که من آماده کردم. البته این باید فرآیند شما باشه. دوست دارم شما هم صاحبش باشید. نظرتون چیه؟ چه فیدبکی دارید؟»

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

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

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

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

مطمئنم که آن سکوت سنگین می‌شکست. یکی می‌گفت بهتر است از اینجا شروع کنیم، دیگری می‌گفت آن قسمتش را باید طور دیگری طراحی کنیم و هر کس گوشه‌ای از کار را می‌گرفت. در نهایت، مجسمه‌ای که ساخته می‌شد، شاید با طرح اولیه‌ی ذهن مدیر متفاوت بود، اما یک ویژگی مهم داشت: اثر انگشت همه‌ی اعضای تیم روی آن بود. دیگر آن طرح متعلق به «مدیر» نبود، متعلق به «ما» بود و همه با جان و دل برای موفقیتش تلاش می‌کردند.

این همان «اصل اثر انگشت» است. اگر می‌خواهید تیمی مسئولیت‌پذیر و خلاق داشته باشید، به آن‌ها راه‌حل‌های آماده و بی‌نقص ندهید. به آن‌ها مسئله، ایده‌های نیمه‌کاره و خام بدهید و اجازه بدهید اشتباه کنند، طرح را تغییر بدهند و آن را مال خودشان کنند. رهبری فقط ارائه‌ی راه‌حل‌های بی‌نقص نیست؛ بلکه خلق فضایی است که بهترین راه‌حل‌ها در آن متولد شوند البته با اثر انگشت همه.

این نوشته الهام گرفته از پادکست استر دربی است.

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

اینجاست که قدرت پنهان «استعاره‌ها» یا «متافور» خودش را نشان می‌دهد. کلماتی که ما به کار می‌بریم، فقط یک سری واژه نیستند. آن‌ها چارچوب‌های ذهنی ما را می‌سازند. وقتی تغییر را مثل «رانندگی» می‌بینیم، ناخودآگاه دنبال یک راننده، یک فرمان و یک جاده‌ی صاف و مشخص می‌گردیم. در این تصویر، بقیه‌ی افراد سازمان مسافرانی هستند که باید ساکت بنشینند تا راننده آن‌ها را به مقصد برساند. اما آیا تغییر در یک سازمان واقعاً اینقدر قابل پیش‌بینی و یک طرفه است؟

این نوع نگاه، پیچیدگی‌های انسانی را نادیده می‌گیرد. در دنیای واقعی، تغییر بیشتر شبیه باغبانی است تا مهندسی مکانیک. شما نمی‌توانید یک دانه را «مجبور» به رشد کنید فقط می‌توانید شرایط را فراهم کنید: خاک را آماده کنید، آب و نور کافی به آن برسانید و علف‌های هرز را از بین ببرید. رشد، یک فرایند زنده و ارگانیک است که از درون اتفاق می‌افتد. آدم‌ها هم همین‌طور هستند. آن‌ها قطعات ماشین نیستند که بشود برنامه‌ریزی‌شان کرد. آن‌ها نیاز دارند که شرایط مناسب برایشان فراهم شود تا بتوانند مهارت‌های جدید یاد بگیرند، با هم همکاری کنند و به شیوه‌ای نو کار کنند.

وقتی به تغییر به چشم یک «سفر» نگاه کنیم، آن وقت دیگر انتظار یک مسیر مستقیم و بی‌دردسر را نداریم. در سفر ممکن است راه را گم کنیم، با چالش‌های پیش‌بینی نشده روبرو شویم و حتی گاهی لازم باشد مسیرمان را عوض کنیم. در این نگاه، همه همسفر هستند، نه راننده و مسافر. همه با هم یاد می‌گیرند و راه را پیدا می‌کنند.

شاید وقت آن رسیده باشد که کمی بیشتر به کلماتی که برای توصیف «تغییر» به کار می‌بریم، دقت کنیم. این استعاره‌ها چه تصوری در ذهن ما و همکارانمان می‌سازند؟ آیا به ما کمک می‌کنند که با واقعیت‌های انسانی و پیچیده‌ی سازمان کنار بیاییم یا برعکس، ما را در یک چارچوب مکانیکی و خشک زندانی می‌کنند؟

دفعه‌ی بعد که در مورد تغییر صحبت کردید یا شنیدید، به این فکر کنید که آیا می‌توان از کلمات دیگری استفاده کرد؟ شاید با تغییر زبانمان، بتوانیم خودِ «تغییر» را هم به تجربه‌ای انسانی‌تر و موفق‌تر تبدیل کنیم.

چابک و موفق باشید

اسد صفری

این تجربه، یکی از بزرگترین چالش‌های مدیران و رهبران را برایم برجسته‌تر کرد: چگونه بازخورد بدهیم؟ این کار یکی از سخت‌ترین وظایف یک مدیر است، اما اگر درست انجام شود، می‌تواند تأثیری شگرف بر رشد افراد و تیم داشته باشد.
برای درک بهتر موضوع، بیایید سه سناریوی مدیریتی را با هم بررسی کنیم. فرض کنید رضا و محمد دو برنامه‌نویس بسیار توانمند در تیم شما هستند، اما هرکدام چالش‌های خاص خود را دارند. رضا از نظر فنی بی‌نظیر است، اما با کوچک‌ترین انتقاد یا بحثی از کوره در می‌رود. محمد نیز برنامه‌نویس قابلی است، اما گاهی دچار حواس‌پرتی می‌شود و وظایف را فراموش می‌کند.

• حالت اول: مدیر سرزنشگر
  • شما به‌عنوان مدیر، دائماً از عملکرد رضا و محمد شاکی هستید. در جلسات مختلف و به هر بهانه‌ای به رضا تذکر می‌دهید که هنگام بحث آرامش خود را حفظ کند و از محمد می‌خواهید که بیشتر روی کارش متمرکز شود. نتیجه این است که هر دو از شنیدن حرف‌های تکراری شما خسته شده‌اند و شما را مدیری سخت‌گیر و بی‌توجه می‌بینند که فقط به انجام کارها اهمیت می‌دهد.
• حالت دوم: مدیریت مبتنی بر ترس
  • شما چنان شیفته توانایی‌های فنی رضا و محمد هستید که از ترس ناراحت شدنشان، هیچ‌گاه بازخورد جدی و منفی به آن‌ها نمی‌دهید. از اینکه مبادا به آن‌ها بربخورد و تیم را ترک کنند، نگرانید. در این حالت، شما مدیری هستید که از رویارویی با چالش‌ها پرهیز می‌کند و اجازه می‌دهد مشکلات کوچک به‌مرور زمان به بحران تبدیل شوند.
• حالت سوم: مدیر بی‌تفاوت
  • شما اساساً کاری به کار آن‌ها ندارید. نه تشویقی در کار است و نه انتقادی. در این سناریو، حضور شما به‌عنوان مدیر، عملاً هیچ تأثیر مثبتی بر تیم ندارد و بود و نبودتان تفاوتی ایجاد نمی‌کند.

هیچ‌کدام از این سه رویکرد، سازنده نیستند. حالت اول، مدیر را به یک «آدم عوضی» تبدیل می‌کند که تنها به دنبال نتیجه است. حالت دوم، ریشه در ترس دارد و مانع رشد افراد می‌شود. و در حالت سوم، مدیر نقش مؤثری ایفا نمی‌کند. پس راه‌حل چیست؟

مغز ما چگونه به بازخورد واکنش نشان می‌دهد؟

مدتی است که به حوزه جذاب نوروساینس (علوم اعصاب) علاقه‌مند شده‌ام و مطالعاتی در این زمینه داشته‌ام. این علم بر عملکرد مغز تمرکز دارد و یافته‌های آن در رشته‌های مختلفی مانند مدیریت، منابع انسانی، بازاریابی و فروش کاربردهای عملی دارد.

یکی از ابزارهای قدرتمند برای مطالعه مغز، اسکن fMRI است. این فناوری با ردیابی جریان خون در نواحی مختلف مغز، نشان می‌دهد که کدام بخش‌ها در هر لحظه فعال‌تر هستند. برای مثال، وقتی احساس شادی می‌کنید، فعالیت در بخش خاصی از مغز افزایش می‌یابد.
نکته شگفت‌انگیز اینجاست: تحقیقات نشان داده‌اند بخشی از مغز که هنگام درد فیزیکی (مانند دندان‌درد) فعال می‌شود، همان بخشی است که در زمان تجربه درد اجتماعی (مانند مورد انتقاد قرار گرفتن، بی‌توجهی یا طرد شدن) نیز به فعالیت وامی‌دارد. این یعنی مغز ما تفاوت چندانی میان یک سیلی خوردن و یک تحقیر کلامی در جمع قائل نیست. وقتی بازخوردی به‌شکلی نادرست ارائه می‌شود و فرد احساس می‌کند ناعادلانه قضاوت شده، مغز او همان واکنشی را نشان می‌دهد که به یک درد فیزیکی نشان می‌دهد. به همین دلیل است که یک بازخورد بد می‌تواند تمام روز و حتی خواب شبانه ما را مختل کند.(منبع)

از «استنتاج» بپرهیزید و بر «رفتار» تمرکز کنید

بزرگ‌ترین اشتباه در بازخورد دادن، قضاوت کردن و برچسب زدن است. ما باید بیاموزیم که میان رفتار (Behavior) و استنتاج (Inference) تفاوت قائل شویم.

• رفتار: «علی، این سومین بار است که کاری را که قول انجامش را داده بودی، در موعد مقرر تحویل ندادی.» (توصیف یک واقعیت قابل مشاهده)
• استنتاج: «علی، تو کلاً آدم مسئولیت‌پذیری نیستی.» (یک قضاوت کلی و شخصی)

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

چارچوب «موقعیت – رفتار – تأثیر» (Situation – Behavior – Impact)

یکی از مؤثرترین مدل‌ها برای ارائه بازخورد، چارچوب «موقعیت – رفتار – تأثیر» است. این مدل به شما کمک می‌کند تا بدون قضاوت و به‌شکلی ساختارمند، پیام خود را منتقل کنید.
فرمول کار ساده است:

• موقعیت (Situation): ابتدا زمان و مکانی که رفتار در آن رخ داده را مشخص کنید. (کِی و کجا؟)
• رفتار (Behavior): سپس رفتار مشخصی را که مشاهده کرده‌اید، بدون هیچ‌گونه قضاوت یا تعمیمی، توصیف کنید. (چه کاری انجام شد؟)
• تأثیر (Impact): در نهایت، تأثیری که آن رفتار بر شما، تیم یا پروژه گذاشته را بیان کنید. (چه نتیجه‌ای داشت؟)

برای مثال : «میلاد جان، (موقعیت) در جلسه مدیران محصول که امروز صبح داشتیم، وقتی داشتی ارائه‌ات را پرزنت می‌کردی، (رفتار) متوجه شدم که بین جملاتت خیلی از ‘اِممم…’ استفاده می‌کردی. (تأثیر) این موضوع باعث شد من این حس را بگیرم که شاید حاضرین در جلسه فکر کنند تو برای ارائه آمادگی کامل نداشتی یا ذهنت درگیر موضوع دیگری بود.»

این چارچوب به شما اجازه می‌دهد تا بازخوردهای مثبت و منفی را به‌شکلی سازنده ارائه دهید:

• مثال مثبت: «(موقعیت) در جلسه‌ای که با مشتری داشتیم، (رفتار) تعادل بسیار خوبی میان شنیدن ایده‌های آن‌ها و بیان نظرات تیم ما برقرار کردی. (تأثیر) این کارت باعث شد خود مشتریان اذعان کنند که ما نیازهایشان را به بهترین شکل درک کرده‌ایم و این حس اعتماد فوق‌العاده‌ای ایجاد کرد.»
• مثال منفی: «(موقعیت) در جلسه با مدیرعامل، (رفتار) سعی کردی تمام جزئیات پروژه را پشت سر هم ارائه دهی و همه سؤالات را به انتهای جلسه موکول کردی. (تأثیر) من احساس کردم مدیرعامل از این موضوع چندان راضی نبود، چون سؤالات زیادی در ذهنش داشت و ترجیح می‌داد همان لحظه پاسخ بگیرد.»

یک گام فراتر: اضافه کردن «جایگزین»

برای اینکه بازخورد شما کامل‌تر و کاربردی‌تر شود، می‌توانید یک بخش چهارم نیز به این چارچوب اضافه کنید: جایگزین (Alternative) یا همان راه‌حل پیشنهادی.

با این کار، شما نه‌تنها مشکل را مشخص می‌کنید، بلکه راهی برای بهبود نیز پیشنهاد می‌دهید و نشان می‌دهید که برای کمک به رشد فرد مقابل، آماده‌اید.

مثال کامل‌شده:
«(موقعیت) در جلسه با مدیرعامل، (رفتار) سعی کردی تمام جزئیات پروژه را پشت سر هم ارائه دهی و همه سؤالات را به انتهای جلسه موکول کردی. (تأثیر) من احساس کردم مدیرعامل از این موضوع چندان راضی نبود، چون سؤالات زیادی در ذهنش داشت و ترجیح می‌داد همان لحظه پاسخ بگیرد. (جایگزین) به نظرم در جلسات بعدی اگر ارائه را به بخش‌های کوچک‌تر تقسیم کنی و پس از هر بخش، فضا را برای پرسش و پاسخ باز بگذاری، تعامل بهتری شکل می‌گیرد و تأثیرگذاری بیشتری خواهد داشت.»

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

چابک و موفق باشید

اسد صفری