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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Прошедшие

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Не надо так

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

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

***

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Планёрка в Nutnet

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

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

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

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

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

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

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

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

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

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

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

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

MVP

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

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

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

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

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

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

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

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

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

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

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

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

Выводы

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