eitaa logo
اجایل تاک | Agile Talk
106 دنبال‌کننده
109 عکس
10 ویدیو
0 فایل
اجایل تاک، محلی برای یادگیری، گفتگو و رشد در مسیر چابکی 🔶️مشاوره، آموزش و منتورینگ چابک 📞راههای ارتباطی: 🔹️محمود متین‌فر 09127509082 🔹️هاشم عمرانی 09352361283 گروه اجایل تاک: @agile_talk_group ایتا، تلگرام، اینستاگرام و لینکدین: @agile_talk
مشاهده در ایتا
دانلود
🎯وبینار هدفگذاری هوشمند، اجرای موثر اگر در سازمانی، هدف‌گذاری به برنامه‌های متعدد و اجرای استراتژی به فهرستی از کارهای روزمره تبدیل شده، احتمالاً مسئله فقط نداشتن استراتژی نیست؛ بلکه مسئله، فاصله میان «دانستن اینکه چه چیزی مهم است» و «توانایی اجرای مؤثر آن» است. در وبینار وبینار هدفگذاری هوشمند، اجرای موثر، یاد می‌گیریم چگونه روی مهم‌ترین اهداف تمرکز کنیم و آن‌ها را به نتایج کلیدی قابل‌فهم تبدیل کنیم و سپس با ذهنیت Agile، با تکیه بر بازخورد، یادگیری، تحویل تدریجی و انطباق، مسیر رسیدن به این اهداف را در دنیای متغیر و پیچیده امروز مدیریت کنیم. 🔖سرفصل های وبینار: 1- چراسازمان ها در اجرای استراتژی شکست میخورند؟ 2- هدفگذاری هوشمند با OKR 3- اجرای موثر با Agile 4- قدرت ترکیب OKR , Agile 5- نمونه های کاربردی در صنایع مختلف 👨‍🏫ارائه دهندگان: 🔹مهدی عرب عامری مشاور، مربی و تسهیلگر OKR 🔹محمود متین فر مربی Agile و تسهیلگر OKR 📆زمان وبینار: شنبه 17 مرداد 1405 🕔ساعت 17 الی 19 🔗لینک ثبت نام: https://evnd.co/FpjUf
🌟کار تموم، تحویل نه! توی خیلی از تیم‌ها، وقتی از اعضای تیم می‌پرسی «این کار تموم شده؟»، معمولاً جواب مثبته. یکی میگه: «بخش مربوط به من انجام شده.» یکی دیگه میگه: «من تحویلش دادم.» و نفر بعدی میگه: «فقط تأیید نهایی مونده.» مشکل اینجاست که هر کس از زاویه مسئولیت خودش به کار نگاه می‌کنه؛ در حالی که تیم باید یک تعریف مشترک از "تمام شدن" داشته باشه. تا وقتی خروجی، همه معیارهای مورد توافق تیم رو نگذرانده باشه، هنوز قابل تحویل نیست؛ حتی اگر ساعت‌ها برای انجامش زمان صرف شده باشه. 🎯یکی از بهترین راهکارها اینه که تیم، Definition of Done (DoD) خودش رو شفاف تعریف کنه؛ یعنی دقیقاً مشخص باشه یک کار برای اینکه Done محسوب بشه، باید چه معیارهایی رو داشته باشه. از اون مهم‌تر، هیچ کاری قبل از عبور از این معیارها Done اعلام نشه. وقتی تعریف Done بین همه اعضای تیم مشترک باشه، اختلاف برداشت‌ها کمتر میشه، دوباره‌کاری کاهش پیدا می‌کنه و خروجی‌های تیم با کیفیت و اطمینان بیشتری تحویل داده میشن. 🔗لینک مطلب در لینکدین ✍️محمود متین فر؛ راهبر چابکی کسب و کار •┈┈••••✾•🌿🌸🌿•✾•••┈┈• 🔷در فضای مجازی با اجایل تاک همراه باشید: 🔹@agile_talk
🌟چرا تیم‌ها خوب کار می‌کنند، اما نتیجه دلخواه حاصل نمی‌شود؟ توی خیلی از سازمان‌ها، تیم‌ها واقعاً با انگیزه و پرتلاش کار می‌کنن. جلسات برگزار میشه، پروژه‌ها جلو میرن و کارها یکی بعد از دیگری انجام میشن. اما آخر فصل که می‌رسیم، مدیرها یه سؤال دارن: این همه تلاش، دقیقاً چه تغییری در کسب‌وکار ایجاد کرد؟ مشکل معمولاً کم‌کاری تیم‌ها نیست؛ شفاف نبودن هدف‌ها و نداشتن یک مسیر مشترکه. اینجاست کهOKR وارد میشه. OKR کمک می‌کنه همه بدونن مهم‌ترین هدف سازمان چیه، چرا این هدف مهمه و موفقیت دقیقاً با چه نتیجه‌ای سنجیده میشه. اما فقط داشتن هدف کافی نیست. وقتی تیم‌ها نتونن با تغییرات سازگار بشن، سریع بازخورد بگیرن، اولویت‌ها رو مدیریت کنن و تمرکزشون رو حفظ کنن، حتی بهترین هدف‌ها هم روی کاغذ می‌مونن. اینجاست که چابکی نقش خودش رو نشون میده. سیستم هدف گذاری OKR مشخص می‌کنه مهم‌ترین مقصد سازمان چیه و روی چه چیزهایی باید تمرکز کنیم. چابکی کمک می‌کنه با یادگیری، بازخورد و تحویل مستمر، به همون مقصد برسیم. به همین دلیله که من همیشه معتقدم OKR و چابکی رقیب هم نیستن؛ مکمل همدیگه‌ان. یکی کمک می‌کنه کار درست رو انتخاب کنیم و دیگری کمک می‌کنه اون کار رو درست اجرا کنیم. ✍️محمود متین فر؛ راهبر چابکی کسب و کار 🔗لینک مطلب در لینکدین •┈┈••••✾•🌿🌸🌿•✾•••┈┈• 🔷در فضای مجازی با اجایل تاک همراه باشید: 🔹@agile_talk
🌟بکلاگ شلوغ، اهداف فراموش‌شده! وقتی OKRهای فصل نوشته میشن، طبیعتاً انتظار داریم اولویت‌های تیم هم تغییر کنه. اما توی خیلی از تیم‌ها، اتفاق عجیبی میفته. اهداف و نتایج کلیدی (OKR) جدید تعریف میشه، ولی بکلاگ (Backlog) تقریباً همون قبلی می‌مونه. کارهای قدیمی همچنان در اولویت هستن، درخواست‌های جدید هم یکی‌یکی اضافه میشن و بعد از مدتی، دیگه تشخیص اینکه واقعاً مهم‌ترین کار تیم چیه، سخت میشه. بکلاگ قرار نیست فقط فهرست کارهای تیم باشه؛ باید بازتاب مهم‌ترین اولویت‌های امروز سازمان باشه. اگر بعد از تعریف OKR، Backlog دوباره بازنگری و اولویت‌بندی نشه، تیم با اولویت‌های دیروز، دنبال هدف‌های امروز حرکت می‌کنه. 🎯یکی از ساده‌ترین و مؤثرترین Practiceها اینه که با شروع هر دوره OKR، قبل از هر برنامه‌ریزی، یک Backlog Refinement واقعی انجام بدین؛ آیتم‌هایی که به اولویت‌های این فصل کمک نمی‌کنن پایین بیارdن، بعضی‌ها را حذف کنین و کارهایی را در بالای Backlog نگه دارین که بیشترین اثر را روی هدف‌های فعلی سازمان دارن. درحقیقت OKR فقط هدف‌های جدید ایجاد نمی‌کنه؛ باید اولویت‌های Backlog را هم تغییر بده. ✍️محمود متین فر؛ راهبر چابکی کسب و کار 🔗لینک مطلب در لینکدین •┈┈••••✾•🌿🌸🌿•✾•••┈┈• 🔷در فضای مجازی با اجایل تاک همراه باشید: 🔹@agile_talk
🌟سرعت تیم، پشت در اتاق مدیر! در خیلی از سازمان‌ها، حتی برای تصمیم‌های کوچک هم تیم منتظر تأیید مدیر می‌مونه. مدیر هم به‌مرور تبدیل میشه به گلوگاه تصمیم‌گیری؛ کارها متوقف میشن، سرعت پایین میاد و مدیر به‌جای تمرکز روی مسائل مهم‌تر، درگیر تصمیم‌های روزمره میشه. یکی از اصول مهم در تیم‌های چابک، خودمدیریت‌شونده بودن تیمه؛ یعنی تیم در چارچوب هدف، محدودیت‌ها و مسئولیت‌های مشخص، درباره نحوه انجام کارش اختیار تصمیم‌گیری داشته باشه. راهکار اینه که مدیر هدف، انتظارات و محدودیت‌ها رو شفاف کنه، مرز اختیار تیم رو مشخص کنه و تصمیم‌ها رو تا حد ممکن به نزدیک‌ترین سطح به کار منتقل کنه. در این شرایط، تیم در محدوده اختیارش تصمیم می‌گیره و در برابر نتیجه تصمیم‌ها هم پاسخگو می‌مونه. مدیر چابک قرار نیست همه تصمیم‌ها رو بگیره؛ باید سیستمی بسازه که تصمیم درست، در نزدیک‌ترین نقطه به مسئله گرفته بشه. ✍️محمود متین فر؛ راهبر چابکی کسب و کار 🔗لینک مطلب در لینکدین •┈┈••••✾•🌿🌸🌿•✾•••┈┈• 🔷در فضای مجازی با اجایل تاک همراه باشید: 🔹@agile_talk
🌟کار در حال انجام یا در حال انتظار؟ توی کار با تیم‌های مختلف، بارها دیدیم یک آیتم چند روز روی برد و "در حال انجام" باقی می‌مونه؛ در حالی که تیم عملاً منتظر یک پاسخ، تصمیم، تایید مشتری، دسترسی یا رفع یک وابستگیه. مشکل از جایی جدی‌تر میشه که این وضعیت در جریان کار دیده نمی‌شه؛ آیتم همچنان In Progress (یا Doing) محسوب میشه، در حالی که بخش قابل‌توجهی از زمانش صرف انتظار (Waiting Time) شده. در مدیریت جریان کار، فقط مدت زمانی که تیم روی یک آیتم کار می‌کنه مهم نیست؛ زمانی که کار به‌دلیل یک مانع یا وابستگی متوقف شده هم باید دیده و مدیریت بشه. 🎯یه راهکار ساده اینه که وضعیت‌های Blocked رو شفاف کنین، علت توقف رو مشخص کنین و برای رفع موانع، مسئول پیگیری و مسیر مشخصی برای رفع اون‌ها داشته باشین. اگه یه وابستگی مرتب باعث توقف کار میشه، خود وابستگی رو هم به‌عنوان یه مسئله بررسی کنین و ببینین چطور میشه اونو کاهش داد، حذف کرد یا مؤثرتر مدیریت کرد. در بازبینی جریان کار، یک سؤال ساده می‌تونه کمک‌کننده باشه: کدام کار متوقف شده، چرا متوقف شده و چه چیزی باید تغییر کنه تا دوباره حرکت کنه؟ چون بهبود Flow فقط با سریع‌تر کار کردن اتفاق نمی‌افته؛ گاهی باید چیزی را که جلوی جریان را گرفته، پیدا و برطرف کنیم. ✍️محمود متین فر؛ راهبر چابکی کسب و کار 🔗لینک مطلب در لینکدین •┈┈••••✾•🌿🌸🌿•✾•••┈┈• 🔷در فضای مجازی با اجایل تاک همراه باشید: 🔹@agile_talk
🌟همه خوب کار می‌کنند؛ اما سازمان جلو نمی‌رود! در بعضی سازمان‌ها، اگر عملکرد هر واحد رو جداگانه بررسی کنیم، همه‌چیز خوب به نظر می‌رسه؛ فروش هدف خودش رو دنبال می‌کنه، تولید روی بهره‌وری تمرکز داره، مالی هزینه‌ها رو کنترل می‌کنه و فناوری هم پروژه‌های خودش رو جلو می‌بره. اما وقتی نتیجه نهایی کسب‌وکار رو نگاه می‌کنیم، تصویر متفاوته؛ چون هر واحد ممکنه در حال بهینه‌سازی عملکرد خودش باشه، اما لزوماً در حال بهینه‌سازی نتیجه کل سازمان نباشه. اینجاست که سیلوهای سازمانی و اهداف متعارض، چابکی رو محدود می‌کنن. 🎯 راهکار فقط بیشتر کردن جلسات بین واحدها نیست. در OKR، بخشی از اهداف باید حول نتیجه مشترک کسب‌وکار شکل بگیره تا واحدها به‌جای دنبال کردن موفقیت خودشون، ببینن چطور می‌تونن روی یک نتیجه مشترک اثر بذارن. این یعنی ایجاد هم‌راستایی (Alignment) بین اهداف تیم‌ها و سازمان. بعد هم در بازبینی‌های دوره‌ای، فقط عملکرد هر واحد رو جداگانه بررسی نکنیم؛ ببینیم مجموع این تلاش‌ها چقدر ما رو به نتیجه مشترک نزدیک کرده. چابکی زمانی در سازمان شکل می‌گیره که واحدها فقط کار خودشون رو خوب انجام ندن؛ بلکه برای نتیجه مشترک کسب‌وکار با هم کار کنن. ✍️محمود متین فر؛ راهبر چابکی کسب و کار •┈┈••••✾•🌿🌸🌿•✾•••┈┈• 🔷در فضای مجازی با اجایل تاک همراه باشید: 🔹@agile_talk
🌟اسپرینت تمام شد؛ خروجی هنوز آماده نیست! توی کار با تیم‌های مختلف، یکی از مشکلاتی که زیاد می‌بینم اینه که تیم بخش زیادی از اسپرینت رو صرف توسعه می‌کنه و تازه در روزهای آخر، کارها به تست می‌رسن. روی برد همه‌چیز تقریباً Done به نظر میاد، اما در واقع چند آیتم منتظر تست، رفع باگ یا تأیید نهایی هستن. نتیجه هم معمولاً مشخصه: آخر اسپرینت حجم زیادی کار نیمه‌تمام جمع میشه، فشار روی تیم بالا میره و بخشی از کارها به Sprint بعد منتقل میشن. 🎯یکی از راهکارها اینه که یادمون باشه تست نباید آخرین ایستگاه کار باشه و تیم به‌جای توسعه تعداد زیادی آیتم و انتقال همه آن‌ها به تست در روزهای پایانی، تعداد کمتری آیتم رو از ابتدا تا انتها جلو ببره؛ یعنی توسعه، تست و رفع مشکل در همان جریان انجام بشه. در کنار این، معیارهای پذیرش و Definition of Done باید از ابتدا شفاف باشن تا «توسعه انجام شده» با «کار واقعاً تمام شده» اشتباه نشه. کار وقتی تمام شده که قابل تحویل باشد؛ نه وقتی توسعه‌اش تمام شده باشد. ✍️محمود متین فر؛ راهبر چابکی کسب و کار •┈┈••••✾•🌿🌸🌿•✾•••┈┈• 🔷در فضای مجازی با اجایل تاک همراه باشید: 🔹@agile_talk
🌟چرا OKR در بعضی شرکت‌ها شکست می‌خورد؟ توی بعضی سازمان‌ها، OKR با انرژی زیادی شروع میشه، آموزشها انجام میشه، جلسه هدف‌گذاری برگزار میشه، Objective و Key Result نوشته میشن و حتی برای پیشرفت‌شون گزارش هم تهیه میشه. اما چند ماه بعد، OKR کم‌کم تبدیل میشه به یک فایل، داشبورد یا گزارش دوره‌ای که باید به‌روزرسانی بشه، در حالی که تصمیم‌های واقعی کسب‌وکار همچنان جای دیگه‌ای گرفته میشن. یکی از دلایل مهم این اتفاق، حمایت نکردن واقعی مدیر ارشده. گاهی مدیر با اجرای OKR موافقت می‌کنه، اما خودش در تصمیم‌ها و اولویت‌های مدیریتی به اون توجهی نداره. در نتیجه OKR تبدیل میشه به چیزی که «باید اجرا بشه»، نه ابزاری که خود مدیریت هم باهاش سازمان رو هدایت کنه. 🎯 راهکار اینه که OKR باید وارد چرخه واقعی مدیریت بشه. مدیران ارشد باید در بازبینی‌ها حضور مؤثر داشته باشن و از OKR برای گفتگو درباره پیشرفت، موانع، یادگیری و تصمیم‌های مهم کسب‌وکار استفاده کنن. اگر OKR اولویت‌های مدیریت رو تغییر نده، به‌سختی می‌تونه اولویت‌های سازمان رو تغییر بده. در نهایت، فقط نوشتن OKR کافی نیست. OKR زمانی اثرگذار میشه که از یک فرآیند هدف‌گذاری به بخشی از سیستم مدیریت سازمان تبدیل بشه. ✍️محمود متین فر؛ راهبر چابکی کسب و کار •┈┈••••✾•🌿🌸🌿•✾•••┈┈• 🔷در فضای مجازی با اجایل تاک همراه باشید: 🔹@agile_talk
همه‌چیز تحویل می‌دهیم؛ اما آیا واقعاً ارزش ایجاد می‌کنیم؟ یکی از چیزهایی که گاهی اوقات در کار با تیم‌های چابک می‌بینم، اینه که تیم موفقیت رو با تعداد کارهای تحویل‌شده می‌سنجه؛ چند Feature تمام کردیم؟ چند تسک بسته شد؟ چند آیتم از Backlog خارج شد؟ اینجا معمولاً یک تفاوت مهم گم میشه: Output با Outcome فرق داره. خروجی یا Output یعنی چیزی که تیم تولید میکنه و تحویل میده؛ مثلاً یک قابلیت جدید، یک گزارش یا یک ویژگی. اما Outcome یعنی تغییری که در نتیجه آن خروجی برای کاربر یا کسب‌وکار اتفاق می‌افته؛ مثلاً افزایش استفاده، کاهش زمان انجام کار، کاهش خطا یا افزایش رضایت مشتری. یک نشونه ساده برای تشخیص این مسئله وجود داره: اگر بعد از تحویل یک Feature، اولین سؤال تیم این باشه که «تسک بسته شد؟»، احتمالاً بیشتر حواسمون به Output بوده. اما اگر بپرسیم «این کاری که انجام دادیم چه تغییری ایجاد کرد؟ چه ارزشی خلق کرد؟»، داریم به Outcome نزدیک می‌شیم. راهکار این نیست که Output رو کنار بذاریم. تیم باید خروجی تولید کنه؛ اما برای یک یا مجموعه ای از خروجی ها، انتظار داریم یک نتیجه مشخص هم ایجاد بشه. قبل از شروع کار بپرسیم: «قرار است چه تغییری ایجاد کنیم؟» و بعد از تحویل هم بررسی کنیم: «آیا واقعاً این تغییر اتفاق افتاد؟» یه تیم چابک تیمی نیست که صرفا سریع‌تر تحویل میده؛ تیمیه که یاد میگیره چه چیزی ارزش تحویل دادن داره ✍️محمود متین فر؛ راهبر چابکی کسب و کار ┈••••✾•🌿🌸🌿•✾•┈• 🔷در فضای مجازی با اجایل تاک همراه باشید: 🔹@agile_talk
🌟از اجرای Agile تا چابک شدن، یک فاصله جدی وجود دارد. یکی از اشتباهات رایج در مسیر چابکی اینه که بعضی مدیران، داشتن Sprint، Planning، Daily و استفاده از جیرا رو نشانه چابک شدن می‌دونن. در حالی که این‌ها بخشی از نحوه اجرای چابک هستن، نه تمام مفهوم چابکی؛ آن هم به شرطی که همین رویدادها درست و با هدف واقعی اجرا بشن. ما می‌تونیم فرآیند اسکرام رو دقیق انجام بدیم، اما هنوز تصمیم‌ها کند باشن، مدیر همه‌چیز رو خودش تعیین کنه، تیم‌ها منتظر دستور بمونن، تغییر تهدید تلقی بشه و از اشتباه و یادگیری فرار کنیم. در چنین شرایطی، فقط ظاهر Agile رو ساخته‌ایم، نه چابکی رو. از طرف دیگه، گاهی حتی همین اجرای ناقص رو هم به‌درستی انجام نمی‌دیم و بعد نتیجه می‌گیریم «Agile برای سازمان ما جواب نمی‌ده!» خوبه که قبل از قضاوت درباره Agile، بررسی کنیم آیا واقعاً اصولش را اجرا کرده‌ایم یا فقط مراسم و ابزارهاش را؟ چابکی زمانی اتفاق میفته که پاسخ به تغییر، همکاری، یادگیری و بهبود مستمر، از جلسه‌ها خارج بشن و وارد رفتار روزمره سازمان و تصمیم‌های مدیریتی بشن. ✍️محمود متین فر؛ راهبر چابکی کسب و کار 🔗 لینک مطلب در لینکدین •┈┈••••✾•🌿🌸🌿•✾•••┈┈• 🔷در فضای مجازی با اجایل تاک همراه باشید: 🔹@agile_talk
اسپرینت را با لیست کار شروع می‌کنید یا با هدف؟ یکی از چیزهایی که در تیم‌های Scrum زیاد می‌بینیم اینه که Sprint Planning تبدیل میشه به یک جلسه تقسیم کار. تیم میگه: «این Story رو برمی‌داریم، اینم انجام می‌دیم، اینم اگر شد...» بعد Sprint شروع میشه و هرکس میره سراغ کار خودش. آخر Sprint هم ممکنه چند استوری Done شده باشه. اما وقتی می‌پرسیم: "این Sprint قرار بود چه تغییری در محصول ایجاد کنه؟" جواب مشخصی نداریم. در اسکرام، Sprint Goal اهمیت ویژه ای داره و قرار نیست یک جمله تزئینی باشه. قراره به تیم یک هدف مشترک بده تا انتخاب و اجرای کارها حول اون شکل بگیره حتی خود Scrum Guide، هدف اسپرینت را تعهد Sprint Backlog میدونه. پس در Planning فقط نپرسیم: «چه کارهایی رو توی این اسپرینت انجام بدیم؟» قبلش بپرسیم: «تا پایان این اسپرینت، دقیقاً می‌خواهیم چه چیزی را بهبود بدهیم یا به چه نتیجه‌ای برسیم؟» بعد کارهایی که برای رسیدن به اون نتیجه باید انجام بشه رو انتخاب کنیم برای انجام. وقتی هدف روشن باشه، اگر وسط Sprint هم شرایط تغییر کرد، تیم راحت‌تر تشخیص میده چه چیزی واقعاً مهمه و چه چیزی فقط یک کار اضافه است. ✍️محمود متین فر؛ راهبر چابکی کسب و کار 🔗 لینک مطلب در لینکدین •┈┈••••✾•🌿🌸🌿•✾•••┈┈• 🔷در فضای مجازی با اجایل تاک همراه باشید: 🔹@agile_talk