Кращий робочий процес веб-розробки: 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. Пневматичний

Роль: управління компонентами та інформаційна панель прогресу

Ефір, суміш електронних таблиць та бази даних, - це те, що змушує цей стек працювати. Існує дві дивовижні функції, які підтримують мій робочий процес: чотири типи переходу подання в одній таблиці та пов’язане вміст. Тут я продемонструю два приклади використання цих двох функцій.

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

Як ви керуєте бібліотекою компонентів? Ми вирішили не використовувати генератор стилів, оскільки дизайнери не можуть редагувати його. Використання бібліотеки компонентів Sketch теж не було доречним, оскільки воно має занадто багато обмежень, якщо ми намагалися використовувати його поза рамками самого програмного забезпечення.

Я б не сказав, що Airtable - ідеальне рішення, але це найпростіший і найгнучкіший варіант, який я міг придумати. Погляньте демонстраційний шаблон таблиці управління компонентами тут:

Після того, як нещодавно зареєстрований проектний вигляд, готовий до програмної розробки, буде поданий розробнику, він оцінить представлення на основі системи ABEM та зареєструє його в таблиці. У таблиці є 9 стовпців, включаючи:

1. Назва: найменування компонента за принципом ABEM

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

3. Пов’язана сторінка: посилання на сторінку містить цей компонент

4. Дітячий компонент: посилання на дитячі компоненти містить цей

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

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

7. Статус розробки: статус прогресу розвитку (очікує на розгляд, призначений, виконується, завершений, переглядається)

8. Цесіонарій: розробник, відповідальний за цей компонент

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

Найкраще, що ви можете посилатися на дані як в одній, так і в інших таблицях. Таке з’єднання точок заважає речам ставати неприємнішими у міру зростання масштабу. Також зауважте, що ви можете легко фільтрувати, сортувати та змінювати подання.

Приклад 2: Статус розробки сторінки

Оскільки тут передбачається, що ми неминуче оцінюватимемо хід розробки по сторінках, необхідний шаблон таблиці, розроблений для цієї мети. Ця таблиця може бути інформаційною панеллю прогресу для обох внутрішніх команд і одночасно ділитися з клієнтом.

Будь-яку інформацію про сторінку, включаючи дедлайн, посилання на прототип InVision, правонаступника та дочірній компонент можна організувати тут. Зауважте, що дуже зручно документувати та одночасно оновлювати дизайн, інтерфейс та задній план розробки.

4. Реферат

Роль: єдине джерело правди та управління версіями активів

Анотація - це ресурси GitHub для Sketch, що рятує дизайнерів від пекла копіювання та вставки файлів. Це поза рамками цієї статті, щоб продемонструвати деталі управління потоком управління версіями. Ключовим виводом тут є те, що Анотація - це магазин дизайну, який виступає єдиним джерелом істини . Дизайнери повинні продовжувати оновлювати головну гілку до останньої версії підтвердженого дизайну, а потім повідомляти розробників. З іншого боку, розробники повинні брати лише дизайнерські активи в головній галузі як еталон.

Більше роботи

З мого власного досвіду, розробка всього проекту після прийняття цього нового робочого процесу була щонайменше в два рази швидшою, ніж раніше. Це не ідеальне рішення, оскільки для оновлення та обслуговування все ще потрібно багато ручної праці.

Але я думаю, що це може бути корисним посиланням на команди розробників веб-сайтів, які шукають кращий робочий процес, і, сподіваюся, більше людей зможуть поділитися своїми робочими процесами в майбутньому!

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