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

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

در بسیاری اوقات اسکرام پیاده می شود، ولی واقعا چیزی بهتر نمی شود.

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

پروژه تحلیلگر امید را چگونه شروع  کردیم؟

سعی کردم در شرکت امید، از مدل اجایل فلوئنسی برای پیشبرد چابک سازی استفاده کنم. مدل اجایل فلوئنسی سه گام اساسی برای چابک سازی دارد:

1- شناسایی فرصت

2- دیاگ زدن

3- دست یابی به فرصت

مرحله اول: شناسایی فرصت

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

در مورد شرکت امید، این شناسایی در طی یک هفته اول که در سازمان بودیم انجام شد، شامل صحبت کردن با تیمها و اعضای فنی و مدیران محصول و مدیران ارشد … .

نکته مهم در اینجا این است که همه دوستان از ظن خودشان یار شما می شوند. کار یک مربی در اینجا این است که درک کند که مسائل زیرین و اساسی چیست؟ مثلا اینکه جلسات دیلی به موقع برگزار نمی شود، شاید مسئله اساسی نباشد.

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

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

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

  • فرصت شناساسی شده در امید

بهبود کیفیت سیستم جهت حداکثری کردن رضایت مشتریان، ذینفعان و بخصوص اعضای تیم

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

انتخاب ناحیه فلوئنسی بر اساس فرصت/چالش

مدل اجایل فلوئنسی یک مدل بلوغ نیست، معمولا در مدل بلوغ هر چقدر بیشتر بهتر است اما در مدل اجایل فلوئنسی که ما چهار ناحیه داریم، هر ناحیه برای خودش منافع مشخص و در عین حال هزینه مشخصی دارد. یعنی به تنهایی هر ناحیه ی مدل بالغ کامل است. در صورتی که ناحیه بالاتر نیاز ما نباشد، صرفا هزینه غیر لازمی را انجام خواهیم داد.

توضیح خلاصه نواحی مختلف فلوئنسی

  • ناحیه Focusing در واقع همان پایه و فونداسیون چابک است و یک تیم چابک فلوئنت در این حوزه می ‌تواند از منافع حاصل شده از شفافیت و کار تیمی به صورت ملموس بهره ببرد. هر چند که فلوئنت بودن در این ناحیه شامل مهارت های فنی پایدار نیست، اما بدست آوردن و نمایش موفقیت در این حوزه باعث ایجاد تمایل بیشتر برای سرمایه‌گذاری های آتی و بدست آوردن مهارت هایی در ناحیه های بعدی می‌شود. همچنین این ناحیه برای تیم هایی خوب است که به نگهداری بلند مدت از نرم‌افزارهای خود نیاز ندارند.
  • برای تیم هایی که نیاز دارند نرم افزار خود را به صورت بلند مدت نگه داشته یا بهبود دهند ناحیه Delivering می تواند انتخاب بهتری باشد. این ناحیه در واقع نمایانگر پایداری چابک است. تیم‌های فلوئنت در این ناحیه باگ کمتری دارند، بازدهی آنها بالا بوده و نسبت به درخواست های کسب و کار پاسخگو هستند. فلوئنت بودن در این ناحیه می تواند برای بسیاری از تیم‌ها جهش بزرگی محسوب شود.
  • سازمان هایی که می‌خواهند با سرعت تغییرات بازار هماهنگ باشند یا حس می کنند که تغییرات مهلک بازار می تواند بقای آنها را به خطر بیاندازد ناحیه Optimizing می تواند انتخاب بهتری باشد. در واقع ناحیه Optimizing وعده اصلی چابک است. چابکی کسب و کار به همراه خلاقیت. گرچه این ناحیه باعث بوجود آمدن منافع زیادی برای کسب و کار می شود ولی نیازمند تغییرات اساسی در ساختار سازمانی خواهد بود. انجام چنین تغییراتی معمولا در سازمان های کوچک راحت تر است.
  • ناحیه Strengthening برای سازمان‌هایی است که مدیران و رهبران به دنبال خلاقیت حداکثری در سازمان هستند و معمولا این اتفاق در سازمان های کوچک و متوسط امکان پذیرتر است. در واقع این آینده چابک است یعنی جدیدترین تکنیک های چابک در همین مسیر در حال حرکت هستند. اما نکته احتیاطی در این جا است که رسیدن به این ناحیه نیاز به تحقیقات بسیاری در خصوص آخرین سبک های مدیریت و سرمایه‌گذاری سنگین برای اجرایی کردن این سبک های جدید کاری خواهد داشت.

بر اساس فرصت/چالش اصلی انتخاب شده برای امید، ما ناحیه  دوم یا Delivering  را انتخاب کردیم اما نیم نگاهی هم به ناحیه Optimizing  داشتیم که در صورت پایداری بتوانیم تارگت آینده ما آن باشد، اما تمرکز اصلی در این دوره بر روی ناحیه Delivering بود.

اما چرا ناحیه Delivering انتخاب شد؟

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

خوب این موارد دقیقا همان مواردی بود که ما برای فرصتی که کشف کرده بودیم لازم داشتیم. پس بر اساس همین، ناحیه دوم انتخاب شد. نکته مهم: ناحیه Delivering  بر پایه ناحیه Focusing استوار است. یعنی شما باید در مسیر، حتما به تمرینات این ناحیه نیز سر بزنید.

خوب در هفته اول ما فرصت را کشف کرده بودیم، و تارگت خودمان را نیز انتخاب کرده بودیم، الان زمان دیاگ زدن بود.

مرحله دوم: دیاگ زدن

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

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

با توجه به شرکتی بودن موارد این دیاگ، جزئیات زیاد آن قابل انتشار نیست.

مرحله سوم: دست یابی به فرصت

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

در خواست ما از مدیران، برای تارگت  ناحیه اول یا همان Focusing  (که زیربنای تارگت اصلی ما بود)، موارد زیر بودند:

●        محیط مناسب که متمرکز بر بازدهی بالا دارد (به خصوص اتاق مخصوص تیم) ایجاد کنید.

●        مطمئن شوید که شخصی با تخصص در حوزه کسب و کاری و آشنا به ارزش های مشتری در دسترس بوده و به عنوان نماینده کسب و کاری تیم عمل نماید.

●        سعی کنید موانع کار تیمی موثر را برطرف نمایید مانند رتبه بندی رقابتی، پاداش های انفرادی.

●        اعضای تیم را در مورد مهارت های Focusing آموزش  داده و زیر نظر مربی قرار دهید.

●        مدیران را آموزش بدهید تا آن ها محیط مناسب جهت کار تیمی را ایجاد نمایند و به جای مدیریت افراد به دنبال مدیریت سیستم های کاری باشند.

مدیران همکاری خوبی در تمامی موارد انجام دادند، مثلا شکستن تیم ها به تیم های محصول یکی از کارهایی بود که انجام دادیم، یا اینکه اعضای تیم محصول دور هم سر میز مشترک نشستند. یا اینکه مدیران به جایی پیگیری کار از شخص که قبلا روال بود، سعی کردند کار را از تیم بخواهند. در نهایت نزدیک به ۸ تیم جدید محصول محور شکل گرفت و ساختار تیم ها نظیر Role and Responsibility، چارت ساختار تیم، ماتریس شایستگی و اهداف و ماموریت تیم ها توسط افراد هر تیم مشخص شد.

ساختار تیم های محصول محور

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

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

در سطح تیم، کارهای زیادی باید انجام میشد. اصلی ترین کار این بود که یک جاهایی از سیستم باید رفاکتور میشد، یک جاهایی باید از اول نوشته میشد، تست (از انواع مختلف به سیستم باید سیستم اضافه میشد)، اما یک خطری که امکان داشت اتفاق بیفتد این است که ما در دام رفاکتور بی انتها بیفتیم. برای این منظور ما از یک تکنیک ساده استفاده کردیم، بالای ۱۰۰ باگ اخیر سیستم را بررسی کردیم، معمولا باگ ها نشانه های خوبی از نقاط  باگ خیز و شکننده سیستم برای ما است. بعد بر اساس این شواهد شروع کردیم، به آماده سازی لیست اولویت بندی شده از رفاکتورها.

رفاکتورها و اضافه شدن تست به مرور در اسپرینت ها انجام میشد. اما باید می دانستیم این کارها منجربه کاهش میزان باگ ها میشود، به عبارت ساده اگر چیزی را نتوانیم اندازه بگیریم نمی توانیم آن را بهبود بدهیم. در شروع کار، یک ویجت گزارش باگ به سیستم اضافه کردیم که کاربران و تسترها می توانستند باگ های سیستم را گزارش کند و این باگ ها در جیرا خودکار ثبت می شد. عدد در هفته های اول باور نکردنی بود، ۳۰ تا ۴۵ باگ در هفته.

اولین گام همراهی در تغییر، ایجاد حس اورژانس است

وقتی اولین بار بچه ها این عدد و نمودار بالا را دیدن، واقعا برایشان باور کردنی نبود، “واقعا ما اینقدر باگ داریم …”. برخی اوقات برای ایجاد حس اورژانس شما نیاز دارید وضعیت واقعی را جلوی چشم بیاورید، همین.

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

تاثیر کار را ببین، با قدرت تر جلو برو

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

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

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

بعد از دیدن نتایج و کاهش باگ، بشدت روابط انسانی افراد نیز بهبود پیدا کرد.

امیرمهدی یکی از برنامه نویس های امید، گزارش کاملی از پرکتیس های فنی در اینجا نوشته است.

اما نتیجه چه بود؟

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

نمودار باگ گزارش شده

ولی مهمترین نکته حس بچه های تیم بود، برای مثال این کامنت یک سری از بچه های فنی شرکت است:

 نتایج ملموس در طول پنج ماه برای کسب و کار،

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

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

بخاطر اینکه، اصلی ترین ذینفع ما در این پروژه، شخص خود مدیرعامل بود، از ایشون درخواست کردم که در یک جمله نظرشون رو در خصوص نتیجه پروژه انجام شده داشته باشم:

گاهی اوقات در سازمان افراد دچار سوگیری قضاوتی می شوند. فرض کنید شما یک سیستم پیشرفته پیاده سازی می کنید و بعد از ۲ سال تمامی راه حل ها و معماری هایی که کنار هم چیده اید شبیه به فرزندتان هستند. به دلیل sunk cost و گذشته ای که از این ماژول ها میشناسید، سازمان در تصمیم گیری محتاط می شود و ممکن است یک تصمیم اشتباه گذشته را به خاطر هزینه هایی که برایش کرده ایم ادامه دهیم. در این نقاط حتما باید یک فرد متخصص و باتجربه به سازمان وارد شود و با reference point جدید اطلاعاتی، شروع به قضاوت کند و تصمیمات بهتری برای پروژه های اشتباه یا پرخرج بگیرد. شما اسدجان به خوبی این کار رو انجام دادید. درک عمیق از روابط انسانی، پیدا کردن ریشه مسایل به جای پرداختن به شاخ و برگ ها، حضور مداوم در تیم ها و تجربه شگرف و شناخت مشکلات کار تیمی در ایران باعث شد، چالش های قبلی که در امید بود کاملا محو شود. واقعا از شما متشکرم.”

آینده امید چگونه است؟

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

چابک و موفق باشید

اسد صفری

درباره اسد صفری

اسد صفری – مربی تحول چابک سازمان و تیم های نرم افزاری. مدارک حرفه ای: CSP - CSM - PSM - PSPO - CDA - Management 3.0 برخی تجربیات: رئیس دفتر تحول چابک شرکت داده ورزی سداد(بیشتر از ده تیم نرم افزاری) - مربی چابک شرکت رامند (تیم های موبایل و گیم سازی) - مدیر تولید نرم افزار SimplyDesk برای شرکت فرانسوی PCI - مربی مشاور شرکت های:خدمات انفورماتیک، ارکید فارمد، فراداده، الفبا برخی از سوابق مشاوره کوتاه مدت و تدریس : علی بابا، فناپ، تجارت الکترونیک پارسیان، بیمه سامان، مهندسین مشاور تجارت (بانک تجارت)، بیمه ایران، پارس آنلاین، شرکت رهنما، ورانگر، انتشارات پزشکی کوثر، فولا آلیاژی یزد، پارک علم فناوری کردستان و ... . عضو انجمن های بین المللی Agile Alliance - Scrum Alliance

3 دیدگاه در “تجربه سفر چابک در شرکت تحلیلگر امید : داستان واقعی تحول چابک

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

پاسخ دادن به محسن شادرو لغو پاسخ

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *

این سایت از اکیسمت برای کاهش هرزنامه استفاده می کند. بیاموزید که چگونه اطلاعات دیدگاه های شما پردازش می‌شوند.