Pereiti prie turinio
Produkto strategija ir pritaikyta programinė įranga

Individualūs SaaS produktai, sukurti pagal realius darbo eigą

Mes planuojame ir kuriame tikslinius SaaS MVP, klientų portalus ir vidinius verslo įrankius, pagrįstus realiais vartotojais, leidimais, duomenimis ir veiklos taisyklėmis. Pirmoji versija sukurta taip, kad kurtų vertę prieš pridedant daugiau funkcijų.

Užklausa dėl produkto apžvalgosŽr. ką mes kuriame
Darbo eiga prieš ekranusMVP apimtis prieš kodąSuplanuoti vaidmenys ir leidimaiAiškus nuosavybės teisės aktas ir perdavimas
Individuali SaaS platforma, jungianti vartotojus, teises, darbo eigas, struktūrizuotus duomenis, API ir ataskaitų teikimą.
  • Pirmiausia pagrindinė darbo eigaUžuot kurę kiekvieną idėją iš karto, pradėkite nuo mažiausio naudingo produkto.
  • Vartotojai ir vaidmenysApibrėžkite, kas naudoja sistemą, ką jie gali matyti ir kokius veiksmus jie atlieka.
  • Struktūrizuoti duomenysPlanuokite įrašus, būsenas ir ryšius, kol sąsaja dar netapo sudėtinga.
  • Plėtros keliasSusieti būsimus modulius ir integracijas neįtraukiant jų į MVP.

Produkto problema

Individuali programinė įranga tampa brangi, kai ekranai kuriami prieš darbo eigą

Projektai praranda laiką, kai komanda nesusitaria dėl naudotojų, leidimų, duomenų, patvirtinimo taisyklių ir veiksmo, kuris sukuria realią vertę.

Pradedame nuo produkto atradimo, kad pirmoji versija išspręstų vieną kontroliuojamą darbo eigą ir suteiktų verslui kažką naudingo testavimui, valdymui ir tobulinimui.

01

Neaiškus nuosavybės teisės objektas

Vartotojai, administratoriai ir komandos nežino, kas turėtų patvirtinti, atnaujinti ar atlikti kiekvieną veiksmą.

02

Per daug MVP funkcijų

„Puiku turėti“ moduliai atitolina darbo eigą, kuri pirmiausia turėtų patvirtinti produktą.

03

Atjungti duomenys

Įrašai, pranešimai ir būsenos lieka išsklaidyti skaičiuoklėse ir atskiruose įrankiuose.

MVP kelionė

Nuo darbo eigos neapibrėžtumo iki produkto, kurį žmonės iš tikrųjų gali naudoti

Ta pati sistema taikoma viešiesiems SaaS produktams, klientų portalams ir vidinėms operacinėms sistemoms.

  1. 01

    Apibrėžkite darbo eigą

    Nubraižykite vartotojus, veiksmus, išimtis ir rezultatus, kuriuos produktas turi palaikyti.

  2. 02

    Žemėlapio vaidmenys ir duomenys

    Apibrėžti teises, įrašus, būsenas ir ryšius prieš kuriant sąsajos dizainą.

  3. 03

    Sumažinkite MVP

    Pasirinkite mažiausią funkcijų rinkinį, kuris sukuria veiklos arba kliento vertę.

  4. 04

    Sukurkite produktą

    Kurkite ataskaitų suvestines, formas, lenteles, būsenas ir testuojamą vartotojo kelionę.

  5. 05

    Kurkite ir patvirtinkite

    Prieš paleidimą įdiekite produktą, integracijas ir realius darbo eigos testus.

Produktų maršrutai

Tinkamas formatas priklauso nuo to, kas naudoja produktą ir kokį darbo eigą jis kontroliuoja.

Ne kiekvienas verslo įrankis turi tapti viešu SaaS produktu. Mes pasirenkame paprasčiausią naudingą formatą vartotojams, prieigos modeliui ir veiklos poreikiams.

Sukurkite arba pirkite

Individualus kūrimas turėtų būti pradėtas tik tada, kai paprastesni įrankiai negali palaikyti darbo eigos

Geriausias sprendimas gali būti esama platforma, mažai kodo reikalaujanti konfigūracija arba pritaikytas produktas. „Discovery“ nustato mažiausiai sudėtingą variantą, kuris gali tinkamai palaikyti verslą.

MetodasGeriausia, kaiPagrindinis kompromisas
Skaičiuoklės arba darbo srities įrankisDarbo eiga yra paprasta, dažnai keičiasi ir turi mažai vartotojų.Ribotos teisės, automatizavimas ir duomenų kontrolė.
Esama SaaSĮmonė gali pritaikyti savo procesą prie patikrinto produkto.Mažiau kontrolės darbo eigai ir produkto planui.
Mažo kodo sistemaPrioritetai yra greitas patvirtinimas ir vidutinė pritaikyta logika.Platformos apribojimai ir didėjančios naudojimo išlaidos gali pasirodyti vėliau.
Individuali SaaSVaidmenys, duomenys, taisyklės ir integracijos yra būdingi konkrečiai įmonei.Didesnė atsakomybė už aptikimą, kūrimą ir priežiūrą.

Produkto architektūra

Naudingam produktui reikia, kad darbo eiga, duomenys, saugumas ir operacijos veiktų kartu.

Technologijų rinkinys parenkamas aiškiai nustačius produkto reikalavimus. Kai kurios sistemos gali būti pradėtos nuo „WordPress“ arba mažai kodo reikalaujančių komponentų; kitoms reikalinga pritaikyta programos architektūra.

  • Autentifikavimas, naudotojai ir vaidmenų leidimai
  • Darbo eigos taisyklės, patvirtinimai ir būsenos perėjimai
  • Duomenų modelis, istorija ir įrašų ryšiai
  • Reaguojanti sąsaja, formos, lentelės ir sistemos būsenos
  • API, pranešimai, mokėjimai ir išorinės paslaugos
  • Atsarginės kopijos, stebėjimas, ataskaitų teikimas ir operacinė kontrolė

Sužinokite, kaip produktas jungiasi prie platesnės skaitmeninės infrastruktūros.

1 sluoksnisVartotojai ir prieigaAutentifikavimas, vaidmenys, leidimai ir paskyros savininkas.
2 sluoksnisDarbo eiga ir taisyklėsVeiksmai, patvirtinimai, išimtys, būsenos ir nuosavybės logika.
3 sluoksnisDuomenų modelisStruktūrizuoti įrašai, ryšiai, istorija ir perkėlimo poreikiai.
4 sluoksnisSąsaja ir būsenosPrietaisų skydai, formos, lentelės, tuščios būsenos, klaidos ir reaguojančios veiklos.
5 sluoksnisIntegracijosAPI, mokėjimai, kalendoriai, CRM, el. paštas, pranešimų siuntimas ir automatizavimas.
6 sluoksnisSaugumas ir patikimumasApsaugota prieiga, atsarginės kopijos, žurnalai, stebėjimas ir atkūrimo planavimas.
7 sluoksnisOperacijos ir ataskaitų teikimasAdministratoriaus valdikliai, eksportavimas, veiklos peržiūros ir produkto tobulinimo signalai.

Reprezentatyvus produkto darbo eiga

Stebėjimo operacija gali būti perkelta iš išsklaidytų atnaujinimų į vieną kontroliuojamą sistemą.

Šiame pavyzdyje parodytas operacinis pakeitimas neskelbiant nepatvirtintų našumo teiginių.

Prieš

Rankinis ir atjungtas

Įrašai saugomi atskiruose failuose, būsenos atnaujinimai siunčiami rankiniu būdu, klientai nuolat teiraujasi apie eigą, o komanda neturi bendros veiklos apžvalgos.

Po

Struktūrizuota ir pagrįsta vaidmenimis

Įrašai tvarkomi pagal apibrėžtą būsenos darbo eigą, darbuotojai naudoja vieną administratoriaus rodinį, klientai pasiekia reikiamus atnaujinimus, o ataskaitos atspindi tą patį teisingą informacijos šaltinį.

Pasirinkti darbai

Individualios platformos, rezervavimo darbo eigos ir operacinės sistemos

Pasirinkti projektai, susiję su stebėjimu, rezervavimu, administravimo darbo eigomis, klientų prieiga, struktūrizuotais įrašais ir susijusiomis operacijomis.

Peržiūrėti visus darbus

Procesas, rezultatai ir patvirtinimai

Etapinis produkto procesas kontroliuoja apimtį ir sprendimus.

Kiekvienas etapas baigiasi aiškia išvestimi ir patvirtinimo tašku prieš pradedant tolesnį kūrimą.

01

Produkto atradimas

Susiejame naudotojus, darbo eigą, duomenis, rizikas, integracijas ir verslo rezultatą, kurį turi sukurti pirmoji versija.

Pristatomas rezultatas: Darbo eigos schema ir aptikimo santraukaPatvirtinimas: Darbo eigos patvirtinimas
02

Planas ir prototipas

Apibrėžiame MVP modulius, ekranus, leidimus, techninę kryptį ir testuojamą sąsajos srautą.

Pristatomas rezultatas: MVP brėžinys ir prototipasPatvirtinimas: Apimties ir sąsajos patvirtinimas
03

Kurti ir patvirtinti

Įdiegiame produktą, integracijas ir pritaikome responsives, tada testuojame teises, kraštutinius atvejus ir realias užduotis.

Pristatomas rezultatas: Darbo testuojamas MVPPatvirtinimas: Vartotojo sutikimo patvirtinimas
04

Paleidimas ir tobulinimas

Diegiame sutartą versiją, dokumentų nuosavybę ir nustatome palaikymo, taisymų ir būsimų modulių prioritetus.

Pristatomas rezultatas: Paleidimo ir po paleidimo veiksmų planasPatvirtinimas: Paleidimo patvirtinimas

Įsitraukimas ir nuosavybė

Pasiūlyme atskirtas atradimas, MVP teikimas ir atsakomybė po paleidimo.

Apimtis ir kainodara priklauso nuo vaidmenų, darbo eigų, ekranų, integracijų, saugumo reikalavimų, projektavimo išsamumo ir esamų duomenų skaičiaus.

Mokamų produktų atradimas

Darbo eigos, vaidmenų, duomenų ir MVP sprendimai yra dokumentuojami prieš patvirtinant patikimą kūrimo sąmatą.

Etapinis MVP pristatymas

Pirmasis leidimas numatomas pagal sutartą apimtį. Nauji moduliai ir svarbūs pakeitimai planuojami vėlesniuose etapuose.

Perdavimas ir palaikymas

Šaltinio kodas, projektavimo ištekliai, talpinimas, duomenų bazės ir trečiųjų šalių paskyros dokumentuojamos pagal sutartį.

Laiko grafikas priklauso nuo darbo eigos sudėtingumo, vaidmenų, integracijų, testavimo ir sprendimų priėmimo greičio. Už talpinimą, mokėjimo paslaugų teikėjus, pranešimų siuntimo paslaugas, dirbtinio intelekto arba API naudojimą ir kitas trečiųjų šalių prenumeratas paprastai mokama atskirai. Palaikymas po paleidimo ir funkcijų kūrimas apibrėžiami kaip atskira nuolatinė apimtis.

Produkto parengtis

Ar pasirinktinis SaaS yra tinkama kita investicija?

Tvirtas atitikimas

Individualus kūrimas yra naudingas, kai darbo eiga yra stabili ir strategiškai svarbi

  • Suprantami pagrindiniai vartotojai ir darbo eiga.
  • Paruošta programinė įranga negali palaikyti svarbių verslo taisyklių.
  • Produkto savininkas gali priimti sprendimus ir išbandyti sistemą.
  • Įmonė gali finansuoti paiešką, pristatymą ir priežiūrą.
  • Pirmąją versiją galima susiaurinti iki kontroliuojamos apimties.

Ne pats tinkamiausias pirmas žingsnis

Pradėkite paprasčiau, kai procesas, nuosavybė ar produkto atvejis vis dar neaiškus

  • Darbo eiga keičiasi kiekvieną savaitę.
  • Standartinė platforma jau išsprendžia daugumą poreikių.
  • Pagrindinis reikalavimas yra tik svetainė, forma arba pagrindinė automatizacija.
  • Vidinis savininkas negali patvirtinti ir išbandyti produkto.
  • Pirmoje versijoje būtinos visos įmanomos įmonės funkcijos.

Prijungtos paslaugos

Individualūs produktai geriausiai veikia, kai viešoji patirtis ir paklausos maršrutai yra aiškūs

Naudokite šiuos susijusius maršrutus, kai produktui reikalinga vieša svetainė, paklausos patvirtinimas arba platesnė operacinė sistema aplink MVP.

SaaS DUK

SaaS apimties, kainos, nuosavybės ir paleidimo klausimai

Praktiniai atsakymai apie atradimą, MVP apimtį, technologijas, nuosavybę, saugumą, diegimą ir atsakomybę po paleidimo.

Kuriame tikslinius SaaS MVP, klientų portalus, vidinių operacijų įrankius, rezervavimo ir valdymo sistemas, CRM stiliaus darbo eigas, administravimo platformas ir su API susijusius produktus. Teisingas formatas priklauso nuo vartotojų, prieigos modelio ir darbo eigos.

Kaina priklauso nuo vartotojų vaidmenų skaičiaus, darbo eigų, ekranų, integracijų, duomenų sudėtingumo, saugumo reikalavimų, projektavimo išsamumo ir esamų sistemų. Produkto atradimas naudojamas patikimam etapiniam įvertinimui apibrėžti prieš pradedant visapusišką kūrimą.

Laiko grafikas priklauso nuo apimties, integracijų, testavimo ir to, kaip greitai patvirtinami su produktu susiję sprendimai. Konkretus darbo eiga gali būti užtikrintas greičiau nei daugiafunkcinė platforma su mokėjimais, perkėlimu ir sudėtingomis ataskaitomis.

Taip, kai reikia apibrėžti darbo eigą ar apimtį. „Discovery“ sukuria darbo eigos žemėlapį, vaidmenų ir duomenų sprendimus, MVP funkcijų sąrašą, integracijos reikalavimus, rizikas ir etapinį veiksmų planą.

Technologija parenkama aiškiai nustačius darbo eigos, saugumo, integracijos ir mastelio reikalavimus. Kai kurie produktai gali būti pradėti nuo „WordPress“ arba mažai kodo reikalaujančių komponentų, o kitiems reikalinga pritaikyta programos architektūra.

Taip. Lyginame skaičiuokles, esamas platformas, mažai kodo reikalaujantį ir individualų kūrimą. Individuali programinė įranga turėtų būti pasirinkta tik tada, kai svarbių vaidmenų, duomenų, taisyklių ar integracijų negalima tinkamai palaikyti paprastesniu variantu.

Prekės kodo, dizaino išteklių, talpinimo, duomenų bazių, domenų ir trečiųjų šalių paskyrų nuosavybė apibrėžta pasiūlyme. Pirmenybę teikiame kliento kontroliuojamoms paskyroms ir dokumentuotam perdavimui, kai tik tai leidžia pasirinkta platforma.

Diegimas įskaičiuotas, jei nurodytas sutartoje apimtyje. Už talpinimą, mokėjimo paslaugų teikėjus, pranešimų siuntimo paslaugas ir API naudojimą paprastai mokama atskirai. Stebėjimas, palaikymas, saugos atnaujinimai ir būsimas kūrimas apibrėžiami kaip paslaugos po paleidimo.

Atsižvelgdami į produktą, apibrėžiame autentifikavimą, vaidmenis, leidimų taisykles, saugomus duomenis, atsargines kopijas, registravimą ir atkūrimo poreikius. Reguliuojamoms arba labai jautrioms sistemoms gali prireikti specialisto atitikties ir saugumo peržiūros.

Taip. Prieš siūlydami tikslinį tobulinimo etapą, galime peržiūrėti esamą produktą dėl darbo eigos problemų, UX trikdžių, leidimų, duomenų struktūros, integracijų, techninių skolų ir plėtros prioritetų.

Mes daugiausia kuriame reaguojančias žiniatinklio programas ir naršyklės pagrindu veikiančius produktus. PWA arba vietinių mobiliųjų įrenginių kūrimas priklauso nuo vartotojo kelionės, įrenginio reikalavimų ir projekto apimties.

Pradėkite nuo mažiausio naudingo produkto

Reikia paversti darbo eigą aiškia MVP taikymo sritimi?

Pasidalykite naudotojais, dabartiniu procesu, duomenimis, įrankiais ir rezultatu, kurį sistema turėtų sukurti. Nustatysime, ar tinkamas pirmas žingsnis yra produkto atradimas, vidinis įrankis, portalas ar tikslinis SaaS MVP.

Užklausa dėl produkto apžvalgosAptarkite „WhatsApp“