بدهی فنی Technical Debt چیست؟
بدهی فنی Technical Debt مفهوم جالبی است که طی چند سال گذشته سرتیتر اصلی رسانه‌ها و مورد توجه مدیران پروژه قرار گرفته است. چرا که به یک موضوع فراگیر در کل اکوسیستم پروژه نرم افزاری تبدیل شده است.
بدهی فنی Technical Debt یک اصطلاح مالی به نظر می‌رسد. وقتی صحبت از توسعه نرم افزار می‌شود، بدهی فنی ایده‌ای است که برخی شرکت‌های توسعه‌دهنده نرم افزار از آن استفاده می‌کنند و برخی کارهای غیر ضروری در طول توسعه یک پروژه نرم افزاری به تاخیر می‌افتد تا به زمان تحویل برسد.
عبارت بدهی فنی را وارد کانینگهام برای اولین بار مطرح کرد. او این عبارت را زمانی به کار برد که می‌خواست به ذی‌نفعان غیرفنی درگیر در پروژه اهمیت بودجه‌بندی منابع موجود برای اصلاحات اینده کد را توضیح دهد. کانینگهام نمی‌دانست که این عبارت تبدیل به یک واژه مصطلح در عالم برنامه نویسی خواهد شد و بعد‌ها برای توضیح این که چرا لغت بدهی را استفاده کرد گفت:
من فکر می کردم وام گرفتن ایده خوبی است ، من فکر کردم که سریع کردن توسعه نرم افزار برای دستیابی به تجربه ایده خوبی است.اما در نهایت شما به عقب بر می‌گردید و چون چیزهای زیادی در مورد نرم‌افزار آموخته‌اید سعی می‌کند بدهی خود را با ریفکتور کردن برنامه پرداخت کنید.به این صورت برنامه شما، بازتابی از تجاربی است که به دست آورده اید.با پول قرض گرفته شده می توانید کاری را زودتر از آنچه ممکن است انجام دهید اما سپس تا زمانی که این پول را پس ندهید ، سود پرداخت خواهید کرد.
پس تعریف ساده بدهی فنی چیست؟
مهم است که بدانید نوشتن کد بد با داشتن بدهی فنی بسیار متفاوت است. اگر نرم افزار خود را از نظر معماری ضعیف نوشته‌اید، بدهی فنی ندارید، نرم افزار بدی دارید.
اولیت بندی فیچرها با چه روشی انجام می‌شود؟
برای اولویت بندی بک لاگ محصول روش‌های مختلفی وجود دارد. یکی از رایج ترین و شناخته شده‌ترین تکنیک‌ها در دسته بندی نیازها و توقعات از یک خدمت و یا ابزار روش MoSCoW نام دارد.
عبارت مربوط به این اصل، مخفف 4 دسته اولویت در این روش است که در زیر به آن اشاره می‌کنیم:
- Must Have
- Should Have
- Could Have
- Won’t Have (At this time)
اولویت‌ها از نوع Must Have وجودشان الزامی است. بدون وجود آن‌ها محصول قابلیت استفاده ندارد و اهداف کسب و کار تامین نخواهد شد. بدون وجود این فیچرها، انتشار یا لانچ محصول با شکست رو به رو خواهد شد. به عنوان مثال در یک فروشگاه اینترنتی وجود درگاه پرداخت واجب است. بدون وجود درگاه عملا فروشگاه اینترنتی کاربردی نخواهد داشت.
اولویت‌ها از نوع Should Have به دسته‌ای اطلاق می‌شود که نیازمندی مهمی محسوب می‌شوند اما ضروری نیستند. نبود آن‌ها باعث نمی‌شود که محصول کنار گذاشته شود. به عنوان مثال در سایت فروشگاه اینترنتی دسته بندی کالا جزء مواردی است که نبودنش محصول را متوقف نمی‌کند. اما بودنش به موفقیت محصول کمک زیادی می‌کند.
اولویت‌ها از نوع Could Have وجودشان بیشتر یک ارزش افزوده است که در نهایت مزیت رقابتی محصول محسوب می‌شود. به عنوان مثال ارسال نوتیفیکیشن کالاهای تخفیف خورده در سایت برای مشتریان از این نوع اولویت‌ها می‌باشد.
الویت از نوع Won’t Have عملا وجودشان از پایین‌ترین درجه اهمیت برخوردار است و نبودشان ضرری نمی‌رساند. به عنوان مثال نمایش کالاهای مشابه در سایت فروشگاه اینترنتی از این نوع اولویت‌ها است.
در واقع در بدهی فنی توسعه دهندگان انجام فیچرها با اولویت پایین را به تاخیر می‌اندازند تا در به روز رسانی‌های بعدی آن را رفع کنند.
بدهی فنی Technical Debt خوب است یا بد؟
بدهی فنی نه خوب است نه بد.
شما می‌توانید با آن مانند بدهی مالی برخورد کنید. به راحتی می توان قربانی این تفکر شد که بدهی همیشه چیز بدی است، اما همیشه اینطور نیست. ما می‌توانیم با استفاده هوشمندانه از بدهی فنی، مشکلات را با نوآوری سریع‌تر حل کنیم. در واقع زمانی بدهی فنی به پروژه آسیب می‌رساند که این بدهی پرداخت نشود و توسعه دهنده در صدد تصحیح آن برنیاید.
استیو مک کانل نگرش دیگری به بدهی فنی دارد و آن را در بلند مدت یا کوتاه مدت طبقه بندی می‌کند. شما به یک وام مسکن در مقابل خرید با کارت اعتباری یک ماهه فکر کنید. یک نوع بدهی استراتژیک بلند مدت می‌تواند تصمیمی برای حمایت از یک پلتفرم باشد.
برای 2تا 3 سال آینده، کسب و کار فقط از پلتفرم فعلی استفاده می‌کند و نیازی به پیچیده کردن کارها با پشتیبانی از چندین پلتفرم نیست. این یک نوع بدهی بلند مدت خوب محسوب می‌شود زیرا در طول 3 سال با پرداخت سود بالا مواجه نخواهیم شد.
بدهی استراتژیک کوتاه مدت می‌تواند تصمیمی برای اضافه کردن سریع یک کد به منظور انتشار محصول و بازگشت و رفع آن بلافاصله پس از انتشار باشد. این کار مانند خرید اعتباری و سپس بازپرداخت موجودی در ماه آینده است.
بدهی‌های بد از نوع کوتاه مدت هستند بدون برنامه بازپرداخت. اینجاست که بسیاری از بدهی‌های کوتاه مدت به سرعت جمع می‌شوند و مانع پیشرفت محصول می‌شوند. از این نوع بدهی‌ها باید به هر قیمتی مانند کارت های اعتباری با بهره بالا اجتناب کرد.
زمان قرض گرفته در بدهی فنی را دیر یا زود باید پس بدهید، با بهره.
به وجود آمدن بدهی فنی در پروژه اجتناب ناپذیر است. در واقع شما هیچ پروژه‌ی بزرگی را نمی‌توانید پیدا کنید که در آن بدهی فنی وجود نداشته باشد. حتی زمانی که مایکروسافت نسخه ویندوز خود را منتشر کرد، سورس کدهای انتشار یافته به دلیل نامرتبی و بهینه نبودن، مورد تمسخر کابران در شبکه‌های اجتماعی قرار گرفت.
چرخه معیوب بدهی فنی در صورت عدم پرداخت
زمانی که تیم توسعه به دلیل فشار بیش از حد و عدم مدیریت نتواند بدهی خود را پرداخت کند، محصول غیرقابل نگهداری و یا به عبارتی توسعه دهندگان ناچار به بازنویسی محصول می‌شوند. اگر زمان درست برای بازپرداخت بدهی ایجاد نشود، بدهی‌ها روی هم تلنبار شده و طبیعتا پرداخت آن نیز سخت‌تر و در بعضی مواقع غیرقابل پرداخت می‌شود. اینجاست که عیار هر شرکت در توسعه محصول نرم افزاری مشخص می‌شود. اینکه بتوان از بدهی فنی به نفع سیستم به گونه‌ای استفاده کرد که نه صاحب بیزینس متضرر شود و نه شرکت توسعه دهنده.
در پایان
قرض گرفتن همیشه بد نیست. بسیاری از پروژه‌ها ممکن است بدون قرض گرفتن به سرانجام نرسند. یا انقدر دیر به بازار عرضه شوند که دیگر نایی برای ماندن در رقابت با نمونه‌های اولیه را نداشته باشند.
در شرکت نوژن به دلیل تحویل فاز به فاز پروژه‌ها و نیز نوشتن تست‌های مکرر برای محصول، این بدهی‌ها در هر فاز و یا هر به روز رسانی پرداخت می‌شود. به طبع بازپرداخت به موقع بدهی‌ها فاز‌های آینده در گسترش‌پذیری محصول و فرایند پشتیبانی را دیگر با مشکل مواجه نخواهد کرد.
در تیم های نرم افزاری که رویکرد فازبندی رایج است، کارفرما در هر فازبندی بخشی قابل ارائه یا دلیوری از پلتفرم خود را تحویل می‌گیرد. به این ترتیب فرایند تست نهایی نرم افزار آسان تر شده است. همچنین زمان مناسب برای پرداخت بدهی‌های فنی که در طول توسعه به وجود آمده، پیدا می‌شود.
