اگر تغییر بهتر است، چرا همیشه بهتر نمیشویم؟
گفتوگویی درباره تغییر، تصمیمگیری، تیمها و سیستمهایی که میسازیم
⬤ نقطه هفتم
گاهی میدانیم چیزی درست کار نمیکند، اما تغییرش نمیدهیم. گاهی تغییر میدهیم، اما بعد از مدتی همهچیز دوباره به وضعیت قبلی برمیگردد.
در تیمهای نرمافزاری این مسئله را همهجا میبینیم:
- یک فرآیند ناکارآمد که سالها ادامه پیدا میکند.
- یک ساختار تیمی که دیگر با واقعیت سازمان سازگار نیست.
- یک تصمیم معماری که همه میدانند باید تغییر کند.
- یک کد قدیمی که همه از آن ناراضیاند، اما هیچکس جرئت دست زدن به آن را ندارد.
پس مسئله فقط خواستن تغییر نیست. مسئله این است که:
چه چیزی واقعاً مانع تغییر میشود؟
و مهمتر از آن:
اهرم تغییر کجاست؟
و اگر تغییر بهتر است، چرا همیشه بهتر نمیشویم؟
ما معمولا تغییر را با بهتر شدن یکی میگیریم.
فرآیند جدید میگذاریم، ساختار تیم را عوض میکنیم، ابزار تازهای انتخاب میکنیم، معماری را بازطراحی میکنیم، آدمها را جابهجا میکنیم یا تصمیم میگیریم از فردا جور دیگری کار کنیم.
نیت هم معمولا خوب است. و اینجا شاید سوالات جدیدتری برای ما بوجود بیاید:
- اما چرا بعضی تغییرها واقعاً چیزی را بهتر نمیکنند؟
- چرا بعضی تغییرها بعد از مدتی به وضعیت قبلی برمیگردند؟
و چرا گاهی اوقات، راهحلی که برای حل یک مسئله ساختهایم، خودش تبدیل به مسئله جدید میشود؟
در هفتمین «نقطه» میخواهیم درباره همین تناقض صحبت کنیم؛ درباره تغییر در دنیای واقعی، بهخصوص در تیمها و سیستمهای نرمافزاری.
از تغییر رفتار یک فرد و عادتهای یک تیم، تا تغییر فرآیندها، ساختار سازمانی، معماری نرمافزار و شیوه تصمیمگیری.
در هفتمین نقطه قرار است درباره تغییر، از زاویههای مختلف فکر کنیم؛ از روانشناسی و رفتار فردی گرفته تا تیم، سازمان، مهندسی نرمافزار و معماری.
با یک سخنرانی از کیوان علیمحمدی، 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؟
ثبتنام
برای ثبتنام از طریق صفحه ایوند رویداد، اقدام کنید.