С 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. Фреймворк продуктовой разработки, который должен настраиваться и постоянно адаптироваться, чтобы минимизировать ТТМ:

Команда

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 Сергей Пращенко, про продакт дискавери вообще и в энтерпрайзе в частности (самый недооцененный доклад, потому что было жутко интересно, но все выдохлись)

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