https://loshenov.ru/tags/upravlenie/ Блог про заказную разработку, запуск и развитие цифровых продуктов. ru Aegea 11.0 (v4079e) ivan@loshenov.ru Блог про заказную разработку, запуск и развитие цифровых продуктов. no 10 https://loshenov.ru/all/itogi-s-ural-digital-weekend-2023/ Mon, 14 Aug 2023 18:29:50 +0400 <p>С 3 по 5 августа провел с коллегами в Перми на Ural Digital Weekend 2023. Ничего не ждал и был удивлен уровнем организации, фестивальной атмосферой и кучей топов из заказной разработки.</p> <p>Чтобы не пропало, делюсь заметками с поездки:</p> <h2>Общее</h2> <ol start="1"> <li>Важность препати на профильных конференциях была мною сильно недооценена</li> <li>Критически важно выходить с уровня бизнес-заказчика на уровень топ-менеджеров и владельцев, чтобы не терять контакт с клиентом из-за смены менеджмента. И в дополнение — регулярно собирать обратную связь от топ-менеджеров и владельцев, чтобы реально оценивать ценность которую вы доносите до бизнеса клиента</li> <li>Отчеты для T&M-контрактов можно делать на BI — реалтайм-обновление и полная прозрачность</li> <li>Первый месяц можно продавать по постоплате, чтобы снизить риски клиента (интересная мысль, но не сталкивался с таким возражением на пресейле)</li> <li>Мало экспертизы на этапе продажи не бывает</li> </ol> <h2>Разработка своих продуктов</h2> <ol start="1"> <li>Значимые тренды рынка энтерпрайз-систем <ul> <li>Освободилась существенная доля рынка из-за ухода зарубежных продуктов (нужны замены ушедших систем)</li> <li>Технические тренды: микросервисы, lowcode/nocode стек, RPA</li> <li>Господдержка импортозамещения</li> <li>Самописные внутренние разработки крупных игроков</li> <li>Риски потери кадров (релокация, конкуренция за ИТ-кадры)</li> <li>Новые продукты крупных российских интеграторов</li> <li>Монетизация собственных решений</li> </ul> </li> <li>Не получится сделать продукт из готового решения, которое разрабатывалось под конкретного заказчика. Но для поиска «болей» рынка и формирования плана по развитию такого продукта можно использовать привычный Jobs To Be Done и мало известный <a href="https://university.connectwise.com/content/documents/cw_wp_painchain.pdf">Pain Chain</a></li> <li>Почему здорово делать продукт с клиентом: <ul> <li>Глубочаяшая отраслевая экспертиза</li> <li>Выходы на всех ЛПР в отрасли</li> </ul> </li> <li>Почему клиенту здорово делать продукт с агентством: <ul> <li>Экспертиза в разработке</li> <li>Умение продавать ИТ-решения</li> <li>Понимание того что такое клиентский сервис в ИТ (продукт может требовать внедрения)</li> <li>Гибкость (агентство всегда меньше и быстрее)</li> </ul> </li> <li>Обратная сторона продуктовой разработки <ul> <li>Очень сложно найти первых клиентов, свою кор-аудиторию</li> <li>Высасывает ресурсы (деньги и людей)</li> <li>Размывается фокус внимания</li> <li>Расходы сложнее планировать</li> <li>Расхолаживает команду, после клиентских проектов</li> <li>Сложно контролировать команду, если делаешь продукт бенчем (так не надо делать)</li> </ul> </li> <li>Рекомендации по организации запуска продукта <ul> <li>Жестко фиксировать этапы и бюджеты на свои продукты. Будьте готовы потерять эти деньги</li> <li>Учитывайте все затраты на разработку, в том числе косвенные затраты и упущенную прбыль</li> <li>Подумайте как будете использовать продукт, если он не взлетит</li> <li>Выделенная команда и четкие роли в ней</li> <li>Выделен ответственный за продукт (визионер) с четкими, прописанными KPI. Найдите человека, который будет думать о продукте всё время (не пол дня).</li> <li>Ответственный за продукт — не просто продакт, это драйвер процесса. Зачастую это должен быть СЕО\СОО\партнер — очень замотивированный предстаитель отдельного бизнес-юнита. Поэтому начать стоит с драйвера, тогда будет все чуть проще.</li> <li>Относитетсь к продукту как к заказчику своего агентства.</li> <li>Четко поставлены цели: smart, harvest, mece</li> <li>Продукт и основной бизнес не соперничают друг с другом</li> <li>10 раз убедиться что за продуктом стоит реальная боль, а не фантазии (даже если это фантазии самых главных людей в компании). Убедитесь, что сфера продукта близка вашему агентству</li> <li>Проработайте бизнес-модель, не смешивайте ее с агентской моделю</li> <li>Рассказывайте о продукте и том, как его делаете</li> </ul> </li> <li>С какими клиентами будет сложно прийти к продуктовой разработке: <ul> <li>Если нет процессов продуктовой разработки или текущее понимание больше на стороне заказчика</li> <li>Работаем по спринтам, но не видим смысла в бизнес-аналитике или системном аналитике. Заказчик не подпускает подрядчика к внутренней кухне, работаем в режиме черного ящика (ВА, привет)</li> <li>Продукт не совсем продукт, не приносит ценности бизнесу, обречен на правал</li> </ul> </li> <li>С какими клиентами возможно прийти к модели продуктовой разработки: <ul> <li>Если у заказчика есть фреймворк продуктовой разработки и он внедрен хотя бы частично</li> <li>Заказчик понимает ценность продукта и имеет план развития</li> <li>Заказчик умеет пользоваться всеми инструментами аутсорса</li> </ul> </li> <li>Если продукт не развивается — не увеличивается бюджет на его развитие.</li> <li>Как устранить раскол между ИТ и бизнесом — путь к успеху агентства: <ul> <li>Не пытаться занимать только одну из сторон (важно всё и сразу: делать важные для продукта задачи, по правильному процессу и быстро, чтобы бизнес возвращать инвестиции)</li> <li>Объяснять бизнесу почему в долгосрочной перспективе нужно учиться слыть ИТ: архитекторов, лидов и СТО</li> <li>Снабдить ИТ бизнесовой фактурой для продажи своих позиций, сделать ИТ-метрики управляемыми</li> <li>Помочь ИТ лучше отвечать требованиям бизнеса, а бизнесу предоставить для ИТ требования в понятном виде</li> </ul> </li> <li>Фреймворк продуктовой разработки, который должен настраиваться и постоянно адаптироваться, чтобы минимизировать ТТМ:</li> </ol> <div class="e2-text-table"> <table cellpadding="0" cellspacing="0" border="0"> <tr> <td>Этап</td> <td>Бизнес-инициатива или гипотеза</td> <td>Оценка и приоритизация</td> <td>Бизнес-анализ</td> <td>Системный анализ</td> <td>Разработка</td> </tr> <tr> <td>Кто</td> <td>Кто угодно: стейкхолдеры, СЕО, владелец продукта</td> <td>Лид разработки, БА, Владелец продукта</td> <td>БА, Владелец продукта, РП, ITBP, стейкхолдеры</td> <td>Лид разработки, Владелец продукта, РП</td> <td>Лид разработки, РП</td> </tr> <tr> <td>С каким результатом</td> <td>Сделаем что-то что сделает продукт более ценным для потребителей с целью увеличения бизнеса</td> <td>Понимаем сложность и сроки в попугаях, понимаем профит, приоритизируем</td> <td>Декомпозированные бизнес-требования, CJM, EJM, описанный бизнес-процесс. Дизайн, UX, ограничения</td> <td>Техническое решение, декомпозиция задач, в том числе по системам, беклог готовых, оцененных и готовых к разработке задач</td> <td>Задачи в рамках изначальных БТ, готовые к релизам (или UAT\AB\E2E) во всех системах</td> </tr> <tr> <td>Пример</td> <td>Если мы автоматизируем процесс оформления заказа — улучшим SLA дял клиентов, сэкономим Х рублей на операционных затратах</td> <td>Клиенты смогут оформить заказ в любое время суток, бизнес сэкономит и высвободит операционного ресурса на 20 млн в год</td> <td>Осознание, что требуется доработка в 5 бэкенд-системах, юридические и финансовые аспекты улажены, готов дизайн, описан процесс, посчитан P&L</td> <td>Эпик или сторя, в который собраны все задачи с оценками. Осталось только положить в спринты по системам согласно приоритетам</td> <td>Команда разработки готова провести демо нового функционала бизнесу и готова к отгрузке на бой</td> </tr> </table> </div> <h2>Команда</h2> <ol start="1"> <li>Для создания эффективной команды нужны единая цель, где каждый преследует цель компании и взаимодействует друг с другом</li> <li>Почему командная работа решает на уровне задач Complex (об этом чуть ниже): <ul> <li>Делает возможным решение задач, что не под силу одному человеку</li> <li>Является гарантией, что будут учитываться интересы всех сторон</li> <li>Понижается риск принятия ошибочных решений</li> <li>Помогает бороться с производственной слепотой</li> </ul> </li> <li>Чтобы у команды появилась сопричастность к происходящему, сопереживание проблемам, поддержка и продвижение изменений, повышения доверия и генерация идей — она должна быть плотно интегрирована в то, что у компании происходит и наоборот. Для этого существует точки для сбора и передачи информации, дальше об этом</li> <li>Какие могут быть точки для сбора информации: <ul> <li>1-2-1 RM</li> <li>1-2-1 HR</li> <li>360</li> <li>Командные встречи</li> <li>Чаты</li> <li>Эскалации</li> <li>Perfomance review</li> <li>Проектные ретро</li> <li>Неофициальные встречи</li> </ul> </li> <li>А какие системы передачи информации: <ul> <li>Планерки топов (еженедельно)</li> <li>Планерки менеджмента (каждые 2 недели)</li> <li>Планерки отделов (каждые 2 недели)</li> <li>Общая встреча компании (квартальные, годовая)</li> <li>Мероприятия по изменениям</li> <li>Личные встречи</li> <li>Дополнительные: почтовые рассылки (nda\not nda), телеграмм-канал, общий чат в телеге, сессии Q&A.</li> </ul> </li> <li>О чем компания может делиться с менеджментом: <ul> <li>Всё и максимально открыто</li> <li>Продавать прототипы изменений и собирать обратную связь</li> <li>Просить задавать неудобные вопросы</li> <li>Рассказывать о возможностях и искать лидеров</li> <li>Показывать проблемы и искать совместные решения</li> </ul> </li> <li>О чем компании стоит делиться со всеми: <ul> <li>Об изменениях (которые уже поддерживает менеджмент)</li> <li>Проблемы — с решениями от менеджмента</li> <li>Возможности — с запросом на участие</li> <li>Выручку, прибыль — в процентах</li> </ul> </li> </ol> <h2>Проекты</h2> <ol start="1"> <li>Каскадная модель производства драматически снижает вероятность успеха проекта</li> <li>Cynefin framework <a href="https://ru.wikipedia.org/wiki/Cynefin_framework">https://ru.wikipedia.org/wiki/Cynefin_framework</a> — как концептуальная основа для принятия решений: <ul> <li>Obvious. Применяйте «Best Practice». Задачи ясны, решения очевидны, следуйте установленным процедурам.</li> <li>Complicated. Применяйте «Good Practice» или экспертные мнения. Возможно несколько правильных решений</li> <li>Complex. Проведите эксперименты и используйте «Emergent Practice». Тут нет очевидных решений, выясните правильный подход через пробу и ошибку.</li> <li>Chaotic. Действуйте сразу для стабилизации ситуации, затем изучайте и отвечайте на изменения. Нужно немедленно действовать.</li> </ul> </li> <li>В разработке нетиповых решений часто приходится решать задачи уровня Complicated и Complex, поэтому взвешивайте решения. Complicated — это граница проектной деятельности, начиная с Complex — это задачи в зоне эмпирической деятельности, а значит мы не можем говорить о каскадной модели и вотерфоле для таких решений. Это всё Симулякр плана, как выразился Глеб Михеев :-)</li> <li>Иногда стоит принять, что ты не можешь определить точные требования и вместо требований определить цель и ключевые результаты (это, кстати, пересекается с тем что говорят ребята из Бюро про ФФФ). Это зона неопределенности, её невозможно спланировать. Это зона командной работы.</li> <li>Что пропагандирует аджайл: <ul> <li>Люди и взаимодействие важнее процессов и инструментов</li> <li>Работающий продукт важнее исчерпывающей документации</li> <li>Сотрудничество с заказчиком важнее согласования условий контракта</li> <li>Готовность к изменениям важнее следования первоначальному плану</li> </ul> </li> <li>В аджайле развитие. Аджайт создает продукт, ватерфолл его воспроизводит</li> <li>Немного о концепции Run-Change-Disrupt</li> </ol> <h2>На кого подписался после конфы</h2> <ol start="1"> <li><a href="https://t.me/panfilovonline">https://t.me/panfilovonline</a> Пишет про запуск digital-проектов и IT-инструменты для бизнеса</li> <li><a href="https://t.me/rukovozhu">https://t.me/rukovozhu</a> Виктор Рындин: CEO @Wemakefab & @Dprofileru</li> <li><a href="https://t.me/tired_glebmikheev">https://t.me/tired_glebmikheev</a> Глеб Михеев, просто поток сознания на стыке менеджмента и ИТ, я влюбился</li> <li>@dpletnev. Дима Плетнев. Но он ничего в паблик почему-то не пишет, приходится писать в личку</li> <li><a href="https://t.me/successfulproduct">https://t.me/successfulproduct</a> Сергей Пращенко, про продакт дискавери вообще и в энтерпрайзе в частности (самый недооцененный доклад, потому что было жутко интересно, но все выдохлись)</li> </ol> <p>Ну и посмотрите запись трансляции, очень много достойных лекций:</p> <div class="e2-text-video"> <iframe src="https://www.youtube.com/embed/6O78hNR2aes?enablejsapi=1" allow="autoplay" frameborder="0" allowfullscreen></iframe> </div> https://loshenov.ru/all/itogi-s-ural-digital-weekend-2023/ <p>С 3 по 5 августа провел с коллегами в Перми на Ural Digital Weekend 2023. Ничего не ждал и был удивлен уровнем организации, фестивальной атмосферой и кучей топов из заказной разработки.</p> <p>Чтобы не пропало, делюсь заметками с поездки:</p> <h2>Общее</h2> <ol start="1"> <li>Важность препати на профильных конференциях была мною сильно недооценена</li> <li>Критически важно выходить с уровня бизнес-заказчика на уровень топ-менеджеров и владельцев, чтобы не терять контакт с клиентом из-за смены менеджмента. И в дополнение — регулярно собирать обратную связь от топ-менеджеров и владельцев, чтобы реально оценивать ценность которую вы доносите до бизнеса клиента</li> <li>Отчеты для T&M-контрактов можно делать на BI — реалтайм-обновление и полная прозрачность</li> <li>Первый месяц можно продавать по постоплате, чтобы снизить риски клиента (интересная мысль, но не сталкивался с таким возражением на пресейле)</li> <li>Мало экспертизы на этапе продажи не бывает</li> </ol> <h2>Разработка своих продуктов</h2> <ol start="1"> <li>Значимые тренды рынка энтерпрайз-систем <ul> <li>Освободилась существенная доля рынка из-за ухода зарубежных продуктов (нужны замены ушедших систем)</li> <li>Технические тренды: микросервисы, lowcode/nocode стек, RPA</li> <li>Господдержка импортозамещения</li> <li>Самописные внутренние разработки крупных игроков</li> <li>Риски потери кадров (релокация, конкуренция за ИТ-кадры)</li> <li>Новые продукты крупных российских интеграторов</li> <li>Монетизация собственных решений</li> </ul> </li> <li>Не получится сделать продукт из готового решения, которое разрабатывалось под конкретного заказчика. Но для поиска «болей» рынка и формирования плана по развитию такого продукта можно использовать привычный Jobs To Be Done и мало известный <a href="https://university.connectwise.com/content/documents/cw_wp_painchain.pdf">Pain Chain</a></li> <li>Почему здорово делать продукт с клиентом: <ul> <li>Глубочаяшая отраслевая экспертиза</li> <li>Выходы на всех ЛПР в отрасли</li> </ul> </li> <li>Почему клиенту здорово делать продукт с агентством: <ul> <li>Экспертиза в разработке</li> <li>Умение продавать ИТ-решения</li> <li>Понимание того что такое клиентский сервис в ИТ (продукт может требовать внедрения)</li> <li>Гибкость (агентство всегда меньше и быстрее)</li> </ul> </li> <li>Обратная сторона продуктовой разработки <ul> <li>Очень сложно найти первых клиентов, свою кор-аудиторию</li> <li>Высасывает ресурсы (деньги и людей)</li> <li>Размывается фокус внимания</li> <li>Расходы сложнее планировать</li> <li>Расхолаживает команду, после клиентских проектов</li> <li>Сложно контролировать команду, если делаешь продукт бенчем (так не надо делать)</li> </ul> </li> <li>Рекомендации по организации запуска продукта <ul> <li>Жестко фиксировать этапы и бюджеты на свои продукты. Будьте готовы потерять эти деньги</li> <li>Учитывайте все затраты на разработку, в том числе косвенные затраты и упущенную прбыль</li> <li>Подумайте как будете использовать продукт, если он не взлетит</li> <li>Выделенная команда и четкие роли в ней</li> <li>Выделен ответственный за продукт (визионер) с четкими, прописанными KPI. Найдите человека, который будет думать о продукте всё время (не пол дня).</li> <li>Ответственный за продукт — не просто продакт, это драйвер процесса. Зачастую это должен быть СЕО\СОО\партнер — очень замотивированный предстаитель отдельного бизнес-юнита. Поэтому начать стоит с драйвера, тогда будет все чуть проще.</li> <li>Относитетсь к продукту как к заказчику своего агентства.</li> <li>Четко поставлены цели: smart, harvest, mece</li> <li>Продукт и основной бизнес не соперничают друг с другом</li> <li>10 раз убедиться что за продуктом стоит реальная боль, а не фантазии (даже если это фантазии самых главных людей в компании). Убедитесь, что сфера продукта близка вашему агентству</li> <li>Проработайте бизнес-модель, не смешивайте ее с агентской моделю</li> <li>Рассказывайте о продукте и том, как его делаете</li> </ul> </li> <li>С какими клиентами будет сложно прийти к продуктовой разработке: <ul> <li>Если нет процессов продуктовой разработки или текущее понимание больше на стороне заказчика</li> <li>Работаем по спринтам, но не видим смысла в бизнес-аналитике или системном аналитике. Заказчик не подпускает подрядчика к внутренней кухне, работаем в режиме черного ящика (ВА, привет)</li> <li>Продукт не совсем продукт, не приносит ценности бизнесу, обречен на правал</li> </ul> </li> <li>С какими клиентами возможно прийти к модели продуктовой разработки: <ul> <li>Если у заказчика есть фреймворк продуктовой разработки и он внедрен хотя бы частично</li> <li>Заказчик понимает ценность продукта и имеет план развития</li> <li>Заказчик умеет пользоваться всеми инструментами аутсорса</li> </ul> </li> <li>Если продукт не развивается — не увеличивается бюджет на его развитие.</li> <li>Как устранить раскол между ИТ и бизнесом — путь к успеху агентства: <ul> <li>Не пытаться занимать только одну из сторон (важно всё и сразу: делать важные для продукта задачи, по правильному процессу и быстро, чтобы бизнес возвращать инвестиции)</li> <li>Объяснять бизнесу почему в долгосрочной перспективе нужно учиться слыть ИТ: архитекторов, лидов и СТО</li> <li>Снабдить ИТ бизнесовой фактурой для продажи своих позиций, сделать ИТ-метрики управляемыми</li> <li>Помочь ИТ лучше отвечать требованиям бизнеса, а бизнесу предоставить для ИТ требования в понятном виде</li> </ul> </li> <li>Фреймворк продуктовой разработки, который должен настраиваться и постоянно адаптироваться, чтобы минимизировать ТТМ:</li> </ol> <div class="e2-text-table"> <table cellpadding="0" cellspacing="0" border="0"> <tr> <td>Этап</td> <td>Бизнес-инициатива или гипотеза</td> <td>Оценка и приоритизация</td> <td>Бизнес-анализ</td> <td>Системный анализ</td> <td>Разработка</td> </tr> <tr> <td>Кто</td> <td>Кто угодно: стейкхолдеры, СЕО, владелец продукта</td> <td>Лид разработки, БА, Владелец продукта</td> <td>БА, Владелец продукта, РП, ITBP, стейкхолдеры</td> <td>Лид разработки, Владелец продукта, РП</td> <td>Лид разработки, РП</td> </tr> <tr> <td>С каким результатом</td> <td>Сделаем что-то что сделает продукт более ценным для потребителей с целью увеличения бизнеса</td> <td>Понимаем сложность и сроки в попугаях, понимаем профит, приоритизируем</td> <td>Декомпозированные бизнес-требования, CJM, EJM, описанный бизнес-процесс. Дизайн, UX, ограничения</td> <td>Техническое решение, декомпозиция задач, в том числе по системам, беклог готовых, оцененных и готовых к разработке задач</td> <td>Задачи в рамках изначальных БТ, готовые к релизам (или UAT\AB\E2E) во всех системах</td> </tr> <tr> <td>Пример</td> <td>Если мы автоматизируем процесс оформления заказа — улучшим SLA дял клиентов, сэкономим Х рублей на операционных затратах</td> <td>Клиенты смогут оформить заказ в любое время суток, бизнес сэкономит и высвободит операционного ресурса на 20 млн в год</td> <td>Осознание, что требуется доработка в 5 бэкенд-системах, юридические и финансовые аспекты улажены, готов дизайн, описан процесс, посчитан P&L</td> <td>Эпик или сторя, в который собраны все задачи с оценками. Осталось только положить в спринты по системам согласно приоритетам</td> <td>Команда разработки готова провести демо нового функционала бизнесу и готова к отгрузке на бой</td> </tr> </table> </div> <h2>Команда</h2> <ol start="1"> <li>Для создания эффективной команды нужны единая цель, где каждый преследует цель компании и взаимодействует друг с другом</li> <li>Почему командная работа решает на уровне задач Complex (об этом чуть ниже): <ul> <li>Делает возможным решение задач, что не под силу одному человеку</li> <li>Является гарантией, что будут учитываться интересы всех сторон</li> <li>Понижается риск принятия ошибочных решений</li> <li>Помогает бороться с производственной слепотой</li> </ul> </li> <li>Чтобы у команды появилась сопричастность к происходящему, сопереживание проблемам, поддержка и продвижение изменений, повышения доверия и генерация идей — она должна быть плотно интегрирована в то, что у компании происходит и наоборот. Для этого существует точки для сбора и передачи информации, дальше об этом</li> <li>Какие могут быть точки для сбора информации: <ul> <li>1-2-1 RM</li> <li>1-2-1 HR</li> <li>360</li> <li>Командные встречи</li> <li>Чаты</li> <li>Эскалации</li> <li>Perfomance review</li> <li>Проектные ретро</li> <li>Неофициальные встречи</li> </ul> </li> <li>А какие системы передачи информации: <ul> <li>Планерки топов (еженедельно)</li> <li>Планерки менеджмента (каждые 2 недели)</li> <li>Планерки отделов (каждые 2 недели)</li> <li>Общая встреча компании (квартальные, годовая)</li> <li>Мероприятия по изменениям</li> <li>Личные встречи</li> <li>Дополнительные: почтовые рассылки (nda\not nda), телеграмм-канал, общий чат в телеге, сессии Q&A.</li> </ul> </li> <li>О чем компания может делиться с менеджментом: <ul> <li>Всё и максимально открыто</li> <li>Продавать прототипы изменений и собирать обратную связь</li> <li>Просить задавать неудобные вопросы</li> <li>Рассказывать о возможностях и искать лидеров</li> <li>Показывать проблемы и искать совместные решения</li> </ul> </li> <li>О чем компании стоит делиться со всеми: <ul> <li>Об изменениях (которые уже поддерживает менеджмент)</li> <li>Проблемы — с решениями от менеджмента</li> <li>Возможности — с запросом на участие</li> <li>Выручку, прибыль — в процентах</li> </ul> </li> </ol> <h2>Проекты</h2> <ol start="1"> <li>Каскадная модель производства драматически снижает вероятность успеха проекта</li> <li>Cynefin framework <a href="https://ru.wikipedia.org/wiki/Cynefin_framework">https://ru.wikipedia.org/wiki/Cynefin_framework</a> — как концептуальная основа для принятия решений: <ul> <li>Obvious. Применяйте «Best Practice». Задачи ясны, решения очевидны, следуйте установленным процедурам.</li> <li>Complicated. Применяйте «Good Practice» или экспертные мнения. Возможно несколько правильных решений</li> <li>Complex. Проведите эксперименты и используйте «Emergent Practice». Тут нет очевидных решений, выясните правильный подход через пробу и ошибку.</li> <li>Chaotic. Действуйте сразу для стабилизации ситуации, затем изучайте и отвечайте на изменения. Нужно немедленно действовать.</li> </ul> </li> <li>В разработке нетиповых решений часто приходится решать задачи уровня Complicated и Complex, поэтому взвешивайте решения. Complicated — это граница проектной деятельности, начиная с Complex — это задачи в зоне эмпирической деятельности, а значит мы не можем говорить о каскадной модели и вотерфоле для таких решений. Это всё Симулякр плана, как выразился Глеб Михеев :-)</li> <li>Иногда стоит принять, что ты не можешь определить точные требования и вместо требований определить цель и ключевые результаты (это, кстати, пересекается с тем что говорят ребята из Бюро про ФФФ). Это зона неопределенности, её невозможно спланировать. Это зона командной работы.</li> <li>Что пропагандирует аджайл: <ul> <li>Люди и взаимодействие важнее процессов и инструментов</li> <li>Работающий продукт важнее исчерпывающей документации</li> <li>Сотрудничество с заказчиком важнее согласования условий контракта</li> <li>Готовность к изменениям важнее следования первоначальному плану</li> </ul> </li> <li>В аджайле развитие. Аджайт создает продукт, ватерфолл его воспроизводит</li> <li>Немного о концепции Run-Change-Disrupt</li> </ol> <h2>На кого подписался после конфы</h2> <ol start="1"> <li><a href="https://t.me/panfilovonline">https://t.me/panfilovonline</a> Пишет про запуск digital-проектов и IT-инструменты для бизнеса</li> <li><a href="https://t.me/rukovozhu">https://t.me/rukovozhu</a> Виктор Рындин: CEO @Wemakefab & @Dprofileru</li> <li><a href="https://t.me/tired_glebmikheev">https://t.me/tired_glebmikheev</a> Глеб Михеев, просто поток сознания на стыке менеджмента и ИТ, я влюбился</li> <li>@dpletnev. Дима Плетнев. Но он ничего в паблик почему-то не пишет, приходится писать в личку</li> <li><a href="https://t.me/successfulproduct">https://t.me/successfulproduct</a> Сергей Пращенко, про продакт дискавери вообще и в энтерпрайзе в частности (самый недооцененный доклад, потому что было жутко интересно, но все выдохлись)</li> </ol> <p>Ну и посмотрите запись трансляции, очень много достойных лекций:</p> <div class="e2-text-video"> <iframe src="https://www.youtube.com/embed/6O78hNR2aes?enablejsapi=1" allow="autoplay" frameborder="0" allowfullscreen></iframe> </div> 5 https://loshenov.ru/all/kak-igra-v-gluhie-telefony-chut-ne-stoila-nam-krupnogo-klienta/ Fri, 09 Sep 2022 11:00:00 +0400 <div class="e2-text-picture"> <img src="https://loshenov.ru/pictures/nutnet-communicate.png" width="700" height="350" alt="" /> <div class="e2-text-caption">Сообщение от партнера, который узнал про ситуацию на проекте</div> </div> <p>В разработке первое, что должен понять исполнитель — цель клиента. Тогда есть шанс создать такой функционал, который ему действительно поможет.</p> <p>Обычно собственники и руководители компаний понимают, чего хотят от инвестиции в ИТ-проект. Они видят в нем ценность и хотят, чтобы вложения в него окупились. С ними легко говорить на языке бизнеса, они формулируют конкретные задачи — например, увеличить объем продаж в X раз.</p> <p>Иногда заказчику трудно сразу обозначить свои цели и четко сформулировать их. Тогда мы помогаем ему — задаем наводящие вопросы.</p> <p>Но чаще в качестве заказчика выступает не сам собственник бизнеса, а менеджеры с его стороны. От них намного сложнее добиться конкретики: они просят нас создать инструмент, но совершенно не понимают зачем.</p> <p>В таких случаях мы стараемся сэкономить ресурсы заказчика и время нашей команды: просим контакты собственников бизнеса и выясняем истинные цели проекта. Этот принцип мы выработали в процессе коммуникации с компанией «Витязь-Аэро».</p> <h2>Почему важна роль бизнес-заказчика в ИТ-проекте</h2> <p>«Витязь-Аэро» — это авиакомпания, которая выполняет пассажирские рейсы на вертолетах в отдаленные населенные пункты Камчатки. У них два ИТ-продукта: сайт и автоматизированная информационная система (АИС) для регистрации пассажиров, багажа, грузов. Первый — для клиентов, второй — для внутреннего пользования сотрудниками.</p> <p>В компании АИС ввели в 2017 году. Изначально ее создавал местный разработчик, сотрудники которого построили систему за полгода и далее осуществляли ее техподдержку. Позже количество человек в его команде сократилось, и работа по продукту замедлилась. АИС для аэропорта перестала стабильно работать и быстро адаптироваться под новые запросы пользователей.</p> <p>Кроме того, в системе изначально было много проблем в функционале: например, плохое изначальное проектирование и невыстроенная система тестирования и модификации кода. Со временем АИС перестала отвечать растущим потребностям компании.</p> <p>В конце 2019 года «Витязь-Аэро» захотели увеличить темпы разработки. Дополнительно нужно было развить функционал системы, ускорить трек поддержки и увеличить скорость реакции для исправления критичных дефектов. Чтобы закрыть эти потребности, в «Витязь-Аэро» решили сменить подрядчика и обратились к нам.</p> <h2>Проблемы в коммуникации с клиентом</h2> <div class="e2-text-picture"> <img src="https://loshenov.ru/pictures/ba-bylo.png" width="1280" height="720" alt="" /> <div class="e2-text-caption">Не надо так</div> </div> <p>Коммуникация с клиентом складывалась непросто: на разницу в местонахождении и часовом поясе (+8 часов) накладывались и другие сложности. Например, с начала сотрудничества у нас не было прямого контакта с бизнес-заказчиками — собственниками, которые хорошо представляют цели разработки и желаемый результат. Мы связывались с ними через руководителя проекта. Это был сотрудник компании, который не мог знать столько же, сколько бизнес-заказчики, несмотря на проактивную позицию в работе. Из-за этого в нашей коммуникации появилось несколько проблем:</p> <p>* <b>Менялись приоритеты, о чем мы поздно узнавали.</b> Например, нам приходила задача, которую надо было выполнить срочно. Мы тратили на нее время, а по готовности оказывалось, что она уже не нужна.<br /> * <b>Возникали недопонимания при постановке задач.</b> Оказалось, что обсуждать задачу без прямого контакта с бизнес-заказчиком — сложно. Это было похоже на игру в «глухие телефоны»: собственник давал нам задание через руководителя проекта, а мы получали его искаженным или неполным. При этом не было возможности быстро уточнить, что значительно увеличивало сроки исполнения. В итоге при релизе демоверсии получалось, что с продуктом все не так — результат не совпадал с ожиданием бизнес-заказчика.</p> <h2>***</h2> <p>Например, нам ставили задачу — настроить онлайн-оплату для реализации электронных билетов на сайте.</p> <p>При выполнении мы обнаружили много тонкостей, которые не могли решить только с нашей стороны. Это не просто техническая задача, она касается всего продукта: надо было понять, какие бизнес-процессы есть в компании и какие изменения в них потребуются. Как на этой основе мы будем выстраивать работу нашего бэк-офиса. Все это приходилось уточнять через руководителя проекта, который тратил много времени для сбора нужных нам данных.</p> <blockquote> <p>В итоге работа усложнилась на всех звеньях коммуникации. С нашей стороны — мы выполняли часть работы и останавливались, потому что ждали ответов на запросы о бухгалтерской отчетности, онлайн-кассе, требованиях к авиабилетам. Со стороны руководителя проекта — не было представления о статусе и проблемах проекта, а также возможности повлиять на работу подразделений и топ-менеджмента. А со стороны бизнес-заказчиков все выглядело так, будто мы затянули выполнение задачи на 2 месяца.</p> </blockquote> <p>Момент оказался поворотным — мы решили организовать переговоры с непосредственными руководителями «Витязь-Аэро».</p> <h2>Переговоры и изменения в порядке работы</h2> <p>Из-за возникшей коллизии мы встретились с бизнес-заказчиками. В ходе переговоров мы:</p> <ol start="1"> <li>Воссоздали моменты нашей коммуникации с самого начала, чтобы проверить, кто какой информацией владеет.</li> <li>Обозначили проекты, которые мы ведем: поддержка и развитие АИС, поддержка существующего сайта «Витязь-Аэро» и разработка нового.</li> <li>Познакомили с нашей командой и рассказали об объеме задач у каждого сотрудника — чтобы клиент понимал, что в проекты вовлечено много человек.</li> <li>Презентовали результаты работы за последние 6 месяцев.</li> <li>Рассказали, на каких стадиях находятся поставленные задачи.</li> <li>Наметили будущие приоритеты и проблемы, из-за которых могут сдвинуться сроки.</li> </ol> <div class="e2-text-picture"> <img src="https://loshenov.ru/pictures/va-stalo.png" width="1280" height="720" alt="" /> <div class="e2-text-caption">Колесо проектного взаимопонимания</div> </div> <p>Также мы проанализировали коммуникацию с «Витязь-Аэро» и предложили варианты, как предотвратить проблемы в будущем. Самым важным было подключить бизнес-заказчика к ключевым процессам разработки. Договорились о следующем:</p> <ul> <li>Внедрили ежемесячные демо. Подключали руководителей и заинтересованных участников со стороны заказчика, чтобы совместно продемонстрировать и принять новый функционал в дев-окружении. Сбор обратной связи здесь и сейчас упрощал коммуникацию с двух сторон и позволил учитывать ожидания заказчика. Также это погрузило руководителей в процесс разработки и дало понимание, почему готовы или нет те или иные инструменты;</li> <li>Договорились о стратегических совещаниях раз в 3—6 месяцев. Это помогло увидеть горизонт работы и определить приоритетные задачи в следующие 6—12 месяцев. Выделили несколько направлений: развитие и поддержка продукта, а также фиксация проблем в автоматизированной системе.</li> </ul> <p>Выстроенная коммуникация позволила сохранить сотрудничество и быстрее выполнять задачи клиента. Объем работ многократно вырос, а time-to-market, время за которое идеи реализовывались и становились доступными для пользователей, сократилось в 2 раза.</p> <h2>Где участие бизнес-заказчика обязательно</h2> <p>Работа с «Витязь-Аэро» показала, что общаться только с руководителем проекта по поводу целей и результата сложно. При такой коммуникации мы упускали из виду приоритеты бизнес-заказчика, подолгу выясняли тонкости его работы и не получали адекватную обратную связь. В итоге понимание задач было неполным, они долго выполнялись — получалось, что бюджет компании тратился без видимого результата.</p> <div class="e2-text-picture"> <img src="https://loshenov.ru/pictures/va-etapy.png" width="1288" height="728" alt="" /> <div class="e2-text-caption">Это позволило синхронизировать бизнес и разработку</div> </div> <p>Теперь мы обязательно привлекаем к прямому обсуждению бизнес-заказчиков. Особенно на следующих итерациях проекта:</p> <ul> <li>Формирование бэклога — определяемся со списком задач с описанием, оценкой и приоритетами;</li> <li>Утверждение скоупа — согласовываем список задач, которые точно должны попасть в следующий релиз;</li> <li>Тестовая эксплуатация — демонстрируем результат работы клиенту.</li> </ul> <p>Если вам интересно, как эффективно выстроить работу с разработчиками — задавайте вопросы. Мы всегда готовы поделиться опытом или провести полноценный аудит вашего ИТ-продукта, чтобы по итогу вы получили обоснованные предложения по развитию и поддержке.</p> https://loshenov.ru/all/kak-igra-v-gluhie-telefony-chut-ne-stoila-nam-krupnogo-klienta/ <div class="e2-text-picture"> <img src="https://loshenov.ru/pictures/nutnet-communicate.png" width="700" height="350" alt="" /> <div class="e2-text-caption">Сообщение от партнера, который узнал про ситуацию на проекте</div> </div> <p>В разработке первое, что должен понять исполнитель — цель клиента. Тогда есть шанс создать такой функционал, который ему действительно поможет.</p> <p>Обычно собственники и руководители компаний понимают, чего хотят от инвестиции в ИТ-проект. Они видят в нем ценность и хотят, чтобы вложения в него окупились. С ними легко говорить на языке бизнеса, они формулируют конкретные задачи — например, увеличить объем продаж в X раз.</p> <p>Иногда заказчику трудно сразу обозначить свои цели и четко сформулировать их. Тогда мы помогаем ему — задаем наводящие вопросы.</p> <p>Но чаще в качестве заказчика выступает не сам собственник бизнеса, а менеджеры с его стороны. От них намного сложнее добиться конкретики: они просят нас создать инструмент, но совершенно не понимают зачем.</p> <p>В таких случаях мы стараемся сэкономить ресурсы заказчика и время нашей команды: просим контакты собственников бизнеса и выясняем истинные цели проекта. Этот принцип мы выработали в процессе коммуникации с компанией «Витязь-Аэро».</p> <h2>Почему важна роль бизнес-заказчика в ИТ-проекте</h2> <p>«Витязь-Аэро» — это авиакомпания, которая выполняет пассажирские рейсы на вертолетах в отдаленные населенные пункты Камчатки. У них два ИТ-продукта: сайт и автоматизированная информационная система (АИС) для регистрации пассажиров, багажа, грузов. Первый — для клиентов, второй — для внутреннего пользования сотрудниками.</p> <p>В компании АИС ввели в 2017 году. Изначально ее создавал местный разработчик, сотрудники которого построили систему за полгода и далее осуществляли ее техподдержку. Позже количество человек в его команде сократилось, и работа по продукту замедлилась. АИС для аэропорта перестала стабильно работать и быстро адаптироваться под новые запросы пользователей.</p> <p>Кроме того, в системе изначально было много проблем в функционале: например, плохое изначальное проектирование и невыстроенная система тестирования и модификации кода. Со временем АИС перестала отвечать растущим потребностям компании.</p> <p>В конце 2019 года «Витязь-Аэро» захотели увеличить темпы разработки. Дополнительно нужно было развить функционал системы, ускорить трек поддержки и увеличить скорость реакции для исправления критичных дефектов. Чтобы закрыть эти потребности, в «Витязь-Аэро» решили сменить подрядчика и обратились к нам.</p> <h2>Проблемы в коммуникации с клиентом</h2> <div class="e2-text-picture"> <img src="https://loshenov.ru/pictures/ba-bylo.png" width="1280" height="720" alt="" /> <div class="e2-text-caption">Не надо так</div> </div> <p>Коммуникация с клиентом складывалась непросто: на разницу в местонахождении и часовом поясе (+8 часов) накладывались и другие сложности. Например, с начала сотрудничества у нас не было прямого контакта с бизнес-заказчиками — собственниками, которые хорошо представляют цели разработки и желаемый результат. Мы связывались с ними через руководителя проекта. Это был сотрудник компании, который не мог знать столько же, сколько бизнес-заказчики, несмотря на проактивную позицию в работе. Из-за этого в нашей коммуникации появилось несколько проблем:</p> <p>* <b>Менялись приоритеты, о чем мы поздно узнавали.</b> Например, нам приходила задача, которую надо было выполнить срочно. Мы тратили на нее время, а по готовности оказывалось, что она уже не нужна.<br /> * <b>Возникали недопонимания при постановке задач.</b> Оказалось, что обсуждать задачу без прямого контакта с бизнес-заказчиком — сложно. Это было похоже на игру в «глухие телефоны»: собственник давал нам задание через руководителя проекта, а мы получали его искаженным или неполным. При этом не было возможности быстро уточнить, что значительно увеличивало сроки исполнения. В итоге при релизе демоверсии получалось, что с продуктом все не так — результат не совпадал с ожиданием бизнес-заказчика.</p> <h2>***</h2> <p>Например, нам ставили задачу — настроить онлайн-оплату для реализации электронных билетов на сайте.</p> <p>При выполнении мы обнаружили много тонкостей, которые не могли решить только с нашей стороны. Это не просто техническая задача, она касается всего продукта: надо было понять, какие бизнес-процессы есть в компании и какие изменения в них потребуются. Как на этой основе мы будем выстраивать работу нашего бэк-офиса. Все это приходилось уточнять через руководителя проекта, который тратил много времени для сбора нужных нам данных.</p> <blockquote> <p>В итоге работа усложнилась на всех звеньях коммуникации. С нашей стороны — мы выполняли часть работы и останавливались, потому что ждали ответов на запросы о бухгалтерской отчетности, онлайн-кассе, требованиях к авиабилетам. Со стороны руководителя проекта — не было представления о статусе и проблемах проекта, а также возможности повлиять на работу подразделений и топ-менеджмента. А со стороны бизнес-заказчиков все выглядело так, будто мы затянули выполнение задачи на 2 месяца.</p> </blockquote> <p>Момент оказался поворотным — мы решили организовать переговоры с непосредственными руководителями «Витязь-Аэро».</p> <h2>Переговоры и изменения в порядке работы</h2> <p>Из-за возникшей коллизии мы встретились с бизнес-заказчиками. В ходе переговоров мы:</p> <ol start="1"> <li>Воссоздали моменты нашей коммуникации с самого начала, чтобы проверить, кто какой информацией владеет.</li> <li>Обозначили проекты, которые мы ведем: поддержка и развитие АИС, поддержка существующего сайта «Витязь-Аэро» и разработка нового.</li> <li>Познакомили с нашей командой и рассказали об объеме задач у каждого сотрудника — чтобы клиент понимал, что в проекты вовлечено много человек.</li> <li>Презентовали результаты работы за последние 6 месяцев.</li> <li>Рассказали, на каких стадиях находятся поставленные задачи.</li> <li>Наметили будущие приоритеты и проблемы, из-за которых могут сдвинуться сроки.</li> </ol> <div class="e2-text-picture"> <img src="https://loshenov.ru/pictures/va-stalo.png" width="1280" height="720" alt="" /> <div class="e2-text-caption">Колесо проектного взаимопонимания</div> </div> <p>Также мы проанализировали коммуникацию с «Витязь-Аэро» и предложили варианты, как предотвратить проблемы в будущем. Самым важным было подключить бизнес-заказчика к ключевым процессам разработки. Договорились о следующем:</p> <ul> <li>Внедрили ежемесячные демо. Подключали руководителей и заинтересованных участников со стороны заказчика, чтобы совместно продемонстрировать и принять новый функционал в дев-окружении. Сбор обратной связи здесь и сейчас упрощал коммуникацию с двух сторон и позволил учитывать ожидания заказчика. Также это погрузило руководителей в процесс разработки и дало понимание, почему готовы или нет те или иные инструменты;</li> <li>Договорились о стратегических совещаниях раз в 3—6 месяцев. Это помогло увидеть горизонт работы и определить приоритетные задачи в следующие 6—12 месяцев. Выделили несколько направлений: развитие и поддержка продукта, а также фиксация проблем в автоматизированной системе.</li> </ul> <p>Выстроенная коммуникация позволила сохранить сотрудничество и быстрее выполнять задачи клиента. Объем работ многократно вырос, а time-to-market, время за которое идеи реализовывались и становились доступными для пользователей, сократилось в 2 раза.</p> <h2>Где участие бизнес-заказчика обязательно</h2> <p>Работа с «Витязь-Аэро» показала, что общаться только с руководителем проекта по поводу целей и результата сложно. При такой коммуникации мы упускали из виду приоритеты бизнес-заказчика, подолгу выясняли тонкости его работы и не получали адекватную обратную связь. В итоге понимание задач было неполным, они долго выполнялись — получалось, что бюджет компании тратился без видимого результата.</p> <div class="e2-text-picture"> <img src="https://loshenov.ru/pictures/va-etapy.png" width="1288" height="728" alt="" /> <div class="e2-text-caption">Это позволило синхронизировать бизнес и разработку</div> </div> <p>Теперь мы обязательно привлекаем к прямому обсуждению бизнес-заказчиков. Особенно на следующих итерациях проекта:</p> <ul> <li>Формирование бэклога — определяемся со списком задач с описанием, оценкой и приоритетами;</li> <li>Утверждение скоупа — согласовываем список задач, которые точно должны попасть в следующий релиз;</li> <li>Тестовая эксплуатация — демонстрируем результат работы клиенту.</li> </ul> <p>Если вам интересно, как эффективно выстроить работу с разработчиками — задавайте вопросы. Мы всегда готовы поделиться опытом или провести полноценный аудит вашего ИТ-продукта, чтобы по итогу вы получили обоснованные предложения по развитию и поддержке.</p>