آن‌چه مدیران محصول می‌توانند برای به حداقل رساندن بدهی فنی انجام دهند

بیشتر مدیران محصول، همانند من، هنگام نظارت بر یک محصول آن چنان به بدهی فنی یا technical debt اهمیت نمی‌دهند. فکر می‌کنیم که این کاری در حیطه مهندسی است و به همین خاطر به آن بی‌توجهی می‌کنیم. اگر منصف باشیم، گاهی اوقات بدهی فنی واقعاً یک مسئله مهندسی است، اما در برخی زمان‌ها هم اینطور نیست. علاوه براین، می‌توانیم از فهمیدن آن‌چه که این موضوع شامل آن است، بهره‌مند شویم.

اگر می‌خواهید یک راه جدید برای ساختن محصول بهتر و نزدیک‌تر شدن به تیم مهندسی خود پیدا کنید، به خواندن این مطلب ادامه دهید!

تاریخچه اصطلاح «بدهی فنی»

بدهی فنی اصطلاحی استعاری است که توسط وارد کانینگهام ابداع شده است. این اصطلاح چهارچوبی درباره این‌که چگونگی بهترین روش برخورد با مشکلات فنی (cruft)، با درنظر گرفتن آن به‌عنوان یک بدهی مالی است. تلاش اضافی که برای افزودن قابلیت‌های جدید لازم است، بهره‌ای است که باید برای این بدهی پرداخت شود.

بدهی فنی چگونه ایجاد می‌شود؟

به سادگی. گاهی اوقات از مهندسان می‌خواهیم که چیزها را «با بیشترین سرعت ممکن» بسازند، زیرا باید یک قابلیت جدید را زودتر منتشر می‌کردیم.

این‌طور فکر کنید: دوستان و همکارانمان به ما کمک می‌کنند و اتاق‌های جدیدی در ساختمان ما می‌سازند (محصول مورد نظر)، آن‌ها دیوارهای مجکمی نمی‌سازند، برای هر نفر یک تخت نمی‌گذارند و بقیه چیزها هم قابل گسترش نیستند. وقتی اتاق در سریع‌ترین زمان ممکن ساخته می‌شود، در ابتدا خوب به نظر می‌رسد، ما فرضیه خود را آزمایش کرده‌ایم و داده‌های ارزشمندی از کاربران دریافت کرده‌ایم؛ اما بعد از آن چه اتفاقی می‌افتد؟ ما می‌خواهیم این اتاق (یک قابلیت جدید که به پروژه ما اضافه شده است) را برای درخواست‌هایی که به منظور بهبود چند ویژگی جزئی به دستمان رسیده است، بازسازی کنیم، و متوجه می‌شویم که مشکلی وجود دارد.

یک تغییر ساده، بنا به دلایلی، زمان قابل توجهی را از ما می‌گیرد و اشکالات جدیدی را در منطق کارهای قبلی ما آشکار می‌سازد. چطور با این موضوع روبرو می‌شویم؟ اتاق زیبای ما (برای حداقل یک مشتری) چه ایرادی دارد؟ اگر فرصتی داشتیم که به داخل آن نگاه کنیم، متوجه می‌شویم که اتاق ما از بیرون عالی به نظر می‌رسد، اما دیوارهای ضعیفی دارد که در آستانه ریختن هستند، و چه چیز بدتری وجود دارد؟ ما متوجه می‌شویم که سه خرس گریزلی در حال تلاش برای استراحت بر روی یک تخت یک نفره  هستند و به عبارتی دیگر، با یک هرج و مرج کامل روبرو هستیم!

آیا «بدهی فنی» عواقبی فراتر از مشکلات مربوط به گسترش قابلیت‌ها دارد؟

مطمئناً! تصور کنید یک نقاش هستید که سعی می‌کند قسمت بیرونی این سازه را نقاشی و تزئین کند. شما در اولین تلاشتان، با چند شکاف روبرو شدید. برای بار اول مشکلی با این موضوع ندارید، اما پنجمین بار یا شاید دهمین باری که می‌خواهید ترک‌ها را برطرف کنید، چگونه خواهد بود؟ شما با عصبانیت به سقف می‌کوبید و به شروع به یافتن راهی می‌کنید که کلاً از شر این کار خلاص شوید. به طور کلی، در مورد مهندسان و تیم‌ها نیز همین اتفاق می‌افتد. انگیزه تمام اعضا کم می‌شود و بازدهی عملکرد کاهش می‌یابد.

اما آیا لازم است هرچه زودتر بدهی‌های فنی تسویه شوند؟ برخی می‌گویند بله، اما من نمی‌توانم با این گفته موافق باشم. و دلیل آن کاملاً واضح است. همه چیز به وضعیت و نوع بدهی بستگی دارد.

اگر بدهی فنی شما را از حرکت رو به جلو بازنمی‌دارد و می‌توانید بدون زحمت خاصی بهره آن را پرداخت کنید، به این قضیه با دید مثبت نگاه کنید. در این حالت این بدهی مانند یک انباری یا گاراژ برای نگهداری چیزهایی است که به ندرت از آن‌ها استفاده می‌کنید؛ و به شما این امکان را می‌دهد که خانه خود را از وسایلی که نمی‌خواهید، مانند مصال ساختمانی استفاده نشده، خالی کنید.

علاوه بر این، می‌توانید به بهبود وضعیت خانه خود ادامه دهید یا حتی آن را باز سازی کنید، چرا که اتاقی دارید که چیزهایی که از آن‌ها استفاده نمی‌کنید را در آن می‌گذارید.

بیایید وضعیت دیگری را در نظر بگیریم: کندن پی یک ساختمان. اگر یک ساختمان مثلاً دوطبقه، از پی و فونداسیون مناسبی برخوردار نباشد، نمی‌توانید یک ساختمان چندطبقه بر روی آن بسازید. سناریویی مانند این شما را به مبارزه با پرداخت سود و بهره برای بدهی فنی سوق می‌دهد و بنابراین، تصمیم می‌گیرید که در اسرع وقت به این بدهی رسیدگی کنید.

رویکردهای رایج برای حل مشکل بدهی فنی

خب. اکنون ما یک ایده تقریبی از آنچه در پشت اصطلاح «بدهی فنی» پنهان شده است، در دست داریم. بیایید ببینیم چه کاری می‌توانیم با آن انجام دهیم.

اولویت توسعه‌دهندگان

بسیاری از ما با روش اول آشنا هستیم: در برخی از روزها، با رئیس تکنولوژی‌مان گپ می‌زنیم؛ او ادعا می‌کند که کارهای عقب‌مانده‌ای در زمینه «بازسازی» داشته‌ایم که برای مدت طولانی به آن‌ها توجه نکرده‌ایم. با توجه به این‌که تخمین ما از زمان لازم برای انجام این کار، نزدیک به یک ماه است، این سوال را می‌پرسیم که چرا باید روی آن کار کنیم؟ اگر بازسازی را به زمان دیگری موکول کنیم چه می‌شود؟ و غیره.

معمولاً مدیران محصول نمی‌خواهند چنین زمانی را صرف فعالیت‌های عجیب و غریب مربوط به بازسازی مجدد کنند، و ما در حال حاضر مقدار زیادی از این کارهای عقب‌مانده را داریم که روی سرمان تلنبار شده‌اند. گاهی اوقات مهندسان نمی‌توانند توضیح دهند که چرا باید در اسرع وقت روی بدهی‌های فنی کار کنیم، بنابراین ما به ساخت یک محصول چندطبقه، بر روی یک فونداسیون دوطبقه ادامه می‌دهیم.

شما همین الان هم می‌توانید عواقب چنین تصمیماتی را تصور کنید.

زمان مشخص شده

رویکرد دوم می‌تواند برای پرداخت بدهی فنی موثرتر باشد. فقط زمانی ثابت (یا بازه زمانی ثابت) را با یک سرعت مشخص برای اتمام بازسازی‌ها، پیشرفت‌های معماری و غیره اختصاص دهید.  انجام این کار می‌تواند شما را به سمت داشتن محصولی با عمر طولانی و ویژگی‌های فنی قابل ‌پیش‌بینی و قابل کنترل هدایت کند.

خوب به نظر می‌رسد، این‌طور نیست؟ پس چرا ما نباید این استراتژی را انتخاب کنیم؟ ما می‌توانیم! اما این بهینه‌ترین راه برای پرداخت بدهی فنی محصول شما نیست. استفاده از این تکنیک منجر به صرف هزینه بیشتر برای چیزهایی می‌شود که نمی‌خواهید آن‌ها را بهبود دهید. در اینجا، مهندسان معمولاً آن‌چه را که باید بازسازی کنیم، انتخاب می‌کنند. نکته اینجاست که آن‌ها شاید ندانند ما دقیقاً می خواهیم چه بسازیم و در هنگام ساختن یک آسمان خراش، به جای طراحی مجدد فونداسیون، یک گاراژ را نوسازی کنند.

رویکرد پیش‌گیرانه

ما به آرامی به سمت روش سوم پیش می‌رویم. این روش زمان بیشتری را از مدیران محصول می‌گیرد، اما مزایای خود را دارد. از جمله این‌که می‌توانیم سلامت فنی محصول خود را آگاهانه و به‌طور بهینه بهبود ببخشیم. خب ما باید چه کاری انجام دهیم؟

من لیست زیر را به عنوان راهنما جمع‌آوری کرده‌ام:

به‌خاطر داشته باشید که مهندسان افراد باهوشی هستند. آن‌ها به خوبی می‌دانند که چگونه یک محصول را بسازند، اما گاهی اوقات در تصمیم‌گیری این‌که دقیقاً چه چیزی باید بسازند، مشکل دارند.

به‌ یاد داشته باشید که به عنوان یک مدیر محصول، شما مشتریان خود، نیازهای آن‌ها، استراتژی شرکت خود، معیارهای کیفیت‌سنجی محصولات و سایر ویژگی‌ها تجاری را می‌شناسید. به عبارت دیگر می‌دانید که می‌خواهید چه بسازید و چرا.

ترکیب دو روش نخست

دو روش اول را با هم ترکیب کنید! همیشه هر آن‌چه در مورد برنامه‌های محصول می‌دانید را با تیم خود به اشتراک بگذارید. (این نه فقط برای مهندسان، بلکه برای همه مفید خواهد بود) همچنین می‌توانید به تیم در مورد وسواس مشتری و مسئولیت محصول آموزش دهید. چشم‌اندازها را برای یک ویژگی خاص نگه ندارید.

این آزمایش، چه راه حلی پایدار باشد یا کدی که ممکن است در آینده حذف شود، تیم شما باید تفاوت را درک کند.

به توسعه محصول خود طوری نگاه کنید که انگار در حال ساختن خانه در یک قطعه زمین هستید. تیم شما اتاق‌ها، طبقات، تزئینات و غیره را ایجاد می‌کنند، اما برخی از قسمت‌های آن تخریب و دوباره ساخته می‌شود. در حالی که افراد شما درگیر دلایل و پیامد‌های ویژگی‌های مختلف هستند، محصول شما نه فقط از نظر تجاری، بلکه از نظر فنی نیز به طور مداوم بهتر و بهتر می‌شود.

علاوه بر نکات بالا، مهندسان را تشویق کنید تا ابتکار عمل داشته باشند و در هر بازه زمانی، مناسب‌ترین بخش بدهی فنی برای تسویه را انتخاب کنند.

دیگر نیازی به مکالمات سخت با رئیس بخش تکنولوژی‌تان ندارید. دیگر نیازی ندارید که محصولتان را به اشتباه بازسازی کنید. هماهنگی عمیق تیم، باعث می‌شود همه کارها به خودی خود انجام شوند.

سخن آخر

به عنوان آخرین کلام، مشتریان خود را دوست داشته باشد. تیم خود را دوست داشته باشید. تلاش کنید دنیای اطراف خود را بهتر کنید و به یاد داشته باشید، روش ساخت محصولاتتان منحصر به فرد است و هیچ کس دیگری نمی‌تواند آن را مانند شما انجام دهد.