بدهی فنی یا Technical Debt چیست؟
۴ دی ۱۳۹۹
تعریف ساده شده بدهی فنی را میتوان اقدامهایی دانست که تیم مهندسی برای تسریع در تحویل بخشی از پروژه انجام میدهد و اغلب باید در بازهی زمانی دیگری اصلاح شود، البته بهطور کلی هیچ تعریف فنی واحد و جامعی برای این اصطلاح وجود ندارد.
اصطلاح Technical Debt در ابتدا توسط یک توسعهدهنده نرمافزار با نام Ward Cunningham ابداع شد و ابداع این اصلاح برای توضیح چرایی بودجهبندی مجدد به ذینفعهای غیر فنی بود.
با دریافت وام میتوانید برخی کارها را زودتر از آنچه که انتظار میرود انجام دهید اما اقساط آن در بلند مدت شامل پرداخت سود آن پول نیز میشود. من فکر میکردم گرفتن وام و انتشار سریعتر نرمافزار برای کسب تجربه، ایدهی خوبی است اما باید توجه داشته باشید که پس از مدتی احتیاج میشود تا آموختهها و تجربههای جدید را در نرمافزار خود منعکس کنید.
بخشی از توضیحهای Cunningham برای ذینفعان پروژه
ضرورت بدهی فنی در چیست؟
بهطور معمول شرکتهای تازه وارد در ابتدای ورود به بازار بایستی محصول خود را تایید و اطمینان حاصل کنند که میتوانند بدون ساخت یک محصول کامل، مشتریان را جذب کنند. حال برای انجام این کار، سرعت عمل از اهمیت فوقالعادهای برخوردار است و اینجاست که تیم مهندسی باید عمده بدهیهای فنی را متقبل شود تا زمان ورود محصول به بازار کاهش پیدا کند.
البته بیشتر کمپانیها از این اصطلاح استفاده میکنند “Hack it for now, fix it later” به این معنی که فعلا اساس کار را انجام دهید و مشکلهای احتمالی را بعدا برطرف کنید زیرا رسیدن سریعتر محصول به مشتری میتواند تعداد مشتریان بیشتری را جذب کند اما فراموش نکنید که بدهی فنی عواقبی بههمراه دارد.
انواع بدهی فنی
در سطحی بالاتر میتوانید بدهیهای فنی را در دستههایی مانند code debt، design debt، infrastructure debt، testing debt و … قرار دهید اما ما در این بخش قصد داریم تا این موارد را در دستههای کلیتری بررسی کنیم و کمی درباره هرکدام از آنها توضیح دهیم:
بدهی فنی برنامهریزی شده
این مورد را میتوانیم تصمیم اتخاذ شده توسط تیم مهندسی بدانیم که نتیجه آن، رساندن سریعتر محصول به بازار و جذب مشتریان بیشتر است.
نحوه رسیدگی به بدهی فنی برنامهریزی شده
مدیر یا مدیران پروژه باید اطمینان حاصل کنند که بدهی فنی موجود در backlog را دنبال و به آنها رسیدگی کنند و تیم فروش باید از عواقب عدم رسیدن بهموقع محصول آگاه باشد. همچنین تمام تیم باید پاسخگو باشند تا این اطمینان حاصل شود که به بدهی فنی بهموقع رسیدگی میشود.
بدهی فنی ناخواسته
عموما این امر بهدلیل عدم درک درست از محصول یا ارتباط ضعیف در مشخص کردن اهداف تجاری یا حتی استفاده از روشهای ضعیف مهندسی رخ میدهد.
نحوه رسیدگی به بدهی فنی ناخواسته
مدیر یا مدیران فنی بایستی اهداف تجاری مورد نظر خود را بهخوبی به تیم توسعه تفهیم کنند و اعتبارسنجی نرمافزار ساخته شده مکررا انجام شود و لحظه به لحظه بازخوردهای محصول گرفته شود.
بدهی فنی اجتناب ناپذیر
هنگامی که تغییری بزرگ در اواسط پروژه ایجاد شود یا حتی محوریت کامل پروژه تغییر کند، منجر به ایجاد بدهی فنی اجتناب ناپذیر میشود.
نحوه رسیدگی به بدهی فنی اجتناب ناپذیر
بهطور معمول رسیدگی به این مورد از همه سختتر است و در این مرحله است که معمولا بودجهبندی مجددا انجام میشود. مثلا ممکن است در اواسط پروژه چه از طرف تیم توسعه، چه از طرف صاحبان پروژه درخواست شود که کتابخانه React با فریمورک Vue جایگزین شود. درنهایت این مسائل باعث ایجاد تغییرهایی اساسی در فازهای توسعهی محصول میشوند.
آیا بدهی فنی بد است؟
جواب کاملا مشخصی برای این سوال وجود ندارد زیرا در مواقع مختلف میتواند پاسخهای متفاوتی دریافت کند. بهعنوان مثال در مراحل اولیه داشتن بدهی فنی خوب است زیرا منجر به رسیدن سریعتر محصول به کاربران نهایی میشود. بااینحال با بالغ شدن محصول، بازپرداخت بدهی فنی برای اطمینان از ثبات محصول ضروری است و این مورد با بیشتر شدن کاربرانی که از محصول استفاده میکنند، مقیاسبندی میشود.
یک نکته مهم دیگر این است که افراد تا زمانی که بدهی فنی مشکلی ایجاد نکرده، آن را نادیده میگیرند و این مورد میتواند از بدهی مالی ضرر بیشتری وارد کند. بههمین دلیل نیاز است تا عواقب بدهی فنی برای همهی ذینفعان توضیح داده شود و این اطمینان حاصل شود که مسئولیت و پاسخگویی بین تیمهای مهندسی و تیمهای فروش تقسیم شده باشد.
جمعبندی
بهطور خلاصه، بدهی فنی را میتوان بخشی از توسعه نرمافزار دانست که خواسته یا ناخواسته به دلیل ضرورتهایی شبیه به محدودیت زمان تحویل پروژه میتواند رخ دهد و بر موارد اجرایی فنی و ملاحظههای طراحی اولویت پیدا میکند. البته نباید بدهی فنی را با بینظمی اشتباه بگیرید زیرا بینظمی و آشفتگی بهدلیل تنبلی و غیر حرفهای بودن بهوجود میآید که درنتیجه باعث میشود نتوانید از پس بدهیهای فنی بربیایید.
توسعهدهندگان دربارهی ما چه میگویند
تجربه کار باliara_cloud@امروز خیلی خوب بود. یکی از سرویس هام رو منتقل کردم روش و راضیم. انقد سریع و جذاب کارم راه افتادم اصن باورم نمیشد! برعکس سرویس های PaaS دیگه با اون همه پیچیدگیشون. دمتون گرم
...
MohammadReza
keikaavousi
بعد از بسته شدن @fandoghpaas و ناراحتی همهمون از اینکه یه سرویس خوب و صادق نمیتونه از پس هزینهها بر بیاد، سرویسم رو منتقل کردم به پاس لیارا (https://liara.ir @liara_cloud) . تجربه راحت و خوب. تفاوتهایی داشت که کمی کار میخواست ولی تا الان کاملا راضی.
jadi
jadi
یه خسته نباشید باید به تصمیمliara_cloud@بگم،
بعد از چندین روز سرکله زدن با سرویس های مشابه بالاخره تصمیم گرفتم لیارا رو امتحان کنم و باور نمیشه ۱۰ دقیقه بیشتر وقت نبرد،
دمتون گرم.
Arch
EbadiDev
واسه سرویس PaaS با اختلاف لیارا بهترین رابط کاربری داره و یکی از مزیتهای سرویس دیتابیسشون اینه که خودشون به صورت دورهای بکآپ میگیرن.
...
Ali Najafi
me_ali_najafi
یکی از کارهای خوبی که جدیداً میکنم اینه که یه دیتابیس روی لیارا میسازم و به پروژه وصل میکنم اینطوری هم خونه و هم محل کار دیتابیس بروز رو دارم و راحت میتونم ادامه بدم کار روliara_cloud@
Navid
1navid
عاشقliara_cloud@شدم درسته در حد AWS نیست ولی خب تجربه خوبی واسه پروژه های داخل ایران ارائه میده، میتونم رو CD هم اجراش کنم
Amir H Shekari
vanenshi