⬤ هر مسیر بزرگی، از یک نقطه آغاز می‌شود.

رویداد نقطه، هفتم | آیا برای تغییر، اول باید چیزی را خراب کنیم؟

رویداد نقطه، هفتم |  آیا برای تغییر، اول باید چیزی را خراب کنیم؟

اگر تغییر بهتر است، چرا همیشه بهتر نمی‌شویم؟ گفت‌وگویی درباره تغییر، تصمیم‌گیری، تیم‌ها و سیستم‌هایی که می‌سازیم ⬤ نقطه هفتم   گاهی می‌دانیم چیزی درست کار نمی‌کند، اما تغییرش نمی‌دهیم. گاهی تغییر می‌دهیم، اما بعد از مدتی همه‌چیز دوباره به وضعیت قبلی برمی‌گردد. در تیم‌های نرم‌افزاری این مسئله را همه‌جا می‌بینیم: یک فرآیند ناکارآمد که […]

تاریخ و زمان رویداد
30 مرداد 1405
مکان رویداد
تهران
مدت زمان رویداد
3 ساعت

توضیحات

اگر تغییر بهتر است، چرا همیشه بهتر نمی‌شویم؟

گفت‌وگویی درباره تغییر، تصمیم‌گیری، تیم‌ها و سیستم‌هایی که می‌سازیم


⬤ نقطه هفتم

 

گاهی می‌دانیم چیزی درست کار نمی‌کند، اما تغییرش نمی‌دهیم. گاهی تغییر می‌دهیم، اما بعد از مدتی همه‌چیز دوباره به وضعیت قبلی برمی‌گردد.

در تیم‌های نرم‌افزاری این مسئله را همه‌جا می‌بینیم:

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

پس مسئله فقط خواستن تغییر نیست. مسئله این است که:

چه چیزی واقعاً مانع تغییر می‌شود؟

و مهم‌تر از آن:

اهرم تغییر کجاست؟

و اگر تغییر بهتر است، چرا همیشه بهتر نمی‌شویم؟

ما معمولا تغییر را با بهتر شدن یکی می‌گیریم.

فرآیند جدید می‌گذاریم، ساختار تیم را عوض می‌کنیم، ابزار تازه‌ای انتخاب می‌کنیم، معماری را بازطراحی می‌کنیم، آدم‌ها را جابه‌جا می‌کنیم یا تصمیم می‌گیریم از فردا جور دیگری کار کنیم.

نیت هم معمولا خوب است. و اینجا شاید سوالات جدیدتری برای ما بوجود بیاید:

  • اما چرا بعضی تغییرها واقعاً چیزی را بهتر نمی‌کنند؟
  • چرا بعضی تغییرها بعد از مدتی به وضعیت قبلی برمی‌گردند؟

و چرا گاهی اوقات، راه‌حلی که برای حل یک مسئله ساخته‌ایم، خودش تبدیل به مسئله جدید می‌شود؟

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

از تغییر رفتار یک فرد و عادت‌های یک تیم، تا تغییر فرآیندها، ساختار سازمانی، معماری نرم‌افزار و شیوه تصمیم‌گیری.


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

با یک سخنرانی از کیوان علی‌محمدی، Engineering Manager در Snappfood شروع می‌کنیم.

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

عنوان سخنرانی:

اهرم تغییر کجاست؟ از نیت خوب تا تحول واقعی.

چکیده:

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

از نیت خوب تا تحول واقعی

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

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

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

در کانتکست تیم‌های نرم‌افزاری، تغییر می‌تواند از یک Refactoring ساده شروع شود و تا تغییر معماری، ساختار تیم، ownership، فرآیند delivery یا حتی مدل تصمیم‌گیری یک سازمان پیش برود.

یکی از پرسش‌های مهم این است:

اگر تغییر می‌خواهیم، دقیقا کجا باید دست بگذاریم؟

  • آیا باید آدم‌ها را تغییر دهیم؟
  • فرآیند را؟
  • ساختار را؟
  • معماری را؟
  • یا چیزی عمیق‌تر در سیستم؟

بعد از ارائه، نوبت گفتگوست

نقطه قرار نیست فقط جایی برای شنیدن یک سخنرانی باشد.

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

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

از تصمیم‌هایی که جواب نداده‌اند، تا تغییرهایی که برخلاف انتظار نتیجه داده‌اند.

از یک Refactoring کوچک تا تغییر در ساختار یک تیم.

از تصمیم‌گیری مدیر تا فاصله او با کسانی که واقعیت را هر روز لمس می‌کنند.

و از این سؤال ساده:

واقعاً چه چیزی باید تغییر کند؟


🔵 حلقه‌های گفتگو

من پیشنهاد می‌کنم به‌جای اینکه همه حلقه‌ها یک سؤال داشته باشند، هر حلقه یک جنس مسئله متفاوت داشته باشد. این باعث می‌شود خروجی‌ها واقعاً متفاوت شوند.

حلقه ۱ – تغییر فردی

«می‌دانیم باید تغییر کنیم؛ پس چرا نمی‌کنیم؟»

  • چه تغییرهایی را مدت‌هاست می‌دانیم باید انجام دهیم ولی انجام نداده‌ایم؟
  • واقعاً چه چیزی جلوی ما را گرفته؟
  • انگیزه مهم‌تر است یا محیط؟
  • آیا اراده فردی برای تغییر کافی است؟
  • چقدر از رفتار ما محصول انتخاب خودمان است و چقدر محصول سیستمی که داخل آن هستیم؟

Challenge:

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


حلقه ۲ – تغییر تیم

«اگر تیم مشکل دارد، چه چیزی را باید تغییر داد؟»

سناریو:

تیم شما کند شده، کیفیت پایین آمده، تصمیم‌ها طول می‌کشند و ownership مشخص نیست.

شما فقط اجازه دارید یک چیز را تغییر دهید.

چه چیزی؟

  • افراد؟
  • ساختار؟
  • فرآیند؟
  • اهداف؟
  • ownership؟
  • architecture؟
  • leadership؟
  • incentive؟

و مهم‌تر:

چرا فکر می‌کنید این نقطه، اهرم تغییر است؟


حلقه ۳ – تغییر معماری

«آیا هر چیزی که باید تغییر کند، باید Rewrite شود؟»

یک سیستم Legacy دارید.

همه می‌دانند مشکل دارد.

سه انتخاب دارید:

A – Rewrite

B – Refactor

C – فعلاً دست نزنیم

گروه باید تصمیم بگیرد:

  • چه زمانی Rewrite منطقی است؟
  • چه زمانی Refactoring؟
  • چه زمانی هیچ کاری نکردن بهترین تصمیم است؟
  • هزینه تغییر را چطور می‌سنجیم؟
  • چه چیزی باعث می‌شود یک تصمیم برگشت‌پذیر یا برگشت‌ناپذیر باشد؟

حلقه ۴ – تصمیم‌گیری

«چه کسی باید تصمیم بگیرد؟»

یک تصمیم مهم فنی در تیم وجود دارد.

Manager اختیار تصمیم دارد.

Architect دانش بیشتری دارد.

Developerها نزدیک‌ترین افراد به واقعیت سیستم هستند.

Product بیشترین اطلاعات درباره نیاز مشتری را دارد.

چه کسی باید تصمیم نهایی را بگیرد؟

و یک سؤال سخت‌تر:

آیا کسی که بیشترین اختیار را دارد، باید بیشترین اطلاعات را هم داشته باشد؟


حلقه ۵ – پارادوکس تغییر

«چه زمانی تغییر کردن، اشتباه است؟»

قرار نیست همیشه تغییر خوب باشد.

گروه باید مثال‌هایی پیدا کند که در آنها:

  • تغییر وضعیت را بدتر کرده؛
  • تغییر زودهنگام بوده؛
  • تغییر دیر اتفاق افتاده؛
  • تغییر در جای اشتباه انجام شده؛
  • یا اصلاً عدم تغییر بهترین تصمیم بوده است.

سؤال نهایی:

آیا «Change» واقعاً یک Value است یا فقط یک وسیله برای رسیدن به Value؟


ثبت‌نام

  برای ثبت‌نام از طریق صفحه ایوند رویداد، اقدام کنید.  

صفحه ایوند 

سخنرانان

سخنرانان

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

 

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

کیوان علی‌محمدی Engineering Manager در اسنپ‌فود
خط زمانی رویداد

خط زمانی رویداد

1
۱۰:۰۰ - ورود و آشنایی

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

2
۱۰:۱۵ - آشنایی و شروع نقطه

معرفی کوتاه رویداد و شکل‌گیری گروه‌ها.

3
۱۰:۳۰ - ارائه کیوان علی‌محمدی

اهرم تغییر کجاست؟ از نیت خوب تا تحول واقعی

4
۱۱:۱۰ - گفت‌وگوی کوتاه و Networking

یک فرصت کوتاه برای آشنایی و ادامه دادن بحث‌های شکل‌گرفته در ارائه.

5
۱۱:۲۵ - حلقه‌های گفتگو

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

6
۱۲:۳۰ - جمع‌بندی حلقه‌ها

هر حلقه یک ایده، یک تجربه یا یک سؤال مهم را با بقیه به اشتراک می‌گذارد.

7
۱۲:۴۵ - آخرین نقطه

هرکس در یک دقیقه پاسخ می‌دهد: اگر قرار باشد از فردا فقط یک چیز را تغییر بدهم، آن چیست؟

8
۱۳:۰۰ - پایان
1. ۱۰:۰۰ - ورود و آشنایی

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

2. ۱۰:۱۵ - آشنایی و شروع نقطه

معرفی کوتاه رویداد و شکل‌گیری گروه‌ها.

3. ۱۰:۳۰ - ارائه کیوان علی‌محمدی

اهرم تغییر کجاست؟ از نیت خوب تا تحول واقعی

4. ۱۱:۱۰ - گفت‌وگوی کوتاه و Networking

یک فرصت کوتاه برای آشنایی و ادامه دادن بحث‌های شکل‌گرفته در ارائه.

5. ۱۱:۲۵ - حلقه‌های گفتگو

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

6. ۱۲:۳۰ - جمع‌بندی حلقه‌ها

هر حلقه یک ایده، یک تجربه یا یک سؤال مهم را با بقیه به اشتراک می‌گذارد.

7. ۱۲:۴۵ - آخرین نقطه

هرکس در یک دقیقه پاسخ می‌دهد: اگر قرار باشد از فردا فقط یک چیز را تغییر بدهم، آن چیست؟

8. ۱۳:۰۰ - پایان

I’m Masoud Barhami. a software architect, developer, and writer with over a decade of experience designing meaningful, maintainable software systems. My career began in hands-on coding, but quickly grew into a deeper exploration of architecture, modeling, and the language of software itself.

My central focus has always been clarity: how to understand real-world domains, how to design with intent, and how to build systems that reflect purpose, not just requirements. I’ve found that truly great software isn’t just well-written, it’s well-discovered: shaped around the right problems, approached with the right mindset, and realized through careful design. This philosophy has guided much of my work, and continues to evolve through experimentation, reflection, and practice.

Today, I work as a software architect and independent consultant, collaborating with teams to navigate complex domains and align systems with real-world goals. I also train and mentor developers and architects who want to level up in their thinking and design fluency.

دیدگاه‌های کاربر

افزودن دیدگاه جدید

دیدگاه خود را بنویسید.