Co je DesignOps? Proč to váš tým potřebuje? A jak může DesignOps pomáhat tvému vývojářskému týmu? Tento článek odpovídá na tyto otázky a také vám poskytuje užitečné tipy, jak začít s implementací tohoto nového konceptu ve vašem vývojovém týmu.
V moderním světě je rychlost vývojového týmu, která často definuje životaschopnost produktu. Současně existuje jeden klíčový prvek, který je nejdůležitější a nejproblematičtější: design.
Design se často stává překážkou a významně ovlivňuje celý vývojový proces, bez ohledu na velikost vašeho týmu. Někdy nadlidské úsilí od vedoucího návrhu pomáhá řídit návrhový proces, ale jakmile se zvyšuje pracovní zátěž, musíte svůj tým změnit.
Jak často jste viděli:
Pokud některé nebo všechny tyto zvuky jsou známé, pak je nejvyšší čas implementovat DesOps (Design Operations).
Termín DesOps nebo DesignOps je replikou tohoto výrazu DevOps což je softwarová inženýrská praxe, která se zaměřuje na sjednocení vývojových procesů s cílem zvýšit efektivitu. Podobně jako specialisté společnosti DevOps jsou specialisté DesOps zkušení návrháři s manažerskými dovednostmi, kteří chápou proces návrhu v rámci širšího kontextu vývoje produktu.
Zatímco my všichni nemůžeme mít termín "DesOps" v našem pracovním oboru, mnoho starších návrhářů již odpovídá za stejnou roli. Od vytváření konstrukčních procesů až po vývoj systémů návrhu, vytváření strategií a řízení projektových týmů je DesOps stále důležitější.
Co je opravdu důležité, je, že tento přístup je škálovatelný a relevantní i v týmech s jediným návrhářem. Takže, jak začnete provádět DesOps?
Návrháři musí vědět, kdy je jejich práce kompletní a připravena k předání vývojovému týmu. Návrháři například potřebují jasně pochopit, které státy musí každá obrazovka potřebovat, a jaké prostředky bude potřebovat pro vývojový tým k vybudování těchto aktiv.
Může se cítit jako oblast, kterou by měli návrháři pochopit. Ale je to vlastně jeden z nejběžnějších bodů tření v projektu a neměl by být ignorován. Pokud vyjádříte, co je požadováno jasně, pak budete omezovat konflikty a zajistíte, aby každý pochopil své povinnosti.
Přínosy z toho jsou: umožňuje udržovat stabilní tempo vývoje; snižuje celkový čas vývoje; snižuje počet nezbytných diskusí mezi návrháři, vývojáři a potenciálními zákazníky.
Konečně jsme uvažovali o tom, co by měl návrhář předat vývojářům. Tento bod je o tom, jakou formu by měl návrhář použít k předávání designových modelů, leštěného designu, prototypů, módních desek - co musí návrhář poskytnout, aby mohli efektivně předvést své záměry ve formátu, který mohou vývojáři porozumět.
Existuje mnoho možností, jako například Zeplin nebo InVision ale jedna z nejčastějších stížností od vývojářů je, že tyto formáty neposkytují vše, co potřebují (například vyvážené prostředky). Nicméně, to je obvykle proto, že návrháři řádně nevyváželi své návrhy. Tím, že se návrhářům vyjasní, od čeho se očekává, že budou vyrábět, mohou snadno převést správná aktiva.
Měli byste vytvořit interní dokument, který bude obsahovat konkrétní technické požadavky na majetek, návrhové nástroje, spolupráci s vývojáři a dalšími členy týmu; konečně by tento dokument měl jasně definovat, kdy a jak mají být projekty dodány.
Soubor návrhových a inženýrských řešení, jakož i pokyny pro jejich realizaci, zajistí řadu výhod: celistvost produktu; jednodušší a rychlejší na palubě nových členů týmu; efektivnější práci projektantů i vývojářů (protože mohou komunikovat v jednom jazyce definovaném systémem návrhu).
Mezi přínosy patří: zlepšení celkové kvality práce; snižuje "seg", když jste velikost týmu; zvyšuje rychlost návrhu i vývoje.
My všichni milujeme nové nástroje, ale účinný tým pracuje s jednotným souborem nástrojů a zajišťuje, že tato jednota je vaší odpovědností.
Všechny nástroje by měly být aktuální, ale pokud je aktualizace z jakéhokoli důvodu přeskočena, měli byste je přeskočit.
Mezi přínosy patří: větší angažovanost týmů; zvýšená konstrukční a vývojová rychlost; zlepšená týmová spolupráce.
Vývojáři jsou z hlediska tohoto úkolu šťastnější, protože ovládání verzí kódu je vyspělé odvětví s mnoha možnostmi. Je těžké vytvořit podobný přístup pro návrháře, protože procesy jsou tak rozmanité, ale v loňském roce jsou to nástroje jako Abstraktní , Kaktus , a Rostlina jsou stále oblíbenější. Dokonce můžete mít několik návrhářů pracujících na jednom rozložení s něčím podobným Obr .
Přínosy z toho jsou: lepší komunikace; zjednodušené škálování týmů; rychlá tvorba návrhových procesů, jelikož mnoho návrhářů může pracovat na jednom projektu produktivně.
Chcete-li popsat všechny funkce týkající se návrhů, zkuste použít namísto technických specifikací "vizuální dokumentaci". Ve většině případů stačí, aby vývojář měl interaktivní prototyp, aby pochopil základní logiku a našel odpovědi na většinu otázek.
Přínosy z toho zahrnují: zkrácení doby psaní technických specifikací; snižuje rozsah práce pro technické spisovatele; vývojáři tráví méně času čtením dokumentace a více času psaním kódu; návrháři jsou produktivnější; zrychlené tempo vývoje.
V mnoha populárních metodách vývoje softwaru není naprosto vhodné místo pro návrh; bez ohledu na vývojový proces, který používáte, najít prostor pro návrháře.
Výhodou tohoto je: sjednocený tým s lepší komunikací; zvýšená rychlost vývoje; snížená přepracování a výpadek vývojářů.
Měli byste neustále demonstrovat růst kvantitativních a kvalitativních ukazatelů díky implementovaným změnám, a to jak pro členy týmu, tak pro špičkové manažery. Bez toho by se tým neochotně změnil, zatímco vrcholový manažer nebude schopen pochopit, kde a proč jsou vynaloženy další zdroje. Konstantní shromažďování a prezentace pozitivních výsledků po implementaci změn vám pomůže získat důvěryhodnost a potřebnou autoritu pro další změny v týmovém workflow.
Mezi přínosy patří: zvýšená motivace a silnější tým; usnadnění nových pravidel a postupů; podporu budoucích inovací.
Termín "DesOps" je zcela nový a právě začíná získávat svůj význam; first DesOps conference první DesOps konference se konala pouze v listopadu v New Yorku.
Pro tuto chvíli bych jednoduše nazývala tuto kulturu, která se zaměřuje na vývoj a podporu pevných procesů návrhu. Ale mám pocit, že v blízké budoucnosti to budeme mít jako samostatnou designovou roli v každém výrobním týmu. Domnívám se však, že můžeme již bezpečně mluvit o významu zavádění těchto postupů s cílem zlepšit efektivitu pracovního postupu návrhu a vývoji produktů obecně.