چرا سازمانهای بزرگ چابک نمی شوند؟

مدیر ارشد: “آقای مدیر پروژه، قرار بود هفته گذشته پروژه ایکس لانچ بشه، چی شد پس؟”

مدیر پروژه: “دو هفته قبل ما به واحد ایکس درخواست زدیم که کار عملیاتی رو انجام بدن، ولی خبری نیست …”

مدیر واحد ایکس: “ما منتظر واحد وای هستیم تا به ما تایید بدن که شروع کنیم یا نه، البته درگیر چند تا پروژه دیگه هم هستیم…”

مدیر واحد وای: “ما در گیر همون پروژه دیگه ای بودیم که خودتون گفته بودید و …” 

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

برای شروع بهتر است با هم مفهوم جریان ارزش را مرور کنیم. 

جریان ارزش 

چند دقیقه فراموش کنیم که شرکت ما چه واحدهایی دارد، فرض کنیم که ما (یعنی یک شرکت با تمامی واحدها) قرار است تنها یک نرم افزار تولید کنیم، مثلا یک نرم افزار به اسم رمزینو که افراد بتوانند از طریق آن رمز دوم و رمز اول یک بار مصرف دریافت کنند. 

خروجی: “یک نرم افزار تولید رمز یکبار مصرف”،

ارزشی که خلق می‌کنیم: “بالا بردن امنیت تراکنش های مبتنی بر کارت، تا مردم در دام فیشینگ نیفتند”. 

جریان ارزشی: “واحدها و فرآیندهای مختلفی که برای خلق این ارزش باید کار کنند تا این ارزش خلق بشود”

معمولا جریان ارزشی در سازمانها چنین چیزی است: 

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

 دست به دست شدن، فرا-معاونتی و درون معاونتی بین گروهها.

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

اما اگر کار پیچیده باشد، چطور؟ 

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

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

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

اما چگونه میتوان این کار را انجام داد؟

1- بهینه سازی فرآیندها و نصب ابزارهای لازم

معمولا اولین روشی که به ذهن دوستان فرآیندی(کسانی که بیشتر سابقه بهبود فرآیند دارند) میرسد، بهینه سازی فرآیند کار با تدوین فرآیند کاری، مجموعه ای از دستورالعمل و قانون و بعلاوه ایجاد ابزارهای جدید جهت تسریع چرخه بازخورد خواهد بود.

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

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

ما که میخواستیم”یک نرم افزار تولید رمز یکبار مصرف ” تولید کنیم تا “بالا بردن امنیت تراکنش‌های مبتنی بر کارت، مردم در دام فیشینگ نیفتند”، خلق شده است واقعا؟ و اینکه مردم از آن استفاده می کنند؟

چرا نگاه ارزش محور در این شیوه سازماندهی از بین می‌رود؟

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

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

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

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

2- نگاه چابک، مبتنی بر خلق ارزش 

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

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

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

برداشت های اشتباه:

در تجربه من وقتی چنین مدلی مطرح می شود، همیشه نگرانی هایی مطرح می شود:

1- “تو میخوای معاونت یا گروههای به جر نرم افزار رو از بین بری، مثلا واحد امنیت چی میشه؟”

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

1- آموزش و توانمند سازی متخصص های امنیت هر تیم محصول

2- ارزیابی عملکرد و استخدام متخصص امنیت برای تیم های محصول

3- تدوین استانداردهای سراسری امنیت برای محصولات

4- ایجاد و مدیریت زیرساخت های امنیتی مثل فایروال یا … 

5- انجام تست های کلان مثل تست زیر ساخت ها و …

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

2- “اینجوری دائم چرخ اختراع می شود، هر گروهی برای خودش یک استانداردی در پیش می‌گیرد، اگر متمرکز باشد خیال ما از استاندارد بودن و اختراع دوباره چرخ راحت می شود”

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

دوست دارم تجربیات و نظرات شما را در این مورد بدانم.

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

اسد صفری

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

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

2 دیدگاه در “چرا سازمانهای بزرگ چابک نمی شوند؟

  1. بسیار عالی توضیح دادی. اما تجربه شخصی من اینه که بعضی اوقات خود (به اصطلاح) اسکرام مسترها با اینکه باید پیش رو این موج باشن، با دید سنتیشون و ایجاد قوانین دست و پا گیر باعث کندی میشن.

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

دیدگاهتان را بنویسید

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

This site uses Akismet to reduce spam. Learn how your comment data is processed.