Правила и методы разработки продукта: как привлечь и удержать клиентов

Три главные роли в ИТ

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

Первая роль — product-менеджер. Это человек, который управляет замыслом, четко видит, какую «боль» клиента продукт решает и какую ценность приносит. Он отвечает на вопрос «Зачем мы это делаем?». Этот человек должен обладать развитыми soft skills (с англ. «гибкие навыки» — «Хайтек»), чтобы чувствовать потребности клиентов, выстраивать общение с командой разработки, продаж и маркетинга. Такие навыки сложно измерить, но есть ряд практик, которые помогают их применить и создать в результате нужный клиенту продукт: знание в области user eXperience (UX), аналитики, позиционирования сделанного, а также способы изучения целевой аудитории и навыки ведения экспериментов.

User eXperience, с англ. «опыт пользователя, опыт взаимодействия» — это восприятие и ответные действия пользователя, возникающие в результате использования и/или предстоящего использования продукции, системы или услуги.

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

Второй человек — главный инженер или, по-другому, CTO — технический директор. Этот человек отвечает на вопрос «Как мы это сделаем?». У него должны быть навыки в области программирования и управления — если компания будет расти, его роль постепенно сместится: он будет меньше работать руками и больше управлять командой. Пригодится знание ИТ-ландшафта в целом и понимание, какие технологии, специалисты, алгоритмы, подходы нужны для выполнения конкретной задачи. У него должен быть широкий ИТ-кругозор, обязательный для этой должности даже на входе.

Третий человек — ответственный за маркетинг и продажи. В начале пути эти области могут совмещаться. Такой специалист отвечает на вопрос «Кому и как мы продадим наше решение?». Набор навыков здесь различается в зависимости от того, работает он на B2C- или B2B-рынке. В B2B нужны прежде всего опыт и «набитая рука» в этой области. Набор специальных навыков даже менее важен, чем опыт.

Основные шаги в разработке

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

Следующий этап не менее важный — внедрение продукта внутри компании клиента, так как мы говорим о рынке B2B.

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

Составление техзадания: как не перепутать роли

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

Technology Roadmap, с англ. «технологическая дорожная карта» — краткосрочный или долгосрочный план выпуска производителем какого-либо продукта. Чаще всего это новая версия или развитие уже известного продукта, изменений в котором ждут потребители. Технологическая дорожная карта может содержать средства, подходы или пути, необходимые для достижения поставленных вех.

Project-менеджер ведет проект у конкретного заказчика и делает так, чтобы ваш продукт максимально удовлетворял уникальную потребность конкретного клиента. Его работа начинается с предпродажи, он управляет замыслом проекта, составлением ТЗ, ведет шаг за шагом проектную работу и отвечает за конечное внедрение.

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

Следующий шаг: «управление счастьем клиента»

На этом этапе есть несколько уровней:

• Первый — стандартный пакет услуг, в рамках которого вы предоставляете SLA (Service Level Agreement), то есть соглашение об уровне обслуживания. В нем важно отметить, насколько быстро вы реагируете на запрос клиента, какой объем услуг можете оказать ему, что в этот перечень услуг входит. Обычно это четко регламентировано и описано.

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

Способы исключить ошибки при разработке

1. Самое главное — не ошибиться в людях при найме. В разработке ПО единственно важный, стоящий и приносящий вам пользу актив — сотрудники. И на первых порах главное правильно их подобрать.

Как правильно собрать команду для ИТ-компании

• На первых этапах подбора нужно ответить себе честно на вопрос, обладаете ли вы необходимыми компетенциями, чтобы оценить профессионализм кандидата. Можете ли вы положиться на рекомендации знакомых, обладают ли они компетенциями в вашей сфере бизнеса? При подборе нужно разделять эмоции и факты — нанять обаятельного, но некомпетентного сотрудника будет ошибкой.

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

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

В) Важно, чтобы сотрудники умели принимать обратную связь и реагировать на нее. Отсутствие этого дает понять, что в будущем с этим человеком не получится комфортной и продуктивной работы.

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

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

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

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

4. Неверные технические решения и накопление технического долга. Это могут быть решения, прекрасно функционирующие сейчас, но мешающие развитию в будущем. Например, нужно отправить клиенту при регистрации письмо, но текст записан в программный код и внести изменения в нем может только программист. Когда вы разрабатываете ПО, всегда есть выбор — сделать быстро или качественно, чтобы это в будущем не принесло проблем. Как правило, выбирается компромисс, и как бы вы ни вели разработку, технический долг накапливается. Важно управлять этим процессом и вовремя ликвидировать неточности. Если об этих нюансах забыть, то через несколько лет компания может стать недееспособной.

5. Игнорирование вопросов по управлению качеством. Качество — это то, что заставляет клиентов возвращаться к вам снова и снова. Недостаток внимания в этом вопросе обернется трудозатратами и потерями денег в будущем. Например, вы не написали тесты в коде, что сэкономило условный час времени. Через месяц, внося доработки, вы потратите день, чтобы убедиться, все ли корректно работает.

Задания от project- и product-менеджеров сначала попадают в бэклог — общее хранилище всех задач. Оттуда выбирают самое важное и запускают в работу. Чтобы понять, какие задачи из бэклога нужно взять, команды договариваются о целях спринта. Этот процесс выглядит как торг, так как учитывается множество мнений. Но никакого другого волшебного пути приоритизировать задачи не существует.

Бэклог — это журнал оставшейся работы, которую необходимо выполнить команде. Термин пришел из семейства методологий Agile, в частности из Scrum, где он является одним из основных артефактов — источником пользовательских историй.

После этого происходит сам спринт — разработка функционала, тестирование, проверка качества, затем релиз и демонстрация продукта клиентам и другим командам.

Так, работа над решением «TalentTech.Адаптация» началась с идеи: мы изучали потребности рынка и увидели, что многим компаниям нужно охватить и оценить весь путь найма кандидата: от его поиска до первых этапов работы. На российском рынке уже есть решения для автоматизации подбора, обучения и постановки целей, но ничего не предусмотрено для адаптации сотрудника. Из-за такого пробела можно быстро потерять мотивацию и убить вовлеченность новичка, а значит в самом начале сделать из классного кандидата безынициативного неудовлетворенного сотрудника.

Предположим, вовлечь новичка в рабочий процесс не удалось — он уволился на испытательном сроке. Во что это вылилось бизнесу? Если рекрутер в ИТ-компании получает 100 тыс. рублей и от него ожидают закрытия четырех вакансий в месяц, а на наем одного человека ушло 1,5 месяца, то получится 37,5 тыс. рублей. Добавляем к этой сумме три оклада сотрудника с учетом налогов и отчислений, получается примерно 931 тыс. рублей, потраченных на одного сотрудника за 4 месяца. Сюда еще можно добавить стоимость рабочих часов наставников, команды, руководителей и бухгалтеров, а также затраты на оборудование рабочего места. А главное – эти затраты улетучились в никуда вместе с его увольнением, то есть бизнес несет значительные финансовые потери.

Мы провели исследование 27 компаний — потенциальных клиентов: спрашивали, где у них «болит» и какие потребности нужно закрыть. Выяснилось, что для многих компаний процесс адаптации — реальная проблема. Так, в одной компании, чтобы оцифровать онбординг, нужно сформировать целый отчет с графиками: сколько человек работают первый день, сколько подписывают документы, сколько проходят обучение. Для этого отделу обучения приходится обзванивать филиалы во всех регионах. Трудоемко, затратно и долго.

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

Проанализировав все эти «боли» клиентов на рынке и оценив возможность наладить процессы и сократить издержки, мы стартовали разработку приложения. Создать продукт и сразу же пилотироваться решили в рамках четырех компаний: ИТ, ритейл, сервисной и компании с онлайн-работой сотрудников. Их объединяло то, что в команде были распределенные сотрудники, с которыми сложнее вести коммуникацию.

Через 2,5 месяца мы запустили первый пилот, еще через месяц — второй. У нас была задача проверить, насколько продукт соответствует требованиям рынка. Перед запуском приложения в компании мы всегда определяем, на какие метрики хотим с его помощью повлиять: улучшение производительности, уменьшение затрат, повышение мотивации сотрудников и качество работы наставников.

Читайте также:

Выяснилось, что заставило цивилизацию майя покинуть свои города

Ученые раскрыли план герпеса по заражению человека: он похож на игру cо ставками

На 3 день болезни большинство больных COVID-19 теряют обоняние и часто страдают насморком