فهرست مطالب
مدیرعامل معمولاً از ما یک چیز ساده می‌خواهد: بگویید چه زمانی چه چیزی تحویل می‌دهید. ما در پاسخ یک فایل پر از قابلیت، وابستگی و اصطلاح فنی نشان می‌دهیم. جلسه تمام می‌شود، اما هیچ‌کدام راضی نیستیم. مشکل معمولاً از فهم یا علاقه‌ی مدیرعامل نیست. مشکل در قالبی است که برای نقشه راه محصول انتخاب کرده‌ایم. در این مقاله قالبی یک‌صفحه‌ای پیشنهاد می‌کنم که روی «اولویت‌ها و فرضیه‌ها» بنا شده است، نه تاریخ و وعده.
چرا نقشه راه محصول برای مدیرعامل شبیه وعده است#
وقتی فهرستی از قابلیت‌ها را کنار ماه‌ها می‌گذاریم، آن فهرست خودبه‌خود به تعهد تبدیل می‌شود. مدیرعامل هم آن را همین‌طور می‌خواند. او می‌خواهد به مشتری، سرمایه‌گذار یا تیم فروش پاسخ بدهد و به یک تاریخ نیاز دارد.
فرض کنید در جلسه‌ای اسلایدی نشان می‌دهید: «ماه سوم، پرتال مشتری». چند هفته بعد معلوم می‌شود یکپارچه‌سازی با سیستم پرداخت پیچیده‌تر از برآورد اولیه است. از نگاه شما این یک تغییر برنامه است. از نگاه مدیرعامل یک وعده‌ی شکسته است.
مشکل از دقت برآورد هم بیشتر است. ما اطلاعاتی را که هنوز نداریم، در قالب تاریخ ارائه می‌کنیم. قالب یک‌صفحه‌ای این ناشناخته‌ها را پنهان نمی‌کند. آن‌ها را صریح و قابل‌فهم می‌گوید.
مدیرعامل واقعاً چه می‌خواهد بداند#
پیش از ساختن هر قالبی باید بدانیم مخاطب چه سؤال‌هایی در ذهن دارد. معمولاً این‌هاست:
- روی چه چیزی کار می‌کنیم و چرا؟
- این کار چه ارتباطی با هدف کسب‌وکار دارد؟
- چه چیزی را عمداً کنار گذاشته‌ایم؟
- کجا ریسک داریم؟
- از من چه تصمیمی یا چه کمکی لازم است؟
دقت کنید که «کد چگونه نوشته می‌شود» در این فهرست نیست. مدیرعامل جزئیات معماری نمی‌خواهد. او می‌خواهد بداند منابع محدود شرکت صرف چه چیزی می‌شود.
در پروژه‌ها این شکاف را زیاد می‌بینیم. تیم فنی می‌گوید «باید لایه‌ی احراز هویت را بازنویسی کنیم». مدیرعامل می‌شنود «چند هفته هیچ قابلیت جدیدی نمی‌بینیم». اگر همان جمله را به زبان کسب‌وکار بگوییم، تصویر عوض می‌شود: «ورود کاربران مدام دچار خطا می‌شود و بخشی از مشتریان جدید همین‌جا رها می‌کنند. این کار جلوی آن را می‌گیرد.» کار یکی است، اما یکی قابل‌دفاع‌تر شنیده می‌شود.
پیشینه‌ی فنی در این‌جا کمک می‌کند. می‌توانم با تیم فنی هم‌زبان باشم و آنچه می‌گویند را به اثر کسب‌وکاری ترجمه کنم. این ترجمه بخش مهمی از کار ماست.
به‌جای تاریخ، اولویت بگویید#
اولویت یعنی ترتیب و دلیل. تاریخ یعنی تعهد زمانی. این دو را جدا کنید.
به‌جای ماه‌های تقویم، از سه دسته استفاده کنید:
- در حال انجام: تیم همین حالا رویش کار می‌کند.
- بعدی: بعد از پایان کارهای فعلی شروع می‌شود.
- بعداً: مهم است، اما هنوز زمانش نرسیده یا اطلاعاتمان کافی نیست.
هر مورد یک دلیل کوتاه دارد. مثلاً:
در حال انجام: ساده‌کردن ثبت‌نام. دلیل: کاربران جدید در مرحله‌ی تأیید شماره‌ی تماس زیاد رها می‌کنند. [نیاز به منبع]
این جمله ادعایی درباره‌ی داده دارد. در سند واقعی باید عدد و منبعش را از داده‌ی خود شرکت بیاورید. اگر ندارید، صادقانه بنویسید «فرض ما این است» و آن را در بخش فرضیه‌ها بگذارید.
مزیت دسته‌بندی این است که مدیرعامل ترتیب را می‌بیند. اگر ترتیب را قبول نداشته باشد، بحث همان‌جا شروع می‌شود. این بحث ارزشمندتر از بحث درباره‌ی «چرا دو هفته دیر شد» است.
به‌جای وعده، فرضیه بنویسید#
هر مورد در نقشه‌ی راه در واقع یک شرط‌بندی حساب‌شده است. ما باور داریم اگر کاری را انجام دهیم، نتیجه‌ای حاصل می‌شود. این باور را صریح بنویسید.
قالب ساده‌ی فرضیه این است:
باور داریم که [کار] برای [گروه کاربران] باعث [نتیجه] می‌شود. می‌فهمیم درست بوده، وقتی [نشانه‌ی قابل‌مشاهده].
یک مثال فرضی: تیم پشتیبانی می‌گوید مشتریان سازمانی مدام گزارش‌ها را دستی استخراج می‌کنند. شما می‌نویسید:
باور داریم که قابلیت خروجی‌گرفتن از گزارش‌ها، بار درخواست‌های پشتیبانی را برای مشتریان سازمانی کم می‌کند. می‌فهمیم درست بوده، وقتی تعداد درخواست‌های مرتبط با گزارش‌گیری پس از انتشار کمتر شود.
حالا اگر نتیجه برعکس شد، شکست نخورده‌اید. فرضیه رد شده و چیزی یاد گرفته‌اید. مدیرعامل هم از قبل می‌داند که این یک آزمون است، نه قول قطعی.
این تغییر لحن اهمیت دارد. وقتی از «وعده» به «فرضیه» می‌رویم، گفت‌وگو از «چرا نکردید؟» به «چه یاد گرفتیم؟» می‌رسد.
قالب یک‌صفحه‌ای#
حالا همه را در یک صفحه جمع کنیم. این قالب را می‌توانید در سند متنی یا یک اسلاید بسازید. ساختارش این است:
بالای صفحه: هدف
یک یا دو جمله در
مورد هدف کسب‌وکار در این دوره بنویسید، آن هم به زبانی که خود مدیرعامل به کار می‌برد، نه زبان تیم فنی. مثلاً «کم‌کردن رهاکردن کاربران در ورود به محصول» روشن‌تر از «بهبود زیرساخت احراز هویت» است. زیر هدف، سه ستون «در حال انجام»، «بعدی» و «بعداً» را بگذارید. هر ستون بیشتر از سه یا چهار مورد نداشته باشد. اگر فهرست بلندتر شد، یعنی هنوز اولویت‌بندی نکرده‌ایم.
برای هر مورد دو خط کافی است: یک خط فرضیه به همان قالبی که گفتم، و یک خط نشانه‌ی موفقیت. جزئیات فنی، وابستگی‌ها و فهرست کامل قابلیت‌ها جایی در این صفحه ندارند. آن‌ها در سند جداگانه‌ای برای تیم نگه داشته می‌شوند و فقط وقتی مدیرعامل بپرسد سراغشان می‌رویم. پایین صفحه دو بخش کوچک اضافه کنید: چه چیزی را عمداً کنار گذاشته‌ایم و ریسک‌ها و ناشناخته‌ها. بخش اول جلوی این سؤال همیشگی را می‌گیرد که «پس فلان درخواست چه شد؟». بخش دوم همان جایی است که عدم‌قطعیت را صادقانه می‌نویسیم، مثلاً «یکپارچه‌سازی با سیستم پرداخت هنوز بررسی فنی نشده و برآورد ما درباره‌ی آن قطعی نیست».
آخرین بخش صفحه، درخواست از مدیرعامل، شاید مهم‌ترین بخش باشد. اگر برای ادامه‌ی کار به تصمیم، بودجه، دسترسی به یک ذینفع یا حذف یک اولویت رقیب نیاز دارید، همین‌جا و به‌صراحت بنویسید. این کار جلسه را از گزارش‌دادن به تصمیم‌گرفتن می‌برد. مدیرعامل نقش خودش را در موفقیت برنامه می‌بیند و فقط تماشاگر آن نیست.
این قالب جادویی نیست و جای گفت‌وگو را نمی‌گیرد. اما اگر آن را هر چند هفته یک‌بار با هم مرور کنید، نقشه راه از سندی که باید از آن دفاع کرد به ابزاری برای تصمیم‌گیری مشترک تبدیل می‌شود. هر بار که فرضیه‌ای تأیید یا رد می‌شود، صفحه را به‌روز کنید و تغییر را با یک جمله توضیح دهید. با گذشت زمان، مدیرعامل به‌جای پرسیدن «چه زمانی؟» می‌پرسد «چه چیزی یاد گرفتیم و قدم بعدی چیست؟». به نظرم این پرسش بهتری برای شروع هر جلسه است.
از کجا شروع کنیم#
لازم نیست همه‌چیز را یک‌شبه عوض کنید. نقشه‌ی راه فعلی را بردارید، سه مورد اول را انتخاب کنید و هرکدام را با قالب فرضیه بازنویسی کنید. اگر برای موردی نتوانستید «نشانه‌ی قابل‌مشاهده» را بنویسید، معمولاً مشکل از قالب نیست. یعنی هنوز نمی‌دانیم آن کار را برای چه می‌کنیم یا چطور می‌فهمیم جواب داده است. این کشف به‌تنهایی ارزش آن نیم‌ساعت وقت را دارد.
یک اشتباه رایج این است که فرضیه دو
پرسش‌های متداول#
چرا نقشه‌ی راه محصول برای مدیرعامل شبیه وعده است؟
وقتی فهرستی از قابلیت‌ها را کنار ماه‌ها می‌گذاریم، آن فهرست خودبه‌خود به تعهد تبدیل می‌شود. مدیرعامل هم آن را همین‌طور می‌خواند، چون برای پاسخ به مشتری، سرمایه‌گذار یا تیم فروش به یک تاریخ نیاز دارد. برای همین تغییری که از نگاه تیم فقط تغییر برنامه است، از نگاه او وعده‌ی شکسته به حساب می‌آید.
مدیرعامل غیرفنی واقعاً می‌خواهد درباره‌ی نقشه‌ی راه چه چیزی بداند؟
او معمولاً می‌خواهد بداند روی چه چیزی و چرا کار می‌کنیم، این کار چه ارتباطی با هدف کسب‌وکار دارد، چه چیزی را عمداً کنار گذاشته‌ایم و کجا ریسک داریم. همچنین می‌خواهد بداند از او چه تصمیم یا کمکی لازم است. جزئیات معماری و چگونگی نوشتن کد جزو این فهرست نیست؛ او می‌خواهد بداند منابع محدود شرکت صرف چه چیزی می‌شود.
به‌جای تاریخ و وعده در نقشه‌ی راه چه بنویسیم؟
به‌جای ماه‌های تقویم، موارد را در سه دسته‌ی «در حال انجام»، «بعدی» و «بعداً» قرار دهید و برای هر مورد یک دلیل کوتاه بنویسید. به‌جای وعده هم فرضیه بنویسید: «باور داریم که [کار] برای [گروه کاربران] باعث [نتیجه] می‌شود. می‌فهمیم درست بوده، وقتی [نشانه‌ی قابل‌مشاهده]». این‌طور مدیرعامل ترتیب و دلیل را می‌بیند و می‌داند با یک آزمون روبه‌رو است، نه قول قطعی.
قالب یک‌صفحه‌ای نقشه‌ی راه شامل چه بخش‌هایی است؟
بالای صفحه هدف کسب‌وکار را در یک یا دو جمله و به زبان خود مدیرعامل می‌نویسید. زیر آن سه ستون «در حال انجام»، «بعدی» و «بعداً» می‌آید که هرکدام حداکثر سه یا چهار مورد دارد و هر مورد یک خط فرضیه و یک خط نشانه‌ی موفقیت. پایین صفحه، بخش‌های «چه چیزی را عمداً کنار گذاشته‌ایم»، «ریسک‌ها و ناشناخته‌ها» و در نهایت «درخواست از مدیرعامل» قرار می‌گیرد.
بیشتر بخوانید#
اگر مفید بود، به اشتراک بگذارید
این نوشته برایتان مفید بود؟
نوشته‌ی
محسن هاشم پور
مدیر محصول و مدیر پروژه؛ نوشتن درباره‌ی ساختن محصول و تحویل پروژه.
