‫معرفی فریم ورک SAFe - با اُرُد سمسارزاده، مدرس رسمی SAFe از استرالیا

طبق روندی که برای فصل دوم داریم این دفعه با اُرُد سمسارزاده همراه میشیم تا با چارچوب کاری SAFe آشنا بشیم، بعد در مورد زندگی در استرالیا و نحوه‌ی مهاجرتش حرف بزنیم. این چارچوب برای سازمان‌هایی با اندازه‌ی بزرگ کاربرد داره و رایج‌ترین فریم ورک اجایل در مقیاس بزرگه!

همونجور که در اپیزود هم اشاره کردیم، اُرُد اواخر فروردین ۱۴۰۱ قراره دوره‌ای رو در همین راستا برگزار کنه که علاقه‌مندان میتونن از طریق کانال‌های ارتباطی نظیر لینکدین و اینستاگرام آمادگی خودشون رو برای شرکت در آن اعلام کنند.

مهمان: اُرُد سمسارزاده

تدوین و اجرا: پدرام کشاورزی

طراح پوستر: محمدحسین بطحایی

لینک‌های مهم:

وبسایت رسمی SAFe

پروفایل پدرام کشاورزی در لینکدین

پروفایل اُرُد سمسارزاده در لینکدین

---

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

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

برای من همیشه این پرسش وجود داشته است که ما در ایران تا چه اندازه در به‌کارگیری تفکر اجایل و پیاده‌سازی فریم‌ورک‌ها و متدها با جهان فاصله داریم. خوشبختانه امروز افراد زیادی داریم که مهاجرت کرده‌اند، به جایگاه‌های مهمی رسیده‌اند و تجربه‌ی کار در این فضاها را دارند. ما هم می‌توانیم از تجربه‌های آن‌ها بهره‌مند شویم.

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

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

اما در این اپیزود قرار است با اورود سمسارزاده، مدرس رسمی فریم‌ورک «SAFe» از استرالیا، درباره‌ی اینکه اصلاً SAFe چیست و چرا و چه زمانی باید از آن استفاده کنیم صحبت کنیم. امیدوارم از این اپیزود لذت ببرید. خوشحال می‌شویم که نظرات و بازخوردهای خود را با ما در میان بگذارید تا بتوانیم در آینده بهتر عمل کنیم. در نهایت هم باید از خودمان شروع کنیم و همان چیزی را که می‌گوییم به کار ببندیم: یعنی به بازخوردها ارزش بدهیم.

سلام آراد جان، حالت چطور است؟ ممنونم که دعوت من را پذیرفتی و در این پادکست حضور پیدا کردی. واقعاً باعث افتخار است. صادقانه بگویم، همیشه در ذهنم بود که در مورد SAFe در پادکست صحبت کنم، اما شخصی را پیدا نکرده بودم که هم دانش عمیق در این زمینه داشته باشد و هم بشود به او اعتماد کرد. خوشحالم که به شکل اتفاقی با تو آشنا شدم و این فرصت فراهم شد.

— مرسی، من هم خیلی خوشحالم که با تو آشنا شدم. از وقتی که در اختیارم گذاشتی ممنونم و امیدوارم بتوانیم به برخی از پرسش‌هایی که درباره‌ی SAFe وجود دارد پاسخ بدهیم و کمی شفاف‌سازی کنیم.

— عالی است، اگر موافق باشی ابتدا معرفی کوتاهی از خودت داشته باش و بعد سراغ موضوع اصلی برویم.

— حتماً. زمینه‌ی کاری من در ابتدا فنی بود. شروع فعالیتم به‌عنوان Oracle DBA بود، سپس به توسعه‌ی جاوا تغییر مسیر دادم. چند سالی در ایران به‌عنوان برنامه‌نویس کار کردم و در سال ۲۰۰۷ به استرالیا مهاجرت کردم. اینجا دو سال فوق‌لیسانس گرفتم و سپس از سال ۲۰۰۹ به‌عنوان برنامه‌نویس مشغول به کار شدم. همان زمان برای نخستین بار وارد تیمی شدم که...

تیمی که برای اولین‌بار با آن آشنا شدم، یک تیم اسکرام (Scrum) بود. در آنجا ما اصول اجرایی (Practices) «ایکس‌پی (XP)» را به‌خوبی انجام می‌دادیم؛ یعنی تست داشتیم و جالب این بود که تیم اصلاً تستر نداشت. توسعه‌دهندگان خودشان کد می‌نوشتند و خودشان هم تست‌ها را آماده می‌کردند. در نتیجه، تیم به سطحی از چابکی رسیده بود که از لحظه‌ای که من کدی را به‌عنوان برنامه‌نویس تکمیل می‌کردم تا زمانی که به محیط عملیاتی (Production) می‌رفت، تنها حدود ۴۰ تا ۴۵ دقیقه طول می‌کشید.

این تجربه مربوط به سال‌های ۲۰۰۹ بود؛ زمانی که اسکرام هنوز آن‌قدر متداول نشده بود. در همان دو سالی که در آن شرکت کار می‌کردم، ما را به دوره‌های آموزشی اسکرام فرستادند و من موفق شدم گواهی اسکرام‌مستر (Scrum Master) را از «اسکرام الاینس (Scrum Alliance)» دریافت کنم. آن زمان خیلی به ارزش این گواهی فکر نمی‌کردم و نمی‌دانستم تا چه اندازه می‌تواند در زندگی حرفه‌ای من تأثیرگذار باشد. اما بعدها، در پروژه‌های بعدی، همان تجربه‌ها باعث شد در هر شرکتی که مشغول می‌شدم، به دلیل سابقه‌ی کار با اسکرام برایشان جذاب باشم. اغلب از من می‌خواستند که تیم‌ها را آموزش بدهم یا در شروع به‌کار با اسکرام کمک کنم.

به همین دلیل، چند سالی در نقش‌های مختلف با اسکرام کار کردم، اصول آن را بیشتر یاد گرفتم و تجربه‌ام عمیق‌تر شد. کم‌کم برایم روشن شد که این کار ارزشمند است و تصمیم گرفتم مسیر شغلی‌ام را تغییر دهم و رسماً به‌عنوان اسکرام‌مستر فعالیت کنم. یکی دو سال هم در این نقش کار کردم تا اینکه در یک سازمان بزرگ با فریم‌ورک «سیف (SAFe)» آشنا شدم.

این آشنایی برایم بسیار جذاب بود. چون همیشه برایم سؤال بود وقتی تعداد تیم‌ها زیاد می‌شود، باید چه کرد؟ در شرکت‌های کوچک و متوسط با اسکرام خوب پیش می‌رفتیم، اما مقیاس بزرگ‌تر چالش‌های جدیدی داشت. وقتی با سیف آشنا شدم، دیدم که پاسخ‌های جالبی برای این مسائل دارد. بنابراین شروع کردم جدی‌تر یاد گرفتن آن و بعد هم آموزش‌دادن به دیگران. از سال ۲۰۱۸ تاکنون در حال آموزش و کار با سیف هستم. حتی چند ماهی است که آموزش «کانبان (Kanban)» را هم آغاز کرده‌ام، چون به‌طور کلی آموزش یکی از علاقه‌مندی‌های اصلی من است و احتمال می‌دهم در آینده نزدیک زمان بیشتری را به آن اختصاص بدهم و کمتر به کوچینگ یا اجرای مستقیم بپردازم.

به‌طور خلاصه، بیش از ۱۲ یا ۱۳ سال است که در محیط‌های اسکرام، سیف و اجایل کار کرده‌ام. اما یک نکته همیشه برایم جالب بوده است: همان اوایل که در ایران برنامه‌نویسی می‌کردم، واقعاً عاشق کدنویسی بودم و از آن لذت می‌بردم. با این حال، علاقه‌ی عمیق‌تر من همیشه «کار کردن با آدم‌ها» بود. هنوز هم آن پَشِن در من وجود دارد. یادم هست همان زمان به این فکر می‌کردم که نمی‌خواهم در نهایت بازنشسته‌ی یک برنامه‌نویس شوم؛ می‌خواستم وارد حوزه‌ی مدیریت شوم. به همین دلیل هم فوق‌لیسانسم را در مدیریت گرفتم.

البته مسیرم تغییر کرد و به جای مدیریت سنتی، به سمت رهبری، کوچینگ و چابکی رفتم. اما علاقه به تعامل با آدم‌ها از همان ابتدا در ذهنم بود و همچنان ادامه دارد.

— چه عالی! واقعاً مسیر جالبی را پشت سر گذاشتی و نکته‌ی قشنگ اینجاست که آرام‌آرام به این سمت آمدی، تجربه کسب کردی و راه برایت باز شد. فکر می‌کنم شنوندگان هم این بخش را دوست داشته باشند. همان‌طور که به آن‌ها قول دادم، در این اپیزود ابتدا درباره‌ی موضوع اصلی‌مان یعنی سیف صحبت می‌کنیم و بعد دوباره به بحث مهاجرت و شرایط زندگی و کاری در استرالیا برمی‌گردیم. این بار ساختار برعکس اپیزودهای قبلی خواهد بود تا ببینیم بازخوردها چگونه خواهد بود.

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

یکی از تجربه‌های شخصی من این بود که وقتی برای اولین‌بار وارد وب‌سایت رسمی سیف (SAFe) شدم، یک نقشه‌ی بزرگ و پیچیده مقابلم قرار گرفت. واقعاً نمی‌دانستم از کجا باید شروع کنم. بخش‌های مختلفی داشت که آدم را گیج می‌کرد؛ نمی‌دانستم این‌ها نقش هستند یا فرآیند را توضیح می‌دهند. خلاصه اینکه در نگاه اول، خیلی گم‌کننده بود.

اما پرسش مهم‌تر این است که چرا اصلاً سیف ایجاد شد؟ مگر خود اسکرام (Scrum) کافی نبود؟ چرا نیاز به چارچوب جدیدی احساس شد؟

اگر بخواهم خیلی خلاصه بگویم، ریشه‌ی این موضوع در همان چیزی است که من هم در تجربه‌ی شخصی‌ام با آن روبه‌رو بودم. اسکرام به‌طور مشخص بر روی یک تیم تمرکز دارد؛ تیمی کوچک متشکل از حدود هفت تا ده نفر با نقش‌ها و مسئولیت‌های مشخص. این تیم می‌تواند کارها را مدیریت کند و خروجی ارزشمندی تحویل دهد.

اما مشکل از جایی شروع می‌شود که شما در یک شرکت بزرگ هستید و محصولی در حال توسعه دارید که پیچیدگی بالایی دارد. در چنین شرایطی، دیگر یک تیم کافی نیست و چندین تیم باید هم‌زمان روی همان محصول کار کنند. طبیعی است که این تیم‌ها روی کار یکدیگر تأثیر بگذارند و میانشان وابستگی‌های زیادی شکل بگیرد.

اینجا است که سیف وارد عمل می‌شود. اگر بخواهم ساده بگویم، هدف اصلی سیف این است که این وابستگی‌ها (Dependencies) را شناسایی کند، آن‌ها را از طریق هم‌راستا کردن (Alignment) تیم‌ها نمایان سازد و سپس در کوتاه‌ترین زمان ممکن برطرف کند.

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

وقتی در مورد سازمان‌های خیلی بزرگ صحبت می‌کنیم، معمولاً با ساختارهایی سنگین، کند و پر از اپلیکیشن‌های قدیمی روبه‌رو هستیم؛ سیستم‌هایی که شاید بیش از بیست سال عمر داشته باشند. در چنین شرایطی، فقط با اسکرام نمی‌توان همه‌ی مشکلات و به‌ویژه وابستگی‌ها (Dependencies) را مدیریت کرد.

اینجاست که سیف وارد عمل می‌شود. سیف تلاش می‌کند این وابستگی‌ها را شناسایی کند، تیم‌ها را با هم هم‌راستا (Align) کند و در نهایت آن وابستگی‌ها را از میان بردارد.

اما پرسش طبیعی این است: «آیا سیف واقعاً به آن اندازه‌ای که در تصویر بزرگش (Big Picture) دیده می‌شود پیچیده است؟»
به نظر من، نه! ظاهرش شاید خیلی پیچیده باشد، ولی اگر قدم‌به‌قدم و مرحله‌به‌مرحله نگاه کنیم، آن‌قدرها هم سخت نیست. در واقع اگر شاخ‌وبرگ‌های اضافی را کنار بزنیم، می‌شود گفت که سیف همان اسکرام است در مقیاس بزرگ‌تر.

فرض کنید یک تیم اسکرام دارید که روی اسپرینت‌های دو هفته‌ای کار می‌کند. حالا سیف می‌گوید چند تیم مشابه را در نظر بگیر که همه روی یک هدف مشترک فعالیت می‌کنند. این تیم‌ها در یک بازه‌ی زمانی بزرگ‌تر که به آن PI یا Program Increment می‌گوییم (حدود سه ماه)، برای رسیدن به همان هدف مشترک تلاش می‌کنند.

اگر به وب‌سایت رسمی سیف (scaledagileframework.com) سر بزنید، آن تصویر بزرگ یا Big Picture چند کانفیگ مختلف دارد: از جمله Large Solution، Portfolio و Full.
اما توصیه‌ی من این است که برای شروع فقط روی Essential تمرکز کنید؛ ساده‌ترین پیکربندی سیف که می‌تواند نقطه‌ی ورود خوبی برای تازه‌کارها باشد.

در مراحل بعدی، سیف تلاش می‌کند فراتر از سطح تیم یا حتی چند تیم برود و چابکی (Agility) را به سطح کل سازمان بیاورد. یعنی هدفش ایجاد اجلیتی در سطح Enterprise است.

به همین دلیل، قبل از اینکه خیلی وارد جزئیات سیف شویم، خوب است یک توقف کوچک داشته باشیم و با هم مطمئن شویم که اساس مفاهیم را درست فهمیده‌ایم:
«اصلاً وقتی می‌گوییم اجایل یا اجلیتی، منظورمان دقیقاً چیست؟»

به نظر من، باید از همین پایه شروع کنیم. باید روی زبان مشترکی به توافق برسیم. وقتی من می‌گویم «اجلیتی»، تو هم دقیقاً بدانی در مورد چه چیزی صحبت می‌کنم.

یک مثال ساده بزنم. فرض کنید کسی می‌خواهد گیاه‌خوار شود. گیاه‌خواری در اصل یک مایندست است، یک طرز فکر با یک‌سری ارزش‌ها. مثلاً اینکه من نمی‌خواهم حیوانی کشته شود یا اینکه می‌خواهم زندگی سالم‌تری داشته باشم و چربی کمتری مصرف کنم.

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

آن متخصص به من یک فریم‌ورک داده است؛ روشی عملی برای رسیدن به هدف گیاه‌خواری.

حالا در این تشبیه:

• گیاه‌خواری همان اجایل است.

• رژیم غذایی همان فریم‌ورک‌ها هستند، مثل اسکرام یا کانبان.

• متخصص تغذیه هم همان اسکرام مستر یا مربی اجایل است که کمک می‌کند راه درست را پیدا کنی.

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

بنابراین، چارچوب SAFe در واقع نسخه‌ای به ما ارائه می‌دهد؛ مشابه همان نسخه‌ای که یک متخصص تغذیه برای گیاه‌خواران تجویز می‌کند.
برای مثال می‌گوید: باید تیمی متشکل از هفت تا هشت نفر داشته باشید، باید به‌صورت اسپرینت کار کنید، باید مالک محصول (Product Owner) داشته باشید و … . اگر این عناصر وجود نداشته باشند، دیگر نمی‌توان نام آن را اسکرام گذاشت.

اما معنای این موضوع چیست؟ به این معناست که شما می‌توانید نسخه را تغییر دهید یا حتی برخلاف آن عمل کنید؛ اگر این تغییرات برای سازمان شما نتیجه‌بخش باشد، اشکالی ندارد. فقط دیگر نام آن «اسکرام» نخواهد بود، هرچند همچنان ممکن است برایتان سطحی از چابکی (Agility) را به همراه بیاورد.

نکته‌ی کلیدی دقیقاً همین‌جاست:
بودن یا نبودن نام «اسکرام» اهمیت چندانی ندارد.
آنچه اهمیت دارد این است که هدف ما ارتقای سطح چابکی در سازمان است.

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

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

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

در چنین شرایطی است که SAFe ادعا می‌کند:
«من برای سازمان‌های بزرگ و سنتی، چابکی را در سطح کلان سازمان (Enterprise) فراهم می‌کنم.»
به این معنا که این سازمان‌ها را از حالت کند و سنگین خارج کرده و توانایی تغییر جهت سریع را برایشان ایجاد می‌کند.

البته باید منصفانه قضاوت کرد. همواره چنین نیست که همه‌ی سازمان‌ها به بالاترین سطح چابکی نیاز داشته باشند.
به‌عنوان مثال، دولت‌ها را در نظر بگیرید. من اکنون خود با دولت ایالت ویکتوریا در استرالیا همکاری می‌کنم. یک دولت به اندازه‌ی یک استارتاپ به چابکی نیازمند نیست. چرا؟ زیرا با رقابت مستقیم تجاری مواجه نیست و تصمیم‌های آن در بازه‌ی چند ماه یا حتی چند سال به اجرا درمی‌آیند.

از همین رو یکی از نقدهایی که بر SAFe وارد می‌شود این است که سطح بالایی از چابکی ایجاد نمی‌کند. به نظر من این نقد درست است. با این حال، نکته‌ی مهم اینجاست که بازار هدف SAFe اساساً سازمان‌هایی هستند که به آن سطح بالای چابکی نیز نیازی ندارند.

برای روشن‌تر شدن موضوع مثالی می‌زنم:
فرض کنید در یک سازمان دولتی همچنان بر روی اپلیکیشنی کار می‌کنند که بیست سال پیش توسعه یافته است. اعضای تیم‌هایی که با آن کار می‌کنند اغلب افرادی با سابقه‌ی بیست تا سی سال هستند. بدیهی است که چنین سازمانی قرار نیست مانند یک استارتاپ رفتار کند.

از نظر فناوری، اصلاً امکان رسیدن به آن سطح وجود ندارد. ما نمی‌توانیم تست اتوماسیون داشته باشیم و عملاً امکان پیاده‌سازی CI/CD وجود ندارد؛ سیستم بسیار قدیمی است و هزینه آن بالا است و در عین حال نیازی هم به آن نداریم. انعطاف‌پذیری سیستم نیز بسیار کاهش یافته است، زیرا اپلیکیشن به حدی توسعه یافته که احتمالاً حتی سازندگان اولیه آن نیز روش کارکرد دقیق آن را فراموش کرده‌اند. مستندسازی نیز در حداقل بوده و تنها موارد ضروری وجود دارد.

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

برای من اهمیت زیادی دارد که بدانیم در چه سطحی از اجیلیتی صحبت می‌کنیم و هدف ما دقیقاً چیست، سپس باید بررسی کنیم که آیا ابزار سیف (SAFe) برای مشکل ما مناسب است یا خیر. در صورت مناسب بودن، می‌توانیم از آن استفاده کنیم.

برای مثال، سیف طبق مستندات خود حداقل اندازه شرکت مناسب برای استفاده از این چارچوب را مشخص کرده است. طبق گفته سیف، اگر حدود ۵۰ تا ۱۵۰ نفر روی یک محصول کار کنند و تعداد تیم‌ها بین ۵ تا ۱۲ تیم باشد، چارچوب مناسب خواهد بود.

این اعداد بر اساس تحقیقات شخصی به نام «دمبر» ارائه شده است؛ او روانشناس است و پژوهش‌هایی روی مغز انسان انجام داده است. نتایج نشان می‌دهد مغز انسان به طور همزمان می‌تواند حداکثر حدود ۱۰۰ تا ۱۵۰ کانال ارتباطی را مدیریت کند، یعنی ارتباط مؤثر با بیشتر از این تعداد افراد امکان‌پذیر نیست. این محدوده به نام او، «عدد دمبر»، معروف شده و بیانگر اندازه‌ای تقریبی برای یک قبیله است.

به همین دلیل، در فریم‌ورک‌های مختلف، از جمله سیف، مفهومی به نام «تیم آف تیمز (Team of Teams)» وجود دارد؛ یعنی یک تیم بزرگ که شامل چند تیم کوچکتر است. در ترمولوژی سیف، این ساختار به «قطار» تشبیه می‌شود. اندازه تیم‌های تشکیل‌دهنده این «قطار» نیز بر اساس همان عدد دمبر تعیین می‌شود.

افرادی که در این «قطار» یا به تعبیر دیگر در این «قبیله» حضور دارند، یکدیگر را می‌شناسند و بنابراین میزان ارتباط و تعامل بین آن‌ها افزایش می‌یابد. این افزایش ارتباط سبب می‌شود سطح اجیلیتی آن‌ها نیز بهبود یابد، فرآیندها شفاف‌تر شود و افراد بهتر متوجه شوند که جریان کار چگونه است.

پیش از پرداختن به جزئیات دیگر، باید اشاره کرد که در سیف (SAFe) معمولاً اعدادی نیز به همراه چارچوب ارائه می‌شود که بیانگر اندازه و ساختار تیم‌هاست. همان‌طور که اشاره شد، سیف یک ابزار است و اولین نسخه آن در سال ۲۰۱۱ منتشر شد. این نسخه بر اساس تجربه گروهی از افراد تعریف شده و از آن زمان تاکنون، یعنی تا سال ۲۰۲۲، تغییرات زیادی در آن رخ داده است. هر یک تا دو سال، نسخه‌های جدیدی ارائه می‌شود که با تغییرات موجود در محیط و بازخوردهای کاربران تطبیق یافته است. در این به‌روزرسانی‌ها، برخی ترمینولوژی‌ها تغییر کرده، برخی روش‌ها اصلاح شده و مواردی که کارآمد نبودند بازبینی شده‌اند.

دو نکته اصلی از این بحث قابل استخراج است:

۱. سیف برای مدیریت وابستگی‌ها بین چند تیم طراحی شده است. وقتی چند تیم با هم کار می‌کنند، مدیریت دیپندنسی‌ها اولین چالشی است که پیش می‌آید. چارچوب‌های دیگری نیز مانند «Nexus» وجود دارند که به نحوی تلاش می‌کنند این مشکل را حل کنند.
۲. سیف به منظور افزایش اجیلیتی در سطح سازمانی طراحی شده، اما میزان این افزایش به خود سازمان بستگی دارد و لزوماً قرار نیست حداکثری باشد. در برخی سازمان‌ها، هدف تنها روان‌تر کردن فرآیندهاست، مانند سازمان‌های دولتی که قبلاً پروژه‌ها را در بازه‌های پنج ساله تعریف می‌کردند و اکنون همان پروژه‌ها در سه ماه اجرا می‌شوند. این یعنی اجیلیتی آن‌ها در سطح استراتژیک سازمان افزایش یافته و تغییر جهت‌ها سریع‌تر صورت می‌گیرد.

یک مثال جالب از استرالیا وجود دارد که به بحث «Agile Government» مرتبط است. در دوران بحران کرونا، دولت‌ها واکنش‌های متفاوتی نشان دادند و برخی موفق شدند جامعه را حفظ کنند، در حالی که برخی دیگر نتوانستند. استرالیا از جمله کشورهایی بود که به سرعت واکنش نشان داد و توانست مدیریت مؤثری بر بحران داشته باشد. این تجربه نشان می‌دهد که پیاده‌سازی اصول اجایل در سطح دولت می‌تواند انعطاف‌پذیری و پاسخگویی به تغییرات جهانی را افزایش دهد.

به‌عنوان نمونه، در بخش مالیاتی استرالیا، هر ایالت قوانین مختص خود را داشت و با شیوع کرونا هر ایالت تغییراتی در قوانین مالیاتی خود اعمال کرد تا شرایط جدید اقتصادی را مدیریت کند. این مثال نشان‌دهنده اهمیت تطبیق سریع و اجیلیتی در سطح سازمان‌های بزرگ و دولتی است.

با تغییراتی که دولت‌ها در قوانین خود اعمال کردند، مثلاً مالیات کمتری دریافت کردند یا پرداخت‌ها سریع‌تر انجام شد، مشاهده شد که پیش از کرونا، سرعت تصمیم‌گیری دولت‌ها بسیار پایین بود و تصمیمات معمولاً تا پایان سال مالی بعد اجرا می‌شد. اما با وقوع کرونا، نیاز به تصمیم‌گیری سریع احساس شد و مشخص گردید که سیستم فعلی قادر به پاسخگویی با این سرعت نیست، زیرا پروژه‌های در حال انجام هنوز نیمه‌کاره هستند و توقف آن‌ها سبب اتلاف منابع و زمان می‌شود.

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

حال، برای بررسی چارچوب SAFe، می‌توانیم نگاهی اجمالی به ساختار و نقش‌های آن بیندازیم. در اسکرام، یک تیم معمولاً دارای اسکرام مستر، پروداکت دونر و بک‌لاگ تیمی است و روی یک اسپرینت کار می‌کند. در SAFe، معادل تیم اسکرام یک «قطار» است که شامل چند تیم کوچک می‌شود. نقش اسکرام مستر در سطح تیم، در SAFe به «RTE» (Release Train Engineer) تبدیل شده است که مسئول فسیلیت کردن و مدیریت وابستگی‌ها بین تیم‌هاست تا دیپندنسی‌ها سریع‌تر حل شوند.

پروداکت دونر تیم در SAFe، معادل پروداکت منیجر است که اولویت‌های قطار را از دیدگاه کسب‌وکار و مشتری تعیین می‌کند. بک‌لاگ تیم در سطح قطار، به «Program Backlog» تغییر نام یافته و به جای یوزر استوری، شامل فیچرها است که هر فیچر به چند یوزر استوری تقسیم می‌شود. اسپرینت در این سطح بزرگ‌تر است و معمولاً ده هفته یا تقریباً سه ماه طول می‌کشد، تا امکان جای‌گیری فیچرها فراهم شود.

نکته مهم دیگر این است که RTE و پروداکت منیجر مدیر تیم‌ها یا پروداکت دونرها نیستند؛ آن‌ها نقش مشخص و مستقل خود را دارند. همه اعضا در یک سطح سازمانی قرار دارند اما روی اسکیل‌های مختلف کار می‌کنند؛ برخی روی اسکیل قطار بزرگ‌تر و برخی روی تیم‌های کوچک‌تر.

در مورد پیشینه SAFe، فریم‌ورک توسط «Dean Leffingwell» توسعه یافته است، فردی با تجربه بسیار زیاد در زمینه Lean و Agile، که پیش از SAFe تجربه‌های متعدد و موفقی در مدیریت فرآیندهای پیچیده داشته است. SAFe ترکیبی از اصول اجایل و لین است و به سازمان‌ها کمک می‌کند اجیلیتی را در مقیاس بزرگ و پیچیده پیاده کنند.

اصطلاح «پایبنده» در اینجا به این معناست که فرد نه تنها به اصول لین و اجایل پایبند است، بلکه ارزش‌های آن‌ها را نیز پذیرفته و سعی می‌کند در عمل به آن‌ها متعهد بماند. بنیان‌گذار SAFe، «Dean Leffingwell»، پیشینه‌ای بسیار قوی در زمینه لین و اجایل دارد و فردی با تجربه، باهوش و جالب است. هرچند جزئیات دقیق شروع کار او برای ما مشخص نیست، اما می‌دانیم که گروهی حدود ۱۰ تا ۱۲ نفره، به نام «SAFe Flow»، از ابتدا با او همکاری کردند یا به سرعت وارد پروژه شدند و در توسعه فریم‌ورک نقش داشتند. دو نفر از این گروه استرالیایی هستند و به همین دلیل، SAFe در استرالیا محبوب و متداول شده است.

برای مثال، اولین قطار SAFe در استرالیا بین سال‌های ۲۰۱۱ تا ۲۰۱۳ در یک شرکت مخابراتی ایجاد شد. افرادی که در توسعه فریم‌ورک نقش داشتند، بعدها به عنوان افراد با تجربه و شناخته‌شده در کنفرانس‌های SAFe شرکت می‌کنند و درباره آن سخنرانی می‌کنند. در اروپا نیز SAFe تا حدی رایج شده و بسیاری از کسانی که قصد استخدام دارند، داشتن مدرک SAFe را نشانه مهارت و تجربه می‌دانند.

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

این نکته اهمیت ویژه‌ای در فریم‌ورک‌هایی دارد که برای مقیاس‌بندی طراحی شده‌اند و در سطح سازمانی کاربرد دارند.

SAFe در مقایسه با سایر فریم‌ورک‌های اسکیل‌بالا تاکنون موفق‌تر و محبوب‌تر بوده است. به همین دلیل، در کشورهای مختلف، به‌ویژه در ایالات متحده، استفاده از SAFe بسیار رایج است. برای مثال، در برخی سازمان‌ها در آمریکا ۱۰ تا ۱۵ قطار فعال هستند و در هند، برخی سازمان‌ها تا ۷۰ قطار دارند که هر قطار شامل حدود ۱۰۰ نفر است و مجموعاً هزاران نفر در آن‌ها کار می‌کنند. این قطارها می‌توانند روی محصولات نرم‌افزاری یا سرویس‌ها فعالیت کنند و محدود به نرم‌افزار نیست.

در حالی که اسکرام از ابتدا با تیم‌های فنی همراه بوده، SAFe توانسته خود را از این محدودیت جدا کند و برای انواع مختلف سازمان‌ها قابل استفاده باشد. اسکرام برای محصولاتی که قابلیت توسعه پیش‌بینی‌پذیر دارند، مانند مهندسی یا ساخت‌وساز، طراحی شده است؛ جایی که عدم قطعیت پایین است و می‌توان با محاسبات دقیق و درصد خطای محدود، ساختار محصول را طراحی و پیاده‌سازی کرد. اما در نرم‌افزار به دلیل عدم قطعیت بالا، تغییرات کوچک و تکراری با هزینه پایین امکان‌پذیر است، بنابراین اجایل و اسکرام برای نرم‌افزار رایج شد.

در مورد مدارک SAFe، این فریم‌ورک دوره‌ها و سرتیفیکیشن‌های متعددی دارد. من شخصاً از سال ۲۰۱۸ تاکنون نزدیک به ۶۰۰ نفر را سرتیفای کرده‌ام. مدارک متداول شامل دوره‌های اسکرام مستر، پروداکت منیجر و RTE است که نقش RTE معادل اسکرام مستر در سطح بزرگ‌تر است. دوره دیگری نیز به نام Lean Portfolio Management (LPM) وجود دارد که گروهی از افراد را برای تعریف استراتژی، تخصیص بودجه و تعیین اولویت‌ها در سطح سازمان آموزش می‌دهد.

علاوه بر این، SAFe دوره‌های دیگری نیز دارد که مجموعاً حدود ۱۵ تا ۱۶ کورس هستند، اما لزوماً همه آن‌ها برای هر فرد ضروری نیستند. برخی از این دوره‌ها دارای امتحان هستند تا اطمینان حاصل شود که شرکت‌کنندگان توانایی عملی استفاده از فریم‌ورک را دارند.

بیشتر دوره‌های SAFe دو روزه هستند و پس از اتمام این دو روز، شرکت‌کنندگان در یک آزمون شرکت می‌کنند. موفقیت در این آزمون منجر به دریافت گواهینامه می‌شود. آزمون به‌صورت آنلاین و چهارگزینه‌ای است و نیازی به نوشتن پاسخ‌ها ندارد. با این حال، آزمون آسان نیست و به‌ویژه برای افرادی که با اسکرام آشنا هستند، بسیار چالش‌برانگیزتر است.

برخی از دوره‌ها مانند Lean Portfolio Management سه روزه هستند و آزمون آن‌ها شامل ۴۵ سؤال چهارگزینه‌ای و زمان ۹۰ دقیقه است. قبل از آزمون اصلی، شرکت‌کنندگان می‌توانند در یک آزمون تمرینی شرکت کنند که چندین بار قابل تکرار است. این آزمون تمرینی نقاط ضعف و قوت افراد را مشخص می‌کند و به آن‌ها نشان می‌دهد کدام بخش‌ها نیاز به مطالعه بیشتر دارد.

شرایط برگزاری دوره‌ها در ایران نیز فراهم شده است. آخرین بار که من به ایران آمدم، حدود سه تا چهار سال پیش بود و هدف اولیه صرفاً آشنایی با جامعه SAFe در ایران بود. اما این رویداد به سرعت به یک کنفرانس با حضور حدود ۲۰۰ نفر تبدیل شد. پس از آن، چندین کلاس در ایران برگزار کردم و با شرکت‌های مختلف همکاری داشتم. برنامه‌ریزی شده است که در اواخر فروردین، دوباره برای چند هفته به ایران بیایم و در صورت امکان، کلاس‌هایی مانند Scrum Master برگزار کنم. این کلاس‌ها کاربردی و عملی هستند و بخش تئوری محدود دارند.

با توجه به مخاطب دوره‌ها، برخی کلاس‌ها برای مدیران طراحی شده و بیشتر بر مفاهیم تئوری SAFe تمرکز دارند تا ذهن آن‌ها برای پذیرش تغییرات آماده شود. این دوره‌ها کمک می‌کنند افراد با فریم‌ورک آشنا شوند، نقش تیم‌های اسکرام و Scrum Master در سازمان‌های بزرگ و ایونت‌های مرتبط با آن را درک کنند.

شرکت‌کنندگان می‌توانند برای ثبت‌نام یا کسب اطلاعات بیشتر از طریق اینستاگرام یا لینکدین با من در ارتباط باشند. نام من در ایران و استرالیا به‌قدری یونیک است که جستجوی آن به‌راحتی من را نشان می‌دهد. خوشحال می‌شوم به سؤالات شرکت‌کنندگان پاسخ دهم و تجربه خود را به اشتراک بگذارم.

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

برای استفاده از روش‌های اجایل، اگر نصفه و نیمه عمل کنیم، واقعاً نتیجه نمی‌گیریم. دلیلش این است که هم اسکرام و هم SAFe یک رویکرد انقلابی (Revolutionary Approach) دارند؛ یعنی سازمان را بازساخت (Restructure) می‌کنند، تیم‌ها را از نو می‌سازند و سیلوهای موجود را حذف می‌کنند.

اجرای این روش‌ها هزینه دارد و اگر ندانیم دقیقاً چه کاری انجام می‌دهیم، هزینه زیادی پرداخت می‌کنیم. مثالی ساده: اگر دریل بخریم ولی برق نداشته باشیم، نمی‌توانیم از آن استفاده کنیم و فقط هزینه کرده‌ایم، بدون هیچ بهره‌ای. بنابراین قبل از انجام این تغییرات، باید حداقل آگاهی از آنچه قرار است رخ دهد داشته باشیم تا تغییر با هزینه کمتر و راحت‌تر اتفاق بیفتد.

واقعیت این است که در ایران نیز این موضوع بسیار شایع است و یکی از دلایل راه‌اندازی «عجایل‌گپ» همین گفتگوها و آگاهی‌بخشی درباره به‌کارگیری اجایل است. هدف ما این است که درباره متدولوژی، فریم‌ورک و تفاوت آن‌ها صحبت کنیم و بعد به موضوع کمبان و تجربه‌های استرالیا بپردازیم.

متدولوژی در اصل یک روش فکری یا فلسفه عمل است. مانند اجایل که مجموعه‌ای از ارزش‌ها و اصول دارد. به‌عنوان مثال، یکی از ارزش‌های Agile این است که ارتباط بین انسان‌ها بر پروسه‌ها و ابزارها ارجحیت دارد. یا اینکه حل مسئله مشتری مهم‌تر از تولید حجم زیادی از مستندات است.

هر متدولوژی ابزارها و فریم‌ورک‌های مختلفی دارد تا ما را به ارزش‌ها و اصولش برساند. فریم‌ورک‌ها چارچوب‌هایی هستند که مسیر عملی رسیدن به این ارزش‌ها را نشان می‌دهند، اما خود متدولوژی همان اصول و ارزش‌هاست. مثالی ساده: مانند رژیم گیاهخواری که نسخه‌ای غذایی ارائه می‌دهد تا فرد به هدف سلامتی برسد.

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

همچنین، نتایج حاصل از اجرای متدولوژی و فریم‌ورک‌ها باعث افزایش اجیلیتی در سازمان می‌شود و این نکته برای سازمان‌های پیچیده بسیار مهم است.

ارد سمسارزاده چگونه به استرالیا مهاجرت کرد؟

در ادامه، درباره تجربه مهاجرت من به استرالیا صحبت می‌کنم. من حدود ۱۵ سال پیش به استرالیا مهاجرت کردم. تصمیم‌گیریم به‌خاطر «فومو» (Fear Of Missing Out) بود؛ یعنی دوستانم یکی یکی به کشورهای دیگر مهاجرت می‌کردند و من احساس کردم ممکن است فرصت‌ها را از دست بدهم. هیچ برنامه‌ریزی خاصی برای مهاجرت نداشتم، ولی پس از بررسی و مشورت، تصمیم گرفتم راهی استرالیا شوم و از فرصت‌های آن بهره‌برداری کنم.

بعد از مهاجرت به استرالیا، ابتدا مدارکم را فرستادم و آمدم اینجا درس خواندم. بعد از دو سال تصمیم گرفتم بمانم و در کل از این تجربه بسیار راضی هستم. به نظر من این مسیر باعث شد به بلوغ بیشتری برسم و تجربه‌های ارزشمندی کسب کنم. البته همیشه گفته‌ام که مهاجرت را به همه توصیه نمی‌کنم، چون سختی‌های خود را دارد. اما تجربه چند سال زندگی در یک کشور دیگر می‌تواند دید و آگاهی فرد را به شدت گسترش دهد. دیدن فرهنگ‌ها و سبک زندگی مختلف، آشنایی با غذاها و مردم متفاوت، برای رشد فردی بسیار مفید است.

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

پس از مدتی، با بهبود زبان انگلیسی، سفرهایی به کشورهای اطراف استرالیا داشتم؛ کشورهایی مانند ویتنام، بنگلادش و دیگر کشورهای کوچک در منطقه. در این سفرها زندگی مردم را تجربه کردم، در بازارها حضور یافتم و غذاهای محلی را امتحان کردم. این تجربه‌ها بسیار آموزنده و رضایت‌بخش بود.

در زمینه کاری، تجربه من در ایران با استرالیا تفاوت‌های زیادی داشت. در ایران، ابتدا در زمینه دیتابیس و ترجمه کار می‌کردم. بعد از مهاجرت و کسب تجربه در استرالیا، تفاوت‌های سازمانی و فرهنگی را بیشتر درک کردم. یکی از نکات جالب این است که در استرالیا افراد بسیار خودمونی و کژوال هستند؛ سلسله مراتب سازمانی کم‌رنگ‌تر است و معمولاً همه با نام کوچک همدیگر را صدا می‌کنند، حتی اگر سن یا تجربه بالاتری داشته باشند. در ایران، حداقل آن زمان، رسم بر این بود که افراد با عنوان و نام خانوادگی همدیگر را خطاب کنند. با این حال، در سال‌های اخیر، به خصوص در حوزه آی‌تی، این رسم کمتر شده و فضای کاری خودمانی‌تر شده است.

تجربه شخصی من نشان داد که صدا کردن افراد با نام کوچک، حتی در محیط‌های رسمی، باعث شد فاصله‌ها کاهش یابد و همکاری تیمی به شکل ملموس بهبود پیدا کند. یک مثال واقعی: وقتی در یک تیم تازه وارد این روش را امتحان کردیم، بعد از یکی دو ماه ارتباطات و همکاری تیم بسیار راحت‌تر و مؤثرتر شد.

استرالیا از نظر جغرافیایی و موجودات زنده، تفاوت‌هایی با ایران دارد. بسیاری از ایرانیان تصور می‌کنند استرالیا پر از عقرب، عنکبوت‌های سمی، مارمولک‌های غول‌پیکر و کوسه است. واقعیت این است که اگر در مناطق شهری و مسیرهای امن باشید، این موجودات معمولاً تهدید جدی ایجاد نمی‌کنند. مثلاً کوسه‌ها در ساحل بسیار نادر هستند و اتفاقات بسیار نادر رخ می‌دهد. در کل، تصور عمومی درباره خطرات استرالیا اغراق‌آمیز است.

خانه ما در استرالیا کمی طبیعت‌دار است و پشت آن باغ و محیطی طبیعی داریم. بعضی حیوانات کوچک مانند عنکبوت‌ها و مارمولک‌های بزرگ (۲۰–۳۰ سانتی‌متری) گهگاهی وارد حیاط می‌شوند، اما هیچ خطری ندارند. تنها چیزی که ممکن است برای افراد ناآشنا ترسناک باشد، دیدن آن‌هاست، اما وقتی زندگی می‌کنی، می‌فهمی که خطری ندارند.

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

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

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

یکی دیگر از نکات جالب، آب و هوا بود. من به ملبورن آمدم و انتظار داشتم هوای آفتابی و ثابت باشد، اما با فصل‌ها و تغییرات غیرقابل پیش‌بینی مواجه شدم. بهار که رسیدم، باد شدید آمد و حتی عینکم را از صورتم برداشت! ملبورن جغرافیای خاصی دارد و تغییرات هوای آن به دلیل ورود جبهه‌های سرد و گرم از قطب و کویر مرکزی است. گاهی صبح هوا خنک است و شب گرم می‌شود، یا بالعکس. این تغییرات برای من بسیار جالب و هیجان‌انگیز بود.

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

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

یکی از نکات جالب این است که مدل کاری اجایل (Agile) و سیف (SAFe) در برخی صنایع بسیار کاربردی است، ولی همه سازمان‌ها به آن نیاز ندارند. همیشه باید ابتدا مشخص شود که چرا یک تغییر لازم است و چه هدفی دنبال می‌شود. تغییر بدون دلیل مشخص و آگاهی از هزینه‌ها، می‌تواند صرفاً باعث هدر رفتن منابع شود. به همین دلیل، وقتی با شرکت‌ها کار می‌کردم، گاهی متوجه می‌شدم که واقعاً تمایل ندارند ارزش‌های اجایل را بپذیرند و تنها تصور می‌کردند که این روش به آن‌ها موفقیت سریع می‌دهد.

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

بنابراین، تصمیم برای تغییر و پیاده‌سازی اجایل یا هر متدولوژی دیگر باید با آگاهی کامل از اهداف و هزینه‌ها انجام شود. اگر هدف برای افراد مشخص باشد، سختی‌های تغییر قابل تحمل می‌شود و نتیجه ملموس خواهد بود، اما اگر هدف وجود نداشته باشد، تغییر منطقی و اثربخش نخواهد بود.

بحث درباره تجربه استرالیا، سیف و اجایل، امیدوارم برای شنوندگان مفید بوده باشد و به روشن شدن نکات مهم کمک کرده باشد.

مهم است که قبل از آنکه بخواهیم به چیزی نقد کنیم یا آن را رد کنیم، ابتدا بفهمیم که آن موضوع چیست و چه قصدی دارد—همان چیزی که می‌گویم، آیا به کار ما می‌آید یا خیر. این به نظرم مهم‌ترین نکته است و ما باید پیش از هر تصمیم، کمی یاد بگیریم و آگاه شویم، وگرنه ادامه‌ی کار ممکن است بی‌نتیجه باشد.

اگر به ایران آمدم و تو را دیدم، خیلی خوشحال خواهم شد. واقعاً مشتاقم. همچنین می‌توانیم اشاره‌ای داشته باشیم به افرادی که علاقه دارند در دوره‌ای که قرار است برگزار شود—فکر می‌کنم پانزدهم یا شانزدهم باشد—شرکت کنند. هر کسی که خواست، می‌تواند به من یا خود ارد پیام بدهد و درباره مراحل ثبت‌نام اطلاعات بگیرد.

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

دمت گرم، خوب و خوش باشی، روز خوبی داشته باشی. مرسی و خدانگهدار، موفق باشی!

‫‫‫اجایل گپ را می‌توانید از طریق شبکه‌های اجتماعی لینکدین، اینستاگرام و تلگرام دنبال کنید