Иван Лощёнов

CMO в Nutnet

Симулякр итогов с Ural Digital Weekend 2023

С 3 по 5 августа провел с коллегами в Перми на Ural Digital Weekend 2023. Ничего не ждал и был удивлен уровнем организации, фестивальной атмосферой и кучей топов из заказной разработки.

Чтобы не пропало, делюсь заметками с поездки:

Общее

  1. Важность препати на профильных конференциях была мною сильно недооценена
  2. Критически важно выходить с уровня бизнес-заказчика на уровень топ-менеджеров и владельцев, чтобы не терять контакт с клиентом из-за смены менеджмента. И в дополнение — регулярно собирать обратную связь от топ-менеджеров и владельцев, чтобы реально оценивать ценность которую вы доносите до бизнеса клиента
  3. Отчеты для T&M-контрактов можно делать на BI — реалтайм-обновление и полная прозрачность
  4. Первый месяц можно продавать по постоплате, чтобы снизить риски клиента (интересная мысль, но не сталкивался с таким возражением на пресейле)
  5. Мало экспертизы на этапе продажи не бывает

Разработка своих продуктов

  1. Значимые тренды рынка энтерпрайз-систем
    • Освободилась существенная доля рынка из-за ухода зарубежных продуктов (нужны замены ушедших систем)
    • Технические тренды: микросервисы, lowcode/nocode стек, RPA
    • Господдержка импортозамещения
    • Самописные внутренние разработки крупных игроков
    • Риски потери кадров (релокация, конкуренция за ИТ-кадры)
    • Новые продукты крупных российских интеграторов
    • Монетизация собственных решений
  2. Не получится сделать продукт из готового решения, которое разрабатывалось под конкретного заказчика. Но для поиска «болей» рынка и формирования плана по развитию такого продукта можно использовать привычный Jobs To Be Done и мало известный Pain Chain
  3. Почему здорово делать продукт с клиентом:
    • Глубочаяшая отраслевая экспертиза
    • Выходы на всех ЛПР в отрасли
  4. Почему клиенту здорово делать продукт с агентством:
    • Экспертиза в разработке
    • Умение продавать ИТ-решения
    • Понимание того что такое клиентский сервис в ИТ (продукт может требовать внедрения)
    • Гибкость (агентство всегда меньше и быстрее)
  5. Обратная сторона продуктовой разработки
    • Очень сложно найти первых клиентов, свою кор-аудиторию
    • Высасывает ресурсы (деньги и людей)
    • Размывается фокус внимания
    • Расходы сложнее планировать
    • Расхолаживает команду, после клиентских проектов
    • Сложно контролировать команду, если делаешь продукт бенчем (так не надо делать)
  6. Рекомендации по организации запуска продукта
    • Жестко фиксировать этапы и бюджеты на свои продукты. Будьте готовы потерять эти деньги
    • Учитывайте все затраты на разработку, в том числе косвенные затраты и упущенную прбыль
    • Подумайте как будете использовать продукт, если он не взлетит
    • Выделенная команда и четкие роли в ней
    • Выделен ответственный за продукт (визионер) с четкими, прописанными KPI. Найдите человека, который будет думать о продукте всё время (не пол дня).
    • Ответственный за продукт — не просто продакт, это драйвер процесса. Зачастую это должен быть СЕО\СОО\партнер — очень замотивированный предстаитель отдельного бизнес-юнита. Поэтому начать стоит с драйвера, тогда будет все чуть проще.
    • Относитетсь к продукту как к заказчику своего агентства.
    • Четко поставлены цели: smart, harvest, mece
    • Продукт и основной бизнес не соперничают друг с другом
    • 10 раз убедиться что за продуктом стоит реальная боль, а не фантазии (даже если это фантазии самых главных людей в компании). Убедитесь, что сфера продукта близка вашему агентству
    • Проработайте бизнес-модель, не смешивайте ее с агентской моделю
    • Рассказывайте о продукте и том, как его делаете
  7. С какими клиентами будет сложно прийти к продуктовой разработке:
    • Если нет процессов продуктовой разработки или текущее понимание больше на стороне заказчика
    • Работаем по спринтам, но не видим смысла в бизнес-аналитике или системном аналитике. Заказчик не подпускает подрядчика к внутренней кухне, работаем в режиме черного ящика (ВА, привет)
    • Продукт не совсем продукт, не приносит ценности бизнесу, обречен на правал
  8. С какими клиентами возможно прийти к модели продуктовой разработки:
    • Если у заказчика есть фреймворк продуктовой разработки и он внедрен хотя бы частично
    • Заказчик понимает ценность продукта и имеет план развития
    • Заказчик умеет пользоваться всеми инструментами аутсорса
  9. Если продукт не развивается — не увеличивается бюджет на его развитие.
  10. Как устранить раскол между ИТ и бизнесом — путь к успеху агентства:
    • Не пытаться занимать только одну из сторон (важно всё и сразу: делать важные для продукта задачи, по правильному процессу и быстро, чтобы бизнес возвращать инвестиции)
    • Объяснять бизнесу почему в долгосрочной перспективе нужно учиться слыть ИТ: архитекторов, лидов и СТО
    • Снабдить ИТ бизнесовой фактурой для продажи своих позиций, сделать ИТ-метрики управляемыми
    • Помочь ИТ лучше отвечать требованиям бизнеса, а бизнесу предоставить для ИТ требования в понятном виде
  11. Фреймворк продуктовой разработки, который должен настраиваться и постоянно адаптироваться, чтобы минимизировать ТТМ:
Этап Бизнес-инициатива или гипотеза Оценка и приоритизация Бизнес-анализ Системный анализ Разработка
Кто Кто угодно: стейкхолдеры, СЕО, владелец продукта Лид разработки, БА, Владелец продукта БА, Владелец продукта, РП, ITBP, стейкхолдеры Лид разработки, Владелец продукта, РП Лид разработки, РП
С каким результатом Сделаем что-то что сделает продукт более ценным для потребителей с целью увеличения бизнеса Понимаем сложность и сроки в попугаях, понимаем профит, приоритизируем Декомпозированные бизнес-требования, CJM, EJM, описанный бизнес-процесс. Дизайн, UX, ограничения Техническое решение, декомпозиция задач, в том числе по системам, беклог готовых, оцененных и готовых к разработке задач Задачи в рамках изначальных БТ, готовые к релизам (или UAT\AB\E2E) во всех системах
Пример Если мы автоматизируем процесс оформления заказа — улучшим SLA дял клиентов, сэкономим Х рублей на операционных затратах Клиенты смогут оформить заказ в любое время суток, бизнес сэкономит и высвободит операционного ресурса на 20 млн в год Осознание, что требуется доработка в 5 бэкенд-системах, юридические и финансовые аспекты улажены, готов дизайн, описан процесс, посчитан P&L Эпик или сторя, в который собраны все задачи с оценками. Осталось только положить в спринты по системам согласно приоритетам Команда разработки готова провести демо нового функционала бизнесу и готова к отгрузке на бой

Команда

  1. Для создания эффективной команды нужны единая цель, где каждый преследует цель компании и взаимодействует друг с другом
  2. Почему командная работа решает на уровне задач Complex (об этом чуть ниже):
    • Делает возможным решение задач, что не под силу одному человеку
    • Является гарантией, что будут учитываться интересы всех сторон
    • Понижается риск принятия ошибочных решений
    • Помогает бороться с производственной слепотой
  3. Чтобы у команды появилась сопричастность к происходящему, сопереживание проблемам, поддержка и продвижение изменений, повышения доверия и генерация идей — она должна быть плотно интегрирована в то, что у компании происходит и наоборот. Для этого существует точки для сбора и передачи информации, дальше об этом
  4. Какие могут быть точки для сбора информации:
    • 1-2-1 RM
    • 1-2-1 HR
    • 360
    • Командные встречи
    • Чаты
    • Эскалации
    • Perfomance review
    • Проектные ретро
    • Неофициальные встречи
  5. А какие системы передачи информации:
    • Планерки топов (еженедельно)
    • Планерки менеджмента (каждые 2 недели)
    • Планерки отделов (каждые 2 недели)
    • Общая встреча компании (квартальные, годовая)
    • Мероприятия по изменениям
    • Личные встречи
    • Дополнительные: почтовые рассылки (nda\not nda), телеграмм-канал, общий чат в телеге, сессии Q&A.
  6. О чем компания может делиться с менеджментом:
    • Всё и максимально открыто
    • Продавать прототипы изменений и собирать обратную связь
    • Просить задавать неудобные вопросы
    • Рассказывать о возможностях и искать лидеров
    • Показывать проблемы и искать совместные решения
  7. О чем компании стоит делиться со всеми:
    • Об изменениях (которые уже поддерживает менеджмент)
    • Проблемы — с решениями от менеджмента
    • Возможности — с запросом на участие
    • Выручку, прибыль — в процентах

Проекты

  1. Каскадная модель производства драматически снижает вероятность успеха проекта
  2. Cynefin framework https://ru.wikipedia.org/wiki/Cynefin_framework — как концептуальная основа для принятия решений:
    • Obvious. Применяйте «Best Practice». Задачи ясны, решения очевидны, следуйте установленным процедурам.
    • Complicated. Применяйте «Good Practice» или экспертные мнения. Возможно несколько правильных решений
    • Complex. Проведите эксперименты и используйте «Emergent Practice». Тут нет очевидных решений, выясните правильный подход через пробу и ошибку.
    • Chaotic. Действуйте сразу для стабилизации ситуации, затем изучайте и отвечайте на изменения. Нужно немедленно действовать.
  3. В разработке нетиповых решений часто приходится решать задачи уровня Complicated и Complex, поэтому взвешивайте решения. Complicated — это граница проектной деятельности, начиная с Complex — это задачи в зоне эмпирической деятельности, а значит мы не можем говорить о каскадной модели и вотерфоле для таких решений. Это всё Симулякр плана, как выразился Глеб Михеев :-)
  4. Иногда стоит принять, что ты не можешь определить точные требования и вместо требований определить цель и ключевые результаты (это, кстати, пересекается с тем что говорят ребята из Бюро про ФФФ). Это зона неопределенности, её невозможно спланировать. Это зона командной работы.
  5. Что пропагандирует аджайл:
    • Люди и взаимодействие важнее процессов и инструментов
    • Работающий продукт важнее исчерпывающей документации
    • Сотрудничество с заказчиком важнее согласования условий контракта
    • Готовность к изменениям важнее следования первоначальному плану
  6. В аджайле развитие. Аджайт создает продукт, ватерфолл его воспроизводит
  7. Немного о концепции Run-Change-Disrupt

На кого подписался после конфы

  1. https://t.me/panfilovonline Пишет про запуск digital-проектов и IT-инструменты для бизнеса
  2. https://t.me/rukovozhu Виктор Рындин: CEO @Wemakefab & @Dprofileru
  3. https://t.me/tired_glebmikheev Глеб Михеев, просто поток сознания на стыке менеджмента и ИТ, я влюбился
  4. @dpletnev. Дима Плетнев. Но он ничего в паблик почему-то не пишет, приходится писать в личку
  5. https://t.me/successfulproduct Сергей Пращенко, про продакт дискавери вообще и в энтерпрайзе в частности (самый недооцененный доклад, потому что было жутко интересно, но все выдохлись)

Ну и посмотрите запись трансляции, очень много достойных лекций:

Нетворкинг на GASTREET 2023

С 5 по 7 июня провел на восьмом GASTREET в Красной поляне. Делюсь заметками по разработке для ресторанов и опытом нетворкинга.

Заказная разработка для ресторанного бизнеса

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

У большинства очень схожие проблемы: не считают маркетинг, нет метрик для принятия быстрых решений (или они не на поверхности), автоматизация из коробки закрывает не все потребности, регулярные технические проблемы с iiko или r-keeper.

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

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

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

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

Специализация окупается. Вот, например, Lemma — интегратор в хореке, работает со средней ставкой около 5000 Р. Это примерно в 2 раза выше средней ставки в заказной разработке.

Рекомендации по нетворкингу для будущего себя

  1. Если едешь на часть мероприятия, лучше ехать ближе к концу, чем началу. В первые дни люди в себе и в людях с которыми уже знакомы.
  2. Первичные договоренности по встречам работают: из 9 встреч состоялось 6. Это те встречи о которых команда договорилась на берегу. О таких встречах договаривалась команда, но кажется что личные договоренности сработают лучше — так будет больше доверия и ближе контакт.
  3. Работает общение после доклада: со спикером и его аудиторией. Часто в этих кулуарах звучат вопросы, которые подсвечивают проблемы. А проблема — это возможность поделиться опытом, предложить решение, познакомиться.
  4. Работает задавание вопросом с подсвечиванием экспертизы и предложением собраться и обсудить тему после мероприятия. В мобильном приложении мероприятия это будет сделать еще проще. Примеры: раз, два
  5. Работают чаты мероприятия. Там легко «продать» бесплатную консультацию, особенно если это отраслевое мероприятие по какой-то теме. Пример.
  6. Постарайся не летать ночью в целях экономии времени, экономия будет условная, а для знакомств и продуктивного общения нужно много энергии.

MVP как стратегия

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

Ограничьте контур MVP только ключевой ценностью

Потратьте время, но поймите лучше основной сегмент ЦА, того кто будет первым пользователем:

  1. Запускайте продукт для лояльных пользователей, клиентов или сотрудников. Нет смысла запускать на всех потенциальных пользователей, выберете самую лояльную группу или важный сегмент
  2. Проверьте что у них есть настоящая проблема и они это осознают. Как это сделать:
    — они активно ищут решение
    — они как-то сами пытаются решать её
    — у них есть возможность платить за решение
  3. Зафиксируйте контур продукта: проставьте приоритеты сценарии своего ключевого сегмента ЦА
  4. Не обсуждайте функциональные возможности продукта. Говорите сначала про задачи, ключевые действия и ценности, а только потом трансформируйте это в решение. Грубо говоря, пользователю не нужен личный кабинет, ему нужно список избранного видеть.

Отделите срок запуска продукта от срока разработки продукта

  1. Если продукт сложный и первые версии MVP — это кожа и кости, не запускайте его на клиента
  2. Следуйте стратегии, презентуйте версии продукта выкладывая ценностные фичи частями на ограниченную аудиторию. Например, в таком порядке:
    1. Проектная команда и бизнес-заказчик\клиент\инвестор
    2. Ключевой сегмент из прошлого совета
    3. Рынок

Синхронизируйте бизнес и разработку

  1. Никогда не планируйте маркетинговые активности: рекламу, посевы, блогеров и конференции впритык к окончанию разработки, которое уже вот-вот, буквально через неделю.
  2. Если бизнес и разработка существовали после первого релиза продукта, они должны знать друг про друга «до».

Перейдите к коротким интеграциям разработки

Почему это важно и хорошо работает:

  • Сможете управлять приоритетами (а ими придется управлять)
  • Не потратите драгоценные месяцы на аналитику
  • Не будете придумывать реализацию того, что изменится за следующие 3-4 месяца
  • Это самый простой способ уменьшить вероятность «обосраться» в два раза (где-то до 50%)

Избавьтесь от лишнего

Сложный функционал портит продукты, откажитесь на старте от всего, что не укладывается в ключевой сценарий основного сегмента:

  1. Часть идей можно не реализовывать, а реализовать в том виде, который бы проверял спрос или собирал обратную связь от пользователей.
  2. Дайте якобы полноценный продукт, но без излишней автоматизации внутри. Автоматизация это дорого, а автоматизация необкатанных процессов — очень дорого.
  3. Импровизируйте: сделайте промо-сайт на Тильде, емэйл-рассылку на сендпульсе, онлайн-оплату на стандартном эквайринге. Используйте лоукод-платформы и готовые решения, если можете.

Начинайте с узких мест

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

Вместо вывода

Не забывайте: пока мы что-то делаем на дев-серверах, пользователи и бизнес ждут перемен!

P.S.: Кстати, я иногда выступаю на конференциях.

Выступаю на конференциях

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

Делюсь опытом на темы:

  • заказная разработка
  • разработка и развитие продуктов
  • управление веб-проектами
  • отношения с клиентами в сервисном бизнесе

С отдельным удовольствием приеду в Ульяновск или Самару.

Прошедшие

  1. MVP как стратегия, Мастерская маркетинга Андва, 2023
  2. MVP как стратегия, IT Summer Camp, 2022
  3. Ничего нового про коммуникацию, Прожектор, 2019
  4. Экономика проектов в заказной разработке, Прожектор, 2018
  5. Давайте поговорим о проектах на примере сайта «АСПЭК-Авто», What the FAQ is WEB-design, 2014
  6. Ирония судьбы или удаленная работа, IzhDevCom, 2012

Вопросы и предложения

  • Telegram: loshenov
  • Эл. почта: ivan@loshenov.ru

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

Со временем любой глаз замыливается, подход в принятии решений встаёт на рельсы и становится рафинированным.

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

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

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

Как игра в «глухие телефоны» чуть не стоила нам крупного клиента

Сообщение от партнера, который узнал про ситуацию на проекте

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

Обычно собственники и руководители компаний понимают, чего хотят от инвестиции в ИТ-проект. Они видят в нем ценность и хотят, чтобы вложения в него окупились. С ними легко говорить на языке бизнеса, они формулируют конкретные задачи — например, увеличить объем продаж в X раз.

Иногда заказчику трудно сразу обозначить свои цели и четко сформулировать их. Тогда мы помогаем ему — задаем наводящие вопросы.

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

В таких случаях мы стараемся сэкономить ресурсы заказчика и время нашей команды: просим контакты собственников бизнеса и выясняем истинные цели проекта. Этот принцип мы выработали в процессе коммуникации с компанией «Витязь-Аэро».

Почему важна роль бизнес-заказчика в ИТ-проекте

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

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

Кроме того, в системе изначально было много проблем в функционале: например, плохое изначальное проектирование и невыстроенная система тестирования и модификации кода. Со временем АИС перестала отвечать растущим потребностям компании.

В конце 2019 года «Витязь-Аэро» захотели увеличить темпы разработки. Дополнительно нужно было развить функционал системы, ускорить трек поддержки и увеличить скорость реакции для исправления критичных дефектов. Чтобы закрыть эти потребности, в «Витязь-Аэро» решили сменить подрядчика и обратились к нам.

Проблемы в коммуникации с клиентом

Не надо так

Коммуникация с клиентом складывалась непросто: на разницу в местонахождении и часовом поясе (+8 часов) накладывались и другие сложности. Например, с начала сотрудничества у нас не было прямого контакта с бизнес-заказчиками — собственниками, которые хорошо представляют цели разработки и желаемый результат. Мы связывались с ними через руководителя проекта. Это был сотрудник компании, который не мог знать столько же, сколько бизнес-заказчики, несмотря на проактивную позицию в работе. Из-за этого в нашей коммуникации появилось несколько проблем:

* Менялись приоритеты, о чем мы поздно узнавали. Например, нам приходила задача, которую надо было выполнить срочно. Мы тратили на нее время, а по готовности оказывалось, что она уже не нужна.
* Возникали недопонимания при постановке задач. Оказалось, что обсуждать задачу без прямого контакта с бизнес-заказчиком — сложно. Это было похоже на игру в «глухие телефоны»: собственник давал нам задание через руководителя проекта, а мы получали его искаженным или неполным. При этом не было возможности быстро уточнить, что значительно увеличивало сроки исполнения. В итоге при релизе демоверсии получалось, что с продуктом все не так — результат не совпадал с ожиданием бизнес-заказчика.

***

Например, нам ставили задачу — настроить онлайн-оплату для реализации электронных билетов на сайте.

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

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

Момент оказался поворотным — мы решили организовать переговоры с непосредственными руководителями «Витязь-Аэро».

Переговоры и изменения в порядке работы

Из-за возникшей коллизии мы встретились с бизнес-заказчиками. В ходе переговоров мы:

  1. Воссоздали моменты нашей коммуникации с самого начала, чтобы проверить, кто какой информацией владеет.
  2. Обозначили проекты, которые мы ведем: поддержка и развитие АИС, поддержка существующего сайта «Витязь-Аэро» и разработка нового.
  3. Познакомили с нашей командой и рассказали об объеме задач у каждого сотрудника — чтобы клиент понимал, что в проекты вовлечено много человек.
  4. Презентовали результаты работы за последние 6 месяцев.
  5. Рассказали, на каких стадиях находятся поставленные задачи.
  6. Наметили будущие приоритеты и проблемы, из-за которых могут сдвинуться сроки.
Колесо проектного взаимопонимания

Также мы проанализировали коммуникацию с «Витязь-Аэро» и предложили варианты, как предотвратить проблемы в будущем. Самым важным было подключить бизнес-заказчика к ключевым процессам разработки. Договорились о следующем:

  • Внедрили ежемесячные демо. Подключали руководителей и заинтересованных участников со стороны заказчика, чтобы совместно продемонстрировать и принять новый функционал в дев-окружении. Сбор обратной связи здесь и сейчас упрощал коммуникацию с двух сторон и позволил учитывать ожидания заказчика. Также это погрузило руководителей в процесс разработки и дало понимание, почему готовы или нет те или иные инструменты;
  • Договорились о стратегических совещаниях раз в 3—6 месяцев. Это помогло увидеть горизонт работы и определить приоритетные задачи в следующие 6—12 месяцев. Выделили несколько направлений: развитие и поддержка продукта, а также фиксация проблем в автоматизированной системе.

Выстроенная коммуникация позволила сохранить сотрудничество и быстрее выполнять задачи клиента. Объем работ многократно вырос, а time-to-market, время за которое идеи реализовывались и становились доступными для пользователей, сократилось в 2 раза.

Где участие бизнес-заказчика обязательно

Работа с «Витязь-Аэро» показала, что общаться только с руководителем проекта по поводу целей и результата сложно. При такой коммуникации мы упускали из виду приоритеты бизнес-заказчика, подолгу выясняли тонкости его работы и не получали адекватную обратную связь. В итоге понимание задач было неполным, они долго выполнялись — получалось, что бюджет компании тратился без видимого результата.

Это позволило синхронизировать бизнес и разработку

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

  • Формирование бэклога — определяемся со списком задач с описанием, оценкой и приоритетами;
  • Утверждение скоупа — согласовываем список задач, которые точно должны попасть в следующий релиз;
  • Тестовая эксплуатация — демонстрируем результат работы клиенту.

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

Иммунитет от провальных продуктов

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

Планёрка в Nutnet

Без розовых очков

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

Часть клиентов приходит к нам с призрачной идеей и горящими глазами. Они верят, что проект «полетит» и оправдывают космические расходы времени, денег и энергии. В основном, это не прорывные идеи: ещё один profi.ru со своей специализацией или мобильное приложение с геолокацией — чат для тех, «кто рядом». Смотрю на это, как на еще один запрос из тысячи.

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

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

«Бэк-офис — это 70% успеха»

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

Все успешные и провальные проекты зависят не от сайта, а от команды. Красивый, современный сайт — это 30% успеха, остальные 70% зависят от работы бэк-офиса. Это владелец, операционные-менеджеры, менеджеры по работе с клиентами — люди, которые обеспечивают внутренние процессы. Мы можем разработать очень удобный сервис, но если менеджер вовремя не ответит или нагрубит клиенту, все напрасно.

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

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

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

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

MVP

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

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

Условная разработка стоит 2 миллиона рублей. А запустить страницу на тильде, рекламу на узкий сегмент и протестировать спрос — 100 тыс рублей. Нужно собирать информацию от потенциальных клиентов, а не от вымышленных персонажей или друзей. Позвоните потенциальным клиентам, поговорите с представителями рынка — развейте фантазии до старта.

Хороший пример — Фиксби. Мы работали в партнерстве с MVPLab. Ребята проработали идею, мы занялись технической стороной. Первую версию запустили за месяц и занялись итерационным развитием: доработали интеграции, систему управления, протестировали разные варианты страницы услуг. Сработали на отлично.

Поддержка и развитие

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

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

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

Контроль окружения проекта

Окружение проекта — это его активы: код, дизайн-макеты, различные регламенты и уставы, документация, инфраструктура: тестовые и прод-сервера, системы мониторинга и деплоя, домен.

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

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

Выводы

  • Прежде чем тратить большие ресурсы, подумайте, как протестировать идею за бесплатно или с небольшими вложениями.
  • Реализация — это лишь старт и верхушка айсберга. 70% успеха зависит от бэк-офиса.
  • С людьми работают люди. Самый красивый и удобный сайт не принесет прибыль, если менеджер грубиян, а клиенты «дураки».
  • Не забывайте про прямой контакт с потенциальными клиентами, рекламу, поддержку и развитие проекта
  • Контролируйте активы проекта. Это напрямую влияет на жизнеспособность проекта.

Первая заметка

Заметка, которая напоминает о времени, когда был создан сайт

 Нет комментариев    421   2008