Discovery و Delivery چه تفاوتی دارند و چگونه باید هم‌زمان پیش بروند؟ راهنمای نقش‌ها، جریان کار، معیارها، اشتباه‌ها و اجرای عملی در تیم محصول.
تفاوت Discovery و Delivery را می‌توان با دو سؤال ساده فهمید: در Discovery می‌پرسیم «چه چیزی ارزش ساختن دارد و چرا؟»؛ در Delivery می‌پرسیم «چگونه آن را با کیفیت، ایمن و قابل‌استفاده به دست کاربر برسانیم؟» اولی عدم‌قطعیت درباره مسئله و راه‌حل را کم می‌کند و دومی راه‌حل منتخب را به محصول واقعی تبدیل می‌کند.
اما این دو، دو فاز پشت‌سرهم یا دو تیم جدا نیستند. تیم سالم هم‌زمان یاد می‌گیرد و تحویل می‌دهد: یافته‌های تحقیق روی انتخاب و شکل راه‌حل اثر می‌گذارند، محدودیت‌های فنی Discovery را واقعی‌تر می‌کنند و داده پس از انتشار دوباره ورودی کشف می‌شود. اگر میان آن‌ها دیوار بسازید، خروجی Discovery به «تحویل نیازمندی» و خروجی Delivery به «تکمیل تسک» تقلیل پیدا می‌کند.
این راهنما در ۵ اکتبر ۲۰۲۶ با منابع جاری بازبینی شده است. اگر هنوز برای یک فرصت، فرض و آزمایش مشخص ندارید، ساخت Opportunity Solution Tree با کمک AI و راهنمای آزمایش محصول کم‌هزینه دو مکمل عملی این مقاله‌اند.
Discovery یا کشف محصول مجموعه فعالیت‌هایی است که کمک می‌کند تیم درباره نتیجه مطلوب، مسئله کاربر، فرصت مناسب و راه‌حل قابل‌اتکا تصمیم بگیرد. مصاحبه و مشاهده کاربر، تحلیل داده، ترسیم فرصت‌ها، ایده‌پردازی، پروتوتایپ، آزمایش فرض و بررسی امکان‌پذیری فنی همگی می‌توانند بخشی از آن باشند.
Product Talk در تعریف به‌روز Product Trio تأکید می‌کند مدیر محصول، طراح و مهندس Discovery را با هم هدایت می‌کنند و همین افراد در تیم سازنده حضور دارند؛ نه اینکه گروه تحقیق سندی بسازد و آن را از روی دیوار به تیم توسعه پرتاب کند. خروجی خوب Discovery یک سند قطعی نیست؛ شواهد کافی برای یک تصمیم کوچک‌تر و کم‌ریسک‌تر است.
Discovery معمولاً چهار ریسک را بررسی می‌کند:
SVPG در توضیح چهار ریسک محصول نیز همین تفکیک را مبنای Discovery می‌داند. شدت هر ریسک یکسان نیست؛ برای یک جریان پرداخت، اعتماد و انطباق ممکن است مهم‌تر از جذابیت رابط باشد و برای یک قابلیت AI، کیفیت داده، هزینه و خطای مدل می‌تواند Discovery فنی بیشتری بخواهد.
Delivery یا تحویل محصول، کار تبدیل راه‌حل منتخب به تجربه‌ای production-ready است: طراحی نهایی، معماری، توسعه، تست، امنیت، دسترس‌پذیری، مهاجرت داده، انتشار، مانیتورینگ، پشتیبانی و نگهداشت. هدف فقط «merge شدن کد» نیست؛ قابلیت باید برای کاربر قابل دسترس باشد و سطح کیفیت توافق‌شده را حفظ کند.
در Delivery هنوز یادگیری ادامه دارد. مهندس ممکن است محدودیتی کشف کند که راه‌حل را تغییر دهد، تست کاربردپذیری نسخه نزدیک به تولید مشکلی تازه نشان دهد یا rollout محدود رفتار متفاوتی از پروتوتایپ بسازد. پس Done به معنی «دیگر سؤال نداریم» نیست؛ یعنی این برش از محصول با استاندارد مشخص قابل عرضه و سنجش است.
راهنمای رسمی Scrum مسئولیت تیم را به توسعه محدود نمی‌کند و از تحقیق، آزمایش، نگهداشت و عملیات در کنار سایر فعالیت‌های محصول نام می‌برد. بنابراین می‌توان Discovery را درون یک تیم Scrum انجام داد؛ به شرطی که Sprint فقط کارخانه تبدیل backlog به خروجی نباشد. برای جزئیات این انتخاب، آیا اسکرام هنوز برای تیم‌های محصول مناسب است؟ را بخوانید.
این تفاوت‌ها برای ساخت مرز سازمانی نیستند. راهنمای جاری Atlassian درباره Product Discovery Discovery را پیوسته، داده‌محور و متصل دوطرفه به Delivery توصیف می‌کند؛ وضعیت ساخت به تصمیم‌های محصول برمی‌گردد و شواهد تصمیم همراه کار به تیم اجرا می‌رسد.
نه. «دو مسیر» استعاره‌ای برای دیده‌شدن دو نوع کار است، نه مجوز ساخت دو سیلو. اگر یک تیم فقط مصاحبه کند و تیم دیگر فقط ticket تحویل دهد، دانش در handoff از بین می‌رود و افراد سازنده زمینه تصمیم را نمی‌فهمند. در مقابل، اگر همه کارها را در یک ستون عمومی بگذارید، کار فوری Delivery معمولاً Discovery را می‌بلعد.
مدل عملی‌تر این است: یک تیم، یک outcome و دو جریان قابل‌مشاهده. آیتم Discovery سؤال یا فرض دارد؛ آیتم Delivery برش قابل‌عرضه و معیار کیفیت. ارتباط میان آن‌ها ثبت می‌شود، اما لازم نیست هر فرض فوراً به feature یا هر feature به پروژه تحقیقاتی بزرگ تبدیل شود.
به‌جای «ساخت داشبورد جدید»، نتیجه‌ای مانند «افزایش درصد مدیرانی که تا روز هفتم اولین تصمیم هفتگی را با داده می‌گیرند» تعریف کنید. outcome مرجع هر دو جریان است: Discovery بهترین مداخله را می‌یابد و Delivery آن را قابل استفاده می‌کند.
شواهد قطعی، فرض‌ها و سؤال‌های باز را روی یک صفحه ثبت کنید. سپس چهار ریسک ارزش، کاربردپذیری، امکان‌پذیری و کسب‌وکار را امتیاز دهید. پرریسک‌ترین فرض کم‌شاهد باید زودتر بررسی شود؛ نه جذاب‌ترین قابلیت.
مدیر محصول زمینه کسب‌وکار، طراح رفتار و تجربه، و مهندس محدودیت و فرصت فنی را می‌آورد. هر سه بهتر است بخشی از مصاحبه، مرور داده و تست راه‌حل را ببینند. حضور مهندس پس از نهایی‌شدن mockup، Discovery فنی را به جلسه تخمین دیرهنگام تبدیل می‌کند.
Definition of Ready سنگین نسازید. برای هر گزینه بنویسید کدام ریسک‌ها بررسی شده‌اند، چه چیز هنوز نامعلوم است، کوچک‌ترین برش قابل‌تحویل چیست و چه سیگنالی تصمیم را عوض می‌کند. هدف قطعیت کامل نیست؛ سطحی از اطمینان است که هزینه قدم بعد را توجیه کند.
راه‌حل را طوری محدود کنید که یک مسیر ارزش انتها‌به‌انتها را تحویل دهد. زیرساخت، طراحی، instrumentation، quality و rollout بخشی از همان برش‌اند. یک frontend نمایشی بدون داده واقعی یا backend کامل بدون تجربه کاربر، یادگیری محصول را عقب می‌اندازد.
feature flag، پایلوت یا rollout مرحله‌ای شعاع خطا را کم می‌کند. پیش از انتشار متریک نتیجه، گاردریل‌ها، eventها و آستانه توقف را مشخص کنید. برای جلوگیری از تصمیم روی داده معیوب، اشتباهات رایج تحلیل داده محصول را مرور کنید.
پس از عرضه فقط uptime و تعداد bug را نبینید. رفتار کاربر، کیفیت outcome، تیکت پشتیبانی و هزینه عملیات را مرور کنید. تصمیم بعدی باید روشن باشد: گسترش، اصلاح، آزمایش تکمیلی یا حذف. این حلقه همان چیزی است که مدل خطی «تحقیق، طراحی، ساخت، پایان» از دست می‌دهد.
فرض کنید فقط ۲۴ درصد مشتریان جدید تا پایان هفته اول اولین گزارش را می‌سازند. راه‌حل اولیه تیم، افزودن tutorial طولانی است. در Discovery، سه مصاحبه و مرور sessionها نشان می‌دهد مشکل اصلی آموزش دکمه‌ها نیست؛ کاربران نمی‌دانند کدام منبع داده برای سؤالشان مناسب است.
تیم سه گزینه می‌سازد: wizard انتخاب منبع، templateهای مبتنی بر نقش و جلسه onboarding. با prototype و پنج کاربر، template نقش‌محور سریع‌تر به گزارش معتبر می‌رسد؛ اما مهندس نشان می‌دهد کیفیت template بدون نگاشت schema مشتری پایین می‌آید. یک technical spike و concierge test، حداقل نگاشت لازم را روشن می‌کند.
در Delivery، تیم فقط دو نقش پرتکرار را با instrumentation و fallback می‌سازد، ابتدا برای ۱۰ درصد کاربران منتشر می‌کند و زمان رسیدن به اولین گزارش، نرخ خطا و درخواست پشتیبانی را می‌سنجد. نتیجه نشان می‌دهد تکمیل جریان بهتر شده اما یکپارچه‌سازی منبع دوم افت کرده است. این داده، ورودی Discovery بعدی می‌شود. تیم نه tutorial کامل ساخته و نه پس از release یادگیری را متوقف کرده است.
برای Discovery، تعداد مصاحبه یا prototype به‌تنهایی معیار موفقیت نیست. بهتر است زمان از سؤال تا شاهد، درصد فرض‌های حیاتی آزموده‌شده، زمان تصمیم و تعداد گزینه‌های کنارگذاشته‌شده پیش از ساخت را ببینید. این‌ها باید کنار کیفیت شواهد خوانده شوند؛ سرعت در تولید تحقیق ضعیف مزیت نیست.
برای Delivery، lead time، deployment frequency، نرخ شکست تغییر، زمان بازیابی، defect، accessibility و سلامت سرویس مفیدند. اما این اعداد نیز موفقیت محصول را ثابت نمی‌کنند. یک تیم می‌تواند قابلیت بی‌ارزش را بسیار سریع و پایدار منتشر کند.
معیار اتصال، outcome محصول است: آیا رفتار و ارزش موردنظر تغییر کرد و گاردریل‌ها سالم ماندند؟ معیارهای Discovery و Delivery باید توضیح دهند چرا به آن outcome رسیده‌اید یا نرسیده‌اید، نه اینکه جای آن را بگیرند.
Discovery کمک می‌کند چیز درست را انتخاب کنیم و Delivery کمک می‌کند آن را درست، ایمن و قابل استفاده بسازیم. یکی بدون دیگری یا به یادگیری بی‌اثر ختم می‌شود یا به خروجی سریع اما کم‌ارزش. مزیت واقعی از حلقه‌ای می‌آید که یک تیم مشترک، شواهد، ساخت و نتیجه واقعی را پیوسته به هم وصل می‌کند.
برای شروع، یک آیتم مهم backlog را انتخاب کنید و سه چیز کنار آن بنویسید: outcome موردنظر، پرریسک‌ترین فرض و شاهدی که پس از عرضه تصمیم شما را تغییر می‌دهد. اگر برای طراحی این جریان به بازخورد نیاز دارید، ارزیابی بلوغ محصول تیم، پروداکت کلاب راه چابکی و منتورینگ مدیریت محصول مسیرهای عملی بعدی‌اند.
