Brugerdefinerede handelselementer
Hvornår har en online shop brug for brugerdefineret udvikling?
Beslut om et butikskrav kræver konfiguration, en udvidelse eller brugerdefineret udvikling. Definér køberrejsen, afhængigheder og accept først.
Brugerdefineret udvikling er nyttig, når det løser et defineret krav. Det er ikke automatisk bedre end en platform funktion, en passende udvidelse eller en enklere købsproces.
For en ny butik er det praktiske spørgsmål: Hvad skal kunden eller administratoren gøre, at den valgte opsætning ikke allerede understøtter godt nok til dette projekt?
Skriv kravet uden at navngive et plugin
Start med adfærden. For eksempel: "En kunde vælger et serviceområde, før de leveringsmuligheder, der er tilgængelige for deres ordre". Det beskriver en købsregel.
"Installer en levering plugin" beskriver en mulig implementering. Det ikke fastslå, om plugin kan anvende den rigtige regel, hvad der sker, når adressen ændres, eller hvordan virksomheden vedligeholder oplysningerne.
Brug en konkret eksempel rækkefølge til at forklare kravet. Inkludér de oplysninger, kunden giver, den beslutning, butikken gør, og hvad administratoren har brug for at se bagefter.
Overvej konfiguration først
Kontroller om den valgte platform og godkendte komponenter kan opfylde kravet gennem deres understøttede indstillinger. En konfigureringsbaseret løsning kan være tilstrækkelig, når adfærden allerede er en del af opsætningen.
Beslutningen kræver stadig test. En indstilling, der lyder relevant, er ikke bevis for, at hele kunderejsen fungerer efter hensigten. Verificer det repræsentative produkt, orden og kundesager, før du behandler kravet som løst.
Dette er en projekt- niveau evaluering, ikke en påstand om, at hver WooCommerce eller Shopware installation giver de samme funktioner.
Vurdere en udvidelse mod arbejdsgangen
En udvidelse bør vurderes i forhold til det faktiske behov, platformmiljøet og dets afhængigheder. Bekræft, hvordan det vil blive konfigureret, hvilken konto eller licens det har brug for, og hvad ansvar forbliver efter lanceringen.
En feature liste kan skjule et vigtigt mismatch. Udvidelsen kan understøtte en lignende workflow, men ikke den præcise beslutning din virksomhed har brug for. Gør denne forskel eksplicit i stedet for at antage, at kunden vil tilpasse sig efter køb.
Køb ikke software, blot fordi ordlyden ligner briefingen. Ejeren skal godkende eventuelle omkostninger efter pasform og betingelser er forstået.
Brug brugerdefineret udvikling til den definerede kløft
En brugerdefineret komponent kan være hensigtsmæssig, når projektet har brug for et bestemt trin, en bestemt regel eller en bestemt forbindelse, som ikke leveres af den aftalte opsætning. Eksempler kan omfatte en specialiseret produktudvælgelsesstrøm, en intern godkendelse før opfyldelse eller en dokumenteret integration med et andet forretningssystem.
Disse er illustrative skoper, ikke funktioner hver butik behov. Det brugerdefinerede arbejde bør have en klar grænse: hvad det modtager, hvad det ændrer, og hvad det efterlader til den eksisterende platform.
Undgå at genopbygge almindelig platformsadfærd blot for at få projektet til at lyde mere sofistikeret. Mere kode betyder også mere projektspecifik adfærd for nogen at forstå senere.
Beslut hvad der sker uden for den ideelle sti
Hvad hvis kunden ændrer en option, betaling ikke fuldføre eller det eksterne system afviser en ordre? Kan administratoren se problemet? Kan operationen blive prøvet igen uden at oprette duplikerede poster?
De relevante undtagelser hører til i acceptkriterierne. Ellers kan den første vellykkede demonstration skjule det arbejde, der er nødvendigt for en brugbar udgivelse.
Sørg for, at de kommercielle ansvarsområder er synlige
Emner, udvidelser, betalingstjenester, hosting og eksterne systemer har deres egne regnskaber og betingelser. Udviklingsgebyrer og tredjepartsomkostninger bør kunne skelnes i forslaget.
Overdragelsen bør identificere brugerdefinerede komponenter og deres afhængigheder, sammen med konfigurations- og udgivelsesansvar, der indgår i projektet. Fremtidige platformsændringer eller nye forretningsregler kan kræve en separat planlagt opdatering.
En nyttig afgørelse record
Før indsættelse af funktionen, skrive ned forretningskravet, en eksempel ordre, de muligheder, der overvejes, den valgte tilgang, og hvorfor det passer. Tilføj accept test, afhængigheder og den person, der er ansvarlig for løbende forretningskonfiguration.
Denne rekord behøver ikke at være lang. Dens formål er at forhindre "vi har brug for brugerdefineret udvikling" i at blive en erstatning for at beskrive, hvad butikken skal gøre.
Udvikling af e-handel, WooCommerce eller ShopwareFor at diskutere en ny bygning, sende handelen kort.