Iran Agile

جمعه‌ی گذشته در سومین جلسه‌ی AI-Native Engineering درباره‌ی معماری نرم‌افزار و تأثیر ایجنت‌های هوش مصنوعی بر تصمیم‌های معماری گفت‌وگو کردیم. ویدیوی کامل جلسه را در یوتیوب میتوانید مشاهده کنید: 🎥 https://youtu.be/eJLcg3WrJpo

معرفی رویداد 🚀 AI-Native Engineering and the Future of Software Development این بار تمرکز ما روی معماری نرم افزار است؛ اینکه وقتی ایجنت‌ها شروع به نوشتن، تغییر دادن و بازبینی کد می‌کنند، معماری نرم‌افزار چطور باید تغییر کند یا نقش این معماری در بهینه سازی خروجی چیست؟ 📅 تاریخ: جمعه ۲۶ تیرماه 🕢 ساعت: ۱۹:۳۰ به وقت تهران 🎙️ با حضور: اسد صفری، هادی احمدی و رضا جان‌محمدی این رویداد آنلاین و رایگان است. لینک ثبت نام: https://luma.com/fh7ksh44

ویدیوی جلسه دوم AI-Native Engineering منتشر شد. در این گفت‌وگو درباره‌ی Harness Engineering و نقش آن در ساخت Agent هوش مصنوعی قابل‌اعتماد، قابل‌کنترل و هماهنگ با معماری سیستم صحبت کردیم. 🎥 ویدیوی کامل: https://youtu.be/ZpAPYZE9Uhs

این روزها، در حالی که بسیاری از مردم ما در ایران درگیر ابتدایی‌ترین مسائل زیرساختی هستیم، از قطعی و اختلال طولانی اینترنت گرفته تا تغییر ناخواسته پارادایم از «توسعه و پیشرفت» به «بقا و زنده ماندن»، دنیای نرم‌افزار در دنیا با سرعتی عجیب در حال تغییر است. مسئله فقط این نیست که ابزارهای جدیدی آمده‌اند. تغییر عمیق‌تر از این حرف‌هاست. ما در حال ورود به دوره‌ای هستیم که به آن AI-native Engineering می‌گویند؛ یعنی مهندسی نرم‌افزاری که از ابتدا با حضور ایجنت های هوش مصنوعی طراحی می‌شود، نه این‌که AI فقط یک ابزار کمکی کنار تیم باشد. در این مدل جدید، بخش زیادی از کدنویسی، تست، بازبینی، مستندسازی و حتی طراحی فنی می‌تواند توسط ایجنت‌های هوش مصنوعی انجام شود. بعضی تیم‌ها حتی دارند به سناریوهایی نزدیک می‌شوند که تقریباً تمام تولید کد توسط AI انجام می‌شود و نقش انسان بیشتر به سمت تعریف مسئله، تصمیم‌گیری، قضاوت، کنترل کیفیت و هدایت سیستم حرکت می‌کند. برای صنعت نرم‌افزار ایران، این می‌تواند یکی از بزرگ‌ترین شکاف‌های تاریخی با جریان اصلی دنیا باشد. چون وقتی ما هنوز برای اتصال پایدار، دسترسی به ابزارها، پرداخت بین‌المللی، زیرساخت و حتی تمرکز ذهنی می‌جنگیم، آن طرف دنیا بحث از این است که «اگر AI کد می‌نویسد، پس کار اصلی تیم‌های محصول و مهندسی چه می‌شود؟» یکی از ترندهایی که در همین فضا جدی‌تر شده، مفهومی است به نام Spec-Driven Development یا توسعه مبتنی بر اسپک. اما این یعنی چه؟ و چرا برای جامعه نرم افزار و اجایل مهم است؟ ایده‌اش در ظاهر ساده است: به‌جای این‌که سریع برویم سراغ کدنویسی و بعداً تلاش کنیم بفهمیم دقیقاً چه ساخته‌ایم، اول نیت، رفتار مورد انتظار، محدودیت‌ها، سناریوها و معیار پذیرش را روشن می‌کنیم. بعد از آن، AI یا تیم توسعه بر اساس همان اسپک شروع به تولید کد، تست و تسک‌های اجرایی می‌کند. اما این فقط یک اسم جدید برای مستندسازی قدیمی نیست. در روش‌های سنتی، خیلی وقت‌ها داکیومنت نوشته می‌شد، بعد در یک فولدر گم می‌شد، و تیم در عمل با برداشت‌های شخصی جلو می‌رفت. در SDD، اسپک قرار است یک فایل تزئینی نباشد؛ قرار است «منبع اصلی قابل اعتماد» باشد. یعنی همان چیزی که محصول، طراحی، معماری، کد و تست باید مدام به آن برگردند. اهمیت این موضوع با AI بیشتر شده است. چون AI می‌تواند خیلی سریع کد تولید کند، اما اگر مسئله مبهم باشد، خروجی هم فقط سریع‌تر اشتباه خواهد شد. سرعت بدون وضوح، لزوماً چابکی نیست؛ گاهی فقط تولید سریع‌تر ابهام است. برای جامعه چابک این نکته مهمی است. ما سال‌ها درباره user story، acceptance criteria، refinement، alignment و shared understanding صحبت کرده‌ایم. SDD در بهترین حالت ادامه همان گفت‌وگوست، اما در دنیایی که AI هم وارد تیم شده. یعنی دیگر فقط انسان‌ها نیاز به فهم مشترک ندارند؛ ابزارهای AI هم باید از یک کانتکست شفاف و ساختارمند تغذیه شوند. یک مثال ساده: فرض کنید می‌خواهیم قابلیت «لغو سفارش» را بسازیم. در حالت معمول ممکن است یک نفر بگوید: «کاربر باید بتواند سفارش را لغو کند.» اما این کافی نیست. تا چه زمانی؟ قبل از ارسال؟ بعد از پرداخت؟ پول چطور برمی‌گردد؟ اگر سفارش بخشی از یک بسته باشد چه؟ پیامی که به کاربر نشان میدهیم چیست؟ وضعیت سفارش در سیستم‌های دیگر چه می‌شود؟ در SDD، این سؤال‌ها باید زودتر روشن شوند. نه برای سنگین‌کردن فرایند، بلکه برای کم‌کردن دوباره‌کاری، سوءتفاهم و خروجی‌های نصفه‌نیمه. البته SDD قرار نیست جای گفت‌وگوی واقعی با کاربر، رویکرد محصولی، طراحی خوب یا مهندسی حرفه‌ای را بگیرد. یک اسپک بد، فقط باعث می‌شود AI با اعتمادبه‌نفس بیشتری چیز اشتباهی بسازد. حتی با اسپک خوب هم باید خروجی بررسی شود، تست شود و با واقعیت کسب‌وکار سنجیده شود. به نظرم نگاه بالغ به SDD این است: نه بازگشت به waterfall است، نه جادوی AI. بلکه تلاشی است برای این‌که در عصر AI، «نیت انسانی» گم نشود. در آینده نزدیک، شاید بخش زیادی یا حتی تمام کد را AI بنویسد. اما این‌که چه چیزی باید ساخته شود، چرا باید ساخته شود، برای چه کسی ارزش دارد، و چه چیزی قابل قبول است، هنوز مسئولیت تیم محصول و تیم توسعه است. پس شاید جمله کلیدی این باشد: در دنیای AI-native، مزیت تیم‌ها فقط سرعت تولید کد نیست؛ کیفیتِ بیان مسئله است.

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

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

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

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

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

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

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

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

سرمقاله امروز HBR - چرا هر تیم نیاز به یک super-facilitator دارد؟ https://hbr.org/2025/09/every-team-needs-a-super-facilitator?ab=HP-hero-featured-1

سرمقاله امروز HBR - چرا هر تیم نیاز به یک super-facilitator دارد؟ https://hbr.org/2025/09/every-team-needs-a-super-facilitator?ab=HP-hero-featured-1