فرهنگ اجایل و اسکواد؛ وقتی مشکل ساختار نیست

در سه مقاله قبل درباره تیم‌های تخصصی، اسکوادها و چپترها صحبت کردم.

• از تیم‌های تخصصی تا Squadها؛ آیا واقعاً بهتر شدیم؟

• اسکواد، چه اسم شیکی!

• رئیس من کیه؟

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

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

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

همه این تغییرات منطقی به نظر می‌رسند. هر کدام برای حل یک مسئله واقعی به وجود آمده‌اند و در بسیاری از شرکت‌ها هم نتایج خوبی داشته‌اند.

اما یک سؤال همچنان باقی می‌ماند.

اگر ساختار این‌قدر مهم است، چرا بعضی تیم‌ها با همین مدل‌ها عملکرد فوق‌العاده‌ای دارند و بعضی دیگر نه؟

چرا بعضی اسکوادها واقعاً مستقل هستند و بعضی فقط نام اسکواد را یدک می‌کشند؟

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

به نظر می‌رسد جایی زیر همه این ساختارها، عامل دیگری وجود دارد که تأثیرش از خود ساختار بیشتر است:

فرهنگ.

از مجموعه‌ای از متخصصان تا یک تیم

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

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

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

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

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

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

وقتی اشتباه کردن ممنوع می‌شود

اگر قرار باشد افراد مسئولیت بیشتری بپذیرند، باید بتوانند تصمیم بگیرند. و اگر قرار باشد تصمیم بگیرند، گاهی هم اشتباه خواهند کرد.

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

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

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

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

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

اما هدف اصلی رترو چیز دیگری است. قرار نیست مشخص کند چه کسی اشتباه کرده است؛ قرار است مشخص کند تیم چه چیزی یاد گرفته است.

شاید بتوان کیفیت فرهنگ یک تیم را از روی یک سؤال ساده سنجید:

وقتی در جلسه رترو درباره یک اشتباه صحبت می‌شود، افراد بیشتر به دنبال پیدا کردن دلیل هستند یا پیدا کردن مقصر؟

رشد فردی یا رشد تیمی؟

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

اما در تیم‌های موفق، رشد فقط یک اتفاق فردی نیست.

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

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

این نگاه حتی روی نحوه تشویق افراد نیز تأثیر می‌گذارد.

سال‌ها پیش در یکی از تیم‌ها، پیشنهادی مطرح شد که در پایان هر اسپرینت یک «قهرمان» انتخاب شود؛ فردی که بیشترین تأثیر را در موفقیت آن دوره داشته است.

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

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

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

وقتی ساختار کافی نیست

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

اما تجربه بسیاری از تیم‌ها نشان می‌دهد که ساختار به‌تنهایی تضمین‌کننده موفقیت نیست.

می‌توان اسکواد داشت اما مالکیت مشترک نداشت.

می‌توان رترو برگزار کرد اما چیزی از اشتباهات یاد نگرفت.

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

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

اما حتی اگر چنین فرهنگی شکل بگیرد، یک سؤال مهم باقی می‌ماند.

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

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

سؤال اینجاست که چطور می‌توان بدون از بین بردن استقلال اسکوادها، از پراکنده شدن دانش و تجربه در سطح سازمان جلوگیری کرد؟

یکی از پاسخ‌هایی که برای این مسئله شکل گرفت، Chapter بود.