خیلی وقتها تغییر در سازمانها این شکلی اتفاق میافتد:
یک مفهوم جدید میآید،
یک اسم جذاب و مدرن دارد،
چند شرکت بزرگ هم از آن استفاده کردهاند،
و ناگهان همه میخواهند همان را تکرار کنند.
«Spotify این کار را کرده.»
«فلان شرکت ساختارش را اسکواد کرده.»
«پس حتماً جواب میدهد.»
بالاخره آنها بزرگاند،
حتماً میفهمند چه کار میکنند.
اما چیزی که معمولاً فراموش میشود این است که:
اصلاً مسئله چه بود؟
قرار بود چه چیزی حل شود؟
در مقاله قبلی درباره این صحبت کردم که چطور تیمهای تخصصی، با وجود تمام مزیتهایشان، کمکم باعث شکلگیری وابستگیهای پیچیده و جدا شدن تیمها از یکدیگر شدند.
از تیمهای تخصصی تا اسکواد؛ آیا واقعاً بهتر شدیم؟
خیلی وقتها چیزی که در عمل اتفاق میافتد فقط این است که چند نفر را از تیم جدا میکنیم و اسم جدیدی روی آن میگذاریم.
یک جزیره جدید متولد میشود.
اما مشکل اصلی هنوز سر جایش است.
قرار بود اسکواد مسئله مالکیت را حل کند،
اما مدیر همچنان میخواهد همه تصمیمها را بگیرد.
قرار بود وابستگی کمتر شود،
اما تیم هنوز برای هر تصمیم مهمی وابسته به تأییدهای بیرونی است.
از طرف دیگر، جدا شدن تیمها کمکم باعث میشود هر اسکواد مسیر خودش را برود.
هر تیم ابزار خودش را دارد،
الگوی توسعه خودش را دارد،
و تجربههایی تولید میکند که هیچوقت وارد حافظه واقعی سازمان نمیشوند.
چیزی که قبلاً تلاش کرده بودیم با تیمهای تخصصی حل کنیم، دوباره برمیگردد:
ساختارهای جدا از هم،
کارهای تکراری،
و دانشی که بهجای تبدیل شدن به دارایی شرکت، فقط در ذهن آدمها باقی میماند.
وقتی تیمها بزرگتر شدند و تعداد پروژهها بیشتر شد، کمکم مشکلی به وجود آمد که تقریباً نقطه مقابل اجایل بود:
بروکراسی.
چیزی که میتواند خیلی آرام، بدون اینکه متوجهش شویم، چرخه مرگ یک تیم نرمافزاری را شروع کند.
تیمها کمکم به گروههایی جدا از هم تبدیل میشوند.
هر گروه در مقابل گروه دیگر قرار میگیرد.
ارتباطها کمتر میشود،
تشریفات بیشتر میشود،
و کارها بهجای حل شدن، بین تیمها جابهجا میشوند.
مالکیت خطاها و مشکلات کمکم گم میشود.
وقتی مشکلی پیش میآید،
همه دنبال این هستند که ثابت کنند مسئله از سمت آنها نبوده است.
پاسکاری بین تیمها شروع میشود:
«مشکل از بکاند است.»
«زیرساخت آماده نبود.»
«تیم محصول دیر اعلام کرد.»
«فرانتاند اشتباه پیادهسازی کرده.»
و همزمان، چیزی که قبلاً یک تیم مشترک بود، کمکم تبدیل میشود به چند جزیره جدا از هم.
روابط دوستانه کمتر میشود،
سلسلهمراتب پررنگتر میشود،
و رقابتهای درونسازمانی شکل میگیرد.
در چنین شرایطی، سرعت توسعه کاهش پیدا میکند؛
نه به خاطر ضعف فنی،
بلکه چون انرژی تیم بهجای حل مسئله، صرف هماهنگی، دفاع، و عبور از لایههای مختلف تصمیمگیری میشود.
ایده اسکواد دقیقاً از دل همین مشکل به وجود آمد.
قرار بود تیمهایی ساخته شوند که بتوانند مستقلتر تصمیم بگیرند،
وابستگی کمتری داشته باشند،
و بهجای پاسکاری مسئولیت، مالک واقعی یک مسئله باشند.
مفهوم اسکواد بیشتر از همه با Spotify شناخته شد؛
شرکتی که در سالهای رشد سریعش با مشکلی روبهرو شد که بسیاری از شرکتهای نرمافزاری تجربه میکنند:
تعداد تیمها بیشتر شده بود،
پروژهها همزمان جلو میرفتند،
و هماهنگی بین تیمها کمکم داشت سرعت توسعه را از بین میبرد.
مدلهای سنتی دیگر جواب نمیدادند.
تیمهای تخصصی، با وجود مزیتهای فنی، باعث ایجاد وابستگیهای زیاد شده بودند.
هر تغییر کوچک باید بین چند تیم هماهنگ میشد.
در نتیجه:
تصمیمگیری کند میشد،
تحویل قابلیتها زمان زیادی میگرفت،
و مسئولیت واقعی کارها بین تیمها پخش میشد.
ایده اسکواد تلاش میکرد این مشکل را حل کند.
بهجای اینکه تیمها بر اساس تخصص جدا شوند،
تیمهایی کوچک و مستقل شکل گرفتند که همه مهارتهای لازم برای حل یک مسئله را در خودشان داشتند.
هر اسکواد قرار بود:
روی یک مسئله مشخص تمرکز کند،
بتواند مستقل تصمیم بگیرد،
و بدون وابستگی دائمی به تیمهای دیگر، ارزش تولید کند.
در واقع، اسکواد بیشتر از اینکه یک ساختار سازمانی باشد، تلاشی بود برای کم کردن اصطکاک در فرایند توسعه نرمافزار.
اما همانطور که بعدها مشخص شد،
ساختن تیم مستقل فقط با تغییر چارت سازمانی اتفاق نمیافتد.
وقتی تیمها مستقلتر شدند، خطر جدیدی هم به وجود آمد.
هر اسکواد کمکم میتوانست به دنیای خودش تبدیل شود؛
با ابزارها، تجربهها، و شیوههای کاری مخصوص خودش.
چیزی که قرار بود وابستگی را کم کند،
در بعضی سازمانها دوباره به شکل جدیدی از جدایی بین تیمها تبدیل شد.
و دقیقاً همینجا بود که مفهوم دیگری وارد ماجرا شد:
Chapter.
مفهومی که تلاش میکرد تعادل بین استقلال تیمها و یکپارچگی سازمان را حفظ کند.
شاید مسئله اصلی هیچوقت فقط ساختن اسکواد نبود؛
بلکه پیدا کردن تعادل بین استقلال و هماهنگی بود.
