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

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

📝 خلاصه‌ی فصل اول: چرا روش‌های سنتی کار نمی‌کنند؟ در این فصل، جف ساترلند با استفاده از فاجعه‌ی پروژه‌ی 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.” «در واقع، آن‌ها دارند به آدم‌ها پول می‌دهند که به آن‌ها دروغ بگویند.» وقتی سازمان روی گزارش‌های کاغذی و ددلاین‌های غیرواقعی اصرار دارد، تیم‌ها مجبور می‌شوند واقعیت را پنهان کنند. 💡 فراسوی کتاب! تصور کن در یک شرکت بزرگ جیرا ادمین هستی. مدیر پروژه با افتخار یک فایل اکسل با ۲۰۰ ردیف تسک که برای ۶ ماه آینده زمان‌بندی شده را روی مانیتور نشان می‌دهد. همه‌چیز سبز است. اما وقتی با بچه‌های فنی حرف می‌زنی، می‌فهمی که زیرساخت اصلی هنوز بالا نیامده و دیتابیس مشکل دارد. این همان «توهمِ کنترل» است که ساترلند در فصل ۱ می‌گوید. شرکت دارد هزینه‌ی سنگینی می‌دهد تا فقط در گزارش‌های هفتگی همه‌چیز را «طبق برنامه» نشان دهد، در حالی که کشتی در حال غرق شدن است! 🧐 نظر من درباره‌ی فصل ۱ به نظرم فصل ۱ یک «سیلیِ بیدارکننده» است. ساترلند خیلی هوشمندانه دست روی نقطه‌ضعف بزرگ مدیریت کلاسیک می‌گذارد: ترس از ابهام. ما برای فرار از ابهام، به برنامه‌های کاغذی پناه می‌بریم، غافل از اینکه همین برنامه‌ها تبدیل به زنجیرهایی می‌شوند که سرعت حرکت و قدرت مانور ما را می‌گیرند. این فصل به زیبایی ثابت می‌کند که «نظمِ اجباری» صلب، در نهایت به «آشفتگیِ واقعی» منجر می‌شود.

🪽اسکرام، هنر انجام دوبرابری کارها در نصف زمان.

سلام👀 درسته فعالیت من دلی هست، اما انتظار فعالیت و همراهی از شماها دارم. یک ضربه به ری‌اکشن کلا یک ثانیه زمان‌بره، اما قوت قلب هست برای من😍 برای پست‌های بعدی سریع‌تر به این عدد برسیم. خب؟ تا منم بین این همه شلوغی، انگیزه‌ام برای فعالیت حفظ بشه.

سلام سلام، دیشب مهمان داشتم، امشبم مهمون دارم. اما مگه قولم به همراه‌های تجربه‌نگاری یادم میره.😌 🪽تا این پیام رو به ۳۰ ری‌اکشن برسونین، منم پست‌ فصل اول کتاب رو می‌فرستم.

سوپرپاور من؟ لذت بردن از تک تک جزئیات. این‌که حتی برای یه آیس کافی، از مسیر لذت ببرم، نه از مقصد!

این نظرسنجی رو با ۳۰ نفر ببندم؟

عزیزان پیگیر خوانش و انتقال تجربه کتاب بودین😇 از اون‌جایی که من طول هفته سرکارم، توی تایم سرویس سعی کردم کتاب رو بخونم و نکاتش رو هایلایت کنم. آخر هفته‌ها که خونه‌ام پست‌هاش رو می‌نویسم و باهم یاد می‌گیریم. فردا، فصل یک رو مرور می‌کنیم😉☺️

📌می‌خوام یک کتاب مهم درباره Scrum رو اینجا با هم بخونیم. کتاب Scrum: The Art of Doing Twice the Work in Half the Time نوشته‌ی Jeff Sutherland. شاید جالب باشه بدونید خود Sutherland یکی از کسانی است که Scrum را طراحی کرده. یعنی این کتاب صرفاً درباره اسکرام نیست؛ روایت کسیه که خودش در شکل‌گیریش نقش داشته. برنامه ساده است:

هر هفته یک چپتر از کتاب را می‌خوانم و اینجا منتشر می‌کنم. در هر پست: چند ایده اصلی چپتر را می‌نویسم، نکته‌هایی که به نظرم مهم است را جدا می‌کنم، و گاهی هم تجربه خودم از کار با تیم‌ها را کنارش می‌گذارم. نه خلاصه خشک کتاب، نه ترجمه خط‌به‌خط. بیشتر شبیه یک کتاب‌خوانی جمعی درباره Scrum.

اگر به اسکرام، چابکی، تیم‌های فنی و مدیریت پروژه علاقه دارید احتمالاً این سری برایتان جذاب خواهد بود. از پست بعدی می‌رویم سراغ چپتر اول کتاب. @navaeinotes

حدود ۳۰ نفر تا الان در این نظرسنجی شرکت کرده‌اند و داریم به نقطه‌ای می‌رسیم که هر پاسخ جدید می‌تواند روی تصویر نهایی اثر واقعی بگذارد. اگر در فضای پروژه، محصول، تیم فنی یا عملیات کار می‌کنید، الان بهترین زمان برای ثبت تجربه شماست. این فرم کمتر از ۱ دقیقه زمان می‌گیرد، اما می‌تواند به ساختن یک تصویر دقیق‌تر از وضعیت واقعی مدیریت پروژه و چابکی در تیم‌های ایرانی کمک کند. 👇 لینک نظرسنجی [https://docs.google.com/forms/d/e/1FAIpQLScFkHP5r6ntiUC8XBk8oFMlbbEAg1AEjmTg2ZtdG1BibsbP8Q/viewform?pli=1] نتایج را بعداً در کانال تلگرامی navaeinotes منتشر می‌کنم

یادآوری شرکت در نظرسنجی☺️

✋🛑نظرسنجی همه ما تجربه کار در پروژه‌هایی را داشته‌ایم که یا در نظمِ خشک غرق شده‌اند یا در بی‌نظمیِ مطلق دست‌وپامی‌زنند. در دنیای مدیریت پروژه مدرن، ابزارهایی مثل Jira و نقشی مثل Agile PMO قرار بود مسیر را برای تیم‌های فنی هموار کنند؛ اما چقدر در این ماموریت موفق بوده‌اند؟ آیا ما واقعاً سیستم می‌سازیم یا فقط در حال تولید بوروکراسی هستیم؟ من در حال جمع‌آوری داده‌هایی برای یک گزارش جامع از «وضعیت مدیریت پروژه و چابکی در تیم‌های ایرانی» هستم. هدف این است که از زاویه دید شما (به عنوان لید فنی، اسکرام‌مستر یا مدیر محصول) ببینیم در واقعیت چه می‌گذرد. شرکت در این نظرسنجی کمتر از ۱ دقیقه زمان می‌برد، اما خروجی آن به ما کمک می‌کند تا بفهمیم کجای مسیر ایستاده‌ایم. 👇 از اینجا نظرت رو به اشتراک بگذار: نظرسنجی نتایج و تحلیل این کنجکاوی جمعی را به‌زودی در کانال @navaeinotes منتشر خواهم کرد

«هنرِ یک PMO، خلقِ مسیری‌ست که در آن، اصطکاک می‌میرد و جریانِ خلق کردن، جان می‌گیرد.»

🎲🕹️Agile PMO یعنی طراحیِ سیستمی که حضورِ تو در آن، «نامرئی» باشد، اما تاثیرت «مشهود». چون بهترین سیستم‌ها، آن‌هایی هستند که آدم‌ها حس نمی‌کنند در حالِ «مدیریت شدن» هستند؛ فقط حس می‌کنند در حالِ «پیش رفتن» هستند.

👾Agile PMO طراحِ یک بازیِ بی‌باک! بیشتر آدم‌ها وقتی اسم PMO (دفتر مدیریت پروژه) را می‌شنوند، یاد فرم‌های اکسل، ددلاین‌های سخت‌گیرانه و پلیسِ تیم می‌افتند. اما بیا از یک زاویه دیگر نگاه کنیم: یک Agile PMO واقعی، شبیه «طراح بازی» (Game Designer) است. طراح بازی قرار نیست خودش بازی کند؛ او قرار است قوانینِ محیطی را طوری طراحی کند که بازیکن (تیم) بدون درگیر شدن در پیچیدگی‌های اضافه، فقط روی «بردن» و «خلق کردن» تمرکز کند. چطور؟ ۱. طراحی قوانینِ مینیمال: قوانینی که مسیرِ کار را روشن کنند، نه اینکه دست و پای تیم را ببندند. ۲. حذفِ اصطکاک (Friction): همان‌طور که طراح بازی باگ‌ها را می‌گیرد تا بازیکن خسته نشود، PMO هم باید موانعی که جلوی «فلو» (Flow) یا جریانِ کارِ تیم را می‌گیرند، شناسایی و حذف کند. ۳. ساختنِ محیطِ امن: محیطی که در آن تیم بداند کجا باید حرکت کند (Jira) و حافظه‌ی این حرکت‌ها کجا ذخیره می‌شود (Confluence). نکته خلاقانه ماجرا اینجاست: اگر تیمِ تو در جریانِ کارش حس کند اصلاً کسی به عنوان PMO آن بالا ننشسته، اما همه‌چیز «خودش» منظم و روان پیش می‌رود... تبریک می‌گویم! تو بازی را برده‌ای. @navaeinotes

یه نفس تازه💚

دیلی مارکت عزیزم! کمتر از یک ماهه که مهمون پروژه‌های تو شدم، بودن کنارت هم سختی‌های خاص خودش رو داره هم شیرینی! تا الان که باهم خوب پیش رفتیم، بیا برای ادامه هم بترکونیم. یه روز خوب، کنار تیم خوب مدرسه اکسیژن و دوستان آیتی دیلی مارکت. ۲۸ خرداد ۱۴۰۵⁩❤️⁩

گاهی فکر می‌کنم مشکل خیلی از تیم‌ها این نیست که کار نمی‌کنن؛ مشکل اینه که اثری از فکر کردنشون باقی نمی‌مونه. جلسه برگزار می‌شه، تصمیم گرفته می‌شه، تسک تعریف می‌شه، کار جلو می‌ره… اما چند وقت بعد اگر بخوای برگردی و بفهمی چرا به این مسیر رسیدید، معمولاً چیزی که می‌بینی یا پراکنده‌ست، یا مبهمه، یا اصلاً وجود نداره. اینجاست که کانفلوئنس می‌تونه بیشتر از یک ابزار ساده باشه. اگر درست ازش استفاده کنیم، می‌تونه تبدیل بشه به حافظه مشترک تیم. نه جایی برای انباشت فایل، نه آرشیو بی‌جان صورت‌جلسه‌ها، بلکه فضایی برای نگه داشتنِ منطق تصمیم‌ها، مسیر گفتگوها و دانشی که نباید گم بشه. برای من، نسبت Jira و Confluence شبیه اینه: جیرا می‌گه تیم الان روی چی کار می‌کنه کانفلوئنس می‌گه چرا، با چه منطقی، و بر اساس چه تصمیمی و این تفاوت مهمیه. چون تیمی که حافظه نداره، مجبوره بارها یک مسئله را دوباره فکر کند. @navaeinotes