مالک محصول در برابر مدیر پروژه: تفاوتی که بیشتر تیم‌ها اشتباه می‌گیرند

در بیش از یک دهه کار روی پروژه‌های فناوری اطلاعات، از سامانه‌های صنعت آب و برق تا بسترهای بانکی، یک سوءتفاهم را بارها و بارها و تقریباً در هر سازمانی دیده‌ام: افراد تفاوت میان مالک محصول (Product Owner) و مدیر پروژه (Project Manager) را نمی‌دانند. بدتر اینکه بسیاری مالک محصول را یک نقش تجملاتی، یک عنوان شیکِ اسکرامی، یا صرفاً دستیارِ مدیر پروژه فرض می‌کنند. به تجربه‌ی من، همین سوءبرداشت بی‌سروصدا بیش از هر خطای فنی، محصول‌ها را از پا درمی‌آورد.

چرا این سردرگمی پیش می‌آید

روی کاغذ، هر دو نقش در جلسه‌ها می‌نشینند، با ذی‌نفعان گفت‌وگو می‌کنند و چیزی را «مدیریت» می‌کنند، پس سازمان‌ها فرض می‌کنند این دو جایگزین یکدیگر هستند. خیلی از شرکت‌ها با علاقه و به سرعت عنوان‌های چابک را می‌پذیرند بی‌آنکه مسئولیت‌ها را تغییر دهند: هماهنگ‌کننده‌ای را «مالک محصول» می‌نامند، در حالی که تصمیم‌های واقعی درباره‌ی آنچه باید ساخته شود همچنان در کمیته‌ی راهبری و توسط فردی که بلندترین صدا را دارد گرفته می‌شود. عنوان عوض می‌شود؛ طرز فکر نه.

دو پرسش متفاوت

روشن‌ترین توضیحی که برایش پیدا کرده‌ام این است: این دو نقش به دو پرسش متفاوت پاسخ می‌دهند.

• مدیر پروژه پاسخ می‌دهد: «آیا داریم درست می‌سازیم؟ سرِ زمان، در بودجه و در محدوده؟» دنیای او زمان‌بندی، منابع، ریسک و هماهنگی است. موفقیت برای او یعنی پروژه‌ی تحویل‌شده.

• مالک محصول پاسخ می‌دهد: «آیا اصلاً داریم چیزِ درستی می‌سازیم؟» دنیای او کاربران، اولویت‌ها، بک‌لاگ و ارزش است. موفقیت برای او یعنی محصولی که مردم واقعاً از آن استفاده می‌کنند.

مدیر پروژه از برنامه محافظت می‌کند. مالک محصول از نتیجه. هر دو مهم‌اند؛ اما در دو جهت متفاوت، و این کشمکش وقتی هر دو نقش وجود داشته باشند و محترم شمرده شوند، سالم و سازنده است.

آنچه در عمل دیدم

در یکی از پروژه‌های داخلی که در آن نقش داشتم، نیازمندی‌ها یک‌بار در ابتدای کار به شکل فهرستی بلند جمع‌آوری شد و از آن به بعد تنها پرسش‌ها درباره‌ی موعدها و درصد پیشرفت بود. پروژه خوب «مدیریت» می‌شد؛ اما هیچ‌کس مالکِ این پرسش نبود که آیا هر قابلیت هنوز ارزش ساخته‌شدن دارد یا نه. نتیجه آشنا بود: تحویل سرِ موعد، و استفاده‌ی بسیار کم از نیمی از قابلیت‌ها.

نقطه‌ی عطف وقتی بود که یک نفر واقعاً مالکِ سمتِ محصول شد، با کاربران واقعی نشست، قابلیت‌هایی را که پرطمطراق بودند اما مسئله‌ای حل نمی‌کردند کنار گذاشت، و بک‌لاگ را بر اساس ارزش بازچینی کرد. همان تیم، همان بودجه؛ نتیجه‌ای کاملاً متفاوت. کار مالک محصول همین است. این نقش، کار اداری نیست؛ تصمیم‌گیریِ هر هفته درباره‌ی این است که ساعتِ بعدیِ تیم صرف چه چیزی بشود که بیارزد.

تفاوت‌های عملی

• تمرکز: مدیر پروژه —> تحویل پروژه. مالک محصول —> ارزش محصول.

• افق زمانی: مدیر پروژه —> تا بسته‌شدن پروژه. مالک محصول —> تا وقتی محصول زنده است.

• خروجی‌های کلیدی: مدیر پروژه —> برنامه، زمان‌بندی و دفتر ریسک. مالک محصول —> بک‌لاگِ مرتب‌شده بر اساس ارزش.

• سنجه‌ی موفقیت: مدیر پروژه —> سرِ زمان، در بودجه، در محدوده. مالک محصول —> پذیرش کاربران، رضایت و اثر کسب‌وکاری.

• شکست‌ها در نبودشان: بدون مدیر پروژه، آشفتگی و موعدهای ازدست‌رفته؛ بدون مالک محصول، کارخانه‌ی قابلیت‌سازی که چیزهایی می‌سازد که کسی نمی‌خواهد.

آیا یک نفر می‌تواند هر دو باشد؟

در سازمان‌های کوچک گاهی چاره‌ای نیست؛ خودم هم هر دو کلاه را بر سر گذاشته‌ام. اما فقط اگر در هر گفت‌وگو با خودتان صادق باشید که کدام کلاه را بر سر دارید. کلاهِ مدیر پروژه می‌خواهد از زمان‌بندی محافظت کند؛ کلاهِ مالک محصول گاهی باید همان زمان‌بندی را بشکند، چون بازار یا کاربران تغییر کرده‌اند. اگر یک نفر بدون توجه به این تعارض هر دو نقش را بازی کند، معمولاً زمان‌بندی برنده می‌شود و محصول می‌بازد.

حرف آخر

اگر پروژه‌تان سرِ زمان و در بودجه تحویل شد اما کاربران از آن فراری‌اند، مشکل شما مدیریت پروژه نبود؛ جای خالی مالک محصول بود. مالک محصول یک تشریفات چابک نیست، کسی است که مطمئن می‌شود آن‌همه تلاشِ خوب‌مدیریت‌شده، به سمت چیزی نشانه رفته که ارزش ساختن دارد. به تجربه‌ی من، این دست‌کم‌گرفته‌شده‌ترین نقش در فناوری اطلاعات است و اولین چیزی که سراغش را می‌گیرم وقتی کسی می‌پرسد چرا پروژه‌ی «موفق»شان شکست خورد.