По-добър работен процес за уеб разработка: Confluence, Airtable и др

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Диаграма на работния поток

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

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

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

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

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

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

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

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

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

1. Сливане

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

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

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

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

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

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

2. Джира

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

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

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

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

3. Проветрив

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

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

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

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

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

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

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

2. Преглед: екранна снимка или експортирано изображение на компонент

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

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

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

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

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

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

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

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

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

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

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

4. Резюме

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

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

Предстои още работа

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

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

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