Публикувано на: 6 януари, 2025Създаването на първото MVP (Minimum Viable Product) е вълнуващ и предизвикателен етап за всеки новосформиран екип.
Това е моментът, в който идеите се превръщат в реалност, а продуктът започва да придобива форма. За ключовите аспекти за подготовката на първото MVP, определянето на потенциални предизвикателства и разработването на стратегии за тяхното преодоляване споделят от mobile екипите на TINQIN.
В публикация за DEV.BG те разглеждат защо е важно да се запази фокусът, как се изгражда и ясна визия за продукта, както и значението на обратната връзка, валидирането на концепцията и итерацията въз основа на реални потребителски данни.
От компанията посочват, че целта на тези стъпки е не само да минимизират риска, но и да създадат продукт, който отговаря на нуждите на целевата аудитория.
Как определихте основните функционалности за първото ви MVP?
За първоначалната версия на приложението (MVP) стартирахме в опростен вид с основни функционалности, които ни позволиха да валидираме продукта директно с потребителите. Основната цел беше да се уверим, че приложението отговаря на ключови потребителски нужди и да потвърдим концепцията си чрез събиране на обратна връзка от реални ползватели на приложението.
На база на първоначалните отзиви разработихме план за добавяне на допълнителни функции, които са приоритетни за потребителите.
Това ни позволи да изградим и развием приложението, като се фокусираме върху значими за потребителя функционалности и постигаме стабилен растеж.
Loading …Какъв е процесът на приоритизиране на функциите и как влияе на потребителското изживяване?
За да приоритизираме функциите на нашето приложение, използвахме няколко утвърдени техники, всяка от които беше избрана според конкретните цели.
MoSCoW (Must-have, Should-have, Could-have, Won’t-have). Разделихме функциите според тяхната критичност. Това ни помогна да се фокусираме върху елементите, които са от съществено значение за потребителското изживяване, и да оставим на заден план тези, които може да бъдат добавени в бъдеще.
RICE (Reach, Impact, Confidence, Effort). Тази техника ни помогна да анализираме въздействието и усилията за вече идентифицирани функции. С нея оценихме кои от тях предлагат най-голяма стойност спрямо необходимите ресурси.
Kano модел. Оценихме функциите според техния потенциал да повишат удовлетвореността на потребителите. Този подход е изключително подходящ за планиране на бъдещи подобрения след реализиране на основните функции.
Какви решения взехте за инструментите и технологиите за разработка на мобилното приложение?
Взехме решението да използваме Swift за iOS и Kotlin за Android, защото те предлагат стабилна и сигурна среда, съвместима с нативните функционалности на мобилните операционни системи. Тези технологии позволяват лесно адаптиране и мащабиране на приложението, което е от решаващо значение за бъдещото развитие на продукта.
Explore more
Какви подходи и технологии избрахте за разработката?
1) Приложихме няколко подхода
Compose-first подход. За изграждане на потребителския интерфейс използваме Jetpack Compose за почти 100% от UI компонентите. Това осигурява модерен и гъвкав начин за създаване на динамични интерфейси.
Model-View-Intent (MVI) архитектура. Подходът ни дава ясно разделение между различните слоеве и компоненти от UI-я до външната комуникация и локалните данни.
Kotlin Coroutines и Flow. Използваме тези инструменти за асинхронна работа, като гарантираме ефективност и управление на потоци от данни.
Ktor и kotlinx.serialization. За комуникация със сървиси избрахме тези библиотеки, защото избягват използването на reflection (за разлика от Retrofit и Gson), което допринася за по-добра производителност и по-малко натоварване на приложението.
iOS/Swift/SwiftUI. Използваме нативни технологии за iOS 16, които предлагат мощен инструментариум за разработка на приложения с интуитивен интерфейс.
SPM (Swift Package Manager). Проектът е модуларизиран, като използва SPM за управление на зависимости и преизползваемост на кода, което подобрява структурата и мащабируемостта.
Onion Layer Architecture. Тази архитектура осигурява ясно разделение на отговорностите между различните слоеве и улеснява както тестването, така и интеграцията на нови функции.
2) Архитектурни модели
MVVM-C (Model-View-ViewModel-Coordinator). Подпомага управлението на навигацията и разделението на логиката.
MV (Model-View). Съкращава сложността при визуализиране на данни и логика на представянето.
Каква е вашата визия за бъдещето и какви са следващите стъпки по развитието на продукта?
След пускането на MVP нашият фокус е сертификацията на приложението по всички европейски стандарти, както и по регулациите в държавите, в които е налично. В момента приложението е достъпно в Белгия, България, Люксембург, Румъния и Франция а скоро се очаква и в Италия, както и в други европейски държави.
Целта за 2025 година е официалното сертифициране на KIPMI като EIDAS 2.0 Digital Identity Wallet, което да утвърди приложението като едно от най-разпознаваемите и използвани на европейския пазар.
Планираме бъдещите версии и добавяне на нови функции въз основа на отзивите от потребителите. Приложението беше пуснато по-рано, за да получим обратна връзка и да направим подобрения, които отговарят на реалните нужди на потребителите.
Първоначално започнахме с вътрешна употреба в компанията, което ни позволи да съберем значима обратна връзка и идеи за оптимизация. Това ни даде стабилна основа за бъдещото развитие, като планираме редовни обновления, които ще включват нови функции и подобрения според отзивите и изискванията на потребителите.
Подготовката за първото ни MVP е ключов момент, който ще постави основите на нашия успех. Чрез ясно дефиниране на целите, използване на подходящи технологии, ефективна комуникация и фокус върху качеството ние сме уверени, че ще създадем продукт, който ще впечатли нашите потребители и ще ни отвори пътя към бъдещи постижения.
