نقشه راه محصول روی صفحه مانیتور و در اسلایدهای ارائه، تمیز و مرتب و کاملاً قابل انجام به نظر می‌رسد؛ اما پیاده‌سازی آن همیشه با چالش‌هایی مثل تغییر سیاست‌های سازمانی، کم و زیاد شدن اعضای تیم و انواع اتفاقات غیرمنتظره همراه است. از وعده‌های تیم مارکتینگ و فروش به مشتریان گرفته تا تخمین‌های نادقیق تیم توسعه، نگهداشت و اجرای یک نقشه راه محصول یک نبرد دائمی است.
در این مقاله به شش چالش رایج تیم‌های محصول اجایل در تدوین و اجرای نقشه راه محصول پرداخته‌ایم؛ شش چالشی که همگی از دل تجارب واقعی تیم‌ها و مصاحبه با مدیران محصول مختلف استخراج شده‌اند. همچنین تلاش کرده‌ایم راهکارهای مقابله با هر چالش را نیز مطرح کنیم.
ما پیش از این درباره طریقه نوشتن نقشه راه محصول صحبت کرده‌ایم؛ این بار می‌خواهیم کمی عمیق‌تر شویم و درباره چالش‌ها و راهکارهای تدوین و نگهداشت Product Roadmap صحبت کنیم. اگر یک مدیر محصول هستید و در مدیریت نقشه راه محصول خود چالش دارید، این مقاله برای شماست.
چالش اول: تورم فیچرها
تورم فیچر یا خزش فیچر / Feature Creep یکی از چالش‌های رایج در توسعه نرم‌افزار است. دخالت ذینفعان، ارائه ایده‌های تازه از سمت تیم توسعه و درخواست‌های متعدد از طرف کاربران و تیم مارکتینگ باعث میشود تا با هر بروزرسانی فیچری جدید به محصول افزوده شود و کم‌کم محصول ما تبدیل به هیولایی شود که نه جوابگوی درد کاربر است و نه تیم فنی می‌تواند به آسانی آن را مدیریت کند.
این اتفاق زمانی می‌افتد که مدیر محصول نتوانسته اولویت‌های خود را به درستی شفاف کند و پیوسته در برابر خواست ذینفعان، درخواست‌های کاربران و تقاضاهای تیم فروش تسلیم شده است.
چه کنیم تا در این چاله‌ها نیفتیم؟
-
گام اول، تقویت مهارت «نه» گفتن است. یک مدیر محصول خوب باید بتواند بیشتر از بله، نه بگوید؛ به مدیران و سهامداران، به تیم فروش و مارکتینگ، به ایده‌های نوی تیم توسعه، به درخواست کاربران. هر فیچر باید یک هدف مشخص و قابل اندازه‌گیری را دنبال کند و ایده‌های تازه اگر به کمک این هدف نمی‌آیند باید کنار گذاشته شوند.
-
بک‌لاگ محصول را مرتب پالایش کنید. از روش‌هایی مانند متد MoSCoW یا RICE کمک بگیرید تا هر فیچر را بر اساس ارزش واقعی و تلاش مورد نیاز رتبه‌بندی کنید؛ این روش‌ها به شما کمک میکنند با شفافیت به درخواستها پاسخ دهید.
-
تصمیمات درباره حذف یا عقب انداختن فیچرها را مستند کنید و دلایل آن را به تیم فروش، مارکتینگ و سهامداران به‌روشنی اعلام کنید. این کار فشارها را کاهش می‌دهد و از ایجاد سوءتفاهم جلوگیری میکند. مدیریت انتظارات ذینفعان و توضیح روشن درباره دلایل اولویت‌بندی‌ها بخش مهمی از کنترل Feature Creep است.
حتی اگر موفق شوید خزش دامنه و تورم فیچر را کنترل کنید، چالش بعدی از راه می‌رسد: تأمین منابع کافی و هماهنگ نگه‌داشتن برنامه‌ها با ظرفیت واقعی تیم.
چالش دوم: بهم خوردن برنامهریزی منابع
تغییرات در تیم - مانند جدایی برخی نفرات یا اضافه شدن نفرات جدید - یکی از اتفاقات رایج در تیم‌های توسعه نرم‌افزار است؛ کمتر پیش می‌آید که کار روی توسعه محصولی را با همان تیمی به پایان ببرید که کار را با آنها شروع کرده بودید. از طرف دیگر تخمین نادرست مدیر محصول در میزان توانایی هر یک از افراد تیم، برنامهریزی منابع را با مشکل روبرو میکند.
وقتی تخمین درستی از توانایی اعضای تیم نداریم و ظرفیت تیم به درستی شناسایی نشده است، همیشه یا از ددلاین‌ها عقب خواهیم ماند یا تیم را دچار فرسودگی خواهیم کرد. هر یک از این دو سناریو هم منجر به سرخوردگی و از دست رفتن روحیه کل تیم خواهد شد.
برای مقابله با این مسئله راهکارهای زیر را پیشنهاد می‌کنیم:
-
ظرفیت تیم را با داده و ابزارهای کمّی تخمین بزنید؛ از متریک‌هایی مثل Velocity و Capacity Planning استفاده کنید تا توان واقعی تیم را برآورد کنید. این متریک‌ها را بر اساس دادههای واقعی اسپرینتهای قبلی استخراج کنید. برای مثال، اگر تیم در هر اسپرینت به طور متوسط ۳۰ واحد Story Point تحویل داده، برنامهریزی باید براساس این عدد و نه فرض و حدس باشد.
-
مدیریت ریسک را در استراتژی خود بگنجانید؛ فهرستی از ریسک‌های احتمالی در رابطه با منابع انسانی (مانند خروج افراد کلیدی، افت روحیه یا عملکرد یک عضو تیم یا تأخیر در آنبوردینگ) تهیه کنید و برای هر مورد برنامه مقابله و واکنش تعریف کنید. به عنوان مثال، اگر یک توسعه‌دهنده کلیدی به دلیل بیماری یک ماه غایب میشود، آماده باشید تا حجم کار را کاهش دهید و بخش‌هایی که کم‌اهمیت‌تر هستند را عقب بیندازید.
-
جلسات رتروسپکتیو را جدی بگیرید؛ تنها در این جلسات است که می‌توانید به روشنی میزان توانایی‌ها و ظرفیت تیم خود را تخمین بزنید و برای اسپرینت بعدی برنامهریزی درستی داشته باشید.
-
اگر از قبل می‌دانید که قرار است تغییری در اعضای تیم ایجاد شود، کمی زمانی اضافی در برنامه‌ریزی‌های خود در نظر بگیرید. در نظر داشته باشید ورود یک عضو جدید - حتی یک نیروی باتجربه - نیازمند فرایند آنبوردینگی است که می‌تواند زمان‌بر باشد.
-
به صورت مستمر و شفاف با ذینفعان در ارتباط باشید؛ ذینفعان کلیدی مانند مدیریت ارشد، تیم فروش و مارکتینگ را درباره ظرفیت واقعی تیم و تغییرات آن مرتب مطلع کنید تا توقعات واقع‌بینانه‌ای شکل بگیرد و فشارهای غیرمنطقی کاهش یابد.
حتی اگر با شناخت درست از ظرفیت تیم، برنامهریزی منابع را به‌خوبی مدیریت کنید، چالش بعدی ممکن است از بیرون تیم سر برسد؛ جایی که وعده‌های خارج از کنترل شما، نقشه راه را به‌هم می‌ریزند.
چالش سوم: ناتوانی تیم توسعه در تخمین زدن
حتی اگر یک دولوپور باتجربه باشید، تخمین میزان تلاش و کاری که برای انجام یک تسک لازم دارید، همیشه کار دشواری است. فیچرهایی که ساده به نظر می‌آیند همیشه پیچیدگی‌های پنهانی دارند.
دست پایین یا دست بالا گرفتن افورت لازم برای انجام یک تسک، اتفاقی رایج در توسعه نرم‌افزار است؛ بدون تخمین دقیق نمی‌توان برنامهریزی درستی برای اسپرینت‌ها و اولویتبندی فیچرها داشت. خطا در تخمین منجر به از دست دادن ددلاین‌ها و از دست دادن اعتماد ذینفعان میشود.
در مورد تخمین زدن یک نکته بسیار مهم را باید همیشه در نظر داشت: تخمین زدن صرفاً وظیفه دولوپور نیست و همه تیم باید خود را در این چالش سهیم بدانند. راهکارهای مقابله با این چالش چیست؟
-
به‌عنوان یک تیم تخمین بزنید؛ از تکنیک‌هایی مانند پلنینگ پوکر یا تی‌شرت سایزینگ استفاده کنید (به ویژه اگر در ابتدای مسیر هستید)؛ به این ترتیب می‌توانید از همه اعضای تیم بازخورد بگیرید و صرفاً بر اساس حدس و گمان یک فرد - دولوپر - تخمین نزنید.
-
در تخمین زدن‌ها یک لید فنی یا تحلیلگر نرم‌افزار داشته باشید تا در خرد کردن تسک‌های بزرگ و شناسایی ریسک‌های پنهان هر تخمین، اعضا تیم را راهنمایی کند.
-
از ابزارهای تحلیلی مانند جیرا یا آژور دواپس کمک بگیرید؛ به کمک این ابزارها می‌توانید دادههای مربوط به تخمین‌ها و اسپرینتهای خود را گردآوری و تحلیل کنید.
-
یادگیری دائمی یکی از اصل‌های اساسی در تمامی انواع متدولوژی‌های اجایل است. در پایان هر اسپرینت و بطور خاص در جلسات رتروسپکتیو، تخمین‌هایی که در ابتدای راه داشتید را با افورتی در عمل به کار رفت مقایسه کنید؛ از این مقایسه برای برنامه‌ریزی‌های دقیق در اسپرینتهای آتی استفاده کنید.
-
یکی از دلایل رایج تخمین‌های نادرست، نبود امنیت روانی در تیم است. باید فرهنگی ایجاد کنید که اعضای تیم در آن بتوانند نگرانی‌ها و دغدغه‌های خود را بدون ترس از قضاوت یا توبیخ بیان کنند. این شفافیت به ارائه تخمین‌های واقعی‌تر کمک میکند.
اما حتی وقتی تیم توسعه تخمین‌ها را با دقت بالا انجام می‌دهد و برنامه‌ها طبق انتظار جلو میرود، یک دشمن نامرئی آرام‌آرام در پشت صحنه رشد میکند: بدهی فنی. چیزی که اگر به موقع به آن رسیدگی نشود، می‌تواند کل نقشه راه را از درون فرسوده کند.
چالش چهارم: دخالت تیم فروش یا صاحب کسب‌وکار
یکی از بزرگترین دردسرهای تیم‌های توسعه نرم‌افزار، وعده‌هایی است که صاحبان کسب‌وکار و یا تیم فروش و مارکتینگ به مشتریان می‌دهند؛ برای مثال، تیم فروش قول ارائه امکان پرداخت اقساطی را به یک مشتری کلیدی داده، در حالی که این فیچر از منظر فنی نیازمند بازنویسی کامل ماژول پرداخت است که چند اسپرینت زمان خواهد برد.
این وعده‌ها اغلب تحت فشار بازار، رقابت شدید و اهداف کوتاه‌مدت فروش شکل می‌گیرند؛ اضافه کردن این وعده‌ها به نقشه راه محصول باعث میشود تا Product Roadmap از یک سند استراتژیک به فهرستی از خواسته‌ها و آرزوها تنزل پیدا کند. برای اینکه در این دام نیفتید باید:
-
نقشه راه محصول باید سندی شفاف باشد که همه اعضای تیم به آن دسترسی دارند: در عین این دسترسی باید به شکلی کنترل‌شده باشد؛ برای مثال تیم فروش به اطلاعات کلان و زمان‌بندی‌های کلی نیاز دارد، اما جزئیات فنی یا تخمین‌های داخلی بهتر است تنها در اختیار تیم توسعه قرار بگیرند. با تعیین سطوح دسترسی از سردرگمی و سوءتفاهم جلوگیری کنید.
-
صاحبان کسب‌وکار و تیم فروش و مارکتینگ را در برنامه‌ریزی‌های خود شریک کنید.جلسات هفتگی یا دوهفته‌ای بین تیم‌های فروش، محصول و توسعه با دستورجلسه مشخص برگزار کنید. در این جلسات، تیم فروش نظرات بازار و مشتریان را ارائه می‌دهد و تیم محصول توانایی‌ها و محدودیت‌های تیم توسعه را شرح می‌دهد. نتیجه جلسات باید شامل اولویت‌های واضح و تصمیمات مستند باشد.
-
از تکنیک «بله ولی حالا نه» استفاده کنید. به همه ایده‌ها و درخواستها نه نگویید؛ آنها را بشنوید، گوشه‌ای یادداشت کنید اما به درخواست‌‌کننده توضیح دهید که چرا آن ایده‌های جدید را در اولویت‌های بعدی خود قرار می‌دهید.
-
در نهایت اگر به هر دلیلی خارج از برنامه یا ظرفیت تیم به مشتریان وعده‌ای داده شد، سریعاً تأثیر آن را ارزیابی و به تیم و مدیران اطلاع دهید. با استفاده از دادهها و تحلیل‌ها، پیامدهای تجاری تأخیر یا تغییر اولویت را شرح دهید و پیشنهادهای جایگزین ارائه کنید.
هماهنگی با ذینفعان و مدیریت وعده‌ها تنها بخشی از ماجراست؛ چالش بعدی زمانی خودش را نشان می‌دهد که تیم توسعه وارد عمل میشود و تخمین‌هایش با واقعیت فاصله دارند.
چالش پنجم: مسئله مدیریت بدهی فنی
هیچ چیز هیجان‌انگیزی در مورد «بدهی فنی» وجود ندارد. کاربران هیچوقت خروجی آن را نمی‌بینند و توضیح آن به ذی‌نفعانی که از امور فنی سر در نمی‌آورند کار دشواری است. تمیز کردن کدها، بهبود عملکرد و برطرف کردن باگها همگی بخشی از بدهی‌های فنی هر نرم‌افزار هستند.
عدم رسیدگی به موقع به Technical Debt باعث انباشته شدن بدهی، افزایش باگها، کندی سیستم و دشوار شدن توسعه فیچرهای جدید میشود. چطور میتوان با این چالش روبرو شد؟
-
بخشی از ظرفیت هر اسپرینت - مثلاً در حدود 20% - برای رسیدگی به بدهی فنی، ریفکتورینگ و بهبود عملکرد سیستم اختصاص دهید.
-
هر چند وقت یک بار می‌توانید یک اسپرینت کامل را به این مسئله اختصاص دهید؛ هیچ ایرادی ندارد که در یک اسپرینت فیچر جدیدی توسعه ندهید و تنها به بهبود زیرساخت‌های نرم‌افزار مشغول شوید.
-
با بدهی فنی نیز درست مانند هر خروجی قابل تحویل دیگری برخورد کنید و آن در نقشه راه محصول قرار دهید؛ برای هر بخش کار زمان‌بندی و خروجی را مشخص کنید تا این تسک‌ها از حالت انتزاعی خارج شده و جدی گرفته شوند.
-
هر دستاورد فنی تیم را مانند به پایان رساندن توسعه هر فیچر جدید جشن بگیرید. با این کار نه تنها روحیه تیم حفظ میشود بلکه ارزش تجاری آن را برای مدیران و سهامداران برجسته میکنید.
اما چه چیزی باعث میشود برخی فیچرها اصلاً نباید وارد نقشه راه می‌شدند؟ پاسخ این است: تصمیمگیری بر اساس احساس، نه شواهد.
چالش ششم: تصمیمگیری بدون داده
گاهی اوقات تصمیمات نه براساس شواهد و آمار بلکه بر اساس ترجیحات تیم مدیریت یا بازخورد گروهی کوچک از کاربران و مشتریان گرفته میشوند. در چنین وضعیتی، آیتم‌های بسیاری بدون در نظر گرفتن رفتار کاربران، نیازهای بازار و اهداف تجاری سر از نقشه راه محصول در می‌آورند. نتیجه آن توسعه فیچرهایی خواهد بود که مشکلات واقعی کاربران را برطرف نمی‌کند و تنها وقت تیم توسعه را می‌گیرد. داشتن رویکرد دادهمحور دوای این درد خواهد بود:
-
همیشه با داده شروع کنید؛ خیلی از مواقع ممکن است بر اساس بازخوردی که از کاربران می‌گیریم تصمیمگیری که در ظاهر امر کار درستی به نظر می‌رسد. اما باید به خاطر داشت که خیلی از مواقع کاربران به خوبی نمی‌توانند درد خود را شناسایی و آن را منتقل کنند. برای ردیابی رفتار کاربران از ابزارهایی مثل Hotjar (برای ضبط Session) و Mixpanel (برای تحلیل Eventها) استفاده کنید. دادههای این ابزارها به شما نشان می‌دهند کاربر واقعاً چگونه از محصول استفاده میکند
-
کشف پیوسته یا Continuous Discovery را در برنامه‌های ثابت خود بگنجانید. مرتباً با کاربران مصاحبه کنید، تست کاربردپذیری و تحقیقات بازار انجام دهید تا نقاط درد واقعی کاربران را کشف کنید. این جلسات و مصاحبه‌ها باید عادتی ماهانه باشند.
-
برای هر فیچر، یک هدف شفاف مشخص کنید. با تعیین معیارهای مشخص برای هر آیتم در نقشه راه مرز مشخصی برای موفقیت یا شکست هر فیچر تعیین کنید؛ مثلاً به‌جای اینکه در رودمپ بنویسید «افزودن امکان ثبت یادداشت صوتی»، هدف را این‌طور تعریف کنید: «افزایش ۳۰ درصدی استفاده از بخش یادداشت‌برداری توسط کاربران موبایل».
جمع‌بندی
نقشه راه محصول یک سند ثابت و تغییرناپذیر نیست بلکه ابزاری زنده، مشارکتی و پویاست که باید همگام با محصول، تیم و شرایط بازار رشد میکند و تکامل مییابد. یک نقشه راه تنها زمانی مفید است که بازتابی از واقعیت موجود باشد و با تغییرات، سازگار شود.
برای رسیدن به این نقطه، مدیران محصول باید با نقشه راه همان‌طور رفتار کنند که با خود محصول رفتار میکنند: آن را آزمایش کنند، مرور کنند و بهبود دهند. زمانی که با چشم‌اندازی روشن برنامهریزی کنید، با اعضای تیم ارتباطی شفاف داشته باشید و به‌جای حدس و فرضیه، بر پایه دادهها تصمیم بگیرید، نقشه راه شما از یک فهرست فیچر ساده فراتر میرود و تبدیل میشود به یک برنامه پویا و مشترک که خروجی آن محصولی ارزشمند برای کاربر و سودآور است.
|
مدیریت محصول، نقشه راهی‌ست بین نیاز کاربران و توانایی تیم. در اجیلیتی، آموزش مدیریت محصول با نگاهی به چالش‌ها و فرصت‌های بازار ایران ارائه میشود.
|