Изграждане на MVP точки за стартиране срещу корпоративен софтуер (Нашият опит)

През изминалата година имах късмета да участвам в разработването на две мобилни приложения за двама различни клиенти в нашата компания.

Макар и сходни по своята същност, предизвикателствата и подходът за всеки варираха драстично един от друг и исках да споделя своя опит с обучението с вас и какво открих, където някои от странностите и разликите между изграждането на MVP за стартиране и голяма компания FinTech.

Стартирането

StartUp - Предизвикателството

Първото ни предизвикателство, зададено на мен и моите колеги, беше задачата да изградим доста сложен MVP за едно от най-големите летища в LATAM, който имаше много движещи се части, от извличане на данни за полети в реално време, визуализация на картите на универсалните магазини и персонализирана машина за препоръки сред много други.

Целта беше да се капсулира истинско напълно дигитално изживяване и да ангажира пътници чрез едно мобилно приложение и да се елиминира нуждата на потребителя да изтегли множество приложения и да намали разпръснатия ангажимент с марката.

Голямо предприятие

ISV - Предизвикателството

Второто предизвикателство, което беше отправено към нас - и имам предвид това по най-добрия възможен начин - беше за голяма компания FinTech. Това е финансово приложение, включва работа с много функционалност около парите на хората. Това също беше нещо, което няколко банки щеше да използват, така че, както можете да си представите, всичко беше много сериозно и сложно през цялото време.

Днес искам да отделя момент, за да споделя с вас нашия опит, но главно разликата между изграждането на MVP за стартиране и изграждането на Enterprise Software ™.

Ще го разделим на различни категории:

Технологиите зад него

Tech Stack

Без съмнение стартирането беше по-гъвкаво в това отношение, те бяха отворени за предложения и нямаха търпение да изпробват авангардни технологии, дори когато това включва риск, като използването на продукти във версия BETA за производство . Например, те искаха да използват Cloud Firestore, дори по това време беше белязан като BETA.

Компанията Fintech беше разбираемо по-затворена относно технологичния стек, който ще използваме. Дори пакетите, които трябваше да инсталираме, трябваше да преминат през задълбочен преглед от техническия екип и от екипа им по сигурността. Да не говорим, че нищо, което те не биха могли да имат 100% собственост, не се разминаваше.

Съвместна дейност

Размер на екипа

Все още не съм сигурен дали това е повлияно от вида на продукта, склонен съм да смятам, че е повече заради обхвата, но за MVP имахме екип от 1 ръководител на проекти, 2 разработчици и 1 QA. В екипа нямаше UX хора, защото клиентът вече имаше своите дизайни.

Екипът за Enterprise проекта беше много по-голям, имахме 1 Project Manager, 6 Developers, 2 QA и 2 UX експерти.

Както казах, става въпрос за обхвата, MVP беше двумесечен проект, Enterprise Software беше ангажимент от една година.

скорост

Скорост на развитие

Това е аспект, при който открихме много разлика, необходимото за стартиране, за да стигнем до пазара ASAP, така че бяхме фокусирани върху внедряването на нова функционалност всяка седмица.

За Enterprise Software ™ нещата са различни, имахме многочастен процес за освобождаване на код:

  • Започнахме със сесия за пътно картографиране, където анализирахме целия проект и дефинирахме характеристиките, които да изградим във всяко издание.
  • Ние създаваме месечно издание с 2 спринта във всяко издание.
  • След всеки спринт, функциите отидоха в нашия QA екип.
  • След QA сертифициране създадохме инсталатор за QA екипа на клиента.
  • След сертифициране на QA на клиента характеристиките бяха одобрени и интегрирани в проекта. Или са изпратени обратно за поправки.
QA

Качествени анализатори

Говорих малко за това в предишната точка, но имаше и някои различия в осигуряването на качество. Например, за проекта Startup, нашата QA имаше повече информация за това как работят нещата и какво смята за изпълнено очакване.

За корпоративния клиент нашият QA екип сертифицира функциите, но след това техният QA екип трябваше да го сертифицира, преди да даде ход, за да го интегрира с основния клон на проекта.

Дизайн

UX / UI

Това е друга част, в която процесът беше много по-различен, със стартиращия клиент те предадоха проектите, за да ги изпълним и беше по-малко строг процес.

С нашия корпоративен клиент дизайнът също беше многоетапен процес:

  • Нашият UX екип създаде дизайните за функцията за следващия спринт.
  • Дизайнерският отдел на клиента одобри проектите.
  • Клиентът изпрати одобрените дизайни за тестване на потребителите.
  • Клиентът изпраща обратно проектите, за да внесе промени, основани на тестване на потребителите.
  • Нашият UX екип направи промените / корекциите и след това изпрати дизайна обратно на клиента.
разгръщане

разгръщане

Мисля, че това трябва да е повече с типа на клиента, отколкото с типа проект, но си струва да се спомене, защото нещата бяха много различни.

За нашия стартиращ клиент настроихме разгръщане, използвайки Firebase и Wordpress (за съдържателната част на приложението).

Корпоративният клиент имаше различни изисквания, всичко беше направено с вътрешни инструменти / платформи, които имаха, имахме изходния код в нашия VSTS акаунт, но само докато бяхме „в процес на разработка“.

След като имаме одобрено издание от клиента, преместихме изходния код в техните собствени хранилища, където те обработваха всичко.

Паричните разговори

Разходи

Както може би си представяте парите, разговорите бяха много различни и за двамата клиенти.

Стартиращият клиент имаше екип около 1/3 от размера на корпоративния клиент, който влияе много на разходите, също така процесите и обхватът бяха различни.

Поуки

Като компания мисля, че най-големият урок, който научихме от двата проекта, е колко различен трябва да бъде подходът ни в зависимост от типа на клиента. Инструменти, комуникация, методология и др.

Като по-лична бележка, научих се да поддържаме по-постоянна и по-постоянна комуникация с клиенти, имаше много моменти, когато разговарянето на нещата заедно ни помогна да запалим големи препятствия.

Какво мислиш, стартираш ли искаш да стигнеш до пазара бързо? Или утвърдена компания, която търси технически партньор?

Не се колебайте да се свържете, ще се радваме да поговорим за това как можем да ви помогнем да стигнете до пазара и да накарате този проект да се осъществи.

Обърнете се към мен или Yuxi Global - [email protected] - ако преживявате подобни предизвикателства във вашата организация и търсите помощ при изграждането на следващия си MVP или цифров продукт. Ние обичаме доброто предизвикателство и винаги търсим начини за иновации с вас.