Бизнес-модели *

Я отвечаю за процессы и репутацию (SERM). Раньше мы отдавали по 40–50 тыс. рублей в месяц за enterprise‑сервисы мониторинга. Но платить столько ради пары десятков упоминаний продукта в день — это забивать гвозди микроскопом.

Задача: прилетел негатив — мы моментально об этом узнали. Я спроектировал логику, а разработчик собрал инструмент. Архитектура простая, но на 100% закрывает боли.

1. Сбор данных
Свой парсер на Python. Где площадки отдают данные по API — берем напрямую. Остальное тянем через Selenium с ротацией прокси от банов.

2. Оценка сарказма
Классический текстовый анализ сыпался на фразах вроде «Отличный сервис, ждал ответа сутки, спасибо!». Подключили LLM по API. Принципиально не брали тяжелые флагманы — для задачи «ругают/хвалят» они избыточны и дороги. Взяли легковесную gpt-4o-mini. Она щелкает скрытый негатив идеально, а косты режутся в десятки раз.

3. Алерты
Если нейронка видит проблему (например, баг на чекауте) — скрипт через aiogram кидает пуш в рабочий Telegram со ссылкой на отзыв.

Итог: время реакции на негатив сократилось с 2 дней до 1 часа. Бюджет — около $5/мес на токены и копейки на VPS.

А как вы решаете задачу мониторинга своих продуктов? Платите за YouScan/Brand Analytics или собираете внутренние велосипеды?

Как Anthropic хитрит с цифрами выручки 

TLDR: в медиа запускают новости о $14 млрд run rate выручки в год. А в суде сообщают о $5 млрд ЗА ВСЕ ВРЕМЯ.

На днях Anthropic подал иск в суд на Министерство Войны США (pdf), и в нем CFO компании сообщил, что за все время существования компании на рынке, она сделала $5 млрд выручки. Не прибыли! При этом на инференс и тренинг потратила $10 млрд.

Это все ок, если бы не публичные заявления компании про $14 млрд выручки (run rate). Через три недели мы узнали уже о $19 млрд annualized run rate (bloomberg). Вау! Неопытные читатели (которых большинство) воспринимают это как уже полученную выручку за год. Что со стороны компании является введением в заблуждение.

Но даже тут дополнительный уровень жопокрутства: 

Run rate — это предполагаемая выручка, когда берут даже не последний период, а иногда лучший месяц, и умножают на 12. Согласно источникам Reuters, Anthropic считает run rate так: (месячные подписки)x12 + (оплата токенов за 28 дней)x13.

Очевидно, что с $5 млрд за все время, Anthropic черрипикнули выручку так, что мама не горюй.

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

А честные $5 млрд выручки Anthropic (за все время на рынке!) — это меньше, чем продажи airpods за пару месяцев.

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

Главные приоритеты выстроены следующим образом: сначала безопасность (например, запрет на создание вирусов или оружия); далее следуют нормы морали («хорошее поведение»), затем интересы самой компании Anthropic, а помощь пользователю ставится лишь на последнем месте.

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

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

тут (https://www.anthropic.com/news/claude-new-constitution) статья в блоге Anthropic
тут (https://www.anthropic.com/constitution) полный текст конституции

У меня не сходится логика RACI матрицы :(

Роли С и I - прекрасны, поэтому оставим их за бортом вопроса.

В моей картине мира есть Заказчик, Ответственный и Исполнител(ь,и).

• Заказчик (может быть внутренний) - принимает результат по требованиям.

• Ответственный - обязуется обеспечить соответствие целостного результата всем требованиям.

• Исполнители - делают руками.

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

Собственно во что я всё никак не могу въехать:

Буквы R и A из матрицы - не ложатся на привычную схему... Если нет Заказчика - (может быть даже внутреннего) - работа бессмысленна...

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

Если же А-из-матрицы это Ответственный за целостный результат, тогда в схеме нет Заказчика, который принимает результат по требованиям и работа становится бессмысленной...

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

Если R-из-матрицы это Исполнитель, который делает руками, и он тут называется Ответственным, то в случае нескольких исполнителей на проекте возникает соблазн спихивать эту ответственность друг на друга, что не конструктивно и без роли "главного" - матрица не помогает прочертить границы в этой ответственности.

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

У кого получается с пользой применять RACI - можете объяснить с какой стороны это кушается? Или это просто сладкая дичь для говорящих голов?

Компания Zhipu AI совместно с Университетом Цинхуа представила одну из важнейших открытых моделей 2026 года — GLM-5. Это не просто инструмент для написания кода, а полноценная система, способная самостоятельно планировать проекты, создавать код, проводить тестирование, устранять баги и улучшать решения в течение длительного времени.

Основные характеристики GLM-5 впечатляют:
- Архитектура MoE с общим количеством параметров 744 миллиарда, из которых одновременно активируется лишь 40 миллиардов.
- Контекст длиной до 200 тысяч токенов позволяет хранить целиком большие кодовые базы.
- Первый открытый релиз с оценкой 50 баллов по индексу AAI.
- Лидирует среди открытых моделей в тестировании LMArena (оценка текста и кода).
- По уровню производительности сравнима с закрытыми моделями уровня Claude Opus 4.5 и Gemini 3 Pro.

Изначально модель была выпущена анонимно под именем Pony Alpha, вызвав предположения, что это продукт от крупных западных компаний вроде DeepMind или OpenAI. Однако вскоре выяснилось, что разработка принадлежит китайской стороне, подчеркивая значимость проекта.

Технические особенности включают:
- Обучение на массиве из 28,5 триллионов токенов.
- Использование технологии Sparse Attention, снижающей вычислительные затраты на обработку больших объемов контекста.
- Асинхронный метод обучения с использованием RLHF, позволяющий эффективно задействовать ресурсы GPU.
- Трехступенчатое обучение, включающее этапы рассуждений, агентирования и выравнивания.

Практические достижения:
- Высокий показатель успешности тестов на платформе SWE-bench Verified (77,8%) и лидерство в тесте BrowseComp (75,9%).
- Модель обучалась на большом количестве репозиториев GitHub (более 10 тыс.).
- Способность успешно управлять бизнес-процессами, включая моделирование реального бизнеса (например, сеть торговых автоматов).

Особенность GLM-5 заключается также в оптимизации под китайские процессоры Huawei Ascend, Cambricon и Kunlun, обеспечивающую производительность, аналогичную западным платформам, но с экономией примерно на 50%.

Таким образом, появление GLM-5 свидетельствует о том, что разница между открытыми и проприетарными системами практически исчезла. Открытые модели теперь способны решать реальные инженерные задачи на мировом уровне, работая на собственном оборудовании и показывая конкурентоспособные результаты.

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

https://arxiv.org/abs/2602.15763v2

ВК: https://vk.com/wall-222544138_412

Tenchat: https://tenchat.ru/media/4986873-glm5

TG: https://t.me/DenoiseLAB/4063

Не пойму — чего за кипишь? Или почему ИИ — это просто новый «питон»

Последнее время из каждого утюга кричат: «ИИ заменит программистов!», «Джуны больше не нужны!», «Учитесь на сантехников, пока не поздно!».

Давайте выдохнем, отставим смузи и разберемся по-простому, «на пальцах», что вообще происходит.

1. Программист — это не «печатающая машинка»

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

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

2. Эволюция «костылей»

Вспомните историю. Раньше писали на перфокартах. Потом на Ассемблере. Потом на Си, потом на Питоне. Каждый раз кричали: «Ну всё, теперь порог входа стал таким низким, что программисты не нужны!». И что? Программистов стало только больше. Просто мы перестали думать о том, в какой регистр положить байт, и начали думать о том, как построить архитектуру сервиса.

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

3. Проблема «идеального мусора»

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

4. ИТ-поликлиника

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

А кого вообще не заденет? (Спойлер: Работы будет завались)

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

• Архитекторы сложных систем (System Architects): ИИ может нарисовать типовой домик. Но построить небоскрёб на болоте, учитывая старое «дырявое» железо, бюджет заказчика и планы на 10 лет вперёд... ИИ не видит контекста «выживания» системы, он видит только код.

• Инженеры кибербезопасности (SecOps): Тут идёт вечная война хитрости. ИИ может искать паттерны, но он не может предугадать нестандартный «выверт» хакера-человека. Безопасность — это интуиция и паранойя, а у нейронок с этим туго. Гы)))

• SRE и DevOps (Те, кто спасают сервера в 3 часа ночи): Когда у системы «инфаркт», данные текут, а клиенты кричат — нужен человек с железными нервами, который примет решение «резать или шить». ИИ в критической ситуации может просто выдать ошибку 404, потому что такого случая не было в его обучающей выборке.

• Бизнес-аналитики и «Психотерапевты заказчика»: Это те, кто переводят с «бреда руководства» на человеческий. ИИ никогда не поймет, почему директор хочет «кнопку как у конкурентов, но чтобы она была синей, но красной».

• Процессные аналитики (BPM): Они рисуют, как ходят бумажки и данные между отделами. ИИ учтёт, что бухгалтер Марья Ивановна просто не отдаст отчёт вовремя, потому что обижена на айтишников?

  Итог

Ребята, расслабьтесь. Программирование не умирает, оно взрослеет. Уходит эпоха «кодинга ради кодинга». Наступает эпоха Качества Мышления. Теперь важно не то, насколько быстро ты стучишь по клавишам, а то, насколько структурированно ты умеешь формулировать смыслы.

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

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

Понял когда можно начинать увольнять сотрудников!

Внедрение искусственного интеллекта в рабочие процессы сегодня идет по двум принципиально разным сценариям:

• Как усиление человека

• Как замена человека в процессах

1. ИИ как “экзоскелет”

В этой роли ИИ выступает в качестве персонального ассистента или “второго пилота”. Сотрудник выполняет свои функции, но использует нейросети для ускорения рутины, преодоления ограничений или усиления экспертизы. 

Плюсы подхода:

• Низкий порог входа: Часто это просто подписка на сервис.

• Гибкость: Сотрудник сам решает, когда и как включить экзоскелет. 

• Контроль качества: Человек остается в контуре, фильтруя галлюцинации и ошибки ИИ.

• Удовлетворенность сотрудников: Позволяет сосредоточиться на творческих и сложных задачах.

Ограничения:

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

• Зависимость от навыков: Эффективность зависит от цифровой грамотности сотрудника.

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

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

2. ИИ как “автономные агенты” (Цифровые сотрудники)

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

Плюсы подхода:

• Масштабируемость: Можно “нанять” тысячи цифровых сотрудников быстрее, чем обучить живых людей.

• Скорость: Агенты работают 24/7 и обрабатывают информацию в разы быстрее человека.

• Стандартизация: Исключается человеческий фактор - результат всегда предсказуем и соответствует заданному шаблону.

• Непрерывность: Цифровые сотрудники не болеют, не уходят в отпуск и не выгорают.

Почему этот подход сложен:

• Должна быть зрелость процессов: Бизнес-процесс должен быть описан, формализован и оцифрован. Автоматизировать хаос невозможно - ИИ его только приумножит.

• API и доступ к данным: У агента должен быть легальный и безопасный доступ к информационным системам компании. Критически важно четко разграничить уровни доступа агента.

• Система валидации: Ошибки должны отлавливаться автоматически, либо процесс должен строиться по принципу Human-in-the-loop (человек проверяет ключевые действия перед финальным одобрением).

Итог

Экзоскелет делает конкретного сотрудника сильнее и быстрее здесь и сейчас. Автономный агент делает бизнес в целом сильнее и независимее от количества человеческих ресурсов.

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

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

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

"Знание некоторых принципов избавляет от необходимости знания многих фактов"

Эту прекрасную фразу приписывают Гельвецию (хотя и не только ему).

Автора попытался указать, поэтому можно переосмыслить так, как мне еще больше нравится:

"Знание базовых принципов помогает сэкономить на множестве неудачных экспериментов"

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

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

</скрип суставов>

Менеджмент — не для малого бизнеса

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

• владелец не имеет личного контакта с каждым сотрудником - ни пнуть, ни похвалить - как обеспечивать динамику работы?

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

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

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

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

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

Вот и получается, что малый бизнес оптом игнорирует всякие MBA и доверчиво падает в объятия инфобиза, которые на доступном языке преподносят банальности вроде: "Вот тебе топор. Размахиваешься и рубишь. Получилось? Повтори! "

И вот я подошел к двум очень важным моментам:

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

2. Без профессионального менеджмента вырасти из штанишек малого бизнеса - без шансов...

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

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

Открываем регистрацию на GoCloud 2026 — конференцию про AI и облака 🦾☁️

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

Что вас ждет

• 4 трека про AI, Data, инструменты разработки и облачную инфраструктуру

• 40+ спикеров

• Демозоны сервисов

• Практические воркшопы

• Нетворкинг и afterparty

Что узнаете

• Какие инструменты позволяют использовать AI без кастомной разработки и долгой настройки

• Как бизнес уже работает с AI-системами и какие результаты получает от их внедрения

• Тренды в AI, облаках и работе с данными, а также подходы, которые становятся стандартом для бизнеса

• Сценарии использования сервисов, готовые инструменты и способы оптимизации затрат в ваших проектах

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

Как принять участие

Можно посмотреть трансляцию на сайте (ссылка придет зарегистрированным участникам в письме) или прийти в кинотеатр «КАРО 11 Октябрь», ул. Новый Арбат, 24 в Москве. Собираемся 9 апреля в 10:00. Количество мест для офлайн-участия ограничено. Регистрируйтесь уже сейчас.

👉 Зарегистрироваться на GoCloud 2026

Постепенно будем рассказывать о программе, а пока можете почитать, как прошли предыдущие конференции Cloud.ru:

• Как прошла GoCloud 2025 — масштабная IT-конференция про облака и AI. Делимся итогами

• Бороздим облака будущего: впечатления айтишника о конференции GoCloud

• Что думают технические лидеры и инженеры о будущем с AI: репортаж с IT-конференции GoCloud Tech 2025

GlowByte проведет вебинар “Как повысить точность планирования в 2026 году”

Спрос меняется молниеносно, а планы устаревают, пока их согласовывают. Знакомо?

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

Для кого вебинар?

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

• повысить точность планирования без роста штата,

• уйти от Excel-моделей,

• получить единый, согласованный план по всей цепочке.

На вебинаре разберем:

• Demand Planning — как улучшить прогноз спроса.

• Replenishment Management — как продуктивно управлять запасами.

• Transportation Load Building — как эффективно формировать заказы.

• Ключевые KPI 2026-2030: точность прогноза, ускорение планирования и своевременная реакция на изменяющийся спрос.

• Что сегодня мешает компаниям достичь прозрачности и управляемости — и где именно IBP закрывает этот разрыв.

Чем этот вебинар отличается от других?

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

17 февраля 2026 г., 13:00 (МСК).

Участие бесплатное, необходима регистрация.

Бесплатный акселератор, неожиданные грабли и куча выпитых чашек кофе: как мы проверяли гипотезы в IT‑стартапе

Привет, Хабр!

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

Нас четверо: бэкенд, фронтенд, дизайнер и QA. Годами работали в аутсорсе, делали понятные продукты по четким ТЗ. А потом в один день задались вопросом: "А чего это мы всё делаем проекты другим? Пора попробовать своё".

В прошлом году мы залетели в акселератор Южного IT-Парка (бесплатный, что важно). Опыт был яркий: где-то больно, где-то смешно, а где-то мы просто осознали глубину своего заблуждения.

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

Ошибка №1: Наш "MVP" оказался "MIP" (Minimum Imaginable Product)

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

Инсайт пришёл, когда ментор спросил: "Вы поговорили хоть с одним потенциальным пользователем?". Мы промолчали. Мы потратили месяц на то, что на деле было "минимально вообразимым продуктом" - тем, что мы могли вообразить и построить, а не тем, что было минимально необходимо для проверки ключевой гипотезы.

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

Ошибка №2: Мы недооценили силу еженедельных дедлайнов

Акселератор - это не про деньги (по крайней мере, в нашем случае). Это про дедлайны и сообщество.

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

Инсайт: Привычка "идеально доделать и потом показать" убивает скорость обучения. "Криво, но сейчас" стало нашим неофициальным девизом. Эти еженедельные отчёты заставляли нас постоянно задавать себе вопросы: «Что мы узнали на этой неделе? Какая гипотеза подтвердилась? Что будем пробовать дальше?».

Ошибка №3: Мы пытались работать "как раньше"

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

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

Инсайт: Стартап - это не проект, это режим работы, где все немножко product owner и немножко предприниматель. Наша привычка "делать свою часть идеально" часто мешала сделать "целое достаточно быстро".

И что в итоге? Стоило ли оно того?

Пока не знаем.

Заработали ли мы на пачку чипсов? Нет.
Кончился ли кофе? Да, много раз.
Получили ли мы то, за чем шли?

Абсолютно да.

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

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

P.S. Если вы тоже думаете о своём продукте или уже на этом пути — делитесь в комментариях, с какими граблями столкнулись вы?

Импортозамещение по-бразильски.  

Пост из серии «никогда бы не подумал». Если попросить назвать крупных производителей самолётов, то скорее всего (не беря советских/российских конструкторов) услышишь названия Boeing, Airbus и Embraer. И вот про последнего я всегда думал, что это какая-то европейская компания, пока не узнал, что это аббревиатура Empresa Brasileira de Aeronáutica. Стереотипно, но я в жизни бы не подумал, что именно Бразилия всего за несколько десятилетий создала одного из лидеров авиапромки.Немного оправившись от удивления, я, само собой, решил понять, как такое вообще получилось и что стало причиной такого вертикального роста:

1. Embraer начиналась как госкорпорация в 1969 году (что по меркам такой индустрии не то чтобы очень давно), которую запускало правительство и ВВС Бразилии. Там люди поняли, что зависимость от авиагигантов — дело опасное и надеятся на то, что Boeing и Airbus не будут выкручивать руки целой стране - вообще не стоит. Ну и при этом страна гигантская, и её концы надо как-то соединять, чтобы удаленные участки не оказались отрезанными от ключевых хабов и центров. Причём желательно соединять их дёшево и надёжно, так как экономическая ситуация в Бразилии не самая простая.

2. В итоге был быстро создан простой и надёжный турбовинтовой самолёт EMB 110. Модель была настолько крутой, что её начали активно покупать американцы, французы, канадцы. Особенно для того, чтобы перевозить пассажиров из малых городов и связывать хабы с малыми локациями. Самолёт был небольшим, неломким и очень рентабельным по сравнению с монстрами Boeing и Airbus. Сыграло роль правильное ТЗ. Нужно было не чудо на крыльях, а рабочий инструмент, который закроет базовые потребности перевозки. Плюс ко всему у руля проекта стоял Озорио Сильва — инженер, военный лётчик и фанат авиации, собственно, что и позволило сделать крутой продукт.

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

4. Параллельно с этим между Boeing и Airbus была война гигантов. Они как одержимые пытались переплюнуть друг друга в огромных лайнерах, игнорируя небольшие самолёты. Ребята из Embraer быстро поняли, что спрос — вот он, и запустили E-Jets, которые быстро решили головную боль многих авиаперевозчиков, которым вообще не нужны были джеты на 300 мест. Принцип был похожий с первым их проектом: надёжно, дёшево и удобно для пассажиров.

5. Уже в 2000-х они пошли по пути диверсификации, продолжая работать с коммерческими самолётами, партнерились с ВВС и запустили бизнес-джеты, которые вообще были золотым дном. До сих пор направление бизнес джетов имеет огромную маржинальность.

6. При этом, будучи в стране с крайне непростой экономической ситуацией, они активно внедряли lean (бережливое производство), так как надо было добиваться крутого качества за приемлемые деньги. Таким образом, они стали одними одними из амбассадоров концепта lean (не все Тойотой единой)

Вот так вот. По итогу Embraer устроил такой забег: от госкорпорации ради импортозамещения, через приватизацию, до корпорации, которая по разным типам самолётов держит от 40% до 70% рынка и продолжает уверенно развиваться.

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

Почему IT продукты дорожают но их реальная ценность падает?

Почему так происходит и справедливо ли это по отношению к пользователю?

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

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

Почему падает реальная ценность
Ценность продукта построена на механиках и фичах
Некоторые фичи дают реальную ценность, возможно не именно нам, но дают. Некоторые дают ценность, но не там где нужно (супер аппы).
А вот фичи с псевдоценностями просто есть и дают только прирост цифр бизнесу.

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

Продают обманом – Бизнес выстраивает маркетинг на псевдоценностях. Для этого он подменяет понятия и запутывает клиента, чтобы он не понял что эта фича несет ценность только для бизнеса, а для него нет. И ведь это не всегда происходит осознано! Иногда бизнес обманывает и сам себя выпуская таки фичи в релиз (.
Не будем упоминать недобросовестное списание денег по причине "потому что мы так решили"

Но самое абсурдное это когда бизнес решает проблему которую сам и создал :(

Пример
В пятёрочке постоянно крутят объявления в аудио формате. Недавно я услышал такую запись – пятерочка заботится о вас, поэтому мы дарим вам пять минут тишины. Сами создали проблему, сами ее решили, а выдают за ценность.

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

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

Вывода в этом посте нет, этот просто открытое рассуждение.

Что думаете об этой проблеме и с чем сталкивались? Делитесь в комментариях 👇

Если хотите упаковать ценности вашего продукта качественно, записывайтесь на бесплатную консультацию, тут на Хабре https://career.habr.com/product-unit

Данные есть, ясности нет: как принимаются сложные решения в IT

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

Со стороны кажется, что проблема в расчётах.
На практике гораздо чаще она в другом.

Когда информации достаточно, но решения всё равно «ломаются»

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

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

Решения приходится принимать в условиях неопределённости, без возможности проверить модель в натуральных условиях заранее.

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

В этот момент формально решение ещё обсуждается, но фактически оно уже принято.

Почему опыт и интеллект не всегда спасают

Парадоксально, но чем выше уровень экспертизы, тем изощрённее могут быть рационализации.

Мозг легко находит логичные объяснения, почему нужно ускориться, почему риски допустимы, почему «потом разберёмся».

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

О паузе как инструменте управления

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

Пауза не даёт готового ответа и не снимает неопределённость. Но она возвращает управление из режима реакции в режим осознанного решения.

Когда паузы нет, решение принимается автоматически: из тревоги, из защиты, из спешки.

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

Почему это важно в IT (и не только)

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

Устойчивость систем, команд и бизнесов начинается не с идеальной аналитики, а со способности выдерживать неопределённость и не торопиться «закрыть вопрос» любой ценой.

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

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

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

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

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

Начнем с избыточности. Одно дело когда у вас команда из 50 человек, где есть и фронты и бекендеры и девопсы и бог знает кто еще. Другое, когда вся команда это три человека с очень разными компетенциями. Если в команде один бекендер, то его никем не заменить. Тоже самое касается и большинства остальных ролей. Всегда нужен человек, который отвечает за свой блок и разбирается в нем лучше всех (или в принципе только он и разбирается). Такому человеку ИИ конечно помогает, но убрать его с помощью ИИ невозможно, как бы красиво это не звучало и не выглядело (посмотрите как я сгенерил лендинг с помощью ии!).

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

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

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

Больше про разработку в моем телеграм-канале Организованное программирование

Часто ли вы смотрите фильм «Одиннадцать друзей Оушена» как учебное пособие? А стоит. Потому что команда, которую собрал Дэнни — это не просто группа авантюристов, а идеально сбалансированный стартап. В нём нет случайных людей, только нужные роли.

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

Дэнни Оушен здесь — классический CEO, визионер и конечный ответственный. Он видит цель, набирает звездную команду и держит в голове общую картину, даже когда всё летит в тартарары.

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

А дальше начинаются ключевые департаменты. У них есть свой технический гений — Ливингстон Делл (фактически CTO) и инновационный отдел снабжения в лице Бэшера Тарра. Есть даже свой глава службы безопасности и по совместительству HR в лице Фрэнка Каттона, а «Грек» следит за качеством работы и атмосферой в коллективе. И конечно, логист Сэдлс, который отвечает за то, чтобы все оказались в нужном месте в нужное время.

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

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

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

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

Команду Дэнни Оушена интересно разобрать не только как сборник ярких персонажей, но и как тонкий социальный энергетический механизм. В ней Альфа - сам Дэни — лидер, задающий цель. Бета (Расти) — его правая рука, превращающая идеи в инструкции. Гамма — блестящие специалисты, идеально собирающие свою часть пазла. А Дельта — тёмная лошадка, скрытый ресурс, который раскрывается в самый нужный момент.

Именно в этой роли в команде Оушена выступает Лайнус Колдуэлл. И здесь раскрывается главный талант Дэнни как лидера — умение работать с энергией Дельты.

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

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

«Мстители» как кейс: что делать, когда в команде два босса и одна живая катастрофа

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

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

Между ними — Наташа Романофф, идеальная Бета. Пока Альфы спорят о будущем вселенной, она обеспечивает движение здесь и сейчас. Её роль — не принимать глобальные решения, а переводить их в конкретные действия, гасить конфликты и делать так, чтобы разрозненные специалисты начали работать как единый механизм. Без неё спор двух лидеров остался бы просто спором.

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

И тут мы подходим к главной проблеме — Брюсу Бэннеру, или, точнее, к Халку. Он не сотрудник, он — ходячая форс-мажорная оговорка в договоре. Скрытая ядерная кнопка, которую все боятся нажать. Сначала команда, и особенно системный мыслитель Старк, пытается с этой энергией справиться классически: подавить, игнорировать, использовать только безопасную часть — учёного Бэннера. Результат предсказуем: попытка контроля оборачивается катастрофой на Хелккэриере, когда Дельта-энергия вырывается наружу и обращается против своих же.

Гениальное решение приходит оттуда, откуда его не ждали — от инновационного Альфы, Тони Старка. Он первым понимает, что энергию Халка нельзя контролировать, запереть или игнорировать. Её можно только направить. Его знаменитая фраза «Сейчас бы прекрасный момент для того, чтобы разозлиться» — это не приказ. Это ритуальное разрешение, выданный кредит доверия разрушительной силе. Это момент, когда хаос получает легитимную цель.

Итог известен: Халк, бывший главной внутренней угрозой, становится ключевым оружием в битве за Нью-Йорк. Он сокрушает левиафанов и, что символично, одним ударом выбивает спесь с бога. Дельта не становится предсказуемой Гаммой — она остаётся собой, но её хаотическая сила теперь работает на команду, а не против неё.

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