کجا استفاده از اسکرام اوضاع را بدتر می‌کند؟ راه حل چیست؟

یک مثل معروفی وجود دارد و آن این است که اگر شما تنها یک چکش داشته باشید تمام مسائل برای شما شکل میخ خواهند شد.

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

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

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

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

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

چگونه بدون یک افق مشخص و زمان بندی دقیق و صرفا بر مبنای حرف های چند جلسه میتوانیم برای توسعه یک محصول برنامه ریزی کنیم؟ مگر چند میلیارد بودجه شوخی است که به یک تیم بگوییم حالا شما بیایید و تلاشتان را بکنید و بدون محدودیت و تخمین زمانی مشخص و دقیق و بدون بودجه بندی درست این نرم افزار را بسازید؟

استفاده از خوبی‌های اسکرام و اجایل و رها کردن بدی‌های آن

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

 مثلا جلسه برنامه ریزی یا همان Planning که در آن افراد در مورد کارهایی که در دو هفته آتی می‌خواهند انجام دهند صحبت می‌کنند، با کمی تغییر فوق‌العاده می‌شوند. شما در ابتدای پروژه زمان‌بندی کامل کار را انجام می‌دهید و سپس این زمان‌بندی را در بازه های 2 هفته‌ای می‌شکنید و در هر دو هفته با تیم یک جلسه می‌گذارید و کار هایی که قرار است انجام دهند را به آن‌ها اعلام می‌کنید و از آن‌ها می‌خواهید که درباره آن صحبت کنند، بعد از آن به طور روزانه در جلسه daily شرکت میکنید و از تیم می‌خواهید که کارهایی را که انجام داده‌اند و میخواهند انجام دهند را بیان کنند و اینگونه در طول دو هفته هم خیال‌تان راحت است که همه دارند روی یک موضوع کار میکنند و هم می‌توانید موانع و مشکلات سر راه تیم را شناسایی کنید و مثلا ببینید چه افرادی مدام درجا میزنند و پیشرفت ملموس روزانه ندارند، یا چه کسانی مدام غر میزنند که کارها قابل انجام شدن نیستند و یا کجا کار کند شده که اگر شده بود با استخدام و اضافه کردن سریع نفرات جدید، سرعت تیم را افزایش دهید.

در انتهای بازه دو هفته‌ای یا همان اسپرینت هم یک جلسه بررسی یا همان review داریم که کل کارهای دو هفته را در آن بررسی می‌کنیم که آیا به آن‌چه برنامه ریزی کردیم رسیده‌ایم یا نه؟  و اگر نرسیدیم مشکلات را در جلسه بعدی یعنی retro بررسی می‌کنیم . در جلسه رترو حالا فضایی مهیّا می‌شود که شما می‌توانید حرفتان را به تیم بزنید و در میان گفتگوها و به شکل خیلی نرم به افراد بگویید که چرا شکست خوردند، چه رفتاری در تیم آن‌ها مسموم است و چه کسانی مسئول این شکست هستند؛ سپس آن‌ها را مجاب کیند که باید تنبلی یا رفتار سمی خود را کنار بگذارند و یا اینکه از تیم کنار گذاشته خواهند شد. 

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

اگر از عکس کشتی به بعد همه متن را خواندید و تصمیم گرفتید که سراغ اسکرام بروید و به نظرتان همه چیز منطقی و خوب است باید کمی بیشتر صحبت کنیم چرا که:

برایتان یک خبر بد دارم

شما یکی از ده‌ها استارت‌آپی خواهید بود که من و دوستانم شاهد نابود شدن و فروریختن آن‌ها بوده ایم اما چرا؟

دقیقا مشکل کجاست؟

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

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

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

تصویر بزرگتر را ببینیم

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

شما دو راه پیش روی خود دارید: 

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

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

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

ارزش‌های اجایل را بازخوانی نکنید، درک کنید. 

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

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

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

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

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

آن چیزی را توسعه دهید که بازار میخواهد

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

اگر سایت شما مشتری داشته باشد و هک شود یا کند باشد بهتر از آن است که مشتری نداشته باشد ولی محصول بی نقص باشد.

برای درک بهتر این موضوع دو واژه وجود دارند که باید تفاوت آن ها را بدانیم: 

• Customer Needs
• Customer Requirements

نیاز مشتری یا همان customer needs آن پلی است که مشتری را به شما وصل می‌کند مثلا مشتری احتیاج به یک گوشی هوشمند دارد و یا دنبال یک همبرگر میگردد، اما احتیاج مشتری یا همان customer requirement به آن چیزی میگویند که مشتری را نسبت به محصول و خدمات راضی یا ناراضی میکند. مثلا ممکن است شخصی از چرب برودن بیش از حد همبرگر ناراضی شود و یا از اینکه در منو همبرگر گیاهی دارید او را راضی و خوشحال کند.

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

از معماری های ساده ولی ماژولار استفاده کنید

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

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

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

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

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

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

سخن پایانی

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