مسعود بهرامی
چرا بسیاری از تیمهای موفق، همان ویژگیهایی را از دست میدهند که باعث موفقیتشان شده بود؟
از تیمهای دو پیتزایی آمازون تا شرکتهایی که دیگر محصول نمیسازند
اگر از من بپرسید مهمترین تفاوت یک استارتاپ ۲۰ نفره با یک سازمان ۲۰۰۰ نفره چیست، احتمالا برخلاف انتظار از تکنولوژی، بودجه، فرآیند یا ساختار حرف نخواهم زد. به نظرم تفاوت اصلی در جای دیگری است. در یک استارتاپ کوچک، تقریباً همه افراد سازمان به مسئله نزدیکاند. در یک سازمان بزرگ، بیشتر افراد به ساختار نزدیکاند.
در یک استارتاپ کوچک، تقریباً همه افراد سازمان به مسئله نزدیکاند. در یک سازمان بزرگ، بیشتر افراد به ساختار نزدیکاند.
و همین تغییر ظاهرا ساده، سرآغاز بسیاری از اتفاقاتی است که بعدها آنها را با نامهایی مانند کند شدن نوآوری، افزایش بروکراسی، کاهش چابکی، فرسودگی تیمها یا حتی مرگ محصول میشناسیم. موضوع جالب اینجاست که این اتفاق معمولا ناگهانی رخ نمیدهد.
هیچ شرکتی یک روز صبح از خواب بیدار نمیشود و تصمیم نمیگیرد نوآوری را کنار بگذارد. هیچ مدیری جلسهای برگزار نمیکند و نمیگوید: بیایید از امروز مشتری را فراموش کنیم و به جای آن چند لایه مدیریتی دیگر اضافه کنیم.
اما با وجود این، بارها و بارها شاهد تکرار همین الگو بودهایم. سازمانهایی که روزی به خاطر سرعت، خلاقیت و جسارتشان شناخته میشدند، سالها بعد به مجموعهای از فرآیندها، کمیتهها و تأییدیهها تبدیل شدهاند.
این نزدیکی به ساختار چه شکلی در تقویم روزانه یک مدیر دیده میشود؟
نزدیکی به ساختار یعنی مدیر روزش رو با ۸ جلسه هماهنگی پر میکند و آخر هفته میفهمد که حتی یک بار هم با مشتری حرف نزده است. یعنی که تیم برای تغییر یک دکمه باید ۳ سطح تأیید بگیرد. و یا حتی یعنی گزارشهای وضعیت مهمتر از خود وضعیت میشوند-در قالبهای چابکی از جمله رتروسپکتیو و برنداون چارت و … .
یه سوال کوتاه دیگر، آیا نزدیکی به ساختار همیشه بد است؟
راستش را بخواید، نه، همیشه نه. در سازمانهایی که مسئلهشان سالهاست حل شده و فقط نیاز به اجرای بیخطا دارند (مثل خط تولید یک کارخانه یا پردازش اظهارنامههای مالیاتی)، نزدیکی به ساختار میتواند کارآمد باشد. اما در دنیای محصولات نرمافزاری که مسئله هر چند ماه یک بار عوض میشود؟ چرا در همچین جاهایی این یعنی یک زنگ خطر. پس شاید این قانون ساده رو بتونم اینطوری بگم که: هر جا سرعت تغییر مسئله از سرعت تغییر ساختار بیشتر شد، نزدیکی به ساختار تبدیل به سرطان میشود. نه پیش از آن.
وقتی مسئله اصلی دیگر محصول نیست
استارتاپها معمولا با یک مسئله واقعی متولد میشوند. گروهی از افراد جمع میشوند چون فکر میکنند چیزی در دنیا باید بهتر از وضعیت فعلی باشد. تمرکز آنها روی مشتری است، روی مسئله است، روی درد افراد است،بر روی بهینهسازی یک راهحل ارائهشده برای مشتری است، و در نهایت اینکه برروی خلق ارزش است.
اما سازمانها پس از مدتی وارد مرحله دیگری میشوند. در این مرحله دیگه سوال اصلی این نیست که: چگونه برای مشتری ارزش بیشتری خلق کنیم؟ سوال کمکم تبدیل میشود به اینکه:چه کسی باید این تصمیم را تأیید کند؟
در ظاهر تفاوت کوچک و کم ارزشی است. اما در واقع و روی زمین، این طرز تفکر منجر به یک تفاوت بنیادین میشود. در حالت اول، انرژی سازمان صرف حل مسئله میشود. در حالت دوم، انرژی سازمان صرف مدیریت خود سازمان میشود. و این همان نقطهای است که پیری آغاز میشود.
نقطهی شروع پیری سازمان وقتی است که انرژی سازمان صرف مدیریت خود سازمان میشود، نه حل مسئله کاربران و خلق ارزش واقعی.
استیو جابز و مسئلهای که هنوز حل نشده است
استیو جابز سالها قبل درباره پدیدهای صحبت کرده بود که امروز تقریبا در همه شرکتهای بزرگ میتوان رد آن را دید.
او معتقد بود بسیاری از شرکتهای بزرگ نه به خاطر کمبود استعداد و نه به خاطر ضعف تکنولوژی، بلکه به دلیل فاصله گرفتن از محصول شکست میخورند.
استیو جابز معتقد بود بسیاری از شرکتها زمانی مسیر نزولی خود را آغاز میکنند که افرادی که عاشق محصول هستند، جای خود را به افرادی میدهند که عاشق مدیریت سازمان هستند. این جمله را نباید اشتباه تفسیر کرد. جابز مخالف مدیریت نبود. اپل یکی از منظمترین سازمانهای دنیا بود و هست. مسئله او چیز دیگری بود.
در نگاه جابز، شرکتها ابتدا توسط افرادی ساخته میشوند که عاشق محصول هستند.
اما با رشد سازمان، کمکم افرادی در ساختار قدرت(تصمیم گیری) قرار میگیرند که تخصص اصلیشان ساختن محصول نیست؛ بلکه مدیریت سازمان است.
استیو جابز میگفت زمانی که معیار موفقیت در سازمان از خلق محصول بهتر به مدیریت ساختار بزرگتر تغییر کند، اتفاق خطرناکی رخ میدهد. در روزهای ابتدایی یک استارتاپ، افراد برای حل مسئله جمع میشوند. اما در بسیاری از سازمانهای بزرگ، بخش قابل توجهی از افراد مشغول مدیریت پیامدهای رشد سازمان هستند. این دو فعالیت یکسان نیستند.
و متاسفانه دومی بهتدریج اولی را میبلعد. شاید به همین دلیل است که بسیاری از شرکتها در ظاهر موفقتر میشوند، اما در باطن کندتر، محافظهکارتر و کمخلاقیتتر میشوند. آنها رشد میکنند. اما دیگر نوآوری نمیکنند. آنها بزرگتر میشوند. اما لزوماً بهتر نمیشوند.
چرا سازمانها عاشق سلسلهمراتب میشوند؟
پاسخ کوتاه این است: چون سلسلهمراتب در کوتاهمدت احساس امنیت ایجاد میکند. وقتی سازمان کوچک است، تصمیمگیری توزیع شده است. افراد نزدیک به مسئله تصمیم میگیرند.
اما هرچه سازمان بزرگتر میشود، ترس نیز بیشتر میشود. ترس از اشتباه. ترس از ریسک. ترس از شکست. در نتیجه سازمان تلاش میکند تصمیمگیری را کنترل کند.
ابتدا یک مدیر اضافه میشود. بعد یک مدیر ارشد. بعد یک کمیته. بعد یک شورای راهبری. بعد یک فرآیند تأیید. و هرکدام از اینها در زمان ایجاد شدن کاملاً منطقی به نظر میرسند. مشکل اینجاست که هیچکدام به تنهایی خطرناک نیستند. اما مجموع آنها سرعت سازمان را نابود میکند.
سازمان عاشق سلسله مراتب هستند، چون احساس میکنند سلسله مراتب امنیت میآورد.
توهم خطی بودن مسائل پیچیده
و اما یک دلیل دیگر، شاید عمیقتر از ترس از اشتباه. سازمانها تمایل دارند مسائل پیچیده را خطی ببینند. یعنی فکر میکنند اگر A را بدهیم، B را میگیریم. اگر این مدیر را اضافه کنیم، آن مشکل حل میشود. اگر این فرآیند را بنویسیم، آن خطا دیگر تکرار نمیشود. سلسلهمراتب به همین درد میخورد: جای همه را مشخص میکند. معلوم میشود چه کسی به چه کسی گزارش میدهد. چه کسی مسئلهی کیست. اما حقیقت این است که بیشتر مسئلههای دنیای محصول، خطی نیستند. پیچیدهاند. غیرقابل پیشبینی. سلسلهمراتب این پیچیدگی را از بین نمیبرد. فقط آن را به طبقات مختلف پخش میکند. و در این میان، هیچکس دیگر صاحب کل مسئله نیست.
گلوگاه واقعی در سازمانهای بزرگ
بسیاری از مدیران تصور میکنند گلوگاه رشد، کمبود توسعهدهنده، یا کمبود بودجه، یا زیرساخت و امثالهم است، اما تجربه چیز دیگری میگوید. گلوگاه واقعی اغلب تصمیمگیری است.
فرض کنید تیم شما برای انتخاب یک کتابخانه جدید باید منتظر تأیید معمار سازمان بماند. برای تغییر یک قابلیت محصول باید منتظر جلسه مدیر محصول باشد. برای انتشار یک سرویس باید منتظر تیم زیرساخت بماند. برای تغییر یک شاخص کسبوکار باید منتظر مدیر واحد باشد. در چنین سازمانی مهم نیست چند توسعهدهنده استخدام کنید.
گلوگاه واقعی در سازمانها اغلب تصمیمگیری است.
سرعت کل سیستم برابر است با سرعت کندترین تصمیمگیرنده. به بیان دیگر: شما در حال اسکیل کردن تیمها نیستید. شما در حال اسکیل کردن صف انتظار هستید.
نقد سلسلهمراتبهای پنهان؛ توهم تیمهای خودگردان
در دو دهه گذشته مدلهای مختلفی برای حل مسئله مقیاسپذیری سازمانهای نرمافزاری مطرح شدهاند. از Scrum و SAFe گرفته تا Spotify Model و Team Topologies.
تقریبا همه این مدلها یک هدف مشترک دارند: افزایش سرعت تصمیمگیری از طریق توزیع اختیار. اما در بسیاری از سازمانها اتفاق عجیبی رخ میدهد. واژگان جدید وارد سازمان میشوند؛ اسکواد، ترایب، چپتر، گیلد و دهها اصطلاح دیگر. نمودار سازمانی تغییر میکند. عنوانهای شغلی جدید تعریف میشوند. اما رفتار سازمان تقریبا همان رفتار گذشته باقی میماند. ساختار تغییر میکند، اما الگوی تصمیمگیری تغییر نمیکند. در ظاهر، تیمها خودگردان هستند. در عمل، همچنان منتظر تأیید هستند.
پارادوکس اصلاح اسکواد
بسیاری از سازمانها میگویند تیمهایشان Self-Organizing هستند. اما کافی است یک تیم بخواهد تصمیم مهمی بگیرد. تصمیم از جمله تغییر در اولویتهای محصول، تغییر در طراحی یک قابلیت، تغییر در معماری یک سرویس و یا تغییر در انتخاب فناوری. در اغلب موارد، تصمیم نهایی همچنان باید از چندین لایه عبور کند. مدیر محصول، مدیر فنی، کمیته معماری، مدیر واحد یا ترکیبی از همه آنها. چیزی شبیه ساختار سلسله مراتب نظامی.
این اسامی هرچند جذاب، به ندرت رفتاری را تغییر دادهاند. الحق که سرچوخه و اسکواد و … اینجا اسامی با مثمایی بودند 🙂
در چنین شرایطی تیم خودگردان نیست. تیم فقط در نحوه اجرای تصمیمات آزادی دارد، نه در خود تصمیمگیری. و این تفاوت کوچکی نیست، بهعکس یک تفاوت بسیار ریز و تریکی ولی با تاثیرات عمیق است(پیشنهاد میکنم یکبار دیگر جمله قبلی رو بخونید). بسیاری از سازمانها اختیار اجرا را توزیع کردهاند، اما اختیار تصمیمگیری را همچنان متمرکز نگه داشتهاند. و این دقیقاً همان نقطهای است که توهم چابکی شکل میگیرد.
گلوگاه واقعی سازمانهای در حال رشد
وقتی درباره مقیاسپذیری صحبت میکنیم، معمولاً ذهن ما به سمت سرورها، دیتابیسها و زیرساخت میرود. اما در بسیاری از شرکتها اولین چیزی که مقیاسپذیر نیست، معماری نرمافزار نیست. معماری تصمیمگیری است. در سازمانهای در حال رشد معمولاً مشکل اصلی کمبود برنامهنویس نیست. کمبود افرادی است که حق تصمیمگیری دارند.
فرض کنید ده تیم توسعه دارید. هر تیم میتواند روزانه ده تصمیم بگیرد. اما برای هر تصمیم مهم باید منتظر نظر یک مدیر ارشد یا یک کمیته مرکزی بماند. در این حالت شما ده تیم مستقل ندارید. شما یک گلوگاه مرکزی دارید که ده تیم به آن متصل شدهاند.
سرعت کل سازمان دیگر به سرعت سریعترین تیم بستگی ندارد. به سرعت کندترین تصمیمگیرنده بستگی دارد.
به عبارتی دیگر:
سازمانها معمولاً تیمها را اسکیل میکنند، اما فراموش میکنند که فرآیند تصمیمگیری را نیز باید اسکیل کنند.
خب باید بگم که نتیجه کاملا قابل پیشبینی است(حداقل از نظر من). تعداد افراد افزایش پیدا میکند. تعداد جلسات افزایش پیدا میکند. تعداد هماهنگیها افزایش پیدا میکند. اما سرعت خلق ارزش تقریبا ثابت میماند. گاهی حتی کمتر هم میشود.
مسئله فقط بوروکراسی نیست
نکته مهم اینجاست که این وضعیت معمولا از نیت بد مدیران ایجاد نمیشود. برعکس. اغلب مدیران ارشد به این دلیل وارد تصمیمها میشوند که نگران کیفیت هستند. نگران یکپارچگی محصول هستند. نگران اشتباهات پرهزینه هستند.
اما همین مداخلههای خیرخواهانه به مرور یک پیام پنهان به سازمان منتقل میکند: تصمیم نهایی جای دیگری گرفته میشود.
و از همان لحظه اتفاق خطرناکتری رخ میدهد. تیمها کمکم تصمیمسازی را متوقف میکنند. چرا باید برای مسئلهای چند ساعت فکر کنیم وقتی در نهایت فرد دیگری تصمیم خواهد گرفت؟ چرا باید مسئولیت ریسک را بپذیریم وقتی اختیار واقعی نداریم؟
در این نقطه سازمان دیگر با کمبود استعداد مواجه نیست. با کمبود مالکیت مواجه است.
درس بزرگ آمازون
یکی از دلایلی که آمازون هنوز برای بسیاری از رهبران فناوری جذاب است، تکنولوژی آن نیست. فرهنگ آن است. جف بزوس سالها بر یک ایده پافشاری کرد:
در آمازون همیشه روز اول است.
Day One فقط یک شعار نیست. به نظرم که بیشتر یک هشدار جدی است. هشداری درباره چیزی که بزوس آن را Day Two مینامید. Day Two زمانی آغاز میشود که سازمان بیشتر از مشتری، نگران خودش باشد. زمانی که فرآیندها مهمتر از نتیجه شوند. زمانی که اجتناب از اشتباه مهمتر از خلق ارزش شود. زمانی که سرعت جای خود را به تشریفات بدهد.
به همین دلیل آمازون مفهوم معروف Two-Pizza Team را مطرح کرد. بسیاری تصور میکنند این مفهوم درباره اندازه تیم است.
اما در واقع درباره مالکیت است. تیم دو پیتزایی تیمی نیست که فقط کوچک باشد. تیمی است که بتواند تصمیم بگیرد. مالک نتیجه باشد. و برای هر تصمیمی منتظر لایهای بالاتر نماند.
فلسفه بقا در مقیاس عظیم، کالبدشکافی فرهنگ Day One و مهندسی تیمهای آمازون
سازمانهایی که پیر نمیشوند
شاید تصور کنیم سازمانهای موفق، سازمانهایی هستند که نظم بیشتری دارند. اما تاریخ شرکتهای فناوری چیز دیگری نشان میدهد. سازمانهای ماندگار معمولا آنهایی نیستند که بیشترین کنترل را ایجاد کردهاند. بلکه آنهایی هستند که توانستهاند با وجود رشد، تصمیمگیری را تا حد ممکن نزدیک مسئله نگه دارند.
پارادوکس مقیاسپذیری انسانی در سازمانهایی که میخواهند چابک باشند/بمانند!
آنها فهمیدهاند که قدرت باید به جایی منتقل شود که اطلاعات وجود دارد(میتونید به فرهنگ context, no control از نتفلیکس نگاهی بیاندازید). نه به جایی که عنوان شغلی بالاتری وجود دارد. آنها فهمیدهاند که افراد نزدیک به مشتری، معمولاً تصویر دقیقتری از واقعیت دارند تا افرادی که چند لایه از آن فاصله گرفتهاند. و مهمتر از همه فهمیدهاند که نوآوری را نمیتوان با دستور ایجاد کرد.
نوآوری محصول اختیار است.
سوال واقعی
شاید سوال اصلی این نباشد که: چطور سازمان را بزرگ کنیم؟ هزاران کتاب برای پاسخ به این سوال نوشته شده است.
سوال سختتر این است: چطور سازمان را بزرگ کنیم بدون اینکه روح آن را از بین ببریم؟
چطور از یک تیم ۲۰ نفره به یک سازمان ۲۰۰۰ نفره برسیم، بدون اینکه سرعت تصمیمگیری، حس مالکیت و نزدیکی به مشتری را قربانی کنیم؟ پاسخ سادهای وجود ندارد. اما یک نشانه خوب وجود دارد. هر وقت دیدید افراد نزدیک به مسئله اختیار تصمیمگیری ندارند و افراد دور از مسئله اختیار تصمیمگیری دارند، احتمالا سازمان شما وارد مسیر پیری شده است.
و برعکس. هر جا تصمیمگیری نزدیک مسئله باقی بماند، هنوز نشانههایی از Day One زنده است. شاید در نهایت چابکی، اسکرام، کانبان یا ساختار سازمانی نباشد.
شاید چابکی فقط یک سوال باشد:
وقتی کسی بهترین شناخت را از مسئله دارد، آیا اجازه دارد درباره آن تصمیم بگیرد؟
اگر پاسخ این سوال نه باشد، احتمالا هیچ چارچوبی نمیتواند سازمان را نجات دهد.و اگر پاسخ بله باشد، شاید هنوز امیدی برای جوان ماندن سازمان وجود داشته باشد.
