Иван Лощёнов

Про суперспособности

Thu, 09 Jul 2026 15:12:20 +0400

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

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

В Школе Бюро мы с командой «Суккулентоводства» (Полина и Катя, привет!) столкнулись с интересным искажением: каждому казалось, что остальные ребята в команде сильные специалисты и вносят много пользы в проект, а ты не делаешь ничего особенного. Но когда обменялись обратной связью, стало понятно: мы не видели ценности в том, что давалось нам легко, а другие видели, потому что для них это огромный труд.

Другими словами:

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

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

А еще поиск суперспособностей помогает в управлении людьми. Если внимательно смотреть на команду, видно тех, у кого получается «само»: без насилия над собой, без лишнего контроля, с интересом и энергией. Часто это значит, что человек на своем месте.

Потратьте пять минут, скажите человеку рядом о его суперсиле. Возможно, сам он ее пока не видит.

Задача и решение

Wed, 29 Apr 2026 14:14:01 +0400

Клиенты редко приходят с задачей, чаще приходят с выбранным решением:

нужен личный кабинет
хотим интернет-магазин
нужен редизайн

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

Например, клиент говорит: «Нам нужен личный кабинет», а на самом деле хочет другое:

увеличить повторные заказы
дать клиентам доступ к документам
сократить ошибки в заказах

И под каждую из таких задач есть другие решения:

CRM-маркетинг и триггерные рассылки
корпоративные чаты
улучшение процесса оформления

Поэтому «понять задачу» — значит разобраться:

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

После обучения в Школе Бюро, полюбил формулировку «полезного действия», она помогает точнее понять кому мы хотим причинить пользу и для чего:

Было	Стало
Сделать сайт	Помочь компании выглядеть надежным поставщиком для закупщиков и служб безопасности
Разработать личный кабинет	Помочь B2B-клиентам оформлять заказы без ожидания менеджера, а менеджерам — меньше времени тратить на рутину
Создать интернет-магазин	Помочь конечным клиентам находить нужный инструмент, видеть наличие и сроки поставки, оформлять заказ, а компании снять зависимость от дилеров, проверять гипотезы по розничным продажам, не ломая текущие процессы

Разница кажется небольшой, но в ней возможность решить настоящие задачи бизнеса.

Люблю вопрос:

«Какую задачу мы на самом деле решаем?»

Честный ответ на него иногда дает такое решение, что и делать-то ничего не надо — это идеально.

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

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

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

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

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

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

Прошедшие

Секция «Электронная коммерция» на форуме «Мой бизнес — путь к новым рынкам» г. Ижевск, 2026
Какие люди добиваются успеха в ИТ, ИТ-лицей №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

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