produktchefen beskrives ofte som “broen mellem forretning, Design og teknologi”. Broen” mellem design og tech ” -delen er især kritisk, når det kommer til forsendelse af et kvalitetsprodukt: bugfri, perfekt, og der tager højde for alle mulige scenarii-og edge-sager. For at sikre, at bridge fungerer godt, er der flere måder, det håndteres af designteamet:

• designeren sender en omfattende prototype, der viser alle strømme af produktet. Desværre, dette vil ofte gange tage en masse tid og vil stadig gå glip af et par kant sager.
• designeren sender kun en prototype, der viser de vigtigste strømme af funktionen, og forbliver tilgængelig for spørgsmål fra udviklingsholdet. Desværre er disse frem og tilbage meget ineffektive (især i en fjernopsætning) og spilder meget tid fra både design-og udviklingsteam.
• designeren, ud over den omfattende prototype, skriver en ordentlig SPECIFIKATIONER dokument, der viser alle de mulige scenarii og kant sager. Problemet er, at det ofte er spild af tid, fordi (1) designernes dyrebare tid vil blive bedre brugt ved faktisk at designe andre funktioner, ikke skrive et spec doc, og (2) de har ikke altid den samme 360-liters visning af produktet som produktchefer gør, hvilket vil få dem til at overse nogle scenarii og edge cases.

derfor overlader modne produktteam normalt skrivningen af deres produktspecifikationer til produktchefer.

men hvordan skal du skrive produktspecifikationer? Jeg har skrevet produktspecifikationer for de sidste 5 år, og jeg fandt et format, der er godt værdsat af de programteams, jeg arbejder med. I dette indlæg deler jeg mere om min metode og de værktøjer, jeg bruger til at skrive produktspecifikationer. Jeg beskriver også nogle begrænsninger, som jeg står over for med de værktøjer, jeg bruger, og nogle ideer om forbedring, jeg har i tankerne.

Her er de 5 hovedemner, som jeg behandler i en produktspecifikation:

1. kontekst og mål
2. Arkitekturkort
3. Epics og brugerhistorier
4. acceptkriterier
5. design, indhold og oversættelser

kontekst og mål

selvom produktspecifikationen primært er rettet mod programmelteams, vil de stadig gerne vide, hvorfor de arbejder på det, de arbejder på. Jeg er kommet til at forstå, at en af de vigtigste drivkræfter for motivation for programmel ingeniører er impact. De fleste af dem drømmer om at arbejde på funktioner, der bruges af millioner af brugere. De er begejstrede, når de hører, at den nye enhed, de har implementeret, har øget fastholdelsen med 15%, for eksempel. Så det er vigtigt at give kontekst om den funktion, de vil implementere:

• hvad taler vi om? Hvilken del af produktet? Du er velkommen til at tilføje enhver historie om den funktion, der er nyttig til at forstå den aktuelle situation.
• hvad er det aktuelle problem? Bemærk: der kan være flere problemer at løse.
• er der nogen kvalitativ feedback / verbatims fra brugere, der skal citeres?
• er der nogen data (f. eks. grafer), der skal vises? I dette afsnit er du velkommen til at medtage diagrammer eller grafer, der gør dataene mere forståelige.
• hvad er den valgte løsning? (beskriv det simpelthen i nogle få sætninger)
• er der overvejet nogen anden løsning? Hvis ja, hvorfor er det blevet afsat?
• er der allerede implementeret en anden løsning? Hvordan har det fungeret?
• hvad er målene ? Er der nogen KPI, vi forsøger at påvirke? Dette vil især hjælpe programmelteamet med at forstå, om de har brug for at implementere nye trackere / tags / begivenheder for korrekt indsamling af dataene. Jeg har set hold føle sig så drevet af projektet, at de tog initiativ til at opsætte dashboards for at følge metrics i realtid, uden at jeg eller nogen andre beder om det.

Arkitekturkort

før du går for meget ind i detaljerne i funktionen, er det vigtigt at give et overblik på højt niveau over, hvad der ændrer sig, og hvad der forbliver det samme i dit produkt. Og selvom du arbejder på et helt nyt produkt, vil et arkitekturkort stadig være yderst relevant for at forstå, hvordan produktet er struktureret.

“Arkitekturkort” er den måde, jeg kalder en diagramrepræsentation på højt niveau af produktets funktioner (strømme, skærme og indhold) og hvordan de er relateret sammen. Nogle kalder det” informationsarkitektur”,” strømkort”,” kortlægning ” osv.

Der er ingen officiel metode til, hvordan man tegner et arkitekturkort. På en mobilapplikation forsøger jeg normalt at differentiere strømme, skærme og “dele af en skærm” (eller “indhold på siden”) ved at bruge en anden form for hver af dem, som beskrevet i forklaringen ovenfor.

det kan også være nyttigt at spille på farvekoden. I eksemplet ovenfor brugte jeg 3 farver og også solid vs stiplet linje for at forklare, hvordan den aktuelle informationsarkitektur ville blive opdateret med den nye opdatering af den applikation, vi arbejdede på. (grøn: vil forblive som den er, orange: vil blive opdateret, rød: vil blive slettet; solid: vil forblive på samme sted, prikket: vil blive flyttet et andet sted). På den måde havde ingeniører et klart fugleperspektiv på, hvilken del af applikationen der kunne ændres.

et andet tip til at opbygge et forståeligt arkitekturkort er at skelne klart de forskellige dele af navigationen, som det gøres nedenfor med separate områder for hver af dem.

at have et arkitekturkort vil være yderst nyttigt til din produktspecifikation; det giver dig mulighed for at fremhæve, hvilken del af produktet du taler om i hver af dine brugerhistorier.

hvilket værktøj skal du bruge til at tegne et arkitekturkort? Der er masser af dem tilgængelige derude, min favorit er lunefuld (fordi den er visuelt behagelig og meget ligetil, ikke rodet med så mange funktioner), men jeg brugte også Draw.io tidligere-hvilket er interessant, fordi det er integreret med Google Drev, Så hvis du arbejder med Google Slides og Google Docs, gør det det rart at bruge. Det er også integreret med JIRA og Confluence.

Hvis du vil lære mere om arkitekturkort (do ‘s and don’ ts, hvilke værktøjer der skal bruges, nogle eksempler osv.), Toptal er kommet med en god læsning: Den omfattende Guide til informationsarkitektur.

Epics og brugerhistorier

nedbrydning og forklaring af alle dele af dit produkt kan meget hurtigt blive ret kaotisk. Skrivning af produktspecifikationer i løbet af de sidste 5 år er den bedste måde, jeg har fundet for at holde specifikationerne organiserede og forståelige, at nedbryde dem i henhold til “brugerhistorier”.

Hvad er en brugerhistorie? Ifølge Agile Modeling er en brugerhistorie ” en definition på meget højt niveau af et krav, der indeholder lige nok information, så udviklerne kan producere et rimeligt skøn over indsatsen for at implementere det.”

ideen med brugerhistorier er at sætte brugerne først og undgå at bruge udelukkende obskure & teknisk ordforråd, når man diskuterer funktioner. Som Atlassian udtrykker det: “efter at have læst en brugerhistorie ved teamet, hvorfor de bygger, hvad de bygger, og hvilken værdi det skaber.”

de sigter mod at opbygge et bedre produkt, hvor brugeren er i centrum for debatterne, i modsætning til god gammel vandfaldsproduktudvikling.

sådan skal en brugerhistorie formuleres:

som en < type bruger >, jeg vil < nogle mål > så < en eller anden grund >.

for eksempel, her er hvordan vi kunne formulere brugerhistorier for følgende subpart af arkitekturkortet, jeg tegnede for en af mine klienter:

• brugerhistorie #1: som medarbejder i profilsektionen vil jeg redigere min profil, så jeg kan opdatere mit foto, fornavn og efternavn.
• brugerhistorie #2: Som medarbejder i profilsektionen vil jeg have adgang til indstillingerne, så jeg kan opdatere min adgangskode og opdatere meddelelsespræferencer.
• brugerhistorie # 3: Som medarbejder i profilsektionen vil jeg få adgang til chatten, så jeg kan give feedback til appens udviklere

det er op til produktchefen at beslutte, hvilket niveau af detaljer de vil dække i brugerhistorien. Hvis vi ville, kunne vi også gå et niveau dybere i Brugerhistorien #2, for eksempel:

• brugerhistorie #2.a: Som medarbejder i indstillingerne vil jeg få adgang til afsnittet “Rediger adgangskode”, så jeg kan opdatere min adgangskode
• brugerhistorie #2.b: som medarbejder i indstillingerne vil jeg få adgang til meddelelsespræferencerne, så jeg kan opdatere med hvilken frekvens jeg modtager hver type meddelelser

men som du ser, er dette noget indlysende og overflødigt. Jeg valgte personligt at dække disse scenarii i” acceptkriterierne ” (se næste afsnit) af de pågældende historier.

for at organisere brugerhistorier bruger vi ofte “epics”. I agile termer er” epics ” store mængder arbejde, der kan opdeles i mindre brugerhistorier. Jeg bruger personligt epics til at gruppere historier, der er en del af det samme tema eller område i produktet. For eksempel, Jeg har valgt at gruppere historierne ovenfor som en del af “profil” – epikken. Nogle mennesker vælger at formulere epos på samme måde som brugerhistorier med en enklere struktur (f. eks. “Som bruger vil jeg have adgang til min profil”)

acceptkriterier

for at sikre, at der tilføjes nok detaljer til en brugerhistorie, bruger vi” acceptkriterier “(undertiden også kaldet”betingelser for tilfredshed”).

ifølge LeadingAgile.com, ” acceptkriterier “er” de betingelser, som et produkt skal opfylde for at blive accepteret af en bruger, kunde, eller i tilfælde af systemniveaufunktionalitet, det forbrugende system.”

i acceptkriterierne skal du liste alle de funktionelle specificiteter, der ikke er tydeligt stavet ud af brugerhistorien. Eksempel:

brugerhistorie

som medarbejder i profilsektionen vil jeg redigere min profil, så jeg kan opdatere mit foto, fornavn og efternavn.

acceptkriterier

• i betragtning af at jeg er på redigeringsprofilskærmen, når jeg klikker på ikonet Rediger fornavn, skal det skifte til redigeringstilstand, fokusere på input og åbne tastaturet (samme for efternavn)
• i betragtning af at jeg er på redigeringsprofilskærmen, når jeg klikker på ikonet Rediger foto, skal det bede mig om at vælge mellem kamera og bibliotek
• i betragtning af at jeg redigerer mit fornavn, når jeg klikker på “Gem”, skal det omdirigere mig til læsetilstand, når jeg og jeg skulle se en succesmeddelelse

etc…

tænk på acceptkriterierne som en tjekliste, der skal udfyldes for at produktet skal sendes. Det givne/hvornår / da-format, der bruges ovenfor, er en god måde at hjælpe dig med at formulere dine acceptkriterier, men i nogle tilfælde kan det være udfordrende at bruge.

Design, indhold og oversættelser

at have opdaterede designs i dine produktspecifikationer

indtil videre har jeg ikke nævnt, hvilket værktøj jeg bruger til at skrive SPECIFIKATIONER. Tidligere har jeg skiftet mellem Google Docs, Google Slides og Notion. Jeg nød virkelig at bruge Notion til alle de seje integrationer, det tilbyder (især dem med InVision og Figma). Men jeg har nu helt skiftet til Google Docs: jeg foretrækker at have mere frihed på den måde, jeg formaterer mine produktspecifikationer. Det er også mere praktisk at bruge Google-produkter, når du arbejder med eksterne partnere eller klienter.

for at sikre, at dit produkts visuelle identitet bringes nøjagtigt til live af udviklingsholdet, er det vigtigt at give dem adgang til de mest opdaterede skærme, der sendes af din designer(e). Men da der ikke er nogen reel integration mellem Google Docs og designværktøjer som Figma, InVision eller Heplin, plejede jeg at eksportere skærme og kopiere/indsætte dem i mine produktspecifikationer.

dette ville meget hurtigt blive et problem: designere gentager på deres skærme dagligt, og selv når alt er aftalt på en skærm, kan det ændre sig et par uger senere på grund af en bestemt komponent, der opdateres i designbiblioteket. Dette ville få mine SPECIFIKATIONER til at være forældede det meste af tiden.

derfor bruger jeg i dag kun skærmenes navn. For eksempel, hvis en brugerhistorie om profiludgave handler om 2 skærme, der er designet på Figma, vil jeg kun skrive “Figma-skærmnavn: Rediger-Profil-1 og Rediger-Profil-2”.

selvfølgelig er dette ikke ideelt og begrænser udviklere eller andre, der læser mine specifikationer for at skifte mellem flere værktøjer.

men dette viser, at der i dag er noget ineffektivt i den måde, vi skriver produktspecifikationer på. Brug af flere produkter rejser spørgsmålene om integration og synkronisering. Hvordan sikrer man, at alle de oplysninger, der er nødvendige for at opbygge et produkt, er synlige på et enkelt sted uden at være forældet? (Faktisk gælder dette ikke kun design, men også arkitekturkort og indhold).hvis du også oplever dette problem og har fundet en løsning, ville jeg være interesseret i at få din feedback!

giver nem adgang til indhold og oversættelser for at undgå skrivefejl

når du designer skærme med en stor mængde indhold, er det rart at give udviklere mulighed for nemt at kopiere / indsætte det i stedet for at skulle skrive det igen selv. Ellers kan du ende med (1) mange stavefejl og (2) pissed udviklere. Der er flere måder, du kan give dem adgang til indholdet:

• ved at give dem adgang til kildefilerne til designarbejdet på f.eks.
• ved at kopiere / indsætte indholdet direkte i spec (det kan gøre det lidt rodet).

Hvis dit produkt findes på flere sprog, skal du også give adgang til hver oversættelse. For eksempel kan du bruge et array til at vise oversættelsen af dit originale indhold på hvert sprog. Det næste niveau af oversættelsesstyring er at bruge et lokaliseringsværktøj (som sætning) og kun tilføje “oversættelsestasterne” i din produktspecifikation. Men igen indebærer dette endnu en frem og tilbage mellem dine produktspecifikationer og et andet værktøj.