Iran Agile

اجایل دوناتز ۱۹ | دورهمی آنلاین چابک‌کاران ایران 🍩☕ زمان: امشب - جمعه ۱۲ دی ساعت ۲۰:۰۰ به وقت تهران موضوع: چابکی و هوش مصنوعی (Agile & AI) فرصت‌ها، چالش‌ها و تجربه‌های واقعی هوش مصنوعی در حال تغییر دادن شیوه‌ی کار تیم‌هاست: از تحلیل نیازمندی و تولید محتوا گرفته تا کدنویسی، تست، مستندسازی و حتی تصمیم‌گیری‌های محصول. اما سؤال مهم این است: آیا شیوه کار ما هماهنگ با این تغییرات است؟ آینده تیم‌های نرم افزار چگونه خواهد بود؟ آیا نقش‌های چابک در این شیوه‌های جدید کاری همچنان جایگاهی خواهند داشت؟ در این دورهمی خواهیم کوشید که نظرات و تجربیات خود را با هم به اشتراک بگذاریم و البته مشتاق شنیدن نظرات و تجربیات همه دوستان هستیم. 🍩☕ لینک جلسه در گوگل میتز: https://meet.google.com/ubj-jtrd-fgk

ورکشاپ «مدیریت محصول چابک (Product Owner)» هفته آینده برگزار می‌شود. این ورکشاپ چهارروزه برای دوستانی طراحی شده که می‌خواهند درک عمیق‌تر و کاربردی‌تری از نقش مدیر محصول چابک و مالک محصول داشته باشند؛ این‌که دقیقاً چه‌کاری انجام می‌دهد، در طول چرخه عمر محصول کجاها وارد می‌شود و در روزمره‌ی کاری‌اش با چه چالش‌هایی روبه‌رو است. در کنار مبانی نقش، با یک‌سری ابزار و تکنیک‌های عملی هم کار می‌کنیم؛ از جمله: User Story Mapping تدوین چشم‌انداز محصول طراحی نقشه راه محصول (Product Roadmap) نوشتن و شکستن استوری‌های کاربر (User Stories) برای اطلاعات بیشتر و ثبت‌نام، می‌توانید از طریق این لینک اقدام کنید.

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

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

سرندیپیتی یعنی چه؟ و یاد گرفتن هنر «وصل کردن نقطه‌ها» همیشه برای ما سؤال بوده که چرا بعضی آدم‌ها انقدر «خوش‌شانس» به نظر می‌رسند. انگار همیشه در زمان درست، در مکان درستی هستند. یک فرصت شغلی عالی پیدا می‌کنند، یک ایده‌ی کسب‌وکار به ذهنشان می‌رسد یا خیلی اتفاقی با کسی آشنا می‌شوند که زندگی‌شان را تغییر می‌دهد. با دوستی صحبت میکردم و او معتقد بود که این فقط بخت و اقبال است؛ چیزی که یا داری یا نداری. اما به نظرم اگر ما داستان اختراع ماکروویو را یک بار دیگر مرور کنیم شاید نظرمان عوض شود. فکرش را بکنید، سال ۱۹۴۵، یک مهندس به اسم «پرسی اسپنسر» داشت روی تجهیزات راداری برای ارتش کار می‌کرد. یک روز، متوجه شد شکلاتی که در جیبش گذاشته بود، آب شده. خیلی‌ها ممکن بود به سادگی از کنار این اتفاق بگذرند و بگویند: «عجب! چه گرمه اینجا!» و تمام. اما اسپنسر این کار را نکرد. کنجکاو شد. با خودش گفت: «چرا؟ چه چیزی باعث این اتفاق شد؟» همین کنجکاوی ساده، او را به سمت یک سری آزمایش کشاند. دانه‌های ذرت را کنار دستگاه گذاشت و دید تبدیل به پاپ‌کورن شدند. بعد یک تخم‌مرغ را امتحان کرد و تخم‌مرغ در صورت همکارش منفجر شد! نتیجه‌ی این کنجکاوی و این بازیگوشی ذهنی، وسیله‌ای شد که امروز در آشپزخانه‌ی اکثر ما پیدا می‌شود. تفاوت اسپنسر با دیگران در شانس او نبود؛ بلکه در توانایی‌اش برای دیدن یک ارتباط بالقوه بین دو پدیده‌ی ظاهراً بی‌ربط بود: یک دستگاه نظامی و پختن غذا. این دقیقاً جوهر سرندیپیتی است. ذهنیت «نقشه» دوست دارد همه‌چیز دقیق، مشخص و از پیش تعیین‌شده باشد. از نقطه‌ی الف به نقطه‌ی ب، طبق مسیری که قبلاً کشیده شده. هر اتفاق غیرمنتظره‌ای را یک مزاحمت می‌بیند و سعی می‌کند آن را نادیده بگیرد. این ذهنیت برای انجام کارهای روتین عالی است، اما جلوی هرگونه کشف و خلاقیت را می‌گیرد. اما ذهنیت «قطب‌نما»، فقط یک جهت کلی را می‌داند. او به دنبال مقصد است، اما در مسیر، چشم‌هایش را باز نگه می‌دارد. وقتی یک اتفاق غیرمنتظره می‌افتد، آن را یک مزاحمت نمی‌بیند، بلکه یک «نشانه» می‌بیند. از خودش می‌پرسد: «این اتفاق چه معنایی می‌تونه داشته باشه؟ آیا می‌تونم ازش استفاده کنم؟» در محیط کار خودمان هم این دو ذهنیت را بارها دیده‌ام. مدیرانی که وقتی یک پروژه شکست می‌خورد، سریع آن را دفن می‌کنند تا کسی از آن حرفی نزند. آن‌ها با ذهنیت «نقشه» کار می‌کنند و شکست یعنی خروج از مسیر. اما در بعضی شرکت‌های خلاق، شنیده‌ام که برای پروژه‌های شکست‌خورده «مراسم خاصی» برگزار می‌کنند! در این مراسم، تیم پروژه در مورد دلایل شکست و چیزهایی که از آن یاد گرفته‌اند صحبت می‌کند. چه اتفاقی می‌افتد؟ خیلی وقت‌ها، کسی از یک بخش دیگر شرکت که در آن جلسه حضور دارد، ناگهان می‌گوید: «صبر کنید! این تکنولوژی که برای شما جواب نداد، دقیقاً همان چیزی است که ما برای حل یک مشکل دیگر نیاز داریم!» و به این ترتیب، یک شکست تبدیل به بذر یک موفقیت جدید می‌شود. این قدرت ذهنیت «قطب‌نما» است. به نظرم همه‌ی ما می‌توانیم این مهارت را در خودمان پرورش دهیم. می‌توانیم با تمرین‌های کوچک شروع کنیم. مثلاً آخر هر هفته از خودمان بپرسیم: «غافلگیرکننده‌ترین اتفاقی که این هفته برایم افتاد چه بود؟ آیا نکته‌ی جالبی در آن پنهان شده بود؟» یا وقتی با مشکلی مواجه می‌شویم، به جای اینکه فقط به راه‌حل‌های همیشگی فکر کنیم، از خودمان بپرسیم: «مسخره‌ترین یا عجیب‌ترین راه‌حل ممکن برای این مشکل چیست؟» دنیا پر از نقطه‌های پراکنده است؛ پر از شکلات‌های آب‌شده و پروژه‌های شکست‌خورده. شاید هنر واقعی زندگی، نه دنبال کردن یک نقشه‌ی بی‌نقص، که یاد گرفتن هنر «وصل کردن این نقطه‌ها» به یکدیگر باشد. شاید شانس، چیزی نیست که برایمان اتفاق بیفتد، بلکه چیزی است که خودمان با کنجکاوی می‌سازیم.

چند وقت پیش با مدیری صحبت می‌کردم که از «مقاومت کارمندها در برابر تغییر» حسابی شاکی بود. می‌گفت: «یک فرآیند جدید و عالی طراحی کردیم که کار همه رو راحت‌تر می‌کنه، ولی انگار نه انگار! هرکس به یک بهانه‌ای از زیرش در می‌ره. واقعاً نمی‌فهمم چرا با چیزی که به نفع خودشونه مخالفت می‌کنن.» تمام مدتی که او با حرارت حرف می‌زد، من داشتم به این فکر می‌کردم که ما اغلب یک نکته‌ی کلیدی را فراموش می‌کنیم: هیچ‌کس صبح از خواب بیدار نمی‌شود تا عمداً کارش را بد انجام دهد یا جلوی پیشرفت را بگیرد. آن روش قدیمی و ناکارآمدی که امروز می‌خواهیم تغییرش دهیم، یک روزی بهترین راه‌حل موجود بوده است. آدم‌ها برایش زحمت کشیده‌اند، با آن خو گرفته‌اند و در آن متخصص شده‌اند. آن فرآیند، بخشی از هویت حرفه‌ای‌شان شده است. ادامه نوشته در لینک زیر: https://blog.scrum.ir/2025/10/rules-of-change/

اولین دوره آموزشی رسمی - Agile Delivery Management این هفته برگزار خواهد شد تاریخ شروع برگزاری از ۲۴ مهرماه به مدت دو هفته هدف اصلی این کارگاه آموزشی علاوه بر عمیق شدن در مفاهیم Delivery Management، انتقال تجربیات از دنیای واقعی کار بخصوص شرکت های بین المللی است که معمولا در کتاب‌ها و اینترنت کمتر پیدا می‌شود. برای اطلاعات بیشتر میتوانید از این لینک استفاده کنید.

اولین دوره آموزشی رسمی - Agile Delivery Management تاریخ شروع برگزاری از ۲۴ مهرماه به مدت دو هفته هدف اصلی این کارگاه آموزشی علاوه بر عمیق شدن در مفاهیم Delivery Management، انتقال تجربیات از دنیای واقعی کار بخصوص شرکت های بین المللی است که معمولا در کتاب‌ها و اینترنت کمتر پیدا می‌شود. برای اطلاعات بیشتر میتوانید از این لینک استفاده کنید:

تفاوت نقش اسکرام مستر و اجایل دلیوری منیجر در پست قبلی که در مورد نقش Agile Delivery Manager بود بسیاری از دوستان در مورد تفاوت این نقش با اسکرام مستر سوالاتی داشتن که فکر کردم که شاید بد نباشد همه ان سوالات در قالب نوشته بررسی کرد. در قلب ماجرا، تفاوت بین اسکرام مستر و دلیوری منیجر، تفاوت در «زاویه دید» است. لنزِ اسکرام مستر معمولاً به سمت داخل و متمرکز بر یک یا حداکثر دو تیم است. وظیفه اصلی او، همان‌طور که در چارچوب اسکرام تعریف شده، ایفای نقش «رهبر خدمتگزار» (Servant-Leader) و مربی برای تیم است. او اطمینان حاصل می‌کند که اصول اسکرام رعایت می‌شود، رویدادها را تسهیل می‌کند و موانع پیش روی تیم را برطرف می‌سازد. موفقیت او با سلامت، پیش‌بینی‌پذیری و بهبود مستمر تیمش سنجیده می‌شود. در مقابل، دلیوری منیجر با لنزی با زاویه دید بازتر عمل می‌کند. با وجود درک عمیق از اصول چابک، تمرکز او کمتر بر پایبندی به یک چارچوب خاص و بیشتر بر کل «جریان ارزش» (Value Stream) است؛ از ایده تا رسیدن به دست مشتری. او مسئول تحویل یک محصول یا خدمت است که اغلب شامل هماهنگی میان چندین تیم، مدیریت وابستگی‌ها، کاهش ریسک‌ها در سطح برنامه (Programme) و تضمین همسویی با اهداف کلان کسب‌وکار می‌شود. موفقیت او نه تنها با سلامت تیم، بلکه با تحویل به موقع و مؤثرِ ارزش ملموس به سازمان سنجیده می‌شود. اشتهای سازمانی: چرا گرایش به سوی اجایل دلیوری منیجرافزایش یافته است؟ تقاضای روزافزون برای مدیران تحویل چابک، به معنای نقد نقش اسکرام مستر نیست، بلکه نشان‌دهنده‌ی پذیرش پیچیدگی‌های فزاینده در توسعه‌ی محصولات مدرن است. چندین عامل کاربردی این گرایش را تقویت می‌کنند: ۲. حرکت عمل‌گرایانه فراتر از تعصب بر چارچوب‌ها: بسیاری از سازمان‌ها به سطحی از بلوغ رسیده‌اند که پیاده‌سازی کتابی و خشک یک چارچوب خاص مانند اسکرام برایشان کافی نیست. آن‌ها اغلب در محیطی ترکیبی (Hybrid) فعالیت می‌کنند و عناصری از اسکرام، کانبان (Kanban) و سایر رویکردها را با هم می‌آمیزند. دلیوری منیجربه دلیل عمل‌گرا بودن ارزشمند است؛ یعنی توانایی انطباق رویکردها با شرایط موجود، به جای تلاش برای خوراندن شرایط به یک چارچوب از پیش تعیین‌شده. ۳. نیاز به مدیریت پیش‌دستانه ریسک و وابستگی‌ها: در محیط‌های پیچیده توسعه محصول، ریسک‌ها و وابستگی‌ها استثنا نیستند، بلکه بخشی از واقعیت روزمره‌اند. وظیفه‌ی دلیوری منیجر به صراحت شامل شناسایی، ردیابی و کاهش این مسائل در سطح کلان است. او سیستم هشدار اولیه و دیپلمات تیم‌هاست؛ کسی که برای یافتن راه‌حل بین تیم‌ها مذاکره می‌کند و مسیر را برای تحویل هموار می‌سازد، مدت‌ها قبل از آنکه یک تیم خاص حتی از وجود یک مانع در آینده باخبر شود. در نهایت، ظهور دلیوری منیجر چابک، بازتابی از بلوغ خودِ جنبش چابک است؛ حرکتی از بهینه‌سازی درونی تیم‌ها به سوی یک دیدگاه کل‌نگر و نتیجه‌محور. در حالی که اسکرام مستر همچنان نقشی حیاتی برای پرورش تیم‌های چابک کارآمد ایفا می‌کند، دلیوری منیجر نیاز اساسی سازمان‌ها برای رهبری و هماهنگ‌کردن این تیم‌ها به سوی تحویل یکپارچه و تأثیرگذار ارزش را برآورده می‌سازد.

کتابخانه رایگان پرامپت های هوش موصنوعی شرکت OpenAI خالق ChatGPT به تازگی در بخش آکادمی خود اقدام به ارایه یک کتابخانه بزرگ از پرامپت های پرکاربرد کرده است. دسته بندی این پرامپت ها بر اساس کاربردهای انها در حوزه های مختلف است. مثلا پرامپت های مخصوص کسانی که در حوزه مدیریت محصول کار میکنند.

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

📌 برای مدیران محصول: https://academy.openai.com/public/clubs/work-users-ynjqu/resources/use-cases-product 📌 برای توسعه دهندگان: https://academy.openai.com/public/clubs/work-users-ynjqu/resources/use-cases-engineers 📌 برای منابع انسانی: https://academy.openai.com/public/clubs/work-users-ynjqu/resources/use-cases-hr و برای خیلی از کاربردهای دیگر که میتوانید از طریق لینک زیر به تمام این کتابخانه دسترسی داشته باشید: https://academy.openai.com/public/tags/prompt-packs-6849a0f98c613939acef841c

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

ظهور نقش Agile Delivery Manager : تغییرات در بازار کار احتمالاً شما هم مثل من این را شنیده‌اید که گفته می‌شود وضع بازار کار در صنعت آی‌تی مثل سابق نیست و این فقط منحصر به ایران نیست. تا همین چند سال پیش، بازار کار تکنولوژی شبیه یک مهمانی بزرگ و بریز بپاش بود. نزدیک به یک دهه، این بازار با رشد سرسام‌آور و اشتهای سیری‌ناپذیر برای جذب نیروهای متخصص تعریف می‌شد. آمارها این واقعیت را به وضوح نشان می‌دهند: در اوج این رونق در سال ۲۰۲۲، آگهی‌های شغلی برای نقش‌های تخصصی به رکوردی تاریخی رسید. این نشان از بازاری داشت که غرق در سرمایه بود و تنها اولویتش، توسعه و رشد با هر سرعتی بود. اما این قله، با یک سقوط آزاد و سریع همراه شد. ما شاهد افت شدید آگهی‌های شغلی در تمام حوزه‌ها بودیم، به‌طوری‌که برخی از نقش‌ها، کاهشی بیش از ۶۰ تا ۷۰ درصد را نسبت به دوران اوج خود تجربه کردند. این یک کاهش سرعت ساده نبود؛ بلکه یک بازنگری و تنظیم مجدد بنیادین در کل بازار بود. محرک اصلی این تغییر، واقعیت‌های جدید اقتصادی مانند افزایش نرخ بهره، فشار سرمایه‌گذاران برای سودآوری، و پایان دوران سرمایه‌های ارزان بود. حالا محاسبات شرکت‌ها کاملاً تغییر کرده است. واقعیت جدید، دورانی از موشکافی، بهره‌وری و تمرکز بی‌رحمانه بر «بازگشت سرمایه» (ROI) است. در این فضای جدید، چیزی به اسم «نقش تشریفاتی» یا «لوکس» دیگر وجود خارجی ندارد. موج تعدیل نیروها در سال‌های ۲۰۲۳ و ۲۰۲۴ کاملاً استراتژیک بود؛ شرکت‌ها موقعیت‌هایی را هدف گرفتند که از زنجیره ارزش‌آفرینی مستقیم دور بودند. امروز، سازمان‌ها در حال ادغام مسئولیت‌ها هستند و از هر کارمندی انتظار بیشتری دارند. این پدیده را می‌توان «ادغام بزرگ» (The Great Consolidation) نامید. پیام بازار شفاف است: هر نقشی باید تأثیر مستقیم خود را بر کسب‌وکار نشان دهد. اگر نتوان ارزش یک موقعیت شغلی را به زبان ساده و قابل‌فهم برای کسب‌وکار توضیح داد، آن موقعیت در خطر است. این همان بستری است که راه را برای ظهور رهبرانی باز کرده که فقط فرآیندها را مدیریت نمی‌کنند، بلکه «مالک» نتایج هستند. پررنگ تر شدن نقش Agile Delivery Manager؛ مالکیت سرتاسری زنجیره ارزش اما درست در دل همین فشار و تغییرات، آمارهای آگهی شغلی نشان می دهد که نقش Delivery Manager نه تنها دوام آورده، بلکه اهمیت بیشتری هم پیدا کرده است. هرچند این نقش هم نسبت به قله‌ی حبابی سال ۲۰۲۲ کاهش داشته، اما تقاضا برای آن بسیار پایدارتر بوده است. چرا؟ چون این نقش دقیقاً برای همین محیط اقتصادی جدید ساخته شده است. مدیران حس میکنند نقش Delivery Manager پاسخی است به مهم‌ترین سؤالی که امروز آنها از خود می‌پرسند: «چه کسی مسئولیت تحویل ارزش از نقطه شروع تا پایان را بر عهده دارد؟»

💡ورکشاپ اسکرام کاربردی مهرماه برگزار خواهد شد. به اطلاع دوستانی که پیگیر ورکشاپ اسکرام کاربردی بودند، می‌رساند که این دوره این هفته در روزهای ۳، ۴، ۱۰، ۱۱ مهرماه ۱۴۰۴با مربی گری اسد صفری برگزار خواهد شد. هدف اصلی این دوره علاوه بر عمیق شدن در مفاهیم اسکرام و چابک، انتقال تجربیات از دنیای واقعی و چالش‌های محیط کار است که معمولا در کتاب‌ها و اینترنت کمتر پیدا می‌شود. 📎 برای اطلاعات بیشتر میتوانید از این لینک استفاده کنید.

چند وقت پیش در جلسه‌ی بازنگری یکی از تیم‌ها بودم. مدیر محصول با هیجان در مورد یک تغییر بزرگ در معماری اپلیکیشن صحبت می‌کرد که قرار بود سرعت توسعه را چند برابر کند. همه چیز خوب پیش می‌رفت تا اینکه یکی از توسعه‌دهنده‌های ارشد و باتجربه تیم، با حالتی مردد گفت: «فکر نمی‌کنم این ایده به این سادگی‌ها جواب بدهد. ما قبلاً یک تلاش مشابه داشتیم و به مشکل خوردیم.» در یک لحظه، دمای اتاق انگار چند درجه پایین آمد. مدیر محصول که تا آن لحظه لبخند می‌زد، کمی جدی شد و بعد از جلسه در گفتگوی کوتاهی که با من داشت، از «مقاومت» این فرد در برابر تغییر گله کرد. راستش را بخواهید، سال‌ها کلمه‌ی «مقاومت» ورد زبان خودم هم بود. هر وقت تیمی یک ایده‌ی جدید را با آغوش باز نمی‌پذیرفت یا فردی در مورد یک تغییر سوال‌های زیادی می‌پرسید، اولین برچسبی که در ذهنم آماده بود، همین بود: «مقاومت در برابر تغییر». اما مدتی است که نگاهم به این موضوع کاملاً عوض شده است... ادامه این نوشته را در لینک زیر میتوانید بخوانید https://blog.scrum.ir/2025/08/how-to-deal-with-resistance-to-change/

پنج گام و یک تکنیک برای متحول کردن جلسات رترو اگر شما هم مثل من چندین سال است که تکنیکهای مختلف برگزاری و تسهیلگری جلسات رترو تیم یا حتی شرکت را آزمایش می‌کنید، متوجه شده‌اید که اکثرا این روشها بسیار شبیه هم هستند و یک چالش بزرگ دارند که بیشتر بر روی بازی گونه کردن رترو تمرکز دارند تا کمک به ایجاد فضای بهبود مستمر. چند وقت اخیر از روش متفاوتی استفاده می‌کنم، که بد ندیدم آن را با شما به اشتراک بگذارم. در اینجا من سعی کردم نسخه و تجربه خودم را از آن خدمت شما معرفی کنم. https://blog.scrum.ir/2024/05/5-steps-for-a-better-retrospective/

۵ نکته اساسی برای بهبود جلسات بازنگری اسپرینت اگر شما هم در تیم‌های نرم‌افزاری یا محصول کار کرده باشید، احتمالاً با این صحنه آشنا هستید: پایان یک اسپرینت دیگر، و زمان جلسه «بازنگری» یا همان «رترو» (Retrospective) است. همه دور هم جمع می‌شوند، یک نفر چند تا ستون روی تخته می‌کشد: «چه چیزهایی خوب بود؟»، «چه چیزهایی بد بود؟» و «چه کارهایی بکنیم؟». چند دقیقه‌ای سکوت برقرار می‌شود، بعد یک یا دو نفر از اعضای تیم که معمولاً فعال‌تر هستند چند نکته می‌گویند، چند استیکی نوت رنگی روی تخته می‌چسبد و در نهایت یک یا دو «اقدام» (Action Item) مشخص می‌شود که اغلب در شلوغی اسپرینت بعدی فراموش می‌شوند. جلسه تمام می‌شود و همه حس می‌کنند یک تسک دیگر را از لیست کارهایشان خط زده‌اند، اما آیا واقعاً چیزی بهتر شد؟ https://blog.scrum.ir/2025/08/five-tips-for-effective-retros/

کاربرد این مثال در دنیای واقعی یک سازمان، مجموعه‌ای از همین لوله‌های به هم پیوسته است. فرآیند کار از تیم محصول به تیم طراحی، سپس به مهندسی، و در نهایت به فروش و بازاریابی می‌رسد. هر کدام از این تیم‌ها همانند یک «لوله» هستند با ظرفیت مشخص. شما به عنوان یک مدیر، یک امتیاز منحصر به فرد دارید: می‌توانید کل این زنجیره را از بالا ببینید. کارمندان هر تیم، معمولاً فقط روی بهینه کردن وظیفه یا بعبارتی «لوله» خودشان متمرکز هستند و این طبیعی است. اما این شما هستید که مسئولیت عملکرد کل سیستم را بر عهده دارید. وقتی خروجی کل سیستم کم است، اولین و ساده‌ترین واکنش، فشار آوردن است. جلسات بیشتر، گزارش‌های بیشتر، تهدید به اضافه‌کاری. اما این کار، مثل فشار آوردن به ابتدای یک سیستم لوله‌کشی معیوب است. آب از جایی نشت می‌کند، لوله‌ها می‌ترکند، اما خروجی بیشتر نمی‌شود. راه حل چیست؟ - تنگ‌ترین لوله یا همان «گلوگاه» (Bottleneck) را پیدا کنید. همیشه قبل از گلوگاه، حجم زیادی از کارهای نیمه‌تمام انباشته می‌شود. این کاری است که شما بعنوان یک مدیر می‌توانید انجام بدهید، اما کارمندان نمی‌توانند چرا که آنها معمولا درگیر کار روزمره خودشان هستند و توجهی به کل پایپ لاین ندارند. - ظرفیت گلوگاه را افزایش دهید. منابع، آموزش یا ابزارهای بهتری در اختیار آن تیم قرار دهید. تمام تمرکزتان را روی بهبود ظرفیت همین یک لوله بگذارید. وقت و پول را برای گشاد کردن لوله‌هایی که گلوگاه نیستند، هدر ندهید. این کار در بهترین حالت بی‌فایده است و در بدترین حالت، باعث می‌شود حجم کار بیشتری پشت گلوگاه انباشته شود. - ورودی به گلوگاه را مدیریت کنید. شاید لازم باشد از تیم‌های قبلی بخواهید کمی خروجی خود را کم کنند تا گلوگاه زیر کار بی انتها غرق نشود. هیچ تیمی داوطلبانه این کار را نمی‌کند. این تصمیم از بالای زنجیره باید گرفته شود. وقتی گلوگاه جدیدی پیدا شد، تمرکز را جابجا کنید. وقتی ظرفیت یک لوله را زیاد می‌کنید، به احتمال زیاد یک لوله دیگر در سیستم تبدیل به تنگ‌ترین لوله می‌شود. هنر شما این است که دائماً در حال شناسایی و رفع گلوگاه‌های جدید باشید. https://blog.scrum.ir/2025/08/theory-of-constraints/

تصور کنید یک لوله آب داریم که گنجایش آن ۵ لیتر بر ثانیه است. چقدر آب از این لوله عبور می‌کند؟ دقیقاً ۵ لیتر. حالا تصور کنید دو لوله با همین ظرفیت (۵ لیتر) را به صورت پشت سر هم به هم وصل کنیم. خروجی آب چقدر خواهد بود؟ باز هم ۵ لیتر. حالا بیایید کمی شرایط را تغییر دهیم. چه اتفاقی می‌افتد اگر ظرفیت لوله دوم را به ۲۰ لیتر افزایش دهیم؟ خروجی نهایی چقدر می‌شود؟ همان ۵ لیتر! چرا؟ چون ورودی آن همان ۵ لیتر بوده است. فرقی نمی‌کند لوله دوم چقدر بزرگ باشد، حتی اگر ظرفیت آن یک میلیون لیتر باشد، خروجی نهایی همان چیزی است که از لوله اول واردش شده است. و برعکس، اگر ظرفیت لوله اول را به ۲۰ لیتر برسانیم و لوله دوم همان ۵ لیتر باقی بماند، خروجی چقدر است؟ باز هم ۵ لیتر. کاربرد این مثال در دنیای واقعی ???

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

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

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

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

اما تقریباً همیشه شکست می‌خوریم. چرا؟ چون زمین را آماده نکرده‌ایم. فرهنگ سازمانی، مهارت‌های تیم، فرآیندهای موجود و حتی طرز فکر ما، همان «خاک» است. اگر این خاک برای پذیرش تغییر آماده نباشد، بهترین و بزرگ‌ترین ایده‌ها هم در آن ریشه نمی‌دوانند. راه حل، شاید در پیروی از منطق طبیعت باشد. به جای تلاش برای یک تغییر بزرگ و ناگهانی، باید بپرسیم: آن «گیاه پیشگام» در محیط ما چیست؟ آن کوچک‌ترین، ساده‌ترین و جان‌سخت‌ترین تغییری که می‌توانیم همین امروز ایجاد کنیم و شرایط را حتی به اندازه‌ی یک ذره، بهتر کند، چیست؟ شاید این تغییر، فقط اصلاح روش برگزاری جلسات هفتگی‌مان باشد. شاید یادگیری یک مهارت نرم‌افزاری جدید توسط یکی از اعضای تیم باشد. یا شاید ایجاد یک کانال ارتباطی جدید برای شنیدن بازخوردها. این‌ها شاید در نگاه اول بی‌اهمیت به نظر برسند، اما همین تغییرات کوچک، مثل همان گیاهان پیشگام، به تدریج خاک سازمان را آماده می‌کنند. اعتماد را کمی بیشتر می‌کنند، یک مهارت جدید اضافه می‌کنند، یا یک مسیر ارتباطی را باز می‌کنند. و این‌ها، شرایط را برای تغییر بعدی، که شاید کمی بزرگ‌تر باشد، مهیا می‌کنند. تغییر پایدار، کاشتنی است، نه نصب‌کردنی. نیاز به صبر و باغبانی دارد. باید از خودمان بپرسیم به جای تلاش برای کاشتن یک جنگل آماده، چطور می‌توانیم امروز اولین بذر یک بوته‌ی کوچک را در خاک سازمان‌مان بکاریم و با حوصله منتظر بمانیم تا زمین برای قدم‌های بعدی آماده شود؟ شاید ما در سازمان‌هایمان به «باغبانان تغییر» بیشتری نیاز داریم تا «مدیران تغییر». https://blog.scrum.ir/2025/08/forest-succession-and-organizational-change/

چند وقت پیش، از نزدیک شاهد کار کردن یک تیم استارتاپی بودم. تیمی پر از آدم‌های باهوش و متخصص که هر کدام در کار خودشان بهترین بودند. اما مثل هر گروهی، پتانسیل بالایی برای تنش، ناهماهنگی و جنگ‌های پنهان بر سر قدرت و دیده شدن وجود داشت. در این میان، یک نفر بود که به نظرم معمار موفقیت آن گروه بود. او مدیرعامل نبود، حتی ارشدترین عضو فنی هم نبود. کارش این بود که بین آدم‌ها پل می‌زد. در جلسات، وقتی بحث داغ می‌شد و صداها بالا می‌رفت، او کسی بود که با یک سؤال هوشمندانه، فضا را آرام می‌کرد و بحث را به مسیر اصلی برمی‌گرداند. حواسش بود که عضو خجالتی‌تر و ساکت‌تر تیم هم فرصت حرف زدن پیدا کند. وقتی کسی ایده‌ای می‌داد، به جای نقد فوری، سعی می‌کرد نقاط قوتش را پیدا کند و بگوید: «چه جالب! چطور می‌تونیم این ایده رو به اون پیشنهاد قبلی وصل کنیم؟». او در واقع «هوش جمعی» تیم را مدیریت می‌کرد. این تجربه من را به فکر فرو برد. ما در فرهنگ کاریمان معمولاً غرق در ستایش از «نابغه‌های تنها» هستیم. همان بنیان‌گذار افسانه‌ای که در گاراژ خانه‌اش یک‌تنه دنیا را تغییر می‌دهد. اما حقیقت این است که نوآوری‌های بزرگ، تقریباً همیشه یک ورزش تیمی هستند. هوش جمعی یک گروه، از میانگین هوش تک‌تک اعضای آن بسیار قدرتمندتر است. اما این هوش جمعی خودبه‌خود به وجود نمی‌آید؛ نیاز به یک معمار دارد. همان «چسب تیم». این افراد سه قدرت ویژه دارند که شاید خودشان هم از آن بی‌خبر باشند: ۱. درک عمیق و همدلی: یعنی فقط حرف‌های شما را نمی‌شنوند، بلکه احساسات و نیازهای پشت آن را هم درک می‌کنند. انگار یک رادار اجتماعی قوی دارند که به آنها اجازه می‌دهد داینامیک پنهان گروه را بفهمند. می‌دانند چه کسی با چه کسی بهتر کار می‌کند، چه کسی در چه زمینه‌ای تخصص دارد و چه کسی نیاز به کمی دلگرمی دارد تا بهترینِ خودش باشد. این توانایی باعث می‌شود افراد بهشان اعتماد کنند و آن‌ها به مرکز شبکه‌ی ارتباطی تیم تبدیل شوند. ۲. ارتباطات سازنده: این افراد در مکالماتشان به دیگران حس باارزش بودن می‌دهند. آن‌ها استاد «اعتمادِ اکتسابی» هستند؛ یعنی با رفتارشان کاری می‌کنند که شما به خودتان و توانایی‌هایتان بیشتر باور پیدا کنید. وقتی آن‌ها از شما تعریف می‌کنند یا مسئولیتی را به شما می‌سپارند، این پیام را منتقل می‌کنند که: «من به تو باور دارم و می‌دانم که از پسش برمی‌آیی.» این باور، مثل یک پیش‌بینی خودمحقق‌شونده عمل می‌کند و باعث می‌شود افراد فراتر از انتظار ظاهر شوند. حتی موقع انتقاد هم، آن‌ها به جای تخریب، روی پتانسیل رشد فرد تمرکز می‌کنند. ۳. توزیع عادلانه توجه: در هر جلسه‌ای، معمولاً یک یا دو نفر تمام زمان صحبت را به خودشان اختصاص می‌دهند و بقیه به شنونده تبدیل می‌شوند. این الگو، هوش جمعی را نابود می‌کند. معماران تیم حواسشان به این موضوع هست. آن‌ها خودشان کمتر حرف می‌زنند و بیشتر نقش یک رهبر ارکستر را بازی می‌کنند. با پرسیدن سؤال از افراد ساکت‌تر، یا با جمع‌بندی هوشمندانه و ایجاد فضا برای دیگران، کاری می‌کنند که توپ مدام در زمین بچرخد و همه در بازی مشارکت داشته باشند. آن‌ها نمی‌گذارند صدای کسی در هیاهوی دیگران گم شود. خبر خوب این است که این یک ویژگی ذاتی و جادویی نیست، بلکه یک «مهارت» است. یعنی همه‌ی ما می‌توانیم یاد بگیریم که چطور به چسب تیم خودمان تبدیل شویم. چطور؟ نقاط قوت آدم‌ها را بشناسیم و به بازی بگیریم. مراقب زمان صحبت باشیم. در جلسات بعدی، به طور ذهنی حواستان باشد که چه کسانی بیشتر صحبت می‌کنند. آگاهانه تلاش کنید از بقیه هم نظر بخواهید. یک تکنیک ساده این است که قبل از شروع بحث، از همه بخواهید چند دقیقه در سکوت ایده‌هایشان را روی کاغذ بنویسند. این کار به افراد درون‌گراتر کمک می‌کند تا با آمادگی بیشتری در بحث شرکت کنند. در نهایت، ستاره‌ی واقعی یک تیم بودن، شاید به معنی درخشش فردی نباشد. شاید قهرمانی واقعی این است که به جای تلاش برای بهترین بودن، تلاش کنیم بهترین‌ها را از دیگران بیرون بکشیم. کسی باشیم که حضورش، مجموعه‌ای از افراد را به چیزی بزرگتر از اجزایشان تبدیل می‌کند.