مالک محصول (Product Owner)

ما یک تیم برنامه‌نویسی کوچک و چابک داریم که به‌صورت ریموت کار می‌کند. کسب‌وکارمون هم مشخصه: حوزه محیط زیست و مدیریت پسماندها. مرکزیت کار هم شهر مشهد هست.
در حال حاضر به دنبال یک نفر هستیم که نقش مالک محصول رو با دقت و مسئولیت‌پذیری پیش ببرد؛ کسی که از “گفتن” به “انجام و پیگیری” برساند، ایده‌ها و نیازهای مبهم رو به ویژگی‌های ملموس و ارزشمند تبدیل کند؛ درک عمیق “چرا” و “برای چه کسی” ؛ فراتر از صرفاً نوشتن User Story ها.
شما در کنار تیم توسعه، مشخص می‌کنید که:
· چه چیزی باید ساخته شود (با اولویت‌بندی روشن)؛
· چرا باید ساخته شود (هم‌راستا با نیاز واقعی کسب‌وکار)؛
· چطور موفقیت را اندازه می‌گیریم (تعریف معیار سنجش و بازخورد)؛
· و مهم‌تر از همه: مطمئن می‌شویم تیم، فقط “حرف” نمی‌شنود؛ خروجی‌ها واقعاً به سمت ارزش میروند.
وظایف اصلی
· همکاری نزدیک با تیم برای تبدیل نیازهای کسب‌وکار به اسناد و بک‌لاگ قابل اجرا؛
· نوشتن و نگهداری Product Backlog (شفاف، مرتب و قابل اولویت‌دهی)؛
· شرکت در جلسات تیم (برنامه‌ریزی، بازبینی، refinement) و روشن کردن ابهام‌ها؛
· تعریف معیارهای قابل اندازه‌گیری برای موفقیت هر قابلیت (به‌صورت واقع بینانه)؛
· بررسی و پذیرش خروجی‌ها در حدی که مطمئن شیم “منتظر چیز درست” هستیم؛
· جمع‌آوری بازخورد از کاربران و ذینفعان (طبق شرایط موجود) و استفاده از نتایج در جهت اتخاذ تصمیم‌ها؛
· مدیریت اولویت‌ها در شرایط محدودیت منابع و زمان (تصمیم‌گیری شفاف، نه امیدواری بی‌پشتوانه)؛
· تست و بررسی نهایی ویژگی‌های توسعه‌یافته قبل از انتشار.
چه ویژگی‌هایی برای ما مهم است؟
ما دنبال مالک محصولی هستیم که این‌ها را جدی بداند و انجام دهد:
· به توسعه Product Vision کمک میکنه؛
· Product Backlog را تعریف و نگهداری میکند و اطمینان پیدا میکند که بک‌لاگ شفاف، کامل، مرتب و قابل اولویت‌بندی هست؛
· توانایی تبدیل نیاز به User Story و نوشتن Acceptance Criteria (شفاف و روشن) را دارد؛
· شاخص‌های کلیدی عملکرد (KPIs) را برای محصول و هر ویژگی تعریف کند و پیگیری آن‌ها برای سنجش موفقیت و شناسایی حوزه‌های بهبود؛
· آشنایی با فرایند چابک (Scrum یا Kanban) و اجرای واقعی آن داشته باشد، نه صرفاً اصطلاحات؛
· اگر چیزی مبهم است، دنبال روشن‌سازی می‌رود و تصمیم را با اطلاعات کافی می‌سازد (اصرار بر فهمیدن دلیل اصلی پشت هر درخواست یا نیاز. به جای پذیرش “ما به دکمه X نیاز داریم”، پرسیدن “چرا به دکمه X نیاز دارید؟ این دکمه چه مشکلی را برای شما حل می‌کند؟ چه نتیجه‌ای انتظار دارید؟”)؛
· از گفته‌ها عبور می‌کند و مطمئن می‌شود “در محصول اتفاق افتاده”؛
· می‌داند که در پارت‌تایم، باید تمرکز داشت: برای هر بازه زمانی، انتخاب‌های درستی انجام دهد؛
· می‌تواند trade-offها را توضیح دهد (با زبان ساده و قابل فهم)؛
· ارتباطش محترمانه، صریح و بدون دور زدن مسئله باشد؛
· برای پاسخ به سوالات تیم توسعه، در دسترس باشد؛
· در جلسات تیم، سوال می‌پرسد، بازخورد میدهد، میگیرد و نهایتا تصمیم می‌سازد؛
· به تیم و ذینفعان وعده‌های غیرواقعی نمی‌دهد؛
· درباره ریسک‌ها از قبل می‌گوید و مسیر جایگزین ارائه می‌کند.
چه چیزی ارائه می‌دهیم؟
· همکاری با تیمی کوچک، صمیمی و بدون بوروکراسی‌های غیرضروری؛
· آزادی عمل و انعطاف‌پذیری کامل در محل و زمان کار (به شرط هماهنگی‌های لازم) ؛
· مشارکت در یک پروژه با هدف اجتماعی و زیست‌محیطی مشخص؛
· پرداخت منصفانه بر اساس توافق و حجم کار انجام شده.