Сроки – наше всё. Часть вторая.

В статье «Организация рабочих процессов. Сроки — наше всё» я начал рассказывать о том, что мы делаем, чтобы придерживаться сроков. Сегодня я подробно расскажу о работе в команде, ведь 90% успеха зависит от слаженной работы сотрудников.

описание изображения

Работа в команде

…Внедряя систему распределения задач, мы волновались за результат: смогут ли сотрудники самостоятельно спланировать своё время, успеют ли они закрыть все задачи до дедлайна? И наши страхи оправдались.

Нам было сложно выполнить задачу в срок, не перегружая сотрудников, — не только из-за их ограниченного опыта в планировании, но и потому, что скорость работы конкретного сотрудника зависит от четырёх факторов. Вот они:

1. Результат работы предыдущего сотрудника.

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

2. Собственные технические навыки.

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

3. Концентрация на задаче.

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

4. Мотивация.

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

С этим надо было что-то делать, и мы приняли меры:

1. Для команды, участвующей в работе над проектом, мы делаем презентацию (такую же, как для клиента).

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

2. Дизайнер в процессе работы консультируется с технологом и программистом.

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

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

3. По окончании работ дизайнер проводит презентацию для команды и собирает замечания.

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

4. Отдельное Т. З. для программистов.

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

5. Тестирование и документирование

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

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

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

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

Если у вас возникнут вопросы, которые касаются нашего рабочего процесса, пишите мне: amelin@dvebukvy.ru. Я постараюсь подробно на них ответить.

Михаил Амелин Михаил Амелин директор