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

“Давайте уже после праздников” VS “Можете успеть до праздников?”

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

Если говорить про нас, то мы в студии стараемся не планировать на майские большие релизы и важные активности. Объяснение простое: даже если всё протестировано и вылизано, всегда есть вероятность, что что-то пойдет не так. А в праздники поддержка может быть ограниченной — как с нашей стороны, так и со стороны клиентов. Поэтому мы обычно просим и клиентов тоже не рисковать и не планировать ключевые запуски на этот период.

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

В общем, майские близко, и как всегда — немного режим ожидания. А у вас что — режим “успеть всё” или уже “обсудим после”?

👋 Привет, !
Рад сообщить, что наш сервис LookLink участвует в голосовании "Продукт недели" на Продакт Радаре! (это как Product Hunt, только Российский).

🔥 Коротко о главном:
— Это тот самый сервис для сбора проверенных отзывов и профессиональной визитки. Собирает всю информацию о вас в одном месте (опыт, регалии, контакты)


🚀Этот голос для нас очень важен! Если вам близка идея, поддержите нас — это займёт буквально пару кликов.
🔥🔥🔥 Проголосовать тут : https://productradar.ru/product/looklink/


Заранее спасибо за поддержку! Для нас это действительно значит многое 🙏

P.S. Поделитесь с коллегами — вместе сможем выиграть!

Как и обещал на выступлении в Сколково — выкладываю чек-лист Product-Solution Fit для всех, кто работает над своим продуктом.

Это один из самых недооценённых этапов: когда кажется, что ты уже “почти сделал продукт”, но на самом деле — только начинаешь понимать, решаешь ли ты вообще нужную проблему и нужным способом.

Я собрал удобный чек-лист, чтобы проверить себя перед выходом в продуктовые гипотезы и масштабирование. Можно пройти за 10–15 минут.

Подходит для основателей, PM-ов, стартаперов и всех, кто думает о решениях, а не только о фичах.

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

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

Признаюсь, раньше я довольно скептически относился к онлайн-формату. Всегда казалось, что “не то”: меньше контакта, сложнее чувствовать аудиторию, проще отвлечься.

Но сегодня было больше 50 участников, и все — максимально вовлечённые, с вопросами, комментариями, своими историями. Рассказывал — и ощущение было, как будто сидим в одной аудитории.

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

P.S. Чек-лист по MVP/Product Solution Fit, как и обещал, выложу сюда чуть позже.

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

Airbnb сейчас — глобальная платформа с миллионами пользователей. Но началось всё максимально приземлённо: в 2007 году Брайан Чески и Джо Гебби жили в Сан-Франциско и едва могли платить за квартиру. Когда в город приехала толпа людей на конференцию и отели оказались переполнены, они… надули три матраса в своей гостиной, сделали простенький сайт и предложили людям пожить у них за небольшую плату.

Так появилась первая версия Airbnb — без календарей, отзывов, мобильного приложения и автоматической оплаты. Но с чёткой гипотезой: люди готовы снимать жильё у других людей.

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

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

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

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

А у вас были истории ранних запусков? Или наоборот — когда «допиливание» затянулось? Делитесь, будет интересно обсудить.

Выступил на конференции в МГИМО — на этот раз немного по-другому.

Обычно я рассказываю про инновации, стартапы, гипотезы и PSF и другие аспекты создания ИТ-продуктов.

В этот раз — выступал на конференции, посвящённой психологии управления и командным процессам. И это дало интересный фокус.

Инновации — это не только про идеи, методологии и MVP. Это про людей.
Про команды, которые учатся в процессе. Про лидеров, которые умеют держать неопределённость. Про среду, в которой можно ошибаться и не бояться признаться «мы не знаем».

Говорили о том, что:
• PSF — это не просто точка продукта, это точка командного инсайта;
• гипотезы — это не только про продукт, но и про культуру проб и ошибок;
• лидер — это не тот, кто знает путь, а тот, кто умеет вести команду в тумане.

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

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

И вот самое забавное: этот язык называется… Easy Language. Ну то есть, видимо, «изи» — это для китайцев😅

Сначала подумал, что это шутка или эксперимент вроде шуточных языков типа Brainfuck, но нет — всё серьезно. Используется в реальных прикладных задачах, особенно в финансовой сфере в Китае. Вот ссылочка на китайскую википедию с более по подробной информацией.

В очередной раз удивляешься, насколько велик и разнообразен мир разработки. И да, в сравнении с этим, Python действительно можно считать международным языком объединения человечества :)

Друзья, небольшой анонс!

В эту субботу, 5 апреля, буду выступать на конференции в МГИМО — «Психология управления групповыми процессами в организации», отделение "ИННОВАЦИИ И КРЕАТИВНОСТЬ В КОМАНДЕ"

Моя тема — «Как превратить идею в востребованное решение: работа с рисками на этапе инноваций и путь к Product-Solution Fit». Поговорим о том, почему хорошие идеи не всегда превращаются в продукты, и что с этим делать.

Если интересно — приходите, участие бесплатное, но сегодня последний день регистрации.

Вот ссылка для записи.

Буду рад видеть знакомые лица!

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

Читайте нашу небольшую историю ��

Среда - время рекомендаций! Ведь когда еще можно найти немного времени для чтения чего-то нового и интересного?

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

Хотел бы сегодня рассказать о моем одно-клубнике из 100Founders и рекомендовать ее канал.

Знакомьтесь, Ольга Сыса – настоящий эксперт в мире корпоративных финансов!

Более 20 лет она работала в самых разных компаниях – от образовательных проектов до крупных нефтегазовых корпораций с оборотом в миллиарды рублей.
Этот опыт позволяет ей видеть финансовую "кухню" бизнеса изнутри и находить решения для самых разных ситуаций.

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

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

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

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

Всем привет!

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

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

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

Я это делаю на платформе LookLink. Самый простейший, который можно только придумать, ресурс, который фокусирует внимание на самом основном и главном.

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

Большая просьба, кто меня знает лично или как-то пересекался, пожалуйста, посетите мой профиль и оставьте отзыв\рекомендацию: https://looklink.ru/anton-tarasenko

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

«Вы делаете не то, что нужно». История про Instagram, ошибки и вовремя сказанное вслух

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

История Instagram начиналась вообще не с Instagram. В 2009 году Кевин Систром и Майк Кригер работали над приложением Burbn — гибридом Foursquare, фото-альбома, планировщика встреч и чуть-чуть мессенджера. Приложение умело всё и сразу: чекины, планы, лайки, фото, геолокация, сообщения.

Почему Burbn? Название — это отсылка к бурбону, любимому напитку Систрома. В начальной идее приложение должно было быть чем-то вроде “виртуального бара”, где друзья делятся, где они, с кем и чем заняты. Такой себе цифровой вечерний напиток — с фоточками, комментариями и «где ты сейчас». Идея звучала атмосферно, но по факту… получалось всё и ничего.

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

И вот тут случилось то, что редко происходит в стартапах. Команда не начала доказывать, что всё по плану. Они просто остановились. Сели. И честно пересмотрели продукт. Удалили почти всё.
Оставили только одно: сделать фото, применить фильтр и выложить.

Так родился Instagram. Не как очередная социальная сеть, а как фокусированное, простое и приятное действие, которое стало привычкой миллионов.

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

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

У нас в студии тоже были клиенты с проектами, где важно было не доделывать — а отказаться от лишнего. И только тогда появлялось ощущение, что «всё на своих местах».

Если вы сейчас работаете над своим продуктом — посмотрите на него со стороны. Спросите себя: что в нем самое главное? А теперь — сможете ли вы оставить только это?

Иногда именно в этом решении и есть точка роста.

Почему «работающий прототип» — не гарантия успеха?

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

Вспомнил историю создания Slack. Сейчас это один из самых популярных корпоративных мессенджеров, а начинался он… с провала.

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

Они не бросились сразу «пилить» из него полноценный сервис. Хотя прототип у них был и работал отлично, команда пошла другим путем:
— начали рассылать MVP друзьям и другим стартаперам
— собирали фидбэк буквально по каждой кнопке
— выкинули часть фич
— переработали интерфейс
— пересобрали всё, уже не для себя, а для будущих пользователей

И только после этой итерации Slack стал тем, что мы знаем сегодня.

Что важно: рабочая штука внутри команды ≠ готовый продукт для рынка. Иногда нужно не «допиливать то, что есть», а пересобрать, оттолкнувшись от новой аудитории и нового запроса.

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

Часто слышу фразу: «Давайте запустим MVP, проверим спрос, а дальше будем развивать». В большинстве случаев это правильный подход — быстрый запуск, тестирование гипотез, минимальные затраты. Но иногда MVP — это не лучший путь.

Вспомнил историю Amazon и их легендарного провала — Fire Phone. В 2014 году компания выпустила свой первый смартфон, вложила миллионы в разработку, но продукт провалился. Почему?

Fire Phone не был MVP. Это был непроработанный, но дорогой эксперимент, где сделали ставку на необычные фичи (3D-экран, жесты), но не учли главного — что реально нужно пользователям. Телефон оказался дорогим, неудобным и никому не нужным, несмотря на мощный маркетинг. В итоге через год проект закрыли, а Amazon списал 170 млн долларов убытков.

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

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

Друзья привет! Хочу порекомендовать канал моей коллеги по клубу 100Founders🤗

Настя вместе со мной участвует в ИТ клубе и руководит разработкой страховых продуктов в Альфа Банке.

Настя мама двоих детей, топит за ЗОЖ и умеет собирать кубик Рубика за 2,5 минуты 😁

Ее канал для тех кто любит «почесать» мозги и саморазвитие в любом его проявлении!

Вот например очень классный ее пост про метод ИКР

Если зайдет - лайк-шер-комментарий)))

У нас в студии теперь есть направление outstaffing — помогаем компаниям усилить команды нужными ИТ-специалистами. Если на проекте не хватает разработчиков, аналитиков или проджект-менеджеров, можем предоставить специалистов от 1 месяца. Они готовы проходить интервью, быстро вливаться в работу и закрывать задачи. Если есть запрос или просто хотите узнать детали — пишите в личный телеграм @antontar. 🚀

Прошлым летом я давал интервью медиа-проекту "ВТБ. Ближе к Делу": о делегировании, выгорании, предпринимательстве и т.п. Получилась, как я считаю, очень неплохая история. Перечитывая ее сейчас, понимаешь, какой тернистый путь был и что еще ждет впереди, насколько все зависит от случая, но и конечно от количества попыток. Обязательно будем продолжать пробовать дальше и дальше! Ведь идей масса.

А сама статья вот здесь (там есть даже старые фотографии с Yota времен) и историческая справка:

https://kdelu.vtb.ru/articles/pochemu-menedzher-chempion-eto-plohoj-predprinimatel-istoriya-osnovatelya-dna-team

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

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

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

Поэтому главный совет – не закапываться в «идеальный продукт». Лучше запуститься с работающим минимальным набором функций, а дальше уже смотреть, что действительно нужно. Иначе можно потратить годы и так ничего и не выпустить.

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

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

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

Привет!

В последнее время владельцы бизнесов часто спрашивают нас о Telegram Mini Apps — создании приложений внутри мессенджера. Интересуются, нормальный ли это вариант для MVP, можно ли заменить им классическое мобильное приложение и какие есть плюсы и минусы.

Обо всем этом решил написать на https://vc.ru/dev/1847860

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

Ну и стандартный вопрос: «А сколько это будет стоить?»

И вот тут начинается самое интересное. Конечно, можно дать базовый ответ: от миллиона рублей и дальше — зависит от деталей. Но как вообще понять бюджет?

Почему одинаковые на первый взгляд приложения могут стоить по-разному?

Мы как пользователи уже привыкли к гигиеническому минимуму:
✔️ Красивый дизайн и анимации
✔️ Удобный интерфейс
✔️ Стабильная работа
✔️ Интуитивные механики
✔️ Быстрое обновление данных \ контента

Но вот дальше начинается глубина. Например:
➡️ Откуда будут браться данные?
Контент можно вносить вручную через админку (а значит, ее нужно сделать), или забирать из другой системы (значит, потребуется интеграция).

➡️ Как будет работать логика взаимодействий?
Простой чат — это одно, а чат с ботом и умными подсказками — совсем другое.

➡️ Как будет собираться аналитика?
Статистика по поведению пользователей не появляется сама собой. Это тоже надо продумывать и закладывать на старте.

➡️ А что с оффлайн режимом?
Работа приложения в оффлайне без интернета часто вообще "забывается" как функция, о которой надо подумать и предусмотреть.

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

Как не ошибиться с оценкой?

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

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

Если интересно узнать, как это работает, — пишите, расскажу подробнее! 🚀

Ваш медицинский сайт покидают быстрее, чем очередь в регистратуру?

Узнайте, как шрифты и фото врачей могут пугать сильнее, чем иглы, почему арабы отказались от золота в дизайне, а 3D-модели иногда опаснее гриппа.

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

Продолжаю опрос себя с помощью ChatGPT

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

Ну что ж, спустя ещё несколько подходов могу сказать — ничего не изменилось. Чат продержался какое-то время, но потом всё равно начал цепляться за предыдущие ответы. Например, спросил про появившееся новое увлечение за последние несколько лет, я ответил — большой теннис. Через пару вопросов снова возвращаемся к этому: «Как стратегии игры в большой теннис повлияли на твою работу?»

Занятно. Получается, это даже немного человечнее, чем оригинальный запрос в формулировке независимых вопросов. Или я чего-то не понимаю?

Зато под конец GPT выдал вопрос, над которым задумался.

«Какой самый неожиданный или нетипичный комплимент ты когда-либо получал?»

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

Так что раз уж мой эксперимент превращается в интерактив, то вопрос к вам:

💬 Что бы вы сказали обо мне, если знакомы со мной какое-то время?

Попробуем обратиться к помощи зала)

Если вы когда-нибудь гуглили симптомы болезни, то обычно новости плохие, у вас осталось мало времени 😂

А если вы хоть раз заходили на медицинские сайты, то часто ощущения те же.

Написали в нашем блоге интересные рассуждения на эту тему)

https://vc.ru/marketing/1817120

Сегодня хочу обсудить пре-сейл в B2B – а именно, сколько времени он должен занимать и какой объем ресурсов стоит тратить, чтобы продажа состоялась.

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

И тут возникает дилемма:
1️⃣ Не погружаться глубоко в проработку, понимая, что если тебя не выберут, затраченные ресурсы не вернутся.
2️⃣ Еще больше углубиться, чтобы повысить вероятность, что проект отдадут именно тебе.

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

Конечно, бежать программировать без контракта не стоит. Но исследование и проработка концепции – иногда необходимый этап.

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

Контрактов никаких не было. Гарантий, что выберут именно нас – тоже.

Но мы приняли решение выделить ресурсы на исследование:

✅ Изучили доступные инструменты
✅ Посмотрели решения с открытым исходным кодом
✅ Протестировали разные варианты реализации

Этот рисерч занял неделю.

Что мы получили?
✔️ Помогли клиенту принять решение о проекте
✔️ Показали нашу заинтересованность и экспертность
✔️ Были готовы к старту сразу, без долгого онбординга

В итоге проект отдали нам, и мы успешно довели его до конца.

Но! Бывали и обратные ситуации. Мы выделяли ресурсы, глубоко погружались в проблему, но контракт получал другой подрядчик. Такое тоже случается.

Где баланс?

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

А как у вас? Какой у вас подход к пре-сейлу? Тратите много времени на анализ задач клиента или стараетесь держать границы?

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

И что могу сказать? КПД резко вырос. За этот период я «прочитал» (или теперь правильнее говорить – прослушал?) больше книг, чем за предыдущие 2-3 года.

Формат оказался идеальным:
✔️ Можно совмещать с рутинными делами
✔️ Нет ощущения, что ты «не находишь время» на чтение
✔️ Легче чередовать художественные и рабочие книги

Читаю (точнее, слушаю) в разных направлениях. Из рабочих книг наконец-то добрался до Филиппа Котлера по маркетингу – кажется, основа основ, а руки не доходили. Из художественного – недавно закрыл цикл Теодора Дрейзера «Финансист», и это просто ТОП.

Кстати, разницы в восприятии между деловой и художественной литературой в таком формате особо не заметил – но многое зависит от диктора. Когда слушал «Финансиста», пришлось даже купить книгу в другой озвучке, потому что голос диктора вызывал физическое напряжение. 😅 Слушать было невозможно.

Вчера закончил возврат к классике – Евгений Онегин в осознанном возрасте открылся совсем иначе. Сейчас пробую Пелевина – никогда раньше не читал, а хайп помню. Взял что-то из нового – «Круть».

В общем, формат аудиокниг зашел на 100%. Бумажные книги или чтение с телефона – ну никак не вписываются в мой быт.

🔥 А что вы думаете про аудиоформат? Используете или предпочитаете классику – бумагу и экран?

Сегодня хочу поднять интересную тему, с которой мы сталкиваемся регулярно – как делиться своим опытом и экспертностью, если проекты закрыты NDA?

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

В других сферах всё проще: например, маркетинговые агентства могут открыто показывать кейсы, рассказывать про рост продаж и эффективность рекламных кампаний. А мы в ИТ? Мы тоже знаем, какие решения дали результат, что сработало лучше, а что нет, но говорить об этом в деталях не можем.

Конечно, мы уже придумали разные способы делиться экспертизой без нарушения NDA:
✅ Обобщенные кейсы без названий и цифр
✅ Описания подходов и технологий, которые использовали
✅ Делиться процессами, а не результатами
✅ Выстраивать личный бренд через экспертизу, а не через портфолио

Но всё это сложнее, чем просто сказать: «Вот наш проект, вот конкретные результаты».

🔥 Как вы с этим справляетесь? Возможно, у вас тоже бывают ситуации, когда невозможно раскрыть детали работы, но хочется показать свою экспертизу. Как находите баланс?

Хочу поделиться небольшой личной историей, которая неожиданно привела меня к бизнес-рефлексии.

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

Казалось бы, что тут такого? Обычное дело, ничего критичного. Но в тот момент для меня это стало настоящей мини-драмой. Я настроился на занятие, давно хотел уделить время инструменту, потому что в этом году поставил себе цель вернуть навыки и участвовать в музыкальных активностях. Но регулярно не удается выделить время, и тут – когда все было готово – на тебе.

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

Ну, конечно. 😅

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

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

И вот тут меня осенило – эта ситуация слишком сильно напоминает бизнес-реальность.

Жесткий фокус на плане или гибкость?

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

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

Потому что жизнь (и бизнес) устроены иначе. Всегда есть вероятность, что что-то пойдет не так – причем необязательно в виде крупной проблемы. Это могут быть обычные операционные вопросы, которые внезапно меняются. И тут есть два варианта:

1️⃣ Оставаться в стрессе, фокусироваться на том, что пошло не так.
2️⃣ Принять изменения, адаптироваться, найти план Б – и двигаться дальше.

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

Но дается это не всегда легко. Особенно если план был четким и детально продуманным.

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

🔥 Если дочитали до конца – рад! Воскресенье, как мне кажется, отличный день для того, чтобы делиться личными историями и рефлексиями.

Технологическое менторство: зачем оно бизнесу?

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

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

Однако, большинство коучей и трекеров фокусируются на бизнесе:
✅ Как перейти от точки А в точку Б
✅ Как вырасти в финансах
✅ Как выйти из операционки
✅ Как масштабироваться

Все это мега-важные вопросы. Но чего лично мне не хватало в таком взаимодействии – это погружения в технические детали.

А что, если ваш бизнес – технологический?

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

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

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

Почему технологическое менторство важно?

Я часто выступаю в этой роли – как на этапе первичной подготовки к проекту, так и после его завершения. И вижу, что этот процесс помогает:

✔️ Сэкономить ресурсы (финансы, время, командные усилия)
✔️ Сформировать понятный фокус
✔️ Выстроить технологические процессы под бизнес-задачи

В прошлом посте я говорил о важности проектирования. Но что, если перед проектированием бизнесу вообще нужно разобраться, стоит ли запускать разработку в принципе?

У меня были кейсы, когда технологическое менторство кардинально меняло ход событий:
🔹 Один клиент вообще отказался от разработки, потому что мы пришли к выводу, что можно обойтись стандартными готовыми инструментами.
🔹 Другой – пивотнул продукт ещё до проектирования, потому что в процессе технологического анализа стало очевидно, что нужно делать совсем другое.

В идеале у предпринимателя должно быть два ментора:
1️⃣ Бизнес-ментор, который помогает со стратегией и финансами.
2️⃣ Технологический ментор, который помогает спроектировать продукт, понять реальные затраты и выстроить технические процессы.

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

🔥 А как вы считаете – технологическое менторство нужно всем или только определенным компаниям? Кто уже сталкивался с подобным опытом? Или вы считаете, что должен быть один бизнес-трекер или ментор, и нужно думать только о финансовой части?

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

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

Что такое проектирование?

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

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

Аналогия со строительством

Я часто сравниваю проектирование ИТ-продуктов со строительством.

Вы не можете сразу узнать точную стоимость ремонта в квартире или доме. Сначала нужно понять, какие материалы будут использоваться, надо ли что-то сносить или возводить, какие сценарии использования помещений вам важны.

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

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

Так же и в ИТ-разработке

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

🔹 Авторизация: Вход по СМС – удобно, но требует постоянных расходов на оплату сообщений. Можно использовать соцсети, а можно – и то, и другое.

🔹 Оплата: Платежный шлюз – ок, но где ваша аудитория? Как будут поступать платежи? Если важны международные переводы, надо предусматривать это в архитектуре и изучать не только технические, но и юридические вопросы работы с платежными системами.

🔹 Чат с поддержкой: Можно взять готовый сервис и встроить его в продукт. Но вот нюанс – где будет храниться переписка? Если это критично (например, для банков или медицинских сервисов), то нужно разрабатывать собственное решение.

И таких тонкостей – сотни.

Почему этап проектирования должен быть отдельным?

✔️ Он позволяет избежать неопределенности и «плавающих» бюджетов
✔️ Помогает правильно выбрать технологический стек
✔️ Позволяет сформировать четкое техническое задание и исключить недопонимание между заказчиком и разработчиком
✔️ Дает возможность построить дорожную карту развития продукта, отказавшись от части функций в первой версии, но понимая, что и когда можно добавить

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

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

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

Я пробовал по-разному, но в итоге получился некий микс. Иногда хочется полностью игнорировать всех и вся (некоторые клиенты любят писать вечером в субботу – в принципе, ничего против не имею, но полноценный, проработанный ответ в моменте дать не всегда возможно). А бывает, что вдруг накрывает вдохновение по какому-то вопросу – цепляется мысль, и… будто писатель, который наконец придумал развязку истории, берусь что-то писать, прорабатывать и детализировать.

А как у вас с этим? Полный оффлайн в выходные или всё-таки держите руку на пульсе? Какой метод работает для вас лучше?

Привет, друзья! 😊

В одном из прошлых постов я решил ответить на 100 вопросов от ChatGPT о себе, а затем пообщаться с «собой» – образом, который нейросеть создаст на основе моих ответов. Хочу рассказать, как идет этот процесс.

Пока он получается… немного странным. 😅 ChatGPT действительно начал задавать мне вопросы – причем, сначала предложил их разделить на группы (что логично и правильно).

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

Например, сначала мне задают: «Какой навык в бизнесе ты развил в последнее время?» Я отвечаю. А следующий вопрос уже строится на этом ответе, например: «А была ситуация, где именно этот навык тебе помог?» И так далее, каждый новый вопрос цепляется за предыдущий.

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

Как думаете, стоит ли оставить такой формат, когда вопросы развиваются как диалог, или лучше задать их в более изолированном стиле? Будет интересно услышать ваше мнение! 😊

Хочу поделиться одной из рабочих дилемм, которая, уверен, многим будет близка. У меня, как у руководителя и предпринимателя, каждый день полно задач разного типа: где-то нужно просто позвонить или уточнить, где-то после встречи появляются новые задачи – что-то сделать, прислать или договориться, а где-то требуется просто остановиться, подумать и предложить идею.

Конечно, вы можете сказать, что для этого есть любимые (или не очень) всеми CRM-системы, таск-трекеры и прочие инструменты. Но честно? Иногда хочется чего-то более интуитивного. Чтобы сразу связать задачу с человеком, вспомнить, о чем мы договорились, понять её срочность и влияние на мои планы на неделю. И чтобы было понятно, делаю ли я эту задачу сам или мне нужно кого-то забрифовать.

Лично я, помимо классических CRM и таск-трекеров (которые, конечно же, у нас есть), веду свой собственный список. Самый обычный, но очень важный для меня список главных вещей. В этот список попадает всё, что в моменте кажется важным. Каждый день я его просматриваю: что-то оттуда уходит в CRM для команды, что-то превращается в звонок с партнёром или коллегой, а что-то просто исчезает, так и не став актуальным.

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

А как у вас с этим? Как вы строите процесс управления задачами такого типа? Какими инструментами пользуетесь, и всё ли вас устраивает? Делитесь мыслями и опытом, очень интересно услышать ваши подходы! 😊

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

Задумался: как часто мы пересматриваем свои привычные подходы к работе? Когда в последний раз вы задавали себе вопросы: «А что, если сделать всё иначе? А что, если попробовать метод, который мне раньше казался слишком сложным или рискованным?»

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

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