en
Feedback
تجربه‌نگاری‌های نوا

تجربه‌نگاری‌های نوا

Open in Telegram

🤍نسیم نوائی | PMO • Agile • Jira 🤍مدیریت پروژه، چابکی و سیستم‌سازی تیم‌ها 🤍منتورینگ فردی | راه‌اندازی Jira سازمانی 🎓MSc Computer Networks, IUST | BSc IT, Tabriz 🪽کانال نظرات همراهی‌ها @withnavaei

Show more
The country is not specifiedThe category is not specified
346
Subscribers
+124 hours
+267 days
+2830 days
Posts Archive
فصل همچنین روی اندازهٔ تیم تأکید زیادی دارد. مغز انسان برای همکاری مؤثر با تعداد زیادی نفر ساخته نشده است. هرچه تیم بزرگ‌تر شود، تعداد ارتباطات ممکن به‌صورت نمایی بالا می‌رود و هماهنگی سخت‌تر می‌شود. به همین دلیل، قاعدهٔ سرانگشتی این است که تیم باید کوچک بماند: حدود ۷ نفر، با دو نفر کم‌تر یا بیشتر. تیم کوچک‌تر سریع‌تر تصمیم می‌گیرد، بهتر می‌فهمد چه کسی چه کاری انجام می‌دهد، و راحت‌تر به یک زبان مشترک می‌رسد. در این فصل، اسکرام‌مستر به‌عنوان یک رهبر خدمتگزار معرفی می‌شود، نه یک مدیر سنتی. وظیفهٔ او این نیست که به تیم بگوید دقیقاً چه کار کند؛ بلکه باید شرایطی ایجاد کند که تیم بتواند بهترین کار خود را انجام دهد. او باید موانع را حذف کند، تمرکز تیم را حفظ کند، جریان ارتباط را ساده کند و اجازه دهد تیم خودش راه‌حل پیدا کند. به‌بیان دیگر، اسکرام‌مستر به تیم خدمت می‌کند تا تیم بتواند بدرخشد. در این فصل، اسکرام‌مستر به‌عنوان یک رهبر خدمتگزار معرفی می‌شود، نه یک مدیر سنتی. وظیفهٔ او این نیست که به تیم بگوید دقیقاً چه کار کند؛ بلکه باید شرایطی ایجاد کند که تیم بتواند بهترین کار خود را انجام دهد. او باید موانع را حذف کند، تمرکز تیم را حفظ کند، جریان ارتباط را ساده کند و اجازه دهد تیم خودش راه‌حل پیدا کند. به‌بیان دیگر، اسکرام‌مستر به تیم خدمت می‌کند تا تیم بتواند بدرخشد. برای توضیح اینکه چرا درک رفتار انسان باید با احتیاط باشد، فصل به خطای بنیادی تبیین اشاره می‌کند. انسان‌ها معمولاً رفتار دیگران را به شخصیت و ذات آن‌ها نسبت می‌دهند، اما رفتار خودشان را نتیجهٔ شرایط می‌دانند. این خطاست. بسیاری از کارهایی که از بیرون به «بد بودن فرد» شبیه‌اند، در واقع نتیجهٔ سیستم، فشار محیط، محدودیت زمانی یا ساختار سازمانی‌اند. مثال‌های کتاب نشان می‌دهند که وقتی سیستم درست طراحی شود، همان آدم‌هایی که قبلاً ضعیف یا حتی خرابکار به نظر می‌رسیدند، می‌توانند عملکردی عالی داشته باشند. در ادامه، آزمایش میلگرام آورده می‌شود؛ یکی از تکان‌دهنده‌ترین نمونه‌ها برای نشان دادن قدرت اقتدار و اطاعت. در این آزمایش، فرد عادی از طرف شخصی با روپوش سفید و ظاهر علمی تشویق می‌شود که شوک‌های الکتریکیِ شدیدتری به فردی دیگر بدهد. آن فردِ دیگر فریاد می‌زند، التماس می‌کند، و حتی وانمود می‌کند که در خطر است، اما بسیاری از آزمودنی‌ها باز هم ادامه می‌دهند. نتیجهٔ میلگرام این بود که افراد عادی، اگر در یک سیستم اقتدارمحور قرار بگیرند، می‌توانند بدون خصومت شخصی، به عامل یک روند ویرانگر تبدیل شوند. پیام این آزمایش این است که همیشه نباید فقط افراد را سرزنش کرد؛ گاهی سیستم است که رفتار خطرناک تولید می‌کند. برای همین، فصل نمونه‌هایی مثل NUMMI را مطرح می‌کند تا نشان دهد مشکل همیشه «آدم‌های بد» نیستند. همان کارکنانی که در یک کارخانهٔ شکست‌خورده، ناکارآمد و حتی خرابکار به نظر می‌رسیدند، وقتی در یک سیستم بهتر قرار گرفتند، به تولیدی عالی و باکیفیت رسیدند. نتیجه روشن است: سیستم خوب می‌تواند رفتار خوب بسازد؛ سیستم بد می‌تواند آدم‌های عادی را به عملکرد بد بکشاند. در بخش‌های پایانی، فصل به لحظه‌ای می‌رسد که تیم واقعاً به سطح Great می‌رسد. اینجا دیگر تیم فقط جمع چند نفر نیست؛ به چیزی فراتر از مجموع اعضایش تبدیل می‌شود. هماهنگی، اعتماد، هدف مشترک و خودسازمان‌دهی باعث می‌شود تیم کارهایی انجام دهد که از بیرون شبیه جادو به نظر می‌رسد. در چنین تیمی، افراد لازم نیست همه‌چیز را کنترل کنند؛ کافی است به هم‌تیمی‌هایشان اعتماد داشته باشند و همه در خدمت یک هدف باشند. جمع‌بندی فصل روشن است: روی تیم تمرکز کنید، نه فقط روی فرد. تیم باید هدفی بزرگ‌تر از خودش داشته باشد. تیم باید اختیار عمل داشته باشد. تیم باید همهٔ مهارت‌های لازم را در خود جمع کند. تیم کوچک، سریع‌تر و مؤثرتر است. به‌جای سرزنش افراد، سیستم را اصلاح کنید. @navaeinotes

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

💡پیرویِ کورکورانه از قوانین (Shu) وقتی با ذهنیتِ «ثباتِ دنیا» (Waterfall) ترکیب شود، تیم را در دنیای پیچیده فلج می‌کند. اسکرام می‌گوید قوانین فقط شروع راه هستند؛ اگر نتوانید در پاسخ به محیط «تطبیق» پیدا کنید (فصل ۱) و از قواعد فراتر بروید (رسیدن به مرحله Ri در فصل ۲)، عملاً در مدلِ شکست‌خورده‌ی قبلی باقی مانده‌اید.

تیمی در مرحله Shu متوقف شده و با روش Waterfall همه‌چیز را از قبل برنامه‌ریزی می‌کند. مهم‌ترین خطر این رویکرد در محیط پیچیده چیست؟
Anonymous voting

سلام🥰 پنجشنبه‌ بخیر🤍 یه کوییز مروری بر دو فصل داشته باشیم که فردا قراره فصل سه رو خلاصه کنیم😍😌

#شما_نوشتید: 📢 اگه هم مجبور بشیم وسط اسپرینت تسک پوش کنیم به تیم ( بر اساس اصل اول که میگه نیاز مشتری الویته) باید حتما با request to change و تایید مدیریت(هیئت رئیسه) و در تسک ریفاینمت انجام بشه

سلام وقت شما هم بخیر، ممنون از لطفتون 🥰🌱 بله، برنامه کلی یا Product Backlog قابل تغییر است؛ یعنی با تغییر نیاز مشتری می‌توان مواردی را اضافه، حذف یا اولویت‌بندی کرد. اما وسط اسپرینت جاری بهتر است هدف اسپرینت تغییر نکند؛ نیاز جدید معمولاً وارد بک‌لاگ می‌شود و در اسپرینت بعدی بررسی خواهد شد. برای گزارش پیشرفت نیز بهتر است از Burn-up Chart استفاده شود؛ چون هم کار انجام‌شده و هم تغییرات حجم پروژه را نشان می‌دهد.

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

تیمی قوانین اسکرام را دقیق اجرا می‌کند، اما با وجود تغییر نیاز مشتری، برنامه اسپرینت‌های آینده را اصلاح نمی‌کند. این رفتار با کدام دو مفهوم فصل دوم بیشترین تضاد را دارد؟
Anonymous voting

فصل ۲ رو هم بخونید که کوییز در راهه🥹😬

از ویتنام تا اسکرام: داستان واقعی ریشه‌های یک انقلاب در کار! 🚀 سلام به همه‌ی همراهان و علاقه‌مندان دنیای کار و پروژه‌ها! 👋 امروز می‌خوام شما رو به یه سفر داستانی ببرم، سفری به اعماق فصل دوم کتاب “Scrum Book” که با عنوان “ریشه‌های اسکرام” منتشر شده. اینجا قراره با هم بفهمیم چطور تجربیات یک خلبان جنگی، مفاهیم هنرهای رزمی ژاپنی و چالش‌های دنیای کسب‌وکار، دست به دست هم دادن تا روشی انقلابی مثل اسکرام به وجود بیاد. از میدان نبرد تا حلقه OODA: همه چیز از جنگ ویتنام شروع شد! جایی که جف ساترلند (یکی از خالقان اصلی اسکرام) با هواپیمای RF-4C پرواز می‌کرد. اونجا بود که با حلقه OODA (مشاهده، جهت‌گیری، تصمیم‌گیری، اقدام) آشنا شد؛ درسی که بهش یاد داد در لحظات بحرانی، تردید یعنی پایان! این مفهوم، بعدها در قلب اسکرام جا گرفت: عمل کردن، نه فقط فکر کردن. وقتی Waterfall شکست می‌خورد… ساترلند در دنیای کار هم با سیستم‌های قدیمی مثل Waterfall برخورد کرد. شرکت‌هایی که پروژه‌های عظیم رو با کلی تاخیر و هزینه سرسام‌آور تحویل می‌دادند. فکر می‌کردند مشکل از آدم‌هاست، ولی ساترلند فهمید مشکل از روش تفکر و روش انجام کار بود. اینجاست که ایده “شرکت درونِ شرکت” شکل گرفت، جایی که تیم‌ها با مالک محصول، بک‌لاگ و اسپرینت‌های کوتاه، شروع به نوآوری کردند. الهام از آیکیدو و تمرین مداوم: جالبه بدونید که اسکرام مثل هنرهای رزمی ژاپنی مثل آیکیدو هست! مفهومی به اسم “شو ها ری” (Shu Ha Ri) که مراحل یادگیری رو نشون میده: اول یاد می‌گیری، بعد نوآوری می‌کنی و در نهایت… خودت میشی اون روش! اسکرام هم همینه؛ نیاز به تمرین مداوم داره تا به مرحله‌ای برسی که کارها روان و طبیعی انجام بشن. “تغییر کن یا بمیر!” ساترلند با دیدن مقاومت در برابر تغییر در شرکت‌هایی مثل BellSouth، مستقیماً گفت: “تغییر کن یا بمیر!” در دنیای امروز که سرعت تغییرات سرسام‌آوره، انطباق‌پذیری و پاسخگویی سریع، دیگه یک گزینه نیست، بلکه یک ضرورت حیاتیه. و اما نظر شخصی من: وقتی این داستان رو می‌خوندم، عمیقاً تحت تاثیر قرار گرفتم. اینکه چطور تجربیات و اتفاقات به ظاهر نامرتبط (مثل خلبانی در جنگ یا یادگیری آیکیدو) می‌تونن در شکل‌گیری یک روش کار مدرن مثل اسکرام نقش داشته باشن، واقعاً شگفت‌انگیزه. این نشون میده که خلاقیت و نوآوری هیچ مرزی نمی‌شناسن و ریشه در نگاه و تجربه‌ی ما به دنیای اطراف دارن. مهم‌تر از همه، درس “تغییر کن یا بمیر” برای همه‌ی ما، چه در کار و چه در زندگی شخصی، یه یادآوری جدیه که نباید در برابر پیشرفت و انطباق با تغییر مقاومت کنیم. نکات کلیدی که نباید فراموش کرد:اقدام قاطع (OODA Loop) ✅ یادگیری مستمر از محیطتیم‌های عالی: خودمختار، چندوظیفه‌ای و با هدف والا ✅ چرخه PDCA: برنامه‌ریزی، انجام، بررسی، اقدام - کلید بهبود مستمر ✅ تسلط بر فرم‌ها و سپس رها کردن آن‌ها (Shu Ha Ri) اسکرام فقط یک متدولوژی نیست؛ یک سبک زندگی و یک روش تفکره که به ما کمک می‌کنه در دنیای پرسرعت امروز، بهتر، سریع‌تر و با کیفیت‌تر کار کنیم.

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

هر جمعه، یک فصل، خلاصه و منتشر می‌شه. چیزی تا جمعه و مرور فصل دوم نمونده😇🪽

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

به نظر «جف ساترلند»، دلیل اصلی ناکارآمدی روش‌های سنتی مدیریت پروژه (Waterfall) چیست؟
Anonymous voting

پست خلاصه فصل اول به ۳۰ ری‌اکشن برسه، فصل دومم به زودی منتشر می‌کنم. چون از تعطیلات استفاده کردم و دارم می‌خونمش ☺️

📝 خلاصه‌ی فصل اول: چرا روش‌های سنتی کار نمی‌کنند؟ در این فصل، جف ساترلند با استفاده از فاجعه‌ی پروژه‌ی IT در FBI نشان می‌دهد که مشکل از آدم‌ها یا بودجه نیست، بلکه مشکل از «مدلِ تفکر» ماست. او روش آبشاری (Waterfall) و برنامه‌ریزی‌های سفت‌وسخت را نقد می‌کند و می‌گوید ما در دنیایی که مدام در حال تغییر است، نمی‌توانیم با نقشه‌هایی که سال‌ها قبل کشیده شده‌اند به مقصد برسیم. 🗝️ ۳ جمله‌ی کلیدی فصل (Key Takeaways) 1️⃣ “The plan was beautiful. It was also useless.” «برنامه زیبا بود، اما بی‌فایده هم بود.» اشاره به اینکه یک گانت‌چارت رنگارنگ و دقیق، به معنی پیشرفت واقعی در پروژه نیست. 2️⃣ “Plans are worthless, but planning is everything.” «برنامه‌ها بی‌ارزش‌اند، اما برنامه‌ریزی همه‌چیز است.» نقل‌قول از آیزنهاور؛ یعنی فرآیندِ فکر کردن به مسیر مهم است، نه چسبیدنِ متعصبانه به یک نقشه‌ی ثابت. 3️⃣ “Essentially, they’re paying people to lie to them.” «در واقع، آن‌ها دارند به آدم‌ها پول می‌دهند که به آن‌ها دروغ بگویند.» وقتی سازمان روی گزارش‌های کاغذی و ددلاین‌های غیرواقعی اصرار دارد، تیم‌ها مجبور می‌شوند واقعیت را پنهان کنند. 💡 فراسوی کتاب! تصور کن در یک شرکت بزرگ جیرا ادمین هستی. مدیر پروژه با افتخار یک فایل اکسل با ۲۰۰ ردیف تسک که برای ۶ ماه آینده زمان‌بندی شده را روی مانیتور نشان می‌دهد. همه‌چیز سبز است. اما وقتی با بچه‌های فنی حرف می‌زنی، می‌فهمی که زیرساخت اصلی هنوز بالا نیامده و دیتابیس مشکل دارد. این همان «توهمِ کنترل» است که ساترلند در فصل ۱ می‌گوید. شرکت دارد هزینه‌ی سنگینی می‌دهد تا فقط در گزارش‌های هفتگی همه‌چیز را «طبق برنامه» نشان دهد، در حالی که کشتی در حال غرق شدن است! 🧐 نظر من درباره‌ی فصل ۱ به نظرم فصل ۱ یک «سیلیِ بیدارکننده» است. ساترلند خیلی هوشمندانه دست روی نقطه‌ضعف بزرگ مدیریت کلاسیک می‌گذارد: ترس از ابهام. ما برای فرار از ابهام، به برنامه‌های کاغذی پناه می‌بریم، غافل از اینکه همین برنامه‌ها تبدیل به زنجیرهایی می‌شوند که سرعت حرکت و قدرت مانور ما را می‌گیرند. این فصل به زیبایی ثابت می‌کند که «نظمِ اجباری» صلب، در نهایت به «آشفتگیِ واقعی» منجر می‌شود.