در این اپیزود با محمد دست‌پاک همراه شدم تا از زاویه دید یک مدیر فنی که هم با مدیریت و هم با تیم فنی در تماس هست داستان‌های پشت این تصمیم را مرور کنم که چه می‌شود سازمان‌ها می‌پذیرند که یک اسکرام مستر یا مربی چابک (Agile Coach) استخدام کنند؟ چه داستانی پشت چنین اقدامی وجود دارد؟ جواب این سوال احتمالا به ما اسکرام مسترها و اجایل کوچ ها می‌تواند کمک کند با دید بهتری به سازمان‌ها کمک کنیم.
مهمان: محمد دست‌پاک، مدیر فنی
اجرا: پدرام کشاورزی، اسکرام مستر حرفه ای
تدوین: پانته‌آ شهریاری
سلام و درود به همه‌ی شنوندگان عزیز.
من پدرام کشاورزی هستم و با یکی دیگر از قسمت‌های پادکست «اجایل گپ» در خدمت شما قرار دارم. امروز تصمیم گرفتم با یکی از دوستان و همکاران قدیمی‌ام همراه شوم تا در مورد یکی از موضوعات مهم و چالش‌برانگیز، یعنی چالش‌های پیاده‌سازی اسکرام گفت‌وگو کنیم. پیش از ورود به بحث، از محمد می‌خواهم که خودش را معرفی کند.
محمد:
سلام و عرض ادب خدمت همه‌ی شنوندگان و مخاطبان «عجایب». من محمد دستگاه هستم. حدود هجده سال است که در حوزه‌ی فناوری اطلاعات فعالیت دارم و در چهار سال اخیر به‌عنوان مدیر فنی در استارتاپ‌ها و شرکت‌های مختلف مشغول بوده‌ام. همچنین به‌عنوان مربی و منتور فنی، با شرکت‌های گوناگون همکاری داشته‌ام.
پدرام:
خیلی ممنون محمد که دعوت من را پذیرفتی. موضوعی که می‌خواهم به آن بپردازیم این است: پیش از ورود یک اسکرام‌مستر به سازمان، چه شرایطی وجود داشته و چه اتفاقاتی رخ داده که در نهایت سازمان به این نتیجه رسیده که باید اسکرام‌مستر استخدام کند؟
این نگاه به گذشته می‌تواند کمک کند تا هم خود اسکرام‌مسترها و هم مدیران سازمان بهتر بدانند انتظارها چه خواهد بود و نقش اسکرام‌مستر دقیقاً در چه بستر و شرایطی تعریف می‌شود.
محمد:
اگر بخواهم بر اساس تجربه‌های خودم صحبت کنم، داستان تقریباً همیشه از یک نقطه شروع می‌شود. گروهی از افراد با انگیزه و تشنه‌ی رسیدن به یک هدف مشخص، دور هم جمع می‌شوند. این افراد ممکن است از بخش‌های مختلف باشند: بیزینس، بازاریابی یا فنی. آن‌ها در کنار یکدیگر تیمی کوچک تشکیل می‌دهند و برای رسیدن به هدف مشترک حرکت می‌کنند.
در این مرحله، همه‌چیز امیدوارکننده و مطلوب به نظر می‌رسد. تیم کوچک با تمرکز کامل روی توسعه‌ی محصول، به پیش می‌رود. محصول اولیه ساخته می‌شود، به تیم کسب‌وکار تحویل داده می‌شود و تیم بازاریابی آن را به دست مشتریان نهایی می‌رساند.
اما این پایان مسیر نیست. در دنیای امروز فناوری اطلاعات، هیچ محصولی پس از توسعه‌ی اولیه متوقف نمی‌ماند. محصول وارد چرخه‌های جدیدی می‌شود: رفع خطاها (Bug Fixing)، بهینه‌سازی (Tuning)، مقیاس‌پذیری (Scaling)، افزودن قابلیت‌های جدید (Feature Development)، بازطراحی (Redesign) و حتی بازنویسی (Refactoring).
از این نقطه به بعد، جنس کار تیم فنی تغییر می‌کند. تا پیش از این، تمرکز صرفاً بر توسعه‌ی اولیه‌ی محصول بود. اما حالا تیم باید در کنار توسعه‌ی فیچرهای جدید، مسئولیت‌های دیگری را نیز برعهده بگیرد:
نگهداری و پشتیبانی از محصول (Maintenance & Support)
پاسخ‌گویی به کاربران نهایی
مدیریت و رفع باگ‌ها
توسعه‌ی مقیاس‌پذیر برای حجم بالاتر کاربر
آماده‌سازی برای تغییرات آینده
این تغییر ماهیت کار، نقطه‌ای است که اغلب سازمان‌ها به فکر تغییر در شیوه‌ی مدیریت و همکاری تیم‌ها می‌افتند و به دنبال استخدام یک اسکرام‌مستر می‌روند.
زمانی که پروژه وارد فاز دوم خود می‌شود، جنس فعالیت‌ها تغییر می‌کند. در مرحله‌ی نخست، تیم فنی صرفاً مأموریت داشت فیچرهای اولیه را توسعه دهد. به‌عنوان مثال، اگر از من خواسته می‌شد که قابلیت ساده‌ای مانند «۲ به‌علاوه‌ی ۲ برابر با ۴» را پیاده‌سازی کنم، من آن را توسعه می‌دادم و تحویل می‌دادم.
اما پس از ورود محصول به بازار و استفاده‌ی کاربران، جنس نیازها تغییر می‌کند. اکنون علاوه بر توسعه‌ی فیچرهای جدید، تیم باید به موارد دیگری نیز توجه کند:
مقیاس‌پذیری (Scaling)
پشتیبانی (Support & Maintenance)
امنیت (Security & Hardening)
بهینه‌سازی (Tuning)
کنترل و اعتبارسنجی ورودی‌ها
بازطراحی و اصلاح مداوم
در این شرایط، دیگر تیم فنی تنها یک تیم توسعه‌ی نرم‌افزار نیست. حوزه‌های متعددی به آن افزوده می‌شود: توسعه‌ی فرانت‌اند، بک‌اند، موبایل، دواپس، امنیت، تست و موارد مشابه. این گستردگی باعث می‌شود که چرخه‌ی کار طولانی‌تر شود.
به بیان دیگر، اگر در گذشته یک فیچر در مدت یک هفته توسعه داده می‌شد، اکنون همان فیچر ممکن است یک ماه یا حتی دو تا سه ماه زمان ببرد. این مسئله برای تیم‌های بیزینس که انتظار سرعت بالای گذشته را دارند، چالش‌برانگیز است؛ چراکه ابعاد جدید کار برایشان ملموس نیست.
در چنین فضایی، تضاد میان تیم‌های فنی و بیزینس شکل می‌گیرد. تیم بیزینس در میانه‌ی کار، به‌واسطه‌ی نیازهای جدید یا گزارش باگ‌های بحرانی، درخواست تغییر فوری می‌دهد. در نتیجه، تمرکز تیم فنی از فیچر اصلی برداشته شده و بر رفع باگ یا انجام اصلاحات فوری قرار می‌گیرد. نبود ساختار مشخص و نبود بازه‌های زمانی تعیین‌شده (Deadline/Timebox) برای تسک‌ها، این مسئله را تشدید می‌کند.
مشکل اصلی این است که تیم‌ها به‌طور مداوم دچار سوئیچ کانتکست می‌شوند. یک روز باید روی توسعه‌ی فیچر تمرکز کنند، روز بعد روی رفع باگ بحرانی، و روز دیگر بر اساس خواسته‌ی مشتری یا مدیر بیزینس، رنگ یک دکمه تغییر داده شود. این جابه‌جایی مکرر تمرکز، علاوه بر کاهش بهره‌وری، نارضایتی عمیقی در تمام اعضای تیم ایجاد می‌کند.
در چنین شرایطی، تنش و اصطکاک به سطوح بالاتر سازمان منتقل می‌شود. تیم بیزینس گلایه می‌کند که «تکنیکال تحویل به‌موقع ندارد»، تیم فنی شکایت دارد که «بیزینس اولویت‌بندی نمی‌کند». این تضادها در نهایت مدیران ارشد را با این پرسش مواجه می‌سازد که چه باید کرد.
راه‌حلی که معمولاً انتخاب می‌شود، استخدام یک کوچ یا اسکرام‌مستر است؛ فردی که بتواند نظم و چارچوب ایجاد کند، فرهنگ همکاری و اولویت‌بندی را وارد سازمان کند، و مانع از این شود که تیم‌ها زیر فشار مشتریان و استیک‌هولدرها فرسوده شوند.
نکته‌ی کلیدی اینجاست: موفقیت یا شکست این تغییر، بیش از آنکه وابسته به ابزارهایی مانند جیرا، ترلو یا سایر سیستم‌های تسک‌منیجمنت باشد، به درک و بلوغ مدیران ارشد و میانی سازمان بستگی دارد. اگر فرهنگ لازم ایجاد نشود، ابزارها به‌تنهایی هیچ مشکلی را حل نخواهند کرد.
پدرام:
تا اینجای گفت‌وگو، اجازه بده یک مرور کوتاه داشته باشم.
بر اساس صحبت‌های تو، اولین وضعیتی که یک کوچ یا اسکرام‌مستر هنگام ورود به سازمان با آن مواجه می‌شود این است که تیم اولیه با یک هدف مشخص شروع کرده، محصولی کوچک را توسعه داده و تحویل بیزینس داده است. از این مرحله به بعد، بیزینس انتظار دارد هرگونه باگ، فیچر جدید یا حتی ایده‌ای برای آزمایش سریع، به‌سرعت توسط تیم توسعه پاسخ داده شود.
زمانی که محصول لانچ می‌شود و در دسترس مشتری قرار می‌گیرد، طبیعتاً حجم تسک‌ها و نیازها چندین برابر می‌شود. اگر تنها یک محصول وجود داشته باشد، مدیریت این حجم کار شاید ساده‌تر باشد؛ اما اگر چند محصول یا پروژه همزمان فعال باشد، پیچیدگی چند برابر می‌شود.
از سوی دیگر، حتی اگر فرض کنیم تیم توسعه متشکل از هشت نفر و به‌صورت کراس‌فانکشنال باشد، باز هم پرسش اساسی این است:
این افراد چگونه باید میان این حجم از فیچرها و باگ‌ها نظم ایجاد کنند؟
بر اساس چه اولویتی باید کارها را انجام دهند؟
چه سازوکاری باید وجود داشته باشد تا تسک‌ها در بازه‌ی زمانی مشخص و قابل اتکا پیش بروند؟
در عمل، دو لایه‌ی مهم از چالش پدید می‌آید:
سوئیچ کانتکست بین محصولات مختلف: هر بار جابه‌جایی میان پروژه‌ها تمرکز و انرژی تیم را از بین می‌برد.
سوئیچ کانتکست بین تسک‌های متعدد: حتی در یک محصول، حجم زیاد تسک‌ها باعث می‌شود هر فرد مدام میان کارهای نیمه‌تمام جابه‌جا شود.
این همان نقطه‌ای است که فرسودگی تیم آغاز می‌شود؛ چراکه اعضا احساس می‌کنند انرژی زیادی صرف می‌کنند، اما خروجی شفاف و قابل لمس چندانی ندارند.
محمد:
برای روشن‌تر شدن موضوع، اجازه بده مثالی بزنم که هر دو ما تجربه‌ی مشترک آن را داشتیم.
زمانی که من وارد مجموعه شدم، شرایط این‌گونه بود:
یک تیم ۹ نفره توسعه،
همراه با یک مدیر فنی که خودش هم به‌عنوان دولوپر کار می‌کرد،
و حدود ۲۴ یا ۲۵ پروژه‌ی فعال همزمان.
یعنی تصور کن تیم ۹ نفره باید روی بیش از ۲۰ پروژه کار کند. چنین شرایطی عملاً تمرکز را غیرممکن می‌کند.
به شوخی می‌گفتیم که حداقل یک نفر از این دولوپرها شبیه «عصبی کبوتری» است که همزمان باید سه پروژه را جلو ببرد!
تا قبل از اینکه تصمیم بگیریم اسکرام را وارد مجموعه کنیم، وضعیت دقیقاً این‌طور بود: هر لحظه سوئیچ بین پروژه‌ها اتفاق می‌افتاد. نه‌تنها کانتکست‌سوئیچ بین تسک‌ها، بلکه حتی بین پروژه‌ها و زبان‌های برنامه‌نویسی مختلف.
مثلاً من روی پروژه‌ای با پایتون/جَنگو کار می‌کردم. ناگهان مالک پروژه‌ی دیگری می‌آمد و می‌گفت در پروژه‌ای که با Node.js توسعه یافته یک باگ داریم؛ بیا اول این را رفع کن.
یعنی در یک روز، نه‌تنها میان تسک‌ها جابه‌جا می‌شدم، بلکه میان زبان‌های برنامه‌نویسی، استک‌ها و دیتابیس‌های مختلف هم پرش می‌کردم. همین پرش‌های متوالی، عملاً کل روز من را از بین می‌برد و امکان بازگشت به کار اول تقریباً وجود نداشت.
این وضعیت به‌خصوص برای نیروهای جونیور و میدلول فاجعه‌بار بود، چون نه شناخت عمیق از اپلیکیشن‌ها داشتند و نه توان کافی برای مدیریت تنوع استک‌ها و اسکیل‌ها.
پدرام:
درست است. ما ابتدا بر اساس پروژه‌هایی که باقی مانده بود، آن‌ها را بر مبنای «ارزش احتمالی برای سازمان» اولویت‌بندی کردیم. ارزش را فقط از منظر پولی ندیدیم؛ بلکه زمان، منابع انسانی و ظرفیت توسعه نیز در نظر گرفته شد. به همین دلیل برخی پروژه‌ها با پتانسیل درآمد بالاتر، تمرکز بیشتری گرفتند و پروژه‌هایی که صرفاً باگ‌های جزئی داشتند، یا به تیم‌های پشتیبانی منتقل شدند یا به‌طور کامل متوقف شدند.
سؤالم این است که: پیش از ورود من به مجموعه، و پیش از اینکه اسکرام یا تمرکز ساختاریافته‌ای وارد شود، از سمت تیم توسعه چه چالش‌های دیگری وجود داشت؟ ما از بحث کانتکست‌سوئیچینگ صحبت کردیم، اما قطعاً مسائل دیگری هم بوده است. بهتر است ابتدا سمت توسعه را بررسی کنیم و سپس به سمت بیزینس برویم.
محمد:
کاملاً درست می‌گویی. اگر بخواهم چالش‌های تیم توسعه یا دقیق‌تر بگویم تیم تکنیکال را پیش از ورود اسکرام دسته‌بندی کنم، می‌توانم به چند مورد اصلی اشاره کنم:
مسئله‌ی لِول‌آپ نشدن نیروها
وقتی یک نیروی توسعه دائماً درگیر تسک‌های سطحی یا رفع خطا (Troubleshooting) باشد و تنها بین پروژه‌های مختلف جابه‌جا شود، عمق دانش او افزایش پیدا نمی‌کند. درواقع، فرصت یادگیری عمیق، طراحی معماری یا تسلط بر تکنولوژی جدید از بین می‌رود.عدم فرصت برای ارتقای مهارت‌های تخصصی
نیروها به جای آنکه روی بهبود کیفیت کد، نوشتن تست‌های خودکار یا یادگیری ابزارهای مدرن تمرکز کنند، صرفاً مشغول خاموش‌کردن آتش‌ها و رفع نیازهای روزمره می‌شدند. این باعث می‌شد احساس رکود و حتی دلزدگی ایجاد شود.خستگی و فرسودگی ذهنی (Burnout)
همان‌طور که گفتی، کانتکست‌سوئیچینگ زیاد، خستگی شدیدی به‌همراه داشت. نیروها نه‌تنها تمرکزشان از بین می‌رفت، بلکه به‌تدریج احساس می‌کردند هیچ کاری به پایان نمی‌رسد. این «تجربه‌ی دائمی نیمه‌تمام بودن» ضربه‌ی بزرگی به انگیزه و اعتمادبه‌نفسشان وارد می‌کرد.نبود ساختار مشخص برای اولویت‌بندی کارها
وقتی هر مدیر پروژه یا هر ذی‌نفعی می‌توانست مستقیم سراغ توسعه‌دهنده برود و تسک خودش را در اولویت بگذارد، تیم عملاً حس می‌کرد در آشوب کار می‌کند. هیچ سلسله‌مراتب یا مکانیزمی برای تصمیم‌گیری وجود نداشت.احساس بی‌اثر بودن خروجی‌ها
چون بسیاری از تسک‌ها نیمه‌کاره می‌ماند یا نتایجشان در میان حجم زیاد کارها گم می‌شد، نیروها نمی‌توانستند اثر مستقیم کار خود را ببینند. این مسئله باعث کاهش حس مالکیت (Ownership) و در نتیجه کاهش تعهد و انگیزه می‌شد.
در شرایطی که شرح دادم، یکی از بزرگ‌ترین آسیب‌هایی که تیم توسعه متحمل می‌شد، از بین رفتن فضای لازم برای لول‌آپ شدن نیروها بود.
نیروهای فنی باید بتوانند زمانی را صرف پژوهش (R&D) و مطالعه‌ی فناوری‌های جدید کنند؛ فناوری‌ها را با یکدیگر مقایسه کنند؛ چرایی انتخاب یک تکنولوژی یا معماری را کشف کنند؛ و در نهایت این چرایی‌ها را وارد سازمان کنند. تنها در چنین فضایی است که می‌توان از معماری‌های بهینه‌تر استفاده کرد.
به عنوان نمونه، وقتی پروژه‌ای به نقطه‌ای می‌رسد که نیازمند تغییر معماری است—مثلاً از معماری مونولیتیک به معماری میکروسرویس—این تغییر نباید به معنای تخریب کامل و بازنویسی از صفر باشد. بلکه باید گام‌به‌گام و اینکریمنتال انجام شود، با برنامه‌ریزی دقیق و کمترین زمان ازکارافتادگی (Downtime). اگر چنین بازطراحی تدریجی انجام گیرد، ارزش واقعی خلق می‌شود: هم محصول حفظ می‌شود، هم درآمد سازمان قطع نمی‌شود، و هم کاربران تغییرات را به صورت بهبودهای محسوس در سرعت، کیفیت سرویس یا تجربه‌ی کاربری دریافت می‌کنند.
اما مشکل اصلی اینجا بود:
نیروها به‌دلیل فشار پروژه‌های متعدد، فرصت اختصاصی برای تحقیق و توسعه نداشتند.
تمرکز آن‌ها صرفاً بر رفع نیازهای روزمره و سوئیچ بین تسک‌ها بود.
در نتیجه، نه توانایی تغییر معماری و نه امکان آزمون و خطای تدریجی برایشان فراهم نمی‌شد.
این فضا باید آگاهانه توسط سازمان ایجاد شود. یعنی سرعت توسعه‌ی روزمره برای مدتی کاهش پیدا کند تا نیروها بتوانند بخشی از زمان خود را صرف یادگیری، تحقیق، و اجرای تغییرات بنیادین (مانند مهاجرت تکنولوژی یا بازطراحی معماری) کنند. این سرمایه‌گذاری کوتاه‌مدت، ضامن پایداری و رشد بلندمدت سیستم است.
پدرام:
درست است. اگر نیرو در طول یک سال احساس کند هیچ بهبودی در مهارت‌هایش رخ نداده، به مرور فرسوده می‌شود. یکی از نکات بسیار مهم که در کتاب Mastering Professional Scrum نیز به آن اشاره شده، این است که یکی از بزرگ‌ترین محرک‌های انگیزشی برای متخصصان دانش‌محور (Knowledge Workers) «استاد شدن در حرفه‌ی خود» است. یعنی فرد باید بتواند حس کند امروز بهتر از دیروز است، و نسبت به روزی که وارد سازمان شده رشد کرده است.
اگر چنین فضایی وجود نداشته باشد، انگیزه از بین می‌رود و فرد تبدیل به نیرویی می‌شود که صرفاً برای دریافت حقوق، کارهای روزمره را انجام می‌دهد. اما اگر فضای یادگیری و رشد فردی ایجاد شود، این رشد نه‌تنها به نفع فرد است، بلکه نهایتاً در راستای اهداف سازمان نیز عمل می‌کند.
محمد:
کاملاً موافقم. من همیشه در گفتگوهایم با مدیران کسب‌وکار و مدیران ارشد سازمان‌ها این نکته را پررنگ می‌کنم: اولویت اول در هر مجموعه، بیزینس است.
شما می‌توانید بهترین تیم فنی دنیا را گرد هم بیاورید:
بهترین معماران نرم‌افزار،
بهترین توسعه‌دهندگان،
بهترین متخصصان منابع انسانی، مالی و زیرساخت،
و همه را در قالب یک تیم منسجم سازمان‌دهی کنید. اما اگر خروجی این تیم به کسب‌وکار و کاربر نهایی (End-User) خدمت نکند، حال تیم هم خوب نخواهد بود. چرا؟ چون درآمدی ایجاد نمی‌شود و تیم نمی‌تواند نتایج تلاش خود را ببیند.
بیزینس در یک بازه زمانی مشخص می‌تواند از منابع بیرونی سرمایه تزریق کند و هزینه‌های تیم را پوشش دهد. اما اگر پس از مدتی محصول خروجی به بازار نرسد یا مورد استفاده کاربر قرار نگیرد، تیم با این پرسش مواجه می‌شود: پس چرا ما این همه تلاش کردیم؟
از همین روست که معتقدم حال خوب تیم به شدت به فیدبک بیزینس و کاربران وابسته است. حتی اگر فیدبک‌ها منفی باشد، باز هم ارزش دارد، چون یعنی محصول استفاده شده و به اندازه‌ای اهمیت داشته که کاربر وقت گذاشته و بازخورد داده است. این استفاده، حتی با انتقاد، به تیم انگیزه و شور (Passion) می‌دهد تا ادامه بدهد.
من به عنوان یک مدیر فنی همیشه با این دید تصمیم‌گیری می‌کنم:
بیزینس اولویت اصلی است.
ابزارها، تکنیک‌ها، متدولوژی‌ها و استک‌های فنی، همه صرفاً وسایلی هستند برای رسیدن به اهداف بیزینس.
بنابراین تصمیم‌هایی که می‌گیرم لزوماً Best Practice به معنای کتابی و ایدئال آن نیستند. چرا؟ چون بیزینس محدودیت‌های خودش را دارد: محدودیت زمان، محدودیت دانش تیم، محدودیت منابع.
به همین دلیل، اگر بیزینس از من یک MVP (Minimum Viable Product) بخواهد، من می‌گویم:
با اولین ابزاری که در دسترس داری شروع کن.
با اولین استک برنامه‌نویسی که تیم بلد است کار کن.
متدولوژی را پیچیده نکن.
تمام آن توصیه‌های مربوط به بهترین معماری‌ها (مانند Microservices) یا بهترین روش‌های توسعه (مانند TDD) را کنار بگذار. اول محصول را بساز، به دست کاربر برسان و فیدبک بگیر.
البته من همیشه با تیم بیزینس این توافق را می‌کنم:
محصولی که امروز تحویل می‌دهم، بر اساس محدودیت‌هایی است که شما برای من تعریف کرده‌اید. بنابراین الزاما بهترین و کامل‌ترین نسخه نیست. این محدودیت‌ها در آینده اثر خود را نشان خواهند داد. اگر کاربرانتان افزایش پیدا کند، یا نیازهای جدیدی شکل بگیرد، باید آماده باشید که دوباره به ساختار، معماری و تصمیمات فنی بازگردیم و اصلاحات اساسی انجام دهیم.
یکی از توافق‌هایی که من همواره با تیم‌های بیزینس انجام می‌دهم این است که در همان ابتدای کار مشخص کنیم محصولی که در بازه‌ی سه‌ماهه یا شش‌ماهه به‌عنوان MVP تحویل داده می‌شود، چه محدودیت‌هایی دارد. به آن‌ها توضیح می‌دهم که اگر تعداد کاربران از ۱۰۰ نفر به ۵۰۰ یا ۱۰۰۰ نفر افزایش پیدا کند، یا اگر نیاز به High Availability (HA)، حذف downtime و مقیاس‌پذیری جدی وجود داشته باشد، ساختار فعلی پاسخگو نخواهد بود. بنابراین پس از تحویل نسخه‌ی اولیه، باید یک بازه‌ی زمانی مشخص برای بازطراحی و بازنویسی سیستم در نظر گرفته شود.
این توافق باعث می‌شود دو طرف رضایت بیشتری داشته باشند:
بیزینس خوشحال است چون محصول در کوتاه‌ترین زمان ممکن و با کیفیت قابل قبول به بازار عرضه می‌شود.
تیم تکنیکال هم خوشحال است چون می‌داند بعد از عرضه، یک بازه‌ی زمانی مشخص برای بهبود زیرساخت‌ها و بازطراحی در اختیار خواهد داشت.
به‌طور معمول، در ۸۰ تا ۸۵ درصد شرکت‌هایی که با آن‌ها همکاری کرده‌ام، این روش نتیجه داده است. چرا؟ چون در بازه‌ی یک یا دو اسپرینت بعدی، بخشی از ظرفیت تیم به درخواست‌های فوری بیزینس اختصاص داده می‌شود، اما بخش عمده صرف بازطراحی و بهبود معماری پروژه خواهد شد.
نکته‌ی دیگری که بسیاری از سازمان‌ها، به‌ویژه استارت‌آپ‌ها، از آن غافل می‌شوند جانشین‌پروری است. در بسیاری از تیم‌ها، یک یا دو نفر حجم عمده‌ای از کارها را انجام می‌دهند. این افراد ممکن است به دلایل مختلف (مالی، فرهنگی، شخصی یا مهاجرت) از سازمان خارج شوند. خروج چنین نیروهایی می‌تواند سرعت توسعه و پشتیبانی را تا ۸۰ درصد کاهش دهد.
راه‌حل مقطعی که معمولاً استفاده می‌شود، افزایش حقوق است. اما این تنها یک مسکن کوتاه‌مدت است؛ چون بعد از مدتی باز هم پاسخگوی نیازهای فرد نیست و او به فکر جابه‌جایی خواهد افتاد.
اینجاست که اسکرام کمک می‌کند.
با شکستن سیلوها و کار تیمی، دانش افراد کلیدی بین اعضای دیگر توزیع می‌شود.
افراد در جلسات برنامه‌ریزی (Planning) باهم درباره‌ی وظایف، تخمین‌ها و اولویت‌ها صحبت می‌کنند.
حتی نیروهای تازه‌کار و کارآموز هم کم‌کم گوششان با پروژه آشنا می‌شود و می‌دانند جنس کار چیست.
در نتیجه، اگر نیروی ارشد و کلیدی به هر دلیلی از تیم خارج شود، پروژه هرچند با سرعت کمتر، ولی متوقف نخواهد شد. این موضوع یکی از بزرگ‌ترین مزایای فرهنگی و ساختاری اسکرام است که به جانشین‌پروری و کاهش ریسک وابستگی سازمان به افراد کلیدی کمک می‌کند.
سمت بیزینس هم ماجرا کمی متفاوت است. قبل از اینکه اسکرام وارد سازمان شود، معمولاً چند اتفاق تکراری می‌افتد:
انباشتگی انتظارات بدون اولویت‌بندی شفاف
تیم بیزینس با حجم بالایی از نیازها و درخواست‌ها مواجه است؛ بخشی از آن‌ها ناشی از فشار مستقیم مشتریان، بخشی از ایده‌های درونی سازمان، و بخشی هم از تغییرات بازار. بدون اسکرام، این نیازها عموماً به‌صورت یک لیست بلندبالا روی میز تیم فنی ریخته می‌شود. هیچ‌کس هم پاسخ مشخصی ندارد که کدام یک اولویت بالاتری دارد یا باید ابتدا به چه چیزی برسیم.عدم پایبندی به تصمیمات و تغییر مداوم جهت‌ها
بیزینس امروز می‌گوید «این فیچر فوریت دارد»، فردا همان فیچر کنار گذاشته می‌شود و مورد دیگری جای آن را می‌گیرد. این تغییر جهت‌های سریع، تیم را خسته و بی‌انگیزه می‌کند. برای بیزینس هم نتیجه‌ای در پی ندارد؛ چراکه عملاً هیچ‌کدام از موارد به پایان نمی‌رسد و خروجی ملموسی به مشتری تحویل داده نمی‌شود.ناامیدی از تیم فنی
چون بیزینس خروجی قابل لمس نمی‌بیند، این تصور شکل می‌گیرد که تیم فنی کند یا ناکارآمد است. درحالی‌که مشکل اصلی در پراکندگی و عدم تمرکز است. همین مسئله باعث اصطکاک بین واحدها می‌شود: بیزینس تیم فنی را مقصر می‌داند، تیم فنی هم معتقد است بیزینس مدام اولویت‌ها را تغییر می‌دهد.ابهام در سنجش موفقیت
وقتی اولویت‌ها مبهم است و تایم‌باکس مشخصی وجود ندارد، هیچ‌کس نمی‌داند موفقیت چه شکلی است. آیا موفقیت یعنی این فیچر بالا بیاید؟ یا اینکه ۵۰ باگ حل شود؟ یا اینکه محصول در بازار عدد خاصی را به دست آورد؟ این ابهام، تیم بیزینس را هم فرسوده می‌کند.
اینجاست که اسکرام وارد می‌شود و به دو شکل کمک می‌کند:
اول، با تایم‌باکس کردن (اسپرینت‌ها) به بیزینس می‌گوید: «در این بازه، فقط روی این مجموعه کار می‌کنیم.» این یعنی پایان دادن به تغییرات لحظه‌ای.
دوم، با اولویت‌بندی بکلاگ توسط پروداکت اونر، بیزینس دقیقاً می‌داند چه چیزی در دست توسعه است و چه چیزی به آینده موکول شده.
به این ترتیب، سطح شفافیت بالاتر می‌رود. بیزینس یاد می‌گیرد که هر خواسته‌ای، هرچند مهم، باید در نوبت قرار بگیرد و در بازه‌ی بعدی مورد بررسی قرار گیرد.
از سمت بیزینس، قبل از اینکه اسکرام‌مستر وارد شود، وضعیت معمولاً به این شکل است:
انتظارات مبهم و متناقض
مدیران بیزینسی همزمان چند خواسته دارند: «فیچر جدید بدهید»، «باگ‌ها را رفع کنید»، «سیستم را پایدار نگه دارید»، «ظاهر را عوض کنید». چون هیچ سیستم اولویت‌بندی شفافی وجود ندارد، هر روز یک چیز «فوری» می‌شود و فردای همان روز، چیزی دیگر.عدم رضایت از خروجی قابل لمس
وقتی تیم درگیر کانتکست‌سوئیچینگ است، خروجی نهایی کمیاب می‌شود. کارها زخمی می‌مانند. بیزینس از بیرون فقط می‌بیند که زمان می‌گذرد اما محصول جدید یا بهبود مشخصی به دستش نمی‌رسد. این باعث می‌شود حس کند تیم فنی ناکارآمد است.فشار مضاعف به خاطر مشتری و بازار
بیزینس مستقیم با مشتری یا ذی‌نفع روبه‌روست. وقتی مشتری می‌گوید «چرا این باگ هنوز رفع نشده؟» یا «رقیب این فیچر را دارد، ما نداریم»، فشار به تیم فنی منتقل می‌شود. بیزینس هم برای حفظ اعتبارش مدام وعده می‌دهد، ولی تیم نمی‌تواند همزمان به همه خواسته‌ها پاسخ بدهد.فضای پر از گلایه و بی‌اعتمادی
به مرور، بیزینس فکر می‌کند تیم فنی کار را جدی نمی‌گیرد یا سرعت کافی ندارد. تیم فنی هم بیزینس را عامل بی‌نظمی می‌داند. نتیجه‌اش جلسات پر از تنش است، شبیه همان چیزی که گفتی: «خونریزی» در رترو یا حتی خارج از رترو.
اینجا نکته جالب این است که برای بیزینس، نارضایتی خیلی شبیه یک فنجان ذهنی بزرگ است. یعنی وقتی صدها درخواست بی‌جواب می‌ماند، ذهن‌شان پر از «چرا این کار انجام نشده» می‌شود. این فنجان‌ها مثل همان چیزی است که در مورد افراد فنی گفتی: مانع تمرکز می‌شود و در نهایت به استرس، بدبینی، و فرسودگی منجر می‌شود.
وقتی اسکرام وارد می‌شود، فقط ایجاد فضای گفت‌وگو و شفاف‌سازی همین فنجان‌ها را می‌شکند:
بکلاگ به زبان مشترک تبدیل می‌شود.
تایم‌باکس به بیزینس یاد می‌دهد که «همه‌چیز فوریت ندارد».
رترو به افراد این حس را می‌دهد که حتی اگر مشکل حل نشود، حداقل شنیده شده‌اند.
می‌خواهی در ادامه، همین خط «نارضایتی بیزینس» را با یک نمونه واقعی از تجربه‌ات باز کنم؟ مثلا جایی که بیزینس به خاطر نبود خروجی، فشار شدیدی آورد و بعد از دو سه اسپرینت اول، فضا تغییر کرد.
تمرکز نیروها بر روی یک پروژه یا یک تسک باعث می‌شود که آن تسک در بهترین زمان و با بالاترین کیفیت ممکن انجام شود. این موضوع نه‌تنها به بهبود نتایج فنی کمک می‌کند، بلکه رضایت بیزینس را نیز به همراه دارد؛ زیرا احتمال رخداد خطا و باگ در فیچرهای توسعه‌یافته به مراتب کاهش می‌یابد. در نتیجه، اعتماد اند‌یوزر و مشتریان به محصول نیز تقویت می‌شود.
یکی از مهم‌ترین دغدغه‌های مدیران ارشد و تصمیم‌گیران سازمانی، رخداد مکرر خطاهای مشابه در نسخه‌های مختلف است. زمانی که یک باگ بارها در بازه‌های زمانی متفاوت تکرار می‌شود، نگاه بیزینس و کاربران نسبت به کیفیت محصول تضعیف می‌گردد و این مسئله می‌تواند آسیب جدی به اعتبار پروژه وارد کند.
از سوی دیگر، با بزرگ‌تر شدن پروژه‌ها و افزایش تعداد کاربران، چالش‌های فنی نیز پیچیده‌تر می‌شوند. در چنین شرایطی، تیم‌های تکنیکال نیز باید همزمان رشد کنند؛ چه از نظر تخصص، چه از نظر ابزارها و متدولوژی‌ها، و چه از نظر تعداد نفرات. پروژه‌ای که در ابتدا با دو یا سه توسعه‌دهنده قابل مدیریت بوده است، در مراحل بعدی نیازمند تیم بزرگ‌تر و فرآیندهای کامل‌تری همچون تست، کد ریویو و معماری مناسب خواهد بود. طبیعی است که این رشد هزینه‌های مالی بیشتری را به سازمان تحمیل می‌کند.
اسکرام با فازبندی پروژه و تقسیم آن به فیچرهای کوچک‌تر کمک می‌کند این هزینه‌ها به‌تدریج و قابل مدیریت‌تر وارد چرخه شوند. همزمان، بستر لازم برای رشد نیروهای مید-لول و ارتقای آن‌ها به سطوح بالاتر فراهم می‌شود و مفهوم جانشین‌پروری نیز تقویت می‌گردد. به این ترتیب، تیم تکنیکال همگام با توسعه و رشد محصول، توانمندتر می‌شود.
یکی دیگر از شاهکارهای اسکرام، الزام تیم به ارائه خروجی‌های قابل لمس در پایان هر اسپرینت است. این خروجی‌ها، هرچند کوچک، برای تیم بیزینس و کاربران نشانه‌ای روشن از پویایی و پیشرفت پروژه محسوب می‌شوند. در دنیای امروز که وفاداری کاربران به محصولات به‌شدت کاهش یافته و تغییر سرویس‌دهنده برایشان ساده است، مشاهده تغییرات و بهبودهای مستمر در محصول اهمیت بسیار بالایی دارد.
کاربری که هر دو هفته یا هر ماه با باز کردن اپلیکیشن تغییرات جدیدی را می‌بیند، اطمینان پیدا می‌کند که پشت محصول تیمی فعال، پویا و متعهد قرار دارد. این تجربه‌ی مثبت نه‌تنها رضایت کاربران را افزایش می‌دهد بلکه از طریق تبلیغات دهان‌به‌دهان، قدرت رقابتی محصول را نیز تقویت می‌کند.
به بیان ساده، هدف اسپرینت در اسکرام این است که تیم در هر چرخه حداقل یک خروجی قابل انتشار ارائه دهد. حتی اگر همه‌ی اهداف اسپرینت محقق نشوند، وجود همین خروجی قابل لمس و قابل نصب برای بیزینس و کاربر ارزشمند است و نشان‌دهنده‌ی حرکت مستمر پروژه در مسیر پیشرفت خواهد بود.
یکی از حیاتی‌ترین موضوعات در اسکرام، تحویل خروجی قابل لمس در پایان هر اسپرینت است. درست است که پایبندی به هدف اسپرینت بخشی از تعهد تیم محسوب می‌شود و باید در مورد آن گفت‌وگو شود، اما خروجی قابل انتشار از هر چیز دیگری مهم‌تر است. این خروجی همان چیزی است که اعتماد بیزینس را می‌سازد. تیم‌های بیزینس معمولاً به تیم‌های تکنیکال بی‌اعتمادند؛ نه فقط به خاطر کیفیت، بلکه به دلیل ناتوانی در پایبندی به زمان‌بندی و ارائه نسخه‌های قابل اتکا.
وقتی محصولی که قبلاً توسعه یافته مورد بازبینی قرار می‌گیرد، تفاوت فاحشی میان کیفیت کدی که انتظار می‌رفته و کیفیت واقعی دیده می‌شود. اما اسپرینت‌های کوتاه‌مدت، همراه با جلسات بازبینی، کد ریویو و فرصت‌های یادگیری مستمر، کیفیت کار را به‌مرور ارتقا می‌دهد. در این رویکرد، دیگر خبری از پروژه‌هایی نیست که پس از مدتی باید «به کل دور ریخته شوند» و از صفر بازنویسی شوند.
اسکرام با انتخاب‌های کوچک در بازه‌های زمانی محدود، ریسک شکست‌های بزرگ را کاهش می‌دهد. این انتخاب‌ها می‌توانند هم از جنس تصمیمات تکنیکال باشند و هم از جنس تصمیمات بیزینسی. حتی در فرآیند جذب نیرو نیز این الگو دیده می‌شود. به‌جای صرف ماه‌ها زمان برای استخدام فردی که پس از مدت کوتاهی مجموعه را ترک کند، تیم در طول اسپرینت‌های مختلف فرصت دارد عملکرد عضو جدید را ارزیابی کند. اعضای تیم در عمل می‌بینند آیا فرد تازه‌وارد توانسته به بهبود عملکرد تیم کمک کند یا خیر.
این سازوکار، شفافیت و معیارهای عینی در اختیار سازمان قرار می‌دهد. اگر فردی پس از فرصت‌های متعدد و بازخوردهای مستقیم، نتواند کیفیت مورد انتظار را ارائه دهد، تیم می‌تواند با شفافیت کامل نظر خود را اعلام کند و سازمان نیز با اطمینان تصمیم به قطع همکاری بگیرد. این فرآیند، به‌جای انباشته شدن نارضایتی‌ها و ایجاد بار منفی در تیم، مسیر سالمی برای تصمیم‌گیری فراهم می‌کند.
ایده‌ی بنیادین اسکرام این است که تیم‌ها خودمدیریت باشند. تیم اسکرام باید مسئولیت کامل تحقق اهدافش را بر عهده بگیرد. به همین دلیل، نقش مدیر فنی یا سایر مدیران بالادستی، به‌جای کنترل مستقیم، به نقشی حمایتی تبدیل می‌شود: اینکه چگونه می‌توانند به تیم کمک کنند بهترین عملکرد را داشته باشد، موانع را برطرف کنند، و تضمین کنند که اعضای تیم با افراد مناسبی همکار می‌شوند.
در این چارچوب، تیم به بلوغ بیشتری می‌رسد، مسئولیت‌پذیری افزایش می‌یابد، و اعتماد بین لایه‌های مختلف سازمان تقویت می‌شود.
واقعاً نکته‌ی مهمی است که اسکرام مستر یا مدیر فنی (در صورت وجود) بتواند نقش «رفع‌کننده‌ی موانع» را ایفا کند و مسیر رسیدن تیم به اهدافش را هموار سازد. یکی از آخرین فرصت‌هایی که باید به تیم داده شود، دریافت بازخورد درباره‌ی حال و کیفیت همکاری اعضاست. طبیعی است که این فضا نباید صرفاً بهانه‌ای برای کنار گذاشتن افراد باشد؛ بلکه باید تلاش واقعی برای همکاری و تعامل صورت گرفته باشد. در چنین شرایطی، اسکرام مستر و مدیران می‌توانند بلوغ تیم را بسنجند و آرام‌آرام زمینه را برای چنین تصمیم‌هایی آماده کنند.
این تصمیم نباید شتاب‌زده باشد. کیفیت خروجی افراد در جلسات پلنینگ، عملکردشان در آموزش‌ها و بازخوردهایی که دریافت کرده‌اند، همگی باید به دقت بررسی شود. در نهایت اگر پس از چندین فرصت و پشتیبانی باز هم نتیجه‌ی مطلوب حاصل نشود، موضوع تعدیل نیرو مطرح می‌شود. این روند می‌تواند کوتاه‌مدت (یک ماهه)، میان‌مدت (سه ماهه) یا حتی بلندمدت‌تر باشد، بسته به شرایط و میزان تأثیر فرد در تیم.
چنین فرآیندی، هم به سازمان کمک می‌کند که کیفیت را حفظ کند و هم به تیم فرصت می‌دهد در فضای واقعی، بلوغ خود را نشان دهد. از سوی دیگر، ایجاد ارتباط سازنده میان اسکرام مستر و واحد منابع انسانی (HR) برای هماهنگ کردن تصمیمات بسیار کلیدی است.
مرور این تجربه‌ها برای من بسیار ارزشمند بود و امیدوارم برای شنوندگان، به‌ویژه اسکرام مسترها و افراد تازه‌وارد به این مسیر، الهام‌بخش باشد. این گفت‌وگو نشان داد که سازمان‌ها از دو سمت ــ تیم‌های توسعه و تیم‌های بیزینس ــ با چه چالش‌هایی روبه‌رو می‌شوند و چرا گاهی نیازمند ورود یک اسکرام مستر هستند. طبیعی است که تجربه‌های هر سازمان متفاوت است و شنیدن آن‌ها می‌تواند تصویری کامل‌تر از انواع موانع و راهکارها به ما بدهد.
بسیاری از سازمان‌ها امروز به بلوغ بیشتری رسیده‌اند و حتی پیش از بروز مشکلات، متدولوژی‌های چابک را پیاده‌سازی می‌کنند تا از چالش‌هایی که ذکر شد پیشگیری کنند. خوشحال می‌شوم مخاطبان این اپیزود تجربه‌ها و بازخوردهای خود را در شبکه‌های اجتماعی یا بخش نظرات اپیزود به اشتراک بگذارند تا از مجموعه‌ای از تجربه‌های واقعی بهره‌مند شویم و راهکارهای عملی بیشتری کشف کنیم.
اجایل گپ را می‌توانید از طریق شبکه‌های اجتماعی لینکدین، اینستاگرام و تلگرام دنبال کنید.
