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

بریم سراغ کارهای خونه، چون که جمعه است و روز خانواده، خونه و زندگی 🧹🫧🧑🏻‍🍳. دوست داشتین از روزاتون بگین.

ترکیب ADHD و کمالگرایی اینطوریه که دوست داری همه کار رو با کیفیت عالی پیش ببری. اگر فرصت داشتم، هزار هزار ایده تو ذهنم بود، اما خودم رو کنترل می‌کنم و با برنامه‌ریزی قدم به قدم سعی می‌کنم تعداد تسک‌های Done شده رو بیشتر کنم. از قضا دیروز تو جلسه منتورینگ به این جمله اشاره کردم: Stop Starting! Start Finishing🕶️. و واقعا جوابه دوستان. حس بهتری دارم🥹

و اینم از فصل هفتم😎. فقط دو فصل مونده تا پایان کتاب! بهش عادت کرده بودم یه جورایی! فردا کوییز داریم👩‍🏫🙏.

📌 پست پنجم: روانشناسیِ فردی عنوان: تیپ شخصیتی Thriver؛ چگونه در اسکرام شکوفا شویم؟ 🌱 ساترلند بر اساس مدل‌های روانشناسی، افراد را در محیط کار به ۴ دسته تقسیم می‌کند: لذت‌طلب، پوچ‌گرا، مسابقه‌دهنده، و شکوفا (Thriver). هدفِ نهاییِ اسکرام، پرورشِ تیپِ Thriver است. این فرد با مثلثِ طلاییِ دنیل پینک حرکت می‌کند: ۱. Autonomy (خودمختاری): قدرتِ تصمیم‌گیری درباره نحوه اجرای کار. ۲. Mastery (تسلط): تمایل به یادگیری و بهتر شدنِ هرروزه (کایزن). ۳. Purpose (هدفمندی): درکِ دقیقِ اینکه کارِ او چه ارزشی برای مشتری ایجاد می‌کند. حرف آخر: اگر به عنوان مدیر یا اسکرام‌مستر، شرایطی را فراهم کنید که افراد فقط «تسلیت‌کننده» دستورات نباشند و حسِ تملک (Ownership) داشته باشند، شادی به عنوانِ یک محصولِ جانبیِ طبیعی، خودش در تیم متولد می‌شود. @navaeinotes

📌 پست چهارم: ضدالگوها (Anti-Patterns) عنوان: تله‌ی «حباب شادی» و نیاز تیم به یک ابلهِ دانا! 🎭 آیا تیمی که همیشه می‌خندد و فضای آرامی دارد، لزوماً بهترین تیم است؟ خیر! گاهی این آرامش ناشی از «سکون» یا «عدم چالش» است (Complacency). ساترلند هشدار می‌دهد که تیم نباید در حبابِ رضایتِ کاذب گیر کند. در اینجا نقشِ اسکرام‌مستر به عنوان یک Wise Fool (ابلهِ دانا) حیاتی است: • او کسی است که جسارتِ پرسیدنِ سوالاتِ ناراحت‌کننده را دارد. • او وضعیتِ موجود را به چالش می‌کشد. • او نمی‌گذارد تیم به «خوب بودن» اکتفا کند و همیشه آن‌ها را به سمت «بهتر شدن» هل می‌دهد. نکته: اسکرام‌مسترِ خوب، محبوبِ همه نیست؛ او کسی است که تیم را از «خستگیِ پنهان» نجات می‌دهد. @navaeinotes

📌 پست سوم: فرهنگ سازمانی عنوان: قوانین «آفتاب تابان»؛ چرا پنهان‌کاری سمِ چابکی است؟ ☀️ در فصل ۷ کتاب اسکرام، به مفهومی برمی‌خوریم به نام Sunshine Laws. شعار اصلی این است: “Secrecy is poison. Make work visible.” (پنهان‌کاری سم است. کار را شفاف کنید.) 🏢 تجربه شرکت Zappos: چرا زاپوس الگوی فرهنگ سازمانی شد؟ چون آن‌ها سیلوهای اطلاعاتی را شکستند: • تمامِ بوردها، سود و زیان‌ها و حتی مسیرهای رشد، برای همه شفاف است. • برخورد تصادفی (Random Collisions): فضایی که افراد در راهروها و فضاهای اشتراکی به راحتی گفتگو و ایده‌پردازی کنند (بدون واسطه مدیریت). 📌 در اکوسیستمِ ما: وقتی بورد اسکرام برای همه باز باشد و «کارهای مسدود» (Blocked Issues) پنهان نماند، دیگر جایی برای سیاست‌بازی و باندبازی‌هایِ فرسایشی باقی نمی‌ماند. شفافیتِ رادیکال، سریع‌ترین راه برای رسیدن به بهره‌وری است. @navaeinotes

📌 پست دوم: ابزار پیاده‌سازی عنوان: چگونه «شادی» را به یک تسک قابلِ پیگیری در جیرا تبدیل کنیم؟ 📊 خیلی‌ها می‌پرسند: «مگر حس و حالِ روحی، قابل اندازه‌گیری است؟» پاسخ: بله! ساترلند یک فریم‌ورک ۴ سوالی شفاف برای پایان هر اسپرینت معرفی می‌کند: ۱. از ۱ تا ۵ به حس فعلی‌تان نسبت به نقش‌تان در تیم چه نمره‌ای می‌دهید؟ ۲. از ۱ تا ۵ حس‌تان نسبت به سازمان چیست؟ ۳. چه عاملی باعث شده این حس را داشته باشید؟ ۴. یک کاری که اگر در اسپرینتِ بعد انجام دهیم شما را شادتر می‌کند چیست؟ 🔑 قانونِ طلایی کایزن: پاسخ سوال چهارم نباید صرفاً دردودل باشد. آن را به یک Task با اولویتِ Highest در بالای بورد جیرا تبدیل کنید. وقتی تیم ببیند بازخوردش فوراً تبدیل به یک اقدامِ اصلاحی (Action Plan) می‌شود، اعتماد سازمانی و بهره‌وری به طور طبیعی رشد می‌کند. @navaeinotes

📌 پست اول: پارادایم شیفت در مدیریت عنوان: شادی نتیجه موفقیت نیست؛ سوختِ آن است! 🚀 اکثر مدیران سنتی می‌گویند: «اول پروژه را با موفقیت تمام کنید و تارگت‌ها را بزنید، بعدش حتماً خوشحال خواهیم شد!» اما جف ساترلند در کتاب Scrum این باور را با داده‌های عملیاتی باطل می‌کند. 💡 شادی یک شاخص پیش‌نگر (Predictive Metric) است. تمامی شاخص‌های معمول (مانند Velocity در Jira، گزارش‌های Burn-up، تحویل‌های ریلیز) شاخص‌های گذشته‌نگر (Lagging Metrics) هستند. یعنی وقتی خطایی در آن‌ها می‌بینید، فاجعه قبلاً رخ داده و تیم آسیب دیده است. نکته کلیدی: افتِ سطحِ شادی تیم، معمولاً ۲ تا ۳ هفته قبل از افتِ نمودارِ ولاسیتی بروز می‌کند. اگر آن را نادیده بگیرید، تاخیر، باگ‌های انبوه و فرسودگیِ فنی اجتناب‌ناپذیر است.

سوال برای مدیران محصول: آخرین باری که وضعیت روحی تیم را قبل از بررسیِ دشبوردهای جیرا چک کردید، کی بود؟

فردا فصل ۷ رو داریم😎🪽 لایک بزنید ببینم چند نفر منتظرین👩‍🏫

این پست یادتونه؟ سه نفر منتی عزیزمون، فرم‌های intake رو گرفتند، پر کردند و امروز عصر با هر سه تاشون جداگانه اولین جلسه منتورینگ رو داریم😎 قراره توی جلسه اول دیسکاوری داشته باشیم! روی چالشی که دارن تمرکز کنین و بر اون اساس تکالیف و تمارین هفته اول بهشون تخصیص داده می‌شه🙂‍↔️

صبح شنبه‌ای که تعطیل نیست بخیر 😒🥰. امروز کوییز داریم😎

📚 پرونده کتاب Scrum | فصل ۶ (پست ۵ از ۵) سرعت تیم (Velocity) دقیقاً به چه دردی می‌خوره؟ 🚀 ولاسیتی یعنی مجموع امتیازهای استوری‌هایی که در طول یک اسپرینت واقعاً «Done» شدن (طبق Definition of Done). ⚠️ بزرگ‌ترین اشتباه مدیریتی: مقایسه ولاسیتی دو تا تیم با هم، یا تبدیل کردن اون به KPI برای فشار آوردن به تیم! ولاسیتی مثل شماره پای هر آدمه؛ شماره پای یک نفر ۴۲ هست و یکی دیگه ۳۸، این دلیل برتری هیچ‌کدوم نیست. 🔹 کاربرد واقعی: ولاسیتی یک ابزار پیش‌بینیه. وقتی بدونید میانگین ولاسیتی تیم در ۳ اسپرینت اخیر ۳۰ پوینت بوده و توی بک‌لاگ ۱۵۰ پوینت کار اولویت‌دار مونده، با قطعیت بالا می‌تونید به بیزنس بگید: «این قابلیت‌ها حدوداً ۵ اسپرینت دیگه ریلیز میشن.» برنامه‌ریزی واقعی یعنی تصمیم‌گیری بر اساس دیتای گذشته، نه آرزوهای آینده! #Velocity #ScrumMetrics #SprintPlanning #AgileLeadership @NavaeiNotes

📚 پرونده کتاب Scrum | فصل ۶ (پست ۴ از ۵) چطور بک‌لاگی بسازیم که تیم واقعاً بتونه تخمینش بزنه؟ 🎯 تخمینی که روی یک تسک گنگ و نامفهوم زده بشه، فقط یک حدس الکیه. توی اسکرام، داستان‌های کاربری (User Stories) باید ویژگی‌های فرمول INVEST رو داشته باشن: 🔹 I - Independent (مستقل): وابستگی حداقلی به بقیه تسک‌ها 🔹 N - Negotiable (قابل مذاکره): قرارداد سفت‌وسخت نیست، جای چکش‌کاری داره 🔹 V - Valuable (ارزش‌افزا): ارزش ملموسی به کاربر یا بیزنس بده 🔹 E - Estimable (قابل تخمین): برای تیم شفاف باشه تا بتونن اندازه‌ش بزنن 🔹 S - Small (کوچک): توی یک اسپرینت به‌راحتی جمع بشه 🔹 T - Testable (آزمون‌پذیر): معیار پذیرش (Acceptance Criteria) مشخص داشته باشه اگر استوری شما INVEST نباشه، پلنینگ تبدیل به میدان جنگ و حدس‌های پوچ میشه! #UserStory #INVEST #ProductBacklog #ProductOwner @NavaeiNotes

📚 پرونده کتاب Scrum | فصل ۶ (پست ۳ از ۵) چطور توی جلسات تخمین، نظرات ارشدها جو تیم رو مسموم نکنه؟ 🃏 حتماً دیدید وقتی یک برنامه‌نویس ارشد یا مدیر پروژه میگه: «این فیچر که ۲ ساعت بیشتر کار نداره!»، بقیه تیم حتی اگر نظر دیگه‌ای داشته باشن ساکت میشن (سوگیری لنگر انداختن یا Anchoring Bias). 🔹 جادوی Planning Poker: ۱. داستان کاربر (User Story) خوانده میشه. ۲. همه هم‌زمان و مخفیانه کارت تخمین خودشون رو انتخاب می‌کنن. ۳. با شمارش ۳، همه کارت‌ها رو هم‌زمان رو می‌کنن! 🗣 بحث اصلی کجاست؟ کمترین عدد و بیشترین عدد با هم صحبت می‌کنن. چرا یکی داده ۲ و یکی داده ۱۳؟ دقیقاً همین‌جا باگ‌های ذهنی، ریسک‌های پنهان و ابهامات معماری کشف میشن، نه توی کدهای نوشته‌شده! #PlanningPoker #ScrumMaster #AgileTeam #Estimation @NavaeiNotes

📚 پرونده کتاب Scrum | فصل ۶ (پست ۲ از ۵) ساعت یا سایز سگ؟! چرا تخمین زمانی کار نمی‌کنه؟ 🐶 مغز انسان در تخمین زدن «زمان مطلق» افتضاحه! اگر از تیم بپرسی این فیچر چند ساعت طول می‌کشه، هرکس یه عددی میده و آخرش هم هیچ‌کدوم درست درنمیاد. اما مغز ما در «مقایسه نسبی» فوق‌العاده است: همه می‌دونیم جثه «سگ لابرادور» از «چی‌واوا» بزرگ‌تره و از «گریت دین» کوچیک‌تره، بدون اینکه لازم باشه وزنشون رو با گرم اندازه بگیریم! 🔹 چرا دنباله فیبوناچی (۱، ۲، ۳، ۵، ۸، ۱۳، ۲۱)؟ چون هرچی کار بزرگ‌تر میشه، عدم‌قطعیتش تصاعدی بالا میره. فرق بین کار ۱ و ۲ کمه، اما فرق بین ۸ و ۱۳ زیاده و روی کارهای بزرگ نباید سر جزئیات الکی بحث کرد. کار بزرگ (مثلاً ۱۳ یا ۲۱) یعنی سریع باید شکسته بشه به تکه‌های کوچک‌تر. #StoryPoints #Fibonacci #Estimation #Agile @NavaeiNotes

📚 پرونده کتاب Scrum | فصل ۶: واقعیت را برنامه‌ریزی کن، نه توهم را! (پست ۱ از ۵) تا حالا شده روز اول پروژه، یه گانت‌چارت ۶ ماهه دقیق با روز و ساعت تحویل بدید و ته دلتون بدونید حتی یک خطش هم واقعی درنمیاد؟ 😅 جف ساترلند تو این فصل دست می‌ذاره روی بزرگ‌ترین دروغ دنیای مدیریت سنتی: «توهم قطعیت». 🔹 مخروط عدم قطعیت (Cone of Uncertainty) چیه؟ اول هر پروژه، میزان خطای تخمین‌ها بین ۴۰۰٪ تا ۲۵٪ است! یعنی کاری که فکر می‌کنی ۱ ماه طول می‌کشه ممکنه ۴ ماه طول بکشه یا توی یک هفته جمع بشه؛ چون اول راه در «بیشترین حالت جهل» نسبت به جزییات قرار داریم. 💡 راه‌حل اسکرام: به‌جای اینکه ماه‌ها وقت تلف کنیم تا یک برنامه کاغذی و غیرواقعی بنویسیم، پروژه‌رو به گام‌های کوتاه (اسپرینت) می‌شکنیم و با هر دمو، مه و ابهام رو کم می‌کنیم تا واقعیت جای توهم رو بگیره. #Scrum #Agile #Planning #ConeOfUncertainty @NavaeiNotes

تصویر فصل شش عوض شد🥹😎