Я працюю фронтенд-розробником близько двох років, брав участь у створенні різних проектів. Один із вивчених мною уроків: взаємодія між різними групами розробників, об'єднаних однією метою, але які мають різні завдання та ступінь відповідальності, — справа непроста.
Порадившись з іншими учасниками команди, дизайнерами та розробниками, я створив цикл створення сайтів, призначений для невеликих команд (5–15 осіб). До нього входять такі інструменти, як Confluence, Jira, Airtable і Abstract. У цій статті я поділюсь особливостями організації робочого процесу.
Skillbox рекомендує: Дворічний практичний курс .
Нагадуємо: для всіх читачів "Хабра" - знижка 10 000 рублів при записі на будь-який курс Skillbox за промокодом "Хабр".
Навіщо взагалі все це потрібне?
Мінімальна команда, потрібна для створення сайту з нуля, – це дизайнер, програміст та менеджер проектів. У моєму випадку команду було сформовано. Але після релізу кількох сайтів у мене склалося відчуття, що з нею щось не так. Іноді ми просто не до кінця розуміли свої обов'язки, залишало бажати кращого спілкування з клієнтом. Все це гальмувало процес і заважало всім.
Я почав працювати над вирішенням проблеми.
Пошук у Google дає непогані результати з нашої проблеми
Для того, щоб виконана робота була наочнішою, я створив діаграму робочого процесу, яка дає розуміння того, як виконується робота у нас.
При натисканні зображення відкриється в повній роздільній здатності
Цілі і завдання
Однією з перших методик, які я вирішив перевірити, є «каскадна модель» (Waterfall). Її я застосував, щоб виділити проблеми та зрозуміти, як їх вирішити.
Проблема: Найчастіше клієнт не оцінює процес створення сайту модульно, як це роблять розробники. Він сприймає його як звичайний сайт, тобто мислить категоріями окремих сторінок. На його думку, дизайнери та програмісти створюють окремі сторінки, одну за одною. У результаті замовник просто не розуміє, що за чим слідує в ході реального процесу.
Завдання: Переконувати клієнта у зворотному не варто, оптимальний варіант – розробити всередині компанії модульний процес створення сайту на основі посторінкової моделі.
Універсальні дизайн-токени та компоненти керуються як розробниками, так і дизайнерами.
Проблема: це звичайна ситуація, якій присвячено велику кількість стратегій. Є чимало цікавих рішень, у більшості випадків пропонується створити дизайн-систему, яка керується гідом стилів/генераторами бібліотек. Але в нашій ситуації додавання в процес розробки ще одного компонента, який би дозволив керувати рівнями доступу для дизайнерів, було просто неможливим.
Завдання: побудова універсальної системи, в якій дизайнери, розробники та менеджери можуть працювати синхронно, не заважаючи один одному.
Точне відстеження процесу розробки
Проблема: незважаючи на те, що існує безліч корисних інструментів, що дозволяють відстежувати проблеми та оцінювати загальний прогрес, більшість з них не можна назвати гнучкими або оптимальними. Інструмент може бути корисним, зберігаючи команді час, який у звичайній ситуації витрачається на запитання та уточнення щодо конкретних завдань. Він також полегшує життя менеджерам, даючи їм точніше розуміння всього проекту.
Завдання: створити дашборд для відстеження процесу виконання завдань різними членами команди.
Набір інструментів
Після експериментування з різними інструментами я зупинився на наступному наборі: Confluence, Jira, Airtable та Abstract. Нижче я розкрию переваги кожного.
Злиття
Роль інструменту: інформаційний та ресурсний центр.
Робочий простір Confluence відносно просто організувати, в ньому є багато функцій, інтеграція з різними додатками та окремі шаблони, що налаштовуються. Його не можна назвати універсальним вирішенням усіх проблем, але він ідеально підходить як інформаційний та ресурсний центр. Це означає, що будь-яке посилання або технічна деталь, що стосуються проекту, мають бути занесені до бази.
Інструмент дозволяє правильно задокументувати кожен компонент та будь-які інші подробиці про проект.
Основна перевага Confluence – налаштування шаблонів документів. Крім того, за його допомогою можна реалізувати єдине сховище специфікацій та різної документації проекту, розділивши рівні доступу учасників. Тепер можна не переживати, що у вас на руках стара версія специфікації, як трапляється, якщо надсилати документи електронною поштою.
Більше інформації про інструмент .
Jira
Роль інструменту: моніторинг проблем та управління завданнями.
Jira – дуже потужний інструмент планування та управління проектами. Основна частина функціоналу — створення робочих процесів, що кастомізуються. Для того, щоб ефективно керувати завданнями (що нам і потрібно), варто звернути особливу увагу на правильне використання типу запиту та завдання (issue type).
Так, щоб бути точно впевненим у тому, що розробники створюють компоненти на основі коректного дизайну, їх потрібно повідомляти щоразу, коли в дизайні щось змінюється. Як тільки компонент оновився, дизайнеру потрібно відкрити завдання, призначити відповідального розробника, надавши йому коректний тип завдання.
З Jira можна бути впевненим, що абсолютно всі учасники процесу (нагадаю, їх у нашому випадку 5–15) одержують коректні завдання, які не губляться та знаходять свого виконавця.
Більш детальна інформація про Jira .
Аеростат
Роль інструменту: управління компонентами та дошка прогресу.
Airtable є сумішшю електронних таблиць і баз даних. Все це дає можливість налаштувати роботу всіх інструментів, про які йшлося вище.
Приклад 1. Управління компонентами
Що стосується генератора посібника за стилем, то користуватися ним не завжди зручно — проблема в тому, що дизайнери не можуть його редагувати. Крім того, не надто правильним буде рішення використовувати бібліотеку компонентів Sketch, так як у неї багато обмежень. Швидше за все, використовувати поза програмою цю бібліотеку просто не вдасться.
Airtable теж не можна назвати ідеальним, але він кращий, ніж багато інших схожих рішень. Ось демонстраційний варіант шаблону таблиці управління компонентами:
Коли розробник бере на роботу дизайн-компонент, він оцінює отримане з урахуванням ABEM, реєструючи компонент у таблиці. Загалом у ній 9 стовпців:
- Назва - найменування компонента згідно з принципом ABEM.
- Попередній перегляд – тут розміщується або скріншот, або зображення компонента, завантажене з іншого джерела.
- Пов'язана сторінка — посилання на сторінку компонента.
- Дочірній компонент – посилання на дочірні компоненти.
- Модифікатор – перевірка наявності варіантів стилю та визначення їх (наприклад, активний, червоний тощо).
- Категорія компонента – це загальна категорія (текст, промозображення, бічна панель).
- Статус розробки — власне прогрес розробки та її визначення (завершено, у процесі тощо).
- Відповідальний – розробник, який відповідає за цей компонент.
- Атомарний рівень - атомарна категорія цього компонента (згідно з концепцією атомарного дизайну).
- Посилатися на дані можна в одній і тій чи різних таблицях. З'єднання точок не дасть заплутатися у разі масштабування. Крім того, дані можна без проблем фільтрувати, сортувати та змінювати їхній вигляд.
Приклад 2: прогрес розробки сторінки
Для оцінки прогресу розробки сторінки потрібний шаблон, створений саме з цією метою. Таблиця може бути як потреб самої команди, так клієнта.
Тут можна побачити будь-яку інформацію про сторінку. Це дедлайн, посилання на макет InVision, адресат, дочірній компонент. Відразу стає помітно, що операції виконувати дуже зручно, що стосується як документування та оновлення дизайну, так і статусу розробки фронтенду та бекенду. І ці операції виконуються одночасно.
абстрактний
Роль інструменту: єдине джерело контролю версій дизайну ассетів.
Abstract можна назвати GitHub для ассетів у Sketch, він рятує дизайнерів від необхідності копіювання та вставки файлів. Основна перевага інструменту в тому, що він є сховищем дизайну, що діє як «єдине джерело істини». Дизайнери повинні оновлювати головну гілку до останнього варіанту затвердженого макета. Після цього їм доводиться повідомляти розробників. Ті, у свою чергу, мають працювати лише з дизайнерськими ассетами основної гілки.
Як висновок
Після того як ми впровадили новий процес розробки і всі інструменти, про які йдеться вище, швидкість нашої роботи збільшилася мінімум вдвічі. Це не ідеальне рішення, але дуже гарне. Щоправда, для того, щоб воно працювало, потрібно докласти чимало зусиль — потрібна «ручна робота» по оновленню та підтримці всього цього у працездатному стані.
Skillbox рекомендує:
- Практичний курс .
- Онлайн-курс .
- Практичний річний курс .
Джерело: habr.com