Tilpasset handel funksjoner
Når trenger en nettbutikk tilpasset utvikling?
Bestem om en butikk krav trenger konfigurasjon, en forlengelse eller egendefinert utvikling. Definere kjøpereisen, avhengighetene og aksepten først.
Tilpasset utvikling er nyttig når det løser et definert krav. Det er ikke automatisk bedre enn en plattformfunksjon, en egnet utvidelse eller en enklere kjøpsprosess.
For en ny butikk er det praktiske spørsmålet: Hva må kunden eller administratoren gjøre som det valgte oppsettet ikke allerede støtter godt nok for dette prosjektet?
Skriv kravet uten å navngi et plugin
Start med atferden. For eksempel: \"En kunde velger et serviceområde før du ser leveringsalternativene som er tilgjengelige for bestillingen.\" Det beskriver en kjøpsregel.
\"Installer en leveringsplugin\" beskriver en mulig implementasjon. Det fastslår ikke om plugin kan anvende riktig regel, hva som skjer når adressen endres eller hvordan virksomheten opprettholder informasjonen.
Bruk et konkret eksempel for å forklare kravet. Inkluder informasjonen kunden gir, avgjørelsen butikken gjør og hva administratoren trenger å se etterpå.
Tenk på konfigurasjon først
Sjekk om den valgte plattformen og godkjente komponenter kan oppfylle kravet gjennom deres støttede innstillinger. En konfigurasjonsbasert løsning kan være tilstrekkelig når atferden allerede er en del av oppsettet.
Beslutningen trenger fortsatt testing. En innstilling som høres relevant ut, er ikke bevis på at hele kundereisen fungerer som tiltenkt. Kontroller det representative produktet, bestillings- og kundesaker før du behandler kravet som løst.
Dette er en prosjektnivå vurdering, ikke et krav om at hver WooCommerce eller Shopware installasjon gir de samme funksjonene.
Evaluer en forlengelse mot arbeidsflyten
En utvidelse bør vurderes mot det faktiske kravet, plattformmiljøet og avhengighetene. Bekreft hvordan den vil bli konfigurert, hvilken konto eller lisens den trenger, og hvilket ansvar som gjenstår etter lanseringen.
En funksjonsliste kan skjule en betydelig feil. Utvidelsen kan støtte en lignende arbeidsflyt, men ikke den nøyaktige avgjørelsen virksomheten trenger. Gjør den forskjellen eksplisitt i stedet for å anta at klienten vil tilpasse seg etter kjøp.
Ikke kjøp programvare bare fordi ordlyden ligner kort. Eieren bør godkjenne enhver kostnad etter passform og betingelser er forstått.
Bruk egendefinert utvikling for det definerte gapet
En egendefinert komponent kan være passende når prosjektet trenger et bestemt trinn, regel eller tilkobling som ikke leveres av det avtalte oppsettet. Eksempler kan omfatte en spesialisert produktvalgstrøm, intern godkjenning før gjennomføring eller dokumentert integrasjon med et annet forretningssystem.
Disse er illustrative omfang, ikke har alle butikk behov. Det tilpassede arbeidet bør ha en klar grense: hva det mottar, hva det endrer seg og hva det etterlater seg til den eksisterende plattformen.
Unngå å gjenoppbygge vanlig plattformadferd bare for å gjøre prosjektet mer sofistikert. Mer kode betyr også mer prosjektspesifikk oppførsel for noen å forstå senere.
Bestem hva som skjer utenfor den ideelle veien
Hva om kunden endrer et alternativ, betaling ikke fullfører eller det eksterne systemet avviser en bestilling? Kan administratoren se problemet? Kan operasjonen komme tilbake uten å opprette dupliserte poster?
De relevante unntakene hører til i akseptkriteriene. Ellers kan den første vellykkede demonstrasjonen skjule arbeidet som trengs for en brukbar utgivelse.
Hold det kommersielle ansvaret synlig
Temaer, utvidelser, betalingstjenester, hosting og eksterne systemer har sine egne kontoer og betingelser. Utviklingsgebyrer og tredjepartskostnader bør være forskjellig i forslaget.
Overleveringen bør identifisere egendefinerte komponenter og deres avhengigheter, sammen med konfigurasjonen og frigjøringsansvaret som er inkludert i prosjektet. Fremtidige plattformendringer eller nye forretningsregler kan kreve en separat planlagt oppdatering.
En nyttig beslutningsrekord
Før du idriftsetter funksjonen, skriv ned forretningskravet, en eksempelordre, de aktuelle alternativene, den valgte tilnærmingen og hvorfor den passer. Legg til aksepttesten, avhengighetene og personen som er ansvarlig for pågående forretningskonfigurasjon.
Denne rekorden trenger ikke å være lang. Dens formål er å hindre at “vi trenger egendefinert utvikling” blir en erstatning for å beskrive hva butikken trenger å gjøre.
Utforsk e-handelsutvikling, WooCommerce eller ShopwareFor å diskutere en ny bygning, Send handelen kort.