همکاری مدیر محصول با تیم توسعه
همکاری با تیم توسعه: هنر تعامل مدیر محصول و مهندسان
زمان مطالعه: ۱۸ دقیقه
دسته‌بندی: توسعه و عرضه محصول (بخش ۴.۱)
کلمات کلیدی: همکاری مدیر محصول و تیم فنی، فرآیند تحویل محصول، اسپرینت پلنینگ، مدیریت بدهی فنی (Technical Debt)، تیم محصول، Product Trio
مقدمه: عبور از مرزهای وظایف سنتی
یکی از بزرگترین اشتباهات سازمان‌ها این است که با تیم‌های فنی خود به عنوان مزدور (Mercenaries) رفتار می‌کنند؛ یعنی لیستی از ویژگی‌ها را به آن‌ها می‌دهند و از آن‌ها می‌خواهند فقط کد بزنند. در نقطه مقابل، تیم‌های محصول واقعی و قدرتمند، شامل افرادی هستند که نقش مبلّغ (Missionaries) را بازی می‌کنند. به این تیم‌ها یک «مشکل» داده می‌شود تا آن را حل کنند و موفقیت آن‌ها با نتایج و پیامدها (Outcomes) سنجیده می‌شود، نه صرفاً با تعداد تسک‌های انجام‌شده.
شالوده این تیم‌های موفق را یک ترکیب سه‌نفره (The Product Trio) شامل مدیر محصول، طراح محصول و مهندس ارشد تشکیل می‌دهد. در این مقاله بررسی می‌کنیم که چگونه یک مدیر محصول می‌تواند رابطهای سازنده و مبتنی بر اعتماد با تیم مهندسی ایجاد کند، فرآیند تحویل را بهینه‌سازی کرده و بدهی‌های فنی را مهار نماید.
۱. ارتباط مؤثر بین مدیر محصول و تیم فنی
رابطه میان مدیر محصول و تیم مهندسی، حیاتی‌ترین پیوند در توسعه محصول است. مدیر محصول قدرت اجرایی مستقیمی بر مهندسان ندارد؛ بنابراین، پیشبرد کارها نیازمند شکل‌گیری اعتماد عمیق میان این نقش‌هاست.
شفافیت در مسئولیت‌ها با ماتریس RACI
برای جلوگیری از تداخل وظایف، تیم‌ها می‌توانند مسئولیت‌ها را در چارچوب‌هایی مانند RACI شفاف کنند. بر اساس این توافق:
-
تیم مهندسی (Engineering): مسئول نوشتن و لانچ کردن کدهای باکیفیت و کارآمد است.
-
تیم طراحی (Design): مسئول آن است که محصول نهایی برای کاربران قابل استفاده (Usable) باشد.
-
مدیر محصول (Product Management): مسئول اطمینان از این موضوع است که محصول یک مشکل واقعی را به شکلی ارزشمند برای کاربر و کسب‌وکار حل می‌کند.
درگیر کردن زودهنگام مهندسان در تصمیم‌گیری‌ها
یک مدیر محصول نباید مهندسان را صرفاً در زمان تحویل نیازمندی‌ها (کدنویسی) وارد بازی کند. مشارکت دادن تمام افراد تأثیرگذار (از جمله مدیران مهندسی) در فرآیند تصمیم‌گیری بسیار حیاتی است.
-
هرچند این فرآیندِ همفکری ممکن است در ابتدا طولانی به نظر برسد، اما مزایای هم‌سویی و دریافت ورودی‌های فنی، بسیار بیشتر از زمان صرف‌شده در جلسات است.
-
هم‌سویی قوی در مراحل اولیه، باعث می‌شود اجرای کار در مراحل بعدی با کیفیت و سرعت عالی پیش برود.
درک تفاوت‌های محیط کاری مهندسی و مدیریت محصول
برای افرادی که از نقش مهندسی به مدیریت محصول تغییر مسیر می‌دهند، درک این تفاوت‌ها ضروری است:
-
شما دیگر کد نمی‌نویسید: به عنوان مدیر محصول، کارهای شما خروجی ملموس (مثل نوشتن یک قطعه کد) ندارد. شما باید موفقیت خود را در قالب دستاوردهای تیمی ببینید و کارهایی مثل متقاعد کردن افراد و هم‌راستا کردن تیم را موفقیت روزانه خود بدانید.
-
شما نقطه کانونی انتقادات هستید: ایده‌ها ممکن است از سوی هر کسی در تیم مطرح شوند، اما زمانی که یک ایده اجرایی می‌شود، مدیر محصول مسئول پاسخگویی به بازخوردها و انتقادات است. شما باید این انتقادات را سازنده بگیرید و آن‌ها را برای بهبود محصول به کار ببندید.
-
درک زمان‌بندی مهندسی: تخمین زمانِ کارهای مهندسی به شدت دشوار است؛ کاری که ممکن است دو دقیقه به نظر برسد، گاهی ساعت‌ها یا روزها طول می‌کشد. یک مدیر محصول با داشتن شهود فنی، می‌تواند درک کند که پیاده‌سازی یک ویژگی چه مدت طول می‌کشد و چه ارزش‌هایی را باید برای مشتری اولویت‌بندی کند.
۲. فرآیند تحویل محصول (Product Delivery)
در چرخه عمر توسعه محصول، فاز اکتشاف (Discovery) ارزان و سریع است تا بفهمیم «چه چیزی باید بسازیم»، اما فاز تحویل (Delivery) که در آن کدنویسی واقعی انجام می‌شود، گران و زمان‌بر است و هدف آن پاسخ به این است که «چطور محصول را با بالاترین کیفیت بسازیم».
برای مدیریت بهینه فاز تحویل، مدیر محصول باید در رویدادهای کلیدی زیر با تیم مهندسی همکاری نزدیکی داشته باشد:
الف) جلسات پالایش بک‌لاگ (Backlog Grooming/Refinement)
-
استفاده از ابزارهای مشترک مانند Jira برای مستندسازی داستان‌های کاربری (User Stories) و معیارهای پذیرش (Acceptance Criteria) تضمین می‌کند که تمام اعضای تیم به به‌روزترین اطلاعات دسترسی دارند.
-
مدیر محصول یا مدیر پروژه نقش مهمی در خرد کردن تیکت‌ها به واحدهای کوچک‌تر و قابل مدیریت دارد که این کار به تخمین دقیق‌تر زمان و حجم کار توسط تیم فنی کمک می‌کند.
ب) برنامه‌ریزی اسپرینت (Sprint Planning)
-
اسپرینت یک بازه زمانی مشخص (Timebox) در چارچوب اسکرام است.
-
در جلسه برنامه‌ریزی اسپرینت، اعضای تیم اسکرام با همکاری یکدیگر کارهایی را که باید در اسپرینت جاری انجام شوند (Sprint Backlog) شناسایی و برنامه‌ریزی می‌کنند.
-
برگزاری جلسات منظم با تیم مهندسی برای بحث درباره نیازمندی‌ها، ابهامات را برطرف کرده و ارتباطات باز را ترویج می‌دهد.
-
همچنین، تعریف واضح از کلمه «انجام شده» (Definition of Done) پیش از شروع کار ضروری است تا تیم فنی و مدیر محصول بر سر استانداردهای کیفیت هم‌نظر باشند.
ج) همراهی در حین اجرا (Swarming و رفع موانع)
-
در طول پیاده‌سازی و کدنویسی، مدیر محصول نمی‌تواند تیم را رها کند. او باید به طور مستمر وضعیت را بررسی کند تا در صورت بروز مشکل (مثلاً متوقف شدن کار یک مهندس به دلیل وابستگی به مهندس دیگر)، برای رفع موانع و هماهنگی تیمی (Swarming) اقدام کند.
-
مدیر محصول گاهی باید با توافق تیم فنی، راه‌هایی برای تغییر ویژگی‌ها در حین پیاده‌سازی پیدا کند تا اجرای آن‌ها ساده‌تر و سریع‌تر شود.
۳. مدیریت بدهی فنی (Technical Debt)
یکی از مفاهیم کلیدی که مدیران محصول اغلب آن را نادیده می‌گیرند، «بدهی فنی» است.
بدهی فنی چیست؟
بدهی فنی به معنای هزینه‌های به تعویق افتاده از کارهایی است که در مراحل قبلی چرخه حیات محصول انجام نشده‌اند (مانند کدهای موقت یا معماری‌های غیربهینه که برای سرعت بخشیدن به عرضه اولیه نوشته شده‌اند).
چرا مدیر محصول باید نگران بدهی فنی باشد؟
-
بدهی فنی یکی از رایج‌ترین عواملی است که ظرفیت اجرایی تیم شما را محدود می‌کند.
-
به ازای هر ویژگی جدیدی که می‌نویسید، اگر تیم درگیر کدهای بی‌کیفیت و پیچیده گذشته باشد، نه‌تنها زمان توسعه محصول کند می‌شود، بلکه از نظر مالی نیز هزینه‌های پنهانی به سازمان تحمیل می‌گردد.
-
به همین دلیل، مدیر محصول موظف است در کنار قابلیت‌های جذاب برای مشتری (Features)، همیشه بخشی از ظرفیت اسپرینت‌ها را به درخواست‌های تیم فنی برای رفع بدهی‌های فنی و بازنویسی کدها (Refactoring) اختصاص دهد. نادیده گرفتن این موضوع، در بلندمدت منجر به توقف کامل توسعه نرم‌افزار خواهد شد.
نتیجه‌گیری
همکاری با تیم توسعه نیازمند ایجاد تعادلی ظریف میان درک محدودیت‌های فنی و پافشاری بر ارزش‌های کسب‌وکار است. یک مدیر محصول موفق، کسی است که مهندسان را از همان ابتدا در کشف راه‌حل‌ها دخیل می‌کند، انتظارات خروجی را با استفاده از ابزارهای شفاف‌سازی مشخص می‌سازد و با پرداخت منظم بدهی‌های فنی، سرعت توسعه را در بلندمدت تضمین می‌نماید.
گام بعدی مستندات: حالا که نحوه تعامل با مهندسان برای ساخت محصول را بررسی کردیم، در بخش بعدی (۴.۲) وارد فاز «طراحی و تجربه کاربری (Design & UX)» خواهیم شد تا نحوه خلق رابطهای کاربری چشم‌نواز و کاربردی را در کنار تیم دیزاین آموزش دهیم.