Produktový Manažer je často popisován jako „most mezi business, design a tech“. Most „mezi designem a technologií“ je obzvláště důležitý, pokud jde o přepravu kvalitního produktu: bezchybný, pixel-perfektní a který bere v úvahu všechny možné scénáře a okrajové případy. Ujistěte se, že bridge funguje dobře, zde je několik způsobů, jak je zpracována projekční tým:

• návrhář lodí komplexní prototyp, který ukazuje všechny toky produktu. Bohužel to bude často trvat hodně času a stále bude chybět několik okrajových případů.
• návrhář dodá pouze prototyp, který zobrazuje hlavní toky funkce a zůstává k dispozici pro dotazy vývojového týmu. Bohužel, tyto tam a zpět jsou vysoce neefektivní (zejména ve vzdáleném nastavení)a ztrácejí spoustu času jak z konstrukčního, tak z vývojového týmu.
• konstruktér kromě komplexního prototypu napíše řádný specifikační dokument, který uvádí všechny možné scénáře a případy hran. Problém je, že to je často ztráta času, protože (1) návrháři drahocenný čas bude lépe využity, tím vlastně navrhování dalších funkcí, napsat spec doc, a (2) nemají vždy stejné 360° pohled na produkt jako produkt manažerů, které způsobí, je, aby přehlédnout některé scenarii a edge případů.

to je důvod, proč týmy vyspělých produktů obvykle svěřují psaní svých specifikací produktů produktovým manažerům.

ale jak byste měli psát specifikace produktu? Napsal jsem specifikace produktu za posledních 5 let a našel jsem formát, který je dobře ocení software týmy, se kterými pracuji. V tomto příspěvku sdílím více o své metodice a nástrojích, které používám k psaní specifikací produktu. Popisuji také některá omezení, kterým čelím s nástroji, které používám, a některé nápady na zlepšení, které mám na mysli.

zde je 5 hlavních témat, kterým se věnuji ve specifikaci produktu:

1. Kontext a cíle
2. Architektura mapě
3. Eposy a Uživatelské příběhy
4. kritéria Přijetí
5. Design, obsahu a překlady

Kontext a cíle

I když se na produkt spec je zaměřena především pro softwarové týmy, oni ještě chtěli vědět, proč pracují na co pracují na. Pochopil jsem, že jedním z hlavních tahounů motivace softwarových inženýrů je impact. Většina z nich sní o práci na funkcích, které používají miliony uživatelů. Jsou nadšeni, když slyší, že nový UX, který implementovali, zvýšil retenci například o 15%. Je tedy důležité uvést kontext o funkci, kterou budou implementovat:

• o čem mluvíme? Která část produktu? Neváhejte přidat jakoukoli historii funkce, která je užitečná pro pochopení současné situace.
• jaký je aktuální problém? Poznámka: může být několik problémů k vyřešení.
• existuje nějaká kvalitativní zpětná vazba / doslovnost od uživatelů, které mají být citovány?
• je třeba zobrazit nějaká data (např. grafy)? V této části neváhejte zahrnout jakékoli grafy nebo grafy, díky nimž budou data srozumitelnější.
• jaké je zvolené řešení? (popište to jednoduše, v několika větách)
• uvažovalo se o nějakém jiném řešení? Pokud ano, proč byl zrušen?
• bylo již implementováno nějaké jiné řešení? Jak si vede?
• jaké jsou cíle ? Je nějaký KPI, který se snažíme ovlivnit? To zejména pomůže softwarovému týmu pochopit, zda potřebují implementovat nové sledovače / značky / události, aby správně shromažďovaly data. Viděl jsem týmy pocit, takže vedený projekt, který vzali iniciativu, aby se nastavení panelů sledovat metriky v reálném čase, aniž by mě nebo kohokoliv jiného si o to.

Architektura mapy

, Než jít příliš do podrobností o funkci, je důležité, aby na vysoké úrovni přehled o tom, co se změní a co zůstane stejné ve vašem produktu. A i když pracujete na zcela novém produktu, mapa architektury bude stále velmi důležitá pro pochopení struktury produktu.

„mapa architektury“ je způsob, jakým nazývám vysokoúrovňové znázornění funkcí produktu (toků, obrazovek a obsahu) a jejich vzájemného vztahu. Někteří lidé to nazývají „informační architektura“, „mapa toku“, „mapování UX“ atd.

Neexistuje žádná oficiální metodika, jak k tomu architektura mapě. V mobilní aplikaci se obvykle snažím rozlišit toky, obrazovky a „části obrazovky“ (nebo „obsah na stránce“) pomocí jiného tvaru pro každou z nich, jak je podrobně popsáno v legendě výše.

může být také užitečné hrát na barevném kódu. Ve výše uvedeném příkladu jsem použil 3 barvy a také solid vs. Tečkovaná čára, abych vysvětlil, jak bude aktuální informační architektura aktualizována pomocí UX přepracování aplikace, na které jsme pracovali. (zelená: zůstane tak, jak je, oranžová: bude aktualizována, červená: bude smazána; pevná látka: zůstane na stejném místě, tečkovaná: bude přesunuta někam jinam). Inženýři tak měli jasný pohled z ptačí perspektivy, na kterou část aplikace se bude měnit.

Další tip na vybudování pochopitelné architektury mapě je jasně odlišit různé části navigation, jak udělat níže s oddělené prostory pro každou z nich.

S architekturu, mapa bude být velmi užitečné pro váš produkt spec; to vám umožní zvýraznit, o které části produktu mluvíte, v každém z vašich uživatelských příběhů.

který nástroj byste měli použít k nakreslení mapy architektury? Tam jsou tuny je k dispozici tam, můj oblíbený je Náladový (protože to je vizuálně příjemné a velmi jednoduché, není přeplněná s tolika funkcemi), ale také jsem použil Draw.io v minulosti — což je zajímavé, protože to je integrován s Google Drive, takže pokud budete pracovat s prezentací Google a Google Docs, to dělá to příjemné používat. Je také integrován s JIROU a Confluence.

Chcete-li se dozvědět více o mapách architektury (dělat a nedělat, jaké nástroje použít, některé příklady atd.), Toptal přišel s velkým čtením: komplexní průvodce informační architekturou.

eposy a uživatelské příběhy

rozebrání a vysvětlení všech částí vašeho produktu se může velmi rychle stát docela chaotickým. Psaní specifikace produktu za posledních 5 let, nejlepší způsob, jak jsem zjistil, aby SPECIFIKACE organizované a srozumitelné je rozdělit je podle „uživatelské příběhy“.

Co je uživatelský příběh? Podle agilního modelování je uživatelský příběh “ velmi vysokou definicí požadavku, která obsahuje jen tolik informací ,aby vývojáři mohli vytvořit přiměřený odhad úsilí o jeho implementaci.“

myšlenka uživatelských příběhů je dát uživatelům první místo a vyhnout se použití výhradně obskurní & technický slovník při diskusi o funkcích. Jak říká Atlassian: „po přečtení uživatelského příběhu tým ví, proč staví to, co staví a jakou hodnotu vytváří.“

jsou zaměřeny na budování lepšího produktu, kde je uživatel ve středu debat, na rozdíl od starého dobrého vodopádového vývoje produktu.

Zde je, jak příběh uživatele by měly být formulovány:

Jako < typ uživatele >, Chci < některé cíle >< nějakého důvodu >.

například, tady je, jak bychom mohli formulovat uživatelské příběhy pro následující hlavy architektury mapu jsem nakreslil jeden z mých klientů:

• User Story #1: Jako zaměstnanec na profil, který chcete upravit můj profil, takže můžu aktualizovat svou fotku, jméno a příjmení.
• uživatelský Příběh #2: Jako zaměstnanec v sekci Profil chci přistupovat k nastavení, abych mohl aktualizovat své heslo a aktualizovat předvolby oznámení.
• User Story #3: Jako zaměstnanec na průřez profilu, chci pro přístup k chatu, takže mohu poskytnout zpětnou vazbu na app vývojáři

je To na produktového manažera, aby o tom, jaká úroveň podrobnosti, že chcete pokrýt v uživatelském příběh. Pokud bychom chtěli, mohli bychom také jít o jednu úroveň hlouběji v uživatelském příběhu #2, například:

• uživatelský Příběh #2.a: Jako zaměstnanec v nastavení chci vstoupit do sekce „Upravit heslo“, abych mohl aktualizovat své heslo
• uživatelský Příběh #2.b: Jako zaměstnanec v nastavení, chci aby přístup k oznámení preference, takže můžu aktualizovat na které frekvenci jsem obdržel každý typ oznámení

Ale jak můžete vidět, to je poněkud zřejmé a zbytečné. Osobně jsem se rozhodl pokrýt tyto scénáře v „kritériích přijetí“ (viz další část) dotyčných příběhů.

k uspořádání uživatelských příběhů často používáme „eposy“. Z agilního hlediska jsou „eposy“ velké množství práce, které lze rozdělit na menší uživatelské příběhy. Osobně používám eposy ke seskupování příběhů, které jsou součástí stejného tématu nebo oblasti v produktu. Například, rozhodl jsem se seskupit výše uvedené příběhy jako součást eposu“ profil“. Někteří lidé se rozhodnou formulovat eposy stejným způsobem jako uživatelské příběhy, s jednodušší strukturou (např. „Jako uživatel chci získat přístup ke svému profilu“)

kritéria přijetí

abychom se ujistili, že je do uživatelského příběhu přidán dostatek podrobností, používáme „kritéria přijetí“ (někdy také nazývaná „podmínky spokojenosti“).

Podle LeadingAgile.com, „akceptační kritéria“ jsou „podmínky, že softwarový produkt, musí splňovat být přijat uživatel, odběratel, nebo v případě systémové úrovni funkčnosti, náročný systém.“

v kritériích přijetí byste měli uvést všechny funkční specifika, která nejsou jasně uvedena v příběhu uživatele. Příklad:

uživatelský příběh

jako zaměstnanec v sekci Profil chci upravit svůj profil, abych mohl aktualizovat svou fotografii, jméno a příjmení.

kritéria pro Přijetí

• Vzhledem k tomu, že jsem na upravit profil obrazovky, Když kliknu na upravit jméno ikonu, Pak je třeba přepnout do režimu úprav, zaměřit se na input a. otevřete klávesnici (totéž pro příjmení)
• Vzhledem k tomu, že jsem na upravit profil monitoru, Když jsem klikněte na upravit ikonu fotky Tak to by se mě vybrat si mezi kameru a knihovny
• Vzhledem k tomu, že jsem úpravu mé jméno, Když jsem klikněte na „uložit“, Pak by to mělo přesměrování mě na režimu čtení a já měli vidět oznámení úspěch

atd…

Myslíte, že přijetí kritérií jako kontrolní seznam, který bude muset být vyplněn pro produkt, který má být odeslán. Daný formát / kdy / pak použitý výše je dobrý způsob, jak vám pomoci formulovat kritéria přijetí, ale v některých případech může být náročné použít.

Design, obsah a překlady

s aktuálními návrhy ve specifikacích produktu

zatím jsem nezmínil, který nástroj používám k psaní specifikací. V minulosti jsem přepínal mezi Dokumenty Google, Snímky Google a Notion. Opravdu jsem si užil používání Notion pro všechny skvělé integrace, které nabízí (zejména ty s InVision a Figma). Ale teď jsem úplně přešel na Dokumenty Google: dávám přednost větší volnosti při formátování specifikací produktu. Je také pohodlnější používat produkty Google při práci s externími partnery nebo klienty.

ujistěte Se, že váš produkt je vizuální identita je přesně přivedl k životu tím, že vývojový tým, je důležité dát jim přístup k nejvíce up-to-date obrazovky odeslány do vašeho projektanta(s). Ale jak tam je žádné skutečné integraci mezi Google Docs a design nástroje, jako Figma, InVision nebo Zeplin, použil jsem export obrazovky a kopírování/vložit je do své specifikace.

Tohle by se velmi rychle stát problémem: návrháři opakovat na svých obrazovkách na denní bázi, a dokonce i když vše, co bylo dohodnuto na obrazovce, můžete změnit pár týdnů později, protože jedna konkrétní složka aktualizován v návrhu knihovny. To by způsobilo, že moje specifikace budou většinu času zastaralé.

proto dnes používám pouze název obrazovky. Například, pokud je uživatelský příběh o vydání profilu asi 2 obrazovky, které byly navrženy na Figma, napíšu pouze „Figma screen name: edit-profile-1 a edit-profile-2“.

samozřejmě to není ideální a omezuje vývojáře nebo kohokoli jiného, kdo čte mé SPECIFIKACE, přepínat mezi několika nástroji.

ale to ukazuje, že dnes je něco neefektivního ve způsobu, jakým píšeme specifikace produktu. Používání několika produktů vyvolává otázky integrace a synchronizace. Jak zajistit, aby všechny informace potřebné k vytvoření produktu byly viditelné na jednom místě, aniž by byly zastaralé? (Ve skutečnosti to platí nejen pro návrhy, ale také pro mapy architektury a obsah).

→ Pokud máte také tento problém a našli jste řešení, měl bych zájem získat zpětnou vazbu!

Dává snadný přístup k obsahu a překlady, aby se zabránilo překlepy.

Při návrhu obrazovek s velkým množstvím obsahu, to je hezké dát vývojářům možnost snadno kopírovat/vložit místo toho, aby re-type to sami. V opačném případě byste mohli skončit s (1) mnoha překlepy a (2) naštvanými vývojáři. Existuje několik způsobů, jak jim poskytnout přístup k obsahu:

• tím, že jim přístup ke zdrojovým souborům projekčních prací na Sketch, Figma nebo Zeplin například.
• zkopírováním/vložením obsahu přímo do SPECIFIKACE (může to být trochu chaotický).

Pokud váš produkt existuje v několika jazycích, poskytněte také přístup ke každému překladu. Například můžete pomocí pole zobrazit překlad původního obsahu v každém jazyce. Další úrovní správy překladů je použití lokalizačního nástroje (jako fráze) a přidání „překladových klíčů“ do specifikace produktu. Ale znovu, to znamená Ještě jeden tam a zpět mezi specifikacemi produktu a jiným nástrojem.