در رابطه با KISS امروز یه خبر جدید خوندم که تو یه این مقاله یه مهندس نرم افزار راجب اتفاقات درون تیمیش نوشته بود که خیلی بامزه بود و تهشم خیلی دراماتیک تموم میشه و یه طورایی داره راجب همین KISS صحبت میکنه خلاصه اش این بود که:

داستان درباره یه Engineering Managerـه که یه‌دفعه توی جلسه می‌فهمه یه تیم جدید به اسم CX بهش اضافه شده، بدون اینکه ازش نظر بخوان یا حتی خبرش کنن. هدف این تیم این بوده که تجربه مشتری رو بهتر کنه و زمان رسیدگی به تیکت‌ها رو کم کنه. مشکل اینجا بوده که شرکت قبلاً از مدل تیم‌های جدا بر اساس تکنولوژی (مثلاً بک‌اند، فرانت، موبایل) حرکت کرده بود به سمت تیم‌هایی که کل محصول رو end-to-end مالک هستن، ولی این تصمیم جدید دوباره یه جور برگشت به همون مدل قدیمی بود. از طرفی تیم CX هم به‌جای حل مشکل واقعی (وابستگی شدید به دولوپرها برای حل تیکت‌ها)، بیشتر روی ساختن یه داشبورد پیچیده تمرکز کرده بود که عملاً با نیاز بیزینس align نبود.

نویسنده تصمیم می‌گیره مسیر خودش رو بره: به‌جای منتظر موندن برای اون سیستم پیچیده، هر تیم یه داشبورد ساده داخلی بسازه که فقط کارهای ضروری CX رو راه بندازه، و تیم CX رو هم آموزش بدن که خودشون بتونن مشکلات رو حل کنن (self-service). تو اجرا کلی چالش پیش میاد مثلاً دولوپرهای بک‌اند با فرانت‌اند راحت نبودن یا CX اولش از ابزار استفاده نمی‌کرد ولی با ساده‌سازی (مثلاً استفاده از HTML ساده به‌جای React) و آموزش، کم‌کم جا می‌افته. در نهایت زمان حل تیکت‌ها از چند روز می‌رسه به چند ساعت و وابستگی به تیم‌های فنی خیلی کم می‌شه. در عین حال، تیم CX که جدا ساخته شده بود چون عملاً ارزشی ایجاد نکرد، بعد از چند ماه منحل می‌شه. نتیجه کلی اینه که اضافه کردن تیم جدید همیشه راه‌حل نیست و گاهی یه راه‌حل ساده و سریع که درست adopt بشه، خیلی مؤثرتره از یه سیستم ایده‌آل ولی بلااستفاده.

لینک اصلی مقالش اینه
https://learnings.aleixmorgadas.dev/p/adding-a-team-was-the-wrong-strategic

دوست داشتین یه نگاه بهش بندازین بنظرم تجربه خیلی خیلی خوبیو شیر کرده مخصوصا ساید سافت اسکیلی که چطوری با این تیم جدید تا کرده تا در نهایت تیم به این نتیجه رسیده که اقا ما CX نمیخوایم !

@codehalics | کدهالیک