فهرست مطالب
ساخت MVP برای ابزار داخلی یعنی ساخت کوچکترین نسخهای از یک ابزار که بتواند یک کار واقعی را برای کسانی که از آن استفاده میکنند، روی فایلهای واقعی پروژه انجام دهد، و سنجش اینکه آیا این کار را درست انجام داده است یا خیر. در ابزار داخلی، کاربران همکاران خود شما هستند و بازاری برای آزمون وجود ندارد. در نتیجه، پرسش محدودتر است: آیا این ابزار زمان را کاهش میدهد، آیا نتیجه را درست به دست میآورد و آیا همکاران پس از هفته‌ی نخست همچنان از آن استفاده میکنند؟ MVP برای پاسخ به همین پرسش ساخته میشود.
اثبات مفهوم و نمونهی اولیه پیش از MVP قرار می‌گیرند و هرکدام به پرسش دیگری پاسخ می‌دهند. توسعه‌ی نمونهی اولیه‌ی نرم‌افزار زمانی بیشترین فایده را دارد که هر مرحله اجازه داشته باشد کوچک بماند.
یکی از نخستین پروژه‌های پژوهشی ما به داده‌های تولیدشده نیاز داشت. ۶۰۰ داده‌ی نخست به‌صورت دستی ساخته شد و واکنشی که دریافت کرد این بود: «۶۰۰؟ واقعاً؟ همین؟» همین واکنش باعث شد کار دستی متوقف شود و یک سامانه‌ی تولید داده ساخته شود که حدود ۲۲٬۰۰۰ پیکربندی تولید کرد و به نخستین مقاله‌ی منتشرشده تبدیل شد. آن ۶۰۰ داده کار خود را انجام داده بودند: نشان دادند تولید این داده ارزش دارد و سامانه‌ی تولید باید چه چیزهایی را درست انجام دهد. MVPای که کار میکند، نیمی از کار خود را انجام داده است. کار آن زمانی تمام میشود که بدانید چرا کار میکند.
MVP وقتی کاربران آن همکاران خود شما هستند
Eric Ries، که اصطلاح MVP با کتاب Lean Startup شناخته شد، آن را نسخهای از محصول تعریف میکند که با کمترین تلاش، بیشترین یادگیری تأییدشده را درباره‌ی مشتریان فراهم کند. Frank Robinson، که این اصطلاح را پیش از او به کار برده بود، MVP را محصولی با اندازهی مناسب می‌داند: به اندازه‌ای بزرگ که پذیرفته شود و به اندازه‌ای کوچک که پرریسک نباشد.
هر دو تعریف برای محصولی نوشته شده‌اند که باید مشتری پیدا کند. ابزار داخلی شرایط متفاوتی دارد و این تفاوت‌ها شکل MVP را تغییر می‌دهند:
- کاربران مشخص‌اند. می‌دانید چه کسانی از ابزار استفاده میکنند و می‌توانید کنار آنها بنشینید و کارشان را ببینید.
- معیار موفقیت قابل‌اندازه‌گیری است. زمان انجام یک کار، تعداد خطاها یا تعداد دفعاتی که یک فایل دوباره ارسال میشود، پیش از ساخت قابل‌ثبت است.
- رقیب اصلی روش فعلی است. ابزار داخلی با Excel، با کپی‌کردن دستی و با عادت چندساله‌ی تیم رقابت میکند.
ابزار داخلی کاربرانی دارد که نمی‌توانند به محصول رقیب بروند. اما می‌توانند به Excel برگردند و معمولاً از روز دوم، بی‌آنکه چیزی بگویند، همین کار را میکنند.
اثبات مفهوم، نمونهی اولیه و MVP به سه پرسش متفاوت پاسخ می‌دهند
این سه اصطلاح اغلب به‌جای یکدیگر به کار می‌روند، اما هرکدام پرسش خود را دارد و مرحله‌ای که پرسش آن هنوز پاسخ داده نشده، نباید نادیده گرفته شود:
- اثبات مفهوم (PoC): آیا از نظر فنی امکانپذیر است؟ مثلاً آیا Revit API اطلاعات موردنیاز را از این نوع المان در اختیار می‌گذارد، یا آیا خروجی نرم‌افزار دیگر ساختار قابل‌خواندنی دارد؟ نتیجه‌ی آن معمولاً کدی است که فقط سازنده‌ی آن اجرایش میکند.
- نمونهی اولیه: آیا ابزار باید به این شکل کار کند؟ ورودی‌ها، ترتیب مراحل و شکل خروجی به کاربران نشان داده میشود، حتی اگر پشت آن هنوز داده‌ی ساختگی باشد.
- MVP: آیا ابزار در کار واقعی نتیجه میدهد؟ یک جریان کاری، یک تیم، فایلهای واقعی پروژه و معیاری که پیش از ساخت ثبت شده است.
اثبات مفهوم نرم‌افزار زمانی لازم است که ریسک اصلی فنی باشد. نمونهی اولیه زمانی لازم است که ریسک اصلی در شیوه‌ی استفاده باشد. اگر هیچ‌کدام از این دو ریسک جدی نیست، می‌توانید مستقیماً سراغ MVP بروید.
چه زمانی یک ابزار داخلی ارزش ساخت MVP دارد
همه‌ی ایده‌ها به نرم‌افزار اختصاصی نیاز ندارند. پیش از هر ساختی، بررسی کنید که آیا محصولی آماده، یک افزونهی موجود یا یک فایل Excel بهتر سازمان‌یافته همین کار را انجام میدهد یا خیر. اگر پرسش شما این است که آیا محصولی آماده این کار را انجام میدهد، پاسخ آن را با یک نسخهی آزمایشی رایگان پیدا کنید. برای این پرسش به ما یا شرکتی مانند ما نیازی ندارید.
ساخت MVP زمانی ارزش دارد که چند نشانه‌ی زیر هم‌زمان وجود داشته باشند:
- کاری تکرارشونده که هر هفته یا هر پروژه انجام میشود و قاعده‌ی آن قابل‌نوشتن است.
- داده‌هایی که در فایلهای خود دفتر هستند، مانند مدل‌های Revit، نقشه‌ها یا جدول‌ها، و محصولات آماده به آنها دسترسی ندارند.
- خطایی که هزینه‌ی آن دیر مشخص میشود، معمولاً هنگام ارسال نقشه‌ها یا در کارگاه.
- کاری که به یک نفر وابسته است و با غیبت او متوقف میشود.
هوشمندسازی فرآیند کاری در صنعت ساختمان نشان میدهد این فرآیندها معمولاً در کجای دفتر پیدا می‌شوند. MVP گام بعدی است، پس از آنکه فرآیند مشخص شد.
با یک پرسش و یک معیار، پیش از نوشتن اولین خط کد شروع کنید
MVP بدون معیار، به نسخهی کوچکی از محصول تبدیل میشود که کسی نمی‌داند موفق بوده است یا خیر. پیش از ساخت، سه مورد را بنویسید:
- پرسش: یک جمله، مانند «آیا این ابزار میتواند شیت‌های یک پروژه را بدون ویرایش دستی شماره‌گذاری کند؟»
- وضعیت فعلی: این کار امروز چه مدت طول میکشد، چه کسی آن را انجام میدهد و خطاها معمولاً در کجا رخ می‌دهند. این اعداد را از یک اجرای واقعی ثبت کنید، از حافظه‌ی افراد استفاده نکنید.
- معیار موفقیت: چه نتیجه‌ای نشان میدهد پاسخ مثبت است، و چه نتیجه‌ای نشان میدهد باید متوقف شوید.
معیار توقف به همان اندازهی معیار موفقیت اهمیت دارد. اگر پیش از شروع مشخص نشده باشد که چه نتیجه‌ای به معنای توقف است، هر نتیجه‌ای به دلیلی برای ادامه تبدیل میشود. این همان رویکردی است که تحقیق و توسعه‌ی آرتینکست بر آن استوار است: معیار، پیش از ساخت.
محدوده‌ی MVP: یک جریان کاری، یک تیم، داده‌های واقعی
محدوده‌ی MVP با حذف تعیین میشود. هرچه به پاسخ پرسش کمک نکند، به نسخهی بعدی منتقل میشود:
- حذف میشود: پنل مدیریت، تنظیمات قابلتغییر، پشتیبانی از چند نسخهی نرم‌افزار، ظاهر نهایی و هر قابلیتی که فقط یک نفر درخواست کرده است.
- باقی می‌ماند: درستی نتیجه، گزارش مواردی که ابزار نتوانسته پردازش کند و امکان بازگشت به وضعیت پیشین، مانند Undo در Revit یا نسخهی پشتیبان از فایل.
در دفاتر فنی، کوتاهترین مسیر اغلب در همان نرم‌افزاری است که تیم هر روز از آن استفاده میکند. یک اسکریپت Dynamo یا pyRevit میتواند منطق یک پلاگین را روی یک پروژهی واقعی آزمون کند، پیش از آنکه برای رابط کاربری، نصب و به‌روزرسانی آن هزینه‌ای شود. توسعه‌ی اسکریپت اختصاصی Dynamo توضیح میدهد چه زمانی یک اسکریپت کافی است و چه زمانی باید به پلاگین تبدیل شود. در این مسیر، اسکریپت به مشخصات فنی پلاگین تبدیل میشود.
کاهش محدوده نباید به کاهش دقت منجر شود. ابزاری که نتیجه‌ی نادرست را بی‌صدا تحویل دهد، از روش دستی پرهزینه‌تر است، زیرا بررسی هر خروجی آن زمان بیشتری از انجام دستی کار می‌گیرد.
MVP را در همان جایی آزمون کنید که کار انجام میشود
آزمون روی فایل نمونه‌ای که سازنده آماده کرده، فقط نشان میدهد ابزار روی همان فایل کار میکند. فایلهای واقعی پروژه نام‌گذاری‌های ناهماهنگ، المان‌های قدیمی و استثناهایی دارند که در هیچ فایل نمونه‌ای وجود ندارند.
راهنمای خدمات دولت بریتانیا (GOV.UK) مرحله‌ی alpha را مرحله‌ای می‌داند که در آن راه‌حل‌های مختلف برای مسائلی که در مرحله‌ی شناخت پیدا شده‌اند، آزمون می‌شوند. برای ابزار داخلی، این آزمون سه شرط دارد:
- کاربر واقعی: کسی که امروز این کار را انجام میدهد، ابزار را اجرا کند.
- اجرای موازی: برای مدتی کار هم به روش فعلی و هم با ابزار انجام شود و نتیجه‌ها مقایسه شوند.
- ثبت همه‌ی موارد: هر خطا، هر مورد پردازشنشده و هر جایی که کاربر مجبور شد کار را دستی تمام کند، ثبت شود.
این فهرست مهم‌ترین خروجی مرحله‌ی MVP است و تعیین میکند نسخهی بعدی باید چه چیزی را حل کند.
سه نتیجه‌ی ممکن، که یکی از آنها نساختن است
MVP با یکی از سه نتیجه تمام میشود و هر سه نتیجه ارزشمندند:
- ساخت نسخهی کامل: معیار موفقیت برآورده شده و مشخص است نسخهی کامل چه چیزهایی را باید اضافه کند.
- تغییر مسیر: بخشی از ایده کار کرده و بخشی نه. نسخهی بعدی بر بخشی تمرکز میکند که نتیجه داده است.
- توقف: ابزار زمان کافی صرفه‌جویی نمی‌کند، دادهها قابل‌اتکا نیستند یا محصولی آماده همین کار را بهتر انجام میدهد.
نتیجه‌ی سوم نیز یک نتیجه است، با هزینه‌ای که هنوز پرداخت نکرده‌اید. Martin Fowler این نگاه را «معماری قربانی‌شونده» می‌نامد: پذیرفتن اینکه آنچه امروز ساخته میشود، ممکن است بعدها کنار گذاشته شود. کد MVP برای یادگیری نوشته میشود و اگر نسخهی کامل با ساختاری متفاوت ساخته شود، هدف آن محقق شده است.
از MVP تا ابزاری که دفتر به آن متکی است
وقتی تصمیم به ساخت نسخهی کامل گرفته میشود، پرسش‌ها تغییر میکنند. دیگر پرسش این نیست که آیا ابزار کار میکند، بلکه این است که آیا سال بعد هم کار میکند:
- نگهداری در برابر نسخه‌های جدید: Revit هر سال نسخهی جدیدی منتشر میکند و پلاگین‌ها باید با آن سازگار شوند.
- مالکیت کد: کد منبع، مستندات و دسترسی به مخزن کد باید در اختیار دفتر باشد.
- پشتیبانی: چه کسی به پرسش کاربران پاسخ میدهد و خطاها چگونه گزارش می‌شوند.
- آموزش: همکاران جدید چگونه با ابزار آشنا می‌شوند.
هزینه‌ی توسعه‌ی پلاگین رویت این هزینه‌های پس از تحویل را جزءبه‌جزء بررسی میکند. MVP کمک میکند این هزینه‌ها فقط برای ابزاری پرداخت شوند که ارزش خود را در کار واقعی ثابت کرده است.
جمع‌بندی
MVP ابزار داخلی نسخهی ارزان محصول نهایی نیست، بلکه ابزاری برای پاسخ به یک پرسش مشخص است. اگر کار کند و ندانید چرا، هنوز پاسخی به دست نیامده است. اگر کار نکند و بدانید چرا، پاسخ را با کمترین هزینه به دست آورده‌اید. اولین چیزی که می‌خواهید تغییر کند چیست؟ از جریان کاری‌تان بگویید.
پرسش‌های متداول
MVP ابزار داخلی چیست؟
کوچکترین نسخهای از یک ابزار که یک کار واقعی را برای یک تیم، روی فایلهای واقعی پروژه انجام میدهد. هدف آن پاسخ به یک پرسش مشخص است: آیا این ابزار زمان را کاهش میدهد، نتیجه را درست به دست میآورد و همکاران از آن استفاده میکنند؟
تفاوت MVP، نمونهی اولیه و اثبات مفهوم چیست؟
اثبات مفهوم نشان میدهد کاری از نظر فنی امکانپذیر است. نمونهی اولیه نشان میدهد ابزار باید به چه شکلی کار کند. MVP نشان میدهد ابزار در کار واقعی نتیجه میدهد یا خیر.
ساخت MVP یک ابزار داخلی چه مدت طول میکشد؟
به اندازهی جریان کاری، وضعیت دادهها و تعداد نرمافزارهایی بستگی دارد که ابزار با آنها ارتباط دارد. زمانبندی قابلدفاع پس از بررسی فایلهای واقعی پروژه مشخص میشود.
آیا یک اسکریپت Dynamo میتواند MVP باشد؟
بله، برای بسیاری از ابزارهای رویت کوتاهترین مسیر همین است. اسکریپت منطق کار را روی پروژهی واقعی آزمون میکند و اگر نتیجه داد، به مشخصات فنی پلاگین تبدیل میشود.
چه چیزهایی باید از MVP حذف شوند؟
پنل مدیریت، تنظیمات قابلتغییر، پشتیبانی از چند نسخه و ظاهر نهایی. درستی نتیجه، گزارش موارد پردازشنشده و امکان بازگشت به وضعیت پیشین باید باقی بمانند.
اگر نتیجه‌ی MVP منفی باشد چه میشود؟
توقف نیز یک نتیجه است. MVP با کمترین هزینه نشان داده که این ابزار نباید ساخته شود یا محصولی آماده همین کار را بهتر انجام میدهد، پیش از آنکه هزینه‌ی نسخهی کامل پرداخت شود.
چه زمانی ساخت MVP لازم نیست؟
زمانی که محصولی آماده یا یک افزونهی موجود همین کار را انجام میدهد. در این حالت، یک نسخهی آزمایشی رایگان پاسخ را سریعتر و کمهزینهتر از هر ساختی به دست میدهد.