


صف، دشمن حقیقی جریان بخش سوم
14 مرداد 1399


تفاوت بین تابلو کانبان و تابلو اسکرام
10 مهر 1399در ادامه مقالهی «بهکارگیری تفکر ناب در توسعه نرمافزار» به بررسی اتلاف شناسایی شده در محیط توسعه نرمافزار میپردازیم. پیشنهاد میشود درصورتیکه هنوز بخشهای قبلی این مقاله را نخواندهاید مطالعه را از بخشهای اول و دوم آن شروع کنید.
هفت اتلاف در فناوری اطلاعات
هفت اتلاف شناسایی شده در یک محیط تولید عبارتند از:
- نقل و انتقال
- موجودی
- حرکت (جابهجایی)
- انتظار
- تولید بیش از حد
- فرایند سازی بیش از حد
- نقصها
اتلاف شماره 5: تولید بیش از حد
تولید بیش از حد، اتلافی عادی در محیط توسعه نرمافزار است. به نظر من، این اتلاف در دو سطح وجود دارد. اولین مورد خزش محدوده[1] است. خزش محدوده زمانی اتفاق میافتد که با مجموعهی مشخصی از ویژگیها شروع به کار میکنید، اما در طی توسعه مجبور میشوید ویژگیهای اضافهای را پیادهسازی کنید و یا ویژگیهای موجود را تغییر دهید. این امر منجر به کار اضافهای میگردد که در بدو شروع پیشبینی نشده بود، و به نوبه خود باعث PLT و چرخههای تحویل طولانیتری میشود.
سطح دوم تولید بیش از حد را با استفاده از اصل پارتو[2] میتوان نشان داد. با استفاده از این اصل، میتوان گفت 80% مخاطبان هدف (target audience)، فقط از 20% ویژگیها استفاده میکنند. شما احتمالاً زمان زیادی را صرف توسعه ویژگیهایی خواهید کرد که به ندرت مورد استفاده قرار میگیرند. آیا این بدان معناست که نباید بههیچوجه آنها را توسعه داد؟ قطعا نه! این ویژگیهای غیر ضروری، که باعث رضایت مشتری میشوند غالباً هیجانانگیز هستند. آنها ممکن است منجر به برتری نسبت به رقبا و جذب بیشتر مشتری شوند. و از آنجا که برای کسب درآمد مشغول کار هستید، جذب مشتری بیشتر همواره چیز خوبی است.
اتلاف شماره 6: فرایند سازی بیش از حد
هر دپارتمان توسعه نرمافزار چند نوع فرایند دارد تا روشی را که وظیفهها، درخواستهای ویژگی یا رفع خطاها مدیریت میشوند؛ شرح داده و آموزش دهد. داشتن چنین مستنداتی که به آسانی در دسترس بوده و قابل درک توسط تیم باشد؛ نیازمند حرکت گردش کار است. با این حال، علیرغم نیتهای خوبی که در شکسته شدن فرایند به گامهای مختلف متعدد برای شفافسازی و تعیین دقیق مسئولیتها دارید، خطر «فرایند سازی بیش از حد» را در کل فرآیند توسعه بالا میبرید.
جریان فرایند باید تعریف شود، اما تعریف بسیاری از زیرفرایندها یا گامهای درون فرایند فقط آن را پیچیدهتر میکند. افزایش پیچیدگی باعث سردرگمی و گاهی ناامیدی در بین افرادی میشود که مجبورند از فرایند پیروی کنند. همهی افراد از مقررات دستوپاگیر دولت بیزار هستند، از سوی دیگر فرایند سازی بیش از حد، مقررات دستوپاگیر شما را نیز وارد محیط کار میکند! این باعث میشود که فرایندتان همچنان که افراد وقت خود را صرف کار کردن روی چیزهایی مثل سردرآوردن از گام بعدی میکنند؛ اتلاف بیشتری داشته باشد چرا که همکاری که مسئولیت یک زیروظیفه خاص را بر عهده دارد، در آن لحظه حاضر نیست و غیره.
همچنین جریان فرایندی پیچیده، منجر به همپوشانی وظیفهها یا مسئولیتها خواهد شد. گاهی دو نفر در گامهای مختلف فرایند، عمل یکسانی را تعهد میدهند. آیا واقعا ضروری است؟ نمیتوانید یکی از آن وظیفهها را به سادگی حذف کنید؟ بعضی مواقع نمیتوانید، زیرا آنها یک مرحله اضافی کنترل کیفیت هستند، اما مطمئنم که معمولا میتوانید در محیط توسعه نرمافزار یکی از وظیفهها را حذف کنید، از کار تکراری جلوگیری کنید و فرایند خود را سرعت بخشید.
بهترین راه برای تشخیص مسئولیتهای همپوشانی شده استفاده از نقشه جریان ارزش (VSM) است. برای ایجاد یک نقشه جریان ارزش، گامهای مختلف فرایند را ترسیم کرده و مسئولیتهای هر فرد را در قبال هر گام اضافه کنید. هنگام انجام این کار، ضروری است که این نقشه را با کل تیم ایجاد کنید. این تنها روشی است که میتوان مطمئن شد فرایند واقعی و نه آنچه را که در ذهن دارید ترسیم کردهاید. یکی از رایجترین اشتباهات در ایجاد VSM تصور آن است که فرایند دقیقاً همان روشی است که شما فکر میکنید.
اتلاف شماره 7: نقصها
نقصها احتمالاً سادهترین موارد برای تشخیص به عنوان اتلاف هستند. مفهوم نقصها در کسبوکار توسعه نرمافزار بهخوبی شناخته شده است و توضیح آن آسان است. نقص هنگامی رخ میدهد که محصول نرمافزاری، وصله یا درخواست ویژگی، آنطور که باید اجرا نمیشود. عبارت «آنطور که باید» توسط مشتری تعریف شده است. اگر مشتری از راهحلی که ارائه میدهید راضی نیست، یک نقص دارید.
همانطور که میتوان از جمله قبلی برداشت کرد، نقص لزوماً یک خطا نیست. اگر مشتری محصول را سفارش داده یا خریداری کرده باشد و آن محصول انتظارات وی را به طور کامل برآورده نکند، یک نقص دارید. اگر در مورد یک خطا بحرانی واقعی صحبت میکنید، قطعاً باید برطرف شود. اما همه نقصها قابل رفع نیستند. بعضی اوقات به محدودیتهایی برمیخورید که به شما اجازه نمیدهند مشتری را کاملاً راضی کنید. در برخی موارد، برآورده کردن تمام نیازهای مشتریان، اقتصادی نیست یا حتی به لحاظ مالی عملی نیست و باید انتخاب سختی کنید؛ بین اینکه چه چیزی را پیادهسازی کنید و چه چیزی را کنار بگذارید. هزینه برآورده کردن یک نیاز خاص ممکن است بیشتر از بازگشت سرمایه باشد. و اگر مشتریان متعددی دارید (که امیدوارم داشته باشید)، نمیتوانید تک تک آنها را به یک اندازه راضی کنید. این موضوع به خوبی مرا به آخرین نکتهای که میخواهم در این مقاله بیان کنم میرساند: هزینه تولید محصول بیکیفیت (COPQ).
هزینه تولید محصول بی کیفیت (COPQ)
COPQ هزینهای است که اگر همهی فرایندها، سیستمها، محصولها و افراد کاملا بینقص باشند، از بین میرود. این یک هزینه قابل توجه است که شما از انواع مشکلات، آن را به ارث میبرید. این معمولاً به یک کوه یخ تشبیه میشود: فقط حدود 10% از آن را میبینید، اما 90% دیگر آن در هزینههای اضافی پایهای شما نهفته است.
اجازه دهید ابتدا مثالی از محیط تولید برایتان بزنم. فرض کنید در چرخه تولیدتان 10% نرخ نقص دارید. این بدان معناست که برای فروش 1000 قلم، باید در عمل 1100 قلم تولید کنید. و این یعنی 100 قلم میسازید که بههیچوجه از آن پولی بدست نمیآورید. هزینه ساخت آن 100 قلم اضافی، COPQ شما است. منشأ این نقصها میتواند در جاهای زیادی نهفته باشد: اجزای اصلی معیوب؛ ماشین آلات نامناسب؛ و غیره.
در نرم افزار،COPQ را در کجا پیدا کنیم
در محیط توسعه؟ خب، در حال حاضر این نقصها واضح هستند، همانطور که قبلتر در مورد آنها بحث کردیم. در هر حال، منبع این نقصها را میتوان در سیستمهای ردیابی معیوب، مدیریت ناکارآمد، توسعه دهندههای کمتجربه و تازهکار، عدم استفاده صحیح از فناوری، عدم وجود مستندات، خرابیهای بیش از حد سیستم و غیره یافت.
اگر مسئلهای دیدید که میتواند به COPQ نسبت داده شود، باید بیشتر کاوش کنید و واقعاً زیر و بم آن را در بیاورید تا منبع هزینه را پیدا کنید. و سپس باید برای رفع آن اقدام کنید و نه آنکه فقط آن را به عنوان یک مسئله شناختهشده رها کنید. اگر واقعاً میخواهید چیزی را بهبود ببخشید، باید هر فرصتی که دارید را غنیمت بشمرید، زیرا هزینه صرفشده برای بهبود کارها خودش بهسرعت برمیگردد.
نتیجهگیری
ماریو آندرتی (Mario Andretti)، قهرمان سابق جهان در فرمول یک، میگوید: «اگر احساس کردید همه چیز تحت کنترل است، یعنی به اندازه کافی سرعت ندارید!» این شعاری است که سعی میکنم با آن زندگی کنم و به نظرم در مورد تفکر ناب نیز صدق میکند. زیرا معتقدم اگر در موقعیت خود احساس راحتی میکنید، به این معنی است که جا برای بهبود دارید.
وقتی نوبت به بهبود مستمر میرسد، همیشه باید از دایره راحتی[3] خود خارج شوید و راههای جدید یا بهتری برای بهبود آنچه انجام میدهید پیدا کنید. به همین دلیل هم «مستمر» نامیده میشود!
درباره نویسنده
استیون پیترز (Steven Peeters) مشاور آزاد با تجربه وسیعی در توسعه برنامههای کاربردی و تحت وب است. او همچنین به عنوان مربی رسمی Adobe آموزشهایی را به افراد و مؤسسات مختلف در منطقه BeLux داده است. در سال 2012 او شرکت خود را، با نامSilver Lining ، با هدف ترکیب جنبه آموزش با مشاوره در مدیریت تغییر، فرایند و پروژه، بهراه انداخت. او با این هدف، شروع به تمرکز بر روی تکنیک شش-سیگمای ناب کرده و موفق به دریافت کمربند سیاه شش-سیگما ناب شد و این تکنیکها را در محیط فناوری اطلاعات بکار گرفت.
[1] خزش محدوده (انگلیسی: Scope creep) یا سندرم سینک آشپزخانه، در مدیریت پروژه، اشاره به تغییرات، رشد مداوم یا کنترلنشده در محدوده پروژه، در هر نقطه از زمان شروع تا پایان پروژه دارد. خزش محدوده میتواند زمانی رخ دهد که دامنه یا محدوده یک پروژه به درستی تعریف و مستند نشده، یا کنترل نشده باشد و حاصل آن، افزایش مدیریتنشده تعهدات یا کارهای اجرایی، به میزان بیش از تعهدات اولیه پروژه میباشد. خزش محدوده در اغلب پروژهها، گونهای ریسک محسوب میشود و بهطور کلی برای پروژه مضر میباشد. (ویکیپدیا)
[2] اصل پارتو (به انگلیسی: Pareto principle)، که با نام قانون ۸۰–۲۰، نیز شناخته میشود بیان میکند که ۸۰ درصد رخدادها از ۲۰ درصد دلایل بهوجود میآیند. اصل پارتو یک قاعده سرانگشتی رایج در تجارت است؛ برای مثال «۸۰ درصد فروشها مربوط به ۲۰ درصد مشتریان است.» از لحاظ ریاضی اصل ۸۰–۲۰ از توزیع قانون توان با مجموعه پارامترهای ویژه پیروی میکند (با نام توزیع پارتو نیز شناخته میشود) و بسیاری از پدیدههای طبیعی از این توزیع پیروی میکنند. (ویکیپدیا)
[3] دایره راحتی (به انگلیسی: Comfort Zone) یک وضعیت رفتاری است که در آن فرد با مسائل و چیزهای آشنا سروکار دارد و اوضاع تحت کنترل و مدیریت اوست. دایره راحتی، نشان دهنده مرزهای روانی است که فرد برای ایجاد امنیت دور خود میکشد و سعی میکند بیرون از آن قدم نگذارد. برای بیرون رفتن از این مرزها، فرد باید رفتارها و تجارب جدیدی را امتحان کند و اجازه دهد که محیط به آنها پاسخ دهد.
مترجم: علی مفخر
ویراستار: مهدیه قدسینژاد



