مسعود بهرامی
چگونه در مسیر بزرگ شدن، روح چابکی را قربانی سلسلهمراتب نکنیم؟
وقتی رشد، قاتل نوآوری میشود
در دنیای استارتاپها، سرعت، خداست. تیمهای کوچک، تصمیمات سریع میگیرند، شکست میخورند و اصلاح میکنند. اما زمانی که یک سازمان از مرحله بقا به مرحله تسلط بر بازار میرسد، نیاز به مقیاسپذیری (Scaling) پیدا میکند. اینجا دقیقاً جایی است که تضاد بنیادین رخ میدهد:
مقیاسپذیری به دنبال نظم و کنترل است، در حالی که چابکی به دنبال خودگردانی و آشوبِ کنترلشده است.
در استارتاپها، سرعت پاسخگویی به تغییرات و خلق ارزش اولیه برای مشتری، خداست!
بسیاری از سازمانها در مسیر رشد، بدون اینکه متوجه باشند، از یک ارگانیزم زنده و چابک به یک ماشین بخار سنگین و کند تبدیل میشوند. در این مقاله به بررسی این بحران خواهم پرداخت که، چرا اسکیل کردن تیمها معمولاً به معنای مرگ چابکی است و چگونه میتوان با الگوهایی مانند مدل آمازون، توازن را برقرار کرد؟
نقد سلسلهمراتبهای پنهان؛ توهم تیمهای خودگردان
بسیاری از سازمانها ادعا میکنند که از مدلهای چابک مانند Spotify Model استفاده میکنند. آنها اسکوادها (Squads)، قبیلهها(Tribes) و چپترها(معادل مناسب به ذهنم نرسید!)(Chapters) را ایجاد میکنند. اما یک حقیقت تلخ وجود دارد: بسیاری از این ساختارها، تنها پوستهای جدید برای همان سلسلهمراتب قدیمی هستند. در ادامه به برخی از این چالشها و تضادها که به تجربه به آن برخورد کردهام و البته دیگران هم گزارش دادهاند خواهم پرداخت.
تضاد در اصلاح اسکواد (The Squad Correction Paradox)
در مدلهای چابک، اسکواد باید خودگردان (Self-organizing) باشد. اما در واقعیت، ما با نوعی سلسلهمراتب تصمیم گیری و تایید و اصلاح و کامندی روبرو هستیم. چیزی شبیه ساختار سلسله مراتب نظامی، با کمترین تفویض اختیار. ژنرال، سرهنگ و سرگرد و … تا وقتی به تیم و جوخه و سربازها و گروهبانها میرسید، آن چیزی که به عنوان تیم خود سازمانده و خودگردان دیگر چیزی جز شوخی نیست. وقتی یک اسکواد مسیر خود را انتخاب میکند، بلافاصله با لایه مدیریت محصول یا مدیران فنی ارشد برخورد میکند که وظیفه آنها اصلاح یا تایید است.
اگر اسکواد نتواند بدون اجازه از لایههای بالاتر، استراتژی فنی یا محصولی خود را تغییر دهد، پس آن اسکواد یک تیم چابک نیست؛ بلکه یک واحد اجرایی است که تحت مدیریت یک سلسلهمراتب پنهان قرار دارد. این یعنی تصمیمگیری هنوز متمرکز است و فقط اجرا توزیع شده است.
گلوگاههای تصمیمگیری (Decision Bottlenecks)
در سازمانهای در حال رشد، مشکل اساسی و شماره 1، کمبود نیروی متخصص نیست، بلکه کمبود افراد دارای حق تصمیمگیری است. وقتی هر تصمیم مهم (از انتخاب یک کتابخانه جدید تا تغییر یک ویژگی محصول) نیاز به تایید یک مدیر ارشد یا یک کمیته داشته باشد، سرعت تیم به سرعتِ کندترین فرد/تیم/واحد تصمیمگیرنده ( slowest-decision-maker ) کاهش مییابد. این یعنی اسکیل کردن تیمها در واقع اسکیل کردن انتظار است.
در سازمانهایی که تیم توسعه توانایی و اختیار تصمیمگیری و تصمیمسازی ندارد، در ایدهآلترین حالت ممکن، سرعت تیم به سرعتِ کندترین فرد/تیم/واحد تصمیمگیرنده ( slowest-decision-maker ) کاهش مییابد.
درس آمازون؛ فرهنگ Day One و ساختار تیمهای کوچک
جف بزوس، بنیانگذار آمازون، با یک فلسفه ساده اما عمیق، سازمان را از یک فروشگاه کتاب به یکی از بزرگترین امپراتوریهای جهان رساند:
اگر روز اول که در گاراژ شروع بکار کردیم، و بهدور از تشریفات و بروکراسی، بالاترین راندمان کاری را داشتیم، و بیشتری نخ رضایت مشتریان را میتوانستیم خلق کنیم، الان که تعداد افراد در سازمان از تعداد انگت شمار روز اول به هزاران نفر در سراسر جهان رسیده است، با اسکیل شدن تعداد افراد، همان فرهنگ روز اول را برای تیمها در پیش خواهیم گرفت. همیشه روز اول است (It’s always Day One).
فلسفه Day One در مقابل Day Two
این جک در آمازون و به نقل از جف بزوس وجود دارد که در آمازون، Day Two یعنی مرگ. یعنی سازمان زمانی که احساس کند به ثبات رسیده، شروع به ایجاد فرآیندهای سنگین، سلسلهمراتبهای پیچیده و محافظهکاری میکند. در Day Two، تصمیمگیریها به جای مشتری، بر اساس ترس از اشتباه انجام میشود.
در آمازون، Day Two یعنی مرگ
تیمهای Day One همیشه با حس یک استارتاپ حرکت میکنند؛ آنها اجازه دارند ریسک کنند، سریع حرکت کنند و مهمتر از همه، آنها مالکیت (Ownership) دارند.
تیمهای دو پیتزایی (Two-Pizza Teams)
یکی از کاربردیترین ابزارهای آمازون برای حل چالش اسکیل کردن، قانون تیمهای دو پیتزایی است. این یک قانون فان است که بصورت ساده بیان میکند که، تیم شما نباید آنقدر بزرگ باشد که با دو پیتزا سیر نشود.
اما نقطه قوت و ریزبینی این قانون در اندازه تیم (و البته پیتزا 😉)نیست، در ساختار تیمها (باز هم نه پیتزاها 😉) است. تیمهایی که در ساختار فرهنگی آمازون شکل میگیرند، انتظار میرود که خصوصیات زیر را دارا باشند:
- استقلال کامل دارند: آنها نه تنها کد میزنند، بلکه مسئولیت بیزنس، دیتابیس، زیرساخت و حتی پشتیبانی مشتری را نیز بر عهده دارند.
- تکنولوژی را خودشان انتخاب میکنند: آنها به جای انتظار برای دستور از بالا، ابزار لازم برای رسیدن به هدف را خودشان تامین میکنند.
- مسئولیتپذیری end-to-end:وقتی تیمی مسئول تمام چرخه زندگی محصول است، دیگر کسی نیست که بگوید این مشکل مربوط به تیم زیرساخت است.
چالشهای واقعی در سازمانهای ایرانی و راهکارهای کاربردی
انتقال مدلهای جهانی به بستر سازمانهای ایرانی با چالشهای فرهنگی و ساختاری خاصی روبرو است. به برخی از این چالشها در ادامه اشاره شده است.
چالش ۱: فرهنگ تایید از بالا (Approval Culture)
در بسیاری از سازمانهای ایرانی، مدیریت به معنای کنترل تلقی میشود. مدیران احساس میکنند اگر حق تصمیمگیری را به تیم بدهند، کنترل خود را از دست داده و مسئولیت شکست را نیز بر عهده میگیرند.
راهکار: تغییر پارادایم از مدیریت کنترلگر به مدیریت تسهیلگر. مدیر باید به جای اینکه بگوید این کار را انجام بده، بپرسد چه مانعی جلوی شماست تا این کار را انجام دهید؟.
چالش ۲: تخصصگرایی افراطی (Siloed Expertise)
در ایران، تمایل به جدا کردن شدید تیمها از جمله تیم توسعه، تیم تست، تیم DevOps، تیم DBA بسیار بالاست. این باعث میشود تیمها در زنجیره ارزش(Value Stream) خود کور شوند.
راهکار: حرکت به سمت تیمهای Cross-functional. یک تیم باید تمام قطعات پازل را در اختیار داشته باشد تا بتواند بدون وابستگی به تیمهای دیگر، یک ویژگی را از ایده تا تولید (Production) برساند.
چالش ۳: ترس از شکست و جریمه شدن
در محیطی که اشتباه با توبیخ یا بازنگری در عملکرد همراه است، هیچکس حق تصمیمگیری نمیخواهد. تصمیمگیری بدون پذیرش ریسک، یعنی تصمیمگیری هوشمندانه؛ اما در فرهنگ ما، ریسک یعنی خطر.
راهکار: ایجاد امنیت روانی (Psychological Safety). سازمان باید محیطی فراهم کند که در آن “شکستهای یادگیرنده” جشن گرفته شوند و “شکستهای ناشی از بیدقتی” اصلاح گردند.
پرسشهای تاملبرانگیز برای رهبران نرمافزار
یک راهکار ساده برای اینکه متوجه شوید و سرنخ داشته باشید که آیا ساختار تیمهای شما برای موفقیت بنا نهاده شده است، یا در عوض بیشتر بر بروکراسی افزوده و سرعتگیر چابکی شدهاند، تامل و پاسخ به یکسری سوالات سادهای است که در ادامه خواهید دید. اگر شما در یک سازمان در حال رشد هستید، این سوالات را از خود بپرسید (و پاسخهای صادقانه به خود بدهید):
- آیا تیمهای من تصمیم میگیرند یا فقط اجرا میکنند؟ اگر برای تغییر یک پارامتر کوچک در دیتابیس، تیم باید جلسه برگزار کند و اجازه بگیرد، شما یک سازمان چابک ندارید؛ شما یک کارخانه با لباس چابک دارید.
- اگر من (مدیر) برای یک ماه از سازمان غایب باشم، آیا تیمها میتوانند به رشد خود ادامه دهند یا فرآیندها متوقف میشوند؟ پاسخ این سوال، میزان واقعی حق تصمیمگیری توزیع شده در سازمان شماست.
- آیا ما در حال اسکیل کردن کد هستیم یا در حال اسکیل کردن مشکلات؟ بسیاری از سازمانها با اضافه کردن افراد، پیچیدگی را بیشتر میکنند (Brook’s Law). . در اینجا بد نیست اشارهای به قانون بروک کنم که اشاره میکند افزودن افراد جدید به تیم زمان اتمام کار را کم که نمیکند، که بیشتر هم میکند، آنهم به دلیل افزایش بارِ هماهنگی (Coordination Overhead) بین اعضای تیم.
- آیا ساختار ما بر اساس تخصصی بودن است یا بر اساس ارائه ارزش؟ اگر تیمها بر اساس نوع تکنولوژی (تیم فرانت، تیم بک، تیم DB) تقسیم شدهاند، شما در حال ساختن سیلو هستید. اگر بر اساس قابلیتهای محصول (تیم پرداخت، تیم جستجو) هستند، شما در حال ساختن ارزش هستید.
بازگشت به اصل مسئله
مقیاسپذیری در نرمافزار، یک مسئله فنی نیست؛ یک مسئله اجتماعی و ساختاری است. بزرگ شدن یک سازمان نباید به معنای اضافه کردن لایههای جدیدی از بله/خیر باشد.
برای حفظ روح چابکی، باید یاد بگیریم که قدرت را از مرکز به حاشیه منتقل کنیم. باید از مدلهای سلسلهمراتب سنتی که بر پایه “اطاعت” بنا شدهاند، به سمت مدلهایی حرکت کنیم که بر پایه مالکیت و مسئولیتپذیری بنا شدهاند.
بزرگ شدن واقعی زمانی رخ میدهد که سازمان بتواند بدون از دست دادن سرعتِ یک تیم دو پیتزایی، پیچیدگیهای یک امپراتوری را مدیریت کند. این کار با قوانین سختگیرانه ممکن نیست؛ بلکه تنها با *اعتماد، شفافیت و فرهنگ Day One میسر است.
آیا شما آمادهاید که کنترل را رها کنید تا رشد را به دست آورید؟
برای حفظ روح چابکی، باید یاد بگیریم که قدرت را از مرکز به حاشیه منتقل کنیم.
