زبان تیم توسعه را بفهمیم: اصطلاحات و سوالاتی که هر Product Owner باید بلد باشد!

به عنوان یک Product Owner، نیازی نیست که خودت کدنویسی بلد باشی.

اما باید زبان تیم فنی رو بفهمی.

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

در این بلاگ پست:

• مهم‌ترین اصطلاحات فنی که باید بلد باشی رو معرفی می‌کنم.
• توضیح می‌دم اگر تیم این اصطلاحات رو به کار برد، چه سوال‌هایی باید بپرسی.
• کمک می‌کنم یاد بگیری چطور بدون وارد شدن به جزئیات کدنویسی، همکاری مؤثرتری با تیم فنی داشته باشی.

بخش اول: اصطلاحات فنی کلیدی برای Product Ownerها

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

توسعه کلی

API (Application Programming Interface):

رابطی برای تبادل داده بین سیستم‌ها. اگر تیم گفت "نیاز به API جدید داریم"، یعنی باید انتظار ارتباط جدیدی بین سیستم‌ها یا بخش‌های مختلف محصول رو داشته باشی.

Frontend:

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

Backend:

بخشی که پردازش داده‌ها و منطق اصلی اپلیکیشن در آن انجام می‌شه. تغییرات در بک‌اند معمولاً به زمان توسعه و تست بیشتری نیاز داره.

Database:

محلی برای ذخیره داده‌ها. تغییر در ساختار دیتابیس ممکنه باعث نیاز به تغییرات مهم در سیستم یا مدیریت ریسک‌های مربوط به داده بشه.

مدیریت کد و تحویل

Git و Branch:

ابزار و روش مدیریت نسخه‌های مختلف کد. اگر تیم گفت "یک Branch جدید باز می‌کنیم"، یعنی قراره تغییرات جدید جدا از کد اصلی توسعه پیدا کنه.

Merge Request (MR) یا Pull Request (PR):

درخواستی برای ادغام تغییرات جدید در کد اصلی. وقتی تیم می‌گوید "PR آماده است"، یعنی تغییرات باید بازبینی بشن تا کیفیت اون‌ها تایید بشن.

Refactor:

بازنویسی کد برای بهبود کیفیت بدون تغییر رفتار ظاهری محصول. اگر تیم نیاز به Refactor رو مطرح کرد، معمولاً به معنای پیشگیری از مشکلات آینده و کاهش هزینه نگهداریه.

تست و کیفیت

Unit Test:

تست یک واحد کوچک از کد به صورت مستقل.

Integration Test:

تست کارکرد صحیح اجزای مختلف با یکدیگر.

E2E Test (End-to-End):

تست کامل یک جریان کار از دید کاربر.

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

محیط‌های اجرایی

Staging:

محیطی شبیه به محیط واقعی برای تست نهایی تغییرات.

Production:

محیط واقعی که کاربران در آن از محصول استفاده می‌کنند.

اگر تیم می‌گه "باید روی Staging Deploy کنیم"، یعنی قبل از انتشار رسمی باید تغییرات کاملاً تست بشن.

معماری‌های فنی

Microservices:

ساخت سیستم به صورت چند سرویس مستقل که هرکدام وظیفه خاصی دارند.

Caching:

ذخیره موقت داده‌ها برای افزایش سرعت پاسخ‌دهی سیستم.

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

بخش دوم: سوالاتی که باید هنگام شنیدن اصطلاحات فنی بپرسی

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

وقتی صحبت از API و Backend شد:

• این API چه داده‌هایی ارسال یا دریافت می‌کنه؟
• آیا این تغییر باعث تاثیر روی کاربران یا بخش‌های دیگه محصول می‌شه؟
• اگر API درست کار نکنه، چه ریسک‌هایی وجود داره؟

وقتی صحبت از Refactor شد:

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

وقتی صحبت از تست شد:

• چه بخش‌هایی از سیستم تست شده و چه بخش‌هایی باقی مونده؟
• آیا نیاز به اضافه کردن تست‌های جدید داریم؟

وقتی صحبت از Deploy شد:

• تغییرات شامل چه ویژگی‌هایی است؟
• آیا قبل از Deploy روی Staging تست شده است؟
• اگر مشکلی پیش بیاد، آیا برنامه بازگشت داریم؟
• وقتی صحبت از Caching یا Microservices شد:
• این تغییر چه تاثیری روی سرعت یا پایداری سیستم داره؟
• آیا خطر خاصی مثل ناسازگاری داده یا پیچیدگی مدیریت سیستم به وجود میاد؟

شما چه اصطلاحات یا موقعیت‌های فنی دیگری رو تجربه کرده‌اید که فهم درست اون‌ها برای یک Product Owner حیاتی بوده؟
خوشحال می‌شم دیدگاه‌های شما رو هم بشنوم!