Вскрытие магии или дизайн масштабируемых проектов (Часть2)

Реорганизация команды

На самом деле невероятно трудно реорганизовать устоявшуюся команду, озадачить всех новыми обязанностями и сказать, что теперь будет по-другому. Здорово, когда все сами осознают слабые места процесса и готовы меняться. Для того чтоб все закрутилось, лучше всего использовать промежуточные звенья в виде гибридных спецов.

Этапы

Работая на “конвейере”, я был в недоумении, насколько раздроблены дизайнерские мощности у “звездных” проектных команд, но окунувшись в обдуманный дизайн и проанализировав основные этапы, я пришел к аналогичному разделению. Их оказалось 6, но это не имеет прямое отношение к количеству участников на проекте. Скажу, что для хорошего темпа, качества и прогресса нужно как минимум 4 (дальше в зависимости от проекта, ожидаемой скорости и слаженности спецов). У нас интерфейсные мощности на каждом проекте существенно меньше, но часть участников очень гибридны и способны видеть результат в целом. Но не стоит рассчитывать на удачу и все-таки избавить команду от перегорания. Скажу по себе, у нас все движется в большей степени благодаря энтузиазму.

Вот основные этапы, которым мы следуем:

AI/UX

Складывается понимание для чего сервис, функционал, порядок действий, примерные экраны. Этот нужно всего лишь для того чтоб понимать картинку на первом этапе. Но не при каком раскладе не нужно привязываться к визуальному отображению, так как не учтены технические детали, конструкции и динамика.

Elements/Images/Illustrations

Подготовка кирпичиков для строительства.

Prototyping

На этап прототипирования уже идут реальные конструкции, предусматривается структура, тех. характеристики и особенности устройств экранов.

UI/Interaction

Непосредственное аккумулирование предыдущих этапов в понятный для восприятия вид, проработка динамики и поведения.

Components/Interaction

Формирование интерфейсной архитектуры, библиотеки компонентов, написание анимации на CSS.

Development

Сборка. Подготовка интерфейса для дальнейшей работы и непосредственно работа фреймворком.

Навыки

Как я уже говорил, гибридность команды это базовое правило для становления процесса, поэтому без хорошего фундамента дело не пойдет.

База, которая необходима для команды:

• HTML/CSS/JS (базовый минимум)
• Основные принципы БЭМ методологии (без тех деталей)
• Sketch
• Совсем скоро будет включен инструмент для динамики

Так же нужно четко отладить обмен знаниями, опытом внутри, чтоб приравнять общие силы и просто начать распределять роли.

Преимущества

Дело не в преимуществе, а в том, что прокачка себя и процесса просто необходима, чтоб поддерживать работоспособность хотя бы на прежнем уровне (реагируя на новые требования)

Трудности

• Относительно высокий порог входа
• Адаптация нового участника команды (3–4 месяца)

Хочу предупредить, что это показатели из личного опыта, для участников начального-среднего уровня без большого багажа за спиной.

Ликвидируем любые намеки на клиентский подход

Необходимо разделить проекты на сервисы и контентные (поддерживаемые / не поддерживаемы интерфейсной командой). Это поможет лучше спланировать ресурсы.

Каждый поддерживаемый проект это отдельная “компания” со своей командой, оптимизированной под эти нужды, а не несколько участников, выдернутые из общей кучи, для цикла работ.

Общая методология, как фундаментальная база для того, чтоб при работе на новом проекте, участнику нужно было только вникнуть в предметную область и особенности, а не вникать в то, как устроена вся работа.

Роли

Понятие “статуса” спецов не актуально. И я совершенно не верю в вертикальную систему — корпоративщину. Но мне часто хватает участника команды внутри проекта, типа “консультанта”. У которого есть хорошая база и опыт, компетентность в проекте. Который способен посмотреть на процесс в общем. Четко спланировать задачи и действия других участников для повышения эффективности. (Мне, да и думаю всем, этого очень не хватает. Приходится отрываться от задач, заниматься анализом/исследованием проблем, багов + поиском инструментов/решений. Что, мягко говоря, не продуктивно).

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

Платформы

Адаптив хорош для небольших страниц. Пытаться сделать это через медиа запросы на проектах, которые разрастаются — полная глупость. Учитывая скорость изменений, это все равно, что расставить капканы для самих себя. Нам нужна гибкость и поэтому мы делаем несколько отдельных версий, которые подгружаются в зависимости от типа устройств. Может и на первый взгляд звучит пугающе, но это на самом деле верное решение.

Убеждение

Попросить месяцы времени на эксперименты очень дико звучит для большинства менеджеров и если в вашей команде проблемы с убеждением лучший способ, запилить небольшую связку и показать наглядно. У нас с этим проще, так как все были заинтересованы и поддерживали процесс. Но экспериментальных месяцев у нас все же не было.

Модернизация

Сейчас более или менее отлажен подход реализации интерфейса, как для крупных так и для небольших проектов. Есть куда расти дальше. Мы делаем ставку на технологии, которыми будем пополнять/заменять текущую связку. Также есть несколько идей, как сделать это все более универсальным. И к счастью эта цепочка интеграция — обкатка — унификация идет безостановочно, а интеративность этого процесса развязывает руки, дает возможность совершать смелые шаги и бесконечно шлифовать подход. Если описать одной фразой, то наша цель это “гибкость, простота и автоматизация”