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

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

В этом материале вы найдете как общие советы — о том, каких принципов придерживаться при общении с клиентами и как устроен рынок digital, так и конкретные практические рекомендации по построению корпоративной переписки, управлению проектами и созданию разных элементов дизайна. Также затронуты работа отдела продаж, вопрос позиционирования, участия в фестивалях и задачи PR-отдела. Отдельно представлен список инструментов, которые помогают работать быстрее и эффективнее.

Ниже — полное содержание главы, посвящённой управлению проектами.

УПРАВЛЕНИЕ ПРОЕКТАМИ

Принципы работы менеджера проектов

Взаимодействие с клиентами

• Необходимо быть одинаково тактичным при переписке с любым человеком при любых обстоятельствах

• Ответ на письмо клиента должен быть отправлен в течение 15 минут. Если подготовка ответа занимает больше 15 минут — нужно отписаться через сколько будет ответ. Обязательно нужно вернуться с ответом в оговоренный срок

• Смета по проекту должна быть отправлена в течение суток с момента обращения. Исключение — сложные проекты с привлечением подрядчиков

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

• Если письмо прочитано — должно быть выполнено какое-либо действие. Действие необходимо выполнить сразу, не отвлекаясь ни на какие задачи. Если нет возможности выполнить действие — нужно пометить письмо как непрочитанное

• Действие по письму должно провоцировать обратную реакцию. Например, должна быть поставлена задача в Бейскемпе. Через какое-то время ту-душка будет закрыта исполнителем — это и будет обратной реакцией. В идеале обратная реакция должна поступить и от клиента, и от исполнителя

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

• Нельзя гарантировать того, в чем нет стопроцентной уверенности

• Если не получается сформулировать ответ или вопрос в письме — следует позвонить клиенту, обсудить все голосом

• Если клиент неправильно понял смысл сообщения уже два раза подряд — следует позвонить клиенту, обсудить все голосом

• Если клиент не ответил на два последних письма, требующих ответа — следует позвонить клиенту, обсудить все голосом

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

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

• Если клиент сообщил об ошибке — приступить к устранению ошибки нужно немедленно

• Если ошибка имела место быть — необходимо извиниться перед клиентом и впредь контролировать результат в 3 раза тщательней

• Необходимо обсуждать и фиксировать с клиентом сроки оплаты в начале проекта

• Если клиент сообщает о задержке платежа, нужно уточнить с чем это связано и попросить по возможности ускорить процесс

Взаимодействие со штатными специалистами

• Важно быть всегда вежливым и тактичным, уважать каждого специалиста

• Решения руководителя проектов должны исполняться, не следует ввязываться в спор по поводу принятых решений

• Решения должны быть последовательны, нельзя допускать противоречий

• Постановка задач должна быть точной. Нельзя допускать размытых формулировок

• Нельзя передавать специалистам настроение заказчика, нельзя давить на них, если клиент нагнетает атмосферу

• Запрещено связывать напрямую клиента и исполнителя. Все общение происходит только через менеджера

• Менеджер всегда должен знать, чем занят каждый специалист

• Следует сообщать специалисту удобные тебе сроки, а не сроки клиента. Не следует называть клиенту сроки, озвученные специалистом

• Необходимо контролировать соблюдение озвученных специалисту сроков

• Узнавать о прогрессе по задаче необходимо не реже, чем каждые 2 часа

• Если проект должен быть сдан сегодня — исполнитель должен доделать его сегодня. Если нужно задержаться — нужно задержаться

• Всегда нужно подробно обсуждать допущенные специалистом ошибки

• Ту-ду должны закрываться сразу после завершения задачи

• Неактивные проекты должны быть архивированы

Взаимодействие с партнерами

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

• Важно быть всегда вежливым и тактичным, уважать каждого партнера

• Решения руководителя проектов должны исполняться, не следует ввязываться в спор по поводу принятых решений

• Решения должны быть последовательны, нельзя допускать противоречий

• Постановка задач должна быть точной. Нельзя допускать размытых формулировок

• Нельзя передавать партнерам настроение заказчика, нельзя давить на них, если клиент нагнетает атмосферу

• Запрещено связывать напрямую клиента и партнера. Все общение происходит только через менеджера

• Менеджер всегда должен знать, чем занят партнер

• В начале обсуждения каждого проекта нужно удостовериться, что исполнитель сохранит конфиденциальность обсуждения

• Следует строить доверительные отношения с партнером

• Не следует работать с ненадежными исполнителями. Если исполнитель ведет себя недопустимым образом — нужно довести проект до завершения, впоследствии не обращаться к этому подрядчику.

• Необходимо обсуждать все условия до начала работы. Если нет возможности — нужно фиксировать условия поэтапно и добиваться фиксации примерных условий на последующие этапы

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

• Называть сроки нужно с существенным запасом до дедлайна — до 50% от зафиксированных с клиентом сроков

• Исполнитель должен ставить наш проект в приоритет

• Необходимо добиваться соблюдения обязательств. Исполнитель должен выполнить все обязательства до того, как будет проведена оплата

• В начале каждого дня нужно фиксировать объем работы на день

• Следует устанавливать микротайминги на протяжении дня

• Если дополнительно не оговорено, то конец дня — это 18:00. То, что должно быть сдано сегодня — должно быть сдано к 18:00. Все, что позже — это завтра

Самостоятельная работа

• Нужно планировать свой день

• Принимать решения нужно быстро вне зависимости от отведенного на это время

• Задачи должны быть зафиксированы в таск-менеджере

• Следует разбивать задачи по срокам выполнения. Приоритет задач — не только по важности, но и по количеству свободного времени

• Необходимо расписывать (не копировать) для себя информацию о проекте в отдельном документе, так легче найти сомнительные моменты

• Необходимо продумывать и расписывать риски проектов

• Нужно планировать стратегию на случай наступления рисков

• При возникновении проблемы — главное найти решение, а не виновного

• Нельзя скрывать свои ошибки, нужно озвучивать и находить решение

• Необходимо фиксировать все устные договоренности на почте

• Нужно всегда обдумывать задачу от клиента прежде чем передать ее исполнителю, даже если это просто комментарий

Методологии разработки

Каскадная (водопадная) модель разработки Waterfall

Waterfall — подход к процессу разработки, основанный в 1970 году У. Ройсом.

В оригинальной модели У. Ройса последовательность действий выглядела так:

1. Изучение требований проекта
2. Планирование проекта
3. Реализация
4. Воплощение
5. Тестирование
6. Установка
7. Поддержка

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

Плюсы

• подходит для небольших проектов
• прост и понятен в использовании
• не задействует сразу всех специалистов

Минусы

• сложно вносить изменения
• клиент не видит результата
• долгий запуск проекта

Гибкая методология разработки Agile

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

Agile — концептуальный подход к разработке. Существует несколько методик, относящихся к гибким:

1. Extreme Programming (Экстремальное программирование) — подход к разработке продукта в нечетких или быстро меняющихся условиях.
   
   Основными целями подхода являются: уменьшение сроков проекта и создание доверительных отношений с заказчиком.
   Принципы: быстрое планирование проекта и дальнейшее постоянное обновление, заказчик — конечный пользователь продукта, коллективная работа, соблюдение общих правил и требований, анализ архитектуры, быстрый запуск и его дальнейшее обновление, простой дизайн, рефакторинг — методика улучшения кода без изменения функциональности, парное программирование (два программиста/один компьютер), непрерывная интерация, написание автоматических тестов).

2. DSDM (Dynamic Systems Development Method) — подход к разработке целью которого является сдать проект вовремя и уложиться в бюджет. Принципы: все правки — обратимы, высокий уровень квалификации команды (без согласования решений с начальством), частые релизы и их дальнейшая доработка, вовлечение пользователя в процесс разработки, требования оговариваются перед началом проекта.

3. Scrum (Толкучка) — подход к разработке, ориентированный на тотальном контроле всего процесса и быстрых (также контролируемых) итерациях, называемых sprints. Спринт — жестко фиксированная по времени итерация (от 2 до 4 недель).

4. FDD (Feature driven development) — подход к разработке, целью которого является создание работающего продукта в оговоренные сроки. Методология включает в себя 5 основных видов деятельности: разработка модели, составление плана, разделение его по функциям, создание проектировочных пакетов, их реализация.

Инструменты управления проектами и учета рабочего времени

Basecamp

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

На главной странице Basecamp располагаются доступные проекты:

Меню внутри проектов Basecamp:

• Discussions — последние обсуждения проекта.

• To-do list — задачи. Внутри каждого To-do можно создать подзадачи.

• Latest project updates — последние изменения в проекте.

В верхнем меню располагаются разделы:

• Projects — все доступные проекты.

• Calendar — календарь, в котором можно отмечать дату начала, сдачи и окончания проекта и др.

• Everything — как ясно из перевода, этот раздел содержит всю информацию по проектам, в том числе, находящуюся в архиве.

• Progress — все изменения по проектам в хронологическом порядке — сверху новое.

• Everyone — список людей, подключенных к вашей организации.

• Me — вы и ваши действия.

Правила наименования задач

Projects — только название бренда (исключения — клиенты, которым оказывается производственная поддержка, например, Tele2)

To-do list — только название креатива

Сайты

Разработка сайта «X» (To Do List)
Подготовка концепции сайта «X»
Аналитика сайта «X»
Дизайн страницы «Y» сайта"X"
Верстка страницы «Y» сайта «X»
Программирование сайта «X»
Тестирование сайта «X»

Баннеры

Идея по креативу «X»
Скетч раскадровки 240x400 креатив «Х»
Раскадровка 240x400 креатив «Х»
Отрисовка элементов раскадровки по креативу «Х»
Уникальный баннер 240x400 креатив «Х»
Стандартные ресайзы (8 шт.) креатив «Х» — Регион
Нестандартные ресайзы (1 шт.) креатив «Х»
Статичный баннер 1000x240 креатив «Х»
Gif-баннер 240x400 креатив «Х»
Ресайзы статичного баннера (8 шт.) креатив «Х»

Иллюстрации

Скетч иконки / иллюстрации 500x500
Отрисовка иконки / иллюстрации 500x500
И т. д.

Правила наименования файлов

На примере баннера.

brand_creative_size_site
Audi-A4_Humming-bird_240x400_mail-ru

Toggl

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

Вверху страницы находится кнопка Start, после нажатия на которую начинается отсчет времени. Эта же кнопка останавливает таймер.

Создание проекта

Чтобы выбрать проект, в графе «Над чем вы сейчас работаете?» (What are you working on?) введите его название в поле поиска или нажмите Select Project. В случае, если проекта не существует, создайте его, нажав кнопку Create Project. Название проектов в сервисах Basecamp и Trello должны быть одинаковыми.

Назначение клиента

Процедура аналогична созданию нового проекта. Вместо подзадач в сервисе используются таски (Task). Добавить таск можно во вкладке Projects, нажав Add task.

Примеры задач:

— Дизайн страницы «Контакты»

— Верстка главной страницы

— Программирование интерактивного калькулятора

Приватность проектов

Чтобы сделать проект доступным для других пользователей, необходимо перейти во вкладку Team. Специалистов можно добавлять группами: менеджеры, разработчики, дизайнеры, сразу всех специалистов Студии или по-одному.

Рентабельность

Основной смысл Toggl — отслеживание рентабельности проекта. У каждого специалиста в системе проставлен свой рейт (стоимость его часа работы). Рейт умножается на количество затраченного им на проект времени, и получается сумма, которую компания потратила на задачу. Проект считается рентабельным, если итоговая сумма минимум на 20% меньше, чем смета по проекту.

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

Основные правила

• Если проект еще не утвержден и находится на этапе оценки, важно анализировать затраченное на него время (трудозатраты). Для этого создается отдельный таск «Оценка проекта». На него нельзя заранее выделить какое-то количество часов, поэтому поле Estimation следует оставлять пустым.

• При подготовке тендерных предложений Студия тратит ресурсы. Трудозатры по тендерам так же должны считаться с помощью Toggl без проставления Estimation.

• Каждый специалист должен выбирать не только проект, но и конкретный таск, над которым он работает. В этом случае статистика по проекту будет более полной.

• Каждый специалист должен распределять все свое время по задачам. Нераспределенных часов не должно быть. Для этого в конце рабочего дня необходимо проверять свой Toggl.

Trello

— бесплатное веб-приложение для управления проектами, строящееся на Agile-методологии Канбан.

Trello представляет собой набор досок, в которые выставляются задачи. В Студии используется 4 доски:

To Do — задачи;

Doing — исполнение;

Approve — обсуждение;

Done — готово.

Добавить задачу можно в любую из досок, нажав Add a card, затем ее можно перемещать между ними. Так как для управления проектами используется платформа Basecamp, то названия задач дублируются.

После этого следует добавить ссылку на задачу Basecamp в карточку Trello. Для этого необходимо нажать на карточку и добавить ссылку в поле Description.

Подробнее https://trello.com/b/hMKYlEtn/trello

Полная версия учебника доступна по ссылке: http://chulakov.ru/company#PM_Intern_Study-Guide