زمانی که حین تولید نرم افزار بنا به هر دلیلی، شما بجای اینکه کار درست و اصولی رو انجام بدید رو انجام نمیدید و میرید سراغ کار سریع تر و راحت تر، به دلیل اینکه میخواهید زودتر پروژه به نتیجه برسه. این کار یک هزینه ای داره که بهش بدهی فنی میگویند. به‌طور معمول شرکت‌های تازه وارد در ابتدای ورود به بازار بایستی محصول خود را تایید و اطمینان حاصل کنند که می‌توانند بدون ساخت یک محصول کامل، مشتریان را جذب کنند. حال برای انجام این کار، سرعت عمل از اهمیت فوق‌العاده‌ای برخوردار است و اینجاست که تیم مهندسی باید عمده بدهی‌های فنی را متقبل شود تا زمان ورود محصول به بازار کاهش پیدا کند.
البته بیشتر کمپانی‌ها از این اصطلاح استفاده میکنند “Hack it for now, fix it later” به این معنی که فعلا اساس کار را انجام دهید و مشکل‌های احتمالی را بعدا برطرف کنید زیرا رسیدن سریع‌تر محصول به مشتری می‌تواند تعداد مشتریان بیشتری را جذب کند اما فراموش نکنید که بدهی فنی عواقبی به‌همراه دارد.
اصطلاح Technical Debt توسط یک توسعه‌دهنده نرم‌افزار با نام Ward Cunningham مطرح شد و ابداع این اصلاح برای توضیح چرایی بودجه‌بندی مجدد به ذی‌نفع‌های غیر فنی بود.
با دریافت وام می‌توانید برخی کارها را زودتر از آنچه که انتظار می‌رود انجام دهید اما اقساط آن در بلند مدت شامل پرداخت سود آن پول نیز می‌شود. من فکر می‌کردم گرفتن وام و انتشار سریع‌تر نرم‌افزار برای کسب تجربه، ایده‌ی خوبی است اما باید توجه داشته باشید که پس از مدتی احتیاج می‌شود تا آموخته‌ها و تجربه‌های جدید را در نرم‌افزار خود منعکس کنید.
بخشی از توضیح‌های Cunningham برای ذی‌نفعان پروژه
فرض کنید شما عضو یک تیم فنی هستید، مدیر پروژه به واسطه فشار های مشتری، به شما میگه که من فیچر x رو تا یک ماه دیگه میخواهم. شما میدونید که اون فیچر در عرض یکماه انجام نمیشه و فرضا دو ماه زمان نیاز داره که انجام بشه، در نتیجه شما برای اینکه کار انجام بشه از یکسری از کارا که به کیفیت نرم افزار مرتبط هست، چشم پوشی می کنید. معمولا هم اولین چیزی که حذفش می کنند بحث تست نرم افزار هست!
موارد دیگه ای که میاییم انجام میدیم چیه؟ همین طور پشت سر هم کد بزنیم بدون اینکه ریفکتور کنیم و صرف نظر کردن از بهبود نرم افزار و پرفورمنس پروژه و فقط تلاش میکنیم که اون فیچر نوشته بشه و کار بکنه و به احتمال زیاد از معماری و دیزاین پترن ها هم بیخیال بشیم. یک کار دیگه ای هم که ممکنه انجام بدیم اینکه تند تند فیچر ها رو مینویسیم و یهو همه رو با هم در یک کامیت بدون توضیحات و مستندسازی پوش میکنیم. تنها و تنها ددلاین پروژه اولویت ماست که کار زودتر تموم بشه.
در ابتدای کار حتی ممکنه بدون تحقیق، تکنولوژی ای رو انتخاب کنیم و حساسیت بخرج ندیم و فرصت اینکار رو نداشته باشیم و فرضا هر چیزی که تیم دستش باز تر و مسلط ترهه همونو انتخاب کنیم و بریم توکارش!!!
همه این انتخاب ها پروژه رو در کوتاه مدت و در ددلاین مورد نظر ممکنه کار شما رو راه بندازه اما موقتی هست. حالا مشتری پروژه رو میبینه و از محصول استفاده میکنه و ممکنه یک رضایت نسبی هم داشته باشه ولی اتفاقی که رخ داده یک فاجعه ست و حتی ممکنه مشتری هم متوجه این موضوع نشه و فقط تیم فنی میدونه چ کاری کرده!!! :(
این مجموعه کارایی که شما برای اون پروژه انجام ندادید میشه بدهی فنی شما و باید در دراز مدت پرداختش کنید. بدهی شما باگی در سیستم بوجود نیاورده و حتی ممکنه مشتری هم متوجه ش نشده باشه. حالا سوال اینجاست، مقصر کیه؟ مشتری؟ مدیر پروژه؟ تیم فنی؟ عموما نمیشه همه ی تقصیر ها رو گردن یک نفر یا یک تیم انداخت چون همه به همون اندازه مسئول هستند.
در سطوح بالاتر می‌توانیم بدهی‌های فنی را در دسته‌هایی مانند code debt، design debt، infrastructure debt، testing debt و … قرار دهیم اما ما در این بخش قصد داریم تا این موارد را در دسته‌های کلی‌تری بررسی کنیم. یکی از رایج ترین ها ضعف دانش شما یا تیم فنی (Lack of Technical knowledge) هست و چون تیم از مهارت های فنی لازم برخوردار نیست، تا بتونه انتخاب ها و کار های درست رو انجام بده. مورد بعدی که باعث بدهی فنی میشه اینکه تیم فنی اعتقادی به نوشتن تست (Insufficient Testing) نداره! و بعضی ها فکر میکنند وقت کشیه یا بعدا واسش مینویسیم. البته امروز اکثرا تیم ها به اهمیت تست نوشتن آگاه اند و سعی میکنند تست بنویسند. تاخیر در ریفکتور کردن ( Delayed Refactoring) نیز از موارد دیگری هست که باعث بدهی فنی میشه. زمانی که پروژه تون رشد میکنه، نیاز دارید که یکسری از دیزاین پترن ها رو روش اعمال کنید و در دراز مدت چون این تاخیر ها زیاد شده و از طرفی هم حجم ریفکتور ها بالا رفته، کم کم تیم فنی بیخیال ریفکتور کردن میشه. فشار روانی و محدودیت زمانی نیز از مورد های تاثیر گذار بدهی فنی هست.
اگر شما وارد یک تیم فنی بشید که از اول پروژه نبودید، الان چطوری میخواهید متوجه بدهی فنی بشید؟
از روی نتیجه ای که پروژه به شما نشون میده، میتونید متوجه این موضوع بشید. حالا فرض کنید همون پروژه ای که بدهی فنی داره، بعد از یک مدتی مشتری از شما چند تا فیچر اضافه میخواد و شما تلاش میکنید که اونو حل کنید تا اینکه بجایی میرسید که پروژه قفل و قابل توسعه نیست و عملا دست و پای شما بسته شده. اینجاست که شما اثرات این بدهی فنی رو متوجه میشید. چون کد باکیفیت تحویل مشتری ندادیم، زمان توسعه فیچر بعدی نیز بیشتر از حد معمول میشه و کاملا تاثیرش رو بصورت زنجیروار در مراحل توسعه میزاره. در نتیجه خیلی از چیز ها فدا میشه و کلی زمان باید بزاریم که اون بدهی ها رو جبران کنیم.
توی این شرایط باید چیکار کنیم؟
اخلاقی ترین و منطقی ترین راه اینکه شفاف با مشتری صحبت کنیم و مشکلات پروژه رو باهاش در میان بزاریم درسته کار سختی هست اما بهای کم کاری هست که باید بپردازیم. در این حالت ممکنه مشتری شرایط رو درک کنه و از خواسته هاش کوتاه بیاد و به شما زمان بده که شما مشکلات رو حل کنید.
اولین کاری که میتونیم انجام بدیم، باید با توجه به ظرفیت تیم و دانش تیم، براساس این ها به مشتری قول بدید و برنامه ریزی واقع بینانه انجام بدید. همچنین میتونید از متدولوژی های نرم افزار مثل اسکرام و xp ... استفاده کنید و که بتونید پروژه رو به قسمت های کوچک تری تقسیم کنید و چابک تر نرم افزار رو توسعه بدید. تست نوشتن رو کنار نزارید و حتما براش تست بنویسید که با کیفیت مناسب تری به دست مشتری برسه.
البته با وجود رعایت اکثر موارد این نکته رو هم در نظر داشته باشید که بدهی فنی اجتناب ناپذیرهه و ممکنه بوجود بیاد اما سعی براین هست که بدهی فنی رو به حداقل برسونیم. البته شما و تیم باید حواس تون باشه که چه بدهی فنی رو در کجا ایجاد می کنید و در نزدیک ترین فرصت باید اون بدهی فنی رو تکمیل کنید. از طرفی تیم فنی همیشه در تلاش باشه که دانش فنی خودشون رو افزایش بدن و همچنین ایجاد یک ارتباط خوب و امن بین مشتری و مدیر پروژه و تیم فنی باعث میشه ریسک بوجود اومدن بدهی فنی کاهش پیدا کنه.
جواب کاملا مشخصی برای این سوال وجود نداره، در مواقع مختلف می‌تواند پاسخ‌های متفاوتی دریافت کند. به‌عنوان مثال در مراحل اولیه داشتن بدهی فنی خوبه، زیرا منجر به رسیدن سریع‌تر محصول به کاربران نهایی میشه. بااین‌حال با بالغ شدن محصول، بازپرداخت بدهی فنی برای اطمینان از ثبات محصول ضروری هست و این مورد با بیشتر شدن کاربرانی که از محصول استفاده میکنند، مقیاس‌بندی میشه.
یک نکته مهم دیگه اینه که افراد تا زمانی که، بدهی فنی مشکلی ایجاد نکرده، اون رو نادیده می‌گیرند و این مورد می‌تونه از بدهی مالی ضرر بیشتری وارد کنه. به‌همین دلیل نیازهه تا عواقب بدهی فنی برای همه‌ی ذی‌نفعان توضیح داده بشه و این اطمینان حاصل بشه که مسئولیت و پاسخگویی بین تیم‌های مهندسی و تیم‌های فروش تقسیم شده باشه.
برای نوشتن این مقاله از این لینک کمک گرفتم و امیدوارم از خوندن این مطلب چیزی یاد گرفته باشید. دوست داشتم که با شما هم به اشتراک بذارم. اگر دوست داشتید از طریق لینکدین باهام در تماس باشید یا اگر نظری دارید خوشحال میشم زیر همین پست بنویسید و به اشتراک بگذارید.
