مالک محصول (Product Owner) ارتباط دهنده تیم توسعه و مشتری می باشد. مالک محصول بر خلاف نام شبهه برانگیز آن پیمان کار یا تهیه کننده پروژه نیست. بلکه پلی است ارتباطی میان همه اعضای درگیر در پروژه. اسکرام یک متدولوژی مبتنی بر روابط است و همخوان با ارزش اول از بیانیه چابک (Agile) به روابط بین فردی بیش از مستندات بها داده می شود. اما همان طور که گفته شد پیاده سازی چنین روابطی بین اعضای تیم توسعه و مشتریان کار چندان ساده ای نیست.
فرض کنید در پروژه ای، تیم توسعه از ۸ نفر باشد. در طرف دیگر نمایندگان مشتری نیز از دو مدیر در دوسطح مختلف و دو اپراتور باشند. ارتباط بین این افراد نیاز به صرف زمان و انرژی بسیار زیاد و جلسات مکرر خواهد داشت. ارتباط هر کدام از اعضا با یکدیگر در نهایت جلسه تبدیل به یک شبکه ارتباطی پیچیده و کاملا بی معنی خواهد کرد. در اسکرام برای حل این مشکل راه ساده تری تعریف شده است.
همه ارتباطاتی که قرار است ایجاد شوند به طور مرکزی در نقش مالک محصول اداره می شوند. ارتباطی بدین شکل، خود باعث می شود امور کاراتر صورت پذیرد چرا که توزیع ارتباط جامع تر خواهد بود و باعث خواهد شد سایر نقش ها به جای درگیر شدن در یک ارتباط پیچیده بر روی وظایف خود تمرکز بیشتری داشته باشند. مالک محصول دارای چهار وظیفه می باشد که شرح آن در زیر آمده است:
1- تعیین مشخصات نرم افزار
بارزترین وظیفه مالک محصول را می توان مهندسی نیازها دانست. مالک محصول در طول توسعه همواره به دنبال شناسایی نیازمندی های نرم افزار می باشد. او به طور پیوسته با مدیران، اپراتورها و افراد دیگر مرتبط با پروژه ارتباط برقرار می کند. او همچنین مستندات سازمانی را مطالعه می کند، چارت ها و نمودارها و گزارشات را بررسی می کند تا بتواند نیازمندی های حقیقی نرم افزار را کشف کند.
مالک محصول پس از این پی می برد که انتظارات مشتری از نرم افزار چیست؟ سپس این انتظارات را به زبان توسعه که همان نیازمندی های نرم افزار است ترجمه کرده و به تیم توسعه تحویل می دهد. از این رو ناگفته پیداست که مالک محصول یک متخصص توسعه یا همان مهندس نرم افزار است.
تنها سند تحت تملک مالک محصول بک لاگ محصول می باشد. بک لاگ محصول در حقیقت قلب اسکرام است. هر اقدامی برای توسعه از طرف تیم توسعه باید با تغییر آیتم های موجود در بک لاگ محصول صورت پذیرد.
تنها فردی که می تواند در بک لاگ محصول تغییرات ایجاد کند شخص مالک محصول است. مالک محصول پس از شناسایی نیازها، آنها را به صورت اولویت بندی شده، در بک لاگ محصول وارد می سازد. آیتم های بک لاگ اولویت بندی می شوند و تنها کسی که می تواند اولویت این آیتم ها را تعیین کند نیز خود مالک محصول است.
مالک محصول به مشتری ضمانت می دهد که قابلیت های خواسته شده به درستی و به موقع در نرم افزار پیاده سازی شوند و نرم افزار نهایی مشخصات تعیین شده را دارا باشد. به همین دلیل مالک محصول همواره در طول توسعه دغدغه کاهش آیتم های بک لاگ محصول و یا به عبارتی افزایش قابلیت های نرم افزار را دارا است و برای اجرای صحیح آن تلاش می کند.
2- کنترل برنامه ریزی Release و اسپرینت
برنامه ریزی برای اسپرینت و Release یکی از اعمالی است که در اسکرام حساسیت ویژه ای دارند. حساسیت آن از این جهت است که در پایان هر اسپرینت و در نهایت هر Release باید قابلیتی به نرم افزار اضافه شود. این کار به صورت گروهی توسط تیم توسعه اسکرام، اسکرام مستر و مالک محصول است. آنچه در پایان Release به مشتری تحویل داده می شود، اغلب با پیشنهاد مالک محصول تعیین می شود.
مشتری در بازه های زمانی انتظاراتی در خصوص نرم افزار در دست تکمیل دارد. این بازه های زمانی مورد انتظار اغلب با بازه های زمانی Release ها هماهنگ است. از آنجایی که مالک محصول ضمانت کننده یک نرم افزار کارکننده در بازه های زمانی مشخص می باشد، همواره سعی می کند برنامه ریزی Release را به گونه ای کنترل کند که موجبات ارضای انتظارات مشتری فراهم آید. اما او تنها شخصی نیست که برای این برنامه ریزی تصمیم می گیرد.
مالک محصول باید با تیم توسعه که وظیفه اصلی توسعه را بر عهده دارد به توافق برسد. چرا که ممکن است انتظاراتی که، آنها هم از انتظارات مشتری تغذیه می شوند از نظر عملی ناممکن باشند که این خود موجب می شود تیم توسعه هم به نوبه خود وظیفه ارائه کارهای اخذ شده را در پایان Release بر عهده دارد، از ارضای برخی نیازها سرباز بزند.
3- آماده سازی تست کیس ها
مالک محصول صرفا قابلیت هایی که باید توسعه پیدا کنند را تعیین نمی کند. بلکه چگونگی این قابلیت ها را نیز تبیین می کند. به عنوان مثال اگر قابلیت جستجو داده های نرم افزار جزو قابلیت های مورد درخواست مالک محصول باشد، او تعیین می کند که جستجو چگونه، بر اساس چه آیتم هایی و با چه فرمتی باید توسط کاربر نهایی انجام شود. این باعث می شود که تیم توسعه دقیقا چیزی را پیاده سازی کند که مورد نظر مشتری می باشد.
گاهی پیش خواهد آمد که آیتمی را که تیم پس از صرف وقت بسیار پیاده سازی کرده است را مشتری نمی پذیرد. این حالت ابهام در پیاده سازی نام دارد. برای جلوگیری از این حالت باید پیش از پیاده سازی، مالک محصول شرایط تطبیق با انتظارات مشتری را به صورت مشروح مکتوب کند تا هم سندی توافقی باشد بین تیم و مشتری و هم راهنمایی برای چگونه ساختن یک آیتم.
همچنین تیم بر اساس این سند می تواند آیتم های پیاده سازی شده را تست نماید. شرایط توافقی را می توان به صورت متنی ساده همراه با آیتم نگه داری کرد و یا اینکه می توان آن را به صورت مدل پیشرفته تری مانند تست کیس استفاده نمود. تست کیس ها اساسا از همان متن شرایط تشکیل می شوند با این تفاوت که مراحل آنها به صورت شفاف تری بیان می شود. پس از تکمیل یک آیتم تست کیسی که برای آن نوشته شده بر روی آن اجرا می شود تا قابلیت تکمیل شده آزموده شود و میزان تطبیق آن با انتظارات مشتری نمایان شود.
مالک محصول به عنوان فردی که تسلط کامل بر نیازمندی های نرم افزار دارد وظیفه نوشتن تست کیس ها را بر عهده دارد. تست کیس های یک آیتم عموما پیش از توسعه آن آیتم نوشته و آماده می شوند.
4- برقراری ارتباط دو طرفه
وظیفه مالک محصول تنها انتقال درخواست و احتیاجات مشتری به تیم توسعه نیست. بلکه او وظیفه دارد بازخوردهایی از تیم توسعه داشته باشد که نظر تیم توسعه را نیز به مشتری اطلاع دهد. به عنوان مثال مشتری ممکن است در خصوص یکی از قابلیت های نرم افزاری درخواستی داشته باشد که از نظر تیم توسعه به دلیل محدودیت های فنی غیر قابل پیاده سازی باشد. مالک محصول چنین شرایطی را به اطلاع مشتری خواهند رساند و از آنها درخواست می کند که در خواسته خود تجدید نظر نمایند.
