Хороший продукт — это необходимое условие. Не достаточное.
Можно сделать понятный интерфейс, добавить нужные фичи, поставить конкурентную цену — и всё равно смотреть на конверсию 1,3% без понимания, что идёт не так.
Чаще всего проблема не в продукте. Она в том, как ваш пользователь принимает решения.
При работе с асинхронным кодом нам часто приходится обрабатывать CancelledError — сигнал отмены задачи. С точки зрения приложения это выглядит как обычное исключение — достаточно добавить try/except блок и продолжить работу. Хотя в большинстве случаев это и правда работает, иногда все же приходится копнуть глубже и разобраться, как устроен механизм отмены под капотом и для чего на самом деле нужен CancelledError.
Я делаю сайты и решил прикинуть размер рынка через Wordstat. «Создание сайтов» — 145 758 показов в месяц. Красивая цифра, под которую легко поверить «вот он, спрос». Но вместо того чтобы поверить, я выгрузил все вложенные запросы и разобрал их по смыслу. Реального «хочу заказать сайт» там оказалось около 3%. Ниже — как считал и что выяснил.
Выгрузил топ-2000 вложенных запросов по «создание сайтов» (и отдельно по «разработка сайтов», «заказать сайт», «seo продвижение») — это обычный CSV‑экспорт из Wordstat. Дальше — скрипт, который делит фразы на корзины: коммерция (есть модификатор покупки), (далее…)
Почему принятие решений во временных рабочих группах единолично руководителем не оптимально? Какие ещё имеются варианты принятия решений?
Это вторая статья об использовании LLM в проекте разработки компилятора языка программирования как транспилятора в код на C++. Я продолжаю историю и хочу рассказать о своих наблюдениях и впечатлениях от попыток применять автономных агентов в большом и сложном проекте. А также о навязчивой рекламе и встроенных «закладках» в коде некоторых инструментов, которые, похоже, целенаправленно ухудшают работу с моделями конкурентов.
В комментариях к первой статье (далее…)
Кейс: как я зашёл в 5 «мёртвых» T&M-проектов, которые никто не хотел вести, и превратил их в портфель на 1,5 года с ростом выручки в 5–6 раз
Ситуация: 5 проектов, от которых все отказались
Технологический контекст
Что я увидел внутри: боль трёх сторон
Что я сделал за первые 2 недели
Артефакт №1: Регламент взаимодействия
Артефакт №2: Детализация отчётности (как было → как стало)
Ключевые правила, которых не было в договоре
Результат: цифры, команда, перспектива
Главный инсайт
Code review (ревью кода) — отличный механизм для отлова багов и обмена знаниями, но вместе с тем это почти гарантированный способ создать «бутылочное горлышко» для всей команды разработчиков. Merge Request (MR) сутками висит в очереди, ревьюер рано или поздно отвлекается от своих задач, чтобы вникнуть в diff, оставляет пару мелких придирок к названиям переменных, автор отвечает, и цикл повторяется. В наших внутренних проектах медианное время ожидания первого ревью часто измерялось часами.
Лето — это маленькая жизнь. В бизнесе это выражение обретает буквальный смысл. Для одних проектов лето становится «золотой жилой», для других — периодом вынужденного затишья. Мы в стартап-студии хорошо знакомы с обеими ситуациями: большинство наших проектов имеют выраженную сезонность.
Очевидно, что к пику нужно готовиться заранее. А вот как использовать спад с максимальной пользой — вопрос, который мы каждый год переосмысливаем заново. В этом материале — наш взгляд на подготовку к обоим сценариям, основанный на практике последних лет.
В 2026 году софт всё чаще пишут с участием ИИ: по данным Stack Overflow, 84% разработчиков уже используют ИИ‑инструменты или планируют начать. При этом исследователи Faros AI фиксируют парадокс: в командах с активным использованием ИИ разработчики закрывают на 21% больше задач и на 98% больше мёржат PR, но время ревью выросло на 91%.
В статье разберём, как выстроить процесс проверки, который не съедает выигрыш от автоматизации и почему ревью ИИ‑кода нельзя полностью отдать моделям.
За консультацию при подготовке материала благодарим:
Обычно разработчики пользуются локальными IDE вроде VS Code или IDE от JetBrains со своим набором плагинов, настроек и собранным под себя окружением. Иногда — удалённой машиной. Но есть третий вариант, который пока многим непривычен и потому вызывает настороженность, — Cloud IDE, или CDE.
Закономерно возникают вопросы: а точно ли мои данные в безопасности? Есть ли в CDE все нужные компоненты для полноценной работы или это просто способ быстро заглянуть в код?