چند هفته پیش، کاربری در ردیت (انجمن r/Entrepreneur) پستی منتشر کرد که خیلی زود بین بنیانگذاران وایرال شد.
او میر آویمِلِک داویدوف است، مدیرعامل شرکت Gliltech Software، که طی سه سال گذشته کارش ممیزی کد استارتاپهای در آستانهی سقوط بوده است. او اعلام کرد که استارتاپها وقتی اوضاع بههم میریزد سراغ من میآیند — نه وقتی پولشان تمام میشود، بلکه وقتی محصولشان دیگر قابل توسعه نیست و هیچکس نمیداند چرا.»
او تا امروز کدبیس ۴۷ استارتاپ شکستخورده را بررسی کرده و به نتایجی رسیده که هر مؤسس فنی باید با ماژیک روی دیوار بنویسد.
الگویی که مدام تکرار میشود
طبق مشاهدات داویدوف، تقریباً همهی این استارتاپها مسیر مشابهی را طی کردهاند. در شش ماه اول، اوضاع خوب است: تیم سریع حرکت میکند، کاربران افزایش مییابند و رشد حس میشود. از ماه ششم تا دوازدهم، باگها شروع به ظاهر شدن میکنند، اما تیم با ذهنیت «بعداً درستش میکنیم» از کنار آنها میگذرد.
در ماههای سیزدهم تا هجدهم، اضافه کردن هر ویژگی جدید باعث میشود ویژگیهای قبلی بشکند. و تا ماه نوزدهم، چند مهندس تازه برای «حفظ سیستم» استخدام میشوند، اما دیگر خبری از توسعهی نوآورانه نیست. تا ماه بیستوپنجم، تیم یا پروژه را تعطیل میکند، یا تصمیم میگیرد از صفر بازنویسی کند.
داویدوف میگوید دلیل اصلی این فروپاشیها نه کمبود پول است، نه ضعف در جذب کاربر؛ بلکه بیتوجهی به معماری نرمافزار از همان روز اول. دادههای بهدستآمده از ممیزی او نشان میدهد:
- ۸۹ درصد از استارتاپها کدبیس خود را ایندکس نکردهاند، که منجر به کاهش چشمگیر سرعت سیستم شده است.
- ۶۸ درصد دارای حفرههای امنیتی بودهاند.
- ۹۱ درصد تست خودکار (automated testing) نداشتهاند.
- ۷۶ درصد از زیرساخت خود بهطور ناکارآمد استفاده کردهاند.
میانگین بهرهوری سرورها تنها ۱۳ درصد بوده است و این یعنی بسیاری از استارتاپها برای ۱۰۰ سرور هزینه پرداخت میکردند، اما فقط از ۱۳ مورد استفاده میکردند. نتیجه: ماهانه بین ۳ تا ۱۵ هزار دلار هزینهی بیثمر.
دو هفته طراحی برای نجات هجده ماه آینده
به گفتهی داویدوف، تنها دو هفته تمرکز بر طراحی معماری قبل از شروع کدنویسی میتواند از هجده ماه بحران در آینده جلوگیری کند. او معتقد است که پایهگذاری درست، هرچند کسلکننده و غیرهیجانانگیز، همان چیزی است که آیندهی فنی تیم را تعیین میکند.
او توصیه میکند که بنیانگذاران فنی پیش از نوشتن اولین خط کد، به چند پرسش کلیدی پاسخ دهند:
مهندس بودن کافی نیست
داویدوف در ادامه میگوید:
- اگر کاربران ۱۰ برابر شوند، چه چیزی در سیستم میشکند؟
- آیا تست خودکار برای بخشهای اصلی محصول وجود دارد؟
- آیا دیتابیس میتواند ۱۰۰ برابر بار کاری را تحمل کند؟
- در صورت رشد کاربران، آیا هزینهی زیرساخت از کنترل خارج نمیشود؟
«بیشتر هممؤسسان فنی و مهندسان اولیه در کدنویسی عالیاند، اما هیچوقت چیزی نساختهاند که واقعاً مقیاس بگیرد.
مثل یک آشپز فوقالعاده هستید که هرگز وسط شلوغی شام در رستوران واقعی کار نکرده است.»
این تفاوت ظریف اما حیاتی است. مهندس بودن بهتنهایی تضمین نمیکند که محصول بتواند در برابر رشد کاربران یا پیچیدگیهای آینده دوام بیاورد. معماری درست، همان جایی است که یک تیم فنی از حالت واکنشی به حالت پیشنگرانه میرسد.
بیشتر بنیانگذاران در ابتدای مسیر، انرژی خود را صرف بازار، جذب سرمایه و بازاریابی میکنند. اما زیربنای فنی، همان ستون نامرئی است که همهی این تلاشها روی آن قرار دارد. بدون آن، حتی قویترین تیمها نیز در برابر فشار رشد از هم میپاشند.
طراحی معماری درست، کاری استراتژیک است، نه فنی صرف. دو هفته سرمایهگذاری در شروع مسیر میتواند مانع از هجده ماه بحران، هزینهی اضافی و توقف رشد در آینده شود. در نهایت، پایداری محصول همانقدر اهمیت دارد که سرعت رشد آن.