در این سند برخی از ساختارهای سازمانی مدیریت اجتماعی معرفی میگردد.
در ادامه اشارهای به ساختار رایج سلسله مراتبی خواهد شد و در مورد ساختار هولاکراتیک که مکانیزم مدیریتی نو برای جهان پر تغییر امروزی است و همچنین ساختار مدل موسوم به مدل Spotify صحبت خواهد شد.
با بکارگیری هولاکراسی، ساختار سازمانی از سلسله مراتب بالا به پایین به ساختار هولاکراتیک تغییر مییابد که شامل مجموعهای از دوایر تودرتو است. در واقع قدرت از سلسله مراتب مدیران گرفته شده و به نقشها تفویض میشود و این موضوع باعث اثربخشی بیشتر در سازمان میگردد.
هر سازمان با سنسورهای حساسی به نام منابع انسانی تجهیز شده است که به نقشها و رفتارها معنی میبخشد. اکثر مواقع این سنسورها، اطلاعاتی حیاتی دارند که نادیده گرفته میشوند بنابراین روی آنها پردازش صورت نمیگیرد. در واقع ظرفیتهای انسانی که ناهماهنگیها را به صورت لحظهای حس میکند و پتانسیل تغییر را در سازمان میبیند، به عنوان بزرگترین هدیه هر سازمان میباشند.
استفاده از هوشیاری منابع انسانی سبب تکامل تدریجی در سازمان میشود که نوعی الگوریتم است؛ در واقع فرمولی همهمنظوره برای نوآوری میباشد. به طوریکه از طریق آزمونوخطا، روشهای جدیدی خلق میشوند که با بکارگیری آنها مسائل و تنشهای پیچیده سازمانی رفع میگردند.
روشهای قدیمی "پیشبینی و کنترل" در دنیای پرتلاطم امروز جواب نمیدهد. طبق نظر یکی از متخصصان علم مدیریت، گری هامل، "دنیای امروزی آشفتهتر از چیزی است که سازمانها بتوانند خودشان را با آن تطبیق دهند. سازمانها برای این نوع تغییرات ایجاد نشدهاند ".
با بکارگیری هولاکراسی، ساختار سازمانی از سلسله مراتب بالا به پایین به ساختار هولاکراتیک تغییر مییابد که شامل مجموعهای از دوایر تودرتو است. در واقع قدرت از سلسله مراتب مدیران گرفته شده و به نقشها تفویض میشود و این موضوع باعث اثربخشی بیشتر در سازمان میگردد. هولاکراسی، فناوری اجتماعی است که برای سازمانهای چابک و هدفمند به کار گرفته میشود و با پیادهسازی این فناوری، ساختاردهی سازمان، نحوه تصمیمگیری، و توزیع قدرت تغییر میکند. در این سند ابتدا این سبک نوین مدیریتی معرفی شده و مفاهیم اصلی آن توضیح داده میشود. پس از آن نحوه راهاندازی هولاکراسی در شرکتها بررسی میگردد. هولاکراسی چهارچوبی را فراهم کرده که چابکی به سطوح سازمانی منتقل شود و در نتیجه بهتر از سازمانهای سنتی، چابکی در فرایند توسعه نرمافزار جاری میشود.
هولاکراسی، سیستم جامعی برای خودسازماندهی میباشد که قدرت را از سلسله مراتب مدیران گرفته و بین نقشهای سازمانی توزیع مینماید. در واقع هولاکراسی یک فناوری اجتماعی جدید برای راهبری سازمان است که توسط مجموعهای از قوانین کلیدی و متفاوت از قوانین قراردادی موجود تعریف شده است. هولاکراسی عوامل زیر را در بر دارد:
برای فرآیندها واژهای تکنیکی وجود دارد که از طریق آن قدرت یا اختیار در سازمان تفویض میشود و آن کلمه "راهبری" است. در اکثر سازمانهایی که بدون هولاکراسی کار میکنند، راهبری صریحا در سطوح ارشد سازمان تعیین می شود یا در آئیننامه مجموعه نوشته شده است. در این آئیننامهها عموما توجه زیادی به تعریف دقیق اختیارات و مسئولیتهای نقشهای سازمانی شده است با این هدف که ساختاردهی مجدد در سازمان انجام شود و بسیاری از مشکلات اساسی آن رفع گردد ولی در واقع این تعاریف از نیازهای واقعی انجام کارها فاصله دارند. از طریق هولاکراسی در محل، راهبری به صورت هشیارانه و منظم انجام شده و در تمامی سازمان توزیع میشود. دیگر عملکرد یک رهبر در تیم کاری ملاک نیست بلکه راهبری و هدایت به فرآیندی دائمی در سطح تیمها تبدیل میشود. هولاکراسی روی طراحی ساختار سازمانی تأثیر میگذارد. ساختار سازمانی سنتی معمولا با مدیر عامل یا تیم اجرایی شروع میشود. راهبری شفافیت سازمانی را به همراه دارد و آن را تکمیل میکند. راهبری به سوالات زیر پاسخ میدهد:
با هولاکراسی، توزیع اختیار تنها به معنی گرفتن قدرت از رهبر و بخشیدن آن به شخص یا گروه دیگر نیست. بلکه گرفتن کرسی قدرت از بالاترین فرد و تخصیص آن به فرآیند است. دیگر مدیران وظیفهی حل تمامی مشکلات افراد زیردستشان را ندارند و نباید مسئولیت همه چیز را به عهده بگیرند. کارکنان نیز مسئولیت و اختیار رسیدگی به تنشهای خودشان را خواهند داشت. در واقع همهی افراد سازمان مسئولیت دارند که تجربیات کسب شده در کارشان را ارائه دهند تا شرکت به سمت جلو حرکت کند. پیادهسازی توزیع قدرت کار بسیار مشکلی است. زیرا باید مدیران خودشان را عقب بکشند و کارکنان در جلو قرار گیرند که حقیقتا سخت و پیچیده است.
برای توزیع اختیار در سازمان نیاز به تغییر ساختار سازمانی است. ساختارهای سازمانی هرمیشکل سنتی امکان توزیع اختیار و قدرت را فراهم نمیسازد. هولاکراسی روش جایگزینی را برای ساختار سازمانی ارائه میدهد. در سازمانی که از هولاکراسی استفاده میکند، افراد سازمان به صورت مرتب میتوانند به شرح شغل خود و دیگران رجوع کنند، زیرا شرح شغل دارای اطلاعات مرتبط، دقیق، شفاف و مفیدی است در رابطه با مواردی که احساس می شود باید انجام شود و کارهایی که انتظار میرود انجام شود. ساختار سازمانی استفاده شده در هولاکراسی، سلسله مراتبی نیست بلکه به آن هولارکی گفته میشود. هولون به پدیدهای گفته میشود که هم شامل جزء و هم کل موجودیت است و از طرفی ساختاری خودسازمانده دارد. به سلسله مراتب هولون، هولارکی گفته میشود. بدن انسان مثال خوبی از هولارکی است. هر سلول بدن انسان یک هولون است که هم شامل کل موجودیت است و هم بخشی از کل بزرگتر به نام ارگان میباشد. همینطور هر ارگان نیز شامل کل موجودیتش است و هم جزیی از کل بزرگتری به نام بدن انسان میباشد. مجموعهای از هولونهای تودرتو مثالی از هولارکی است. این نوع ساختار در اطراف ما بسیار به چشم میخورد زیرا روشی است که طبیعت از آن برای سازماندهی استفاده میکند و ساختاری است که در هولاکراسی وجود دارد.
وقتی به سازمان با این دید بنگریم، انسانها در سیستم سازمانی، هولونهای کوچکی هستند که در هولونهای بزرگتری مانند تیم، واحد و ... قرار گرفتهاند. اما انسانها درست شبیه سلولها نیستند که بخشی از یک ارگان باشند بلکه موجودیتهای خودمختاری هستند که باعث تقویت فرآیندهای سازمانی میشوند و در نقشهای متفاوتی سازماندهی میگردند. آن نقشها بخشی از شرکت هستند و پایهترین بلوک تشکیلدهنده ساختار هولاکراسی میباشند. در واقع وقتی صحبت از توزیع قدرت میشود، بدین معنی است که قدرت و اختیار بین نقشها توزیع میگردد و نه بین افراد سازمان.
نقشها در هولاکراسی داینامیک هستند و به صورت موجودات زندهای میباشند که در طول زمان تغییر میکنند. همیشه هنگام تعریف نقشها و فرآیندها در هولاکراسی، با این سوال مواجه هستید که آیا این کار از مسئولیتهای شخص است یا انتظار ضمنی شما از وی میباشد؟ اگر انتظار شفاف و مشخصی نباشد شما حق ندارید که از او انتظار انجام آن کار را داشته باشید. در ساختار هولاکراسی نقشها، لینک هستند که در راهبری و فرآیندهای عملیاتی دوایر مرتبط نقش دارند و اجازه میدهند تا بازخوردها و پردازش تنشها در سراسر مرزهای دوایر جریان یابد.
هر دایره گروهی از افراد سازمان نیستند بلکه گروهی از نقشهای سازمانی میباشند. ساختار هولاکراسی شبیه مجموعهای از دوایر تودرتو است و هر بخش یا هر هولون تحت سلطه بالادستیها نمیباشد و خودمختاری، حاکمیت فردی و تمامیت خود را حفظ میکند. holarchy از نقشها به وجود میآید که درون دوایری گروهبندی شدهاند که خودشان داخل دوایر گستردهتری قرار دارند. دایره لنگر (Anchor) بزرگترین دایرهای است که کل سازمان را در بر دارد.
در هولاکراسی دو نوع نقش وجود دارد. نقشهای عمومی هر دایره و نقشهای مختص هر دایره. نقشهای عمومی عبارتند از:
علاوه بر نقشهای عمومی تعریف شده، هر دایره نقشهای دیگر خاص خودش را دارد که شامل وظایف مشخصی هستند. اعضای دایره وظایف خاص دیگری نیز در ساختار هولاکراسی دارند که عبارتند از:
در هولاکراسی سه نوع جلسه برگزار میشود:
1 . جلسات راهبری
2 . جلسات تاکتیکی
در این جلسات تمرکز روی کارهای عملیاتی هر یک از دوایر در طول هفته و حذف موانع میباشد تا کارها به سمت جلو حرکت کنند. هر دایره جلسات تاکتیکی خودش را هدایت میکند.
3 . جلسات استراتژی
خروجی این جلسات معمولا در مورد پروژهها و اقدامات است اما در این جلسات میتوان به مواردی مانند بهروزرسانیها، پروژههای درخواستی، نقش افراد و ... نیز رسیدگی کرد.
همانطور که در بخشهای قبل ذکر شد، هولاکراسی تفاوتهایی با ساختار سلسله مراتبی که در اکثر سازمانها به کار گرفته میشود دارد و برای به کارگیری این سبک نوین مدیریتی در سازمان، نیاز به تغییرات ساختاری میباشد. در سایت رسمی هولاکراسی، مراحل زیر برای راهاندازی سریع این فناوری اجتماعی مدیریتی معرفی شده است:
1 . تعیین اینکه آیا شما واقعا دارای یک سازمان هستید زیرا هولاکراسی یک سیستم راهبری برای سازمان است نه برای گروهی از مردم.
2 . پذیرش اساسنامه هولاکراسی: در مرحله اول لازم است تا قوانین بازی که در سندی با عنوان اساسنامه هولاکراسی قرار دارد، تصویب گردد. تصویبکننده اساسنامه بر اساس ساختار سازمانی فعلی انتخاب میشود.
3 . در نظر گرفتن سیستمی برای آرشیو و به اشتراکگذاری سوابق راهبری
4 . تعریف ساختار اولیه: در این مرحله دوایر، نقشها و مسئولیتها تعریف میشوند. دقت کنید که برای هر نفر در سازمان حداقل باید یک نقش در نظر گرفته شود و حداقل یک هدف یا یک مسئولیت به آن نقش ضمیمه شده باشد.
5 . برگزاری اولین جلسات راهبری و انجام انتخابات: برای انتخاب منشی دایره باید انتخابات صورت گیرد اما قبل از انجام انتخابات، زمانبندی جلسات توسط لینک رهبر هر دایره انجام میشود. لینک رهبر باید در نقش تسهیلکننده جلسه نیز ظاهر شود یا شخص دیگری را برای این کار انتخاب نماید. در این جلسه راهبری لینک رهبر باید جزو موارد دستور جلسه، انتخاب منشی، لینک نماینده و تسهیلکننده را قرار دهد.
6 . تنظیم و راهاندازی فضایی برای به اشتراکگذاری موارد عملیاتی
7 . زمانبندی جلسات تاکتیکی و راهبری به صورت منظم: پس از جلسه انتخابات قبل، منشی منتخب دایره باید جلسات منظم تاکتیکی و راهبری را زمانبندی نماید. جلسات تاکتیکی هر هفته یا هر دو هفته یکبار و جلسات راهبری هر دو هفته یکبار یا به صورت ماهانه زمانبندی میشوند.
در اوایل قرن 21 شرکت Spotify با بهرهگیری از سیستم هولاکراسی و بهینه کردن آن توسط متدهای Agile به یک مدل دست پیدا کرد. Spotify با حدود 286 میلیون کاربر بزرگترین و محبوبترین سرویس اشتراک و استریم محتوای صوتی در جهان است. بخش مهمی از موفقیت Spotify توسط رویکرد منحصر به فرد این شرکت به منظور سازماندهی کار در جهت افزایش چابکی تیم انجام شده است. همانطور که تیم های مهندسی Spotify در مسیر پیشرفت چابکی قدم برداشتند، تجربه خود را مستند کردند، آن را با جهان به اشتراک گذاشتند و سرانجام بر نحوه سازماندهی بسیاری از شرکتهای فناوری حول محور کار تأثیر گذاشتند. آنها تصمیم گرفتند برخی از نقشها ،مصنوعات و رویدادهای Scrum را بشکنند و شخصیسازی کنند. بنابراین آنها تصمیم گرفتند نقشها، مصنوعات و رویدادهای Scrum را اختیاری کنند. مهندسان Spotify دریافتند که Agile بیش از Scrum اهمیت دارد و اصول بیش از هر روش خاصی اهمیت دارد. اسکرام مستر را به مربی چابک و همچنین تیم اسکرام را به Squad تغییر نام دادند. امروزه این رویکرد به عنوان مدل Spotify شناخته شده است.
مدل Spotify یک رویکرد مبتنی بر افراد و مستقل برای اندازهگیری و پیادهسازی روشهای چابک است که بر اهمیت فرهنگ و شبکه ارتباطی تأکید دارد. این مدل به Spotify و سازمانهای دیگر کمک کرده است که با تمرکز بر روی استقلال داخلی، ارتباطات، مسئولیتپذیری، پاسخگویی و کیفیت، نوآوری و بهرهوری را افزایش دهند.
هنریک نیبرگ که در Spotify نقش مربی را دارد اشاره میکند مدل Spotify یک چهارچوب نیست زیرا نشاندهنده دیدگاه Spotify در مورد مقیاس و معیارهای فنی و فرهنگی است. این یک نمونه از سازماندهی تیمهای متعدد در یک سازمان توسعه محصول است و بر نیاز به فرهنگسازی و شبکهسازی ارتباطی تأکید میکند. در واقع مدل Spotify بر چگونگی ساختار سازمان برای فعالسازی چابکی متمرکز است.
مدل Spotify ابتدا در سال 2012 به جهان معرفی شد، زمانی که Henrik Kniberg و Anders Ivarsson مقالهای را منتشر کردند که راه کاملا ساده ای را که Spotify را به چابکی نزدیک میکرد معرفی کنند. از آن زمان، مدل Spotify سر و صدای زیادی ایجاد کرد و در فضای تحول چابک محبوب شد. بخشی از جذابیت آن این است که تمرکز آن بر سازماندهی حول محور کار است تا دنبال کردن مجموعه خاصی از روشها. در چهارچوبهای سنتی اندازهگیری و مقیاسگذاری روشهای خاص (به عنوان مثال استندآپهای روزانه)، نحوه اجرای چهارچوب است، در حالی که مدل Spotify بر چگونگی ایجاد مشاغل برای فعالسازی چابکی در یک سازمان متمرکز است.
این مدل استانداردسازی کمی دارد و استاندارد رسمی ندارد. آنها معتقدند همکاری و تبادل متقابل دانش بهتر از استانداردسازی است. به عنوان مثال، وقتی Squad ها به اندازه کافی از یک ابزار خاص استفاده میکنند، آن ابزار به روشی با مخالفت کمتر تبدیل میشود و سایر Squad ها تمایل به انتخاب ابزار مشابه دارند. بعد از اینکه سایر Squad ها از همان ابزار استفاده کردند، آن را آزمایش کرده و با هم همکاری میکنند، سپس این ابزار به یک استاندارد پیشفرض تبدیل میشود. همچنین Spotify از یک مدل متنباز داخلی استفاده میکند. بر اساس احترام متقابل و خودخواهی کم، Spotify دارای یک مرور کد متقابل است، جایی که هر کسی میتواند هر کدی را در هر زمان اضافه کند. سپس یک همکار میتواند کد را بازبینی کرده و تنظیماتی را انجام دهد. همه با هم همکاری میکنند و دانش را گسترش میدهند! آنها همچنین دارای فرهنگ متمرکز بر انگیزه هستند که به آنها کمک کرده است تا از اعتبار خوبی به عنوان یک محل کار برخوردار شوند.
استقلال داخلی تیم در مدل Spotify به گونهای است که هر تیم (یا Squad) چهارچوب خود را انتخاب میکند (به عنوان مثال Scrumban ،Kanban ،Scrum و ...). Squad ها به Tribe ها و Guild ها سازمان یافتهاند تا به نگه داشتن افراد در راستای تبادل متقابل دانش کمک کنند.
مدل Spotify حول محور سادگی بنا شده است. هنگامی که Spotify شروع به سازماندهی کار خود کرد، آنها تعداد اندکی از عناصر مهم را در مورد چگونگی ساختار افراد و تیمها شناسایی کردند. از آنجا که Spotify تعداد زیادی تیم مختلف دارد، آنها نیاز به ایجاد ساختار دارند. هر Squad به یک Tribe گروهبندی میشود که دارای یک یا چند Chapter است. در این محیط، میتوانید بدون تغییر مدیر، Squad خود را تغییر دهید. آنها همچنین دارای یک یا چند Guild هستند که یک جامعه با علاقهمندیهای مشترک است و از روشهای غیررسمی ارتباطی در داخل شرکت استفاده میکنند.
1. Squad
شبیه به تیم اسکرام ،Squad ها تیمهایی با عملکرد متقابل، متفاوت، مستقل و خودمختار هستند (به طور معمول 6-12 نفر) که بر روی یک فیچر خاص تمرکز دارند و در عین حال با ماموریت، استراتژی محصول و اهداف کوتاهمدت همسو هستند. یک اکوسیستم محصول میتواند هر تعداد Squad داشته باشد، به شرطی که با استراتژی اصلی محصول هماهنگ شوند. Squad های مدل Spotify برای یافتن راهحلها همکاری میکنند. Squad های خاص دارای سیستمها یا فرآیندهای خاصی خواهند بود و هدف آنها این است که یکدیگر را قادر به استفاده از آن سیستمها یا فرآیندها کنند تا سایر Squad ها بتوانند به ماموریت خود برسند. هر Squad دارای یک مربی چابک برای پشتیبانی، یک مالک محصول برای راهنمایی و همچنین یک ماموریت منحصر به فرد است که کارهایی که انجام میدهند را جهتدهی و هدایت میکند. Squad ها مشخص میکنند که از کدام روش یا چهارچوب چابک استفاده شود و تمرکز خود را بر روی تحویل محصول و کیفیت آن میگذارند.
2. Tribe
هنگامی که چندین Squad برای هدفی (یک بخشی از محصول یا Feature، بررسی جامع بر یک مشکل، یک مکان یا موارد دیگر) با یکدیگر همراه میشوند، آنها یک Tribe را تشکیل میدهند. Tribe ها به ایجاد هماهنگی در Squad ها کمک میکنند و میتوانند هر تعداد Squad را شامل شوند اما به طور معمول از 40 تا 150 نفر تشکیل میشوند تا بتوانند هم جهت بودن خود را حفظ کنند. هر Tribe یک رهبر Tribe دارد که مسئول کمک به هماهنگی در بین Squad ها و تشویق جهت همکاری است.
3. Chapter
حتی اگر Squad ها مستقل باشند، مهم این است که متخصصان (به عنوان مثال توسعه دهنده DBA ،Javascript) در استفاده از بهترین روشها هماهنگ باشند. به عنوان مثال، چهار Squad ممکن است در هر کدام یک نفر داشته باشد که در زمینه دیزاین تجربه کاربری تخصص دارد. این چهار نفر یک Chapter را در چهار Squad تشکیل میدهند. Chapter ها خانوادهای هستند که هر متخصص دارد و به حفظ استانداردهای مهندسی در یک تخصص کمک میکند. Chapter ها معمولا توسط یک رهبر ارشد فناوری هدایت میشوند، که همچنین ممکن است مدیر اعضای تیم در آن Chapter باشد. این ساختار افراد را قادر میسازد تا بدون از دست دادن مدیر و رهبر خود، از یک Squad به Squad دیگر بپرند و با ابتکارات عمل مختلف کار کنند.
4. Guilds
اعضای تیم که علاقه زیادی به یک موضوع دارند میتوانند یک Guild تشکیل دهند که اساسا یک جامعه با علاقهمندیهای مشترک است. Chapter ها به یک Tribe تعلق دارند، در حالی که Guild ها میتوانند از Tribe های مختلف عبور کنند و چندین نفر را از یک Squad یکسان شامل شوند. کارمندان اجازه دارند به دلخواه خود در Guild ها رفت و آمد کنند و به یک Guild بپیوندد که این موضوع کاملا داوطلبانه است. Guild ها میتوانند در حوزههای مختلف توسعه حرفهای مانند پایتون یا گوگل آنالیتیکس قرار گیرند یا بر روی علاقهمندیهای شخصی خود تمرکز کنند مانند یک باشگاه کتابخوانی، یوگا، فیلم و سریال یا بازی. هیچ رهبر رسمی برای Guild وجود ندارد در عوض، کسی دست خود را بلند میکند تا هماهنگ کننده Guild باشد و به گرد هم آمدن کارمندان کمک کند. Guild ها برای فرهنگسازی و تعامل کارمندان فراتر از نقش آنها ضروری هستند.
5. Trio
تریو (معروف به TPD Trio) ترکیبی از Product Lead ،Tribe Lead و Design Lead است. هر Tribe دارای یک Trio است تا اطمینان حاصل شود که هنگام کار بر روی بخشی از محصول یا Feature، هماهنگی مداوم بین این سه نقش وجود دارد.
6. Alliance
همانطور که سازمانها مقیاس میپذیرند، گاهی اوقات چندین Tribe برای رسیدن به یک هدف نیاز به همکاری نزدیک دارند. Alliance ترکیبی از Tribe Trios (به طور معمول سه نفر یا بیشتر که شامل Product Head ،Tribe Head و Design Head میشود) است که با هم همکاری میکنند تا Tribe های آنها برای هدفی بزرگتر از هدف هر Tribe همکاری کنند.
هنگامی که Spotify شیوه مقیاسپذیر چابک را تغییر داد، آنها میخواستند که Squad ها را قادر به حرکت سریع، ارسال سریع نرمافزار و انجام همه کارها با حداقل هزینه و سربار کند. آنها با استفاده از مدل خود و تکامل آن، این مزایا و موارد دیگر را درک کردند. مزایای سازمانی اجرای مدل Spotify شامل موارد زیر است:
1 . فرآیند و تشریفات رسمی کمتر
مدل Spotify بر سازماندهی حول محور کار و نه لزوما فرآیندها و تشریفات متمرکز است. این امر در مورد نحوه کار Squad ها، انعطافپذیری بیشتری به سازمان میدهد. این کار به جای اینکه Squad ها را ملزم به تغییر نحوه انجام کار خود کند ('شما باید اسکرام را انجام دهید')، بر روی همسوسازی آنها با یکدیگر و هدایت نتایج تیمی متمرکز است.
2 . خودمدیریتی و خودمختاری بیشتر
این مدل با اعتماد به افراد برای تکمیل کارهایی که انجام میدهند به روشی که صلاح میدانند، استقلال و خلاقیت را تشویق میکند. آیا شما نیاز به انتشار نرمافزار دارید؟ این به Squad بستگی دارد. آیا شما نیاز به تغییر جهت دارید؟ این نیز به Squad بستگی دارد. مدل Spotify بر تمرکززدایی در تصمیمگیری و انتقال این مسئولیت به Squad ها، Tribe ها، Chapter ها و Guild ها متمرکز است. در واقع کنترل منجر به موافقت و پذیرفتن میشود در حالی که خودمختاری منجر به تعامل میشود. این مدل میتواند شفافیت بیشتری را در مورد کار انجام شده ارائه دهد و رویکرد مبتنی بر تست و آزمایش را برای حل مسئله در یک محیط با اعتماد بالا رشد دهد. همه اینها میتواند منجر به مواردی مانند محصولات بهتر، مشتریهای شادتر و کارمندان بیشتر شود. با این حال، همه این نتایج را تجربه نخواهند کرد.
مدل Spotify بر اساس روش کار یک سازمان ساخته شده بود. بسیاری از سازمانها مزایای مشابه مدل Spotify را میخواهند، بنابراین سعی میکنند آنچه Spotify انجام داده است را تقلید کنند. برخی از سازمانها موفقیت بیشتری نسبت به سازمانهای دیگر تجربه کردهاند، اما احتمالا هیچ سازمانی همان موفقیت Spotify را تجربه نکرده است. دلیل؟ مانند هر روش کار، فرهنگ و ساختار فعلی یک سازمان باید مورد توجه قرار گیرد. مدل ساده است، اما محیطی که در آن پیادهسازی شده پیچیده است. مدیران خردمند رویکرد خود را متناسب با پیچیدگی شرایطی که با آن روبرو هستند، تنظیم میکنند.
متأسفانه، بسیاری از سازمانها سعی میکنند مدل Spotify را کپی کنند. از نظر برخی، ممکن است یک ساختار سازمانی ماتریسی ساده باشد که در آن افراد به یک بخش متناسب با عملکردشان(Chapter) گزارش میدهند، اما با یک تیم چند منظوره(Squad) کار میکنند. با این حال، پیچیدهتر از آن است. اگرچه ممکن است مانند یک سازمان ماتریسی به نظر برسد، اما برای رشد ساختار مانند اعتماد و خودمختاری، باید عناصر اصلی فرهنگی مدل وجود داشته باشد. اگر سازمانی رفتارهای خود (و در نهایت فرهنگ خود) را تغییر ندهد، مزایای مدل Spotify هرگز محقق نخواهد شد. اگر تیمها را به راحتی به Squad ها تغییر نام دهید، فقط روی یک خوک رژ لب میگذارید.
اگر میخواهید فرهنگ اعتماد، خودمختاری و یادگیری سریع را فعال کنید، نمیتوانید برای الهام گرفتن از مدل Spotify اشتباه کنید. اگر سازمان شما به مدل Spotify به عنوان وسیلهای برای کمک به شما کمک میکند تا در مقیاس رویکرد چابک عمیق شوید، در زیر لیستی از بهترین روشهایی است که باید بخاطر بسپارید.
1 . مدل را کپی نکنید
به دنبال درک ساختار، عملکردها و طرز فکر پشت روش Spotify باشید. با این درک، جنبههای مدل را متناسب با محیط خود تغییر دهید. هدف شما Spotify بودن نیست، بلکه استفاده از مدل آنها برای بهبود عملکرد سازمان شما است.
2 . استقلال و اعتماد کلیدی هستند
اسپاتیفای هر چه بیشتر استقلال را به افراد خود داد تا بتواند به آنها کمک کند تا سریع عضو موثر و محوری شوند. اجازه دادن به تیمها برای انتخاب ابزارهای توسعه خود و تغییر کد تیم دیگری فقط چند نمونه از این موارد است. در داخل سازمان خود، تعیین کنید که تصمیماتی وجود دارد که میتواند به جای اینکه توسط بخشهایی از سازمان که از کار روزمره جدا شدهاند به تیمها القا شود، توسط تیمها گرفته شود.
3 . شفافیت با جامعه
موفقیت Spotify مدیون توجه آنها به ایجاد جامعه و شفافیت در مورد کارشان است. اولین Guild خود را در مورد پذیرش مدل Spotify تأسیس کنید و مشارکت همه افراد در سازمان را تشویق کنید. با ایجاد روشهای شفاف و فراگیر برای جمعآوری بازخورد و ایجاد هماهنگی در مورد چگونگی فعالیت سازمان شما در آینده، اعتماد ایجاد کنید.
4 . تشویق به اشتباه کردن
در این مسیر زمین خواهید خورد و لغزش خواهید کرد. اما مشکلی نیست پیشرفت شامل تست و آزمایش و یادگیری از موفقیتها و شکستهای ما است. شرکت تکرارهای زیادی را قبل از دستیابی به الگویی که امروز میشناسیم، پشت سر گذاشته است و از آن زمان به تست و آزمایش خود ادامه داده است تا دائما به دنبال راههای جدید برای بهبود روند کار باشد. در سازمان خود این روش را تشویق کنید!
اگر روی این روشها تمرکز کنید، تأثیرات مثبتی در نحوه همکاری و همسویی سازمان خود خواهید دید، خواه از مدل Spotify به عنوان راهنما استفاده کنید یا نکنید.
هدف اصلی این است که یک انتشار کوچک و مکرر داشته باشید و بر روی اتوماسیون و زیرساختهای انتشار مستمر سرمایهگذاری کنید. هنگامی که فرآیند انتشار دشوار است، حتی انتشار نسخههای ساده و کوچک نیز دشوار است. از طرف دیگر، هنگامی که فرآیند انتشار آسان است، انتشار میتواند بیشتر انجام شود!
به جای ایجاد قوانین و فرآیندهای دست و پا گیر برای مدیریت انتشارها، برای تشویق انتشارهای کوچک و مکرر باید فرآیند کار را ساده کرد. آنها معماری را تغییر دادند تا انتشارهای جدا شده را با استفاده از چهارچوب تعبیه شده رمزگذاری شده فعال كنند. هر بخش از مرورگر وب مانند Frame یک وبسایت است که در آن هر تیم میتواند به طور مستقیم موارد شخصی خود را منتشر کند. آنها سه Squad مختلف بر اساس مدل سلف سرویس دارند.
1. Feature Squad:
اسکوادها در این مدل بر روی یک فیچر یا بخش خاصی از محصول تمرکز میکنند.
2 . Client App Squad:
بر ساخت و عرضهی آسان محصول بر اساس پلتفرم مورد نظر مانند اندروید، PWA و غیره تمرکز میکنند.
3 . Infrastructure Squad:
متمرکز بر موثر تر کردن Squad نوع اول و دوم با نظارت بر آنها و تهیه ابزارها و برنامههای معمول برای Squad هاست.
در فرآیند مدیریت محصول باید در نظر داشت هر فیچر از یک نقشه راه برخوردار است. برای تحقق یک فیچر معمولا باید بین یک تا سه هفته زمان اختصاص داد. در صورتیکه زمان تحویل فیچر برسد و فیچری به صورت 100 درصد پیادهساز ی نشده باشد، انتشار محصول نباید معطل شده و متوقف شود بلکه انتشار محصول صورت میگیرد اما فیچر از دید کاربران مخفی خواهد ماند. اما چرا؟ پاسخ ساده است. شناسایی مشکلات احتمالی موجود و تصحیح این مشکلات در زمان تکمیل فیچر از یک سو، و اتخاذ تصمیم به عرضه و تحویل به موقع محصول با کمی نقص قابل اصلاح به جای تاخیر در انتشار محصول از اهم دلایل هستند. شکل زیر میتواند منظور را بهتر برساند:
"هدف ما این است که سریعتر از هر کس دیگری اشتباه کنیم" این جمله را بنیانگذار Spotify گفته است. ایده پشت آن این است که همراه با چرخه توسعه محصول، ما مرتکب اشتباه خواهیم شد و این اجتنابناپذیر است. بنابراین چرا وقتی شکست میخوریم سریعتر شکست نخوریم؟ هر شکست همچنین فرصتی برای یادگیری و اعتباربخشی به یادگیریهای ماست! این یک استراتژی برای موفقیت طولانیمدت است. این مدل بیشتر به بازیابی سریع شکست علاقهمند است تا اجتناب از شکست زیرا شکست خوردن بدون یادگیری فقط شکست است و آنها علاقهای به این کار ندارند. آنها آنقدر در این مورد جدی هستند که برخی از Squad ها دیواری به نام دیوار شکست برای به اشتراک گذاشتن شکستهای خود دارند، که به همه این فرصت را میدهد تا از شکستهای دیگران درس بگیرند.
مستندسازی پس از شکست
این فرآیندی است که معمولا در پایان یک پروژه انجام میشود و عناصر موجود در پروژه را که موفق یا ناموفق بودهاند تعیین و تجزیه و تحلیل میکند. این فرآیند آموختهها و پیشرفتهایی است که خطرات آینده را کاهش میدهد. وقتی مشکل حل شد کار به پایان نمیرسد. کار هنگامی به پایان میرسد که آنها برای جلوگیری از داشتن مشکل مشابه در آینده، آموختهها را فرا میگیرند.
بهبود مستمر
این Squad ها هر چند هفته یکبار با نگاهی به گذشته در مورد اینکه چه چیزی خوب پیش رفت و چه چیزهایی را باید در آینده بهبود ببخشند بحث و گفتوگو میکنند. بهبود مستمر از پایین هدایت میشود و از بالا پشتیبانی میشود.
شعاع انفجار محدود
شعاع انفجار محدود باعث میشود تیمها به جای اتلاف وقت در پیشبینی و کنترل همه خطرات، آزمایشهای کوچک زیادی انجام دهند و سریع از آنها بیاموزند.
با استفاده از معماری جدا شده، اگر هر تیمی اشتباه کند، تنها قسمت تحت تأثیر قسمت کوچکی از سیستم خواهد بود. همه چیز را خراب نمیکند از آنجایی که هر تیم مسئولیت پایان کار خود را بر عهده دارد، میتوانند مشکل را خیلی سریع برطرف کنند.
با استفاده از عرضه تدریجی، بسیاری از Feature های جدید به تدریج ارائه میشوند. این کار با درصد کمی از کاربران شروع میشود و از نزدیک کنترل میشود. هنگامی که ثابت شد این Feature پایدار است، شرکت به تدریج آن را برای بقیه کاربران عرضه میکند. بنابراین اگر مشکلی پیش بیاید، معمولا تعداد اندکی از کاربران نهایی را برای مدت زمان کوتاه تحت تأثیر قرار میدهد.
یک ایده محصول شگفتانگیز با یک شخص و یک الهام آغاز میشود. این فقط در صورتی واقعی میشود که به شخص اجازه داده شود بازی کند و چیزهایی را امتحان کند. بنابراین شرکت همه را تشویق میکند که 10٪ از وقت خود را صرف انجام ایدهپردازی یا بازی و آزمایش کنند. مهم نیست که ایده مفید باشد، نکته این است که اگر به تعداد کافی ایدههایی را امتحان کنید، هر از چندگاهی به یک ایده از جنس طلا دست پیدا خواهید کرد.
فرهنگسازی تست و آزمایش
با یک فرهنگ آزمایشپسند، افراد مجاز به تست و آزمایش چیزهای جدید هستند و این به جای یک محیط خودخواهانه یا اقتدارمحور، یک محیط مبتنی بر تصمیمات دادهمحور را ایجاد میکند.
فرهنگ دوری از موارد اضافی
افراد برای هر کاری که برای شرکت ارزش افزوده نداشته باشد توقف میکنند. آنها همچنین برای پروژههای بزرگ و هر چیزی که به تعداد زیادی از تیمها احتیاج داشته باشد در طی مدت چند ماه هماهنگ میشوند. پروژههای بزرگ همچنین به معنای خطرات بزرگ هستند، بنابراین آنها سازمان یافتهاند تا نیاز به پروژههای بزرگ را به حداقل برسانند. در عوض، آنها سخت تلاش میکنند تا پروژههای بزرگ را به بخشهای کوچکتر تقسیم کنند. البته استثنائاتی نیز وجود دارد و آنها از آن آگاه هستند! Spotify از برخی روشها برای به حداقل رساندن خطرات یک پروژه بزرگ استفاده میکند:
اسپاتیفای همچنین احساس نیاز به گروه کوچکی از گروههای رهبری کرد تا بتوانند با یک رهبر فناوری، رهبر محصول و یک رهبر دیزاین، نقشه راه کلان شرکت را تحت نظر داشته باشند.
بروکراسی زیاد یا بسیار کم، هر دو منجر به اتلاف وقت، انرژی و منابع میگردد. در همین راستا، فرهنگ چابک Spotify در مدیریت محصول باعث شده تا تعادل بین بروکراسی و بینظمی برقرار شود. همچنین جهت جلوگیری از اتلاف وقت و کاهش بروکراسی، پروژههای بزرگ به چندین پروژه کوچک تقسیم میگردند تا هم در زمان صرفهجویی شود و هم ریسک اشتباهات تیمها کاهش یابد و بر هم اثر نگذارند.
اسپاتیفای معتقد است بهترین روش برای کاهش هزینه و هدررفت منابع، مستندسازی و مصور نمودن پروسه مدیریت محصول و صحبت دربارهی آن است. اینکه چه موانعی سر راه رسیدن به هدف است؟ مشکلات فعلی چیست؟ چه کارهایی باید انجام داد؟ هدف بعدی چیست؟ هدف نهایی و غایی چیست؟ و ... . در Spotify تمام موارد بالا روی تخته سفیدی نوشته شده و در مورد آنها بحث و طوفان فکری انجام میگردد تا اعضای Squad ها، متوجه اوضاع کلی شده و به درکی مشترک برسند.
اگر به دنبال ایجاد سازمانی متمرکز بر حرکت سریع به همراه خودمختاری و هدفمندی هستید، مدل Spotify منبع عالیای میباشد. Spotify جامعه سلسله مراتبی را تحت فشار قرار داد و معتقد بود که یک جامعه به اندازه کافی قوی میتواند تصمیمات درست را بدون نیاز به تأیید رهبران متمرکز بالادستی بگیرد. Spotify معتقد بود که با ایجاد یک جامعه مستقل و خودمختار از طریق Squad ها، Tribe ها، Chapter ها و Guild ها در حال ساخت یک تیم محصولی هستند که به سادگی پتانسیل 'ایجاد چیزهای بهتر' را دارد. حتی بیشتر چهارچوبهای رسمی مانند Scrum@Scale از این مدل الهام گرفتهاند (و بالعکس). مهم است که به یاد داشته باشید که مدل Spotify مقصد و هدف نیست. از قضا، Spotify دیگر از اجرای مدل اولیه Spotify استفاده نمیکند. آنها تکامل یافته و مدل را متناسب با تغییرات سازمان خود سازگار کردند. Trio ها و Alliance ها در واقع عناصر جدیدتری در Spotify هستند زیرا برای حل مشکلات جدیدی که سازمان با بزرگتر شدن خود با آن روبرو بود ایجاد شد. شروع با عناصر کلیدی مدل Spotify میتواند شما را به حرکت درآورد، اما چابکی واقعی همراه با تکامل مدل متناسب با شرکت و حوزه فعالیت شماست.
اگر شما مشتاق هستید که درباره مدل Spotify بیشتر بدانید، فیلم دو قسمتی ارسال شده در Spotify Labs درباره فرهنگ مهندسی در Spotify (قسمت اول و قسمت دوم) را تماشا کنید. اگر میخواهید مدل Spotify را در سازمان خود پیاده کنید، داشتن مکانیزم بازخورد گرفتن و شفافیت برای ایجاد و تداوم فرهنگ اعتماد و خودمختاری بسیار مهم است.
اگر شما هم نقطه نظر یا تجربهای در بررسی و اجرای این ساختارها در سازمان خود دارید، خوشحال میشم توی قسمت کامنتها تجربهتون رو باهام به اشتراک بذارید.