شرکت‌ها برای ایجاد هماهنگی بین عرضه و تقاضا و به اصطلاح سازگار شدن، از متدولوژی مدیریت چابک استفاده می‌کنند. اما عجله بسیاری از آنها در اجرای این متدولوژی، باعث شده است که چابکی آنها کم‌تر شود. این شرکت‌ها تنها از نظر اسمی چابک شده‌اند؛ و در واقع نحوه پیاده‌سازی متدولوژی در این شرکت‌ها، منجر به آسیب دیدن انگیزه و کاهش بهره‌وری شرکت شده است.
توسعه نرم‌افزار چابک
رویکردهای مختلف توسعه نرم افزار سازگار مانند متدولوژی چابک، مدت‌هاست که وجود داشته و به اشکال مختلف نمایان می‌شوند. اما جوهره اصلی بیشتر این مدل‌ها دو چیز است: 1- شکل‌گیری فرضیه‌ها (به عنوان مثال، ویژگی‌هایی که قرار است به انجام برسد) و 2- همکاری در حوزه‌های تخصصی تجربیات.
هنگامی که متدولوژی چابک در سال 2001 متولد شد، چهار اصل مهم را برای ارتقا صنعت توسعه نرم افزار و بهبود انگیزه مهندسی و مدیریت محصول تبیین کرد.
- افراد و تعاملات بین آنها بر فرایندها و ابزارها ارجحیت دارد.
- نرم افزار کارا بر مستندسازی جامع ارجحیت دارد.
- مشارکت کارفرما در انجام کار بر قرارداد کاری ارجحیت دارد.
- پاسخگویی و واکنش به تغییرات بر پیروی از یک برنامه ثابت ارجحیت دارد.
لازم است تاکید شود که متدولوژی چابک مخالف فرایندها و ابزارها، مستندسازی، قراردادها و یا برنامه‌ریزی نیست؛ بلکه تنها به چهار اصل گفته شده، اعتبار بیشتری می‌بخشد.
مروری بر نحوه پیاده‌سازی متدولوژی چابک در شرکت‌ها
طی سه سال گذشته، ما در تحقیقات خود درباره انگیزه نیروی انسانی با استفاده از ترکیبی از رویکردهای مطالعاتی و تجربی، عملکرد مهندسان را در بیش از 500 سازمان مختلف تجزیه و تحلیل کرده‌ایم. ما دریافته‌ایم که آنچه در عمل اتفاق می‌افتد به شدت از اصول بیان شده، فاصله دارد.
فرایندها و ابزارها در مقابل تعاملات افراد تیم
به عنوان مثال در عمل، فرایندها و ابزارها به افراد و تعاملات بین آنها، مقدم شده‌اند. در یکی از 100 شرکت برتر فورچون، مدیر محصول به ما گفت: “ما مجاز نیستیم فرایند چابک شرکت را نقد کنیم.” در سازمانی دیگر، تعاملات بین مدیر محصول و اعضای تیم تنها از طریق بستر نرم افزار بود و تنها برای صدور دستورات از مافوق به کارکنان استفاده می‌شد. در حالی‌که کارآمدترین و موثرترین روش انتقال اطلاعات در میان اعضای تیم چابک، گفتگوی چهره به چهره است.
معضل مستندسازی
به همین ترتیب درگیر مستندسازی شدن، یکی دیگر از معضلات روش چابک در سازمان‌ها است. برای مثال در یک شرکت بزرگ فناوری، اعضای تیم محصول، ابتدا زمان زیادی برای نوشتن خرده الزامات نیازمندی‌های مشتری صرف می‌کردند. این الزامات به عنوان تیکت به اعضای تیم توسعه واگذار می‌شد تا شروع به کار کند. در روند اجرا، حجم اسناد و مدارک به مرور افزایش یافت و صف درازی شکل گرفت. تا در نهایت به یکی از چندین آبشاری تبدیل شد که از واحد تولید به واحد طراحی و مهندسی سرازیر می‌شد. این پیامد، دقیقاً همان چیزی است که فرآیند چابک قصد دارد از بین ببرد.
پیروی از برنامه ثابت و یا ایجاد تغییر، در مواجه با عدم قطعیت‌ها
وقتی می‌گوییم در متدولوژی چابک، واکنش به تغییرات بالاتر از پیروی از یک برنامه ثابت است؛ نباید برداشت اشتباه شود که طرح و برنامه نداشته باشیم. به عنوان مثال در یک شرکت که در حوزه فناوری رشد سریع داشت، تیم‌های چابک نتوانستند استراتژی اصلی و کلان سازمان را درک کنند. درنتیجه تلاش آنها اغلب بر روی ویژگی‌های کم ارزش یا استراتژی‌های بی‌اهمیت متمرکز شده بود. باید در نظر داشت که بدون برنامه، اعضای تیم نمی‌دانند چگونه کارهای خود را اولویت‌بندی کنند و چگونه روی کارها تمرکز کنند.
استفاده نادرست از روش چابک به جای اینکه به اعضای تیم این قدرت را بدهد؛ که بهتر و قوی‌تر در مقابل ریسک‌ها و عدم قطعیت‌ها در فرایند توسعه محصول ظاهر شوند؛ باعث کاهش انگیزه آنها می‌شود. چرا که به آنها اجازه سازمان‌دهی و مدیریت کارهای خود و تعامل با مشتری داده نشده است؛ و از طرفی فشار موفقیت یا رکود شرکت را احساس می‌کنند. باعث می‌شود که یادگیری و انگیزه‌شان کم شده و با بیشترین توان خود کار نکنند.
برای مثال، یک شرکت سرمایه‌گذار عنوان کرد که یک شرکت بازی ویدیویی، یک سال برای تولید محصولی تلاش کرد درحالی‌که تمام مهندسان شرکت معتقد بودند این بازی ارزش بازی کردن ندارد. در نتیجه زمان و سرمایه بسیاری از این شرکت، از بین رفت.
فرایندهای چابک به این دلیل اشتباه پیش می‌روند که:
در حالی‌که شرکت‌ها برای عملکرد بالا تلاش می‌کنند، یا بسیار تاکتیکی می‌شوند (مدیریت جزء نگر و تمرکز بیش از حد روی فرآیندها) و یا بسیار سازگار (اجتناب از اهداف بلندمدت، برنامه‌های زمانی و یا همکاری‌های متقابل عملکردی). نکته اصلی ایجاد تعادل بین عملکرد تاکتیکی و سازگاری است. در اینجا چند نکته برای یافتن این نقطه تعادل ارایه شده است. بنابراین می‌توانید با به کارگیری آنها انگیزه و عملکرد تیم چابک خود را بهبود بخشید.
توسعه نرم‌افزار باید یک فرآیند مشارکتی باشد.
در تیمی که برای دست‌یابی به چابکی واقعی تلاش می‌کند، به جای طی کردن فرایندی که یک نفر در آن نیازمندی‌های مشتری را استخراج کرده و دیگری فقط اجرا کند؛ افراد باید از ابتدا تا انتها برای اجرای کار مورد نظر با یکدیگر همکاری داشته باشند.
به این ترتیب که، در ابتدا چالش‌های استراتژیک تیم به شکل سوالاتی مطرح می‌شوند که معمولاً بر تامین و بهبود رضایت مشتری متمرکز هستند. بررسی این سوالات در سطح تیم به شکل ماموریت درآمده و تفکر جمعی را ایجاد می‌کند؛ و در نهایت منجر به ارائه بهترین ایده‌ها، نیازمندی‌ها و طراحی‌ها می‌شود. سپس تک تک اعضای تیم به صورت مشترک، روی ایده کار می‌کنند تا به بهترین شکل به انجام برسد.
محصول قابل استفاده در بازه‌های زمانی متناوب (اسپرینت) ارائه شود.
تحویل یک نرم افزار قابل استفاده، اصلی‌ترین معیار سنجش پیشرفت پروژه است. تیم‌ها معمولاً برای رسیدن به محصول مشتری وقت زیادی را تلف می‌کنند. برای جلوگیری از این امر، تیم‌های چابک باید محصول درخواستی را به تناوب در چندین بخش قابل استفاده حاضر کرده و تحویل دهند. هرچه این بازه‌های زمانی کوچک‌تر باشند، بهتر است؛ و در صورت امکان، بازه زمانی نباید بیش از یک هفته به طول انجامد.
رویکرد تیم چابک باید مشتری محور باشد.
روند ساخت نرم افزار (حتی نرم افزارهای داخلی) باید کاملاً مشتری محور باشد. به‌این منظور، در ساده‌ترین حالت، اصول زیر باید رعایت شود:
- چالش‌های استراتژیک همیشه باید با نگاه به مشتری مطرح شوند.
- جلسات حل مساله، همیشه باید با مسایل مشتریان آغاز شوند و یکی از اعضای تیم فروش و ارتباط با مشتریان، در جلسه حضور داشته باشد.
- هر یک از فعالیت‌ها، حول یکی از فرضیات مشتری‌محور شکل بگیرد.
مهم‌ترین و موثرترین نکته این است که تیم مهندسی و طراحی، نحوه استفاده از محصول نهایی توسط مشتری را ببینند. بر این اساس، ارتباط مداوم و همکاری تیم مهندسی با تیم فروش و ارتباط با مشتری ضروری است.
همچنین تیم‌های چابک به طور متناوب و پیوسته باید از مشتری بازخورد دریافت کنند؛ تا محصول نهایی تولیدی را با بیشترین میزان نزدیکی به درخواست مشتری تحویل دهند. در این حالت، مشتری نیز دسترسی زود به زود به سفارش در حال تکامل خود را دارد. و به خوبی در جریان روند پیشرفت کار قرار می‌گیرد.
از بازه‌های زمانی برای جلوگیری از انحراف و تلف شدن وقت بهره بگیرید.
در توسعه نرم افزار سازگار، زمان‌بندی و تعیین بازه و مهلت زمانی برای انجام کارها، به عنوان محرک و ابزار کنترل تناسب سرمایه‌گذاری و سطح پذیرش کیفیت ویژگی‌های مورد نظر شناخته می‌شود. از سوی دیگر، برخی مخالف استفاده از مهلت‌های زمانی هستند. زیرا معتقدند باعث ایجاد فشار روانی بر کارکنان می‌شود. یکی از بدترین شرایط برای یک برنامه‌نویس این است که احساس کند، ماه‌ها تلاش و فعالیتش بیهوده بوده و ثمری نداشته است.
برای جلوگیری از ایجاد چنین حسی، باید مشخص کنید که کجای کار لازم است مسیر طی شده را کنترل کنید تا به بیراهه نروید. هرچه عدم قطعیت فرضیه بالاتر بوده و ریسک پروژه بیشتر باشد، این بازه زمانی باید کوتاه‌تر باشد. در این صورت این بازه‌های زمانی به معنی مهلت انجام کار نیست و معیاری برای تعیین عمق و کیفیت کار پیش از تحویل نهایی است و بنابراین به افزایش انگیزه اعضای تیم کمک می‌کند.
تیم چابک باید برای افزایش همکاری مشترک سازمان‌دهی شود.
برای اطمینان از اینکه فرایند به طور مشارکتی انجام می‌شود، لازم است ذی‌نفعان مختلف درگیر در پروژه، مانند یک تیم بین وظیفه‌ای عمل کند که در اصطلاح “پاد” نامیده می‌شود. هدف هر “پاد”، پیشبرد مشارکت کلی با سایر “پاد”هاست و هر “پاد” مجموعه کاملی از تمام تخصص‌های موردنیاز برای ارایه محصول را باید دارا باشد.
در بسیاری از سازمان‌ها، تیم‌ها خود را “پاد” می‌نامند، ولی در واقع کاذب هستند و بر خلاف عملکرد “پاد” عمل می‌کنند. نشانه‌های یک “پاد” کاذب به شرح زیر است:
- متخصصان در تیم‌های جداگانه‌ای حضور دارند. برای مثال همه طراحان در یک تیم جمع شده‌اند.
- تیم‌ها از ابزاری استفاده می‌کنند که مانع همکاری اشتراکی است.
- تیم‌های طراحی و تولید محصول اهداف متفاوت و مغایر با اهداف کلان دارند. مسئولان هر دو تیم از قدرت خود برای اثبات برتری عملیات خود استفاده می‌کنند. این امر در نهایت منجر به شکست در کار و عدم تحقق کار تیمی می‌شود.
- رویه‌های سخت‌گیرانه در ارزیابی عملکرد، عناوین سلسله‌مراتبی، فشار برای ارتقای سمت و مانند آن، باعث از بین رفتن روحیه کار تیمی می‌شود. این سیستم‌ها توجه اعضای تیم را به جای مشتری معطوف به مدیر تیم کرده و بین کارکنان رقابت ایجاد می‌کند در نتیجه اعضا مانند یک تیم عمل نمی‌کنند.
اعضای تیم باید دائماً روند کار خود را نقد کنند.
یک جمله مشهور به اسم قانون کانوی می‌گوید: “سازمان‌هایی که سیستم طراحی می‌کنند، ساختار محصولاتشان مشابه ساختار ارتباطی و فرایندهای داخلی سازمان خواهد بود.”
اگر بخواهید قانون کانوی را نقض کنید، باید به مرور ساختار و فرایندهای کاری را متناسب با مساله و نیاز مشتری تغییر دهید. این امر، نیازمند تیم‌هایی با ساختار و فرایندهای ساده است تا مدام قابل نقد و اصلاح باشد.
بنابراین، الگوی چابک نباید مانند یک عقیده و باور خدشه‌ناپذیر باشد، بلکه باید به طور متناوب (مثلاً در دوره‌های ماهانه) مورد ارزیابی قرار گرفته و بهبود یابد.
توانایی ایجاد، توسعه و حفظ محصول دیجیتال، به یک ماموریت حیاتی برای سازمان‌ها بدل شده است. بیشتر سازمان‌ها فریب یک عبارت ساده را خورده‌اند که اجرای پشت سر هم الگوی چابک باعث بهبود همه چیز می‌شود. متاسفانه این عبارت هنگامی که عامل انسانی را در پروژه‌ها فراموش می‌کنیم، نادرست خواهد بود. با رعایت اصول انگیزش و سازگاری عملکرد و استفاده از یک بستر مناسب برای مدیریت متدولوژی چابک، می‌توان سازمانی به معنی واقعی چابک ساخت.
اگر این موضوع برای شما جذاب بوده است، پیشنهاد می‌شود تا این یادداشت را نیز مطالعه کنید.