Планирование и организация работы творческой команды в условиях каскадной модели проектов08.12.2014 15:33

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

08.12.2014 | Автор: Константин Терещенков, Дизайн-бюро «Две буквы» (Сооснователь)

Когда мы только начинали свой бизнес это была компания из трех человек) За уже почти 4 года многое поменялось. Компания выросла в 4 раза, проекты, которые мы делаем стали иметь высокую степень ответственности. В этом году мы вошли в сотню лучших диджитал-агентств России и занимаем 25 строчку в рейтинге самых креативных студий Рунета. На всем пути от нас требовалось постоянное внимание к вопросам планирования и организации рабочих процессов. И, конечно мы многое пробовали, меняли, придумывали за это время. Результатами этой работы я и хотел бы с вами сегодня поделиться.

Проблемы Прежде всего стоит описать те проблемы с которыми мы столкнулись.

У заказчиков нет ТЗ. А если и есть, то его качество очень низкое.

Определить стоимость и сроки проекта без ТЗ невозможно. Все строится на предположениях, догадках и опыте.

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

Так как сроки определялись не точно, то вполне логично, что также они и соблюдались. А это негативно сказывается на репутации, выгодности проектов и конечно на настроении коллектива.

Важно понимать что решение всех этих задач критически важно, так как их игнорирование ведет к серьезному уменьшению прибыли, разрушению команды и, как следствие — к саморазрушению бизнеса.

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

Одно из самых важных решений, которые мы приняли довольно давно: «Клиент не должен писать ТЗ. ТЗ — наша забота». В большинстве случаев клиент не может качественно формализовать и описать работу, которую необходимо для него сделать. Зато у него есть цели, опыт и знания. Так зачем взваливать на него ту работу, с которой мы справимся лучше? Незачем. Так мы пришли к тому, что первым этапом работы над любым сайтом стало проектирование. Что это дает:

Детальное понимание задач и целей клиента

Детальное понимание клиентом какой результат он получит

Исходные данные для близкой к реальности оценке сроков и соотвественно стоимости проектов.

Клиент получит прототипы и техническое задание на их основе.

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

Клиент получает отличную возможность провести тендер на основании прототипов и ТЗ.

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

На основании прототипов дизайнеру довольно легко оценить предстоящий объем работы и тут мы получаем весьма точное число в часах. Время на верстку проекта как правило на 10–15% больше времени на дизайн. А время необходимое на разработку согласовывается с тимлидом.

Важный момент: по согласованию с Заказчиком мы называем время для комфортного решения задачи дизайна. Клиент имеет возможность сократить этот этап (в определенных рамках). Тут мы руководствуемся принципом: «Срок — это просто часть задачи».

Прототипы презентуются клиенту. Вместе с прототипом клиент получает два документа: техническое задание и почасовой план работ в котором одна из величин (время на верстку) определена не точно.

Первый этап работы над проектом завершен. Заключается договор с Заказчиком на создание сайта и продакшн приступает к работе.

Этап I. Дизайн Расскажу о некоторых вещах, к которым мы пришли не так давно:

Клиент в большинстве случаев не получает наброски или эскизы. Мы отрисовываем все страницы сайта и только потом устраиваем презентацию Заказчику. Опыт показывает, что наброски очень плохо воспринимаются (нет ощущения продукта, нет понимания что в этом наброске останется в финале, а что еще требует проработки и тд). Но, чтобы не было сюрпризов мы, конечно, заранее с клиентом определяем стилистику будущего сайта. Референсы решают проблему.

Мы помним, что время на верстку было определено не точно. Как не допустить того, чтобы после завершения работ по дизайну верстальщик не сказал «А это у меня займет больше времени чем вы продали заказчику»? Ведь когда сотрудник получает задачу, которую он не может реализовать в поставленные сроки это не правильно! Мы нашли достойный и как нам кажется правильный выход из ситуации:

Верстальщик заранее знает сколько у него будет времени на верстку проекта.

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

Перед тем, как презентовать дизайн-макеты заказчику они проходят:

Постоянный контроль и правки со стороны арт-директора в формате «презентация-фидбэк»

Этап внутренней презентации рабочей группе: как только у дизайнера практически полностью готовы все макеты. Дизайнер презентует свою работу всем участникам проекта: арт-директору, верстальщику, тим-лиду, менеджеру проекта. Этот этап — защита дизайнером своей работы перед всей командой. Любой вопрос со стороны участников должен получить ответ. Отвечать «Ну просто я так придумал» нельзя. Любое свое решение дизайнер должен мотивированно объяснить. Этап дает очень глубокую критику со стороны, которая обладает реальной экспертизой.

Презентацию макетов проводят два человека: менеджер проекта и арт-директор. Как правило продолжительность такого мероприятия — 2–3 часа. Цель — не борьба с возражениями, а реальное достижение взаимопонимания. Заказчик должен увидеть и понять как мы достигли его целей, а мы должны понять почему именно заказчик хочет внести те или иные правки.

Получив правки от клиента мы вносим коррективы в макеты и отправляем на согласование. Если все отлично (а как правило второго цикла правок не бывает) мы приступаем к этапам верстки и программирования.

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

Менеджер проекта вместе с тимлидом пишут второе ТЗ, адаптированное для внутренних нужд. Оно содержит сухую логику, схемы данных и сценарии. Эта небольшая дополнительная работа сократила время разработки почти на 25%.

Задача тимлида как руководителя используя свои ресурсы (сотрудников, собственное время) вовремя сдать проект к дедлайну.

Каковы результаты Мы значительно увеличили эффективность процесса работы.

Сотрудникам интереснее участвовать в разработке новых продуктов

Гораздо более предсказуемые сроки и качество их соблюдения

Повысилось качество презентации дизайна заказчику.