När det kommer till mjukvaruprojekt, har du någonsin sett hur olika mjukvaruutvecklingsföretag och mjukvarutjänstdesignföretag beskriver ett projekt? Efter att ha läst deras beskrivningar, kan du snabbt förstå de specifika projektkraven och bakgrunden?

Vanliga sätt att beskriva mjukvaruprojekt inkluderar vanligtvis följande fyra punkter:

Introduktion till kundens bransch

Mjukvaruprojektets kunder finns inom alla branscher. För att presentera projektet för människor från olika branscher måste man börja med branschens bakgrund. Innehållet i branschintroduktionen inkluderar hur denna bransch kopplas till människors liv, vilka som är målgruppen för försäljning eller tjänster på marknaden? Vilken roll spelar kunden i denna bransch? Vilka övertygelser eller egenskaper har de? Vad är företagets framtidsvision? För att mjukvaruutvecklare ska kunna hantera kraven på rätt sätt, fungerar kundens branschintroduktion som en grund, vilket gör det lättare för utvecklingsteamet att förstå kundens perspektiv.

Problem i affärsprocessen (var behovet ligger)

Detta är den största motivationen för kunden. Vad är det som stör kunden i deras arbetsmiljö? Är det den befintliga arbetsprocessen som behöver digitaliseras, eller behöver det nuvarande informationssystemet omorganiseras efter år av användning, eller behöver man införa digitala åtgärder för att möta nya trender i branschen? Här behöver man objektivt och empatiskt förstå kundens situation.

Föreslagen lösning

Efter att ha nått en överenskommelse med kunden, föreslår mjukvaruföretaget skräddarsydda projektplaner och implementeringar som framgångsrikt kan tillämpas i kundens arbetsprocess.

Resultat

Jämfört med den gamla lösningen, vad är de objektiva slutsatserna om skillnader och förändringar som den nya lösningen har medfört för kunden, såsom förbättrad effektivitet i produktionslinjen, minskad tid för informationssammanställning, nya kanaler för att nå målgruppen...

Genom att sammanfatta dessa fyra punkter om mjukvaruprojekt kan vi få en grundläggande förståelse för projektet. Under diskussioner med kunden måste projektledaren också säkerställa att dessa beskrivningar är tydliga i våra sinnen. Eftersom en mjukvaruprojektsbeskrivning är flexibel, kan den kortfattat uttrycka vad projektet handlar om i en mening, eller beskriva projektets innehåll i en rapport. Då kan man försöka:

Skapa ett 'Kärnvärde' för att definiera projektets omfattning

Projekt är projekt eftersom de uppnår specifika mål med begränsade resurser. Men under processen att uppnå specifika mål, om det inte finns några begränsningar i omfattningen, kommer 'relaterade' funktioner att utvecklas. Dessa relaterade funktioner kan avsevärt förbättra hela lösningen, men kan också förlänga utvecklingstiden och orsaka förseningar i lanseringen; eller kanske de inte har någon konkret effekt på hela lösningen.

Exempel:

Kunden vill skapa en funktion i ett företagsinformationssystem där 'tryck på startknappen automatiskt utför schemalagda uppgifter'. Intuitivt kan det bara behövas att koppla ihop de kommande arbetsflödena i följd, men i verkligheten kan utvecklingen kräva att man tar hänsyn till olika affärslogiker beroende på systemets applikationsområde, såsom användarbehörigheter, status för tidigare körningar, systemets stabila anslutning... Då kan kunden plötsligt säga i diskussionsgruppen: 'Jag vill att det ska kännas levande och dynamiskt när jag trycker på start.'

När vi utvecklar mjukvara och planerar funktioner baserade på en enda användarberättelse, behöver vi ofta lägga till bedömningar av situationen och överväga olika affärslogiker. När kunden inte har några invändningar mot funktionerna kan fokus flyttas till gränssnittets färger, layout, knappbeteenden och övergångar, vilket kan leda till olika krav på att göra gränssnittet mer livligt.

Vad ska man göra när det uppstår en konflikt mellan utvecklingsfunktioner och kundens förväntade systemgränssnitt inom den begränsade utvecklingstiden?

Då måste vi återgå till det grundläggande 'Kärnvärdet' för att bekräfta nödvändigheten och prioriteringen av dessa relaterade funktioner med den tid och arbetskraft vi har. Kärnvärdet är ofta en kort och koncis slogan, som en kraftfull trollformel, som hjälper oss att överväga att lägga till eller ta bort användarberättelser, och genom att upprepa det tre gånger i våra sinnen kan vi få ett tydligt svar!

Från exemplet ovan, när kunden är envis, kan vi styra diskussionen till att tänka 'Vad är fördelarna med ett mer levande gränssnitt för företagets informationssystem?' 'Om vi behöver börja från design för att göra gränssnittet mer levande, kommer det att lägga till extra tid i planeringen och kan orsaka förseningar i lanseringen, är det okej?' Sedan föreslår vi att 'föreslå att prioritera de föreslagna kraven enligt 'Kärnvärdet' för att säkerställa att lanseringen sker i tid.'

För varje projekt, definiera det mest relevanta 'Kärnvärdet' tillsammans med kunden under diskussionerna

Projektets kärnvärde fungerar som en fyr, som leder oss i de omfattande diskussionerna, så att vi inte avviker från ämnet och återgår till projektets huvudfokus under utvecklingsteamets diskussioner eller när vi intervjuar eller godkänner krav med kunden.

Om du som läser denna artikel också är bekymrad över kundens krav, varför inte lista projektets kärnvärde för att övertyga både dig själv och kunden!