Иван Лощёнов

Влияние искусства на мышление

Wed, 19 Mar 2025 10:31:08 +0400

До эпохи Возрождения (14-17 века) образ мышления человека базировался на мышлении социальной группой: семьей, классом, нацией.

И только через появление в искусстве перспективы (глубины и уникальной точки зрения) и большого количества портретов (научило видеть человека как личность) развился индивидуализм, мышление трансформировалось.

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

По сути, привычному для нас мышлению — каких-то жалких 400-500 лет (эволюция смеется с этой прикормки). Сложно представить, сколько еще у человечества впереди.

P.S.: Узнал это слушая подкаст о Пушкине. К своему стыду, со школьной скамьи к Пушкину было отбито уважение и ответа на вопрос почему он сердце русской поэзии не было. Поэтому с особым восторгом рекомендую эту работу, сильно кайфанул. Там много вкусного про: отношения с отцом, нетворкинг лицеистов, путь от либерализмного вольнодумства до службы на Николая I, книжный бизнес, любовь а Наталье Гончаровой и стоицизм в преодолении проблем.

Подкаст: https://music.yandex.ru/album/24956069/track/126893630

Добродетели для роста в ИТ-карьере

Mon, 17 Mar 2025 19:45:39 +0400

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

Посчитал, что за 16 лет через компанию прошло больше 320 человек, 60% команды начинали работать будучи студентами.

Многие из них остались в отрасли и показали результат — открыли свое дело, перешли в продукты (кто-то в небольших влияет на бизнес-показатели, а кто-то трудится в больших продуктах), занимают руководящие должности.

Ключевой тезис:

Технологии приходят и уходят, остаются люди, которым доверяют.

Выводы, кратко:

Одних развитых хардскилов для быстрого роста недостаточно
Решают личностные качества, которые надо развивать:
- Ориентация на развитие
- Самоанализ, логическое и критическое мышление
- Ориентация на результат и ответственность
- Работа в команде
- Инициативность и настойчивость
Важно любить, что делаешь → тогда будет рост
Личностные качества развиваются с рождения, но если очень хочется — можно начинать в любое время:
- Составлять план развития: осьминожка навыков, цели и их трекинг
- Постоянно просить обратную связь: делать это правильно
- Развивать самостоятельность и настойчивость: даю примеры как
- Смотреть как работают другие → заземляться в рынок

Презентация

Полная версия «Какие люди добиваются успеха в ИТ» в PDF.

Как организовать родительский комитет и не умереть

Thu, 18 Jul 2024 00:24:00 +0400

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

Проблемы! Какие проблемы?

Родительские комитеты, как и любое общественное управление, опирается на инициативу.

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

Почему мне стоит доверять

Дети на зимнем корпоративе, который «самоорганизовался» по этим правилам, как и все остальное

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

распределял ответственность между родителями
выстраивал отношения с классным учителем
вел финансовый учет

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

База знаний — это старт!

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

Первая версия

Первая версия системы будет работать только на уровне родителей и учебного заведения, без выхода в надсистему (систему образования) и подсистему (детей). Уровень вопросов, которые будет закрывать база знаний:

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

База будет представлять из себя сайт с информационными материалами и инструментами. Для популяризации сервиса подготовим брендированные материалы: таблички для учета доходов\расходов, памятку для родительских чатов, шаблоны.

Сервис будет работать бесплатно, а у пользователей будет возможность пожертвовать деньги на развитие проекта.

Таблица для финучета

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

Планы

После выхода базы знаний и набора аудитории в 500 человек — создадим сообщество. Чтобы не терять контакт с аудиторией — сразу заведем группу в телеграмм и будем собирать емэйл-адреса. Сначала будем сообщать об обновлениях базы знаний, а потом сообщать о развитии сервиса. Подробнее о деталях проекта и контуре первой версии в понимании задачи.

Как помочь

Ищу в проект редактора и дизайнера, разработчик есть. Ребята из Школы Бюро — я вас ищу, пишите в телеграмм: @loshenov.

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

Mon, 14 Aug 2023 18:29:50 +0400

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

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

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

Mon, 19 Jun 2023 10:48:39 +0400

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

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

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

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

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

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

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

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

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

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

Thu, 19 Jan 2023 20:51:18 +0400

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Thu, 19 Jan 2023 17:49:03 +0400

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

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

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

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

Прошедшие

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

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

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

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

Thu, 19 Jan 2023 00:31:22 +0400

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

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

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

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

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

Fri, 09 Sep 2022 11:00:00 +0400

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

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

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

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

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

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

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

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

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

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

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

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

Не надо так

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

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

***

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

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

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

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

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

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

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

Колесо проектного взаимопонимания

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

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

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

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

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

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

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

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

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

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

Mon, 07 Dec 2020 23:33:13 +0400

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

Планёрка в Nutnet

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

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

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

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

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

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

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

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

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

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

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

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

MVP

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

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

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

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

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

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

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

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

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

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

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

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

Выводы

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

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

Sat, 05 Apr 2008 11:00:00 +0400

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