MVP چیست؟ نسخهٔ اول محصول را چطور بسازیم که پولت هدر نرود
MVP یعنی «نسخهٔ ارزان و بی‌کیفیت» نیست. یعنی کوچک‌ترین چیزی که بتواند خطرناک‌ترین فرض تو را امتحان کند. این نوشته می‌گوید چطور آن فرض را پیدا کنی و چه چیزی را در نسخهٔ اول بگذاری و چه چیزی را نه.
«MVP» را اغلب اینطور می‌فهمند: نسخه‌ای ارزان‌تر از محصول اصلی، با کیفیت کمتر، که بعداً کاملش می‌کنیم. این تعریف باعث می‌شود آدم‌ها یا پول زیادی خرج چیزی کنند که لازم نبود، یا چیزی بسازند که به‌خاطر کم‌کاری هیچ‌چیزی را ثابت نمی‌کند.
تعریف به‌دردبخورتر این است: MVP کوچک‌ترین چیزی است که می‌شود ساخت تا مهم‌ترین چیزی که نمی‌دانی را بفهمی.
اول بپرس: چه چیزی را نمی‌دانم؟
هر ایدهٔ محصول روی چند فرض ایستاده، و بعضی‌شان خطرناک‌ترند. معمولاً سه دسته‌اند:
- آیا کسی این مشکل را دارد؟ و آن‌قدر جدی که دنبال راه‌حل بگردد؟
- آیا راه‌حل من را می‌پذیرند؟ و حاضرند به‌خاطرش عادتشان را عوض کنند، یا حتی پول بدهند؟
- آیا می‌شود ساختش؟ با این بودجه، این زمان و این داده‌ها.
بیشتر ایده‌ها در فرض اول و دوم می‌میرند، نه سوم. ولی بیشتر پول در سوم خرج می‌شود: چون ساختن، ملموس‌ترین کار است. MVP خوب اول همان فرضی را می‌آزماید که اگر غلط باشد، بقیه بی‌معنی است.
چهار راه برای آزمودن ایده، قبل از نوشتن کد
بسیاری از ایده‌ها را می‌شود بدون یک خط کد جان‌دار آزمود. این‌ها هر کدام زودتر از یک اپلیکیشن کامل جواب می‌دهند:
- صفحهٔ معرفی و فرم ثبت‌نام. یک صفحه که توضیح می‌دهد محصول چه می‌کند و دکمهٔ «می‌خواهم» دارد. اگر صد نفر را به آن بیاوری و کسی نخواست، همین جواب است. آزمودن علاقهٔ مردم با این کار چند روز طول می‌کشد، نه چند ماه.
- انجام دستی پشت‌صحنه. کاربر فکر می‌کند سیستم خودکار است، ولی پشتش خودت با اکسل و تلفن کار را انجام می‌دهی. نمی‌توانی میلیون‌ها کاربر را اینطور نگه داری، ولی ده کاربر اول را می‌توانی؛ و در همان ده نفر یاد می‌گیری چه چیزی را خودکار کنی.
- ابزارهای آماده. فرم، جدول، پرداخت و پیامک را اغلب می‌شود با سرویس‌های موجود سر هم کرد. زشت‌تر است و کندتر، ولی ارزان است و فرض را می‌آزماید.
- نمونهٔ قابل‌کلیک. یک طرح تعاملی از صفحه‌ها که هنوز هیچ منطقی پشتش نیست. برای فهمیدن «آیا مردم این جریان را می‌فهمند؟» کافی است.
کد زدن وقتی لازم می‌شود که دستی کردن دیگر جواب نمی‌دهد، یا وقتی خودِ نرم‌افزار همان چیزی است که می‌خواهی امتحانش کنی؛ مثلاً سرعت، دقت یا یک تجربهٔ کاربری که با ابزار آماده نمی‌شود.
چه چیزی در نسخهٔ اول باشد
یک فیلتر ساده: برای هر قابلیت بپرس «اگر این نباشد، کاربر هنوز می‌تواند به نتیجه‌ای که برایش آمده برسد؟» اگر بله، در نسخهٔ اول جایی ندارد.
معمولاً باید باشد:
- جریان اصلی از اول تا آخر. یک نفر بیاید، کاری که برایش آمده را انجام بدهد و تمام شود. زشت یا ساده، ولی کامل.
- چیزهای ملال‌آور که شوخی‌بردار نیستند. پشتیبان‌گیری از داده‌ها، ورود امن، و هر جایی که پول یا اطلاعات شخصی دست‌به‌دست می‌شود. «نسخهٔ اول» بهانه‌ای برای درست‌نبودن این‌ها نیست.
- راهی برای دیدن چه می‌شود. چند عدد ساده که بگوید کسی چه کرد و کجا ول کرد. بدون این، MVP چیزی را نمی‌آزماید.
معمولاً نباید باشد:
- نقش‌های متعدد کاربری و سطح‌های دسترسی پیچیده،
- گزارش‌های رنگارنگ،
- چندزبانه‌بودن و تنظیمات بی‌پایان،
- هر چیزی که با عبارت «بعداً ممکن است لازم شود» شروع می‌شود.
کوچک بودن یعنی کم‌کیفیت بودن نیست
یک تفاوت مهم هست: کوچک بودنِ دامنه، با نامرتب بودنِ کد یکی نیست. می‌شود کم‌قابلیت ولی تمیز ساخت. و چیزی که بعداً گران‌تر از همه تمام می‌شود، قابلیت‌های جا افتاده نیست؛ مدل داده‌ای است که از اول غلط طراحی شده.
ظاهر و متن‌ها را به‌راحتی عوض می‌کنی، ولی ساختار داده‌ها را نه. پس همان‌جا که نسخهٔ اول را کوچک نگه می‌داری، روی «داده‌ها چطور نگه‌داری می‌شوند» وقت بگذار. دو ساعت فکر در این‌جا، چند هفته بازنویسی را کم می‌کند.
قبل از شروع، معیار را بنویس
بنویس: «اگر بعد از چهار هفته X نفر Y کار را انجام دادند، ادامه می‌دهیم. اگر نه، چیز دیگری امتحان می‌کنیم.» این معیار را قبل از ساختن بنویس، نه بعدش. بعد از ساختن، همه عاشق چیزی شده‌اند که ساخته‌اند و هر عددی را به نفع خودشان تفسیر می‌کنند.
عدد دقیق مهم نیست؛ مهم این است که از قبل مشخص باشد، تا نتیجه نظر شخصی نباشد.
جمع‌بندی
MVP خوب سه چیز دارد: یک فرض مشخص که قرار است بیازماید، دامنه‌ای که بتواند فقط همان را بیازماید، و معیاری که از قبل تعیین کرده نتیجه یعنی چه. با بریف روشن شروع می‌شود؛ اگر هنوز بریف ننوشته‌ای، این راهنما کمک می‌کند. و اگر می‌خواهی بدانی چنین کاری از کجا قیمت می‌گیرد، این نوشته جواب می‌دهد.