Technical Debt چیست و چگونه باید آن را در پروژه مدیریت کرد؟
هر میانبُر فنی شبیه چکی است که تاریخش را جلو میاندازیم؛ مبلغش پاک نمیشود، فقط موعدش عقب میافتد و بهره هم میگیرد. به مجموع این تصمیمهای کوچک و بزرگ، بدهی فنی (Technical Debt) میگویند: چیزی که در روز جمعشدنش حتی عاقلانه به نظر میرسد و سالها بعد، سرعت تیم را آرامآرام میخورد.
بدهی فنی یک خطای اخلاقی نیست و نشان تنبلی تیم هم نیست؛ پدیدهای ساختاری در مهندسی نرمافزار است که با فشار زمان، تغییر نیازمندیها و محدودیت دانش شکل میگیرد. به همین دلیل سؤال درست این نیست که «چرا بدهی داریم؟»؛ سؤال درست این است که «چطور آن را ثبت کنیم، اولویت بدهیم و برنامه بازپرداخت داشته باشیم؟»
بدهی فنی دقیقاً به چه چیزی گفته میشود؟
استعاره پایه از دنیای مالی میآید: برای تحویل سریعتر، از راهحل ناکامل یا موقتی استفاده میکنیم؛ این میانبُر، اصل بدهی است. بعد از آن، هر تغییری که باید روی همان بخش انجام شود، کمی سختتر و زمانبرتر میشود؛ این گرانشدن تدریجی، بهره بدهی است. وقتی بهره آنقدر بالا برود که هیچ بهسازی در توان تیم نباشد، بخشی از سیستم عملاً به منطقه ممنوعه تبدیل میشود: همه میدانند آنجا خرابی، اما هیچکس نمیخواهد دستش را ببرد.
باید تأکید کرد که بدهی فنی فقط «کد بد» نیست. تصمیم به ننوشتن تست، بهتعویقانداختن مستندسازی، انتخاب کتابخانهای که پشتیبانیاش رو به پایان است و حتی تأخیر در بازنگری معماری، همگی شکلهایی از یک پدیدهاند: خریدن سرعت امروز با پول سرعت فردا.
بدهی خواسته و ناخواسته
همه بدهیها از یک جنس نیستند و تفکیکشان برای مدیریت مهم است. نوع آگاهانه و حسابشده آنجاست که تیم میداند میانبُر میزند، چون فرصت بازار کوتاه است و این تصمیم با دلیل، مستند و همراه برنامه بازپرداخت ثبت میشود. نوع آگاهانه اما بیمحاسبه، همان «دیر وقت است، ولش کن» است که هیچ سندی و برنامهای پشتش نیست. نوع ناآگاهانه وقتی شکل میگیرد که تیم الگوی بهتری را نمیشناسد و بدون درک پیامد، بدهی میسازد. و نوع فرسایشی، بدهیای است که از تصمیم درستِ دیروز ساخته میشود: طراحیای که زمانی جواب میداد، با رشد محصول دیگر کفاف نمیدهد و بدون بازنگری، آرامآرام سد راه میشود.
پاسخ مدیریتی هر نوع متفاوت است: اولی یک تصمیم تجاری موجه است، دومی نشانه ضعف فرآیند، سومی نشانه شکاف دانش و چهارمی طبیعت محصولات زنده که به بازنگری دورهای نیاز دارد.
روند شکلگیری: بدهی چطور انباشته میشود؟
بدهی معمولاً با یک فشار زمانی شروع میشود: کمپین، قرارداد، نمایشگاه، مهلت قانونی. تیم دقایق را ذخیره میکند؛ تست نمینویسد، منطق قیمت را مستقیم داخل رابط کاربری جا میدهد و نامها را برای «فعلاً» ساده انتخاب میکند. تحویل انجام میشود، همه خوشحالاند و دفترچه بدهی هیچجا نوشته نمیشود.
بعد چرخه تکرار میشود. محصول میماند و رشد میکند، اما همان کدهای موقتی بهتدریج ستون فقرات میشوند. اعضای تیم عوض میشوند و کسی دلیل انتخابها را نمیداند. هر تغییر جدید باید از همان مسیرهای پیچخورده عبور کند و بهره بدهی شروع میشود: راهاندازی محیط توسعه طولانی است، رفع یک اشکال دو اشکال تازه میآورد و تستهای خودکار یا وجود ندارند یا کماعتمادند.
نکته مهم این است که هیچ لحظه فاجعهباریای در کار نیست؛ بدهی فنی با افت تدریجی خودش را نشان میدهد و همین باعث میشود تا وقتی گران شده، جدی گرفته نشود. به همین دلیل، شناختنش باید به نشانهها تکیه کند، نه به یک رویداد هشداردهنده.
وضعیت فعلی: نشانههای رسیدن بدهی به سطح بحرانی
- هر تغییر کوچک، چند ماژول ظاهراً بیربط را لمس میکند و دامنه اثر تغییرها پیشبینیناپذیر شده است.
- تخمین کارهای مشابه، دوره به دوره بزرگتر میشود بدون آنکه محصول واقعاً پیچیدهتر شده باشد.
- تیم از استقرار نسخه جدید نگران است و ترجیح میدهد تغییرات را جمع کند و یکجا منتشر کند.
- بخش بزرگی از ظرفیت هر دوره صرف رفع اشکالاتی میشود که ریشه در تصمیمهای قبلی دارند.
- افراد باتجربه از دستزدن به بخشهایی از سیستم طفره میروند و دانش نگهداشتن آن بخشها نزد یکدو نفر میماند.
مثال کاربردی: سبد خرید یک فروشگاه آنلاین
فرض کنید تیمی در آستانه یک کمپین فروش، برای فروشگاه آنلاین شرکت، محاسبه تخفیف را در دو هفته میسازد. فرصت طراحی لایه جدا نیست؛ قواعد تخفیف مستقیم در کد صفحه سبد جا داده میشود و چند حالت خاص، مثل ترکیب کد هدیه با تخفیف عضویت، با شرطهای تودرتو حل میشود. کمپین موفق است و آن روز، تصمیم هم منطقی و قابل دفاع بود.
دو سال بعد، تخفیف ستون اصلی کسبوکار شده است. هر قاعده جدید یعنی دستکاری همان شرطهای تودرتو، انتشار نسخه جدید و تست دستی چند سناریو با نگرانی از خرابی حالتهای دیگر. تیم متوجه میشود نیمی از زمان توسعه قابلیتهای تخفیف، صرف جنگیدن با کد قدیمی است؛ این همان بهره بدهی است که حالا صورتحسابش رسیده و برای مالک محصول باید قابل توضیح باشد.
مسیر درست از همینجا شروع میشود: ثبت بدهی بهعنوان یک آیتم واقعی با توضیح علت و اثر، و برنامه بازپرداخت مرحلهای، مثلاً استخراج موتور محاسبه تخفیف به ماژول مستقل با تستهای پوششدهنده، بدون توقف تحویل قابلیتهای جدید.
ثبت و اندازهگیری بدهی فنی
بدهیای که فقط در گفتوگوها زندگی میکند، پرداخت نمیشود. خانهاش باید مشخص باشد: یا آیتمهای مشخص در بکلاگ محصول با برچسب بدهی فنی، یا درج در ثبت ریسک وقتی اثرش روی تحویلها و کیفیت جدی است. شرح هر آیتم ساختار مشابه شرح ریسک دارد: چه چیزی میانبُر زده شد، چه هزینهای همین حالا تولید میکند و چرا الان مهم است. آیتمی که اثرش برای مالک محصول روشن نشده باشد، در اولویتبندی هرگز بالا نمیآید.
برای اندازهگیری هم لازم نیست اعداد تزئینی بسازید؛ نشانههای واقعی را دنبال کنید: زمان تحویل تغییرات مشابه در طول زمان، دفعات بازگشت باگ به یک ناحیه از کد، و زمانی که یک عضو تازه برای راهاندازی محیط و نخستین تغییر لازم دارد. این سه، بدون ابزار پیچیده، تصویر بدهی را برای جلسات برنامهریزی کافی میسازند.
اولویتبندی و بازپرداخت
هیچ تیمی بدهی را صفر نمیکند و نباید این را هدف گذاشت؛ هدف، مدیریت آگاهانه است. سه معیار برای اولویتبندی کاربردیاند: تکرار تماس، یعنی ناحیههایی که هر دوره به آنها دست میخورد جلو میافتند؛ ریسک خرابی، یعنی جایی که شکستش برای کاربر یا امنیت گران تمام میشود؛ و سد مسیر، یعنی کدی که رویهای که محصول میخواهد برود را قفل کرده است.
ابزارهای بازپرداخت هم متنوعاند: کنارگذاشتن بخش کوچکی از ظرفیت هر دوره برای بهسازی؛ قاعده پیشاهنگی (Boy Scout Rule) که میگوید هر کس هنگام کار با کد، آن را کمی مرتبتر تحویل بدهد؛ و بازنگریهای معماری دورهای برای تصمیمهای فرسایشی. مهم این است که هر بازپرداخت به کاهش هزینه آینده گره بخورد، نه به سلیقه زیباییشناسی؛ بهسازیای که چیزی را سریعتر یا کمریسکتر نمیکند، اولویت نیست، تزئین است.
خطاهای رایج در مدیریت بدهی فنی
- استفاده از اصطلاح بدهی فنی بهعنوان بهانه هر بازنویسی دلخواه؛ بدهی یعنی هزینه قابل توضیح، نه سلیقه شخصی.
- برنامه بازنویسی کامل و چندماهه که ارتباط با کسبوکار را قطع میکند؛ پرداخت مرحلهای همراه تحویل، پایدارتر است.
- ثبت آیتمهای بدهی بدون توضیح اثر؛ چیزی که هزینهاش روشن نشده، اولویت نمیگیرد.
- بهسازی بدون تست؛ پرداخت بدهی بدون شبکه ایمن، فقط جابهجایی ریسک است.
- انتظار رسیدن بدهی به صفر؛ هدف، جریان آگاهانه پرداخت و گرفتن بدهی است، نه پایان آن.
کاربرد عملی: گامهای شروع
- یک جلسه فهرستبرداری با تیم فنی برگزار کنید و بدهیهای شناختهشده را با علت و اثر بنویسید.
- هر مورد را با برچسب مشخص به بکلاگ منتقل کنید تا در اولویتبندی دورهای دیده شود.
- با مالک محصول روی سهم ثابتی از ظرفیت هر دوره برای بهسازی توافق کنید تا پرداختها برنامهای شود، نه ماجرایی.
- سه نشانه اندازهگیری، یعنی زمان تحویل، تکرار باگ در ناحیههای داغ و زمان راهاندازی محیط، را هر فصل مرور کنید.
- در پایان هر فصل فهرست بدهی را پاکسازی کنید: چه چیزی پرداخت شد، چه چیزی بیاثر شد و چه چیزی تازه شکل گرفته است.
جمعبندی: بدهی فنی نه دشمن است و نه سرنوشت محتوم؛ نتیجه طبیعی ساختن محصول در دنیای واقعی است. تیمی آن را مدیریت میکند که بدهیاش را دیده باشد، نوشته باشد و هر دوره، بخشی از ظرفیتش را برای بازپرداخت آگاهانه کنار گذاشته باشد.
نکات کلیدی این مقاله
- بدهی فنی ترکیبی از میانبُرهای آگاهانه، ناآگاهانه و فرسایشی است و فقط «کد بد» نیست.
- هر بدهی اصل و بهره دارد؛ بهره، همان گرانشدن تدریجی هر تغییر روی ناحیه بدهیدار است.
- نشانههای بحران، تدریجیاند: رشد تخمینها، ترس از استقرار و ماندگاری دانش در افراد محدود.
- ثبت بدهی با علت و اثر در بکلاگ یا ثبت ریسک، شرط دیدهشدن آن در اولویتبندی است.
- هدف، صفر کردن بدهی نیست؛ مدیریت آگاهانه با ظرفیت ثابت بهسازی و معیارهای تکرار تماس، ریسک خرابی و سد مسیر است.
سوالات متداول
آیا بدهی فنی همیشه بد است؟
نه. بدهی آگاهانه و حسابشده میتواند تصمیم درستی باشد؛ مثلاً برای رسیدن به یک فرصت بازار. مشکل از جایی شروع میشود که بدهی بیسند، بیبرنامه و بیبهره شکل بگیرد و بعداً هیچکس نداند چه چیزی، به چه قیمتی و تا کِی قرض گرفته شده است.
بدهی فنی با باگ چه تفاوتی دارد؟
باگ رفتاری است خلاف انتظار که باید اصلاح شود؛ بدهی فنی حالتی از کد و معماری است که شاید همین حالا درست کار میکند، اما تغییرهای آینده را گران و پرریسک میکند. به همین دلیل باگ به رفع فوری نیاز دارد، ولی بدهی به برنامه بازپرداخت.
چه کسی تصمیم میگیرد بدهی پرداخت شود؟
تشخیص و شرح بدهی با تیم فنی است و اولویتدادن به آن با مالک محصول؛ چون بازپرداخت بدهی یعنی جای یک قابلیت تازه، بهسازی. تصمیم پایدار زمانی گرفته میشود که هزینه امروز بدهی و هزینه نپرداختنش، به زبان اثر روی تحویل و کیفیت برای مالک محصول روشن شده باشد.
