saját aranyszabályok, hogy megbizonyosodjon arról, hogy a terméket megfelelően szállítják-e.
a termékmenedzsert gyakran úgy írják le, mint “híd az üzlet, a design és a tech között”. A híd “a design és a tech között” rész különösen kritikus, amikor minőségi terméket szállítunk: hibamentes, pixel-tökéletes, és figyelembe veszi az összes lehetséges forgatókönyvet és edge esetet. Annak érdekében, hogy a bridge jól működjön, a tervezőcsapat többféle módon kezeli:
- a tervező átfogó prototípust szállít, amely megmutatja a termék összes áramlását. Sajnos ez gyakran sok időt vesz igénybe, és még mindig hiányzik néhány edge eset.
- a tervező csak olyan prototípust szállít, amely megmutatja a funkció főbb folyamatait, és továbbra is elérhető marad a fejlesztői csapat kérdéseire. Sajnos ezek oda-vissza nagyon hatástalanok (különösen távoli beállításokban), és sok időt pazarolnak mind a tervező, mind a fejlesztő csapattól.
- a tervező az átfogó prototípus mellett egy megfelelő specifikációs dokumentumot is ír, amely felsorolja az összes lehetséges forgatókönyvet és edge esetet. A probléma az, hogy ez gyakran időpocsékolás, mert (1) a tervezők értékes idejét jobban fogják eltölteni más funkciók tényleges megtervezésével, nem pedig egy speciális dokumentum megírásával, és (2) nem mindig ugyanaz a 360 ezer dolláros nézetük van a termékről, mint a termékmenedzsereknek, ami miatt figyelmen kívül hagynak néhány forgatókönyvet és edge esetet.
ezért az érett termékcsoportok általában a termékspecifikációik írását bízzák a termékmenedzserekre.
de hogyan kell írni a termék specifikációit? Az elmúlt 5 évben termékspecifikációkat írtam, és találtam egy olyan formátumot,amelyet a szoftvercsapatok nagyra értékelnek. Ebben a bejegyzésben többet osztok meg a módszertanomról és azokról az eszközökről, amelyeket a termék specifikációinak megírásához használok. Leírok néhány korlátot is, amelyekkel szembesülök az általam használt eszközökkel, és néhány fejlesztési ötletet gondolok.
itt van az 5 fő téma, amellyel foglalkozom egy Termék specifikációjában:
- kontextus és célkitűzések
- architektúra térkép
- eposzok és felhasználói történetek
- Elfogadási Kritériumok
- tervezés, tartalom és fordítások
kontextus és célkitűzések
még ha a termék specifikációja elsősorban a szoftvercsapatoknak szól is, még mindig szeretik tudni, hogy miért dolgoznak azon, amin dolgoznak. Megértettem, hogy a szoftvermérnökök motivációjának egyik fő mozgatórugója az impact. Legtöbbjük arról álmodozik, hogy olyan funkciókkal dolgozzon, amelyeket több millió felhasználó használ. Izgatottak, amikor meghallják, hogy az általuk bevezetett új UX például 15% – kal növelte a megtartást. Tehát fontos, hogy kontextust adjunk arról a funkcióról, amelyet megvalósítani fognak:
- miről beszélünk? A termék melyik része? Nyugodtan adja hozzá a szolgáltatás bármely előzményét, amely hasznos a jelenlegi helyzet megértéséhez.
- mi a jelenlegi probléma? Megjegyzés: több probléma is megoldható.
- van-e minőségi visszajelzés / verbatims a felhasználóktól, amelyeket idézni kell?
- vannak-e megjelenítendő adatok (pl. grafikonok)? Ebben a részben nyugodtan szerepeljen olyan diagramok vagy grafikonok, amelyek érthetőbbé teszik az adatokat.
- mi a választott megoldás? (írja le egyszerűen, néhány mondatban)
- mérlegeltek – e más megoldást? Ha igen, miért tették félre?
- van más megoldás már megvalósítva? Hogy teljesített?
- mik a célok ? Van olyan KPI, amit megpróbálunk becsapni? Ez különösen segít a szoftvercsapatnak megérteni, hogy új nyomkövetőket / címkéket / eseményeket kell-e végrehajtaniuk az adatok megfelelő gyűjtéséhez. Láttam olyan csapatokat, akik úgy érezték, hogy a projekt annyira hajtja őket, hogy kezdeményezték az irányítópultok beállítását, hogy valós időben kövessék a mutatókat, anélkül, hogy én vagy bárki más kérné.
architektúra térkép
mielőtt túlságosan belemennénk a funkció részleteibe, fontos, hogy magas szintű áttekintést adjunk arról, hogy mi változik és mi marad ugyanaz a termékben. És még akkor is, ha egy teljesen új terméken dolgozik, az építészeti Térkép továbbra is rendkívül releváns lesz a termék felépítésének megértéséhez.
az”architektúra térkép” az a mód, ahogyan a termék jellemzőinek (áramlások, képernyők és tartalom) magas szintű diagramját ábrázolom, valamint azt, hogy ezek hogyan kapcsolódnak egymáshoz. Vannak, akik “információs architektúrának”, “áramlási térképnek”, “UX leképezésnek” stb.
az építészeti Térkép rajzolásának hivatalos módszertana nincs. Egy mobilalkalmazásban általában megpróbálom megkülönböztetni az áramlásokat, a képernyőket és a “képernyő részeit” (vagy az “Oldalon belüli tartalmat”), mindegyikhez eltérő formát használva, amint azt a fenti jelmagyarázat részletezi.
hasznos lehet A színkódon is játszani. A fenti példában 3 színt, valamint szilárd vagy szaggatott vonalat használtam annak elmagyarázására, hogy a jelenlegi információs architektúra hogyan frissül az alkalmazás UX átalakításával, amelyen dolgoztunk. (zöld: marad, ahogy van, narancssárga: frissül, piros: törlődik; szilárd: ugyanazon a helyen marad, pontozott: máshová kerül). Így a mérnökök egyértelmű madártávlatból látták, hogy az alkalmazás melyik része változhat.
egy másik tipp az érthető építészeti Térkép elkészítéséhez az, hogy világosan megkülönböztesse a navigáció különböző részeit, az alábbiakban külön területekkel mindegyikhez.
miután egy architektúra térkép rendkívül hasznos lesz a termék Spec; ez lehetővé teszi, hogy kiemelje, hogy a termék melyik részéről beszél az egyes felhasználói történetekben.
melyik eszközt használja az építészeti Térkép rajzolásához? Rengeteg közülük elérhető odakinn, a kedvencem szeszélyes (mert vizuálisan kellemes és nagyon egyszerű, nem zsúfolt annyi funkcióval), de én is használtam Draw.io a múltban-ami azért érdekes, mert integrálva van a Google Drive-ba, így ha a Google diákkal és a Google dokumentumokkal dolgozik, akkor jó használni. Ez is integrálva van a Jira és a Confluence.
Ha többet szeretne megtudni az építészeti térképekről (do-k és nem, mely eszközöket kell használni, néhány példa stb.), Toptal jött egy nagy olvasmány: Az átfogó útmutató az információs architektúra.
eposzok és felhasználói történetek
a termék minden részének lebontása és magyarázata nagyon gyorsan meglehetősen kaotikussá válhat. Írásban termék specifikációk az elmúlt 5 évben, a legjobb módja azt találtam, hogy tartsa a szemüveg szervezett és érthető, hogy lebontják szerint “felhasználói történetek”.
mi az a felhasználói történet? Az agilis modellezés szerint a felhasználói történet ” egy követelmény nagyon magas szintű meghatározása, amely éppen annyi információt tartalmaz, hogy a fejlesztők ésszerű becslést készíthessenek a megvalósítására irányuló erőfeszítésekről.”
a felhasználói történetek ötlete az, hogy a felhasználókat helyezzük előtérbe, és kerüljük a kizárólag homályos & technikai szókincs használatát a funkciók megvitatásakor. Ahogy Atlassian fogalmaz: “miután elolvasta a felhasználói történetet, a csapat tudja, miért építi azt, amit épít, és milyen értéket teremt.”
céljuk egy jobb termék felépítése, ahol a felhasználó áll a viták középpontjában, ellentétben a jó öreg vízesés termékfejlesztéssel.
így kell megfogalmazni egy felhasználói történetet:
mint < a felhasználó típusa >, Szeretnék < néhány cél > tehát < valamilyen okból >.
például így fogalmazhatnánk meg felhasználói történeteket az egyik ügyfelem számára rajzolt architektúra térkép következő részrészéhez:
- felhasználói történet #1: A profil részben alkalmazottként szerkeszteni akarom a profilomat, hogy frissíthessem a fényképemet, a keresztnevemet és a vezetéknevemet.
- felhasználói történet #2: A profil részben alkalmazottként szeretnék hozzáférni a beállításokhoz, hogy frissíthessem a jelszavamat és frissíthessem az értesítési beállításokat.
- felhasználói történet #3: a profilszakasz alkalmazottjaként hozzáférni akarok a csevegéshez, így visszajelzést adhatok az alkalmazás fejlesztőinek
a termékmenedzser feladata eldönteni, hogy milyen szintű részleteket akarnak lefedni a felhasználói történetben. Ha akarnánk, egy szinttel mélyebbre is mehetnénk a 2. Felhasználói történetben, például:
- 2.Felhasználói történet.a: A Beállítások alkalmazottjaként szeretnék hozzáférni a” Jelszó szerkesztése ” szakaszhoz, hogy frissíthessem a jelszavamat
- felhasználói történet #2.b: a Beállítások alkalmazottjaként szeretnék hozzáférni az értesítési beállításokhoz, hogy frissíthessem, milyen gyakorisággal kapok minden típusú értesítést
de amint látod, ez kissé nyilvánvaló és felesleges. Én személy szerint úgy döntöttem, hogy ezeket a forgatókönyveket a kérdéses történetek “elfogadási kritériumaiban” (lásd a következő részt) ismertetem.
a felhasználói történetek rendezéséhez gyakran “eposzokat”használunk. Agilis értelemben az “eposzok” nagy mennyiségű munka, amelyet kisebb felhasználói történetekre lehet bontani. Én személy szerint eposzokat használok olyan történetek csoportosítására, amelyek a termék ugyanazon témájának vagy területének részét képezik. Például, úgy döntöttem, hogy a fenti történeteket a “Profil” eposz részeként csoportosítom. Vannak, akik úgy döntenek, hogy az epikusokat ugyanúgy fogalmazzák meg, mint a felhasználói történeteket, egyszerűbb felépítéssel (pl. “Felhasználóként szeretnék hozzáférni a profilomhoz”)
Elfogadási Kritériumok
annak érdekében, hogy elegendő részlet legyen hozzáadva a felhasználói történethez, az “elfogadási kritériumokat” használjuk (néha “elégedettségi feltételeknek”is nevezik).
szerint LeadingAgile.com, az ” Elfogadási Kritériumok “azok a feltételek, amelyeknek egy szoftverterméknek meg kell felelnie ahhoz, hogy a felhasználó, az ügyfél, vagy rendszerszintű funkcionalitás esetén a fogyasztó rendszer elfogadja őket.”
az elfogadási feltételekben fel kell sorolnia azokat a funkcionális sajátosságokat, amelyeket a felhasználói történet nem határoz meg egyértelműen. Példa:
felhasználói történet
a profil rész alkalmazottjaként szerkeszteni szeretném a profilomat, hogy frissíthessem a fényképemet, a keresztnevemet és a vezetéknevemet.
Elfogadási Kritériumok
- tekintettel arra, hogy a Profil szerkesztése képernyőn vagyok, amikor rákattintok a keresztnév szerkesztése ikonra, akkor át kell váltania szerkesztési módra, a bemenetre kell összpontosítania, és nyissa meg a billentyűzetet (ugyanaz a vezetéknév esetében)
- tekintettel arra, hogy a Profil szerkesztése képernyőn vagyok, amikor rákattintok a fotó szerkesztése ikonra, akkor meg kell kérnie, hogy válasszak a kamera és a könyvtár között
- tekintettel arra, hogy a keresztnevemet szerkesztem, amikor a “Mentés” gombra kattintok, akkor át kell irányítania az olvasási módba, és meg kell nyitnia a látnom kell egy sikeres értesítést
stb…
gondolj az elfogadási kritériumokra ellenőrzőlista, amelyet ki kell tölteni a szállítandó termékhez. A fent használt megadott/mikor/akkor formátum jó módja annak, hogy segítsen megfogalmazni az elfogadási kritériumokat, de bizonyos esetekben kihívást jelenthet a használata.
tervezés, tartalom és fordítások
a termék specifikációiban naprakész tervek vannak
eddig nem említettem, hogy melyik eszközt használom a specifikációk írására. A múltban váltottam a Google Dokumentumok, a Google Diák és a fogalom között. Nagyon élveztem a fogalom használatát az általa kínált hűvös integrációkhoz (különösen az InVision és a Figma). De most teljesen átálltam a Google dokumentumokra: inkább nagyobb szabadságot élvezek a termékspecifikációim formázása során. Kényelmesebb a Google-termékek használata, ha külső partnerekkel vagy ügyfelekkel dolgozik.
annak érdekében, hogy a fejlesztői csapat pontosan életre keltse a termék vizuális identitását, fontos, hogy hozzáférést biztosítson számukra a tervező(k) által szállított legfrissebb képernyőkhöz. De mivel nincs valódi integráció a Google Dokumentumok és az olyan tervezési eszközök között, mint a Figma, az InVision vagy a Zeplin, exportáltam a képernyőket, és másoltam/beillesztettem őket a termékspecifikációimba.
Ez nagyon gyorsan problémává válna: a tervezők napi szinten iterálnak a képernyőn, és még akkor is, ha mindent megegyeztek egy képernyőn, néhány héttel később megváltozhat, mert egy adott komponens frissül a tervezési könyvtárban. Ez azt eredményezné, hogy a specifikációim legtöbbször elavultak.
ezért ma csak a képernyők nevét használom. Például, ha a profile edition felhasználói története 2 képernyőről szól, amelyeket a Figma-ra terveztek, akkor csak a “Figma screen name: edit-profile-1 and edit-profile-2″szöveget írom.
természetesen ez nem ideális, és korlátozza a fejlesztőket vagy bárki mást, aki elolvassa a specifikációimat, hogy váltsanak több eszköz között.
de ez azt mutatja, hogy ma valami nem hatékony a termékspecifikációk írásában. Több termék használata felveti az integráció és a szinkronizálás kérdéseit. Hogyan biztosítható, hogy a termék felépítéséhez szükséges összes információ egyetlen helyen látható legyen, anélkül, hogy elavult lenne? (Valójában ez nem csak a tervekre vonatkozik, hanem az építészeti térképekre és a tartalomra is).
ha Ön is tapasztalja ezt a problémát, és megtalálta a megoldást, érdekelne, hogy visszajelzést kapjon!
könnyű hozzáférést biztosít a tartalomhoz és a fordításokhoz az elírások elkerülése érdekében
amikor nagy mennyiségű tartalommal rendelkező képernyőket tervez, jó, ha a fejlesztőknek lehetőséget adnak arra, hogy egyszerűen másolják/illesszék be, ahelyett, hogy maguknak kellene újra beírniuk. Ellenkező esetben előfordulhat, hogy a végén (1) sok elírás és (2) dühös Fejlesztők. Számos módon adhat nekik hozzáférést a tartalomhoz:
- azáltal, hogy hozzáférést biztosít számukra a Sketch, Figma vagy Zeplin tervezési munkájának forrásfájljaihoz.
- A tartalom másolásával/beillesztésével közvetlenül a specifikációba (ez kissé rendetlenné teheti).
Ha a termék több nyelven is létezik, adjon hozzáférést Minden fordításhoz. Például egy tömb segítségével megjelenítheti az eredeti tartalom fordítását az egyes nyelveken. A fordításkezelés következő szintje egy lokalizációs eszköz (például kifejezés) használata, és csak a “fordítási kulcsok” hozzáadása a termék specifikációjához. De ismét ez azt jelenti, hogy még egy oda-vissza a termék specifikációi és egy másik eszköz között.