– من : “چرا میخاهید از متد اسکرام استفاده کنید؟”
– مدیر سازمان : “میخاهیم چابک بشویم”
– من :” چرا میخواهید چابک بشوید؟ چه مشکل خاصی دارید؟”
– مدیر سازمان :” ما مشکل خاصی نداریم فقط میخواهیم اگر بشود با استفاده از این متدلوژی بهتر کار کنیم”
خیلی وقت ها شده است که چنین مکالماتی در سازمان ها داشته ام، که واقعا بعضی وقت ها دردناک است. بعد از این همه مدت می خواهم در مورد سازمان های ایرانی و نحوه چابک سازی ها آن ها بنویسم و امیدوارم که مفید باشد.
در سازمان درک مناسبی از چابک بودن پیدا کنیم
چند روز پیش دوره اسکرامی داشتم که خیلی برایم جالب بود، در این دوره از یک سازمان پست های مختلفی وجود داشتند، در آغاز دوره متوجه شدم اعضای این سازمان به دو قسمت تقسیم شده اند: 1- آنهایی که میخواهند ثابت کنند اسکرام بدرد نمی خورد 2- آنهایی که همانند عاشقان آیفون که از شب جلوی اپل صف می کشند میخاستند ثابت کنند فقط اسکرام راه نجات سازمان است.
گروه اول که اغلب پست های مدیریتی داشتند، از اسکرام این برداشت را داشتند که اسکرام روشی برای از زیر کار در رفتن هست و برنامه نویس ها و تیم های توسعه (گروه دوم) میخواهند با این روش از زیر کار و از سنجش های سازمانی در بروند. این گروه درک مناسبی از اسکرام یا چابک بودن نداشتند.
گروه دوم هم که غالبا توسعه دهندگان بودن و راه سعادت را در اسکرام شدن می دیدند، فکر میکردند اسکرام یعنی اینکه هر طور دوست داری کار کن، مستند سازی تعطیل، هر شکستی آزاد، مهندسی نرم افزار نیاز نیست و … . این گروه هم درک مناسبی از این چابک بودن نداشتند.
پس از درک این مشکل در دوره سعی کردم که توهم و دیدگاه موجود در هر دو گروه را حل کنم، و شناخت مناسبی در هر دو گروه ایجاد کنم.
افراد قبل از معرفی چابک و یا روشی مثل اسکرام در سازمانريال چیزهایی در مورد آن شنیده اند یا در جایی خوانده اند، امکان دارد آنها درک های متفاوتی از آن داشته باشند، پس ما در هر سازمان ابتدا باید درک واحد و درستی در سازمان بوجود آوریم که این میتواند طی برنامه های آموزشی، یا استفاده از رادیاتورهای اطلاعاتی مناسب یا هر روش دیگری استفاده کرد.
برخی از درک های نادرست :
در مستند سازی Agile مانند همه دیگر عمل های چابک, شما به اعتدال در اعمال دعوت شده اید . شعار تیم های توسعه در تهیه مستندات پروژه : ” فقط به اندازه کافی و صحیح مستند سازی خواهیم کرد“.
- اسکرام = مهندسی نرم افزار تعطیل
یه بنده خدایی در یک جایی به من گفت “اسد جان دستت درد نکنه، چند سال بود این مفاهیم مهندسی نرم افزار رو می خوندم و درک نمی کردم ولی از وقتی با اسکرام آشنا شدم خیلی راحت شدم”. اسکرام یک روش مهندسی نرم افزار نیست بلکه ظرفی برای استفاده از روش های مختلف مهندسی نرم افزار است.
- چابک بودن = همه در یک سطح هستند
این سوال همیشه مطرح می شود که در محیط های چابک همه در یک سطح قرار می گیرند و به همه باید به یک اندازه حقوق و پاداش داد. این درک درست نیست، تفاوت همیشه وجود دارد، نیروها تخصص ها و تجربیات مختلف و بالا پایینی دارند، و نمی شود به یک اندازه به همه حقوق داد، یا نحوه انگیزش افراد بسیار میتواند مفید باشد و همه را نمی توان با یک صورت با انگیزه کرد.
- چابک بودن = مدیران را اخراج کنید
چابک بودن یعنی اینکه تا آنجایی که می توانید تصمیم ها توسط یک مدیر گرفته نشود و قدرت تصمیم گیری به نفرات پایین تر و تیم ها اعطا شود. قدرت تصمیم گیری در نفرات و تیم ها مساوی است با تعهد و مسئولیت. مدیران قدرت تصمیم گیری را به نفرات پایین تر اعطا می کنند و آنها را متعهد می کنند تا برای تصمیمات گرفته شده خود مسئولیت را بپذیرند. این یعنی این که در محیط های چابک باز مدیران هستند ولی به نحو دیگر و خدمت گذارانه فعالیت می کنند.
حقیقتا چابک بودن نیاز به سطح فنی بالا در تیم ها دارد، تیم ها باید بتوانند پرکتیس های لازم مانند Design pattern ها، اصولی مانند SOLID یا دیگر موارد را در عمل استفاده کنند. تیم هایی که اندر خم این کوچه ها باشند واقعا نمی توانند در انتهای هر اسپرینت یا چرخش محصول کار کننده ارایه کنند که خود این ارزش چابک بودن تیم ها را از بین خواهد برد. پس حتی اگر بخواهیم با تیم سطح پایین فنی هم چابک بشویم باید برای بالا بردن آن برنامه داشته باشیم و نه فقط برنامه چابک سازی.
- یادگیری اسکرام راحت است پس پیاده سازی آن هزینه ندارد
برای چابک شدن باید فرهنگ را تغییر بدهید، بلی باید فرهنگ را تغییر دهید. تغییر فرهنگ هزینه دارد و هزینه آن هم معمولا سنگین است، شاید لازم باشد کل سلسله مراتب سازمان تغییر کند، نحوه مدیریت تغییر کند، نحوه ارتباط با مشتری عوض شود، نحوه تولید و توسعه و نگه داری تغییر کند، نحوه ارتباطات متحول شود و همه اینها هزینه هستند.
مسلما ما در دنیای چابک متخصص معماری داریم اما نه خارج از تیم، بلکه بعنوان اعضای تیم. بهترین حالت که اخیرا من تجربه داشتم این است که همه ی تیم در طراحی معماری نقش داشته باشند در کنار این یکی از اعضای تیم مسئولیت آن را بر عهده داشته باشد بدین صورت که اختیارات تصمیم گیری او بیشتر از بقیه در حوزه معماری باشد. نه اینکه اگر معماری از هم پاشید فقط او مسئول است بلکه او بیشتر از بقیه حواسش هست که پروژه در قالب همان معماری پیش برود و معماری همیشه طبق متدلوژی گسترش پیدا کند و رفاکتور شود.
پس از چند سالی که از عمر دنیای چابک می گذرد، سعی کرده ایم که در این وبلاگ به مباحثی بپردازیم که نقاط روشن و واضحی در اختیار خوانندگان و تعقیب کنندگان دنیای چابک قرار داده شود. اما در این اواخر بیشتر رویکرد اسکرامی گرفتیم و به قول یکی از دوستان “فکر کردم اسکرام نام دیگر اجایل است”.
خیلی اتفاق افتاده است که مدیران فکر میکنند، یا حتی نگران این می شوند که چطور افراد از روز اول خود سازمانده می شوند، یا بعبارتی چطور آدم ها را رها کنیم به حال خودشان. تیم نیاز به اختیارات دارد و مدیر یا رهبر باید اختیاراتی مانند اختیار در تصمیم گیری به آنها اعطا نماید. اما خود این مسئله می تواند بسیار چالش بر انگیز باشد.
مدیر شرکتی با خواندن یک مقاله یا کتاب در مورد Agile به این فکر می افتد که :”این همونه – این خودشه – همینه یا …” و سریعا اقدام به چابک سازی شرکت با معلومات یک مقاله ای یا کتابی می کند.مشکل از آنجایی حادث می شود که در مقالات یا کتاب های Agile (مانند منابع بنده) , Agile به گونه ای تشریح می شود(یا شده است) که اصطلاحا آب از دهن خواننده سرازیر می کند یا به عبارت رسمی تر خواننده را به سمتی هدایت می کند تا سریعا چابک شود.
در این پست در مورد دیدگاههای اشتباه در مورد چابک بودن صحبت کردیم، در ادامه به سوال چگونه سازمان را به چابک بودن متحول کنیم جواب خواهیم داد.
چابک و موفق باشید
مطلب خوبی بود. متشکرم و خسته نباشید