تقریباً همه استارتاپ‌ها یک مسیر مشابه را طی می‌کنند و در ابتدای راه فقط یک سؤال مهم وجود دارد:
«آیا اصلاً کسی حاضر است از محصول ما استفاده کند یا بابتش پول بدهد؟»
وقتی سؤال اصلی این باشد، طبیعی است که سرعت از هر چیز دیگری مهم‌تر شود. تیم‌ها سعی می‌کنند هرچه سریع‌تر محصول را به دست کاربر برسانند، بازخورد بگیرند و ببینند آیا در مسیر درستی هستند یا نه.
به همین خاطر معمولاً تصمیم‌هایی گرفته می‌شود مثل:
تست‌ها را بعداً می‌نویسیم.
فعلاً معماری خیلی ایده‌آل لازم نیست.
این بخش را بعداً Refactor می‌کنیم.
Deployment دستی هم فعلاً جواب می‌دهد.
مانیتورینگ را بعداً اضافه می‌کنیم.
اگر این تصمیم‌ها آگاهانه گرفته شوند، لزوماً اشتباه نیستند. اتفاقاً شاید تنها راهی باشند که یک استارتاپ بتواند قبل از تمام شدن سرمایه، به Product-Market Fit برسد.
مشکل از جایی شروع می‌شود که همان تصمیم‌های موقتی، سال‌ها در سیستم باقی بمانند و کسی هم سراغشان نرود.
وقتی صحبت از Tech Debt می‌شود، معمولاً اولین چیزی که به ذهن می‌رسد «کد بد» است.
اما بدهی فنی همیشه چیز بدی نیست.
فرض کنید با چند هفته میانبر زدن می‌توانید محصول را یک ماه زودتر منتشر کنید و همین باعث شود اولین مشتری یا اولین سرمایه‌گذار را جذب کنید. در چنین شرایطی، احتمالاً این معامله ارزشش را دارد.
در واقع شما آگاهانه کیفیت را با سرعت معامله کرده‌اید تا شانس موفقیت کسب‌وکار بیشتر شود.
پس خود بدهی فنی مشکل نیست؛ مشکل زمانی است که هیچ برنامه‌ای برای بازپرداخت آن نداشته باشیم.
یکی از نکات مهم مقاله همین است. خیلی وقت‌ها هر مشکلی که در تیم پیش می‌آید را به حساب بدهی فنی می‌گذاریم.
سرعت توسعه کم شده؟ Tech Debt.
فیچرها دیر آماده می‌شوند؟ Tech Debt.
اما همیشه اینطور نیست و ممکن است مشکل اصلی چیز دیگری باشد؛ مثلاً:
زیرساخت هنوز برای این حجم از کاربران طراحی نشده باشد.
Deployment کاملاً دستی باشد.
مانیتورینگ مناسبی نداشته باشیم.
هنوز CI/CD راه‌اندازی نشده باشد.
یا محصول آن‌قدر بزرگ شده باشد که به قابلیت‌های جدیدی نیاز داشته باشد.
قبل از اینکه تصمیم بگیریم سیستم را بازنویسی کنیم، باید مطمئن شویم واقعاً با بدهی فنی طرف هستیم، نه صرفاً نیازهای جدید یک محصول در حال رشد.
من بدهی فنی را فقط محدود به کیفیت کد نمی‌دانم و چند دسته مختلف برای آن معرفی می‌کنم.
کدی که تغییر دادنش سخت شده، خوانایی پایینی دارد یا تست مناسبی برای آن وجود ندارد.
معماری‌ای که زمانی برای یک تیم کوچک مناسب بوده، حالا دیگر پاسخگوی رشد محصول نیست و هر تغییر کوچکی روی بخش‌های مختلف سیستم اثر می‌گذارد.
کمبود ابزارهایی مثل CI/CD، مانیتورینگ، اتوماسیون یا محیط‌های توسعه استاندارد که باعث کند شدن کار تیم می‌شوند.
کارهایی که هنوز به صورت دستی انجام می‌شوند؛ از انتشار نسخه گرفته تا مدیریت Incidentها و بازیابی سرویس‌ها.
داشتن بدهی فنی به معنی این نیست که باید فوراً همه چیز را Refactor کنیم.
سؤال مهم‌تر این است:
آیا این بدهی دارد روی کسب‌وکار اثر می‌گذارد یا نه؟
اگر پاسخ مثبت باشد، وقت سرمایه‌گذاری روی آن رسیده است.
یکی از معیارهایی باید روی آن تاکید کرد Value Lead Time است.
یعنی از زمانی که تصمیم می‌گیریم یک قابلیت جدید بسازیم تا وقتی که آن قابلیت به دست کاربر می‌رسد، چقدر زمان می‌گذرد.
اگر این زمان مدام بیشتر می‌شود، احتمال زیادی وجود دارد که بدهی فنی یکی از دلایل آن باشد.
اگر برای اضافه کردن یک تغییر کوچک مجبور باشید چندین سرویس را تغییر دهید یا همیشه نگران خراب شدن بخش‌های دیگر باشید، احتمالاً سیستم دارد هزینه بدهی فنی را از شما می‌گیرد.
باگ‌های بیشتر، قطعی‌های مکرر یا کاهش Performance فقط مشکل تیم فنی نیست؛ این‌ها مستقیماً روی تجربه کاربر و حتی درآمد کسب‌وکار اثر می‌گذارند.
اگر یک توسعه‌دهنده جدید چند هفته یا حتی چند ماه زمان نیاز داشته باشد تا بتواند اولین تغییر مفیدش را انجام دهد، این هم می‌تواند یکی از نشانه‌های پیچیدگی بیش از حد سیستم باشد.
وقتی جمله‌هایی مثل این زیاد شنیده می‌شود:
«به این قسمت دست نزن.»
«کسی نمی‌داند این کد دقیقاً چه کار می‌کند.»
«اگر اینجا را تغییر دهیم احتمالاً جای دیگری خراب می‌شود.»
یعنی اعتماد تیم به سیستم از بین رفته است و همین موضوع سرعت توسعه را به شدت کاهش می‌دهد.
یکی از مهم‌ترین نکته ها این است که کاهش بدهی فنی هم باید مثل توسعه یک فیچر مدیریت شود.
یعنی به جای اینکه فقط بگوییم:
«می‌خواهیم کدها را تمیز کنیم.»
باید بتوانیم توضیح دهیم:
این تغییر چه مشکلی را حل می‌کند؟
چه شاخصی را بهتر می‌کند؟
چه هزینه‌ای را کاهش می‌دهد؟
چه ارزشی برای کسب‌وکار ایجاد می‌کند؟
مدیر محصول یا مدیر کسب‌وکار معمولاً با اصطلاحاتی مثل Coupling یا Architecture Debt تصمیم نمی‌گیرد.
اما اگر بگویید:
انتشار نسخه از دو ساعت به پانزده دقیقه می‌رسد.
سرعت توسعه بیشتر می‌شود.
احتمال رخ دادن Incident کاهش پیدا می‌کند.
آن وقت تصمیم‌گیری خیلی ساده‌تر خواهد بود.
وقتی بدهی فنی زیاد می‌شود، اولین پیشنهادی که مطرح می‌شود این است:
«بیایید همه چیز را از اول بنویسیم.»
این تصمیم، در بیشتر مواقع، هزینه زیادی دارد و ممکن است ماه‌ها طول بکشد بدون اینکه ارزشی برای کاربر ایجاد شود.
در عوض پیشنهاد می‌کند سیستم به صورت تدریجی و هم‌زمان با توسعه محصول بهتر شود.
همان قانونی که به Scout Rule معروف است:
هر بار که روی بخشی از سیستم کار می‌کنی، سعی کن آن را کمی بهتر از قبل تحویل بدهی.
همه بدهی‌های فنی ارزش یکسانی ندارند.
لازم نیست لیست بلندبالایی از مشکلات تهیه کنید و بخواهید همه را یکجا حل کنید.
بهتر است از خودتان بپرسید:
امروز بزرگ‌ترین مانع رشد محصول چیست؟
همان را حل کنید و بعد سراغ مورد بعدی بروید.
بدهی فنی بخشی طبیعی از مسیر رشد هر استارتاپ است.
حتی گاهی وجود آن نشانه این است که تیم توانسته با سرعت بالا حرکت کند و محصول را به بازار برساند. اما اگر این بدهی مدیریت نشود، کم‌کم تبدیل به گلوگاهی می‌شود که سرعت توسعه را کاهش می‌دهد، کیفیت محصول را پایین می‌آورد و رشد کسب‌وکار را محدود می‌کند.
شاید مهم‌ترین پیام این مقاله همین باشد:
بدهی فنی دشمن ما نیست؛ بدهی فنیِ مدیریت‌نشده است که به بزرگ‌ترین مانع رشد تبدیل می‌شود.
این مقاله با الهام و بازنویسی از مقاله زیر نوشته شده است:
Bottlenecks of Scaleups #1: Tech Debt نوشته Martin Fowler و Tim Cochran و Carl Nygard
https://martinfowler.com/articles/bottlenecks-of-scaleups/01-tech-debt.html
