یک آرزوی شکست خورده

اسپاتیفای از "مدل اسپاتیفای" استفاده نمی‌کند و شما نیز نباید از آن استفاده کنید.

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

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

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

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

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

اما شما مجبور نیستید حرف من را قبول کنید.

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

«حتی در زمانی که ما آن را نوشتیم، آن را انجام نمی‌دادیم. بخشی از جاه طلبی بود، بخشی حدس. مردم واقعاً برای کپی کردن چیزی که واقعاً وجود نداشته تقلا کرده اند.» - Joakim Sundén، مربی چابک در اسپاتیفای2011–2017

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

خلاصه

اسپاتیفای تیم هایی داشت که آنها را جوخه می نامید ، زیرا به نظر جالب تر بود (شوخی نمی‌کنم). گروهی از تیم ها در بخشی به نام قبیله سازماندهی شدند . در نظر گرفته شده بود که هر تیم یک مینی استارت‌آپ مستقل باشد، با یک مدیر محصول که به‌عنوان مینی مدیرعامل برای یک منطقه ویژه عمل می‌کند. این تیم ها دارای طراحان و مهندسان نرم افزار با طیف وسیعی از تخصص ها بودند. هدف این بود که یک تیم باید تمام مهارت های لازم را بدون نیاز به تکیه بر تیم دیگری برای موفقیت داشته باشد.

مدیران محصول دارای ساختار مدیریت سنتی بودند. یک مدیر محصول در یک تیم به راهبر محصول بخش خود گزارش میداد ( "رهبر قبیله" ). برای طراحان هم همینطور. با این حال مهندسان نرم افزار خارج از ساختار تیم مدیریت می شدند.

رهبران چپتر . به عنوان مثال، همه مهندسان نرم‌افزاری که روی APIهای Backend در تمام تیم‌های داخل دپارتمان کار می‌کنند، یک مدیر خواهند داشت و همه مهندسان موبایل اندروید در این بخش نیز مدیر متفاوتی خواهند داشت. هدف این بود که به مهندسان اجازه داده شود تا بین تیم‌های داخل دپارتمان حرکت کنند و نیازهای تجاری را بدون نیاز به تغییر مدیران برآورده کنند.

چرا این روش جواب نداد

• مدیریت ماتریسی یک مشکل اشتباه را حل کرد
• بر استقلال تیم تاکید داشت
• همکاری یک صلاحیت مفروض بود
• تغییر اسطوره دشوار شد

مدیریت ماتریسی یک مشکل اشتباه را حل کرد

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

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

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

”رهبران چپتر، رهبران خدمتگزار هستند که به شما کمک می‌کنند به‌عنوان یک فرد رشد کنید. آنها واقعاً با هیچ تیمی کار نمی کنند. آنها گزارش مستقیم از همه تیم ها دارند ولی واقعاً هیچ مسئولیتی در قبال تحویل ندارند. آنها این مسئولیت را نمی پذیرند. به راحتی می توان صاحب محصول را به عنوان مدیر تیم درنظر گرفت.“
Joakim Sundén، مربی چابک در اسپاتیفای

از اشتباهات Spotify درس بگیرید:

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

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

اسپاتیفای روی استقلال تیم متمرکز شده است

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

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

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

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

از اشتباهات اسپاتیفای درس بگیرید:

• استقلال نیاز به همسویی دارد. اولویت های شرکت باید توسط رهبری مشخص شود. استقلال به این معنا نیست که تیم ها هر کاری می‌خواهند انجام دهند.
• فرآیندهای همکاری بین تیمی باید تعریف شود. خودمختاری به این معنا نیست که تیم ها را برای خود سازماندهی هر مشکلی رها کنیم.
• نحوه اندازه‌گیری موفقیت باید توسط رهبری تعریف شود تا افراد بتوانند به طور مؤثر در مورد اولویت‌بندی وابستگی بین تیمی مذاکره کنند.
• استقلال مستلزم پاسخگویی است. مدیریت محصول نسبت به ارزش پاسخگو است. تیم، مسئول ارائه فرآورده‌های (increment) «انجام شده» است. تیم های بالغ می توانند استقلال خود را با توانایی خود در بیان ارزش تجاری، ریسک، یادگیری و حرکت بهینه بعدی توجیه کنند.

«اگر بخواهم یک کار را متفاوت انجام دهم، می‌گویم که نباید آنقدر روی خودمختاری تمرکز کنیم.
"هر بار که یک تیم جدید دارید، آنها باید چرخ را در مورد نحوه عملکردشان دوباره اختراع کنند. شاید، فقط شاید، باید «حداقل چابکی حیاتی» (MVA) داشته باشیم. شما با آن شروع کنید. شما آزاد هستید که انصراف دهید، اما مردم نباید همیشه مجبور باشند شرکت کنند. «در چه مرحله ای این فرآیند را وارد می کنید؟ احتمالاً زمانی که خیلی دیر شده است.»
- Joakim Sundén، مربی چابک در اسپاتیفای

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

گمان میکنم تلاش‌های فراوانی در جهت همسویی تیم‌های مستقل تا کنون انجام شده است. یکی از این آخرین تلاشها استفاده از سطوح پروازی(Flight Levels) است. کلاس لئوپولد در دو کتاب Practical Kanban و Rethinking Agile این موضوع، یعنی همراستایی در یک تیم، بین چند تیم و در سطح کل سازمان را مورد بررسی و راهکار سبکی را برای آن نیز ارائه کرده است که مطالعه آن خالی از لطف نیست بالاخص برای کانبان دوستان
پیشنهاد مترجم - خباز

همکاری یک شایستگی فرضی(خیالی) بود

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

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

"کنترل بدون شایستگی هرج و مرج است."
- L. دیوید مارکت، کشتی را بچرخان!

ادامه این جمله به درک آن کمک می‌کند:
کنترل بدون شایستگی هرج و مرج است. اگر تنها کاری که باید انجام دهید همان چیزی است که به شما گفته می‌شود، پس نیازی به درک کاری که انجام می‌دهید نیست – اما زمانی که قدرت بیشتری برای تصمیم‌گیری به شما داده می‌شود، به دانش فنی نزدیکی نیاز دارید که بر اساس آن تصمیم‌گیری کنید.
پیشنهاد مترجم - خباز

از اشتباهات اسپاتیفای درس بگیرید:

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

تغییر اسطوره دشوار است

هنگامی که Agile Scrum معانی جدیدی را به مجموعه ای از کلمات مانند burn-down و sprint معرفی کرد، این کار را به دلیل معرفی مفاهیم جدیدی انجام داد که نیاز به نام داشتند. اسپاتیفای واژگان ماموریت‌ها ، قبیله‌ها ، جوخه‌ها ، اصناف و سرنخ‌های فصل را برای توصیف روش کار خود معرفی کرد. این توهم را ایجاد کرد که چیزی را ایجاد کرده است که برای یادگیری آن انتخاب کلمات غیر عادی نیاز است. با این حال، اگر مترادف‌های غیر ضروری را از ایده‌ها حذف کنیم،(یعنی زلم زیمبو اسمهای قلمبه سلمبه رو کنار بگذاریم و این مفهوم را لخت لخت بررسی کنیم، چیزی به نام) مدل اسپاتیفای به عنوان مجموعه‌ای از تیم‌های چندکاره با استقلال بیش از حد و ساختار مدیریتی ضعیف آشکار می‌شود.

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

از اشتباهات اسپاتیفای درس بگیرید:

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

در عوض این کار را انجام دهید

(فقط شوخی کردم. هیچ راه حل سریعی وجود ندارد.)

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

مشخص شد، اسپاتیفای در سال 2012 متوجه نشده بود که چگونه سرعت و چابکی یک تیم کوچک را در یک سازمان بزرگ حفظ کند. این شرکت فراتر از مدل همنام خود تکامل یافت و برای یافتن پاسخ های بهتر به بیرون از خود نگاه کرد. شما هم باید(همین مسیر را در پیش بگیرید و به حیات سازمان‌های بیرونی بیشتر توجه کنید).

چند توصیه من در رابطه با موضوعات تحت پوشش روش کار اسپاتیفای:

• Team Topologies توسط متیو اسکلتون و مانوئل پیس
• Essential Scrum اثر کنت اس روبین
• Shape Up by Basecamp ایده های خوبی برای سازمان های زیر 150 نفر به نظر می رسد .
• من از نزدیک شاهد بودم که چگونه Scaled Agile Framework به Fitbit کمک کرد تا هزاران نفر را برای راه اندازی سخت افزار پیچیده هماهنگ کند. مانند هر روش دیگری، هر سازمانی تجربه موفقی با آن نداشته است.

منبع: لینک