Når det kommer til softwareprojekter, har du nogensinde set, hvordan forskellige softwareudviklingsfirmaer og softwaretjenestedesignfirmaer beskriver et projekt? Efter at have læst deres beskrivelser, kan du hurtigt forstå de konkrete projektkrav og baggrund?

Den almindelige måde at beskrive softwareprojekter på inkluderer typisk følgende fire punkter:

Kundeindustriens introduktion

Softwareprojekter tjener kunder på tværs af forskellige industrier. Når man skal introducere et projekt til folk fra forskellige industrier, er det nødvendigt at starte med industribaggrunden. Indholdet af industribaggrunden inkluderer, hvordan denne industri forbinder med folks liv, hvilke markeder eller målgrupper der er, hvilken rolle kunden spiller i denne industri, hvilke overbevisninger eller karakteristika de har, og hvad virksomhedens fremtidsvision er. For at softwareudviklere kan håndtere kravene passende, hjælper det at introducere kundens industri med at give udviklingsteamet en bedre forståelse af kundens perspektiv.

Problempunkter i forretningsprocessen (hvor behovet ligger)

Dette er den største motivation for kunden. Hvilke situationer har kunden oplevet i deres arbejdsmiljø, der har forårsaget bekymring? Er det den eksisterende arbejdsgang, der skal digitaliseres, eller er det det nuværende informationssystem, der efter mange års brug skal omstruktureres, eller er det nødvendigt at implementere digitale foranstaltninger for at imødekomme nye tendenser i industrien? Her er det nødvendigt at forstå kundens situation objektivt og empatisk.

Foreslåede løsninger

Efter at have nået enighed med kunden, foreslår softwarefirmaet skræddersyede projekter og implementeringer, der opfylder kravene og kan anvendes med succes i kundens arbejdsgang.

Resultater

Sammenlignet med de gamle løsninger, hvad er de objektive konklusioner om forskellene og ændringerne, som den nye løsning har bragt til kunden, såsom forbedret effektivitet i produktionslinjen, reduceret tid til at integrere information, eller nye kanaler til at nå ud til kunder?

Ved at kombinere de ovennævnte fire beskrivelser af softwareprojekter kan vi få en grundlæggende forståelse af projektet. Under diskussionen med kunden skal projektlederen også sikre, at disse beskrivelser er klare i vores sind. Fordi en softwareprojektsbeskrivelse er fleksibel, kan den være kort og præcis eller detaljeret som en rapport. På dette tidspunkt kan du prøve:

Opret en "kerneværdi", der kan definere projektets omfang

Et projekt er et projekt, fordi det opnår et specifikt mål med begrænsede ressourcer. Men i processen med at nå det specifikke mål, hvis der ikke er nogen begrænsning af omfanget, vil der opstå "relaterede" funktioner. Disse relaterede funktioner kan muligvis forbedre den samlede løsning betydeligt, men de kan også forlænge udviklingstiden og forhindre, at projektet lanceres til tiden; eller de kan faktisk ikke bidrage væsentligt til den samlede løsning.

Eksempel:

Kunden ønsker at oprette en funktion i et virksomhedsinformationssystem, der "automatisk udfører planlagte opgaver, når startknappen trykkes". Intuitivt kan det kun kræve, at de efterfølgende arbejdsgange kædes sammen og udføres i rækkefølge. Men i den faktiske udviklingssituation kan det være nødvendigt at tilføje forretningslogik som brugerrettigheder, status for tidligere udførelser, og om systemet er stabilt forbundet, afhængigt af anvendelsesområdet for systemet. På dette tidspunkt siger kunden pludselig i diskussionsgruppen: "Jeg vil have en følelse af liv og bevægelse, når jeg trykker på startknappen."

Under softwareudvikling, når vi planlægger funktioner baseret på en enkelt brugerhistorie, er det ofte nødvendigt at tilføje vurderinger af konteksten og overveje forskellige forretningslogikker. Når kunden ikke har andre indvendinger mod funktionerne, kan de skifte fokus til interfacefarver, layout, knapadfærd og sideovergange og begynde at insistere på, at skærmen skal være mere livlig.

Hvad skal man gøre, når der opstår konflikter mellem udviklingsfunktioner og kundens forventede systeminterface inden for den begrænsede udviklingstid?

På dette tidspunkt skal vi vende tilbage til den grundlæggende "kerneværdi" for at bekræfte nødvendigheden og prioriteten af de eksisterende funktioner i forhold til den tilgængelige tid og arbejdskraft. Kerneværdien er ofte en kort og præcis sætning, der fungerer som en stærk trylleformel, der hjælper os med at få klare svar, når vi overvejer at tilføje eller fjerne brugerhistorier. Fra det tidligere nævnte eksempel, når kunden insisterer, kan vi lede diskussionen til at overveje "Hvad er fordelene ved en mere levende skærm for driften af virksomhedsinformationssystemet?" "Hvis vi skal gøre skærmen mere levende, kræver det ekstra tid til design, hvilket kan forsinke lanceringen. Er det okay?" Derefter foreslår vi "at prioritere de foreslåede krav i henhold til 'kerneværdien' for at sikre, at vi kan lancere til tiden."

Fastlæg den mest passende "kerneværdi" sammen med kunden for hvert projekt

Projektets kerneværdi fungerer som et fyrtårn, der guider os gennem diskussionerne, så vi ikke afviger fra emnet og kan vende tilbage til projektets hovedfokus under udviklingsteamdiskussioner eller kundemøder. Hvis du, der læser denne artikel i dag, også er bekymret over de krav, kunden har fremsat, kan du overveje at liste projektets kerneværdi for at overbevise dig selv og kunden!