Сильный менеджер способен вытащить проект так, чтобы клиент остался доволен даже при слабой технической команде. Слабый менеджер способен завалить проект даже при сильной команде. Вам не обязательно знать все технические нюансы, но навык технологий должен быть выше (или хотя бы на уровне) с заказчиком.
Специалисты склонны отвечать только за свою работу, поэтому если получают продолжительное время посредственный результат, теряют почву — уверенность в своей работе и могут вернуться к своей прежней специальности. Уже не в рамках вашей компании.
Продажники уже умеют общаться с людьми, договариваться и убеждать. Если их погрузить во внутреннюю кухню, дать возможность общаться со специалистами и не оставлять без присмотра, может выйти хороший менеджер. Менеджер других отраслей или из другой компании приносит с собой багаж привычек, который может деструктивно сказаться на вашей команде. Поэтому важно не оставлять его без присмотра.
Оговаривайте период подготовки, все критерии успеха и неуспеха, пошаговость. Развивать человека по шагам — гораздо лучше, чем бросить его в бой и разгребать ошметки проектов, заказчиков и команды через пару месяцев.
ПОДГОТОВКА ПРОЕКТА К ЗАПУСКУ
Релиз-менеджмент — это подготовка проекта к состоянию, когда на него можно запускать реальных пользователей. Мы будем говорить о ручном тестировании. Он дешевле для небольших проектов. Чтобы проводить тестирование, тестировщику необходимо на что-то опираться.
Это могут быть чек-листы (критерии проверки готовности задач), утвержденные результаты предыдущих этапов (ТЗ, прототипы, бэк-логи), здравый смысл.
ПРОВЕРКА МАКЕТОВ
На этом этапе мы сверяем макеты с перечнем функций, которые запланированы к реализации. Такая проверка необходима не всегда, лишь в небольших проектах, где их сильно больше дюжины. Наша задача — убедиться, что дизайнер в творческом порыве не придумал лишних новых функций, и в угоду красоте или по неосторожности не забыл какие-то элементы страницы (или даже целые экраны).
Если дизайнер получает ТЗ в письменном виде, рекомендуем проверять законченную работу методом светофора. Красный цвет — сделано с ошибками. Желтый цвет — есть незначительные расхождения. Зеленый цвет — все в порядке. Серый цвет — есть вода. Белый цвет будет означать, что тестировщик это место еще не проверял.
Красить нужно не абзацами, а слово за словом. Бывает, что разница в нескольких буквах кардинально меняет смысл задачи (к примеру, “и” прочитают как “или”).
ТЕСТИРОВАНИЕ ВЕРСТКИ
В этом нам может помочь инструмент, который прямо в браузере сможет сравнить макет и готовую работу и показать расхождения.
Одним из таких инструментов является плагин для браузера PerfectPixel. Загружаете макеты, выставляете прозрачность и сопоставляете макеты с версткой. Обратите внимание, что “Пиксель в пиксель” не равно “Здравый смысл”.
Представим, что для повышения скорости, над несколькими макетами работали разные дизайнеры. По некоторым макетам могли быть доработки, некоторые приняты с первого раза. В таком случае, вероятность того, что макеты будут одинаковыми крайне мала. Так что добавление людей в опаздывающий проект скорее всего его только затянет.
ТЕСТИРОВАНИЕ РАЗРАБОТКИ
На этом этапе собираются все недоработки и мелочи с предыдущих этапов. Часто поэтому на программистов ложиться вся вина за недоработки, в том числе невнимательность самого менеджера. Тестирование проекта закладывается еще на этапе планирования.
Если идет работа по SCRUM, то имеет смысл привлекать тестировщика к планированию спринта. Это активность, когда вся команда собирается вместе, зачитываются и обсуждаются вслух постановки по задачам, которые пойдут в работу.
Тестировщик наравне со всеми участниками принимает участие в планировании и оценке, слушает обсуждение задач, понимает детали. Так у всех будет общее понимание задач и необходимых результатов + тестировщик получит навыки оценки и декомпозиции задач.
Эти навыки помогут ему в дальнейшем стать менеджером.
Тест-кейсы пишутся таким составом (тестировщик + разработчик), чтобы сэкономить время в будущем. Если тестировщик пишет тест-кейсы в одиночестве, он может придумать то, чего вообще не было в задаче, или наоборот — не указать что-то важное.
Менеджер в подготовке тест-кейсов участвует только в случае, если возникают вопросы, требующие его решения. Стоимость каждого бага в зависимости от субъекта, который его нашел. Итерационное тестирование проводится раз в день. В редких случаях — раз в 2 дня. Для этого при планировании оценка задач не должна превышать 4-8 часов на выполнение.
Если больше — декомпозируем. Такой подход применим к крупным проектам.
Если у вас простой проект на неделю, смысла в итерационном тестировании нету. Достаточно сделать полный тест по всем задачам после завершения разработки. Упрощайте проект под реальные задачи. Автоматизированное тестирование.
ТРЕБОВАТЕЛЬНОСТЬ DIGITAL-ПРОДЮСЕРА
Умение настоять на интересах своего проекта. Задача менеджера состоит в организации рабочего процесса таким образом, чтобы человеку было проще выполнить задачу, чем ее не выполнять. Необходимо удерживать исполнителей в состоянии интереса к задаче и ненапряжности.
Поле власти в проекте должно быть четко распределено, чтобы не возникало конфликта интересов. Каждый участник проектной работы должен знать, за что отвечает он, а где необходимо прислушиваться.
Менеджер должен дать понять участникам проекта границы своей власти и пресекать любые покушения на нее. К примеру, если менеджер не отреагирует должным образом на опоздание сотрудников, то этот сотрудник отвоюет себе право на опоздания, а менеджер потеряет часть власти.
Чаще всего менеджер остается без следующих прав: на оценку оставшегося времени работы над проектом; выбор инструментов и технологий работы; выбор использования готовых модулей / разработки с нуля; права оценки работы менеджером.
Если вы новичок, наращивайте свою власть постепенно. Давайте несложные задачи с запасом времени, но добивайтесь их 100%-ного выполнения. 100%, не 99%. После этого постепенно наращивайте сложность выполняемых задач.
Планирование. Необходимо создать порядок, по которому другие будут делать проект и вообще работать. То есть правила, принципы, ценности подчиненных.
Доведение правил до подчиненных. В письменном виде уместно привести жизненный пример и дописать историю, по причине которой правило существует. Проследите, чтобы все пункты были понятны, и сотрудники получили ответы на все возникшие вопросы.
Среди других методов — личное наставничество, видео-вставки, проведение собраний.
Перед заключением контракта клиент может лишь примерно представлять будущий проект и ответить на общие вопросы по нему, но хочет знать цену проекта. Соответственно на этапе заключения сделки мы строим общий каркас будущего проекта, накидываем основные возможности и рамочно их оцениваем.
У заказчика при этом должны сформироваться примерное понимание бюджета и точная стоимость 1 этапа разработки. Это аналитика.
ЭТАП АГРЕГАЦИИ ТРЕБОВАНИЙ
Отвечает на вопрос “Что делать”. Он нужен для того, чтобы состыковать ожидания заказчика с пониманием проекта студией. Результатом агрегации является ментальная карта. Агрегация позволяет четко определить основные функции сайта, которые соответствуют ожиданиям заказчика и пожеланиям будущих пользователей, а также свести все требования к проекту воедино.
Здесь мы формируем четкую структуру сайта, на основании которой делаются прототипы и ТЗ дизайнерам.
ВИДЕНИЕ ПРОЕКТА
Определяем продукт, который мы делаем и что он из себя представляет. Определяем цели и задачи проекта. Цель — это то, чего мы хотим достичь. Задачи — что будем для этого делать. Задачи заказчики обычно ставят в 2 ключах — увеличение оборота или снижение прибыли.
ЦЕЛЕВЫЕ ПЕРСОНЫ
Разбиваем таблицу функций на разделы будущего проекта. Например, каталог, корзина, отзывы, статьи и т.д. И в каждый раздел переносим решения для пользователей из таблицы. Можно использовать цветную разметку, чтобы было понятно, что к чему относиться.
Повторяйте действия обычного пользователя сайта, пробуйте насколько удобно ему ими пользоваться. Обращайте внимание не только на функции, но и на идею, на подачу контента. Зафиксируйте минусы и плюсы на скриншотах.
В качестве сайтов схожей тематики можно выбирать 2-3 проекта, которые не относятся к нашей сфере, но имеют одинаковые с ней цели и задачи (продажа, привлечение аудитории и т.д.)
СОСТАВЛЕНИЕ СТРУКТУРЫ
Это ментальная карта с обозначением всех разделов и подразделов, функций и элементов. При составлении структуры учитываем те функции, которые выделили на этапе анализа ЦА.
Кроме этого, учитываем все интересные идеи, которые нашли на этапе анализа конкурентов. Сначала прорабатываем общий каркас структуры, а затем для каждого раздела и страницы расписываются блоки и элементы, из которых они состоят.
Каждый раздел декомпозируется и делится на страницы.
ПОДГОТОВКА СТРУКТУРЫ САЙТА
Фиксируем элементы, которые будут встречаться на всех страницах сайта. Фиксируем разделы сайта и самостоятельные страницы (главная, каталог, новости и т.д.) На этом этапе уже должна быть видна общая структура сайта.
Страницы и разделы также декомпозируются по блокам. Фиксируется список функций элементов на каждой странице.
Здесь не нужно продумывать, как конкретно будет реализована функция в интерфейсе и где именно это будет расположено. Все это решается на этапе прототипирования.
В верхней части структуры добавляется легенда с условными обозначениями. Там, где есть вопросы к заказчику ставим специальный маркер. Все вопросы фиксируются прямо в структуре. Выделяем в структуре сайта этапы реализации, чтобы в будущем было удобнее составлять смету проекта.
Обозначаем это маркером, который соответствует номеру этапа. Отдельно обозначаем функции, которых изначально не было в смете, но которые появились на этапе агрегации.
В итоге мы имеем четкую структуру проекта с условными обозначениями и вопросами к заказчику. Остается обсудить ее и прояснить неясные моменты.
ЭТАП ПРОТОТИПИРОВАНИЯ
Прототип — это схема проекта без дизайна и программирования, по которой можно видеть порядок расположения основных блоков страницы и кнопок для совершения целевых действий. Основная цель прототипа — согласовать с заказчиком структуру сложных страниц с заказчиком и проверить, будет ли проект удобен для конечных пользователей с точки зрения персон, которые мы проектировали ранее.
Далее, отправляем ТЗ заказчику. Если клиент не желает расписывать корректировки понятным для всех образом, эта обязанность перекладывается на плечи менеджера. Не стесняйтесь взимать за это доплату.
К разработчику задача должна попадать таким образом, чтобы можно было быстро найти ее среди всего списка задач. Понятным и однозначным образом формулируйте задачи. Конкретизируйте задачи, избегая формы пожелания.
ДЕЛЕГИРОВАНИЕ
Причины плохого делегирования, когда руководители: не понимают, в чем заключается работа руководителя и боятся идти на конфликт с подчиненными.
Какие выделяются виды делегирования? Делегирование на уровне идеи; делегирование на уровне тезисов; делегирование на уровне задач; делегирование на уровне “упал — отжался”.
Если вы слишком детально распишете задачи для человека, который способен выполнять задачи на более ответственном уровне делегирования и доверия, человек может обидится.
Предусмотрите в графике время на то, чтобы поставить задачу. Определите параметры задачи в зависимости от уровня исполнителя. Распределите параметры по приоритетам.
Определяем методы и ресурсы. Проговариваем цели по SMART. Учитывайте разницу между трудоемкостью (необходимым количеством времени на выполнение задачи) и реальными сроками выполнения проекта. Выбираем исполнителя. Учитывайте нагрузку, рабочий график и уровень знаний и навыков подчиненных. Формулируем задачу в зависимости от уровня подчиненных (уровень цели/тезисов/т.д.)
Если подчиненные жалуются на плохую постановку задач, это повод прислушаться и изменить детализацию задачи.
Контрольные точки. Проверяем исполнение. Давать обратную связь / наказывать / поощрять по итогам контроля. Либо изменить параметр задания.
ПЕРЕГОВОРЫ И ПРОДАЖИ
Продажа — это умение убедить человека в своей правоте и донести мысль. Заказ digital-услуги глазами клиента.
Цикл продаж. Приветствие — представьтесь и спросите, удобно ли человеку говорить.
Выяснение потребностей — задавайте открытые вопросы и давайте человеку понять, что вы его внимательно слушаете. Информация, которую вы берете у клиента будет использоваться для составления структуры будущего проекта. Фиксируйте письменно (лучше в электронном виде) все договоренности, которые заключили в процессе разговора.
Этап выяснения потребностей не заканчивается первичным брифованием.
Презентация — на этом этапе презентация минимальная. В идеале необходимо повторить постановку задачи. которая необходима клиенту, после чего ориентируем его по дальнейшим действиям.
Работа с возражениями — всегда отсылайте договоренности с клиентом ему на почту, чтобы он в дальнейшем не мог “случайно забыть” какую-то деталь. Выписывайте возражения клиентов и разбирайте их после разговора в спокойной обстановке. Попытайтесь обработать возражения так, чтобы их грамотно закрыть.
Тренируйте отработку возражений на лидах, которые не принципиально важны для компании.
Закрытие сделки — в конце разговора должна происходить договоренность, по итогу которой и вы, и клиент понимаете, к чему пришли. Продумайте максимальную (идеальный исход) и минимальную (без которой вы из переговоров уйти не согласны) цели.
