اهداف تجاری شما در توسعه نرم‌افزار همچنان مشابه اهداف در تولید هستند. کسب‌وکار شما متعهد به ارائه راه‌حل‌های باکیفیت و نوآورانه به مشتریان در سریع‌ترین زمان ممکن است. سرعت معمولاً با دو معیار زمان تحویل (Lead Time) و زمان چرخه (Cycle Time) اندازه‌گیری می‌شود. زمان تحویل، یک معیار متمرکز بر مشتری است، در حالی که زمان چرخه، یک معیار مربوط به فرآیند داخلی است. زمان تحویل مدت‌زمانی را نشان می‌دهد که مشتری برای دریافت چیزی باید منتظر بماند، و زمان چرخه مدت‌زمان انجام واحدهای کاری مجزا را نشان می‌دهد.
هنگامی که از زمان تحویل صحبت می‌کنم، منظورم سرعت انجام کار در یک بخش خاص از نقطه A به نقطه B نیست. منظورم این است که کار از تعهد مشتری (نقطه A) تا دریافت و استفاده از قابلیت توسط مشتری (نقطه Z) انجام شود. در این بخش، این دو معیار را بررسی خواهیم کرد.
زمان چرخه
بیایید به مثال تولید خودرو برگردیم، جایی که به زمان تاکت (Takt Time) اشاره کردم. زمان چرخه با زمان تاکت تفاوت دارد. زمان تاکت نشان می‌دهد که با توجه به میزان تقاضا، چقدر زمان برای تکمیل یک واحد کاری مشخص دارید. زمان چرخه نشان می‌دهد که برای انجام یک واحد کاری چقدر زمان صرف کرده‌اید. زمان چرخه می‌تواند در هر سطحی اندازه‌گیری شود. این چه معنایی دارد؟
فرض کنید وارد یک کافی‌شاپ شده‌اید و سرانجام به صندوق رسیده‌اید تا سفارش نوشیدنی خود را بدهید. زمان چرخه از لحظه‌ای شروع می‌شود که باریستا (Barista) (امیدواریم) با لبخند از شما سفارش می‌گیرد و زمانی پایان می‌یابد که سفارش یا نام شما را اعلام می‌کند. مدت‌زمانی که برای تهیه نوشیدنی شما صرف شده است، همان زمان چرخه است. همچنین می‌توانید زمان چرخه را در سطوح پایین‌تر اندازه‌گیری کنید، برای مثال، چقدر طول کشید تا سفارش شما گرفته شود، چقدر طول کشید تا قهوه شما آماده شود و سپس زمان چرخه کلی چه مدت بود.
برگردیم به دنیای مهندسی نرم‌افزار. درخواست‌های ویژگی (Feature Requests) دارای یک زمان چرخه کلی هستند، یعنی روزها یا ساعت‌هایی که از شروع کار روی درخواست ویژگی تا استقرار آن طول می‌کشد. وظایف فردی برای تکمیل درخواست‌های ویژگی نیز دارای زمان چرخه هستند. زمان چرخه وظایف اهمیت دارد، زیرا در نهایت زمان چرخه کلی توسعه درخواست ویژگی را تعیین می‌کند.
شکل 1: محور X تعداد روزهای لازم برای تکمیل یک کار را نشان می‌دهد و محور Y تعداد درخواست‌های ویژگی در آن گروه را. امکان دارد این داده‌ها را به تابع توزیع نمایی منفی تطبیق داد. اینجا دنیای میانگین‌ها نیست.
زمان تحویل
این مورد در کارهای دانشی (Knowledge Work) گیج‌کننده‌ترین بخش است. زمان تحویل، مدت‌زمانی است که از لحظه تعهد کاری به صف انجام آن تا تکمیل آن سپری شده است.
بیایید دوباره به مثال کافی‌شاپ بازگردیم. زمانی که وارد کافی‌شاپ می‌شوید، به صف متعهد شده‌اید. مدت‌زمان کلی از لحظه ورود شما به کافی‌شاپ تا لحظه خروج با یک فلت‌وایت (Flat White) خوشمزه همان زمان تحویل است.
ممکن است فکر کنید، «خب، احتمالاً زمان زیادی منتظر می‌مانم تا به صندوق برسم و زمان چرخه من شروع شود!» درست است. نکته جالب این است که در کارهای استاندارد (Standard Work) می‌توان پیش‌بینی کرد که چقدر در صف منتظر خواهید بود. این امر به دلیل وجود زمان چرخه میانگین است. فرض کنید آماده‌سازی هر فنجان قهوه حدود 1 دقیقه زمان می‌برد. بنابراین اگر 4 نفر جلوی شما باشند، این یعنی 4 نفر در حال کار هستند و شما می‌دانید که قهوه خود را در حدود 5 دقیقه (4 نفر + 1 نفر خودتان × 1 دقیقه) دریافت خواهید کرد.
شکل 2: توزیع نرمال، دنیای میانگین‌ها
برگردیم به مهندسی نرم‌افزار. کار معمولاً در “اسپرینت” (Sprint) متعهد می‌شود، بنابراین زمان تحویل از همان لحظه شروع می‌شود. اگر از کانبان (Kanban) استفاده می‌کنید و کار دائماً جابه‌جا نمی‌شود (صف پایدار)، زمان تحویل از لحظه تعهد کار به تخته کانبان شما اندازه‌گیری می‌شود.
مشکل اینجاست که در مهندسی نرم‌افزار زمان چرخه بی‌ثبات است و این باعث می‌شود پیش‌بینی کار کمتر قابل‌اعتماد باشد. شکل 1 نشان می‌دهد که حدود 25 درصد از درخواست‌های ویژگی در 2.5 روز، 50 درصد در 7 روز، 75 درصد در 10 روز و آخرین 25 درصد در 15 روز تحویل داده شده‌اند. به نظر می‌رسد که کارهای دستی (Craft Work) نمی‌توانند مانند کارهای استاندارد (شکل 2) به یک واحد زمانی میانگین استاندارد تبدیل شوند، و به همین دلیل قانون لیتل (Little’s Law) نمی‌تواند به‌صورت آماده استفاده شود.
تیم تولید دستی
سه عامل اصلی که زمان کاری شما را تشکیل می‌دهند:
- زمان انتظار: زمانی که منتظر اطلاعاتی هستید که ندارید، تصمیماتی که نمی‌توانید بگیرید و در نهایت منتظر اتمام کار دیگران قبل از شروع کار خود هستید.
- زمان اختلال: زمانی که باید کارهایی را با اولویت بالا انجام دهید، کارهای قبلی را بازبینی کنید، با اختلالات شرکتی روبرو شوید یا تأثیرات مربوط به سلامت روان را تجربه کنید.
- زمان وظیفه: در نهایت، این همان زمان خالصی است که صرف انجام کار می‌کنید، یعنی زمانی که واقعاً می‌نشینید و کار را انجام می‌دهید.
شکل 3: عواملی که کار شما را تشکیل می‌دهند
فرض کنید شما به‌تنهایی در حال کار روی یک استارت‌آپ هستید. در این صورت زمان انتظار و اختلال شما بسیار کم خواهد بود. شما تنها هستید و می‌توانید تمام تصمیمات را بگیرید. همچنین اگر خوش‌شانس باشید و در محیطی آرام کار کنید، احتمالاً اختلالات بسیار کمی را تجربه خواهید کرد یا حتی هیچ اختلالی نخواهید داشت. کارها را سریع انجام می‌دهید، کاربران شما از شرکت شما شگفت‌زده می‌شوند و ویژگی‌های جدید دائماً ارائه می‌شوند. در این شرایط، شما در “سناریوی کار فردی” خود هستید.
این وضعیت زمانی تغییر می‌کند که اولین کارمند خود را در استارت‌آپ استخدام می‌کنید. در این لحظه شما یک سازمان ایجاد کرده‌اید، به این معنا که یک سیستم ایجاد کرده‌اید. در سیستم، کار دیگر توسط یک فرد انجام نمی‌شود، بلکه توسط افراد زیادی انجام می‌شود. شما به‌عنوان بنیان‌گذار احتمالاً تأثیر زیادی از استخدام این شخص جدید احساس نخواهید کرد (جز بار انتقال دانش)، اما اگر مراقب نباشید، کارمند جدید شما باید منتظر تصمیمات، اطلاعات و تخصیص وظایف شما بماند. زمان انتظار او افزایش می‌یابد، زیرا منتظر شماست و احتمالاً توسط شما دچار اختلال خواهد شد. شما ممکن است تعجب کنید که چرا او به‌اندازه شما کارآمد نیست. این می‌تواند به این دلیل باشد که او استقلال کافی برای تصمیم‌گیری ندارد، زیرا ارزش‌های شما را نمی‌داند، بنابراین نمی‌داند به نمایندگی از شما چه تصمیماتی بگیرد. یا شاید او وضوح کافی در مورد نتایج موردنظر ندارد. بیشتر افراد بنیان‌گذار نیستند؛ آنها کارمند هستند و گاهی “چارچوب تصمیم‌گیری” بنیان‌گذاران را نمی‌بینند.
شکل 4: نشان می‌دهد چگونه پویایی کار و زمان چرخه با ورود یک عضو تیم دیگر تغییر می‌کند.
تیم‌های تولید تخصصی مجزا
تصور کنید شرکت شما خیلی سریع رشد کرده است، اما هیچ فرآیند چابکی را دنبال نکرده و به‌جای آن، تیم‌ها بر اساس تخصص‌های مختلف به دپارتمان‌های جداگانه تقسیم شده‌اند. به‌عنوان‌مثال، توسعه‌دهندگان وب در یک دپارتمان هستند، توسعه‌دهندگان API در دپارتمان دیگر و همین‌طور ادامه دارد. هر دپارتمان لیست کارهای (backlog) خودش را دارد، که این به معنی زمان انتظار جداگانه برای هر دپارتمان است. علاوه بر این، تمام افراد با اختلالاتی مثل جلسات تیمی، درخواست‌های فوری و موارد مشابه روبرو می‌شوند و تحویل کارها بین دپارتمان‌ها نیز زیاد خواهد بود. همچنین، به دلیل سوءتفاهم‌ها، کارها ممکن است دوباره به مراحل قبلی برگردد. برخی این نوع سازمان را “مدیریت آبشاری” می‌نامند و ساختارش شبیه به این است:
شکل ۵، بهینه‌سازی بر اساس دپارتمان
اگر یک مشتری درخواست یک “ویژگی داغ A” را داشته باشد، برای رسیدن کار به مقصد نهایی در چنین سازمانی مدت زمان زیادی لازم است. زمان واقعی انجام کار ممکن است فقط ۱۲ ساعت باشد، اما به دلیل تمام زمان‌های انتظار و اختلالات، ممکن است تا یک ماه طول بکشد تا این ویژگی منتشر شود. تفاوت بزرگی بین یک ماه زمان تحویل و ۱۲ ساعت زمان واقعی کار وجود دارد. مشتری شما به ۱۲ ساعت زمان واقعی کار اهمیتی نمی‌دهد، بلکه فقط به این موضوع اهمیت می‌دهد که شما یک ماه زمان صرف کرده‌اید. به‌طور کلی، در چنین سازمانی، زمان تحویل بیشتر کارها بسیار بالا خواهد بود، پروژه‌های کمتری تکمیل می‌شوند، پروژه‌ها به ندرت به‌موقع اجرا می‌شوند و افراد احساس ناامیدی می‌کنند چون بیشتر وقت خود را صرف مقابله با مشکلات فوری می‌کنند.
تیم‌های تولید تخصصی متمرکز بر ارزش
حالا تصور کنید که بنیان‌گذار شرکت شما اهمیت زمان تحویل و چرخه کار را درک کرده و تلاش کرده است تا تا حد ممکن زمان‌های انتظار، اختلالات و زمان انجام کار را از فرآیند کلی حذف کند.
او تصمیم گرفته است که افراد را برای مدت زمانی محدود کنار هم قرار دهد تا ویژگی‌ها و پروژه‌های خاصی را تحویل دهند. این کار برای حذف تحویل‌های متعدد، کاهش نیاز به مدیریت پروژه، حذف تعارض‌های داخلی، کاهش انتظار برای تصمیم‌گیری، و کاهش وابستگی‌های دانشی و سازمانی انجام شده است. در این مدل، تیم به صورت متمرکز روی یک داستان در یک زمان کار می‌کند (تا حد امکان) و هدف اصلی آنها این است که آن داستان را هرچه سریع‌تر از سیستم عبور دهند.
داستانی که در سیستم قبلی یک ماه طول می‌کشید تا تحویل داده شود، در این سیستم جدید در ۱۲ ساعت یا حتی کمتر تحویل داده خواهد شد. این امر به این دلیل است که تمامی زمان‌های انتظار، اختلالات (مدیر تیم و صاحبان محصول نقش محافظ دارند) حذف شده‌اند و به دلیل تمرکز تیم، آنها می‌توانند ناشناخته‌ها را سریع‌تر آشکار کنند، پیچیدگی‌ها را مدیریت کنند، تجربیات خود را به اشتراک بگذارند و بار کاری را تقسیم کنند تا کار را سریع‌تر تحویل دهند. ساختار این مدل شبیه به این خواهد بود:
شکل ۶، بهینه‌سازی بر اساس کار و نه دپارتمان
نتیجه‌گیری و پیامدها
اکنون می‌دانیم که زمان تحویل و چرخه کار شامل زمان‌های انتظار، اختلالات و زمان واقعی انجام کار است و تمامی این عوامل با کار تیمی دپارتمانی تشدید می‌شوند.
زمان تحویل و چرخه کار چیزی را به ما می‌دهد که روش‌های چابک به‌تنهایی ارائه نمی‌کنند: امکان اجرای آزمایش‌ها و اندازه‌گیری نتایج واقعی بهره‌وری. این امکان وجود دارد که فرضیه‌ای مانند “نوشتن تست‌های واحد، زمان تحویل را کاهش می‌دهد اما زمان چرخه کار را افزایش می‌دهد” مطرح شود و این فرضیه را آزمایش کرد.
با استفاده از زمان تحویل و چرخه کار حتی می‌توان تأثیر منطقی یک تغییر پیشنهادی را آزمود و از تصمیمات مدیریتی اشتباه جلوگیری کرد. اگر تغییر به‌صورت منطقی قابل آزمایش نباشد، حداقل می‌توانید تأثیر آن را در زمانی که تغییرات نتیجه مطلوبی نداشتند اندازه‌گیری کنید. زمان تحویل و چرخه کار به مدیران یک چارچوب تصمیم‌گیری برای تغییرات فرآیند ارائه می‌دهد.