این مطلب برای خواندن سریع نوشته نشده؛ برای ساختن یک تصمیم روشن و قابل اجراست.
بسیاری از پروژههای محصول با یک جمله ظاهراً روشن شروع میشوند: «فروش باید بیشتر شود»، «یک باشگاه مشتریان لازم داریم» یا «فرایند ثبتنام را بازطراحی کنید». این جملهها برای آغاز گفتوگو مفیدند، اما هنوز مسئله محصول نیستند. یکی هدف کسبوکار است، دیگری راهحل پیشنهادی و سومی محدوده کار. اگر تیم همین عبارتها را بدون ترجمه وارد طراحی و توسعه کند، هر نقش برداشت خودش را میسازد و اختلاف معمولاً زمانی آشکار میشود که هزینه تغییر بالا رفته است.
فصل اول کتاب «زبان محصول» مسیر «از کسبوکار تا محصول» را دنبال میکند. این مقاله همراهی مستقل و عمومی برای همان مسیر است؛ متن کامل فصل یا جایگزین کتاب نیست. هدف آن ساختن یک قرارداد زبانی ساده است تا بنیانگذار، مدیر محصول، طراح، مهندس و متخصص داده بتوانند یک درخواست تجاری را به صورت مسئلهای قابل بررسی تبدیل کنند.
چرا نیاز کسبوکار با مسئله محصول یکی نیست؟
نیاز کسبوکار تغییری است که سازمان برای بقا، رشد، کارایی یا مدیریت ریسک میخواهد. مسئله محصول توضیح میدهد کدام گروه در چه موقعیتی نمیتواند به نتیجه مطلوب برسد، این اصطکاک چه اثری دارد و برای وجود آن چه شواهدی در دست است. راهحل محصول یکی از گزینههای پاسخ به این مسئله است، نه خود مسئله.
این سه جمله را مقایسه کنید:
- «باید نرخ تمدید افزایش پیدا کند» یک نتیجه مطلوب کسبوکار است.
- «باید سیستم امتیازدهی بسازیم» یک راهحل پیشنهادی است.
- «مشتریانی که نزدیک پایان اشتراک هستند، ارزش استفادهشده و پیامد تمدیدنکردن را نمیبینند و تصمیم را تا لحظه آخر عقب میاندازند» یک صورت مسئله قابل بررسی است.
جمله سوم هنوز حقیقت قطعی نیست. یک فرض منظم است که باید با رفتار، داده و گفتوگو بررسی شود. همین تفاوت مهم است: زبان مشترک قرار نیست اختلاف را حذف کند؛ قرار است معلوم کند درباره داده، برداشت، هدف یا راهحل اختلاف داریم.
راهنمای رسمی GOV.UK درباره نیازهای کاربر نیز پیشنهاد میکند تمرکز روی مسئله کاربر باشد، نه یک راهحل از پیش انتخابشده؛ برای نمونه «نیاز به یادآوری» با «نیاز به ایمیل» یکسان نیست. این جداسازی به تیم اجازه میدهد چند پاسخ ممکن را ببیند.
قرارداد زبانی تیم از چه واژههایی شروع میشود؟
تیم به فرهنگ لغت بلند نیاز ندارد؛ ابتدا باید چند واژه پرکاربرد را با مرز روشن تعریف کند. در هر پروژه این قرارداد را کنار سند تصمیم نگه دارید و اگر کاربرد واژه تغییر کرد، آن را بهروزرسانی کنید.
سیگنال کسبوکار
مشاهدهای است که توجه سازمان را جلب کرده: کاهش تمدید، افزایش تماس پشتیبانی، طولانیشدن چرخه فروش یا رشد هزینه عملیات. سیگنال میگوید کجا را نگاه کنیم، اما علت را ثابت نمیکند.
هدف کسبوکار
تغییری است که سازمان میخواهد ببیند. هدف باید جهت بدهد، اما نباید تیم را به یک قابلیت خاص متعهد کند. «کاهش ریزش قابل پیشگیری» هدف است؛ «ساخت پنل وفاداری» راهحل است.
نیاز کاربر
نتیجهای است که یک فرد یا نقش در زمینه مشخص میخواهد به آن برسد. نیاز از خود محصول بزرگتر است. کاربر لزوماً «داشبورد» نمیخواهد؛ ممکن است بخواهد پیش از تماس با مشتری بداند کدام سفارش در معرض تأخیر است.
مسئله محصول
شکاف میان وضعیت فعلی و نتیجه مطلوب است که محصول میتواند بهطور معنادار روی آن اثر بگذارد. مسئله باید گروه، زمینه، مانع، پیامد و شاهد فعلی را مشخص کند.
فرض
گزارهای است که هنوز برای تصمیمگیری به شاهد بیشتری نیاز دارد. نوشتن واژه «فرض» کنار جمله، ضعف نیست؛ از تبدیل حدس مدیر به حقیقت سازمانی جلوگیری میکند.
راهحل
تغییری در تجربه، فرایند، محتوا، سیاست، عملیات یا فناوری است که برای اثرگذاشتن بر مسئله پیشنهاد میشود. قابلیت نرمافزاری فقط یکی از شکلهای راهحل است.
برای دیدن شبکه کاملتر مفاهیم و مسیرهای مطالعه نقشمحور، صفحه کتاب زبان محصول نقطه مرجع این کلاستر است.
ترجمه را با یک زنجیره پنجمرحلهای انجام دهید
بهجای اینکه درخواست مدیر مستقیم وارد backlog شود، آن را از این زنجیره عبور دهید. هر مرحله سؤال خاص خود را دارد و خروجی مرحله قبل را دقیقتر میکند.
۱. سیگنال را بدون تفسیر ثبت کنید
بگویید چه چیزی مشاهده شده، در چه بازه یا موقعیتی و منبع آن چیست. «کاربران ناراضیاند» مبهم است. «در مکالمات لغو، ابهام درباره ارزش استفادهشده تکرار شده» دقیقتر است، اما هنوز باید کیفیت و دامنه داده بررسی شود. اگر داده عددی معتبر ندارید، عدد نسازید؛ منبع کیفی و محدودیت آن را بنویسید.
۲. نتیجه مطلوب کسبوکار را جدا کنید
از صاحب درخواست بپرسید اگر این پروژه موفق باشد چه تغییری در تصمیم یا عملکرد سازمان رخ میدهد. سپس روشن کنید این نتیجه در اختیار محصول است یا عوامل دیگری مانند قیمت، فروش، عملیات و بازار نیز بر آن اثر دارند. محصول را مسئول متغیری نکنید که کنترل کافی روی آن ندارد.
۳. گروه و زمینه را محدود کنید
«کاربران» یک گروه عملیاتی نیست. بگویید کدام دسته، در کدام مرحله سفر و هنگام انجام چه کاری با مانع روبهرو است. بخشبندی بر اساس رفتار و زمینه معمولاً از دستهبندی صرفاً جمعیتشناختی برای تصمیم محصول مفیدتر است.
۴. مانع و پیامد را صورتبندی کنید
مانع باید قابل مشاهده یا قابل بررسی باشد. پیامد توضیح میدهد چرا حل آن مهم است. کاربر چه زمان، پول، اعتماد یا فرصتی از دست میدهد؟ سازمان چه هزینه یا ریسکی متحمل میشود؟ اگر پیامد روشن نیست، ممکن است با ناراحتی کماهمیت یا یک درخواست موردی روبهرو باشید.
۵. شاهد و سؤال باز را کنار مسئله بنویسید
صورت مسئله نهایی نباید قطعیت جعلی بسازد. زیر آن دو بخش بگذارید: «آنچه میدانیم» و «آنچه هنوز باید بفهمیم». این کار مسیر فرآیند کشف محصول را به تعریف مسئله وصل میکند و مانع میشود جلسه همترازی با جلسه اثبات ایده اشتباه شود.
چهار نقش یک جمله را چگونه متفاوت میخوانند؟
فرض کنید جمله اولیه این است: «باید ورود کاربران سریعتر شود.» هر نقش سؤال مشروع اما متفاوتی دارد.
- کسبوکار: کندی ورود چه اثری بر فعالسازی، هزینه پشتیبانی یا درآمد دارد؟
- محصول و تحقیق: کدام کاربر، در کدام زمینه و دقیقاً در کدام مرحله متوقف میشود؟
- طراحی: مشکل از فهم مسیر، بار شناختی، بازخورد رابط یا دسترسپذیری است؟
- مهندسی و امنیت: کندی ادراکشده است یا واقعی؟ کدام محدودیت فنی، امنیتی یا وابستگی وجود دارد؟
- داده: رویدادها چه چیزی را ثبت میکنند و چه بخشی از مسیر اندازهگیری نمیشود؟
هیچکدام از این سؤالها بهتنهایی مسئله را کامل نمیکند. اگر زبان مشترک نباشد، کسبوکار درباره نتیجه حرف میزند، طراحی درباره تجربه، مهندسی درباره زمان پاسخ و داده درباره event؛ همه درست میگویند اما تصور میکنند دیگری پاسخ سؤال آنها را داده است.
یک سند مشترک باید این لنزها را کنار هم بگذارد، نه اینکه همه را مجبور کند با ادبیات مدیر محصول حرف بزنند. سواد همکاری یعنی هر نقش منطق و محدودیت نقش دیگر را تا حد تصمیم مشترک بفهمد، بدون اینکه تخصصها حذف شوند.
ضدتعریفها: مسئله محصول چه چیزی نیست؟
مرز مفاهیم با مثال مخالف روشنتر میشود. این ضدتعریفها را در بازبینی brief استفاده کنید.
مسئله، فیچرِ منفیشده نیست
«کاربر امکان فیلتر پیشرفته ندارد» معمولاً راهحل را در لباس مسئله پنهان میکند. بپرسید کاربر بدون فیلتر نمیتواند چه کاری انجام دهد و امروز چگونه آن را جبران میکند.
مسئله، KPI تنها نیست
«نرخ تبدیل پایین است» یک سیگنال است. مشخص نمیکند چه کسی، چرا و در کدام زمینه از رسیدن به نتیجه بازمیماند. KPI جهت تحقیق میدهد، نه تعریف کامل مسئله.
مسئله، نظر ذینفع نیست
درخواست مشتری مهم یا مدیر ارشد باید جدی گرفته شود، اما جای شاهد را نمیگیرد. آن را به فرض تبدیل کنید و دامنه اثر را بررسی کنید.
مسئله، شکایت منفرد نیست
یک شکایت میتواند نشانه مسئله عمیق باشد یا یک مورد استثنایی. زمینه، فراوانی، شدت و راهحل موقت را بررسی کنید. لازم نیست برای معتبرشدن هر مسئله حتماً داده بزرگ داشته باشید، اما باید محدودیت شواهد را صریح بنویسید.
مسئله، مأموریت بیمرز نیست
«بهبود تجربه مشتری» آنقدر وسیع است که اولویت نمیسازد. صورت مسئله باید به تیم بگوید چه چیزی داخل دامنه تصمیم است و چه چیزی فعلاً خارج از آن میماند.
یک مثال فرضی از ترجمه درخواست تجاری
سناریوی زیر ساختگی است و به پروژه واقعی یا نتیجه واقعی نسبت داده نمیشود. هدف آن نشاندادن قالب گفتوگو است.
مدیر یک فروشگاه آنلاین میگوید: «برای کاهش تماسها یک چتبات لازم داریم.» تیم اگر مستقیم وارد اجرا شود، راهحل از قبل انتخاب شده است. گفتوگو با پرسش درباره سیگنال شروع میشود. پاسخ: تعداد زیادی از تماسها درباره زمان رسیدن سفارش است. هدف کسبوکار کاهش بار پاسخگویی و حفظ اعتماد مشتری است.
تیم داده بررسی میکند که وضعیت ارسال در سیستم ثبت میشود، اما گاهی با تأخیر به صفحه سفارش میرسد. تحقیق کیفی محدود نشان میدهد برخی مشتریان عبارتهای وضعیت را نمیفهمند و نمیدانند آیا باید اقدامی انجام دهند. عملیات هم توضیح میدهد که بعضی تأخیرها خارج از کنترل فروشگاه است.
صورت مسئله موقت میتواند چنین باشد: «مشتریانی که سفارش آنها از زمان وعدهدادهشده عبور میکند، وضعیت بهروز و اقدام بعدی را به زبان روشن نمیبینند؛ بنابراین برای اطمینان با پشتیبانی تماس میگیرند. هنوز نمیدانیم سهم تأخیر داده، ابهام متن و نبود اطلاعرسانی پیشدستانه چقدر است.»
اکنون چتبات فقط یکی از گزینههاست. گزینههای دیگر شامل اصلاح وضعیتها، اطلاعرسانی پیشدستانه، نمایش زمان آخرین بهروزرسانی یا بهبود فرایند داده است. یک MVP برای یادگیری میتواند کمهزینهترین فرض را بررسی کند، نه اینکه نسخه ناقصی از چتبات نهایی بسازد.
تمرین تیمی: قرارداد مسئله در یک صفحه
این تمرین را میتوان بدون ابزار خاص و در یک جلسه کوتاه انجام داد. پیش از جلسه، صاحب درخواست سیگنال و هدف را مینویسد. در جلسه، هر نقش ابتدا مستقل پاسخ میدهد تا نظر فرد ارشد از ابتدا بقیه را جهت ندهد. سپس پاسخها مقایسه میشوند.
قالب یکصفحهای:
- سیگنال: چه چیزی توجه ما را جلب کرده و منبع آن چیست؟
- هدف کسبوکار: چه تغییری میخواهیم و چرا اکنون؟
- گروه و زمینه: چه کسی هنگام انجام چه کاری با مانع روبهرو است؟
- مانع و پیامد: چه چیزی جلوی نتیجه را میگیرد و اثر آن چیست؟
- شواهد موجود: چه مشاهده، داده یا منبعی داریم؟
- فرضها: کدام بخش هنوز حدس است؟
- گزینهها: چه پاسخهایی غیر از راهحل اولیه ممکن است؟
- سؤال تصمیم: برای انتخاب گام بعدی چه چیزی باید روشن شود؟
- خارج از دامنه: فعلاً چه چیزی را حل نمیکنیم؟
- صاحب و تاریخ بازبینی: چه کسی تصمیم را نگه میدارد و چه زمانی برمیگردیم؟
شورای طراحی در چارچوب Double Diamond، مرحله Discover را فهم مسئله بهجای فرضکردن آن و مرحله Define را بازتعریف چالش بر اساس یافتهها توضیح میدهد. تمرین بالا همین حرکت را در مقیاس یک تصمیم تیمی اجرا میکند: ابتدا نگاهها باز میشوند و سپس دامنه بر اساس شاهد محدود میشود.
چکلیست یک صورت مسئله قابل استفاده
پیش از تبدیل مسئله به فرصت، آزمایش یا backlog این سؤالها را مرور کنید:
- آیا هدف کسبوکار از راهحل پیشنهادی جدا نوشته شده است؟
- آیا گروه و زمینه استفاده مشخصاند؟
- آیا نیاز با نام یک قابلیت بیان نشده است؟
- آیا مانع و پیامد هر دو روشناند؟
- آیا شاهدها از فرضها جدا شدهاند؟
- آیا نقشهای کسبوکار، طراحی، فنی و داده یک معنی مشترک از جمله دارند؟
- آیا گزینه «نسازیم» یا تغییر فرایند بررسی شده است؟
- آیا سؤال باز و کمهزینهترین راه یادگیری مشخص است؟
- آیا دامنه و خارج از دامنه نوشته شدهاند؟
- آیا صاحب تصمیم و زمان بازبینی معلوم است؟
زبان مشترک قرار نیست همه را همعقیده کند. خروجی خوب این است که اختلاف دقیقتر شود: درباره اهمیت مسئله اختلاف داریم، درباره اعتبار شاهد، درباره محدودیت اجرا یا درباره انتخاب راهحل. وقتی نوع اختلاف روشن باشد، تصمیم هم قابل پیگیری میشود.
اگر میخواهید این شبکه مفاهیم را با مسیرهای جدا برای نقشهای مختلف و نمونههای تصمیم دنبال کنید، میتوانید از طریق درخواست نسخه کتاب زبان محصول مشخصات نسخه را دریافت کنید. این مقاله ارزش مستقل دارد؛ کتاب دامنه واژهها، ارتباط میان فصلها و کاربرد آنها در موقعیتهای بیشتری را گسترش میدهد.
مطالعه کافی نیست؛
قدم بعدی را انتخاب کنید.
یکی از مسیرهای مرتبط را ادامه دهید یا همین حالا موضوع را به یک اقدام واقعی تبدیل کنید.
درخواست نسخه کتاب