Vytváření MVP pro startupy vs. podnikový software (naše zkušenosti)

Během minulého roku jsem měl to štěstí, že jsem se zapojil do vývoje dvou mobilních aplikací pro dva odlišné klienty v naší společnosti.

Přestože se jejich povaha podobná, výzvy a přístupy se od sebe navzájem výrazně lišily a já jsem se chtěl s vámi podělit o své studijní zkušenosti a to, co jsem našel, kde byly některé výstřednosti a rozdíly mezi budováním MVP pro Startup a velkou společností FinTech.

Startup

StartUp - Výzva

Naší první výzvou, kterou jsem dostal se svými kolegy, byl úkol vybudovat poměrně složitý MVP pro jedno z největších letišť v LATAMu, které mělo mnoho pohyblivých kusů, od stahování letových dat v reálném čase, vizualizací map obchodních domů a přizpůsobeného doporučení. mezi mnoha dalšími.

Účelem bylo zapsat skutečný plně digitální zážitek a zapojit cestující prostřednictvím jediné mobilní aplikace a eliminovat potřebu uživatele stahovat více aplikací a omezit rozptýlené zapojení značky.

Velký podnik

ISV - Výzva

Druhá výzva, která na nás byla vyvolána - a myslím tím, že nejlepším možným způsobem - byla pro velkou společnost FinTech. Je to finanční aplikace, která zahrnuje práci se spoustou funkcí kolem peněz lidí. Bylo to také něco, co několik bank hodlá použít, takže si dokážete představit, že všechno bylo vždy velmi závažné a složité.

Dnes se chci věnovat chvilce, abych se s vámi podělil o naše zkušenosti, ale hlavně o rozdíl mezi budováním MVP pro spuštění a budováním Enterprise Software ™.

Rozdělíme to do různých kategorií:

Technologie za tím

Tech Stack

Spouštění bylo bezpochyby flexibilnější, byly otevřené návrhům a dychtily vyzkoušet špičkové technologie, i když se jednalo o riziko, jako je použití produktů ve verzi BETA pro výrobu . Například chtěli použít Cloud Firestore, i když byl tehdy označen jako BETA.

Společnost Fintech byla pochopitelně více zavřená ohledně technologického zásobníku, který bychom použili. Dokonce i balíčky, které jsme museli instalovat, musely projít důkladným kontrolním procesem, a to jak jejich technickým týmem, tak jejich bezpečnostním týmem. Nemluvě o tom, že nic, co nemohli mít 100% vlastnictví, nebylo vyloučeno.

Týmová práce

Velikost týmu

Stále si nejsem jistý, jestli je to ovlivněno typem produktu, mám sklon myslet si, že je to spíše kvůli rozsahu, ale pro MVP jsme měli tým 1 projektového manažera, 2 vývojáře a 1 QA. V týmu nebyli žádní lidé UX, protože klient již měl své návrhy.

Tým pro projekt Enterprise byl mnohem větší, měli jsme 1 projektového manažera, 6 vývojářů, 2 QA a 2 odborníky UX.

Jak jsem řekl, je to více o rozsahu, MVP byl dvouměsíční projekt, Enterprise Software byl celoroční zakázkou.

Rychlost

Rychlost vývoje

Toto je aspekt, ve kterém jsme našli spoustu rozdílů, spuštění se muselo dostat na trh ASAP, takže jsme se každý týden zaměřovali na nasazení nových funkcí.

V případě Enterprise Software ™ jsou věci jiné, měli jsme proces uvolňování kódu z více částí:

  • Začali jsme s relací mapování, kde jsme analyzovali celý projekt a definovali funkce, které mají být v každé verzi vytvořeny.
  • Zřídili jsme měsíční vydání se 2 sprinty v každém vydání.
  • Po každém sprintu šly funkce týmu QA.
  • Po certifikaci QA jsme vygenerovali instalační program pro tým QA klienta.
  • Po certifikaci QA klienta byly funkce schváleny a integrovány do projektu. Nebo byli posláni zpět na opravu.
QA

Analytici kvality

V předchozím bodě jsem o tom trochu mluvil, ale existují i ​​rozdíly v zajišťování kvality. Například pro projekt Startup měla naše QA více slovo v tom, jak věci fungovaly a co považovala za splněné očekávání.

Pro podnikového klienta náš tým QA certifikoval funkce, ale poté jej musel vlastní tým QA certifikovat, než odešel, aby jej integroval s hlavní větví projektu.

Design

UX / UI

Toto je další část, kde byl proces A LOT jiný, se spouštěcím klientem nám předali návrhy, abychom je implementovali, a byl to méně přísný proces.

U našeho podnikového klienta byl návrh také vícestupňovým procesem:

  • Náš tým UX vytvořil návrhy pro funkci pro další sprintu.
  • Návrhové oddělení klienta tyto návrhy schválilo.
  • Klient odeslal schválené návrhy k testování uživatele.
  • Klient poslal návrhy zpět k provedení změn na základě testování uživatele.
  • Náš tým UX provedl změny / opravy a poté návrhy zašle zpět klientovi.
Rozvinutí

Rozvinutí

Myslím, že to musí být více s typem klienta než s typem projektu, ale stojí za zmínku, protože věci byly velmi odlišné.

Pro našeho spouštěcího klienta jsme nastavili nasazení pomocí Firebase a Wordpress (pro obsahovou část aplikace).

Firemní klient měl různé požadavky, všechno se dělo s interními nástroji / platformami, které měli, zdrojový kód jsme měli uvnitř našeho účtu VSTS, ale pouze když jsme byli „ve vývoji“.

Jakmile jsme dostali schválené vydání ze strany klienta, přesunuli jsme zdrojový kód do svých vlastních úložišť, kde zpracovali vše.

Peníze mluví

Náklady

Jak si můžete představit, peníze diskuse byla velmi odlišná pro oba klienty.

Startovací klient měl tým asi 1/3 velikosti podnikového klienta, který hodně ovlivňuje náklady, procesy a rozsah se také lišily.

Ponaučení

Jako společnost si myslím, že největší lekcí, kterou jsme se naučili z obou těchto projektů, je, jak odlišný by měl být náš přístup v závislosti na typu klienta. Nástroje, komunikace, metodologie atd.

Ve více osobní poznámce jsem se naučil udržovat konstantní a plynulejší komunikaci s klienty, bylo mnoho okamžiků, když jsme spolu mluvili o věcech, které nám pomohly ve velkých zátarasech.

Co si myslíte, že jste Startup, který se chce rychle dostat na trh? Nebo zavedená společnost hledající technického partnera?

Neváhejte oslovit, rádi bychom si povídali o tom, jak vám můžeme pomoci dostat se na trh a zajistit, aby se tento projekt uskutečnil.

Oslovte mě nebo Yuxi Global - [email protected] - pokud se ve vaší organizaci potýkáte s podobnými výzvami a hledáte pomoc při vytváření dalšího MVP nebo digitálního produktu. Milujeme dobrou výzvu a vždy hledáme způsoby, jak s vámi inovovat.