Когда ты создаешь продукт для консервативной отрасли, которая не использовала ничего, кроме Excel и 1С, приходится бороться с возражениями и идти на компромиссы. Брать больше доработок, чтобы выстоять на рынке и наладить контакт с клиентами, а затем перестраивать и собственные процессы.
Привет, Хабр. Меня зовут Алексей Сердюков, уже больше пяти лет я PM «Синтеки», а по совместительству строю процессы и управляю командой. Мы занимаемся разработкой сервисов для строительных компаний. В статье хочу рассказать об изменениях в системе отбора тикетов от клиентов: как было раньше и к чему пришли. Наш подход помог сохранить клиентов на ранних этапах развития продукта и реализовывать задачи без лишней нагрузки на команду. Надеюсь, опыт будет полезен в сферах, где без лояльности к фичам не выстоять, и поможет сориентироваться, как определить, стоит ли тикет усилий.
Нужно ли брать доработки со стороны клиентов?
Из опыта могу сказать – надо. Реализовывать продукт на рынке в условиях быстро растущей конкуренции становится все сложнее. А делать это в сферах, где компании привыкли работать «по старинке» и в лучшем случае будут годами присматриваться к тебе – тем более.
Как процесс строился раньше: генеральный директор – PM
Немного предыстории: наш первый продукт – «Синтека» – был идеей генерального директора, когда тот руководил своей инженерной компанией. Тогда он столкнулся с тем, что на закупках стройматериалов деньги пропадают, как в черной дыре, а что с этим делать, было непонятно. Инструментов для оперативного контроля на этапе подачи заявок с объектов или для согласования счетов на рынке не существовало. Бюджетирование никто не вел. Все вопросы решали в мессенджерах и по телефону. К слову, многие работают так до сих пор.
Тогда ему и пришла идея создать некую программу, которая и о превышениях предупредит, и весь процесс сделает контролируемым. Но так как он был больше про стройку, чем про ИТ, путь занял много лет. И начинался он с 1-2 разработчиков, а пилот запускался в знакомых компаниях.
Спустя несколько лет, уже у сформированного продукта, появились вполне реальные клиенты, которые платили нам деньги. Появились запросы на кастом и точечные доработки. Тогда сбор таких обращений не был оформлен как процесс. Клиенты напрямую связывались с генеральным директором, который фактически выполнял роль PM. Иногда запросы передавали менеджеры, которые обучали пользователей. Фиксировали их разрозненно (в таблицах, заметках или устно). Задачи ставили в Redmine, там же пытались оценить трудозатраты на реализацию функционала. Команда разработки тогда была небольшой – всего около 6 человек, для такого размера компании было ок.
Основным источником новых функций в продукте пока еще оставалась экспертиза генерального директора. Его опыт позволял внедрять достаточно востребованные решения. Из его идей и формировался план, а все остальное – бралось «сверху».
Мы делали почти все, что к нам поступало, это помогло на ранних этапах укрепить доверие клиентов – многие из них оставались с нами.
Попытки структурировать процесс: еженедельные встречи и стори поинты
Число клиентов росло, команда тоже, а мы столкнулись с увеличением нагрузки и резким развитием отраслей, в которых варились. IT менялась, появлялись новые инструменты, AI-решения, а некоторые сервисы, которые мы использовали ранее (например, Confluence и Jira), наоборот, стали недоступны. В строительной отрасли выросли требования к качеству, скорости и аналитике, клиенты стали требовательнее. Они уже успели познакомиться с чем-то лучше Excel и хотели получить «таблетку от всех болей». Им нужно было решение, которое и закупки проконтролирует, и ЭДО подтянет, и склад автоматизирует. А у нас за плечами был монолит, который не так просто подстраивать по первому требованию даже крупных клиентов.
Здесь мы поняли, что пора что-то менять: процессы не были оптимальны для большой команды, старый подход перестал работать, возникли проблемы с приоритизацией обращений и оценкой нагрузки на команду, с некоторыми задачами мы сталкивались впервые.
Мы внедрили еженедельную встречу, на которой присутствовали сотрудники отделов внедрения ПО и технической поддержки, исполнительный директор и генеральный директор, который все еще был единственным продакт-менеджером. Состав определялся задачей – лучше понять клиентов и оценить реальную необходимость реализации того или иного функционала. Некоторые фичи были актуальны только для одного точечного клиента, бизнес-процессы у строительных компаний отличались, поэтому разбирать было что. Тратить время на разработку и менять продукт под одного клиента для всех нерационально.
На встречах мы обсуждали поступившие запросы, определяли приоритеты и решали: брать и делать или отказать. В случае отказа мы искали альтернативные решения для клиента, чтобы минимизировать неудобства и попросту его не потерять.
И стоит сказать, что вот на этом этапе уже начали возникать споры внутри состава.
Немного техники: тогда мы использовали Jira (которую позже по понятным причинам заменили на Yandex Tracker) – это помогло сделать разработку более структурной. Задачи начали оценивать в стори поинтах, а работу организовали спринтами. Мы получили возможность точнее прогнозировать объем работы, эффективнее распределять ресурсы команды и отслеживать прогресс по ключевым задачам. Стори поинты мы, кстати, позже монетизировали, но об этом в блоге компании расскажут коллеги, которые поделятся опытом работы с enterprise-клиентом.
Сбор доработок реализовали через тикет-систему, где использовался один из первых разработанных нами шаблонов. Это позволило стандартизировать процесс сбора информации, и сделать его более прозрачным для всех участников.
Технический совет: заставили совещаться и разработчиков
С усложнением запросов и появлением задач, связанных с интеграциями, стало понятно, что для принятия решений уже недостаточно обсуждений, нужна более глубокая оценка, значит, нужны технические специалисты.
Функционал программы был достаточно обширным: он охватывал процесс закупок от закладывания смет по проекту до этапов согласования материалов и счетов и приемки поставок на объекты. Многие изменения могли затронуть узкие места системы и существенно увеличить нагрузку на мощности. Например, был запрос на поиск по всем полям сущностей, которых было больше всего в проекте, но на тот момент мы еще не внесли необходимых изменений для масштабирования поискового механизма, и такая доработка требовала обсуждения с технической командой, которой во встрече раньше не было.
Это же касалось интеграций: если с 1С мы уже были знакомы, то при запросах на более нестандартные системы приходилось изучать их API и оценивать сложность запрошенной интеграции. Кроме того, мы развивали и собственный API продукта, и каждый новый запрос требовал анализа его влияния на систему.
Еженедельную встречу по сбору и первичному согласованию доработок хотелось сохранить и оставить компактной при этом. Поэтому мы внедрили второй этап – так называемый «Технический совет» с участием команды, собранной из продакт-менеджера, технического директора и лидов разработки и тестирования. Они решали:
Возможно ли реализовать запрошенный функционал?
Как доработка повлияет на нагрузку системы и ее производительность?
Сможем ли мы реализовать запрошенную интеграцию? Какие ресурсы для этого потребуются?
Такое решение разделило процесс на два этапа, один фокусировался на бизнес-целях, второй – на технической стороне. Это позволило осуществлять проверку возможности реализации доработки до передачи ОС клиенту, а также утвердиться во мнении, что это то, что действительно нужно и возможно.
Здесь же мы учились отказывать.
Работали над ошибками
Компания продолжала расти: появились аналитики, сотрудники отдела внедрения были разделены на группы с собственными руководителями. Количество мнений множилось вместе с количеством людей, поэтому было принято решение – сокращать состав.
Оставили только руководителей отделов, аналитиков и продукт-менеджера на первом этапе. Шаблон сбора информации переработали и актуализировали под новые требования. Это сказалось и на скорость обсуждений, и на их содержательность, при этом в объемах реализации задач мы не потеряли. Да и необходимость представлять доработки от своего отдела, а не от себя лично фоново создала первый ценз – любой запрос проходил оценку на осмысленность еще среди отдела внедрения.
Утонули ли в кастомных запросах?
Помимо запросов доработок от клиентов мы проверяем и свои гипотезы. Например, несмотря на то, что в большинстве строительных компаний работают в офисах за компьютерами, а мобильные приложения используются редко – мы продолжали развивать мобильный функционал. Мы были убеждены, что часть процессов требует оперативного доступа к данным в мобильном формате, например, согласование закупок на строительные объекты или мониторинг статусов заявок.
Гипотеза о востребованности мобильного приложения изначально вызывала вопросы, но чем больше функций мы переносили в мобильное приложение, тем выше становился отклик — клиенты стали отмечать удобство работы для сотрудников, которые часто находятся в режиме перемещения между объектами. Это дополнило наше мировоззрение – иногда мы действительно знаем лучше.
Неотъемлемой частью процесса с самого начала являлась и остается постоянная связь с клиентом на всех этапах работы. Даже когда доработка не согласовывается, мы сообщаем клиенту о причинах отказа и предлагаем альтернативные варианты. Это позволяет нам сохранять доверие клиентов, что, конечно, сказывается и на успехе продукта на рынке в целом. Но с другой стороны, уходить только в кастом – гиблое трудозатратное дело. Комбинация подходов помогает нам оставаться на рынке и не перегружать внутренних специалистов.
Что сработало:
Разделение обсуждений на бизнес- и техэтапы
Помогло отделить «хотелки» от реальных возможностей, сократило количество спорных решений.Шаблон для сбора запросов
Стандартизировал ввод информации, избавил от «серых зон» и позволил быстрее оценивать запросы.Формализация ролей и ответственности
Снижение количества участников обсуждений → рост фокуса и ответственности за предложения.Коммуникация с клиентом даже при отказе
Поддерживает лояльность, даже если реализация невозможна. Клиенты чувствуют участие.Собственные гипотезы – не менее важны
Некоторые продуктовые идеи сначала казались спорными, но в итоге доказали свою ценность.
Надеюсь, наш опыт покажется кому-то полезным или подсветит возможности, которые еще не реализованы в вашей компании. Продуктовыми нюансами статью грузить не хотелось, если что-то упустил, c радостью расскажу в комментариях. А вы берете в работу фичи от клиентов?