(Skillbox & Sibirix & Tagline) Управление Digital проектами

Skillbox + Сибирикс
Управление проектами
Необходимые навыки Руководителя проекта
Сильный менеджер способен вытащить проект так, чтобы клиент остался доволен
даже при слабой технической команде.
Слабый менеджер способен завалить проект даже при сильной команде.
Вам не обязательно знать все технические нюансы, но навык технологий должен

быть выше (или хотя бы на уровне) с заказчиком.
https://tele.click/plumcore
1. Специалисты склонны отвечать только за свою работу, поэтому если
получают продолжительное время посредственный результат, теряют
почву - уверенность в своей работе и могут вернуться к своей прежней
специальности.
Уже не в рамках вашей компании.
2. Продажники уже умеют общаться с людьми, договариваться и убеждать.
Если их погрузить во внутреннюю кухню, дать возможность общаться со
специалистами и не оставлять без присмотра, может выйти хороший
менеджер.
3. Менеджер других отраслей или из другой компании приносит с собой
багаж привычек, который может деструктивно сказаться на вашей команде.
Поэтому важно не оставлять его без присмотра.
Оговаривайте период подготовки, все критерии успеха и неуспеха, пошаговость.
Развивать человека по шагам - гораздо лучше, чем бросить его “в бой” и разгребать
ошметки проектов, заказчиков и команды через пару месяцев.
Рост компетенций менеджера
Дилетанты, которые нахватались поверхностной информации, чаще всего, более
самоуверенны. С ростом знаний и опыта специалисты теряют уверенность, вникая в
детали и нансы работы, но потом постепенно ее наращивают.
Карта компетенций менеджера проектов
https://drive.google.com/open?id=1XHqWkwMAmTM62xxbRVeLM7aE-tPOa2gG
Релиз-менеджмент.
Подготовка проекта к запуску
Релиз-менеджмент - это подготовка проекта к состоянию, когда на него можно

запускать реальных пользователей.
Мы будем говорить о ручном тестировании. Он дешевле для небольших проектов.
Чтобы проводить тестирование, тестировщику необходимо на что-то опираться.

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

законченную работу методом светофора.
Красный цвет - сделано с ошибками.

Желтый цвет - есть незначительные расхождения.
Зеленый цвет - все в порядке.
Серый цвет - есть вода.
Белый цвет будет означать, что тестировщик это место еще не проверял.
Красить нужно не абзацами, а слово за словом. Бывает, что разница в нескольких

буквах кардинально меняет смысл задачи (к примеру, “и” прочитают как “или”).
Тестирование верстки
В этом нам может помочь инструмент, который прямо в браузере сможет сравнить
макет и готовую работу и показать расхождения.
Одним из таких инструментов является плагин для браузера PerfectPixel.
Загружаете макеты, выставляете прозрачность и сопоставляете макеты с версткой.
Обратите внимание, что “Пиксель в пиксель” не равно “Здравый смысл”.
Представим, что для повышения скорости, над несколькими макетами работали

разные дизайнеры.
По некоторым макетам могли быть доработки, некоторые приняты с первого раза.
В таком случае, вероятность того, что макеты будут одинаковыми крайне мала. Так
что добавление людей в опаздывающий проект скорее всего его только затянет.
Чтобы избежать таких результатов, используйте общий гайдлайн, который
иллюстрирует основные элементы и отступы. Теперь не требуйте верстки
“Пиксель в пиксель”. Но если отступ от заголовка в гайдлайне = 20 пикселям, он
должен быть таким во всех аналогичных местах.
Теперь даже если в одном из макетов отступ = 18 пикселям, а в другом = 21
пикселю, тестировщик должен отметить это ссылаясь на гайдлайн, а разработчик -
исправить.
В случае спора, финальное решение принимает менеджер.
Тестирование разработки
На этом этапе собираются все недоработки и мелочи с предыдущих этапов.

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

Если идет работа по SCRUM, то имеет смысл привлекать тестировщика к
планированию спринта. Это активность, когда вся команда собирается вместе,
зачитываются и обсуждаются вслух постановки по задачам, которые пойдут в
работу.
Тестировщик наравне со всеми участниками принимает участие в планировании и

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

Большая часть тест-кейсов пишется на основе полного чек-листа проверки
проектов.
Чек-лист проверки проектов

https://docs.google.com/spreadsheets/d/1NCfKsFqfAvuNjnnx8aDhSsA63uts3N1Sxvv5
gnnG8sE/edit?usp=sharing
Чек-лист общий и не учитывает контекст, поэтому в тест-кейсах необходимо

прописать именно те пункты, которые применимы к решению конкретной задачи.
Тест-кейсы пишутся таким составом (тестировщик + разработчик), чтобы

сэкономить время в будущем. Если тестировщик пишет тест-кейсы в одиночестве,
он может придумать то, чего вообще не было в задаче, или наоборот - не указать
что-то важное.
Менеджер в подготовке тест-кейсов участвует только в случае, если возникают
вопросы, требующие его решения.
Итерационное тестирование в спринте
1. Команда выполняет часть задач, выгружает на тестовый сервер.

2. Тестировщик проверяет задачи и пишет баг-лист (список элементов с
ошибками).
3. Разработчики приступают к исправлению багов (ошибок).
4. Разработчики приступают к следующим задачам.
Это необходимо, чтобы баги не накапливались в геометрической прогрессии.

Мелкие тестирования в итоге экономят 20-50% времени на исправление ошибок.
Стоимость каждого бага в зависимости от субъекта, который его нашел.
Итерационное тестирование проводится раз в день. В редких случаях - раз в 2 дня.

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

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

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

деплоймент - перенос проекта на рабочий сервер.
Упрощайте проект под реальные задачи
Автоматизированное тестирование
Требовательность digital-продюсера
Умение настоять на интересах своего проекта.
Задача менеджера состоит в организации рабочего процесса таким образом, чтобы

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

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

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

1. На оценку оставшегося времени работы над проектом.
2. Выбор инструментов и технологий работы.
3. Выбор использования готовых модулей / разработки с нуля.
4. Права оценки работы менеджером.
Если вы новичок, наращивайте свою власть постепенно. Давайте несложные задачи

с запасом времени, но добивайтесь их 100%-ного выполнения. 100%, не 99%.
После этого постепенно наращивайте сложность выполняемых задач.
1. Планирование.
Необходимо создать порядок, по которому другие будут делать проект и
вообще работать. То есть правила, принципы, ценности подчиненных.
2. Доведение правил до подчиненных.
В письменном виде уместно привести жизненный пример и дописать
историю, по причине которой правило существует. Проследите, чтобы все
пункты были понятны и сотрудники получили ответы на все возникшие
вопросы.
Среди других методов - личное наставничество, видео-вставки, проведение
собраний.
Менеджер должен уметь правильно обработать возражения и донести
важность регламента.
3. Контроль и наблюдение за ходом работ.
Следите за тем, как работают сотрудники, а не что они об этом говорят.
4. Поощрение / наказание.
Когнитивные искажения
Отличие требовательности от мозгоклюйства
Очень часто менеджер предпочитает ставить задачи команде с помощью какого-то
сервиса, избегая личного общения и неприятных разговоров. Если проект большой,
личного общения не избежать.
Если не уверены, что ваше обещание/распоряжение/угроза будут выполнены - не

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

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

точная стоимость 1 этапа разработки. Это аналитика.
Этап агрегации требований
Отвечает на вопрос “Что делать?”
Он нужен для того, чтобы состыковать ожидания заказчика с пониманием проекта

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

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

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

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

сводную таблицу.
Разбиваем таблицу функций на разделы будущего проекта. Например, каталог,

корзина, отзывы, статьи и т.д.
И в каждый раздел переносим решения для пользователей из таблицы.
Можно использовать цветную разметку, чтобы было понятно, что к чему
относиться.
Анализ сайтов конкурентов
Результатом анализа сайтов конкурентов является список идей, которые можно
учесть при составлении структуры будущего сайта, а также список функций и
решений, которые стоит избегать.
1. Рассматриваем сайты 2 типов:
2. Повторяйте действия обычного пользователя сайта, пробуйте насколько

удобно ему ими пользоваться.
3. Обращайте внимание не только на функции, но и на идею, на подачу
контента.
4. Зафиксируйте минусы и плюсы на скриншотах.
5. В качестве сайтов схожей тематики можно выбирать 2-3 проекта, которые не
относятся к нашей сфере, но имеют одинаковые с ней цели и задачи
(продажа, привлечение аудитории и т.д.)
Составление структуры
Это ментальная карта с обозначением всех разделов и подразделов, функций и
элементов.
1. При составлении структуры учитываем те функции, которые выделили на
этапе анализа ЦА.
2. Кроме этого учитываем все интересные идеи, которые нашли на этапе
анализа конкурентов.
3. Сначала прорабатываем общий каркас структуры, а затем для каждого
раздела и страницы расписываются блоки и элементы, из которых они
состоят.
4. Каждый раздел декомпозируется и делится на страницы.
Подготовка структуры сайта

1. Фиксируем элементы, которые будут встречаться на всех страницах сайта.
2. Фиксируем разделы сайта и самостоятельные страницы (главная, каталог,
новости и т.д.). На этом этапе уже должна быть видна общая структура сайта.
3. Страницы и разделы также декомпозируются по блокам. Фиксируется список
функций элементов на каждой странице.
Важно! Здесь не нужно продумывать, как конкретно будет реализована
функция в интерфейсе и где именно это будет расположено. Все это
решается на этапе прототипирования.
4. В верхней части структуры добавляется легенда с условными
обозначениями. Там где есть вопросы к заказчику ставим специальный
маркер. Все вопросы фиксируются прямо в структуре.
5. Выделяем в структуре сайта этапы реализации, чтобы в будущем было
удобнее составлять смету проекта. Обозначаем это маркером, который
соответствует номеру этапа.
6. Отдельно обозначаем функции, которых изначально не было в смете, но
которые появились на этапе агрегации.
7. В итоге мы имеем четкую структуру проекта с условными обозначениями и
вопросами к заказчику. Остается обсудить ее и прояснить неясные моменты.
На этапе агрегации важно задавать правильные вопросы.
Важно задавать открытые вопросы.
Примеры вопросов для заказчика:
Любой дизайн, прототип, посыл и т.д. к пользователю строится на УТП.
Если этой составляющей продажи нет - продавать будет сложно.
Шаблон для первичного брифования заказчика
https://drive.google.com/open?id=13JdOKccc2YyC-8GUzfGu6F9UZ1wY8G4K
Этап прототипирования
Прототип - это схема проекта без дизайна и программирования, по которой можно

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

заказчиком и проверить, будет ли проект удобен для конечных пользователей с
точки зрения персон, которые мы проектировали ранее.
ТЗ на разработку проекта
Заказчики хотят ТЗ потому что:
Шаблон ТЗ
https://drive.google.com/open?id=1bDEjtEdEwUWq32qUMm4mcvJt95q9gGzPMAiDfvK3vUY
Если в проектах необходима интеграция с другими сервисами. необходимо

создавать интеграционные протоколы.
Правильная постановка задач
1. Смягчайте речь с помощью дополнительных смайлов / знаков.
2. Избегайте излишне агрессивных неконструктивных комментариев.
3. Описывайте проблему не на скриншоте, а в комментариях.
4. Если клиент не желает расписывать корректировки понятным для всех

образом, эта обязанность перекладывается на плечи менеджера. Не
стесняйтесь взимать за это доплату.
5. К разработчику задача должна попадать таким образом, чтобы можно было
быстро найти ее среди всего списка задач.
6. Понятным и однозначным образом формулируйте задачи.
7. Конкретизируйте задачи, избегая формы пожелания.
8.
9. Не “подкидывайте посуду”. Предоставляйте следующие пункт исправления
задач только после завершения предыдущего списка.
10.
Делегирование
Причины плохого делегирования, когда руководители:

1. Не понимают, в чем заключается работа руководителя.
2. Боятся идти на конфликт с подчиненными.
3. Не уверены в подчиненных.
4. Нет достаточных компетенций.
1. Делегирование на уровне идеи
2. Делегирование на уровне тезисов
3. Делегирование на уровне задач
4. Делегирование на уровне “упал - отжался”
Если вы слишком детально распишете задачи для человека, который способен

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

2. Определите параметры задачи в зависимости от уровня исполнителя.
3. Распределите параметры по приоритетам.
4. Определяем методы и ресурсы. Проговариваем цели по SMART.
5. Учитывайте разницу между трудоемкостью (необходимым количеством
времени на выполнение задачи) и реальными сроками выполнения проекта.
6. Выбираем исполнителя. Учитывайте нагрузку, рабочий график и уровень
знаний и навыков подчиненных.
7. Формулируем задачу в зависимости от уровня подчиненных (уровень
цели/тезисов/т.д.).
Если подчиненные жалуются на плохую постановку задач, это повод
прислушаться и изменить детализацию задачи.
8. Контрольные точки. Проверяем исполнение.
9. Давать обратную связь / наказывать / поощрять по итогам контроля.
Либо изменить параметр задания.
Переговоры и продажи
Продажа - это умение убедить человека в своей правоте и донести мысль.
Заказ digital-услуги глазами клиента
Типовые ошибки в переговорах
Цикл продаж
1. Приветствие.
Представьтесь и спросите, удобно ли человеку говорить.
2. Выяснение потребностей.
Задавайте открытые вопросы и давайте человеку понять, что вы его
внимательно слушаете.
Информация, которую вы берете у клиента будет использоваться для
составления структуры будущего проекта.
Фиксируйте письменно (лучше в электронном виде) все договоренности,
которые заключили в процессе разговора.
Этап выяснения потребностей не заканчивается первичным брифованием.
3. Презентация.
На этом этапе презентация минимальная. В идеале необходимо повторить
постановку задачи. которая необходима клиенту, после чего ориентируем
его по дальнейшим действиям.
4. Работа с возражениями.
Всегда отсылайте договоренности с клиентом ему на почту, чтобы он в
дальнейшем не мог “случайно забыть” какую-то деталь.
Выписывайте возражения клиентов и разбирайте их после разговора в
спокойной обстановке. Попытайтесь обработать возражения так, чтобы их
грамотно закрыть.
Тренируйте отработку возражений на лидах, которые не принципиально
важны для компании.
5. Закрытие сделки.
В конце разговора должна происходить договоренность, по итогу которой и
вы, и клиент понимаете, к чему пришли.
Продумайте максимальную (идеальный исход) и минимальную (без
которой вы из переговоров уйти не согласны) цели.
Типы клиентов
Классификация клиентов
Необходима для того, чтобы подстроить диалог под человека, который будет
принимать решение по заключению проекта.
Работа с возражениями
Возражения - это неприятие клиентом вашего предложения.
Возражения делятся на реальные и мнимые. Реальные описывают истинные

причины несогласия, а мнимые служат для того, чтобы избежать принятия
ключевого решения.
Провокация
Слои аргументации
Конструктивный диалог
Оценка проектов
Любая оценка начинается с декомпозиции.
Откуда это на странице?
Управление временем
Определяйте 7 главных задач на неделю и на день.
Формулировки задач
Виды задач

(Skillbox & Sibirix & Tagline) Управление Digital проектами

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

(Skillbox & Sibirix & Tagline) Управление Digital проектами

Загружено:

Авторское право:

Доступные форматы

Skillbox + Сибирикс

Необходимые навыки Руководителя проекта

Вам не обязательно знать все технические нюансы, но навык технологий должен

Рост компетенций менеджера

Релиз-менеджмент - это подготовка проекта к состоянию, когда на него можно

Мы будем говорить о ручном тестировании. Он дешевле для небольших проектов.

Чтобы проводить тестирование, тестировщику необходимо на что-то опираться.

Если дизайнер получает ТЗ в письменном виде, рекомендуем проверять

Красный цвет - сделано с ошибками.

Красить нужно не абзацами, а слово за словом. Бывает, что разница в нескольких

Загружаете макеты, выставляете прозрачность и сопоставляете макеты с версткой.

Обратите внимание, что “Пиксель в пиксель” не равно “Здравый смысл”.

Представим, что для повышения скорости, над несколькими макетами работали

В случае спора, финальное решение принимает менеджер.

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

Тестирование проекта закладывается еще на этапе планирования.

Тестировщик наравне со всеми участниками принимает участие в планировании и

Тест-кейсы пишет тестировщик и разработчик (как правило, более опытный).

Чек-лист проверки проектов

Чек-лист общий и не учитывает контекст, поэтому в тест-кейсах необходимо

Тест-кейсы пишутся таким составом (тестировщик + разработчик), чтобы

1. Команда выполняет часть задач, выгружает на тестовый сервер.

Это необходимо, чтобы баги не накапливались в геометрической прогрессии.

Стоимость каждого бага в зависимости от субъекта, который его нашел.

Итерационное тестирование проводится раз в день. В редких случаях - раз в 2 дня.

Если у вас простой проект на неделю, смысла в итерационном тестировании нету.

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

В случае, если закончена первая версия проекта, вам необходимо сделать

Упрощайте проект под реальные задачи

Умение настоять на интересах своего проекта.

Задача менеджера состоит в организации рабочего процесса таким образом, чтобы

Поле власти в проекте должно быть четко распределено, чтобы не возникало

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

Чаще всего менеджер остается без следующих прав:

Если вы новичок, наращивайте свою власть постепенно. Давайте несложные задачи

Отличие требовательности от мозгоклюйства

Если не уверены, что ваше обещание/распоряжение/угроза будут выполнены - не

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

У заказчика при этом должны сформироваться примерное понимание бюджета и

Этап агрегации требований

Отвечает на вопрос “Что делать?”

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

Агрегация позволяет четко определить основные функции сайта, которые

Чтобы хотя бы приблизительно понимать, кто приходит на сайт, нужно изучить

Переходим к изучению основных целевых персон.

Информацию для составления персон необходимо брать из:

В заключение мы собираем все функции. которые может предложить сайт в одну

Разбиваем таблицу функций на разделы будущего проекта. Например, каталог,

1. Рассматриваем сайты 2 типов:

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

Подготовка структуры сайта

Важно задавать открытые вопросы.

Примеры вопросов для заказчика:

Прототип - это схема проекта без дизайна и программирования, по которой можно

Основная цель прототипа - согласовать с заказчиком структуру сложных страниц с

Заказчики хотят ТЗ потому что:

Если в проектах необходима интеграция с другими сервисами. необходимо

1. Смягчайте речь с помощью дополнительных смайлов / знаков.

2. Избегайте излишне агрессивных неконструктивных комментариев.

3. Описывайте проблему не на скриншоте, а в комментариях.

4. Если клиент не желает расписывать корректировки понятным для всех

7. Конкретизируйте задачи, избегая формы пожелания.

Причины плохого делегирования, когда руководители: