Чек-лист ведения и закрытия проектов для менеджеров веб-студий: как не сорвать сроки и избежать факапов
Привет, это Коля — CEO студии GRCH! Представьте: пятница, вечер, вы закрываете ноутбук и идете отдыхать. Но тут раздается звонок: клиент требует срочных правок, разработчики спорят из-за ТЗ, а сроки уже не просто поджимают — они в огне. Узнали себя?
Если вы IT-менеджер, то знаете, что без четкого процесса проект может легко выйти из-под контроля. Чтобы избежать таких проблем, мы в GRCH разработали чек-лист ведения и закрытия проектов. В этой статье разберем каждый пункт, а если вам лень читать, листайте вниз и смотрите скринкаст, где проджект-директор GRCH все подробно объясняет.
Зачем нужен чек-лист ведения и закрытия проектов
Чтобы избежать хаоса, мы в GRCH разработали чек-лист ведения и закрытия проектов. Он помогает:
Фиксировать все договоренности и защищаться от внезапных «а я просил по-другому».
Следить за статусом задач, не терять баги и держать клиента довольным.
Закрывать проекты правильно и даже находить точки для апсейла.
Контролировать сроки и финансы, чтобы проект не уходил в минус.
Каждый менеджер ведет свой файл в Google Таблицах, где фиксирует информацию по проекту. Потом все файлы объединяются в одну сводную таблицу, чтобы я и другие руководители могли видеть картину в целом.
Что делают менеджеры:
Указывают название проекта и его статус.
Заполняют чек-лист с ключевыми артефактами.
Актуализируют все данные по мере продвижения проекта.
Дальше разберу детально каждый пункт.
1. Бриф и коммерческое предложение
Перед началом работ важно зафиксировать ожидания клиента. Для этого мы:
Заполняем бриф, где прописываем, что хочет клиент.
В коммерческом предложении указываем детали, нюансы и границы ответственности.
Фиксируем все договоренности, чтобы при необходимости можно было вернуться к ним.
Если клиент в середине проекта говорит: «Я же просил анимации!», менеджеры просто открывают бриф и показывают, что на старте речь об этом не шла.
2. Смета и экономика проекта
Финансовый файл помогает:
Контролировать доходы и расходы.
Следить за маржинальностью.
Реагировать, если проект выходит в минус.
Если проект недоходный, менеджер должен вовремя предложить решения, чтобы исправить ситуацию. Это одна из главных метрик для проджекта, поэтому важно, чтобы он вел финансовый файл по каждому проекту.
3. Тайминг и roadmap
Здесь все просто: если нет четкого расписания работы, сроки проекта могут затянуться. Чтобы этого избежать, менеджеры фиксируют:
Основные этапы и дедлайны.
Кто за что отвечает.
Контрольные точки — если сроки начинают сдвигаться, сразу ищем причину и корректируем план.
4. Таблица страницы и сущности
Эта Google Таблица помогает спроектировать админку:
Менеджер описывает, какие блоки и элементы должны быть в проекте, а еще как они динамически управляются.
Бэкенд-разработчики детализируют настройки и сущности: как будет выглядеть админка, какие у нее должны быть настройки. То есть детально раскладывает то первоначальное описание, которое задал менеджер в таблице страницы.
В итоге формируется база для удобной админки. Если клиент хочет редактировать баннеры на сайте, в этом файле должно быть четко прописано, как это реализовать.
5. Техническое задание — ТЗ
Важно зафиксировать ожидания клиента и команды, чтобы не было разночтений:
Описываем, что и как будем разрабатывать.
Согласовываем с клиентом.
Используем как защиту от перерасходов в Fixed Price проектах.
Если нет ТЗ, считайте, что клиент всегда прав. Даже если он передумает 10 раз.
6. Дизайн-макет
Мы в GRCH используем отдельные чек-листы, чтобы проверять дизайн-макеты. Они помогают дизайнерам создавать макеты, которые легко адаптируются в разработку и не вызывают проблем на следующих этапах. Если вы часто сталкиваетесь с такими задачами, забирайте один из наших материалов — гайд «Как готовить макеты к верстке и экономить на техническом дизайне».
7. Проверка верстки дизайнером
Этот пункт в чек-листе мы ввели после нескольких случаев, когда макет выглядел красиво, но его разработка оказывалась слишком сложной и дорогой. Иногда дизайнеры не учитывали сложность верстки и их дизайн-решений, например, могли накинуть слишком сложные анимации или использовать в макете нестандартные элементы, а это приводило к перерасходу бюджета.
Чтобы этого избежать, ввели регламент по синхронизации между разработчиками и дизайнерами. Теперь они совместно проверяют:
Насколько реалистично воплотить макет в жизнь.
Совпадает ли сложность реализации с изначальной оценкой.
Не выходит ли проект за рамки бюджета и сроков.
Это особенно важно для проектов с фиксированной стоимостью, Fixed Price, так как помогает избежать неожиданных затрат и переработок.
8. WIKI проекта
Эта документация нужна, чтобы новый разработчик, техдиректор или девопс могли быстро разобраться в проекте, и вся важная информация не терялась. Для этого у нас в GRCH есть два типа документации:
Вики — это база знаний по направлениям. Там собраны регламенты, процессы, лучшие практики, которые помогают команде работать быстрее и эффективнее. Это своего рода онбординг для новых сотрудников — заходишь и сразу понимаешь, как устроена работа.
Что там можно найти — вот несколько примеров:
как работать с Git;
как готовить дизайн к разработке;
как правильно верстать email-рассылки.
Каждый специалист ведет вики по своему направлению. Если кто-то глубоко погружен, например, в работу с email-версткой или API-интеграциями, он фиксирует наработки, чтобы ими могли пользоваться коллеги.
README проекта — это уже документация под конкретный проект, которую оформляет разработчик. Она помогает быстро разобраться в его устройстве и развернуть среду.
Что включает README:
Какие технологии и библиотеки используются.
Как развернуть проект локально и на проде — порядок действий, команды.
Сложности проекта, узкие места и важные нюансы.
Где лежат тестовые данные и как ими пользоваться.
Как устроены интеграции с внешними сервисами, если они есть.
README — первая точка входа для любого нового разработчика. Если кто-то подключается к проекту или принимает его в поддержку, он должен получить все ответы в одном месте, а не выискивать их по чатам.
9. Баг-репорт
В Google Таблицах со вшитым скриптом ведем список багов по проекту:
У каждого репорта есть столбцы, которые заполняются самостоятельно:
ожидаемый/фактический результат;
скриншоты;
окружение;
шаги;
столбцы с комментариями для QA, разработчиков и менеджеров — по желанию;
дата — проставляется автоматически;
столбцы с раскрывающимися списками — статус, критичность, исполнитель, приоритет, суть.
Баги фиксируем сразу, иначе они накапливаются, и потом сложнее работать.
10. Проведение ретроспективы
Чтобы каждый новый проект был лучше предыдущего, после завершения проекта или важного этапа проводим ретро:
Обсуждаем, что получилось хорошо, а что можно улучшить.
Разбираем ошибки и находим решения.
Получаем фидбэк от клиента.
В чек-лист прикладываем ссылку на документ по ретроспективе. Для этого у нас есть готовый шаблон ретро, в котором содержатся:
Регламент проведения ретроспективы.
Карточки, которые заполняют все участники проекта.
Отдельная карточка с проблемами и решениями.
Это помогает команде фиксировать ошибки, улучшать процессы и не наступать на те же грабли в будущем.
11. Предложение по развитию — апсейл
После завершения проекта мы в GRCH не забываем про клиента: собираемся с командой и думаем, что еще можем ему предложить и как можем быть полезны. Например, внедрить дополнительный функционал или пересмотреть сценарий оформления заказа, чтобы повысить конверсию.
Предложения по развитию проекта оформляем в виде документа, например, в виде презентации, и ревьюим раз в месяц. То есть созваниваемся с менеджерами, проходимся по проектам и думаем, что еще можем предложить клиентам или партнерам.
Апсейл, кстати, — это не только про деньги, но и про долгосрочные отношения с клиентом.
12. Сбор отзывов
Отзывы помогают формировать доверие и привлекать новых клиентов, поэтому важно собирать их в одном месте, чтобы они не терялись. Мы запрашиваем их у клиентов после того, как завершим проект, чтобы потом использовать в маркетинговых материалах: в соцсетях и на других площадках, например, когда публикуем кейс на WorkSpace.
13. Проверка NDA
Эта колонка для контент-менеджеров и маркетологов. Перед тем как начать работать над кейсом, они проверяют:
Можно ли рассказывать о проекте.
Какие детали можно раскрывать.
Нет ли ограничений от клиента.
Очень важно системно собирать такие данные. Ошибка может обойтись дорого: если публиковать кейс о проекте, который был под NDA, можно получить штраф и испортить отношения с клиентом.
14. Текстовый кейс
Этот пункт внедрил наш контент-маркетолог. В чем суть: хороший кейс можно написать только с помощью людей, которые напрямую работают над проектом. Чаще всего это менеджеры — они погружены в проект, знают все факапы. Иногда приходится дополнительно привлекать дизайнеров или разработчиков, чтобы узнать какие-то детали.
Менеджер пишет базу для кейса, то есть собирает всю фактуру в один файлик. А редактор, если нужно, задает дополнительные вопросы, превращает это в крутой материал и размещает на площадках, например, в Телеграме или на VC.
Кстати, для менеджеров такая работа полезна еще и тем, что пока они собирают материал для кейса, то вспоминают о проекте, об ошибках. Таким образом, рефлексируют, понимают, что и где можно было сделать по-другому, поэтому растут как профессионалы и в следующих проектах работают еще лучше.
15. Финансовая часть и документация
После завершения проекта:
Закрываем все платежи.
Собираем и архивируем документацию.
Проверяем, нет ли незакрытых обязательств.
16. Анкета NPS — оценка удовлетворенности клиента
Отправляем клиенту опрос, чтобы понять:
Насколько он доволен работой.
Какие были проблемы.
Готов ли он рекомендовать нас.
В краткосрочных проектах просим заполнить анкету сразу после того, как проект завершится. А если это долгосрочный проект — запрашиваем фидбэк раз в два месяца.
Скринкаст: чек-л��ст ведения и закрытия проектов
Никита Бакланов, проектный директор в GRCH, подробно объясняет каждый пункт чек-листа →
Менеджеры в GRCH используют этот чек-лист в каждом проекте, и он действительно работает. Если хотите управлять клиентскими задачами без стресса и путаницы, попробуйте внедрить его в свою работу.
Если у вас есть идеи, как можно улучшить чек-лист — пишите в комментариях. А еще делитесь, был ли он полезен для вас, мне интересно послушать обратную связь →