هر برنامه‌ای برای یک هدف مشخص طراحی می‌شود و آن کمک به کاربران برای دستیابی به روشی یکپارچه و لذت‌بخش است. با اینکه یک تعریف کلی است، اما نکته‌ای در این ابهام وجود دارد.
یعنی این تنها چیزی است که هنگام شروع ساخت و توسعه نرم افزار از آن اطلاع دارید. می‌دانید که می‌خواهید به کاربران کمک کنید. حتی ممکن است بدانید که کاربران باید دقیقا چه فعالیت‌هایی را در برنامه انجام دهند. اما آیا کاربران واقعا به آن نیاز دارند؟ یکپارچگی و لذت‌بخش بودن به چه معناست؟ پاسخ به این سوالات کمی دشوار است.
در این مقاله به صورت رویکردی قصد داریم به شما بگوییم که MVP چیست و چگونه می‌تواند روی کارهای‌تان تاثیر بگذارد. اما پیش از آن یک نکته:
نکته اینجاست: می‌توانید بپذیرید که کاربران به این ویژگی نیاز دارند و می‌توانید فرض کنید که تجربه کاربری چقدر باید خوب باشد. اما فرضیات اغلب نتیجه معکوس دارند. به طوری که شرط‌بندی پول بر روی مفروضات چیزی نیست که بسیاری از مردم بخواهند انجام دهند.
بنابراین در اینجا دو سوال پیش می‌آید:
- اگر از صفر می‌سازید، چگونه مطمئن می‌شوید که محصولی با ارزش را ارائه میدهید؟
- اگر در حال حاضر یک MVP توسعه یافته دارید، بهترین گزینه برای حرکت رو به جلو چیست؟
بیایید با اولی شروع کنیم.
چگونه یک MVP با ارزش بسازیم
اریک ریس کتابی به نام استارت‌آپ ناب نوشته که کاملا تفکرات و ایده‌های ایجاد یک MVP (حداقل محصول قابل پذیرش) با ارزش را توصیف می‌کند. این کتاب نکات و رویکردهای بسیار خوبی دارد که ارزش تطبیق در توسعه کسب و کار را خواهند داشت.
بنابراین به‌جای خلاصه‌نویسی مطالبی که کتاب ارائه می‌کند، می‌خواهم نتایج عملی خود را که از یک دهه توسعه نرم‌افزار به دست آمده به اشتراک بگذارم.
هنگام ساختن و توسعه نرم افزار، وسوسه زیادی برای یادداشت و برنامه‌ریزی هر ویژگی که به ذهن‌تان می‌رسد وجود دارد. هدف MVP آزمایش یک فرضیه است، اما زمانی که روند توسعه پیش می‌رود، اغلب ایده‌ها برای ویژگی‌ها جمع می‌شوند. این یک فرآیند کاملا طبیعی بوده، اما برنامه‌ریزی برای تعقیب این ایده‌ها چند خطر دارد:
- احتمال دارد بازار تغییر کند و ایده‌ها ممکن است عملی نشوند.
- بودجه ممکن است قبل از رسیدن به چیزی که کاربران برای آن ارزش قائل هستند، تمام شود.
- ممکن است معلوم شود که این ایده‌ها نیازهای کاربران را مشخص نکرده‌اند.
در ادامه سه راه برای مقابله با این خطرات ذکر می‌کنیم.
بهترین رویکرد: به یاد داشته باشید که در حال آزمایش هستید
در این رویکرد شما کارها را طبق کتاب انجام میدهید (استارت‌آپ ناب). این بدان معنی است که بر تمایل طبیعی خود به برنامه‌ریزی از قبل غلبه کرده و بر ساخت یک برنامه کوچک تمرکز می‌کنید که به شما امکان می‌دهد موارد زیر را تست نمایید:
- آیا کاربران به چیزی که فکر می‌کردید واقعا نیاز دارند؟ اینجا از مثال Dropbox استفاده می‌کنیم. یعنی به جای ایجاد یک سرویس ذخیره‌سازی ابری، آن‌ها با یک صفحه فرود شروع کردند که توضیح می‌داد Dropbox چه کاری انجام می‌دهد و یک فرم اشتراک ایمیل را در آنجا قرار دادند. این کار به آن‌ها اجازه داد تا ایده خود را ارزان و سریع آزمایش کنند.
- اگر کاربران به چیزی کمی متفاوت از آنچه شما فکر می‌کردید نیاز داشته باشند، چه؟
- کارآمدترین راه برای ارائه آنچه کاربران نیاز دارند چیست؟ محصول چگونه باید برای بهترین تجربه کاربری رفتار کند؟
در این صورت می‌بینید که کاربران چگونه واکنش نشان می‌دهند و بر اساس آن روال کار را تنظیم می‌کنید. به طور خلاصه MVP در این سناریو یکی از تعاملات چرخه build-measure-learn است.
بدین منظور تا حد امکان از فرضیات کم‌تری کمک می‌گیرید، یک MVP می‌سازید، همه چیز را با کاربران تست کرده و سپس تنظیم می‌کنید.
دومین رویکرد: ویژگی‌های حیاتی و ضروری را توسعه دهید و آزمایش کنید
اگر به دلایلی نمی‌توانید به پروژه به عنوان یک آزمایش نگاه کنید و نیاز به ارائه یک ایده ثابت دارید، بهتر است فقط چند ویژگی (یا حتی فقط یکی) که در مرکز ایده‌ها هستند را شناسایی کنید. به عبارت دیگر قابلیتی که بدون آن برنامه حتی نمی‌تواند وجود داشته باشد.
سپس این اپلیکیشن کوچک و به نوعی ناپایدار را به اولین کاربران تحویل میدهید و می‌بینید که چگونه واکنش نشان می‌دهند. با این تکنیک یاد می‌گیرید که آن‌ها چه چیزهایی را دوست دارند، چه چیزهای دیگری مورد نیاز است و چه مواردی نیاز به تنظیم دارد.
سومین رویکرد: اولویت، ارائه، تست
برخی از محصولات قرار است در یک بازار تثبیت شده رقابت کنند. در این سناریو کاربران به روش خاصی برای انجام کارها عادت کرده‌اند و حرکت در خلاف جریان توصیه نادرستی است. بنابراین از قبل فهرست کارهایی که یک محصول باید انجام دهد و همچنین نحوه عملکرد آن برای اطمینان از متمایز بودن و آشنایی با محصول وجود دارد.
بهترین راه در اینجا این است که لیستی از ویژگی‌ها را در نظر بگیرید و 20 درصد از آن‌ها را اولویت‌بندی کنید. این کار به ساختاردهی فرآیند توسعه کمک زیادی کرده و هنوز هم فضایی برای بازخورد کاربران وجود دارد. زیرا پس از آزمایش نسخه اول، همچنان می‌توانید ویژگی‌های برنامه‌ریزی شده را بر اساس بازخورد کاربران تنظیم کنید.
اگر می‌خواهید جزئیات بیشتری در مورد اینکه MVP دقیقا چقدر می‌تواند مفید باشد و نحوه نزدیک شدن به مراحل آن را نیز بفهمید، این مقاله را بررسی کنید.
فرض کنیم اکنون یک MVP دارید، قدم بعدی چیست؟
در بالا به برخی از رویکردهای ساخت MVP نگاه کردیم. هر رویکردی که برای شما بهترین باشد، برای یافتن تعادلی که کاربران به دنبال آن هستند، به تکرار چند چیز نیاز است. به احتمال زیاد تا این مرحله بیشتر کار توسعه توسط یک شرکت خارجی انجام شده است. پس بعد از این چه باید کرد؟
هنوز هم کارهایی برای انجام دادن وجود دارد. تکرارهای MVP به شما این امکان را می‌دهد تا محصولی را بسازید که کاربران به آن نیاز دارند و اکنون می‌توانید مواردی را اضافه کنید که استفاده از محصول شما را راحت‌تر می‌کند. اما در اینجا نیاز به توسعه دهندگان دارید. انتخاب شما چیست؟ بهترین راه برای این فرایند کدام است؟ ما گزینه‌های شما را در زیر فهرست می‌کنیم و نحوه برخورد با هر کدام را شرح می‌دهیم.
گزینه 1: با شرکت فعلی بمانید
اگر از نتایج و کیفیت کار راضی هستید، عملا این بهترین گزینه برای ادامه روند توسعه است.
چرا که دانش محصول از قبل وجود دارد، تمام برنامه‌های آینده نوشته شده و درک می‌شوند، تیم محصول و کانال‌های ارتباطی نیز راه‌اندازی شده‌اند. به همین ترتیب می‌توانید به آرامی به سمت توسعه محصول پیش بروید یا اگر در مرحله بازخورد باشد، بر رفع اشکال، نظارت بر رفتار و نگهداری تمرکز خواهید کرد.
گزینه 2: ترکیبی از تیم داخلی و شرکت خارجی
اگر می‌خواهید تیم داخلی خود را بسازید، می‌توانید مدل هیبریدی را انتخاب کنید، جایی که شرکت از عملیات اصلی شما پشتیبانی می‌کند.
در این سناریو، ما بر انتقال دانش به تیم داخلی جدید تمرکز می‌کنیم و مطمئن می‌شویم که آن‌ها همه چیزهای مورد نیاز را دارند تا بتوانند پشتیبانی و بررسی کد را انجام دهند. با اینکه ما این کار را انجام می‌دهیم، به مراقبت از خود محصول ادامه می‌دهیم. هدف در اینجا این است که یک تحویل تمیز و بی‌عیب داشته باشیم.
گزینه 3: انتقال کامل به تیم داخلی یا شرکت جدید
به دلایل زیادی ممکن است تصمیم بگیرید که یک تیم داخلی بسازید تا بتواند به طور کامل توسعه محصول را به عهده بگیرد، یا ممکن است بخواهید به طور کلی شرکت طرف قرارداد را تغییر دهید.
در این صورت هدف ما نیز واگذاری کامل است. تا زمانی که تیم جدید به طور کامل قادر به تصاحب آن نباشد باید از محصول، بررسی کد و انتقال دانش پشتیبانی کرد.
اگر قصد دارید این مسیر را دنبال کنید، مطمئن شوید که توافق‌نامه‌های قانونی از مالکیت معنوی کسب و کار و محصول شما محافظت می‌کند. یک روش خوب این است که اطمینان حاصل شود مشتری حقوق مالکیت معنوی را با مجوز یا با انتقال دریافت می‌کند.
اگر قصد دارید به صورت کاملتر و بهتر با MVP آشنا شوید به شما پیشنهاد می‌کنم مسیر یادگیری برنامه نویسی را دنبال کنید.
دیدگاه و پرسش
در حال دریافت نظرات از سرور، لطفا منتظر بمانید
در حال دریافت نظرات از سرور، لطفا منتظر بمانید