در اینجا آمده است که چگونه استارتاپ ها می توانند از انباشته شدن بدهی های فناوری جلوگیری کنند – TechCrunch

در سال 1992، وارد کانینگهام استعاره «بدهی فنی» را ابداع کرد تا نشان دهد که چگونه کسبوکارها سود کوتاهمدت خود را در برابر ماندگاری بلندمدت یک محصول نرمافزاری ارزیابی میکنند. پویایی کسب و کار از آن زمان تا کنون بسیار تکامل یافته است، اما این استعاره هنوز کار می کند.
ترجیح دادن یک برنامه کوتاه مدت برای دستیابی به گزینه ای سریع تر برای ورود به بازار همیشه بد نیست، مشروط بر اینکه کسب و کار یک برنامه پشتیبان برای ارائه کدهایی با طراحی خوب داشته باشد که تکرارها و نوآوری های آینده را ساده کند.
اما برای استارتآپها، کار مجدد دشوار است، زیرا ضربالاجلها و کمبود منابع مانع از تولید کد تمیز و بینقص توسط توسعهدهندگان میشود. استارتآپها برنامههای کوتاهمدت را اولویتبندی میکنند و بیشتر بر روی افزودن قابلیتها برای دستیابی به نقاط عطف، ثبت نام مشتریان خیمه شب بازی یا جمعآوری بودجه تمرکز میکنند. این به هم ریختن نقشه راه و بی توجهی به دیدگاه بلندمدت باعث بدهی های فناوری می شود.
من از نزدیک با بیش از 25 استارت آپ کار کرده ام و از سفر آنها از مرحله اولیه تا مرحله رشد چیزهای زیادی یاد گرفته ام. من متوجه شده ام که اجتناب از بدهی های فناوری با برخی قوانین اساسی آسان تر می شود.
در اینجا چهار قانون وجود دارد که استارت آپ ها باید برای جلوگیری از بدهی های فناوری از آنها پیروی کنند:
اجازه ندهید پیاده سازی های خاص بیش از سه ماه ادامه داشته باشد
استارتآپها اغلب سعی میکنند محصول خود را سفارشی کنند تا خواستههای مشتریان خیمه شب بازی خود را برآورده کنند. گاهی اوقات این منجر به دو محصول می شود – یک نسخه تعمیم یافته و یک نسخه خاص مشتری، و همگرایی آنها در طول زمان دشوار می شود.
برای ادامه مسیر، شرکتها شروع به کوتاهکردن میکنند که باعث بیثباتی محصول میشود. من دیده ام که تیم های مهندسی برای یک سال کامل روی سفارشی سازی کار می کنند و سپس 20 ماه را در ادغام و تثبیت محصول اصلی از دست می دهند.
اساس هر محصول نرم افزاری مستقیماً مسئول مقیاس پذیری و نگهداری بهتر است.
استارتآپها معمولاً قبل از افزایش سطح بعدی بودجه، با یک باند 18 تا 24 ماهه کار میکنند. اگر آنها برای تعمیم ویژگی ها دوباره کار کنند، ممکن است یک سه ماهه پرهزینه را برای تثبیت از دست بدهند.
چه باید کرد:
وقتی تیمها روی ویژگیهای سفارشی بیش از جدول زمانی مشخص کار میکنند، ادغام مجدد آنها با محصول اصلی پیچیده میشود. بهتر است اذعان کنیم که محصولات در همان ابتدا نمی توانند خاص مشتری باشند. استارتآپها باید پلتفرم را در نظر بگیرند و در مورد قابلیت نگهداری آینده فکر کنند.