Post by Hasan Parasteh

بدهی فنی فقط یک مشکل فنی نیست؛ یک هزینه‌ی واقعی و پنهان برای کسب‌وکار است. در دو TechTalk | تِک تاک اخیر که شرکت کردم، درباره‌ی این موضوع از زاویه‌های مختلف Tech و Product صحبت شد. چیزی که به نظرم کم‌تر بهش اشاره می‌شه اینه که بدهی فنی راحت قابل تبدیل به عدد و متریک‌هایی بیزنسیه. مثلاً اگر کدبیس پیچیده و نامنظم باشه، سرعت توسعه فیچرهای جدید پایین میاد. این یعنی زمان بیشتری برای هر تغییر، و در نهایت افزایش هزینه توسعه. این موضوع کاملاً با میانگین زمان تحویل فیچر قابل اندازه‌گیریه. از طرف دیگه، وقتی بحث scale و بهینه نبودن سیستم وسط میاد، خروجی مستقیمش روی performance دیده می‌شه؛ چیزی که با p95 و p99 می‌شه دقیق اندازه‌اش گرفت. اینجا دیگه بحث فقط فنی نیست، تبدیل می‌شه به خرید از دست‌رفته و اثر مستقیم روی درآمد. و در نهایت، چیزی که کمتر جدی گرفته می‌شه: زمان برگشت از بحران. اینکه اگر یک incident جدی اتفاق بیفته، تیم چقدر سریع می‌تونه سیستم رو به حالت پایدار برگردونه، خودش یک متریک حیاتی برای بقاست. من در Saraf تلاش کردم این نگاه رو عملی کنم؛ با کمک داشبوردهای Grafana، و در فرآیند تحویل فیچرها هم همکاری Navid Moradi خیلی در ساختارمند شدن جریان Jira و فرآیندها مؤثر بود و Ali Qavidel هم نقش مهمی در بهبود زمان ریکاوری داشت. که از همکاری جفتشون صمیمانه تشکر می‌کنم. در نهایت، اگر این متریک‌ها در یک کسب‌وکار شفاف باشند، تقریباً هر چیز فنی قابل تبدیل به زبان مشترک با بیزنس می‌شود. حالا که این متریک‌ها وجود دارند، فقط تنها مشکل باقی مونده ارتباط درست و صحیح است. گفتگو در آرامش و نمایش واقعیت روی میز و مذاکره درباره اولویت‌های کسب و کار، مسیر آینده را مشخص می‌کند. (بعضی وقتا هم پیش میاد که بهتره بدهی فنی همینجوری بمونه، شاید چون هزینه‌ی درست کردنش در این برهه صرفه‌ی اقتصادی نداشته باشه.. و خب اینم طبیعی و باید قبولش کنیم.) و درآخر واقعیت ساده است: زبان مشترک هر بیزنس، پول است و نباید با زبان غیر از پول صحبت کرد در پایان هم از Amir Zamaniha و Cafe Ertebat | کافه ارتباط باید یه تشکر ویژه کنم که این فضا و دورهمی رو فراهم کرد.