Развитие стартапа

MVP в стартапе давно мёртв...

Интернет полон буллшита на тему MVP. Вам продали удобную сказку. Сделай как-нибудь. Пользователь схавает. Главное, протестируешь гипотезу. Нет. Не схавает! Уже лет пять как это не работает.

Пользователь в 2026 году живет в мире, где у него в кармане продукты уровня Apple, Spotify, Telegram и ИИ-ассистенты, которые угадывают ваши мысли быстрее, чем вы их сами формулируете.

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

Ищу таких как ты, опытных backend и full-stack разработчиков, а также performance & growth маркетологов и продактов, которые хотят выходить за границы скучных простых задач. В нашей стартап-студии все партнеры, все профессионалы, работаем на результат. Я более 20 лет занимаюсь разработкой и выводом на рынок новых продуктов. Напиши мне, если интересно поучаствовать.

То, что вы называете MVP это чаще всего не Minimum Viable Product. Это Minimum Viable Excuse.

Оправдание, почему:

• нет нормального UX

• нет ясной ценности

• нет ощущения "хочу вернуться"

• нет даже базового уважения к вниманию пользователя

Реальность неприятная, но как есть. Вы не тестируете идею. Вы тестируете, насколько пользователи готовы терпеть ваш плохой продукт.

И когда они не терпят, вы делаете гениальный вывод: Гипотеза не зашла.

Чтобы быстро тестировать гипотезы, нужно сначала сделать нормально! А вы умеете делать нормально??? Один из тысячи может и умеет!

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

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

AI-дирижёр: почему оркестратор ценнее промптера

Два года назад на конференциях гордо представлялись: «Я промпт-инженер». Звучало свежо и дорого. Сегодня это примерно как писать в резюме «уверенный пользователь Google». Навык нужный — но не дифференцирующий.

Дело не в том, что промпты устарели. Изменилась единица работы с ИИ.

Что реально произошло

Раньше типичный сценарий: открыл ChatGPT → ввёл запрос → получил текст → поправил руками → пошёл дальше. Один инструмент, одна итерация, один человек в петле управления.

Сегодня производственные пайплайны выглядят иначе:

• Агент-планировщик разбивает цель на подзадачи и строит граф выполнения

• Специализированные агенты выполняют каждую задачу параллельно или последовательно

• RAG-слой подтягивает релевантный контекст из векторного хранилища

• Валидатор проверяет выход на соответствие контракту

• Оркестратор управляет всем этим — как дирижёр, а не как музыкант

В чём принципиальная разница

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

Разница хорошо видна на вопросах, которые задаёт каждый. Промпт-инженер спрашивает: «Как лучше сформулировать запрос? Какой tone of voice выбрать? Как получить нужный формат?» Оркестратор спрашивает иначе: «На какие подзадачи разбить цель? Какому агенту что делегировать? Что происходит, если один из них возвращает ошибку?»

Первый оптимизирует ввод. Второй проектирует систему.

Что нужно уметь оркестратору

Это не про знание математики нейросетей и даже не обязательно про Python. Это про системное мышление плюс несколько прикладных навыков.

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

2. Управление состоянием. Что хранить в памяти между вызовами, что передавать явно в контексте, а что безопасно забыть — это напрямую влияет на стоимость и надёжность системы.

3. Fallback-логика. Если агент вернул невалидный ответ или timeout — что дальше? Перезапуск, альтернативный путь, эскалация человеку? Системы без продуманного error handling ломаются в продакшене предсказуемо.

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

5. Оценка качества выхода. Не «красиво ли написано», а «решена ли задача, воспроизводим ли результат, насколько система деградирует при изменении входных данных».

Почему это важно именно сейчас

Microsoft в опросе 31 000 сотрудников из 31 страны обозначил роль «промпт-инженера» как одну из наименее перспективных для роста на горизонте 12–18 месяцев. Проектирование мультиагентных систем при этом называется ключевым навыком следующих двух-трёх лет.

Компании уже сейчас ищут не тех, кто «умеет работать с ИИ», а тех, кто умеет строить системы на базе ИИ. Это разные запросы — и разный рынок труда.

Порог входа ниже, чем кажется

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

Понять, как работает memory и state в агентных системах, и попрактиковаться на реальных задачах — n8n, LangGraph или AutoGen дают это с минимальным порогом входа.

Промпт-инженерия дала нам грамотность в работе с ИИ. Оркестрация даёт проектирование. Переход между ними — это не про новый инструмент. Это про новый тип мышления.

Как обычный понедельник превратился в повод собрать коллег со всей отрасли

У нас в клубе «Фармакод» есть традиция: каждый понедельник в 12.00 мы с резидентами созваниваемся. Без повесток, без строгих регламентов. Просто открываем микрофоны и говорим о том, что болит. Кто-то приходит с вопросом по ИБ, кто-то — по регламентам, кто-то просто хочет услышать, как дела у коллег.

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

Я тогда сказал: «Давайте не будем ограничиваться нашим узким кругом. Соберём круглый стол, пригласим коллег из других компаний, обсудим открыто. Тем более что тема актуальна для всей фармы».

Резиденты поддержали. И мы начали готовить.

Что в итоге получилось

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

Вот о чём поговорим:

• как сохранить доступ к M365, Teams, SharePoint, когда условия постоянно меняются;

• реальные кейсы: у кого что получилось, а где — провал и почему;

• аудит инфраструктуры: с чего начать, какие срезы делать, как классифицировать критичные сервисы;

• сценарное планирование: риски, сроки, бюджеты — как не утонуть в цифрах;

• архитектурные решения: выделенные каналы, split routing, SD-WAN — что реально работает;

• как распределять трафик между головным офисом и локальными контурами;

• взаимодействие с операторами и регуляторами: подводные камни, которые не лежат на поверхности.

И главное — мы не будем читать лекции.

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

Зачем я это рассказываю

Чтобы вы увидели, как работает «Фармакод» на самом деле. Это не «клуб по интересам», где раз в месяц высылают дайджест. Это место, где:

• твою проблему слышат и не оставляют одного;

• из одного вопроса могут вырасти полноценное мероприятие, разбор, а иногда и новый отраслевой стандарт;

• ты можешь влиять на повестку, а не просто подстраиваться под неё.

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

Поэтому я приглашаю вас

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

📅 Когда: 24 апреля, 12:00 🔗 Регистрация: https://my.mts-link.ru/j/Digital4pharma/18252549746

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

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

Автор Павел Карасев - основатель закрытого клуба ИТ и ИБ лидеров фармацевтических компаний «Фармакод»

За последние пару недель в Кулере появилось много всего: счётчики переходов по ссылкам из постов, генератор коротких ссылок, даже страничка-визитка - вот моя: cooler.debug-leg.ru/my-link/debug-leg

Но главного: кросспостинга в VK с фото до сих пор нет. И вот почему.

Я думал, это будет просто. Создал API-ключ в группе VK, дал ему права на стену, фото, файлы, потом попросил ИИ написать код. Первая публикация прошла. Текст лёг на стену как надо. Добавил фото и сразу ошибка:

error_code: 27 — Group authorization failed: method is unavailable with group auth.

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

error_code: 15 — Access denied: no access to call this method with current scopes.

Расширенные права? Пишу на devsupport@corp.vk.com. Ответ:

Из-за изменения политики дистрибуции API-методов расширенные API-доступы больше не выдаются.

Кольцо замкнулось. Токен сообщества - нельзя. Пользовательский токен - нельзя. Расширенные права - не дают.

Я пока не понимаю: это я что-то упускаю, или VK тихо закрыл эту возможность и просто не обновил документацию?

Кто-нибудь встречался с VK API и получал что-то кроме боли? 👇

Как распределить доли в проекте? Мой опыт и принципы.

Распределение долей - вопрос, который мы решаем с партнером “на берегу”. Расскажу о методике, которой пользуюсь я. Когда-то я сам узнал ее во время обучения в “Сколково”: о ней рассказал юрист и адвокат Дмитрий Гриц. Мне очень понравилось все то, о чем он говорил, и потом я даже брал у него отдельную консультацию. Сейчас мы используем именно такой подход в работе стартап-студии.

Немного теории: Доля - это соотношение капиталов, которые вносят партнёры. Капитал может быть:

• экономическим (деньги, сырье, продукция, здания, помещения, сотрудники и т.д.);
• человеческим (опыт и квалификация самих партнёров, труд самих партнёров);
• социальным (социальные связи, нетворкинг, умение и возможность привлекать инвестиции и т.д).

Если с экономическим капиталом все ясно (он легко переводится в цифры), то два других вида капитала считаются по таким формулам:

• Человеческий капитал: Компетенции партнера х Время, которое он уделяет проекту в месяц (берется во внимание время, не оплачиваемое рыночным образом, т.е. бесплатно) = Польза, которую партнер приносит проекту.

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

Для начала нужно понять распределение этих 3-х видов капиталов (вкладов) между собой. На практике чаще всего бывает так, что 50% успеха компании - это экономический вклад, а оставшаяся половина  - человеческий и социальный вклады, примерно в равных долях, человеческий чуть больше. Для капиталоемких видов бизнеса экономический вклад может быть и выше 50%. По итогу, доля в проекте будет сопоставима с тем вкладом, который делает партнер. Это справедливо и честно.

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

GEO - оптимизация контента под ИИ. Как это делать?

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

По прогнозам Gartner (исследовательская компания с фокусом на IT) в 2026 году объём традиционного поиска упадёт на 25% из-за перехода пользователей на ИИ-ответы. Так что сейчас - самое время работать с контентом так, чтобы он был удобен для ИИ, сохраняя при этом смысл и ценность. Конечно, привычная нам органика из поисковика никуда не уйдет и не будет полностью заменена платным размещением, она изменится. Но одного SEO будет уже не достаточно (хотя это и не новость!).  

Техническая база оптимизации сайтов остается прежней. Но помимо классического SEO, мы подстраиваем контент под генеративный поиск, чтобы из него легко извлекался конкретный ответ, приводим в соответствие Schema-разметку, усиливаем E-E-A-T сигналы (авторство, экспертность, источники), насколько удается закрываем тему семантически (не ключевыми словами, а полным раскрытием намерения пользователя).

Теперь мониторим: цитируют ли нас ChatGPT,Perplexity и другие Ai по целевым запросам клиента. Это новая актуальная метрика видимости, и для неё уже существуют свои инструменты. 

GEO быстро меняется, но расскажу, какие моменты на сегодняшний день могут быть интересны: 

1)ИИ предпочитает скучные тексты. Чем проще и прямолинейнее написан абзац, тем охотнее его цитируют нейросети. Не нужно никаких длинных подводок. Желательно чтобы ответ на тот вопрос, по которому вы хотите "выдаваться", был сформулирован у вас на сайте уже в первом абзаце.

2)Ссылки на чужие (проверенные!) источники помогают. Если в тексте ссылаться на исследования, статистику, авторитетные источники, то ИИ цитирует чаще.

3)Эффект “Википедии”. Страницы, которые структурно напоминают “Википедию” - определение, подразделы, конкретика - цитируются лучше обычных. ИИ обучали в том числе и на популярной интернет-энциклопедии. 

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

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

6)Корпоративный контент для ИИ - это хорошо, но лучше цитируется контент с указанием автора, его должности, опытом и тд. (E-E-A-T сигналы).

Пример:

Как может звучать в обычном тексте:

"Для пошива обуви по индивидуальным меркам мы рекомендуем измерять параметры стопы в вечернее время: так можно узнать максимальные размеры”. 

Как может звучать эта же фраза, оптимизированная для ИИ-поиска: 

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

Пробовали ли вы оптимизировать свой контент под ИИ-выдачу? Делитесь в комментариях! 

Как я сжег $60 в Cursor за 3 дня и понял, что флагманские LLM - это оверпрайс для рутины

Сейчас я с головой погружен в разработку Кулера. И на днях впервые уперся в лимит подписки Cursor Pro. Закинул еще $20, потом еще $20 и всё это меньше чем за три дня. Спойлер: эти деньги сгорели всего на половине фичи (сокращатель ссылок + счетчик переходов).

Я сидел на Claude Sonnet 4.6 и пробовал Opus 4.7. И вот на какой задаче до меня дошло, что я делаю какую-то херню.

Мой стек это React + Supabase. Прошу Opus сгенерить логику, а эта нейросеть за $25/1M токенов на серьезных щах пишет код, который тянет из базы все посты сразу, забив на батчи и даты публикации.

И тут пазл сложился. Флагманские модели - это эксперты во всём. Opus 4.7 шарит в молекулярной биологии и может написать эссе про пирамиды Хеопса. Но когда мне нужно накидать очередную формочку, я переплачиваю за всю эту мировую эрудицию, стреляя из пушки по воробьям.

Если мне всё равно нужно давать детальные инструкции и бить ИИ по рукам за детские архитектурные косяки, зачем платить х10? Встроенный Composer 2 (где токен стоит $2.50) при нормальном входном контексте отлично генерит базовый код.

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

1️⃣ Базовая разработка (формочки, CRUD, бойлерплейт) - по умолчанию сижу на легком Composer 2.

2️⃣ Проектирование и архитектура - иду обсуждать в Perplexity.

3️⃣ Реально сложная логика - переключаю ручками на что-то от Antropic, опираясь на чутье разработчика.

P.S. Перечитал сейчас свой текст. Звучу как динозавр из мира C++, который хейтит Python и ворчит про лишние слои абстракции и оптимизацию.

Дайджест мероприятий на апрель

16 апреля, 19:00 (Мск)

Технологическое предпринимательство для начинающих. Часть 1: от идеи к экономике проекта

Открытая онлайн-лекция о том, как технологии становятся бизнесом. Без стартап-магии — только реальные кейсы, ошибки и экономика проектов.

На встрече разберем:

● Чем техпред отличается от просто цифрового продукта

● Почему сильная технология — еще не успех

● Как говорить с инвесторами и смотреть на проекты через экономику

● Ошибки, которые ломают даже яркие стартапы

Кейсы: Under Armour, Theranos, YotaPhone, Ё-мобиль, On, CaseGuru.

🎤 Спикер: Антон Пчелинцев — магистр бизнес-информатики, соавтор курса «Экономика для технологических предпринимателей».

Формат: онлайн-лекция

Участие бесплатное. Регистрация по ссылкам: https://t.me/mipt_events_bot?start=dl-1775661093137

https://vk.com/app6379730_-224205661#l=9&auto=1

23 апреля, 19:00 (Мск)

Технологическое предпринимательство для начинающих. Часть 2: разбор кейсов и практика питчей

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

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

🎤 Спикер: Антон Пчелинцев — магистр бизнес-информатики, соавтор курса «Экономика для технологических предпринимателей».

Формат: онлайн-лекция + практика питчей + ответы на вопросы

Участие бесплатное. Регистрация по ссылкам:

https://t.me/mipt\_events\_bot?start=dl-1776090447189

https://vk.com/app6379730_-224205661#l=10&auto=1

29 апреля, 19:00 (Мск)

ИИ‑агенты: от LLM к автономным рабочим процессам

Лекция + мини‑практика. Разберем, как проектировать, запускать и измерять эффект от ИИ‑агентов.

О чем лекция:

● Чем ИИ‑агенты отличаются от чат‑ботов и «просто LLM»

● Архитектура агента: планирование, вызов инструментов, память, оркестрация

● Паттерны построения агентных систем (single/multi‑agent, planner‑executor)

● Сценарии применения: поддержка, продажи, аналитика, операции

● Метрики, стоимость выполнения задач, ROI пилота

● Риски, безопасность, human‑in‑the‑loop

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

🎤 Спикер: Никита Финченко — менеджер продукта VK Tech, преподаватель в МФТИ, ВШБ и VK Education

Формат: 45 мин лекции + 45 мин практики и разбора решений

Участие бесплатное. Регистрация по ссылкам:

https://t.me/mipt_events_bot?start=dl-1776161105388

https://vk.com/app6379730_-224205661#l=11&auto=1

Не особо интересный пост.

Я все еще считаю, что стартап — это весело 🐙

Наша разработка hardware продукта напрямую связана с софтом. В нашем случае умный датчик качества воздуха Atmy, становится по настоящему “умным” в связке с целой экосистемой в виде интеграций ML моделей, системы подтверждения качества данных Atmy Trust Rating (хочу об этом написать отдельно позже), токенизации, веб-сайта и приложения для управления устройством.

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

Спойлер 👀: ресурсов никогда не будет хватать. 

Приведу вам пример того, как мы работаем над платформой atmy.ai

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

↖️User product ← сейчас мы здесь

Какой воздух вокруг меня?

↖️Device management

Как живут мои станции?

↖️Data intelligence

Дай аналитику, API, выгрузки и объясни, что вообще происходит.

Объем большой. Мы реализуем функционал, которого еще не существует, поэтому выбрали работу по уровням и с быстрым тестированием:

накрутить идеи на максимум → быстро обкатать → выкинуть лишнее → остальное в прод и допиливать API

На практике это выглядит так:

появилась идея → накидываем проект в Figma (важно визуальное, так как делаем для людей) → дорабатываем за пару дней MPV через Cursor → тестируем → а далее либо удаляем без сожалений / либо сразу на git программистам.

Из того, что уже долетело до продакшна:

— Atmy Data Hub

Место, где наконец появилась нормальная аналитика по стране и миру. Скачивание графика по клику или скачать готовый csv файл. Графики, которых мне самому отчаянно не хватало в начале пути, когда заинтересовался экологией в своем городе.

— Режим “Мониторинг”

Внутри я его называю «око Саурона». По клику кнопки “Мониторинг” переходишь в этот режим сразу с карты, где “сейчас” находишься — и просто наблюдаешь за динамикой изменения воздуха в реальном времени. Все элементы в большем масштабе для удобного считывания с расстояния, обновление происходит практически real-time.

Есть ещё несколько фич, но их судьба пока под вопросом.

Например:

Мы тестируем гибридный режим (CAMS+AirMap Local) отображения глобального слоя pm2.5 CAMS совмещенный с локальными данными с земли, чтобы достичь максимальной актуальности данных. Здесь много математики и это тоже очень увлекательно.

И это всё — только первый слой.

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

Больше картинок и общения в нашем маленьком чате разработки телеграм: https://t.me/atmyhub

На кого я иду на Стачку?

Надо признаться, выбор очень хороший. В этом году на Стачку в Ульяновск приезжает более 200 спикеров по направлениям Разработка, Управление, Дизайн, Контент и Маркетинг.

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

Александр Бындю, автор методологии и книги Карта Гипотез. Эта штука помогает лучше структурировать стратегии(как компаний, как и жизни человека).

Анна Жаркова, автор книги Kotlin Multiplatform на практике. Чтобы было понятно, похожих книг в мире только две. И автор одной из них приедет на Стачку, в Ульяновск.

Очень круто послушать как строится разработка, архитектура и управление в крупных компаниях. На Стачке будет много спикеров из таких компаний, как Сбер, Яндекс, VK, МТС, Газпром, Wb, Ozon, Dodo, Ростелеком, Магнит, Т-банк и другие. Например, будут выступать такие ребята, как:

Михаил Шогин, архитектор Wildberries

Павел Горохов, руководитель направления по проектному управлению Газпром нефть.

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

Максим Крыжановский, R&D Lead Института искусственного интеллекта МГУ.

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

Александр Рыжов, руководитель SEO-отдела Wb.

B конечно же на Стачке будет много крутых ребят, кто делает Контент и Дизайн, например:

Андрей Абрамов, главный редактор Яндекс.Плюс

Роман Горшков, арт-директор Битрикс24

Мне как фаундеру, конечно интересно пообщаться с основателями компаний, их будет достаточно много, например:

Никита Обухов, основатель компании Тильда.

Юрий Кузнецов, основатель компании Суточно.ру

и другие.

В общем, будет куча крутых ребят, прикольный нетворкинг.

Поэтому:

Stop working! Все на Стачку!

Бережливое облако для стартапа: GPU, гранты, нагрузки и экономика роста 

Какой минимум нужен маленькой команде для стабильности и безопасности? Разбираемся в новом выпуске подкаста «Стартап-секреты».

🎧 Подкаст «Стартап-секреты»: Сезон 7, выпуск 2

В гостях Сергей Рыжков – коммерческий директор Рег.облака – российский облачный провайдер и поставщик комплексной ИТ-инфраструктуры.

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

Где послушать выпуск, подписаться и лайкнуть:

• Яндекс Музыка

• YouTube

• Apple Podcasts

• VK Music

• На сайте подкаста «Стартап-секреты»

Приятного прослушивания!🙌

💙 Подписывайся на подкаст в Телеграм: @podcaststartup

В топку ваши резюме! Как на самом деле нанимать сотрудников в стартап

В стартапах принято говорить, что команда — главный актив. Но как на практике отличить человека, который украсил резюме, от того, кто действительно поможет проекту выжить? Резюме тут бесполезно. Правильный найм начинается не с поиска кандидата, а с формулирования задач, которые ему предстоит решать. Рекрутер изучает резюме, и это — входная точка, не более. Настоящее собеседование начинается после. И на нём фокус смещается на мягкие навыки (soft skills). Почему это критично? Потому что всему необходимому («хардам») можно обучить. А вот если у человека нет нужных софтов — будет сложно.

На что мы смотрим при найме?

1. Адаптивность и быстрая обучаемость
Вчера делали одно, сегодня приоритеты сменились, завтра можем перечеркнуть всё и начать с нуля. Нам нужны те, кто не паникует при смене курса и способен «переобуться в воздухе».2. 2. 2. Проактивность
В стартапе никто не бегает с напоминаниями. «Я ждал, когда мне скажут» — здесь не работает. Нужно самому видеть, что сделать, самому предлагать улучшения, самому уточнять, если что-то непонятно.
3. Ориентация на результат, а не на процесс
Нам не важно, сколько часов человек просидел за компьютером. Важно — сделано или нет. Если сотрудник привык отчитываться «я работал», а не «я сделал» — это не наш человек.
4. Умение работать в хаосе
В стартапе нет идеального ТЗ, нет налаженных коммуникаций, нет «зоны комфорта». Нам нужны те, кто в хаосе не тонет, а, наоборот, видит возможности там, где другие видят бардак.
5. Честность и зрелость
Ошибаться можно. Не признавать ошибки — нельзя. В стартапе цена ошибки высока, но цена сокрытия проблемы — ещё выше. Мы ищем взрослых людей, которые способны сказать: «Я накосячил, давай чинить», а не прятать голову в песок или искать виноватых.

4 фишки собеседований в стартап: наши секреты

Лично я собеседую кандидатов только на ключевые должности в проектах — руководителей, кофаундеров, лидеров направлений. Для меня важно проверить, есть ли у человека предпринимательское мышление, готов ли он брать ответственность и как относится к рискам.
Что касается остальных сотрудников, их собеседуют руководители на местах. Раскрою несколько наших «фишечек».

1. Собеседование — почти что кастдев
Фокус не на былых «заслугах», а на том, как человек решал конкретные задачи в прошлом. Мы предлагаем наши актуальные кейсы: интересно, как человек работает с цифрами и воронками. Хороший тест: «Расскажи бабушке, что такое ROMI» (или другая метрика — в зависимости от профиля). Умение принять нестандартную задачу, спокойно её решить, приложить креатив — это и есть софты.

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

3. Тестовая неделя вместо долгого вливания
Собеседование — процесс двусторонний, ошибиться могут обе стороны. Поэтому, помимо испытательного срока, у нас есть понятие «тестовая неделя». По итогам первой недели куратор делает вывод о работе подопечного и проводит беседу с ним. Если всё ок — работаем дальше. Если нет — расстаёмся безболезненно. Примерно 5% кандидатов, прошедших собеседования, отсеиваются по результатам тестовых недель.

4. Два крутых кандидата на одну вакансию? Берём обоих!
Бывает так, что есть сразу два сильных кандидата на одну должность. У нас была практика — делать предложение сразу двоим. И, кстати, бывали случаи, когда в компании оставались оба. Для софтового и грамотного сотрудника работа найдётся всегда. Такой подход позволяет привлекать как можно больше компетентных ребят и усиливать команду.

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

И вправду, коммерческой логики в этом не очень много. Да, в Ульяновске есть ИТ‑компании и достаточно развитая ИТ‑индустрия, но в соседних, более крупных городах, очевидно, что специалистов больше. Если говорить про Москву, так больше на пару порядков. И очевидно, что такого объема мероприятие, где более 300 крутых спикеров, но проведенное в Москве, будет успешнее, чем в Ульяновске.

В 2012 году, в Ульяновске, мы встретились с основателями несколькими ИТ‑компаний и захотели, чтобы люди в городе начали обмениваться практическими знаниями. Нам хотелось, чтобы в городе было больше квалифицированных специалистов, чтобы рождалось больше успешных компаний. Но даже тогда некоторые ИТ‑компании говорили, что у нас ничего не получится, не верили в нас, боялись говорить сотрудникам о мероприятии(вдруг схантят). 

Но мы росли, развивались и к 2019 году собрали на площадках Ульяновска и Иннополиса более 6000 участников, объединив специалистов со всей страны. В 2020 году пришла пандемия и мероприятия запретили проводить. 

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

Сейчас индустрия переживает сложные времена. Мы понимаем, что для многих ИТ-компаний и ИТ‑специалистов сейчас непростое время. Мягко говоря, не до развития. Но мы чётко уверены, что именно такие времена и порождают что‑то новое, прорывное, именно сейчас мы, как мероприятие, очень нужны. Где ещё можно узнать на самом деле, что происходит в индустрии? Где ещё понять, какие возможности открываются?

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

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

Стачка — это в первую очередь наша крутая команда, ребята — вы лучшие. 

Огромное спасибо вам за ежедневный труд!

Нас поддерживают и помогают много ребят, огромное спасибо, что вы с нами! 

И да, мы будем продолжать делать Стачку в Ульяновске. 

Для каждого, кто читает этот пост.

Stop working! Все на Стачку!

10–11 апреля, Ульяновск.

MVP на обкатке: как мы запустили сервис обработки звука на ИИ

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

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

Первые метрики

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

В первый месяц, на этапе настройки рекламных кампаний, проект вышел на положительный ROMI в районе 35%. К концу второго месяца этот показатель удалось увеличить почти вдвое — в основном за счёт накопления данных о целевой аудитории и более точной настройки каналов привлечения.

Эволюция продукта

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

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

Динамика потребления

Показатели использования сервиса также демонстрируют устойчивый рост. За первый месяц было обработано около 200 часов пользовательского аудио. Ко второму месяцу этот объём увеличился практически вдвое.

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

Что дальше

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

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

Как вы знаете, мобильный интернет стал нестабильным последнее время, поэтому в поезде у меня появилась возможность посмотреть, что же я там скачивал почитать, когда появится время. И наткнулся на книгу: «Founders at Work [Stories of Startups' Early Days]» — 2008 года. Фактически эта книга рассказывает про яркие, выстрелившие стартапы в долине с 1980 по 2006 год примерно.

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

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

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

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

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

ИИ-разработка. Темп

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

Мне говорят, что 90-95% разработчиков не используют ИИ. Мне тяжело в это поверить. Я скорее поверю, что они это скрывают. Ни самим разработчикам, ни IT-компаниям невыгодно рассказывать о возросшей эффективности. Мы еще поговорим как-нибудь об этом. А пока держите эффективность моей разработки.

✔ Только что я закончил весьма тяжелый переход к новой архитектуре данных в своем проекте lanchess.ru

👀 И занял этот переход у меня 2 дня! (если считать сегодня, то 3)
Стоило это мне 10 тыс строк кода и массы тестов (и тд и тп).

А теперь внимание.
Сколько времени эта же работа заняла бы без использования ии-инструментов?
Ответ: 16-26 рабочих дня.

💥 2 дня против 1 месяца работы!

Вы пока думайте, что сказать, а я пошел дальше работать 🙂

Всегда ваш, Ланчев PRO ИИ

Регламентирование процессов в стартапе: когда и как?

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

Когда имеет смысл создавать регламенты?

Если у вас 3 сотрудника и 10 клиентов, смысла делать лишнюю работу нет. Если вы еще не выпустили MVP и процессы не то чтобы не отстроены, а они нормально непредсказуемы, регламентировать тоже нечего. А вот когда, например:

‑вы ловите себя на мысли, что в пятый раз разжёвываете сотруднику одно и то же;
‑повторяются ситуации, когда один сотрудник что‑то не передал другому;
‑новичок онбордится дольше 2-х недель,

то это все поводы начать регламентировать.

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

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

Вопрос о создании регламента (либо методички, инструкции) выносится на обсуждение Советом Управляющих вместе с участниками процесса. Если задача касается очень многих сотрудников компании, мы выносим это на общее обсуждение в чат. После этого ответственному (чаще всего это офис‑менеджер) ставится задача — сформировать документ, где будет описан весь процесс от и до.

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

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

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

Еще один важный момент: стартап — это всегда гибкая структура. Даже регламентирование не должно сделать процессы «застывшими». Оно призвано облегчить работу, сделать результат предсказуемым и в какой‑то степени стандартизировать его. Однако важно не скатываться до бюрократии. Мы регулярно напоминаем сотрудникам о том, что регламенты можно менять, указывать на несоответствия, предлагать изменения, и, кстати, многие ребята такими возможностями пользуются.

Если интересно что‑то еще о регламентировании процессов, задавайте вопросы в комментариях!

Сейчас делаем пилот сразу для нескольких заказчиков. Рабочее название — «Суперраспознавалка» :))

Основная задача: настроить TAPe-модель на датасет типа COCO под задачу detection. Вторая — дать клиентам возможность добавлять собственные классы к уже существующим. Ну и далее, при необходимости, полная адаптация модели под конкретного заказчика. Поскольку у нас есть Теория активного восприятия с ее методами, на выходе заказчик должен получить кратную эффективность и кратную экономию ресурсов.

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

Некоторые проекты — NDA, когда буквально нельзя указывать точное название объектов, которые нужно детектировать. Поэтому не обессудьте. Ноу‑хау по‑прежнему не собираемся раскрывать. Только результаты и часть пути к этим результатам.

День 1. TAPe и YOLO

Закончили с базовой структурой для сегментации, то есть с тем, как за один «ход» получать необходимый набор патчей, чтобы дальше расчёты шли параллельно (и оттуда же быстро), что также немного подводит ближе к самой логике действий здесь. Сейчас за одно действие получается определить все точно‑неинтересные места, а также все возможно‑интересные места (то есть, где есть детали в целом).

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

• Необходимость классификации буквально каждого пикселя (как поступают стандартные современные модели семантической сегментации);

Стандартные модели буквально классифицируют каждый пиксель (или каждый N‑ный пиксель, если сжимают разрешение) на отношение к тому или иному классу. 

• Необходимость проверять каждый шаг в какой‑то ограниченной сетке размером N на N (так делает конкретно YOLO)

YOLO обходит это использованием сил CNN, классифицируя только конечное количество патчей (зависит от версии YOLO, в первой их было 6400, что всё равно много). Методы TAPe же нам позволяют этого не делать, потому что единицы информации в TAPe (которые мы назвали T‑bit) несут в себе гораздо больше информации, чем бит. В данном случае — несут в себе нужную структуру для нахождения похожести — а значит для нахождения сегментов, в которых нужно что‑то классифицировать в целом. И даже здесь благодаря TAPe у нас есть преимущество: мы можем проводить классификацию на условном нулевом уровне, не уходя в глубину.

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

Антарктическую площадку на Беллинсгаузене ставим на паузу до доп. согласований

Запуск площадки RUVDS в Антарктиде задерживается — мы вынуждены временно остановить работу оборудования на станции Беллинсгаузен.

Перенос сроков не связан ни с «железом», ни с каналом связи. Сервер, питание, связь/сеть — всё это было и остаётся рабочим. Вопрос в организационном моменте.

Что случилось:

1. Оборудование несколько месяцев «гонялось» в тестовом режиме (стабильность, связь, удалённое администрирование, «а что если…» сценарии в условиях станции).

2. Только после того, как тесты показали, что решение можно эксплуатировать, мы открыли публичный доступ и дали всем желающим возможность попробовать VM в Антарктиде.

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

Варианта «просто продолжать как было» у нас нет: площадку нужно остановить до завершения согласований и отдельного уведомления о возможности возобновления эксплуатации.

Что это значит для пользователей, которые успели взять VM:

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

• Всем, кто оформлял антарктический VM, мы отправим отдельное уведомление с дальнейшими вариантами (например, перенос/компенсация/опции касательно данных — в зависимости от сценария и того, что технически успеем корректно осуществить).

Приносим искренние извинения за смещение сроков: понимаем, что многие пришли именно за «сервером в Антарктиде», и нам самим досадно сворачивать публичную часть проекта в момент, когда она уже заработала. Но выполнение всех требований площадки и регуляторов — это приоритет. Мы хотим быть на все 100% уверены в соблюдении всех процедур, чтобы предоставить вам тот уровень сервиса, который вы привыкли получать.

Будем информировать вас о поступлении новых сведений по статусу проекта: обновим пост и напишем отдельно.

Благодарим за внимание.

Пол Грэм — Век бренда. Перевод эссе

В 1970-х кварц сделал механические часы технически бесполезными. К 1990-м они стоили дороже, чем когда-либо в истории.

Новый перевод эссе Пола Грэма «Век бренда» — о том, как это стало возможным, и что это говорит о природе брендов вообще.

Грэм делит историю часового дела на три эпохи: золотой век (1945–1970), когда лучшие часовщики соревновались в точности и тонкости; кварцевый кризис (1970–1985), когда индустрия рухнула; и эпоха бренда (1985 — наше время), когда выжившие переосмыслили, что они вообще продают.

Переход от второй эпохи к третьей — не стратегия, а нащупывание в темноте. Грэм по шагам восстанавливает, как Patek, Audemars Piguet и Rolex случайно изобрели новую бизнес-модель: продавать не инженерное мастерство, а право принадлежать к клубу тех, кто может себе это позволить. И как эта модель в итоге потребовала от них вещей, которые звучат как антиутопия — контроля над покупателями, выкупа собственных часов на аукционах, управления пузырём активов.

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

Сразу же обновил сборник и добавил туда эссе.