Я Никита, больше пяти лет работаю в веб‐студии из Петербурга. За последние годы диджитал‐сферу захватили продуктовые компании: специалисты стремятся устроиться туда на работу, а руководители выделяют продуктовые направления и запаковывают внутренние проекты в отдельные решения, чтобы выпустить на рынок свой продукт.
Проектная разработка постепенно стала ассоциироваться с конвейером, агентством полного цикла или аутсорсом. Но работать попроектно — это не значит 100 проектов в год и полный штат менеджеров продаж. Вы можете построить комфортный для себя гибрид проектной и продуктовой разработки, сохраняя лучшие практики обоих режимов работы.

Design Prosmotr — крупнейшая встреча дизайнеров в России
За годы работы я сформулировал немало тезисов о продуктовом походе. Часть из них я раскрыл в лекции «Как мы чуть не потеряли веб‐студию» на конференции Design Prosmotr, она о наших ошибках в менеджменте и построении бизнес‐процессов, а также о том, к каким выводам мы пришли.
Свои тезисы я оформил в виде серии статей, в которых обращу внимание на подводные камни клиентской разработки. Расскажу о тех. долге, рекламе и поиске специалистов. Первая статья — о том, что далось нам тяжелее всего. О том, как сопровождать проекты.
От создания к сопровождению
Большой проект невозможно сделать хорошо, просто работая по схеме «Заказчик—Исполнитель». Поэтому ещё до начала сотрудничества мы стремимся встать на одну сторону и работать с клиентом, так, словно мы его отдел. Так обе стороны в полной мере заинтересованы не только в сроке, но и в качестве решений.
Это значит, что проекты мы берём с прицелом на долгосрочное сотрудничество, а после завершения работ не пропадаем, а переходим к следующему этапу жизненного цикла продукта — к сопровождению.
Преимущества такого подхода понятны. Клиент доволен, что знакомый с проектом подрядчик рядом; мы рады, что проект из нашего портфолио находится под присмотром; руководитель компании счастлив, что компания нашла ещё одного постоянного клиента.
Кроме того, мы держим в уме, что диджитал‐мир активно развивается, а значит через два‐три года, продукт нужно будет обновлять — обеим сторонам лучше, если этим займёмся мы.
Но в дело вступает нерушимая логика: чем больше клиентов — тем больше работы. На первый взгляд, это даже хорошо — можно брать больше людей, расширяться и расти. Но всё не так просто.
Расширяться для саппорта — опасно и недальновидно
Расширяя штат под клиентов, вы сильно рискуете, особенно, если получаете деньги за человеко‐часы, а не фиксированную оплату: так вы ставите свою компанию в прямую зависимость от состояния бизнеса заказчика.
Представим, что отдел, который сотрудничал с вами, расформировали, а ваш проект передают другому исполнителю. Что делать с командой, которая в течение года сопровождала проект? Придётся либо сокращать ценных сотрудников, либо срочно искать новый проект, чтобы были деньги на их зарплату. Получается, что план развития компании зависит не только от вас, а ещё от ваших клиентов — это опасно и недальновидно.
Что будет, если не расширять команду? Очевидно: в какой‐то момент проектов станет больше, чем людей. Тогда начнётся настоящий агентский кошмар: команда перестанет успевать прорабатывать задачи, запустится конвейерный режим работы по принципу LIFO (last in, first out) — кто последний напишет, тот первым получит результат. Это повлечёт за собой рост технического долга, снижение скорости разработки новых продуктов и постепенное выгорание коллектива.
Клиенты станут терять терпение — задачи будут становиться в очередь без учёта срочности и бизнес‐процессов заказчика. Каждый день вы будете начинать с ответов на вопросы «Что с задачами?», а завершать — ночными ответами в духе «Простите, что не успели отписаться…». Теперь ваш бизнес — рафтинг без вёсел.
Ещё один побочный эффект — постепенно оперативность решения вопросов станет важнее творчества и инноваций. Сил и времени на креатив не останется, ваши проекты станут похожи друг на друга. И речь не о фирменной изюминке, а об ограниченных возможностях. Все мы знаем, что происходит с бизнесом, который не адаптируется к инновациям.
Звучит совсем не радужно, но есть решение. В первую очередь стоит изменить отношение к этапу поддержки, если он ассоциируется с тезисами выше по тексту. Во‐вторых, попробуйте разделить задачи на две больших категории — ошибки и нововведения. Первая категория не зависит от клиента, и это ваша задача встроить их решение в свои процессы, ведь это ваш технический долг. О задачах из второй категории расскажу подробнее.
Каждая новая задача — это мини‐проект
Перед подписанием договора о поддержке вы должны договориться с клиентом о важном правиле: обо всех работах стоит предупреждать заранее независимо от их масштаба задач.
Если этого не сделать, то заказчик попытается выполнить за вас часть операционных задач — будет ставить их в том порядке и сочетании, который сам посчитает правильным и логичным. А логика клиента не всегда совпадает с вашей, правда?
Разберём на примере. Допустим, вы сделали сайт жилого дома, и клиент хочет добавить новую фичу — калькулятор программ ипотеки. В мире заказчика это важная бизнес‐задача, поэтому чем раньше она будет готова, тем лучше. Чтобы вам помочь, клиент начинает подсказывать: «Просто возьмите поля ввода из лид‐формы, текст‐сноску сделайте серым, а для анимацию — из бесплатной библиотеки. Сколько вам на это нужно, сегодня успеете?». Или даже придумывать за вас: «Вот примерный макет в гугл‐доке, посто стилизуйте его, чтобы он хорошо смотрелся на сайте».
Вместо того, чтобы потратить время на решение задачи, вы будете общаться с клиентом — спрашивать про макет и задачу, слушать про важность сроков. Гораздо эффективнее получить задачу и формулу для расчёта, а вместо макета — список референсов. Но важнее всего — узнать о задаче заранее, чтобы команда не перегорала, а вы поставили её в план работ, руководствуясь сроками и экспертным пониманием, сколько человеко‐часов уйдёт на её выполнение.
Звучит утопично, но если продемонстрировать на паре кейсов, что это эффективно, заказчик пойдёт навстречу. Таким образом, получая задачу заранее, вы относитесь к ней, как к мини‐проекту со своей дорожной картой, ответственными исполнителями и сроком. И клиентская работа плавно трансформируется в совместную работу над одним продуктом.
Не ведите задачи в чатах
Ещё одна отличительная черта проектной работы — клиенты не знают друг о друге. Для них существуете только вы и список задач, поэтому нет ничего страшного в том, чтобы запросить статусы по каждой из них в чате или в личке. Но чаще всего клиент не один. Все они пишут с разной степенью настойчивости, каждый в своём стиле и (главное!) все одновременно.
Ещё несколько лет назад такое общение было редкостью. Деловая переписка велась в почте, а в чаты существовали только для экстренных вопросов. Сейчас, если у вас несколько клиентов, работа так проникает в жизнь, что в какой‐то момент диалогов с клиентом становится больше, чем переписок с друзьями и семьёй. Какой там work‐life balance…
Вы должны ограничить переписку в чатах. Создайте или найдите удобный инструмент ведения задач, что‐то вроде тикет‐системы. Мы используем ClickUp, который интегрирован с внутренней системой управления проектами, но вы можете выбрать любой трекер задач, важно, чтобы система была одинаковой для всех клиентов.
В дэшборде ClickUp мы видим все проекты, которые сопровождаем, клиенты изолированны друг от друга. Каждую задачу мы снабжаем статусом, пониманием задачи, сроком; задаём вопросы, тегаем клиента, отписываемся, когда всё готово.
Заказчик доволен — он интегрирован в процесс на приемлемом для себя уровне — видит статусы всех задач и в курсе сроков. А если клиент доволен и вопросов нет, у вас появляется гораздо больше времени на работу.
Делегируйте сопровождение
Если вы понимаете, что процессы внутри своей компании перестроить почти невозможно, рассмотрите вариант сотрудничества с молодыми студиями или агентствами. Сейчас на рынке немало молодых компаний, которые с удовольствием ухватятся за возможность поработать с большими клиентами. Подойдёт любой вариант, в котором вы уверены, даже если это фриланс‐проект вашего сотрудника.
Ни в коем случае нельзя делать это тайно: просто передавать задачи молодой компании, а результат выдавать за свой. Это невыгодно ни одной из сторон — вы всё равно должны быть погружены в задачи, чтобы обсуждать их с клиентом, а субподрядчик не сможет добавить клиента в портфолио (а это несомненно важно для молодой компании).
Передавать компанию на сопровождение нужно открыто. Приезжайте на встречу вместе, расскажите об успешном опыте взаимодействия и покажите, что не первый день знаете друг друга, и будете на связи в переходный период. Перед этим обязательно устройте несколько сессий обмена знаниями между командами, можно даже позвать на них клиента. Помните, что рекомендуя компанию‐подрядчика по сопровождению, вы всё ещё отвечаете за результат.
Поддержка — это не страшно
О сопровождении проектов можно написать книгу. Четырёхтомник. В этой философской статье я постарался показать, что сопровождать проекты можно без надрыва и выгорания. Даже наоборот, поддерживая продукт в актуальном состоянии и регулярно вдыхая в него новую жизнь, вы будете конкурентны на рынке — ведь вас рекламируют только ваши работы.
Все тезисы сформулированы на основе моего опыта работы в веб‐студии и общения с коллегами из студий и продуктовых компаний. Примеры выдуманы, совпадения случайны.
Если вы сталкивались с ситуацией, когда саппорта становилось больше, чем новых клиентов, напишите мне о том, как вы справились и не закрылись.
Или закрылись.