Når det kommer til programvareprosjekter, har du noen gang sett hvordan ulike programvareutviklingsselskaper eller programvaretjenestedesignselskaper beskriver et prosjekt? Etter å ha lest deres beskrivelser, kan du raskt forstå de konkrete prosjektbehovene og bakgrunnen?

Vanlige måter å beskrive programvareprosjekter på inkluderer ofte følgende fire punkter:

Kundeindustriintroduksjon

Kundene til programvareprosjekter kommer fra ulike bransjer. For å introdusere et prosjekt til folk fra forskjellige bransjer, må man starte med bakgrunnen til industrien. Innholdet i industribakgrunnsintroduksjonen inkluderer hvordan denne industrien kobles til folks liv, hvilke markeder eller målgrupper den retter seg mot, hvilken rolle kundens selskap eller individ spiller i denne industrien, hvilke tro eller egenskaper de har, og hva selskapets fremtidsvisjon er. For å la programvareutviklere håndtere behovene på en passende måte, fungerer kundens industriintroduksjon som en innledning som gjør det lettere for utviklingsteamet å forstå kundens perspektiv.

Problempunkter i forretningsprosessen (behovets opprinnelse)

Dette er hovedmotivasjonen for kunden. Hva slags situasjoner har kunden møtt i sitt arbeidsmiljø som har forårsaket problemer? Er det den eksisterende arbeidsflyten som trenger digitalisering, eller er det det nåværende informasjonssystemet som trenger omorganisering etter mange års bruk, eller er det behov for å innføre digitale tiltak som svar på nye trender i industrien? Her er det nødvendig å objektivt og empatisk forstå kundens situasjon.

Foreslåtte løsninger

Etter å ha nådd enighet med kunden, foreslår programvareselskapet skreddersydde prosjekterings- og implementeringsplaner som oppfyller behovene, og som kan anvendes vellykket i kundens arbeidsflyt.

Resultater

Sammenlignet med tidligere løsninger, hva slags forskjeller og endringer har den nye løsningen brakt til kunden? For eksempel: forbedring av produksjonsprosessens effektivitet, reduksjon av tiden brukt på å samle informasjon, eller å tilby nye kanaler for å nå ut til kunder...

Sammenfattende kan de fire beskrivelsene av programvareprosjekter hjelpe oss med å få en grunnleggende forståelse av prosjektet. Under diskusjoner med kunden må prosjektlederen også sørge for at disse beskrivelsene er klare i våre sinn. Fordi en programvareprosjektbeskrivelse er fleksibel, kan den være så kort som en setning som beskriver hva prosjektet gjør, eller så lang som en rapport som beskriver prosjektets innhold. På dette tidspunktet kan man prøve:

Å etablere en "kjerneverdi" som kan definere prosjektets omfang

Et prosjekt er et prosjekt fordi det oppnår et spesifikt mål med begrensede ressurser. Men i prosessen med å nå et spesifikt mål, hvis omfanget ikke er begrenset, vil det alltid dukke opp "relaterte" funksjoner. Disse relaterte funksjonene kan i stor grad forbedre den samlede løsningen, men kan også forlenge utviklingstiden, noe som fører til at prosjektet ikke kan lanseres i tide; eller de kan faktisk ikke ha noen konkret effekt på den samlede løsningen.

Eksempel:

Kunden ønsker å bygge en funksjon for et bedriftsinformasjonssystem som "starter automatisk planlagte oppgaver når startknappen trykkes". Intuitivt kan det bare være nødvendig å koble sammen de neste arbeidsprosessene i rekkefølge, men i virkeligheten kan utviklingssituasjonen kreve at man tar hensyn til forskjellige bruksområder for systemet, inkludert utførelsesrettigheter, statusen for forrige kjøring, om systemet er stabilt tilkoblet, og så videre. På dette tidspunktet sier kunden plutselig i diskusjonsgruppen: "Jeg vil at det skal føles levende og dynamisk når jeg trykker på start."

Når vi utvikler programvare, planlegger vi funksjoner basert på en enkelt brukerhistorie, men vi må ofte også vurdere konteksten og ulike forretningslogikker. Når kunden ikke har andre innvendinger mot funksjonaliteten, kan fokuset skifte til grensesnittets farger, layout, knappens oppførsel, sideoverganger, og så videre, og det kan oppstå ulike krav om at skjermen skal være mer livlig.

Hva gjør vi når det oppstår konflikter mellom utviklingsfunksjoner og kundens forventninger til systemgrensesnittet innenfor en begrenset utviklingstid?

Da må vi gå tilbake til den grunnleggende "kjerneverdien" for å bekrefte nødvendigheten og prioriteten til de relaterte funksjonene med tanke på den tilgjengelige tiden og arbeidskraften. Kjerneverdien er ofte en kort og konsis setning, som en kraftig formel, som kan hjelpe oss med å få klare svar når vi vurderer å legge til eller fjerne brukerhistorier!

Fra eksempelet ovenfor, når kunden blir vedvarende, kan vi lede diskusjonen til å tenke "Hva er fordelene med et mer levende grensesnitt for driften av bedriftsinformasjonssystemet?" "Hvis vi trenger å starte fra design for å gjøre grensesnittet mer levende, vil det legge til ekstra tid i planleggingen, noe som kan føre til forsinket lansering. Er det greit?" Deretter foreslår vi "å prioritere forespørslene i henhold til 'kjerneverdien' for å sikre at prosjektet kan lanseres i tide."

Sammen med kunden, fastsett den mest passende "kjerneverdien" for hvert prosjekt

Prosjektets kjerneverdi fungerer som et fyrtårn, enten vi diskuterer i utviklingsteamet eller intervjuer kunden om behov eller aksept, og leder oss gjennom det store havet av diskusjoner uten å avvike fra temaet, tilbake til prosjektets hovedfokus. Hvis du som leser denne artikkelen også er bekymret for kundens forespørsler, kan du prøve å liste opp prosjektets kjerneverdi for å overbevise både deg selv og kunden!