بیشتر MVPها در مرحلهٔ ساخت شکست نمی‌خورند. در سؤالی شکست می‌خورند که هیچ‌کس در هفتهٔ صفر نپرسید.
الگوی تکراری این است: تیم شش هفته کد می‌زند، محصول را منتشر می‌کند، و بعد متوجه می‌شود نمی‌داند چه چیزی را قرار بود یاد بگیرد. کد کار می‌کند. هیچ‌کس نمی‌داند نتیجه یعنی چه.
این چک‌لیست برای بستن همان شکاف است.
«آماده» یعنی چه و یعنی چه نیست
آمادگی MVP یعنی می‌دانید این نسخه قرار است چه فرضی را آزمایش کند، چطور نتیجه را می‌سنجید، و در چه شرایطی متوقفش می‌کنید.
آمادگی به معنی داشتن طرح کامل، تیم کامل، یا بودجهٔ کافی نیست. تیم‌هایی با هر سهٔ این‌ها MVPهای بی‌فایده ساخته‌اند. آمادگی یک شرط شناختی است، نه یک شرط منابع.
دوازده سؤال زیر در چهار دستهٔ سه‌تایی‌اند. هر سؤال یا پاسخ مشخص دارد یا ندارد؛ پاسخ «تقریباً» به‌معنی نداشتن است.
وضوح مسئله — سه سؤال
- مشکلی که حل می‌کنید، امروز چطور حل می‌شود؟ اگر پاسخ «حل نمی‌شود» است، احتمالاً به‌اندازهٔ کافی نگاه نکرده‌اید. آدم‌ها همیشه یک راه‌حل دست‌وپاشکسته دارند؛ رقیب واقعی شما همان است، نه محصول مشابه.
- چه کسی امروز برای این مشکل پول یا زمان می‌دهد؟ نام ببرید. اگر نمی‌توانید نام ببرید، هنوز فرضیه دارید، نه مسئله.
- اگر این محصول هرگز ساخته نشود، چه اتفاقی برای آن‌ها می‌افتد؟ اگر پاسخ «هیچ خاصی» است، مسئله واقعی است ولی فوری نیست — و فوری‌نبودن، کشندهٔ MVPهاست.
دسترسی به کاربر — سه سؤال
- می‌توانید همین هفته با ده نفر از مخاطبان هدف صحبت کنید؟ نه ده نفر آشنا. ده نفر که مشکل را واقعاً دارند.
- چه کسی اولین کاربر واقعی است و چرا بله می‌گوید؟ یک شخص مشخص، با انگیزهٔ مشخص.
- وقتی محصول آماده شد، چطور به دستشان می‌رسد؟ اگر پاسخ «بازاریابی می‌کنیم» است، مسیر توزیع ندارید.
سؤال چهارم بیشترین تعداد پروژه را متوقف می‌کند و بهترین سؤال کل فهرست است. اگر رسیدن به ده کاربر بالقوه یک هفته طول می‌کشد، رسیدن به هزار کاربر یک سال طول می‌کشد و مدل رشد شما هنوز وجود ندارد.
انضباط دامنه — سه سؤال
- کوچک‌ترین چیزی که فرض اصلی را آزمایش می‌کند چیست؟ اگر پاسخ بیش از یک جمله شد، هنوز کوچک نشده.
- چه چیزهایی را عمداً نمی‌سازید؟ فهرست کنید. فهرست نساخته‌ها همان قراردادی است که در هفتهٔ چهارم از شما محافظت می‌کند.
- کدام بخش را می‌شود با کار دستی جایگزین کرد؟ ورود داده، تطبیق، تأیید — بیشتر این‌ها در نسخهٔ اول می‌توانند انسانی باشند بدون اینکه یادگیری آسیب ببیند.
سنجه‌ها و قانون توقف — سه سؤال
- چه عددی نشان می‌دهد این کار کرد؟ یک عدد، نه یک داشبورد.
- چه عددی نشان می‌دهد کار نکرد؟ این را باید قبل از انتشار بنویسید.
- چقدر زمان و پول حاضرید صرف کنید تا آن عدد را ببینید؟ سقف را الان تعیین کنید.
سؤال یازدهم رایج‌ترین جای خالی است. تیم‌ها معیار موفقیت را تعریف می‌کنند و معیار شکست را نه، پس هیچ نتیجه‌ای هرگز به توقف ختم نمی‌شود — همیشه یک تفسیر خوش‌بینانه در دسترس است.
نمره‌دهی: پاسخ ضعیف بعداً چقدر هزینه دارد
| دسته | پاسخ مبهم چه چیزی می‌سازد | هزینهٔ معمول |
|---|---|---|
| وضوح مسئله | محصولی که کار می‌کند و کسی نمی‌خواهد | کل چرخهٔ ساخت |
| دسترسی به کاربر | محصول آماده، بدون مسیر رسیدن | سه تا شش ماه تأخیر |
| انضباط دامنه | دامنه دو برابر، یادگیری همان | دو تا سه برابر شدن زمان |
| سنجه و قانون توقف | نتیجهٔ مبهم، ادامهٔ بی‌پایان | هزینهٔ فرصتِ نامحدود |
قاعدهٔ عملی: اگر در یک دسته دو سؤال از سه سؤال پاسخ روشن ندارند، آن دسته پیش از شروع کد باید بسته شود.
چطور این را در یک جلسهٔ ۹۰ دقیقه‌ای اجرا کنید
چک‌لیستی که به یک سند تبدیل شود، خوانده نمی‌شود. چیزی که جواب می‌دهد، یک جلسهٔ کوتاه با یک قاعدهٔ سخت است.
سه نفر بیشتر نباشند: کسی که محصول را می‌سازد، کسی که با مشتری حرف می‌زند، و یک نفر بیرونی که هیچ منفعتی در ادامهٔ پروژه ندارد. نفر سوم مهم‌ترین است. تیمی که خودش را ارزیابی می‌کند، همیشه پاسخ‌های مبهم را قابل قبول می‌بیند.
قاعدهٔ سخت: هر سؤال حداکثر پنج دقیقه. اگر در پنج دقیقه به یک جملهٔ روشن نرسیدید، پاسخ «نداریم» ثبت می‌شود و بحث تمام. تلاش برای رسیدن به پاسخ در جلسه، دقیقاً همان جایی است که تیم‌ها فرض را جای واقعیت می‌گذارند.
خروجی جلسه یک صفحه است: دوازده سؤال، دوازده پاسخ یا خط تیره، و فهرست کارهای تحقیقی برای خط‌تیره‌ها. اگر بیش از چهار خط تیره داشتید، هنوز وقت کدنویسی نیست.
چرا دوازده سؤال، نه چهل
فهرست‌های بلندتر وجود دارند و بیشترشان بی‌فایده‌اند، چون یک چک‌لیست چهل‌سؤالی به تشریفات تبدیل می‌شود. تیم تیک می‌زند تا رد شود.
این دوازده سؤال انتخاب شده‌اند چون هرکدام یک نوع شکست متفاوت را پوشش می‌دهند و هیچ‌کدام با دیگری همپوشانی ندارد. اگر سؤالی به فهرست اضافه می‌کنید، باید بتوانید بگویید کدام شکستِ پوشش‌داده‌نشده را می‌بندد. اگر نتوانستید، اضافه‌اش نکنید.
یک نمونهٔ واقعی: تیمی که سؤال یازدهم را نداشت
یک تیم دو نفره ابزاری برای مدیریت نوبت‌دهی کلینیک‌های کوچک ساخت. هفت هفته کار، محصول تمیز، سه کلینیک اول رایگان.
بعد از دو ماه: هر سه کلینیک هنوز استفاده می‌کردند، ولی هیچ‌کدام حاضر به پرداخت نبود. تیم این را نشانهٔ نیاز به فیچر بیشتر خواند و سه ماه دیگر ساخت.
مسئله فیچر نبود. آن‌ها معیار موفقیت را «استفادهٔ مستمر» تعریف کرده بودند، که یک معیار درست برای یک محصول رایگان است و هیچ چیزی دربارهٔ تمایل به پرداخت نمی‌گوید. اگر سؤال یازدهم پرسیده شده بود — «چه عددی نشان می‌دهد این کار نکرد؟» — پاسخ احتمالاً می‌شد «اگر بعد از هشت هفته هیچ کلینیکی حاضر به پرداخت نشد». آن قانون، پنج ماه را نجات می‌داد.
مبادله‌ای که این چک‌لیست تحمیل می‌کند
پاسخ‌دادن به این دوازده سؤال بین سه روز تا دو هفته طول می‌کشد و حس بدی دارد، چون شبیه کار نیست. کد زدن حس پیشرفت می‌دهد؛ پاسخ‌دادن به سؤال یازدهم نمی‌دهد.
در مقابل، بیشترین چیزی که از دست می‌دهید دو هفته است. بیشترین چیزی که یک MVP بی‌فرض از دست می‌دهد، یک فصل کامل است.
اگر بعضی پاسخ‌ها را نمی‌دانم چه کنم؟
ندانستن مشکل نیست؛ ندانستن و شروع‌کردن مشکل است. هر سؤال بی‌پاسخ را به یک کار تحقیقی یک‌روزه تبدیل کنید.
آیا این برای محصول داخلی هم صدق می‌کند؟
بله، و دستهٔ دوم حتی مهم‌تر می‌شود. محصولات داخلی معمولاً کاربر تضمین‌شده فرض می‌شوند، در حالی که پذیرش داخلی همان‌قدر شکننده است.
چند وقت یک‌بار باید بازبینی شود؟
در هر تغییر جدی فرض. پاسخ‌های هفتهٔ صفر بعد از دیدن سی کاربر واقعی دیگر معتبر نیستند.
جمع‌بندی
MVP یک محصول کوچک نیست. یک آزمایش است که تصادفاً شکل محصول دارد. اگر نمی‌توانید بگویید چه چیزی را آزمایش می‌کند، فقط دارید نرم‌افزار می‌سازید.
اگر می‌خواهید این دوازده سؤال را روی ایدهٔ خودتان و با یک نگاه بیرونی مرور کنید، بررسی آمادگی MVP دقیقاً همین کار را می‌کند.
نظرات (0)
برای ثبت نظر باید وارد حساب کاربری خود شوید.
ورود / ثبت‌نام