چطور بدهی فنی را بدون کاهش سرعت توسعه محصول مدیریت کنیم؟
مدیریت بدهی فنی مانند نگهداری خانه‌ای است که در آن زندگی می‌کنید؛ ضروری است، اما نمی‌توانید همه چیز را متوقف کنید تا فقط به تعمیرات بپردازید. در این مقاله، رویکردهای عملی برای مدیریت بدهی فنی را بررسی خواهیم کرد، در حالی که اطمینان حاصل می‌کنیم که توسعه محصول با سرعت مناسب ادامه یابد.
هر خط کد با یک انتخاب همراه است: سریع حرکت کنید یا درست بسازید. بیشتر تیم‌ها سرعت را انتخاب می‌کنند، و دلیل خوبی هم دارند. فرصت‌های بازار منتظر کسی نمی‌مانند. بدهی فنی از این تصمیم‌های عجولانه که «بعداً درستش می‌کنیم» به شما کمک کرد به یک مهلت حساس برسید یا فرصتی در بازار را تصاحب کنید، انباشته می‌شود. اما درست مانند بدهی مالی، بدهی فنی نیز با گذشت زمان افزایش می‌یابد. هر اصلاح سریع و راه‌حل موقتی، بار بیشتری به پایگاه کد شما اضافه می‌کند تا جایی که روزی تیم شما خود را در وضعیتی می‌یابد که به جای دویدن، در گل و لای گرفتار شده است.
هنر واقعیريال اجتناب از بدهی فنی نیست، بلکه در مدیریت استراتژیک آن است. بهترین تیم‌های محصول یاد گرفته‌اند که این تعادل را حفظ کنند، به‌طوری که سرعت خود را حفظ کرده و در عین حال مانع از رسیدن بدهی فنی به حد بحرانی شود. بیایید بررسی کنیم که چگونه می‌توان این تعادل را به بهترین شکل ممکن برقرار کرد.
شناسایی و اولویت‌بندی بدهی فنی
همه بدهی‌های فنی یکسان نیستند. درست مانند بدهی مالی، بدهی خوب هم وجود دارد (مانند وام مسکنی که ارزش افزوده ایجاد می‌کند) و بدهی بد (مانند کارت‌های اعتباری با بهره بالا که از کنترل خارج می‌شوند). نکته کلیدی این است که بدانید کدام یک خوب است و کدام بد.
با تیم مهندسی خود کار کنید تا بدهی فنی را به سه دسته تقسیم کنید:
مسدودکننده‌های بحرانی
- سیستم احراز هویتی که با چسب و وصله سرپا نگه داشته شده است
- دیتابیسی که هر دو هفته به ۹۰٪ ظرفیت خود می‌رسد
- API شخص ثالثی که ممکن است هر لحظه غیرفعال شود
نگرانی‌های در حال رشد
- کمبود پوشش تست در ویژگی‌های اصلی
- یک مونولیت که به‌تدریج به‌روزرسانی آن سخت‌تر می‌شود
- مشکلات عملکردی که فقط کاربران حرفه‌ای را تحت تأثیر قرار می‌دهند
موارد قابل بهبود
- مستندات قدیمی
- تکرار جزئی در کد
- فریم‌ورک رابط کاربری که کمی از نسخه جدید عقب است
تمرکز خود را روی چیزی بگذارید که بازگشت سرمایه بیشتری داشته باشد. پایگاه کد نامرتبی که همچنان به‌طور قابل‌اعتمادی ارزش ارائه می‌دهد ممکن است کمتر از سیستمی تمیزی باشد که با ورود یک مشتری بزرگ ممکن است دچار مشکل شود.
ایجاد تعادل بین بدهی فنی و توسعه ویژگی‌ها
چالش همیشگی در توسعه محصول این نیست که آیا باید بدهی فنی را مدیریت کرد یا نه، بلکه این است که چقدر به آن زمان اختصاص می دهیم. از مثال قبلیِ نگهداری خانه‌ای که در آن زندگی می‌کنید استفاده کنیم: نمی‌توانید زندگی در خانه را متوقف کنید تا فقط به تعمیرات بپردازید، اما همچنین نمی‌توانید علائم هشدار را برای همیشه نادیده بگیرید. نقطه تعادل کجاست؟ بسیاری از تیم‌های موفق با استفاده از "قانون ۸۰/۲۰" به این پاسخ رسیده‌اند: ۲۰٪ از هر اسپرینت را به نگهداری سیستم اختصاص دهید، در حالی که ۸۰٪ انرژی خود را صرف توسعه ویژگی‌های جدید کنید.
این تنها یک عدد تصادفی نیست. بلکه درباره ایجاد یک ریتم پایدار است که در آن مدیریت بدهی فنی به اندازه جلسات روزانه استندآپ طبیعی شود. وقتی کاهش بدهی فنی را در جریان کاری منظم خود ادغام کنید، به‌جای اینکه آن را به‌عنوان مشکلی جداگانه ببینید، می‌توانید هم سرعت توسعه را حفظ کنید و هم پایگاه کد خود را سالم نگه دارید.
بیان ارزش تجاری مدیریت بدهی فنی
مدیریت بدهی فنی شبیه حفظ اعتبار نزد ذینفعان است. برای جلب حمایت آن‌ها باید به زبانشان صحبت کنید. در حالی که تیم مهندسی شما درگیر کدهای درهم‌وبرهم و وابستگی‌های قدیمی است، مدیران اجرایی فقط بر یک چیز تمرکز دارند: تأثیر تجاری. کلید کار چیست؟ تبدیل بدهی فنی از یک مشکل مهندسی به یک روایت تجاری.
تصویری ارائه دهید که نتوانند نادیده بگیرند:
- آن تأخیر سه‌ماهه در عرضه یک ویژگی؟ فقط به دلیل کد پیچیده نبود. بلکه به معنای از دست دادن ۲۰۰ هزار دلار درآمد بالقوه بود.
- اختلال اخیر در تولید؟ فقط تیم مهندسی را ناراحت نکرد. بلکه باعث از دست رفتن ۵۰ مشتری پریمیوم شد.
- انتشار سریع ویژگی‌ها توسط رقیب شما؟ فقط به دلیل اندازه تیمشان نیست. بلکه به دلیل داشتن یک پایگاه کد تمیزتر و قابل‌انطباق‌تر است.
وقتی بدهی فنی را به‌صورت فرصت‌های از دست‌رفته بازار، کاهش مشتریان، و مزیت رقابتی بیان کنید، ناگهان اسپرینت‌های بازسازی به جای آنکه به‌نظر افراط مهندسی بیایند، به سرمایه‌گذاری‌های استراتژیک تبدیل می‌شوند. نقش شما این است که این نقاط را به هم متصل کنید و نشان دهید چگونه بدهی فنی امروز می‌تواند به نقطه‌ضعف بازار فردا تبدیل شود.
فرهنگ بهبود مستمر ایجاد کنید
سلامت کد عالی، مانند عادات خوب، با تلاش‌های کوچک و مداوم روزانه ساخته می‌شود. این موضوع بیشتر به تصمیمات کوچک روزمره تیم شما مربوط است تا اسپرینت‌های cleanup قهرمانانه. تصمیماتی مانند نوشتن یک تست واحد اضافی، انجام یک بازسازی سریع هنگام توسعه ویژگی‌ها، یا بازبینی دقیق کدی که می‌تواند از مشکلات آینده جلوگیری کند.
محیطی ایجاد کنید که در آن کیفیت نه تنها ترویج شود، بلکه جشن گرفته شود:
کار درست را آسان کنید:
- بررسی‌های خودکار کیفیت کد برای شناسایی زودهنگام مشکلات
- الگوهایی برای الگوهای کد تمیز و یکپارچه
- مستنداتی شفاف که واقعاً به‌روز و قابل استفاده باشند
- دستورالعمل‌های بازبینی کد که بر قابلیت نگهداری تأکید دارند
پیروزی‌های نامرئی را جشن بگیرید:
- تقدیر از مهندسی که در حین افزودن ویژگی‌ها، کد را تمیز کرده است
- اشتراک‌گذاری آمار مربوط به کاهش نرخ باگ‌ها و تسریع در استقرار
- برجسته کردن اینکه چگونه کد تمیز امکان واکنش سریع‌تر به بازار را فراهم کرده است
- مستندسازی زمان صرفه‌جویی‌شده از طریق تلاش‌های بازسازی قبلی
این را مانند یک آشپزخانه حرفه‌ای در نظر بگیرید. بهترین سرآشپزها در حین آشپزی، محل کار خود را تمیز می‌کنند. آن‌ها صبر نمی‌کنند تا همه ظروف روی هم انباشته شوند، زیرا می‌دانند که یک ایستگاه تمیز، خروجی سریع‌تر، بهتر و قابل‌اعتمادتری به همراه دارد. پایگاه کد شما نیز شایسته همین احترام است.
استراتژی بلندمدت برای مدیریت بدهی فنی ایجاد کنید
مدیریت بدهی فنی را مانند یک باغ در نظر بگیرید، نه مانند تمیزکاری گاراژ. شما منتظر نمی‌مانید تا علف‌های هرز همه‌جا را فرا بگیرند، بلکه به‌طور منظم به آن رسیدگی می‌کنید و آن را به بخشی از ریتم روزانه خود تبدیل می کنید، نه یک بازسازی عظیم فصلی.
موفقیت در ایجاد یک سیستم مدیریت بدهی منظم و قابل اندازه‌گیری است:
ایجاد "مانیتورهای سلامت" که تیم شما به آن‌ها اهمیت می‌دهد:
- چقدر طول می‌کشد تا یک توسعه‌دهنده جدید را به پروژه وارد کنید؟
- نسبت کار برنامه‌ریزی‌شده به کار اضطراری شما چقدر است؟
- چقدر سریع می‌توانید یک اصلاحیه بحرانی ارسال کنید؟
- چقدر به‌طور مکرر همان بخش‌های کد خراب می‌شوند؟
ایجاد آیین‌هایی که پابرجا بمانند:
- بررسی‌های ماهانه رادار فنی با رهبران مهندسی شما
- "جمعه‌های تعمیر" که تیم‌ها در آن به بدهی فنی در مناطق بحرانی رسیدگی می‌کنند
- ارائه‌های فصلی "سلامت فنی" برای ذینفعان
- معیارهای کیفیت کد در بررسی‌های اسپرینت
هدف کمال نیست. هدف پیشرفت پایدار است. زمانی که مدیریت بدهی به‌طور روتین به اندازه استندآپ‌های روزانه شما شود، شما راه را پیدا کرده‌اید. خود آینده شما (و تیم شما) از شما تشکر خواهد کرد، زمانی که فرصت‌های بحرانی بازار به دلیل محدودیت‌های فنی به تنگنا نرسند.
مسیر پیش رو
بدهی فنی را مانند امتیاز اعتباری یک محصول در نظر بگیرید. همه آن را دارند، اما تیم‌های موفق می‌دانند چطور آن را سالم نگه دارند. موضوع این نیست که بدهی صفر داشته باشید؛ بلکه این است که تصمیمات استراتژیک بگیرید که محصول شما را چابک نگه دارد و تیم شما را انگیزه‌مند کند.
راز موفقیت؟ یک رویکرد سه‌قسمتی:
بدهی را قابل مشاهده کنید:
- آن را مانند ویژگی‌ها پیگیری کنید
- تأثیر آن را بر سرعت تحویل اندازه‌گیری کنید
- وقتی آن را پرداخت می‌کنید جشن بگیرید
جنگ‌های خود را انتخاب کنید:
- آنچه که بیشتر آسیب می‌زند را تعمیر کنید
- بدهی که مانع نوآوری است را حل کنید
- بهبودها را در کارهای ویژگی‌ها ترکیب کنید
عادات سالم بسازید:
- در حین کدنویسی تمیز کنید
- تأثیر بدهی را در بررسی‌های بازخورد (retrospectives) مرور کنید
- پیروزی‌ها و درس‌های آموخته‌شده را به اشتراک بگذارید
یادآوری: کمال فنی درباره‌ی کمال نیست. بلکه درباره پیشرفت است. بهترین محصولات آن‌هایی نیستند که بدهی فنی صفر دارند؛ آن‌ها محصولاتی هستند که تیم‌ها به‌طور آگاهانه انتخاب می‌کنند کدام بدهی را بپذیرند و کدام را پرداخت کنند.
دقیقاً مانند یک سرمایه‌گذار هوشمند که رشد را با ثبات متعادل می‌کند، تیم‌های محصول هوشمند سرعت را با پایداری متعادل می‌کنند. خود آینده شما از شما تشکر خواهد کرد زمانی که درخواست ویژگی تحول‌آفرین دریافت می‌کنید و تیم شما می‌تواند آن را در عرض هفته‌ها به جای ماه‌ها تحویل دهد.
علی امینی (مدیر ارشد محصول و مربی چابک)
مطالب مرتبط
چطور تسک ها را اولویت بندی کنیم؟
