مسعود بهرامی
هر تیم نرمافزاری که حداقل یک بار محصولی را به خط تولید رسانده باشد، این لحظه را تجربه کرده. بعد از ماهها کار، محصولی تحویل میدهی که دقیقاً همان چیزی نیست که کاربر میخواست. نه صرفا بخاطر اینکه کدش تمیز نبوده، یا اینکه تیم فنی تجربه کافی رو نداشته، و یا حتی بخاطر اینکه کسبوکار حرف نامربوط زده. بلکه بیشتر بخاطر این بوده که بین بین این دو-یعنی فضای کسبوکار و فضای توسعه محصول و تیم فنی، ترجمه صحیحی انجام نشده.
اینجاست که نقش مالک محصول معنا پیدا میکند. کسی که نه فقط لیست خواستهها را جمع میکند و میدهد به تیم، بلکه مسئولیت دارد نیازهای مبهم، گاهی متناقض و همیشه در حال تغییر کسبوکار را به زبان قابل فهم و قابل اجرا برای تیم فنی تبدیل کند. و در مسیر برگشت، محدودیتها و هزینههای فنی را طوری برای کسبوکار توضیح دهد که تصمیمگیرنده بداند چه ریسکی میکند.
من این نوشته رو برای مدیران محصول، اعضای تیمهای فنی، و هر کسی نوشتهام که میخواهد بفهمد چرا بعضی محصولات موفق میشوند و بعضی نه، و اینکه نقش مالک محصول در این معادله کجاست.
یک واقعیت: چرا جدا کردن نقش PO و PM اشتباه است؟
در تئوریهای مدیریت محصول، خیلی جاها این دو نقش را از هم جدا میکنند. یکی به اسم Product Manager که مینشیند و بازار را میخواند، با کاربر حرف میزند، استراتژی مینویسد، و نقشه راه میکشد. و دیگری به اسم Product Owner که میآید پایین، آن نقشه راه را میشکند به کارهای کوچک، اولویتبندی میکند، و با تیم فنی جلو میبرد.
این تفکیک در تئوری زیباست. در عمل، داستان خیلی متفاوت است و چالشهای پنهان اما عمیقی با خودش دارد. اجازه بدید چندتا از مشکلاتی را که در تیمهایی با این تفکیک دیدهام برایت بگویم.
دو نفر، دو اولویت متفاوت
مدیر محصول مثلا میگوید بر اساس تحلیل بازار، این سه ویژگی برای شش ماه آینده اولویت اول هستند. مالک محصول میگوید بر اساس گفتگو با تیم فنی، این سه ویژگی وابستگی دارند و باید اول این یکی را زد. حالا دو نفر با دو اولویت متفاوت داریم. هر کدام از زاویه خودشان حق دارند. اما محصول گیر میکند. در تیمهایی که یک نفر هر دو نقش را دارد، این تضاد وجود ندارد. همان کسی که با بازار حرف زده، با تیم فنی هم مینشیند و جمعبندی میکنند.
شکاف اطلاعاتی
مدیر محصول جلساتش را با کاربران میگذارد. چیزهایی میشنود. تحلیل میکند. نتیجه میگیرد. بعد میآید آن نتیجه را تحویل مالک محصول میدهد، مثل یک سند. مالک محصول هم آن را میبرد به تیم. اما چیزی از آن حرفها و آن فضا و آن حس را ندارد. فقط سند را دارد. وقتی تیم فنی سوال میپرسد این کاربر دقیقاً چه منظوری داشته، مالک محصول نمیداند. چون خودش آنجا نبوده. در تیمهایی که یک نفر هر دو کار را میکند، این شکاف وجود ندارد.
اهرم فشار دوطرفه
مدیر محصول میگوید بازار این را میخواهد. مالک محصول بعد از صحبت با تیم فنی میگوید، از نظر تیم فنی نمیشود این آیتم را پیادهسازی کرد. حالا کی برنده میشود؟ هر کدام که صدایش بلندتر باشد، یا هر کدام که به مدیر ارشد نزدیکتر باشد. این جنگ قدرت، به جای حل مسئله، وقت تلف میکند. در تیمهایی که یک نفر هر دو را میکشد، این جنگ وجود ندارد.
مسئولیت فراری
محصول که موفق میشود، هر دو میگویند من بودم. محصول که شکست میخورد، هر دو میگویند تقصیر نفر دیگری بودش. هیچکس جوابگو نیست. در تیمهایی که یک نفر مسئول است، جوابگو هم هست. این شفافیت، تیم را مجبور میکند که بهتر کار کند.
خلاصه بگم که نظر من این است که این دو مسئولیت را نباید به دو نقش متفاوت داد. همان یک نفر باید هم کشف کند، هم اجرا کند. هم با کاربر حرف بزند، هم با تیم فنی. هم استراتژی بنویسد، هم بکلاگ را مرتب کند. بله قطعا این کار آسانی نیست! سخت است. خیلی سخت. به این معنی است که یک نفر باید چند کلاه متفاوت را همزمان بر سر بگذارد. گاهی کلاه استراتژیست، گاهی کلاه دیپلمات، گاهی کلاه مدیر پروژه، گاهی کلاه مدافع کاربر. اما در نهایت، یک نفر پاسخگو است. یک نفر دارد تصمیم میگیرد. یک نفر دارد بین خواسته بازار و محدودیت فنی پل میزند.
یک استثنا میتواند اینجا ظهور کند. در تیمهای خیلی بزرگ، مثلاً تیمهای چندصدنفره با چندین محصول موازی، شاید چارهای جز تفکیک نباشد. چون حجم کار آنقدر زیاد است که یک نفر از پسش برنمیآید. اما حتی در آن صورت، باید مراقب بود که فاصله بین این دو نقش خیلی زیاد نشود. جلسات مشترک منظم، گزارشهای شفاف، و مهمتر از همه، فرهنگ یکی هستیم نه شما و ما. و یک مورد خیلی مهم که در این سناریوها به چشم میخورد، تفویض تصمیمگیری مناسب به PO است.
اما در بیش از نود درصد تیمهایی که من دیدهام، تیمهای پنج تا پنجاه نفره، تفکیک Product Owner و Product Manager بیش از آنکه کمک کند، ضرر زده است.
در نظر داشته باشید که در این مقاله، وقتی میگویم مالک محصول، منظورم همان کسی است که هر دو نقش را بر عهده دارد. کسی که هم کشف میکند، هم اجرا میکند. هم استراتژی مینویسد، هم بکلاگ را مرتب میکند. چون معتقدم این تنها راهی است که محصول درست، در زمان درست، با کیفیت درست ساخته میشود.
مالک محصول کسی است که هم کشف میکند، هم اجرا میکند.
یادگیری فضای مسئله: کار جمعی، نه انفرادی
یک باور غلط کاملا مصطلح در برخی تیمهای اسکرام این است که مالک محصول مسئول کامل یادگیری فضای مسئله است. میگویند برود و با کاربران حرف بزند، بازار را بفهمد، نیازها را شناسایی کند، بعد برگردد و به تیم بگوید چه چیزی بسازند. این باور، هم غلط است، هم در عمل ضرر زده.
این باور که فقط مالک محصول مسئولیت یادگیری فضای مسئله را به عهده دارد، یک باور کاملا غلط است که از فضای اسکرام نشات گرفته شده!
واقعیت این است که همه اعضای تیم مسئول یادگیری فضای مسئله هستند. توسعهدهنده، تستر، هر کسی که قرار است روی محصول کار کند، باید درک درستی از مشکلی که قرار است حل کند داشته باشد. اگر این درک را نداشته باشند، تصمیمهای فنیشان احتمالاً اشتباه از آب درمیآید. ممکن است جایی یک راه حل فنی خیلی تمیز بزنند که اصلاً به مسئله اصلی ربط نداشته باشد. یا جایی یک ویژگی اضافه کنند که هیچکس به آن نیاز ندارد.
پس نقش مالک محصول این نیست که برود و تنها یاد بگیرد و بعد به تیم بگوید. نقش او این است که فرآیند یادگیری جمعی را تسهیل کند. با استفاده از تکنیکهایی مثل ایونت استورمینگ، مدلسازی مشارکتی، و اکتشاف دامنه(Collaborative Modelling and Designing). این تکنیکها کمک میکنند که همه اعضای تیم با هم فضای مسئله را کشف کنند. نه اینکه یک نفر برود و بفهمد و برگردد و به بقیه بگوید.
در این روش، مالک محصول نقش یک تسهیلگر را دارد، نه یک محقق تنها. او سوال میپرسد، بحث را هدایت میکند، مفاهیم را شفاف میکند، و مطمئن میشود که همه به یک درک مشترک رسیدهاند. اما خودش تنها منبع حقیقت نیست.
پس نقش مالک محصول این نیست که برود و به تنهایی فضای مسئله را یاد بگیرد و بعد به تیم بگوید. نقش او این است که فرآیند یادگیری جمعی را تسهیل کند. در این روش، مالک محصول نقش یک تسهیلگر را دارد، نه یک محقق تنها.
تفاوت این دو رویکرد در عمل خیلی بزرگ است. تیمی که با هم یاد میگیرد، وقتی میرسد به اجرا، همه میدانند چه خبر است. نیازی نیست هر بار برگردند بپرسند این کاربر چه میخواسته. تصمیمهای فنی را آگاهانه میگیرند، چون میدانند این تصمیم قرار است چه مشکلی را حل کند. تیمی که منتظر میماند یک نفر برود و بفهمد و برگردد، همیشه یک گام عقبتر است.
این یکی از مهمترین مهارتهایی است که یک مالک محصول باید داشته باشد: توانایی تسهیل یادگیری جمعی. نه اینکه خودش تنها بفهمد، بلکه بتواند تیم را با خودش همراه کند.
اما در این بخش میخوام به مسئولیتهایی که یک مالک محصول موفق باید برعهده بگیرد بپردازیم.
مسئولیتهای مهم مالک محصول
فهمیدن اینکه چه چیزی بسازیم
قبل از اینکه اولویتبینی کنی، قبل از اینکه بکلاگ را مرتب کنی، قبل از اینکه با تیم فنی جلسه تنظیم کنی، باید بدانی اصلاً قرار است چه چیزی بسازی. این ساده به نظر میرسد، اما در عمل سختترین بخش کار است.
یعنی باید با کاربران حرف بزنی. نه گهگاهی و اوایل اسپرینتت ، و نه تنها وقتی که وقت اضافه داری. بلکه جزئی از روال هفتگیات باید باشد. یک هفته بدون حرف زدن با کاربر واقعی، یعنی یک هفته داری با چشم بسته حرکت میکنی. یعنی داری بر اساس حدس تصمیم میگیری، نه بر اساس داده.
باید بازار را بفهمی. رقبا چه میکنند؟ نیازهای کاربران در شش ماه گذشته چطور تغییر کرده؟ باید با ذینفعان داخلی حرف بزنی. فروش چه وعدههایی به مشتری داده؟ پشتیبانی از چه چیزی شاکی است؟ مدیرعامل چه چشماندازی در سر دارد؟
تمام این حرف زدنها و فهمیدنها، خروجیاش یک چیز است: نقشه راه محصول. نه یک سند پنجاه صفحهای که هیچکس نمیخواند. یک سند زنده که میگوید در شش ماه آینده، چه قابلیتهایی، به چه ترتیبی، برای رسیدن به چه هدفی قرار است ساخته شود.
ویژگیهای یک نقشه راه محصول خوب
نقشه راه خوب سه ویژگی دارد. اول اینکه مبتنی بر هدف است، نه ویژگی. به جای اینکه بنویسی قابلیت X را میسازیم، بنویس میخواهیم نرخ تبدیل را از دو درصد به چهار درصد برسانیم. برای این کار، قابلیت X را میسازیم. اینطوری اگر راه بهتری برای رسیدن به آن هدف پیدا شد، میتوانی قابلیت را عوض کنی بدون اینکه هدف را گم کنی.
دوم اینکه افق زمانی مشخص دارد. نقشه راه بیزمان، نقشه راه بیاستفاده است. تا سه ماه دیگر، تا شش ماه دیگر، تا یک سال دیگر. نه روز و ماه دقیق، چون در نرمافزار هیچوقت دقیق نمیشود پیشبینی کرد. اما یک بازه زمانی مشخص، به همه کمک میکند بدانند چه انتظاری داشته باشند.
سوم اینکه شفاف است برای همه. نه فقط برای مدیرعامل. برای تیم فنی، برای فروش، برای پشتیبانی. همه باید بدانند محصول دارد به کدام سمت میرود.
شفاف کردن بکلاگ
اگر نقشه راه بگوید به کجا میرویم، بکلاگ میگوید چطور میرویم. بکلاگ، مرکز ثقل کار روزمره تو و تیم است. اگر بکلاگ به درستی مدیریت نشود، کل فرآیند توسعه به هم میریزد. به گواه من، بکلاگ خوب سه ویژگی دارد.
اول اینکه آیتمهای بالای آن شفاف هستند
هر داستان کاربری باید به اندازه کافی واضح باشد که تیم بتواند آن را تخمین بزند. نه اینکه تیم بیست دقیقه وقت بذارد تا بفهمد اصلا خواسته چه بوده.
دوم اینکه اولویتبندی آن مبتنی بر ارزش است، نه فشار
نه اینکه هر کس صدایش را بلندتر کرد، یا در چارت سازمانی نقش بالاتری داشت، اولویت بگیرد. نه اینکه آخرین درخواست مدیرعامل، صدرنشین همیشگی جدول باشد-مثل جدول لیگ برتر فوتبال ایران!
سوم اینکه پویا است.
بکلاگ یک سند مرده نیست. هر هفته باید بازبینی شود. چیزهایی که دیگر ارزش ندارند حذف شوند، چیزهای جدید اضافه شوند، اولویتها جابهجا شوند. یک بکلاگ که شش ماه است دست نخورده، نه بکلاگ است، علف هرز است.
در عمل، خیلی از بکلاگهایی که من دیدهام، این سه شرط را ندارند. بالای بکلاگ پر است از آیتمهای مبهمی که شش ماه پیش نوشته شده و هیچکس یادش نیست یعنی چه و اینجا سوالی که همیشه میپرسم این است که:
آخه این چه چابکی است که ادعا میکنیم پاسخگویی به تغییرات داریم ولی آیتمهایی هست که برای شش ماه پیش وجود دارد و خاک خورده ولی دست نخوره باقی مانده است.
وسطش آیتمهایی هستند که اولویتشان شش بار عوض شده. تهش هم پر است از ایدههای خوبی که هیچوقت نوبتشان نمیرسد.
یک عادت خوب این است که هر هفته، دو سه ساعت وقت بگذاری و فقط بکلاگ را مرتب کنی. آیتمهای مرده را حذف کنی. آیتمهای مبهم را شفاف کنی. اولویتها را با تیم مرور کنی. این یک ساعت، بهترین سرمایهگذاری وقت توست.
لقمه را کامل نده
یک باور غلط رایج بین مالکین محصول این است که هرچه آیتمهای بکلاگ را مفصلتر و دقیقتر بنویسند، کار تیم فنی راحتتر میشود. میروند و هر شرط را مینویسند، هر حالت لبه را توضیح میدهند، هر جزئیاتی را از قبل مشخص میکنند. فکر میکنند هر چه لقمه را کوچکتر و جویدهتر بدهند، تیم سریعتر جلو میرود.
این باور غلط است.
اگر تو همه چیز را از قبل جواب داده باشی، تیم فنی دیگر سوال نمیپرسد. ذهنشان درگیر نمیشود. فقط مینشینند و پیادهسازی میکنند. بدون اینکه بفهمند چرا این کار را میکنند. بدون اینکه به راههای بهتر فکر کنند. نتیجه این میشود که تیم فنی به یک گروه مجری ساده تبدیل میشود. نه شریک تو در حل مسئله.
وظیفه تو این است که حس پرسشگری تیم را بالا ببری. باید آیتمهای بکلاگ را به گونهای بنویسی که هشتاد یا نود درصدش روشن باشد، اما ده یا بیست درصد آن جا برای سوال بگذارد. جایی که تیم مجبور شود بیاید از تو بپرسد. این سوال پرسیدن، باعث میشود که آنها درگیر شوند. خودشان فکر کنند. خودشان به حدسهایی برسند. و بعد با تو چک کنند.
این کار دو فایده دارد. اول اینکه تیم مسئله را عمیقتر میفهمد. کسی که سوال میپرسد، چند برابر کسی که فقط گوش میدهد یاد میگیرد. دوم اینکه تو متوجه میشوی کجای حرفت مبهم بوده. اگر تیم سوال نپرسد، احتمالاً چیزی را اشتباه فهمیدهاند ولی نمیدانند که نفهمیدهاند. این خطرناکترین حالت است.
پس یادت باشد. لقمه را کامل نده. همیشه یک حفره کوچک در داستان بگذار. یک جای خالی. یک سوال بیجواب. بگذار تیم خودش آن را پر کند. این کار نه فقط کیفیت کار را بالا میبرد، بلکه تیم را از حالت مجری صرف به شریک تو در حل مسئله تبدیل میکند.
مالک محصول خوب حس پرسشگری تیم را بالا میبرد!
با مثال کار کن، نه فقط با قاعده
این یک تکنیک کاملا عملی و کارا است که میتونه در بسیاری از شرایط بهت کمک کنه. این تکنیک به تو کمک میکند که همان لقمه نیمهجوش را درست به خورد تیم بدی. اسمش Specificaiton by example یا مشخص کردن رفتار با مثال است. به جای اینکه قاعده را بگویی، مثال بزن.
مثال بد از یک آیتم بگلاگ:
سیستم باید تخفیف را درست محاسبه کند. این جمله هیچی نمیگوید. هم مبهم است، هم تیم را وادار به پرسش نمیکند. تیم نگاه میکند و میگوید یعنی چی درست؟ از کجا بفهمیم درسته؟
نسخه بهتر:
سناریو 1: اگر کاربر کد تخفیف بیست درصد داشته باشد و سبد خریدش صدهزار تومان باشد، مبلغ نهایی باید هشتادهزار تومان شود.
سناریو 2: اگر کاربر کد تخفیف پنجاه هزار تومانی داشته باشد و سبد خریدش صدهزار تومان باشد، مبلغ نهایی باید پنجاه هزار تومان شود.
سناریو 3: اگر کاربر کد تخفیف بیست درصدی داشته باشد و سبد خریدش صدهزار تومان باشد، اما محصول شامل تخفیف نباشد، مبلغ نهایی باید صدهزار تومان شود.
این روش را specification by example میگویند. با مثالها مشخص میکنی که سیستم چه رفتاری باید داشته باشد. این کار هم مبهم بودن را از بین میبرد، هم به تیم اجازه میدهد که خودشان قاعده را استنتاج کنند. وقتی چند مثال میبینی، میتوانی بفهمی الگو چیست. مثلاً از این سه مثال میتوانی بفهمی که تخفیف هم میتواند درصدی باشد هم نقدی، و اگر محصول شامل تخفیف نباشد، تخفیف اعمال نمیشود.
این همان استدلال قیاسی است. مغز را درگیر میکند. مجبور میکند که از جزئیات به قاعده برسد. اگر تو فقط قاعده را بگویی، تیم شنونده منفعل است. اگر مثال بزنی، تیم تبدیل میشود به تحلیلگر فعال. فرق این دو را در عمل خواهی دید. تیمی که با مثال کار میکند، سوالهای بهتری میپرسد. زودتر متوجه تناقضها میشود. و در نهایت، محصول بهتری تحویل میدهد.
پس قاعده را بگو، اما قاعده به تنهایی کافی نیست. مثال بزن. چند مثال. مثالهایی که حالتهای مختلف را پوشش بدهد. بگذار تیم خودش الگو را کشف کند. این روش، هم درگیری ذهنی ایجاد میکند، هم شفافیت را بالا میبرد. دو پرنده را با یک سنگ میزنی.
اولویتبینی در شرایط ابهام
اولویتبینی، قلب تپنده کار یک محصولچی است. و شاید سختترین بخش نقش. چون همیشه اطلاعات کافی نداری. هیچوقت نمیدانی فلان ویژگی چقدر دقیقا ارزش دارد. هیچوقت نمیدانی فلان باگ چقدر دقیقاً کاربر را اذیت میکند. هیچوقت نمیدانی فلان بهبود فنی چقدر دقیقا در بلندمدت صرفهجویی میکند. با این حال، باید تصمیم بگیری. و این تصمیم، مسیر محصول را تعیین میکند.
اولویتبینی، قلب تپنده کار یک محصولچی است.
یک چارچوب ساده که خیلی به کار میآید، ماتریس تأثیر در برابر تلاش(Impact/Effort Matrix) است. یک صفحه دو در دو در ذهنت بکش. محور افقی: تلاش از کم به زیاد. محور عمودی: تأثیر از کم به زیاد.
- کارهایی که تأثیر زیاد و تلاش کم دارند: اولویت اول. همین حالا انجامشون بده. این آیتمها سریع ارزش ایجاد میکنند.
- کارهایی که تأثیر زیاد و تلاش زیاد دارند: اولویت دوم. بزارشون توی برنامه بلندمدت. اینها پروژههای اصلی هستند. باید برایشان وقت بگذاری.
- کارهایی که تأثیر کم و تلاش کم دارند: اولویت سوم. اگر وقت اضافه ماند برو سروقتشون. اما اجازه نده اینها اولویتهای اصلی را بزنند.
- کارهایی که تأثیر کم و تلاش زیاد دارند: ازشون دوری کن و وقتت رو تلف نکن برای اینها. هر چقدر هم کسی روی آن پافشاری کند، ارزش ندارد.
این ماتریس جادو نیست. اما به تو کمک میکند که تصمیمهای سخت را ساختارمند بگیری. و مهمتر از خود تصمیم، وقتی هست که میتوانی به بقیه نشان بدهی که بر اساس چه منطقی اولویتها را تعیین کردهای، حرفت باورپذیرتر میشود.
یک مفهوم دیگر که خیلی به کارت میآید، ماتریس هزینه-تأخیر است. یعنی اگر این کار را الان انجام ندهیم، چقدر ضرر میکنیم؟ اگر یک باگ جلوی پرداخت را گرفته باشد، هر روز تأخیر یعنی ضرر مالی مستقیم. هزینه تأخیر آن بالاست. اگر یک ویژگی خوب اما غیربحرانی باشد، هزینه تأخیر آن پایینتر است. اگر یک بهبود فنی باشد که در بلندمدت سرعت تیم را زیاد میکند، هزینه تأخیر آن نامشهود است اما میتواند خیلی بالا باشد.
گاهی باید بین هزینه تأخیر و تلاش، تعادل برقرار کنی. یک کار با هزینه تأخیر بالا و تلاش کم، اولویت اول است. یک کار با هزینه تأخیر بالا و تلاش زیاد، باید بشکنی به چند کار کوچکتر. یک کار با هزینه تأخیر پایین و تلاش کم، میتواند بماند برای بعد.
نگاه دوم؛ Matrix Thinking | نقشه ذهن: غلبه بر خطا با تفکر سیستمی (برای مهندس و مالک)
ترجمه بین کسبوکار و فنی
اینجا جایی است که خیلی از مالکین محصول زمین میخورند. به خاطر اینکه فکر میکنند فقط کافی است حرفها را جابهجا کنند یا ترجمه کنند. بروند پیش کسبوکار، حرفها را یادداشت کنند. بعد بیایند پیش تیم فنی، همان حرفها را تکرار کنند. و برعکس. این اشتباه بزرگ است.
تو به عنوان مالک محصول باید دو تا زبان را بفهمی. یک زبان، زبان کسبوکار است با کلماتی مثل ارزش، هزینه، ریسک، فرصت، سود، ضرر، بازار، رقیب، مشتری. اون یکی زبان، زبان فنی است با کلماتی مثل معماری، وابستگی، بدهی فنی، تستپذیری، مقیاسپذیری، امنیت، کارایی.
مسئولیت تو اینه که بین این دو ترجمه کنی. نه صرفا اینکه فقط حرف یکی رو برای دیگری تکرار کنی. ترجمه یعنی بفهمی طرف مقابل چه میگوید، بعد آن را به زبانی بگویی که طرف دیگر بفهمد. بدون کم و کاست، اما با توضیح. اگر این ترجمه را درست انجام ندهی، دو طرف حرف هم را نمیفهمند. کسبوکار فکر میکند تیم فنی کلهشق است. تیم فنی فکر میکند کسبوکار بیمنطق است. و این محصول نگون بخته که هزینه این نفهمیدن را پرداخت میکند.
با یک مثال واقعی جلو برویم.
فرض کن روی یک محصول سامانه پرداخت آنلاین مشغول هستی. کسبوکار به تو میگوید که میخواهیم کاربر بتواند بدون رفتن به صفحه درگاه بانکی، فقط با تأیید اثر انگشت روی گوشی، پرداخت را انجام بدهد. یک مالک محصول ضعیف، همین خواسته را میبرد به جلسه برنامهریزی و میگوید بچهها، کسبوکار میخواهد پرداخت تککلیک داشته باشیم!. احتمالا تیم فنی میگوید: هان!! تیم فنی نمیداند از کجا شروع کند. یک هفته وقت میگذارد. آخرش میگوید این شدنی نیست. کسبوکار ناراحت میشود. تیم فنی ناراحت میشود. تو وسط میمانی.
یک مالک محصول خوب، قبل از اینکه چیزی را به تیم ببرد، مینشیند با کسبوکار و سوال میپرسد تا بفهمد و متوجه دغدغه افراد و مشکل کاربر شود که قرار است فیچر مورد نظر انرا علاج کند. مثلا میپرسد این پرداخت یککلیک برای چه کاربری است؟ برای همه کاربران یا فقط کاربرانی که قبلاً یک بار پرداخت موفق داشتهاند؟ آیا بانک ما از این قابلیت پشتیبانی میکند؟ اگر نه، آیا میتوانیم با درگاه واسط صحبت کنیم؟ هزینه پیادهسازی این قابلیت چقدر است؟ فایده آن چقدر است؟
بعد از اینکه جواب گرفت، میرود پیش تیم فنی. میرود برای اینکه بفهمد این خواسته از نظر فنی یعنی چه. با تیم فنی مینشیند و میگوید کسبوکار میخواهد کاربرانی که قبلاً یک بار کارت خود را وارد کردهاند، دفعه بعد فقط با اثر انگشت پرداخت کنند.
تیم فنی نگاه میکند. میگوید برای این کار، باید توکن کارت را در سمت خودمان ذخیره کنیم. الان این کار را نمیکنیم. برای امنیت این توکن، باید یک سرویس جداگانه راه بیندازیم. این کار حداقل دو ماه طول میکشد. اما اگر فقط بخواهیم اثر انگشت را چک کنیم و خود پرداخت را همان درگاه بانکی انجام دهد، دو هفته کار است.
حالا تو میتوانی تصمیم بگیری.
این دانستن، فرق بین یک مالک محصول معمولی و یک مالک محصول خوب است. اولی حرف را جابهجا میکند. دومی حرف را میفهمد و بعد ترجمه میکند. اولی وقتی تیم فنی میگوید وابستگی دارد، نمیداند یعنی چه. دومی میداند که وابستگی یعنی برای این کار، باید سه تا سرویس دیگر هم عوض شوند و بعد میتواند تصمیم بگیرد.
محافظت از تیم در برابر بینظمی
این مسئولیت را خیلی از مالکین محصول فراموش میکنند. اما به اندازه تمام موارد قبلی مهم است. تیم توسعه برای اینکه بتواند تمرکز کند، نیاز به ثبات دارد. تغییرات باید قابل پیشبینی باشد. اگر هر روز اولویتها عوض شود، تیم هیچوقت نمیتواند وارد فلو شود. مثلا وقتی تیم روی Feature A کار میکنند، شما اولویت رو عوض میکنید و از تیم میخواهید روی Feature B کار کند. دوباره دارند روی B کار میکنند، میگویید نه، باگ C مهمتر است. نتیجه این میشود که تیم خسته میشود. سرعت میرود پایین. کیفیت میرود پایین. و محصول دیرتر تحویل داده میشود، نه زودتر.
وظیفه تو این است که یک ضربهگیر باشی بین بینظمی بیرون و ثبات درون. یعنی وقتی یک درخواست جدید از راه میرسد، آن را بررسی کنی، اولویتبندی کنی، و اگر واقعاً مهم بود، در یک بازه زمانی مشخص به بکلاگ اضافه کنی. نه اینکه هر روز بروی به تیم بگویی این را هم اضافه کنید.
راههای زیادی برای انجام دادن این مشئولیت وجود دارد. مثلا میتونی یک پنجره تغییر مشخص تعریف کن. مثلا اولویتها فقط در ابتدای هر اسپرینت عوض میشود. بقیه زمان، تیم روی همان چیزی که تعهد داده کار میکند. دوم اینکه برای تغییرات اورژانسی، یک جلسه فوقالعاده برگزار کن. نه اینکه بروی بالای سر تیم و بگویی الان این کار را بکن. تیم را جمع کن، تأثیر را بسنجید، با هم تصمیم بگیرید. سوم اینکه نه گفتن را یاد بگیر. خیلی از درخواستهایی که به نظر اورژانسی میرسند، واقعاً اورژانسی نیستند. اگر هر درخواستی را بپذیری، تیم از هم میپاشد.
چالشهای واقعی در این نقش
تا اینجا از مسئولیتها و وظایف حرف زدم. حالا برویم سراغ چالشهایی که هر روز با آنها دست و پنجه نرم میکنی.
ذینفعان متعدد و خواستههای متناقض
بخش فروش یک چیز میخواهد، تیم پشتیبانی چیز دیگر، مدیرعامل چیز دیگر، کاربران چیز دیگر. و همه فکر میکنند خواستهشان از همه مهمتر است. تو وسط مانی. راه چاره شفافیت است. معیارهای ارزیابی را مشخص کن، و به همه نشان بده بر اساس چه منطقی اولویتها تعیین شده.
تغییر مداوم اولویتها
دنیای نرمافزار سریع تغییر میکند. دیروز چیزی که اولویت اول بود، امروز ممکن است به خاطر ورود یک رقیب جدید یا یک بازخورد مهم کاربر، دیگر اولویت نباشد. تو باید به این تغییرات واکنش نشان دهی. اما نمیتوانی هر روز اولویتها را عوض کنی.
فاصله بین میخواهم و شدنی است
گاهی کسبوکار یک چیزی میخواهد که تیم فنی میگوید نمیشود. تو اینجا باید بفهمی چرا نمیشود. شاید واقعا با معماری فعلی شدنی نیست. شاید با بودجه فعلی شدنی نیست. شاید تیم مهارت کافی ندارد.
فشار برای تحویل سریع با کیفیت پایین
کسبوکار میگوید این قابلیت را دو هفته دیگر میخواهم. تیم فنی میگوید حداقل یک ماه طول میکشد. تو در میانه گیر کردهای. اگر تسلیم فشار شوی و تیم را مجبور کنی سریعتر کار کند، کیفیت میرود پایین. بدهی فنی انباشته میشود. بعداً هزینهاش چند برابر درمیآید. اگر مقاومت کنی، کسبوکار فکر میکند تو یا تنبلی یا از تیم حمایت بیجای میکنی.
تنهایی در تصمیمگیری
تو کسی هستی که در نهایت تصمیم میگیری. تیم فنی نظر فنی میدهد، کسبوکار نظر کسبوکاری میدهد، کاربران نیازشان را میگویند. اما جمع کردن اینها و تصمیم نهایی، با توست. و این تصمیم، گاهی اشتباه از آب درمیآید. بعد همه به تو نگاه میکنند. تحمل این مسئولیت، سنگین است.
سه مهارت ضروری یک محصولچی
اول: درک کسبوکار.
باید بدانی پول از کجا درمیآید. اگر محصول فروش مستقیم دارد، ویژگیهایی که نرخ تبدیل را بالا میبرند اولویت دارند. اگر اشتراکی است، ویژگیهایی که ریزش را کم میکنند اولویت دارند. اگر رایگان است و با تبلیغات درمیآید، ویژگیهایی که تعامل کاربر را بالا میبرند اولویت دارند. باید بدانی هزینه از کجا آب میخورد. وقت تیم، زیرساخت، پشتیبانی، بازاریابی. هر تصمیم تو، روی همه اینها تأثیر میگذارد. این مهارت را با کنجکاوی بساز. هر وقت چیزی در مورد مدل کسبوکار نفهمیدی، بپرس.
دوم: درک فنی کافی.
اینکه کد بزنی یا نه، موضوع این نیست. باید درک کنی معماری سرویسگرا یعنی چه، تا بدانی چرا ارتباط بین دو سرویس هزینه دارد. باید بدانی بدهی فنی یعنی چه، تا بدانی چرا گاهی تیم میگوید نمیشود این تغییر را زود زد. باید بدانی تست خودکار یعنی چه، تا بدانی چرا تیم بدون نوشتن تست، ریسک میکند. یاد گرفتن این مفاهیم سخت نیست. دو ساعت در هفته با تیم فنی بنشین. بگو این قضیه را برای من توضیح بدهید، طوری که بفهمم.
سوم: مهارت ارتباط و نفوذ.
تو بر کسی قدرت مستقیم نداری. نمیتوانی به تیم بگویی باید این کار را بکنی. نمیتوانی به بخش فروش بگویی حق نداری این قابلیت را بفروشی. باید متقاعد کنی. نفوذ هم بر اساس اعتماد و trustای است که ایجاد میکنی. این اعتبار از کجا میآید؟ خیلی ساده بخوام بگم از خروجی قابل لمس محصول. اگر چند بار تصمیمهای درست گرفته باشی، دفعه بعد حرفت را جدی میگیرند. با شفافیت. اگر منطق پشت تصمیمهایت را واضح توضیح بدهی، حتی مخالفها هم قبول میکنند که عادلانه بوده. با داده. اگر بگویی بر اساس مصاحبه با بیست کاربر، پانزده تایشان این باگ را گزارش کردهاند، حرفت باورپذیرتر است. با گوش دادن. گاهی کسی که مخالف توست، فقط میخواهد شنیده شود. و گاهی با نه گفتن. نه به این معنی که تو اهمیتی نداری. به این معنی که الان نه. شاید سه ماه دیگر.
اما کلام آخر اینکه
نقش مالک محصول، نقشی است که در ظاهر ساده به نظر میرسد اما در عمل بسیار پیچیده است. تو در تقاطع کسبوکار و فنی قرار داری. مدام در حال ترجمه، مدام در حال تصمیمگیری با اطلاعات ناقص، مدام در حال متقاعد کردن افرادی که بر تو قدرت مستقیم ندارند.
مالک محصول تصمیمگیرنده نهایی است. نه به این معنی که بقیه حرف نزنند. به این معنی که بعد از شنیدن همه نظرات، از تیم فنی و کسبوکار و کاربران، جمعبندی و تصمیم نهایی با اوست. تحمل این مسئولیت، بخشی از نقش است. مالک محصول خوب، از این مسئولیت فرار نمیکند. بهانه نمیآورد که تیم فنی گفت یا کسبوکار گفت. تصمیم میگیرد و جواب آن را هم میدهد.
سه مهارت در این نقش بیش از همه به کارت میآید: درک کسبوکار، درک فنی کافی، و مهارت ارتباط. این سه تا را اگر داشته باشی، حتی در بدترین شرایط هم میتوانی محصول درستی را، در زمان درست، با کیفیت درست تحویل بدهی.
و یک چیز آخرتر:
اگر این نقش را بر عهده داری، بپذیر که نمیتوانی همه را راضی کنی. نه تیم فنی همیشه با تصمیماتت موافق است، نه کسبوکار، نه همه کاربران خوشحال میشوند. وظیفه تو این نیست که محبوب باشی. وظیفه تو این است که محصول درست را، در زمان درست، با کیفیت درست تحویل بدهی. بقیهاش حاشیه است.
