По-добър работен процес в мрежата: Confluence, Airtable, Jira и Abstract

Съединение, Джира, Airtable и Abstract

中文 版 連結 (китайска версия) / Първоначално публикувано на vinceshao.com

Работейки като разработчик от близо две години, имам полезен опит от участието си в няколко проекта за уеб разработка на дизайнерски / дигитални агенции.

Един очевиден, но ценен урок, който научих, е, че сътрудничеството между всяка група с една цел, но с различни отговорности и цели не е лесно. Има различни аспекти и нива на затруднения по отношение на сътрудничеството и специфичната част, на която бих искал да се спра на тук, е процесът на работния процес.

Въз основа на моя опит и с помощта на моите приятели дизайнери и разработчици създадох работен процес за разработване на уебсайт, предназначен за малък екип (5–15 души). Системата е съставена от Confluence, Jira, Airtable и Abstract. В тази статия ще споделя защо и как на този работен процес.

Мотивация за изграждане на нов работен процес

За да доставите персонализиран уебсайт без да използвате шаблони, предоставени от строителите на уебсайтове, минималните изисквания за таланти включват дизайнер, разработчик и ръководител на проекти. След като участвах в няколко случая, имах чувството, че има нещо нередно в работния процес, който имахме: важна информация винаги не е била подравнена както вътрешно между различни роли, така и външно спрямо клиента. Тази неефективна комуникация очевидно забави цикъла на развитие и навреди на екипа.

Затова започнах да решавам този проблем.

Големи ресурси на работния процес в Google Търсене: Функции на дизайнерските системи, ресурси за ръководство за стил и дефиниция на работния процес

Google търсех ресурси за създаване и подобряване на работния процес. Въпреки че научих много от всички големи ресурси, открих, че почти никой от тях не е за проекти за уеб разработка в дизайнерска / дигитална агенция. Това беше или система за проектиране, или кодиране на насоки, обхванати в дизайнерски или предни роли, или работен поток, създаден за екип със собствен продукт.

В резултат на това реших да избера частите, необходими за решаване на проблемите ни, и създадох персонализиран работен процес за разработване на уебсайтове.

Проблеми и цели

Следват проблемите, които проверих от съществуващия ни работен процес, и съответните цели за подобряване:

1. Методология на водопада

водопад модел абстрактна демонстрация

Проблем: Въз основа на моя опит проектите на уебсайтове възприемат подход за водопад, тъй като клиентите нямат концепция за минимален жизнеспособен продукт (MVP). Вместо да разделят функционалности от изгледи и модулиране, клиентите са склонни да мислят за сайта по традиционен начин страница по страница, което принуждава както дизайнерите, така и разработчиците да работят страница по страница последователно. Това кара те да губят универсална перспектива в целия проект. Тази ситуация води до много излишни ревизии между страниците.

Цел: Промяната на мисленето на клиентите е едновременно арогантна и нереалистична. Целта е да се намери начин да се отделят изискванията от изгледите възможно най-бързо и да се развие по възможно най-модулиран начин вътрешно въз основа на модел на страница.

2. Универсални дизайнерски жетони и компоненти, управлявани както от дизайнери, така и от разработчици

дизайнерски жетони от Salesforce

Проблем: Това е често срещан проблем, на който много статии споделят страхотни решения, които предлагат най-вече изграждането на система за проектиране, управлявана от генератори за стилове / библиотеки. Въпреки че е чудесно решение, управлението на допълнителен сайт, който едва предостави разрешение за редактиране на дизайнерите, не беше подходящо в нашата ситуация.

Цел: С изключение на създаването на универсални дизайнерски маркери и езици, които дизайнерите, разработчиците и мениджърите могат да разберат, изграждат система, която позволява на всеки да управлява активите по синхронен начин.

3. Точно, актуализирано табло за напредък

имаме нужда от редактируемо и достъпно табло за напредък

Проблем: Въпреки че проблемите за проследяване, канбан и повече модели за управление на проекти са полезни и практични, повечето от тях не успяха да действат като правилно, гъвкаво и приятелско табло за напредък. Този вид табло би спестил на екипа много време, защото би попречил на членовете на екипа активно да докладват или да питат за текущата ситуация на конкретни задачи. Освен това улеснява живота на мениджърите, ако те имат ясни познания за целия проект, без много усилия.

Цел: Изградете система на табло, което предоставя разрешение за редактиране на лица, отговорни за конкретни задачи.

Диаграма на работния процес

Преди да се потопим в подробното въвеждане на стека от инструменти за управление, нека разгледаме абстрактния опростен работен процес, който организирах. Това е почти просто визуализация на нормален работен процес, който имат повечето агенции, но тук трябва да се отбележат две точки.

диаграма на работния процес, която проектирах

1. Оценка на разработчика

Първо, когато изискванията или проблемите, идващи от клиента, са одобрени и документирани от мениджъра, с изключение на изпращане на задачата до дизайнер, те също отиват при програмист за оценка. В този процес разработчикът преглежда спецификацията на задачата, проверявайки дали са включени някакви доста сложни функции или функции. Ако това е положително, разработчикът може да започне работа по него или предварително да уведоми дизайнера за потенциалните проблеми.

2. Единен източник на истината

Също така забележете, че след като доставката на дизайна е одобрена от клиента, и преди да предадете задачата на ръката на програмиста, тя преминава през процес на регистрация / промяна на / изтриване над дизайнерския магазин, проведен от дизайнера. Това е така, защото разработчикът винаги трябва да бъде изложен на един и само един източник на дизайн магазин, който съдържа постоянно поддържани и актуализирани активи, готови за развитие.

Сега можем да се потопим в стека с инструменти за управление, който подготвих и да видим как инструментите ни помагат да решим проблемите си.

Инструментите се подреждат

След експериментиране с различни опции на пазара, стека, който предлагам тук, се състои от Confluence, Jira, Airtable и Abstract. В допълнение към основното въведение и няколко основни примера на приложения, няма да покрия всички подробности за използването на инструментите.

атомен дизайн и ABEM

Забележка: системата предполага, че екипът за разработка приема методологията за атомно проектиране и системата за именуване ABEM.

1. Съединение

Роля: информационен и ресурсен център

Макар че в началото е плашещо, Confluence осигурява мощно работно пространство, което е лесно да се организира и има множество функции, интеграция на приложения и персонализирани шаблони. Това определено не е универсално решение на всички проблеми, но е идеално за документиране на спецификации, изисквания, бележки за среща и други.

Следователно, Съединението в този стек работи като информационен и ресурсен център, което означава, че всяка свързана връзка и подробности за този проект трябва да бъдат документирани правилно тук.

Любимото ми предимство на Confluence е възможността да персонализирате шаблони на документи. Тази функция прави наистина удобството да се стандартизира работният процес.

етап на оценка на разработчика

Пример: Преглед на функционалността на компонента

По-горе споменах процеса на оценка на разработчиците, което всъщност е сложна работа. Това е така, защото този процес включва основна информация за компонента, FSM преглед на разработчика (ако е необходимо), пространство за често задавани въпроси и други. Но гъвкавостта на шаблона и инструментите, които предоставя Съединението, прави това супер лесно. Просто изградете шаблон в конфигурационни настройки и е добре да продължите.

персонализиран шаблон за преглед на компонента в Confluence

2. Джира

Роля: проследяване на проблеми и управление на типа действие

Също така член на семейството на атласите, Джира е супер мощен софтуер за проследяване и планиране на проекти. Любимата ми част за това е създаването на персонализирани работни процеси. Тъй като има много страхотни уроци за това как да използвам силата на Джира, единственото, което искам да отбележа тук, е използването на типа на проблема, както е споменато по-долу.

дизайнерски магазин за актуализация на дизайнер

Пример: Актуализирайте програмиста за промени в магазина за дизайн по тип на изданието

За да се гарантира, че разработчиците изграждат компонентите въз основа на правилни дизайнерски изгледи, те трябва да бъдат уведомявани, когато нещо в магазина за дизайн се актуализира, което включва действия като регистриране, промяна и изтриване. И тъй като компонентът се актуализира, дизайнерът трябва да отвори проблем с назначения отговорен разработчик и избран правилен тип проблем / действие.

Функциите на вида на Jira функция

3. Въздухопроводими

Роля: табло за управление на компоненти и напредък

Airtable, смес от електронни таблици и база данни, е нещото, което кара този стек да работи. Има две невероятни функции, които поддържат работния ми процес: четири типа преход на изглед в една таблица и свързано свързване на съдържание. Ще покажа два примера за използването на тези две функции тук.

разработчикът започва работа по задачата

Пример 1: Управление на компоненти

Как управлявате библиотеката си с компоненти? Избрахме да не използваме генератор на стилови ръководства, тъй като дизайнерите не са достъпни за редактиране. Използването на библиотеката на компоненти на Sketch също не беше подходящо, тъй като има твърде много ограничения, ако се опитаме да го използваме извън обхвата на самия софтуер.

Не бих казал, че Airtable е перфектно решение, но това е най-лесният и гъвкав вариант, за който бих могъл да се сетя. Вижте демонстрационния шаблон на таблицата за управление на компоненти тук:

компонентна таблица

След като на регистрирания бъде представен ново регистриран изглед на дизайн, който е готов да бъде разработен програмно, той оценява изгледа въз основа на системата ABEM и го регистрира в таблицата. В таблицата има 9 колони, включително:

1. Име: именуване на компонента в принципа ABEM

2. Визуализация: екран или експортирано изображение на компонент

3. Свързана страница: връзката към страницата съдържа този компонент

4. Компонент за деца: връзката към компонентите за деца съдържа тази

5. Модификатор: проверява дали има промени в стила (напр .: - активни, - червени)

6. Категория на компонента: класификация с обща категория (напр .: текст, герой, странична лента)

7. Състояние на развитието: състояние на напредъка в развитието (предстоящо, възложено, в ход, завършено, преразглеждане)

8. Възложител: разработчик, отговорен за този компонент

9. Атомно ниво: атомна категория на този компонент (атом, молекула, организъм)

Най-хубавото тук е, че можете да препращате данни както в същите, така и в други таблици. Тази връзка на точки предотвратява нещата да станат по-меки с нарастването на мащаба. Също така забележете, че можете лесно да филтрирате, сортирате и променяте изгледи.

Пример 2: Състояние на развитието на страницата

Тъй като тук предположението е, че неизбежно ще оценяваме напредък по развитие на страница по страница, е необходим шаблон на таблица, предназначен за тази цел. Тази таблица може да бъде табло за прогрес за двата вътрешни екипа и да бъде споделено с клиента едновременно.

таблица със списък на страниците

Тук може да се организира всяка информация за страницата, включително крайния срок, връзката към прототипа на InVision, правоприемника и децата. Обърнете внимание, че е много удобно да се документират и актуализират едновременно дизайн, предния и задния статус на разработка.

4. Резюме

Роля: единичен източник на истина и контрол на версиите на дизайнерските активи

Абстрактът е GitHub за Sketch активи, който спасява дизайнерите от ада на копиране и поставяне на файлове. Извън обхвата на тази статия е да се демонстрират подробности за управление на потока за контрол на версиите. Ключовият момент тук е, че абстрактът е магазин за дизайн, който действа като единствен източник на истина. Дизайнерите трябва да продължават да актуализират основния клон до последната версия на потвърдения дизайн и след това да уведомяват разработчиците. От друга страна, разработчиците трябва да вземат само дизайнерски активи в основния клон.

Шаблон на абстрактния клон

Предстои да се свърши още работа

От моя собствен опит разработването на целия проект след приемането на този нов работен процес беше поне два пъти по-бързо от преди. Това не е перфектно решение, защото все още се изисква много ръчен труд, за да се актуализират и поддържат.

Но мисля, че това може да бъде полезна справка за екипи за разработка на уебсайтове, които търсят по-добър работен процес, и се надяваме повече хора да споделят своите работни процеси в бъдеще!