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

بخش ۷: دشمن پنهان، نویز ارتباطی کم‌کم فصل نشان می‌دهد مشکل فقط حجم کار نیست. خیلی وقت‌ها دشمن اصلی، ارتباطات کند و پیچیده است. عنوان‌های شغلی، مرزهای بین تخصص‌ها، واسطه‌های زیاد، و حرف‌هایی که به‌جای مستقیم رفتن، از چند فیلتر رد می‌شوند. نتیجه؟ دانش دیر می‌رسد، تصمیم‌ها کند می‌شوند، و تیم انرژی‌اش را صرف هماهنگی می‌کند، نه خلق ارزش. اسکرام اینجا هم سادگی را ترجیح می‌دهد: 🤍ارتباط مستقیم‌تر، شفاف‌تر، سریع‌تر.

بخش ۶: ایستادن برای هماهنگی، نه برای گزارش دادن ☀️در میانه داستان، Daily Stand-up هم وارد می‌شود. اما نه به‌عنوان یک مراسم خشک. نه جایی برای گزارش به رئیس. بلکه مثل یک توقف کوتاه در مسیر: 💠کجا هستیم؟ 💠چه چیزی جلویمان را گرفته؟ 💠امروز چطور بهتر حرکت کنیم؟ این جلسه قرار نیست کنترل ایجاد کند؛ قرار است ریتم بسازد. 📊یک ضربان روزانه که تیم را کنار هم نگه می‌دارد.

بخش ۵: داستان WIKISPEED بعد کتاب برای اینکه حرفش فقط تئوری نباشد، یک داستان واقعی می‌آورد: 🚙تیمی که این منطق را از دنیای نرم‌افزار بیرون کشید و برد سمت ساخت ماشین. پیام این بخش خیلی روشن است: اسکرام فقط برای کد نیست؛ برای هر جایی است که آدم‌ها باید با هم چیزی واقعی بسازند. اگر کار را ماژولار کنی، وابستگی‌ها را کم کنی، و در چرخه‌های کوتاه جلو بروی، حتی کارهای پیچیده و فیزیکی هم می‌توانند سریع‌تر و هوشمندانه‌تر انجام شوند.

بخش ۴: تیمی که زودتر یاد می‌گیرد، زودتر برنده می‌شود در ادامه، داستان از «کار بیشتر» فاصله می‌گیرد و به «یادگیری سریع‌تر» می‌رسد. فصل می‌گوید تیم موفق الزاماً تیمی نیست که بیشتر عرق می‌ریزد؛ تیمی است که زودتر بازخورد می‌گیرد. وقتی در بازه‌های کوتاه تحویل می‌دهی، اشتباه‌ها زودتر خودشان را نشان می‌دهند. فرضیات غلط زودتر می‌شکنند. و تیم به‌جای اینکه ماه‌ها در مسیر اشتباه بدود، می‌تواند سریع اصلاح مسیر کند.

بخش ۳: لحظه‌ای به نام Done بعد فصل می‌رسد به مهم‌ترین واژه‌اش: Done. اما نه آن Doneای که فقط روی کاغذ خوب به‌نظر می‌رسد. نه Doneای که یعنی «کدم را زدم» یا «تسک را بستم». بلکه Doneای واقعی: چیزی که مشتری بتواند از آن استفاده کند. انگار فصل دارد به تیم‌ها می‌گوید: 📚جهان بیرون به زحمت شما امتیاز نمی‌دهد؛ به نتیجه‌ای امتیاز می‌دهد که به درد بخورد.

بخش ۲: ورود زمان به‌عنوان داور اینجا «زمان» وارد داستان می‌شود؛ نه به‌عنوان یک تقویم ساده، بلکه مثل یک داور سخت‌گیر. اسکرام می‌گوید اگر کار را باز و بی‌انتها رها کنی، همه‌چیز کش می‌آید: تصمیم‌ها عقب می‌افتند، اولویت‌ها مبهم می‌شوند، و تیم در شلوغی گم می‌شود. 🪽برای همین Sprint متولد می‌شود: یک بازه کوتاه و مشخص که تیم را مجبور می‌کند از رویا بیرون بیاید و چیزی واقعی تحویل بدهد.

بخش ۱: توهم پیشرفت داستان فصل از جایی شروع می‌شود که خیلی از تیم‌ها در آن گیر می‌افتند: فکر می‌کنند چون مشغول‌اند، پس در حال پیشرفت‌اند. اما اسکرام یک مرز روشن می‌گذارد: 📝مشغول بودن با ارزش ساختن فرق دارد. ممکن است هفته‌ها کار کرده باشی، اما هنوز چیزی نداشته باشی که کاربر بتواند لمسش کند، استفاده‌اش کند یا بابتش پول بدهد.

فصل ۴: زمان⏰

فصل ۴ انگار با یک صحنه آشنا شروع می‌شود: یک تیم شلوغ. همه در حال کارند. جلسه‌ها برقرار است. تسک‌ها روی بورد جابه‌جا می‌شوند. آدم‌ها خسته‌اند، اما یک سؤال بی‌رحم وسط اتاق می‌ایستد: «آخرش چی واقعاً قابل استفاده شد؟»

برای فصل چهارم آماده‌این؟😌☺️🤍

دانش سازمان شما کجاست؟ توی ذهنِ آدم‌ها یا توی مستندات؟ 📉 صادقانه بگید، اگه فردا یکی از اعضای کلیدی تیم بره، چقدر از بیزنس‌تون لنگ می‌مونه؟ سؤالم از متخصص‌ها و صاحب‌سخن‌ها: برای مدیریت دانش از چی استفاده می‌کنید؟ اگه جواب‌تون Confluence هست، چطوری تیم رو راضی کردید که «بنویسن» و نذارن اونجا تبدیل به قبرستانِ PDF بشه؟ فرآیندتون چیه؟ تجربه‌تون رو برام بنویسید، شاید راهی که رفتید گره‌گشای بقیه هم باشه. 👇 @nasimnavaeii #مدیریت_دانش #کانفلوئنس #جیرا #مستندسازی #Agile

جوابی که اکثرا به اشتباه انتخاب کردین، بیشتر شبیه سازمان‌های سنتیه؛ جایی که همه چیز از بالا کنترل میشه. اما تیم‌های عالی هدف مشترک دارن، خودمختارن و برای رسیدن به نتیجه کنار هم کار می‌کنن، نه فقط زیر نظر یک سلسله‌مراتب سخت.

یه خورده سیس تیچر اخمو‌ بگیرم؟ جواب این سوال عینا در این متن و پررنگ هست. 😒😒😒😒 می‌دونم این روزها ذهن‌ها درگیره، اما خوبه که از مسیر عقب نمونیم☺️🤍 همیشه گفتم، 📌مفاهیم اجایل به درد زندگی واقعی و هدف‌گذاریش هم می خوره.

بریم‌ کوییز؟

💬نظر شخصی من وقتی به این فصل از نگاهِ مدیریت جیرا و محیطِ دیتاسنتر نگاه می‌کنم، یک نکته برایم بیش از همه برجسته است: «طراحی سیستم، مقدم بر مدیریت تیکت‌هاست.» دامِ مدیریتی: در کار روزمره، بسیار دیده‌ام که تیم‌ها را برای «خطا» یا «کندی» سرزنش می‌کنند، در حالی که اگر واقعاً در سطوح پایین‌تر (در سطح SOPها یا معماریِ گردشِ کارِ جیرا) دقیق شویم، می‌بینیم که سیستمِ کاریِ ماست که آدم‌ها را به سمتِ خطا سوق می‌دهد. به قول این فصل، اگر می‌خواهید عملکرد عوض شود، باید سیستم (و در اینجا تیم) را مهندسی کنید، نه آدم‌ها را. ارتباط با کارهای فنی: در پروژه‌های سخت‌افزاری مثل FPGA/ASIC، ما عادت داریم معماری را بهینه کنیم تا نرخ خطای بیت (BER) پایین بیاید. در اسکرام هم، تیم همین نقش را دارد. وقتی تعداد نفرات بالا می‌رود، «نویز» در کانال‌های ارتباطی زیاد می‌شود. تیم‌های بزرگ در پروژه‌های ما همیشه منبع ایجاد «بدهی فنی» (Technical Debt) هستند، چون هماهنگی بین آن‌ها زمان‌بر و پرهزینه است. رهبری در جیرا: اسکرام‌مستر برای من تعریفِ واقعیِ «مدیریتِ غیرمتمرکز» است. در سازمان‌های بزرگ، مدیران اغلب فکر می‌کنند با اضافه کردن فیلد یا قانونِ اعتبارسنجی در جیرا می‌توانند کیفیت را بالا ببرند. اما فصل ۳ به ما یادآوری می‌کند که نقش ما به عنوان ادمین یا مدیر، «توانمندسازی» تیم است. اگر تیم نتواند خودش تیکت‌هایش را پیش ببرد، سیستم اسکرامِ شما از پایه ایراد دارد، نه از عملکردِ اعضا. این فصل برای من تأییدِ این بود که چابکی (Agility) یک ویژگیِ سازمانی نیست، یک ویژگیِ تیمی است.