Симулякр итогов с Ural Digital Weekend 2023
С 3 по 5 августа провел с коллегами в Перми на Ural Digital Weekend 2023. Ничего не ждал и был удивлен уровнем организации, фестивальной атмосферой и кучей топов из заказной разработки.
Чтобы не пропало, делюсь заметками с поездки:
Общее
- Важность препати на профильных конференциях была мною сильно недооценена
- Критически важно выходить с уровня бизнес-заказчика на уровень топ-менеджеров и владельцев, чтобы не терять контакт с клиентом из-за смены менеджмента. И в дополнение — регулярно собирать обратную связь от топ-менеджеров и владельцев, чтобы реально оценивать ценность которую вы доносите до бизнеса клиента
- Отчеты для T&M-контрактов можно делать на BI — реалтайм-обновление и полная прозрачность
- Первый месяц можно продавать по постоплате, чтобы снизить риски клиента (интересная мысль, но не сталкивался с таким возражением на пресейле)
- Мало экспертизы на этапе продажи не бывает
Разработка своих продуктов
- Значимые тренды рынка энтерпрайз-систем
- Освободилась существенная доля рынка из-за ухода зарубежных продуктов (нужны замены ушедших систем)
- Технические тренды: микросервисы, lowcode/nocode стек, RPA
- Господдержка импортозамещения
- Самописные внутренние разработки крупных игроков
- Риски потери кадров (релокация, конкуренция за ИТ-кадры)
- Новые продукты крупных российских интеграторов
- Монетизация собственных решений
- Не получится сделать продукт из готового решения, которое разрабатывалось под конкретного заказчика. Но для поиска «болей» рынка и формирования плана по развитию такого продукта можно использовать привычный Jobs To Be Done и мало известный Pain Chain
- Почему здорово делать продукт с клиентом:
- Глубочаяшая отраслевая экспертиза
- Выходы на всех ЛПР в отрасли
- Почему клиенту здорово делать продукт с агентством:
- Экспертиза в разработке
- Умение продавать ИТ-решения
- Понимание того что такое клиентский сервис в ИТ (продукт может требовать внедрения)
- Гибкость (агентство всегда меньше и быстрее)
- Обратная сторона продуктовой разработки
- Очень сложно найти первых клиентов, свою кор-аудиторию
- Высасывает ресурсы (деньги и людей)
- Размывается фокус внимания
- Расходы сложнее планировать
- Расхолаживает команду, после клиентских проектов
- Сложно контролировать команду, если делаешь продукт бенчем (так не надо делать)
- Рекомендации по организации запуска продукта
- Жестко фиксировать этапы и бюджеты на свои продукты. Будьте готовы потерять эти деньги
- Учитывайте все затраты на разработку, в том числе косвенные затраты и упущенную прбыль
- Подумайте как будете использовать продукт, если он не взлетит
- Выделенная команда и четкие роли в ней
- Выделен ответственный за продукт (визионер) с четкими, прописанными KPI. Найдите человека, который будет думать о продукте всё время (не пол дня).
- Ответственный за продукт — не просто продакт, это драйвер процесса. Зачастую это должен быть СЕО\СОО\партнер — очень замотивированный предстаитель отдельного бизнес-юнита. Поэтому начать стоит с драйвера, тогда будет все чуть проще.
- Относитетсь к продукту как к заказчику своего агентства.
- Четко поставлены цели: smart, harvest, mece
- Продукт и основной бизнес не соперничают друг с другом
- 10 раз убедиться что за продуктом стоит реальная боль, а не фантазии (даже если это фантазии самых главных людей в компании). Убедитесь, что сфера продукта близка вашему агентству
- Проработайте бизнес-модель, не смешивайте ее с агентской моделю
- Рассказывайте о продукте и том, как его делаете
- С какими клиентами будет сложно прийти к продуктовой разработке:
- Если нет процессов продуктовой разработки или текущее понимание больше на стороне заказчика
- Работаем по спринтам, но не видим смысла в бизнес-аналитике или системном аналитике. Заказчик не подпускает подрядчика к внутренней кухне, работаем в режиме черного ящика (ВА, привет)
- Продукт не совсем продукт, не приносит ценности бизнесу, обречен на правал
- С какими клиентами возможно прийти к модели продуктовой разработки:
- Если у заказчика есть фреймворк продуктовой разработки и он внедрен хотя бы частично
- Заказчик понимает ценность продукта и имеет план развития
- Заказчик умеет пользоваться всеми инструментами аутсорса
- Если продукт не развивается — не увеличивается бюджет на его развитие.
- Как устранить раскол между ИТ и бизнесом — путь к успеху агентства:
- Не пытаться занимать только одну из сторон (важно всё и сразу: делать важные для продукта задачи, по правильному процессу и быстро, чтобы бизнес возвращать инвестиции)
- Объяснять бизнесу почему в долгосрочной перспективе нужно учиться слыть ИТ: архитекторов, лидов и СТО
- Снабдить ИТ бизнесовой фактурой для продажи своих позиций, сделать ИТ-метрики управляемыми
- Помочь ИТ лучше отвечать требованиям бизнеса, а бизнесу предоставить для ИТ требования в понятном виде
- Фреймворк продуктовой разработки, который должен настраиваться и постоянно адаптироваться, чтобы минимизировать ТТМ:
Этап | Бизнес-инициатива или гипотеза | Оценка и приоритизация | Бизнес-анализ | Системный анализ | Разработка |
Кто | Кто угодно: стейкхолдеры, СЕО, владелец продукта | Лид разработки, БА, Владелец продукта | БА, Владелец продукта, РП, ITBP, стейкхолдеры | Лид разработки, Владелец продукта, РП | Лид разработки, РП |
С каким результатом | Сделаем что-то что сделает продукт более ценным для потребителей с целью увеличения бизнеса | Понимаем сложность и сроки в попугаях, понимаем профит, приоритизируем | Декомпозированные бизнес-требования, CJM, EJM, описанный бизнес-процесс. Дизайн, UX, ограничения | Техническое решение, декомпозиция задач, в том числе по системам, беклог готовых, оцененных и готовых к разработке задач | Задачи в рамках изначальных БТ, готовые к релизам (или UAT\AB\E2E) во всех системах |
Пример | Если мы автоматизируем процесс оформления заказа — улучшим SLA дял клиентов, сэкономим Х рублей на операционных затратах | Клиенты смогут оформить заказ в любое время суток, бизнес сэкономит и высвободит операционного ресурса на 20 млн в год | Осознание, что требуется доработка в 5 бэкенд-системах, юридические и финансовые аспекты улажены, готов дизайн, описан процесс, посчитан P&L | Эпик или сторя, в который собраны все задачи с оценками. Осталось только положить в спринты по системам согласно приоритетам | Команда разработки готова провести демо нового функционала бизнесу и готова к отгрузке на бой |
Команда
- Для создания эффективной команды нужны единая цель, где каждый преследует цель компании и взаимодействует друг с другом
- Почему командная работа решает на уровне задач Complex (об этом чуть ниже):
- Делает возможным решение задач, что не под силу одному человеку
- Является гарантией, что будут учитываться интересы всех сторон
- Понижается риск принятия ошибочных решений
- Помогает бороться с производственной слепотой
- Чтобы у команды появилась сопричастность к происходящему, сопереживание проблемам, поддержка и продвижение изменений, повышения доверия и генерация идей — она должна быть плотно интегрирована в то, что у компании происходит и наоборот. Для этого существует точки для сбора и передачи информации, дальше об этом
- Какие могут быть точки для сбора информации:
- 1-2-1 RM
- 1-2-1 HR
- 360
- Командные встречи
- Чаты
- Эскалации
- Perfomance review
- Проектные ретро
- Неофициальные встречи
- А какие системы передачи информации:
- Планерки топов (еженедельно)
- Планерки менеджмента (каждые 2 недели)
- Планерки отделов (каждые 2 недели)
- Общая встреча компании (квартальные, годовая)
- Мероприятия по изменениям
- Личные встречи
- Дополнительные: почтовые рассылки (nda\not nda), телеграмм-канал, общий чат в телеге, сессии Q&A.
- О чем компания может делиться с менеджментом:
- Всё и максимально открыто
- Продавать прототипы изменений и собирать обратную связь
- Просить задавать неудобные вопросы
- Рассказывать о возможностях и искать лидеров
- Показывать проблемы и искать совместные решения
- О чем компании стоит делиться со всеми:
- Об изменениях (которые уже поддерживает менеджмент)
- Проблемы — с решениями от менеджмента
- Возможности — с запросом на участие
- Выручку, прибыль — в процентах
Проекты
- Каскадная модель производства драматически снижает вероятность успеха проекта
- Cynefin framework https://ru.wikipedia.org/wiki/Cynefin_framework — как концептуальная основа для принятия решений:
- Obvious. Применяйте «Best Practice». Задачи ясны, решения очевидны, следуйте установленным процедурам.
- Complicated. Применяйте «Good Practice» или экспертные мнения. Возможно несколько правильных решений
- Complex. Проведите эксперименты и используйте «Emergent Practice». Тут нет очевидных решений, выясните правильный подход через пробу и ошибку.
- Chaotic. Действуйте сразу для стабилизации ситуации, затем изучайте и отвечайте на изменения. Нужно немедленно действовать.
- В разработке нетиповых решений часто приходится решать задачи уровня Complicated и Complex, поэтому взвешивайте решения. Complicated — это граница проектной деятельности, начиная с Complex — это задачи в зоне эмпирической деятельности, а значит мы не можем говорить о каскадной модели и вотерфоле для таких решений. Это всё Симулякр плана, как выразился Глеб Михеев :-)
- Иногда стоит принять, что ты не можешь определить точные требования и вместо требований определить цель и ключевые результаты (это, кстати, пересекается с тем что говорят ребята из Бюро про ФФФ). Это зона неопределенности, её невозможно спланировать. Это зона командной работы.
- Что пропагандирует аджайл:
- Люди и взаимодействие важнее процессов и инструментов
- Работающий продукт важнее исчерпывающей документации
- Сотрудничество с заказчиком важнее согласования условий контракта
- Готовность к изменениям важнее следования первоначальному плану
- В аджайле развитие. Аджайт создает продукт, ватерфолл его воспроизводит
- Немного о концепции Run-Change-Disrupt
На кого подписался после конфы
- https://t.me/panfilovonline Пишет про запуск digital-проектов и IT-инструменты для бизнеса
- https://t.me/rukovozhu Виктор Рындин: CEO @Wemakefab & @Dprofileru
- https://t.me/tired_glebmikheev Глеб Михеев, просто поток сознания на стыке менеджмента и ИТ, я влюбился
- @dpletnev. Дима Плетнев. Но он ничего в паблик почему-то не пишет, приходится писать в личку
- https://t.me/successfulproduct Сергей Пращенко, про продакт дискавери вообще и в энтерпрайзе в частности (самый недооцененный доклад, потому что было жутко интересно, но все выдохлись)
Ну и посмотрите запись трансляции, очень много достойных лекций: