Потому что БЕЗ Качественной Отчетности и Полноценной Сквозной Аналитики вы регулярно принимаете ошибочные решения и упускаете до 80% результатов и прибыли.
Мысли про создание AI-агента, который будет помогать с "Важно, но не срочно" задачами. Часть 1
Последний месяц в сети хайпит OpenClaw (он же ClawBot, он же MoltBot).
У него есть доступы много куда — вы наверняка уже видели новости о том, как он самостоятельно тратит деньги или общается с женой (не своей)
Но меня интересует механизм работы его core feature — проактивности
Это первый масштабный агент, который не ждёт сообщения, а сам приходит и говорит: «Эй, я вот это сделал, глянь»
Я хотел собрать такого агента ещё год назад, когда обнаружил и начал исследовать Model Context Protocol, который дал моим LLM-кам доступ во внешний мир. Но тогда не хватило ни знаний, ни механизма.
Сейчас, благодаря OpenClaw, Claude Code + Codex стало понятнее, как именно это можно реализовать
И вот последнюю неделю я понемногу развиваю этот концепт
------------------------------
Суть в одном предложении AI-агент, который знает мои цели на год и выполняет первые, самые сложные 15% работы, которые приведут меня к этим целям в долгосрок.
Последние три года я работаю на себя. У меня нет начальника, который скажет «сделай к пятнице». Почти все мои перспективные задачи лежат в квадранте «Важно, но не срочно»
И чаще всего проблема не в том, что я не знаю, что делать, а в том, что мне впадлу начать
Ресёрчить варианты. Разбираться в деталях. Сделать первый шаг. Вот эти первые 15% — самый проблемный шаг для меня
Поэтому я подумал — а что если агент будет делать именно это?
------------------------------
Представьте, что агент каждый день приходит к вам с такими сообщениями
Нетворкинг и аутрич Учитывая твои финансовые и профессиональные цели, на этой неделе я советую тебе пообщаться с этими людьми. Я провёл небольшой ресёрч по каждому и подготовил персональное сообщение под каждого. Сделаешь до конца недели?
SEO и органика Я опять помониторил SEO твоего сайта и сайты конкурентов. Советую сделать A, B, C, D, чтобы мы подросли в органике. Вот конкретные правки с приоритетами
Контент и кросс-постинг Твой последний пост на LinkedIn набрал 10К просмотров — тема зашла. Давай этот пост ещё и в Threads, Instagram и на Хабр адаптируем? Вот три черновика под каждую площадку
Партнёрства Нашёл 8 владельцев продуктово-консалтинговых агентств, которые подходят под твой ICP. Отсортировал по релевантности. Вот топ-3 с кратким профилем и черновым сообщением под каждого. Первое можешь отправить прямо сейчас.
Мониторинг конкурентов [Конкурент] вчера выкатил новую фичу — вот что изменилось. Это может повлиять на позиционирование твоего продукта. Вот 2 варианта, как отреагировать: адаптировать лендинг или написать пост-сравнение.
Портфолио и резюме За последний месяц ты закончил 2 проекта и написал 4 поста. Вот обновлённая версия секции «достижения» для LinkedIn-профиля и сайта. Опубликуешь?
Здоровье Ты 4 месяца переносишь задачу "Записаться к стоматологу. Поэтому я решил действовать и нашел 3 клиники рядом с тобой с рейтингом выше 4.5, у двух есть слоты на эту неделю. Записать?
------------------------------
То есть агент не просто читает календарь — он понимает, что ему чего-то не хватает, и сам приходит за недостающим контекстом
Я хочу, чтобы агент не просто напоминал по моим задачам в календаре, а ресёрчил → структурировал → предлагал конкретный микро-шаг → спрашивал «актуально ли?»
Хочу чтобы конвертировал мои абстрактные хотелки из раздела «Важно, но не срочно» в конкретные day-to-day actions.
И это может работать не только для одного человека. Та же логика ложится на компанию: стратегические цели → первые шаги, которые никто не делает, потому что «не горит».
Пока это концепт. Но направление, в котором я копаю, кажется мне одним из самых интересных применений AI-агентов — не делать за тебя, а снимать барьер старта и помогать тебе двигаться к твоим Long Term Goals — по типу коуча/ментора
У подобного агента будут доступы к интернету и моему календарю. А общаться мы с ним будем через Telegram — видимо, как и с OpenClaw
Каждая третья фича не приносит ожидаемого эффекта. Частая причина — её запускают без проверки ключевой гипотезы. В результате — потраченные месяцы работы, бюджет и репутация команды.
26 февраля на практическом вебинаре «Как предотвратить провал фичи: чек-лист валидации гипотезы до разработки», вы получите готовое решение — структурированный чек-лист для валидации гипотез до старта разработки. Этот инструмент поможет вам сэкономить ресурсы и избежать ошибок, и он применим как в Agile, так и в Waterfall-среде.
Разберем на практике:
➕ Как появляются фичи: от боли бизнеса до решения.
➕ Что такое настоящая потребность и как её выявить.
➕ Ключевые метрики продукта и проекта для оценки.
➕ Факторы, влияющие на грамотную приоритизацию.
➕ Особенности требований в Agile vs Waterfall.
➕ Рабочие методы валидации требований из практики крупных компаний.
Дата: 26 февраля
⏰ Время: 18:00-19:00 (Мск)
👨🎓 Спикер: Басова Екатерина — эксперт по бизнес-анализу и управлению продуктами.
Подписывайтесь на канал AvitoTech в Telegram, там мы рассказываем больше о профессиональном опыте наших инженеров, проектах и работе в Авито, а также анонсируем митапы и статьи.
Можно тратиться на эксперименты и искать то, что сработает, чтобы затем повторять удачное. Это сейчас основа в обучении стартаперов и начинающих предпринимателей.
Но мне симпатичен другой вариант - когда знаешь, что инструмент точно сработает и не надо тратиться на бесполезные попытки.
"Знание некоторых принципов избавляет от необходимости знания многих фактов"
Эту прекрасную фразу приписывают Гельвецию (хотя и не только ему).
Автора попытался указать, поэтому можно переосмыслить так, как мне еще больше нравится:
"Знание базовых принципов помогает сэкономить на множестве неудачных экспериментов"
К чему это я - менеджмент развивается уже более столетия! Столько проведено исследований, придумано и апробировано новых подходов - рабочие группы собираются раз в несколько лет и переписывают отраслевые стандарты... вот только всё это не возбуждает новых падаванов грызть гранит науки управления...
Изобретение велосипедов и продвижение путем проб и ошибок - более симпатичный и простой подход.
Это способ организации файлов внутри вашего хранилища без использования папок.
Принцип работы:
Вы создаёте посадочные страницы для различных категорий заметок. Они могут быть пустыми.
Называете страницу, например, "00 Бизнес". Нули нужны для удобства навигации, чтобы файл всегда был вверху.
В заметки по теме бизнеса добавляете ссылку на заметку "00 Бизнес"
Включаете встроенный плагин "Обратные ссылки"
Результат! В заметке "00 Бизнес" в разделе "Упоминания со ссылкой" показаны все ваши заметки про бизнес
Преимущества подхода:
Простота и естественность организации файловой системы
Если заметка относится сразу к нескольким категориям - ставите несколько ссылок на посадочные страницы. А добавить один файл сразу в две папки невозможно.
💬 Больше про ведение заметок и планирование в Obsidian в моём тг-канале
Разработчик публично сообщил, что ему не нравится обновление для Obsidian, но не рассчитал свои силы. В реплаи пришёл CEO проекта и по-русски написал, что разработчик просто «не прочитал документацию». Ответ разработчика: да, я реально её не читал.
-Почему друзья не смеются над вами, когда вы говорите про теорию заговора? -Потому что все оказалось правдой!
После изобретения электрической лампы (опустим споры кто был первым) производители "светильников" старались делать свою продукцию наиболее качественной, долговечной и надежной. При таких показателях лояльность клиентов и, как следствие, продажи росли с геометрической прогрессией. Но после насыщения рынка качественным и не ломающимся продуктом, реализация приостанавилась и компании начали терять прибыль, а топ-менеджеры – премии. Именно в таких условиях оказались 🇩🇪 немецкая Osram, 🇬🇧 британская Associated Electrical Industries и 🇺🇸 американская General Electric в 20-х годах 20-го века, когда они организовали картель "Фебус" (англ. Phoebus), направленный на искусственное сокращение срока службы ламп накаливания до 1000 часов (вместо прежних 1500–2500), чтобы стимулировать продажи.
Можно сказать, что отсюда начинает свою историю глобальный заговор под названием "Запланированное старение". Кстати нередко под громкими эгидами по типу "глобальное потепление", "сокращение выброса СО2", "солнечная энергия" и т.д. компании и продвигают свою продукцию, которая в итоге прослужит не более пары лет.
И, как говорится, никогда такого не было и вот опять запланированное старение добралось и до святая святых всех айтишников - компьютерного железа.
В одном из последних видео 📺 Владислав проводит ремонт внезапо вышедшего из строя без видимых причин 🇨🇳 китайского ноутбука Maibenben X568, проработавшего +- около года. Вскрытие показало, что специалисты из поднебесной начали использовать в качестве припоя бессвинцовый Sn42Bi58.
Что же в этом необычного? Проблема в том, что это эвтектический низкотемпературный бессвинцовый припой, состоящий из 42% олова и 58% висмута, который плавится все-лишь при температуре 138С (против 218С свинцового). То есть, любой перегрев даже на коротокое время (забитый пылью вентилятор охлаждения, закрытая перфорация охлаждения от работы с ноутбуком на коленях) превратит компьютерное оборудование в озеро сплава. В большинсте случаев, дешевле будет купить новую комплектующую, чем платить мастеру за длительную работу по распайке-пайке SMD-элементов по всей плате.
Тенденция не здоровая и, я думаю, она скоро доберется до крупных корпораций: какой смысл продавать качественное железо за х2 цену, которое прослужит 5 лет, когда можно реализовать дешевое сроком жизни 1 год (долгосрочная выгода в 2.5 раза...) Мораль? Берегите своих железных помощников, ведь старый друг лучше новых двух (и экономней)!
Добрый день, друзья! Меня зовут Грачья, мне полных 38 и я запустил свой первый серьезный бизнес в Армении. Кто-то скажет: "Поздновато", а я скажу: "Лучше поздно, чем никогда!"
За плечами у меня 15-и летний стаж работы в разных инженерных компаниях на разных должностях от инженерных до управленческих. Последние 7 лет я руководил комплексными проектами по созданию различных систем, включающих в себя разработку софта, схемотехнических решений и железа.
А сейчас понял, что пришло время работать на себя, создавать рабочие места, а не занимать их.
Буду писать о том, как я свою первую компанию основал, инженерный стартап по разработке интеллектуальных систем, об успехах и неудачах первого бизнеса, о проектах и технологиях.
Формат ведения будет смешанным. Буду ставить себе цели и показывать путь их достижения, рассказывать о сложностях и подводных камнях, делиться мыслями, советоваться, проверять с вашей помощью гипотезы и показывать реализованные проекты.
Как сказал Гагарин: "Поехали!"
Учитывая все ошибки, которые допустила прежняя компания, в которой работал по найму, я первым делом начал собирать виртуальную команду менеджеров по продажам. Ошибка заключалась в том, что руководство не признавало маркетинг, продажи, выставки, соц. сети.
Инженерный костяк у нас есть, не подумайте, что я начал с продажников, не побеспокоясь о самом главном. У меня 2 партнера в доле, которые полностью обеспечивают техническое сопровождение, разработку, сборку и тестирование.
За неимением бюджета на штатных специалистов и нежеланием брать кредиты я решил поступить нестандартно. Написал порядка 50 кандидатам в LinkedIn предложение о сотрудничестве, обещающее процент с продажи. Начал с 5%, но понял, что рынок требует 15-20%. С учетом средней стоимости инженерного проекта в 15000-20000$, получается хороший бонус. Даже если будет подписан всего 1 контракт в месяц, это выходит в 1.5-2 раза выше средней ЗП по Еревану.
На сегодня, откликнулись несколько человек, с двумя начинаем работать. Кстати, если среди читателей есть желающие, то я не ограничиваю себя количеством.
Что я сделал в первую очередь - написал всем контактам из записной книжки с предложением о сотрудничестве. В результате смог заключить 2 договора на создание автоматизированных измерительных систем. Их я опишу в отдельных постах. Это важный шаг, который позволит поддержать штаны команды на 3 месяца.
Далее я создал удобную систему для учета всего и вся. Перепробовав уйму PMских инструментов остановился на Coda.io Ее бесплатные функции вполне достаточны даже для командной работы. Скрины с коротким описанием выложу отдельно. Это полноценный аналог Notion, но мне понравился больше.
Выше я писал о двоих менеджерах, которые согласились с нами поработать. Метод их работы состоит в поиске заказов на таких площадках, как Upwork, LinkedIn. Надеюсь, что работа с этими ребятами даст нам постоянный денежный поток.
Вторая глобальная цель на ближайшие полгода, это создание концепции и MVP продукта, рассчитанного на массовое производство. Я думал так: "Eсли я найду 2-3 проекта на стороне, то у меня будет запас денег и возможность создать MVP продуктовой идеи." Звучит, как хороший план, учитывая тот факт, что уже есть 2 подписанных контракта и переработано порядка 6 идей.
Об успехах и неудачах буду регулярно тут отчитываться, что бы рука всегда была на пульсе.
Если у вас есть предложения о сотрудничестве/партнерстве, всегда буду рад обсудить.
PS Есть варианты смены имени аккаунта?) Возможно было бы правильней зарегистрироваться заново, но этот аккаунт был создан довольно давно и несет для меня определенную ценность.
Последние полторы сотни лет менеджмент развивался исключительно для крупного бизнеса, а это особый круг проблем, когда:
владелец не имеет личного контакта с каждым сотрудником - ни пнуть, ни похвалить - как обеспечивать динамику работы?
возникают серьёзные проблемы с прохождением управленческих сигналов "сверху вниз" и обратно - руководитель теряет ощущение реальности, плюс любая попытка что-то изменить - вязнет в хитросплетениях иерархии.
результат уже мало зависит от одного исполнителя - можно прятаться за чужими спинами, имитировать деятельность... и мотивация хороших сотрудников падает
Современность к этим вызовам добавляет ещё и пристальное внимание проверяющих органов. Корпораты вынуждены соответствовать огромному количеству нормативов и предписаний.
Большинство разработанных управленческих стандартов - суть - умножают бюрократию. А у малого бизнеса на эти танцы просто нет ресурсов! Нет возможности ни выделить отдельный финансовый отдел, ни создать отдел кадров, ни внедрить профессиональное программное обеспечение. Не хватает ни денег, ни возможностей, чтобы соблюсти кучу мелких требований и нормативов.
В итоге получается парадокс: в учебниках всё изложено верно, но для обычного предпринимателя эти знания малополезны. В лоб и в полном объёме их применить не получится.
Вот и получается, что малый бизнес оптом игнорирует всякие MBA и доверчиво падает в объятия инфобиза, которые на доступном языке преподносят банальности вроде: "Вот тебе топор. Размахиваешься и рубишь. Получилось? Повтори! "
И вот я подошел к двум очень важным моментам:
Какими бы стерильными и скучными ни были теории, в них заложен огромный потенциал. Нужно лишь найти ключик и грамотно перевести знания на язык практики.
Без профессионального менеджмента вырасти из штанишек малого бизнеса - без шансов...
Это ровно то, во что я полностью погружен - делаю фреймворки для полезного применения заумных стандартов в практике обычных рабочих групп. Методические выкладки и цифровой сервис.
Буду рад найти единомышленников, людей, которые также как и я - изучают теории и ищут возможности применить их на практике.
Интуиция — плохой советчик, когда на кону бюджет в миллионы. Выбор технологического стека, подрядчика или стратегии развития часто превращается в «битву мнений». Побеждает тот, кто громче, а не тот, кто прав. Результат: внедрение ради внедрения, скрытые косты и проваленные сроки.
Роль Agile Coach мертва… да здравствует агент изменений
TL;DR Роль Agile Coach должна умереть, чтобы переродиться в роль Change Agent (или Organizational Architect). И работать такие спецы должны не "вечно", а проектно - как спецназ внедрения изменений.
Здесь и далее: скрам-мастер и аджайл коуч тождественны.
1. Выделенная роль в команде — это кража ответственности
Постоянно приставленный к команде Agile Coach (или Scrum Master, или Delivery Manager в роли «няньки») - это прямое забирание ответственности у руководителей.
Зачем компания платит продактам и тимлидам хорошие деньги? Наверное, не для того, чтобы кто‑то другой создавал атмосферу безопасности, фасилитировал и работал с людьми.
Если руководитель не умеет управлять динамикой команды — значит, его надо учить, а не ставить ему «костыль» в виде коуча (ну и спрашивать с него соответственно). Соответственно, большая часть работы Agile Coach → Change Agent это обучение тем навыкам, которых не хватает руководителям. Скорее всего в больших организациях уже есть T&D‑отдел, который и занимается обучением. Наша задача состыковать системно прокачивание самых актуальных навыков.
2. Коуч для руководителей и архитектор среды
Роль трансформируется в коуча для руководителей и человека, который проводит изменения (зачастую проектно).
Чаще всего наболее активная часть работы - это движение системы к зрелости через работу с лидами. Агенты по изменениям - архитекторы среды обмена опытом. Даже на разборах ситуаций по хорошему (и когда получается) надо молчать и давать слово коллегам руководителя, даже если знаешь «правильный» ответ. Система должна уметь саморегулироваться, когда нас не будет.
Тут еще есть научная обоснованность: в модели проведения изменений ADKAR доказательно видно как CLARC (people менеджеры) это те, через кого мы проводим изменения.
3. Тест на прочность: «А что, если я уйду?»
Agile Coach делает хорошую работу, если после его ухода система радикально не ломается. Посмотрите, как быстро команды откатываются назад и насколько (например, по метрикам), когда из них убирают скрам‑мастера.
Стабильная привычка, как известно, формируется около 3 месяцев. В зависимости от масштаба изменений вы можете работать 3-6 месяцев и довести команду до определенного целевого состояния.
Нет предела совершенству, но нам с вами не туда: доводить процессы и майндсет до идеальных состояний почти никогда не стоит. Команды после нашего ухода все равно откатятся (и это нормально, главное чтоб не до нуля). С точки зрения всей системы, нам важнее дотягивать другие команды, процессы, взаимодействия, целеполагание до базового и достаточного уровня (который каждая организация определяет сама). Это даст намного более сильный результат по всей организации.
Более того, если долго работать с одной командой - возникает привыкание и порой выученная беспомощность, вы тратите свое время неэффективно. Нужно зайти, настроить, передать ответственность лидам и выйти. А потом трекать (как в настоящем стартапе) - что получается у лидов и команды, что нет - и точечно консультировать.
4. Мы наняты бизнесом, а не командой
Прошли времена раздутых бюджетов, когда можно было плодить «аджайл ради аджайла» чтобы «оптимизировать процессы». В текущих реалиях (особенно с нынешними ставками ЦБ) каждая копейка на счету.
Мы должны уметь драйвить бизнес‑стратегию, будь то организационная трансформация, радикальная смена концепции стартапа, оптимизация костов. И часто команда будет считать, что это «не по аджайлу».
Балансировать перформанс и здоровье команды (например, удовлетворенность, отток, выгорание) - вот это реальная задача, с которой надо помочь руководителям справиться или продумать оркестрацию изменений.
Софт скилы - это новые хард скилы
Управление изменениями, оргдизайн, работа с сопротивлением и сложная фасилитация - язык не поворачивается назвать это «софт скилами». Сейчас это самые настоящие харды. И именно за эти харды бизнес готов платить.
Обсуждали новую крупную фичу и произошел интересный поворот разговора. Я отвечаю за крупную часть системы и дал поверхностный(тк обзорный разговор), но комплексный взгляд на возможную реализацию. И невольно:) залез в зону ответственности команды фронтенда больше, чем как оказалось мне следовало.
Как "технический" человек я начал складывать пазл из вполне конкретных кубиков. И попал в одну из типичнейших ошибок менеджеров: скатился в "рецепт", сам того не заметив. И получил вполне справедливое возмущение от коллег.
Сам раньше тысячу раз обьяснял разницу между "постановкой проблемы" и выдачей конкретного рецепта ее решения "делай раз, делай два, потом строго направо".
Развитые софт-скилы для аналитика — +1000 к долгосрочному профессиональному успеху, ведь с ними преуспевать в работе будет проще. Благо софты, как и харды, всегда можно прокачать.
Поэтому делимся несколькими важными для аналитика софт-скилами и рассказываем о методах тренировки этих «мягких» навыков.
Стратегическое мышление, или, иначе, helicopter view
Навык, который помогает смотреть на задачи сверху и переключаться с деталей на большую картину.
Как развивать: расширять фокус, интересоваться всем, что происходит в сфере, регулярно обмениваться опытом с коллегами и рассматривать альтернативные решения. Полезно смотреть на проект с позиции наблюдателя и задавать себе вопросы, например, как еще можно достичь этих целей, или какую проблему решение этой задачи закроет.
Фасилитация встреч
Суть навыка в умении вести переговоры и выстраивать коммуникацию так, чтобы находить компромисс между конфликтующими сторонами.
Как развивать: организовать групповое обсуждение помогают коммуникабельность и эмоциональный интеллект. Коммуникабельность прокачивается через постоянное живое общение, курсы ораторского мастерства или клубы дебатов. Эмоциональный интеллект, задача которого понять не только свои эмоции, но и эмоции других, — через наблюдения и рефлексию.
Понимание потребностей и выявление требований
Грамотное погружение в потребности бизнеса помогает вовремя понять требования для того, чтобы продукт или проект функционировали так, как нужно.
Как развивать: нужно учиться не бояться задавать вопросы, уточнять недостающие детали и копать вглубь. Полезно обсуждать с заказчиком возможное состояние продукта/проекта в будущем, сверять понимание требований и проверять каждое требование на полноту и согласованность, чтобы выявить противоречия на ранних этапах.
Самоорганизация
Аналитику полезно уметь самостоятельно организовывать свой рабочий процесс: приоритизировать задачи и грамотно планировать день.
Как развивать: пробовать декомпозировать свои задачи и разбивать сложные процессы на управляемые шаги. А еще не стоит пренебрегать этапом планирования личной эффективности и личной работы.
Коммуникация и обмен информацией
Помимо построения долгосрочных отношений, для аналитика важно эффективно обмениваться данными по документации: артефакты должны быть понятны читателю.
Как развивать: через практику живого общения с другими людьми и через понимание, что перед нами человек, которому, как и нам, важна ясность. Документы — это тоже общение. Концепцию можно передать через схемы, диаграммы, таблицы, они проще воспринимаются при чтении. Можно использовать user stories и рассказывать истории так, чтобы командам разработки и заказчика были понятны суть и ценности предлагаемого решения.
Хотел написать небольшой пост по причинам провалов проектов 1С. Но погрузился в тему, что люди пишут, и вижу, что получится неплохая статья. А пока собрал основные причины - мои, от ИИ и из Сети, и получил список. Дополняйте в комментариях. Потом в статье рассмотрю подробнее.
Как избежать?
Сначала главные причины:
Критичные изменения (смена руководства и т.д.)
Отсутствие команды Заказчика, либо её невовлечённось, саботаж, отсутствие времени
Неконтролируемая волна хотелок (НВХ)
Неготовность к изменениям - внутренним и внешним
Неправильный выбор подрядчика, чрезмерное доверие или недоверие.
Ещё причины, вытекающие из основных
Непредоставление информации Заказчиком.
Неправильный выбор продукта, разочарование в продукте, несовершенство и сложность продукта
Отсутствие технического планирования (железо)
Чрезмерно сжатые сроки
Не хватает денег
Неотлаженные бизнес-процессы
Проблемы с данными
Также нашёл и такие "причины", о них в статье планирую специальный комментарий: Внедрение без обследования Отсутствие или изменение целей Неправильно выбранная проектная методология Незаинтересованность руководства Заказчика
Я пробовал организовывать рабочие чатики самыми разными способами: иногда просто в отдельную папочку, иногда – в папки по проектам.
Но у такой логичной организации есть проблемы: – Ты не можешь сходу понять, какие чатики требуют внимания – Имея большое количество чатов в папке, иногда невольно открываешь посмотреть то, что тебе сейчас вовсе не нужно
И некоторое время назад я придумал (вряд ли я, но в моём мире – именно я), как иначе организовать рабочие чатики – по срочности.
Сделал 4 папки: 🔹Now – то, на что мне нужно реагировать незамедлительно. Таких чатов всего 1–2, но стремиться нужно к нулю 🔹Hourly – то, на что нужно посмотреть в течение часа 🔹Daily – пробежаться раз в день, узнать, что происходило 🔹Later – оно же «никогда», оно же «когда-нибудь». Это чаты, где просто нужно присутствовать :)
В результате стало гораздо легче ориентироваться и не отвлекаться на лишний шум.
3 мифа про аналитику, которые мешают бизнесу расти
Давайте сегодня поиграем в «разрушителей мифов» и разберём 3 типовых заблуждения про аналитику, которые мы слышим из разговоров с фаундерами и топ-менеджерами компаний:
«Некому и некогда считать цифры»
Вам не нужен профессиональный аналитик, чтобы начать считать метрики. Вы можете дать эту задачу текущим сотрудникам по зоне их ответственности: маркетологи считают квал лиды, продажники — конверсию открытий outreach-писем, HR — кол-во дней на закрытие одной вакансии и т.д.
«У нас своя специфика, шаблоны не подходят»
Да, действительно некоторые метрики будут работать только для вашей компании. Но 80-90% метрик типовые — кол-во квал лидов, retention, ROI от вложений в маркетинг и т.д. Увы, но из нашей практики не все компании отслеживают базовые метрики хотя бы еженедельно. Потому дело не в специфике бизнеса, а в отсутствии культуры работы с данными.
«Сначала разгребём завалы, потом займёмся аналитикой»
На самом деле завалы и появляются потому, что решения принимаются «по срочности», а не на основе прозрачных данных. Как только у вас ежедневно перед глазами будут цифры, вы перестанете делать 90% лишних действий и сконцентрируетесь только на ключевом.
Вывод: «Мы ещё не доросли до аналитики» — опасная мысль, которая тормозит компанию от роста. Базовые метрики вы можете регулярно считать уже сегодня. Попробуйте хотя бы месяц каждый день начинать с подсчёта кол-ва лидов, выручки и чистой прибыли за неделю и удивитесь, какие задачи вы начнёте ставить в приоритет.
На днях случайно наткнулся на такую вот интересную картинку с глубокой мыслью про релиз и как говорится "зацепило".
Тема релизов очень отзывается у меня и накопилось много "материала" на эту тему. В своем канале о разработке в стартапах делюсь опытом и рассказываю еще больше удачных примеров и факапов. Подписывайтесь, будем вместе создавать синергию знаний !
За 15 лет в разработке я участвовал на разных ролях в создании совершенного разного типа продуктов, как по способу запуска(десктоп, веб и тд), типу поставки(desktop, saas, onprem) так и по зрелости продукта(прототип, mvp, плановое развитие зрелого продукта, полное переписывание внутренней системы крупного банка и тд и тп).
Порефлексировав об этом опыте с точки зрения релиз-менеджмента я нашел несколько явных закономерностей в процессах сдачи релиза в разных типах продуктов и стадий их развития. Было бы очень интересно сравнить мой опыт с опытом читателей и дополнить его. Дисклеймер: все ниже написанное исключительно мой опыт, он может не совпадать с Вашим и это хорошо. "Пусть расцветают сто цветов", будем учиться друг у друга.
В этом посте расскажу одну историю. Если тема "зайдет", то подробно систематизирую все известные мне архетипы и напишу уже полноценную статью.
В одной из организаций, в которой мне довелось трудиться были очень странные (на мой взгляд и на тот момент) процессы на всех стадиях разработки и it-поддержки(не продуктовой) продукта. Они сложились естественным образом при становлении организации и не подходили под мое определение "правильных", привитых мне в крупной организации.
Часть, относящаяся к менеджменту релиза также удивляла как ни странно своим отсутствием и незримостью и непрозрачностью для большей части команды разработки. Все это происходило из за сочетания типа поставки: saas (вернее отсутствия onprem поставки и строгих проверок на стороне клиентов, как говорится "все свое" ) и факта сосредоточения функций релиза в умах 1.5 человек, 0.5 из которых уже давно не относилось к отделу разработки.
Назовем такой тип релиз-менеджмента "one man release managment". Он неплохо работал, пока разработка шла по привычному процессу в рамках небольших изменений логики. Все быстро и удобно. Один человек знает и код и деплой, описывать ничего не надо, планов развертывания строить не надо, планов отката также. И ответственность тоже шарить не надо ;)
Все конечно изменилось по мере роста сложности системы и вызовов перед командой разработки, но это как говорится "уже совсем другая история". Был ли у вас похожий опыт и как вы относитесь к такому устройству процесса релиза? видите ли все таки в нем плюсы или это "не правильно\в книжках пишут не так" ?
GlowByte разработала методику выбора BI на основе сценарного анализа
Источник: Freepik.com
Практика Business Intelligence GlowByte разработала подробное руководство по сценарному выбору BI с готовой Excel-матрицей для сравнения платформ.
GlowByte выделяет 4 ключевых сценария с разными потребностями и акцентами:
отчеты для руководителя,
self-service,
регламентная отчетность,
исследование данных.
Сценарии в матрице сопровождаются своим набором релевантных критериев, каждый из которых имеет оценку критичности, что позволяет адаптировать расчет под конкретный проект: при изменении критичности пересчитываются все баллы, и BI-платформа получает новую оценку.
ℹ️ Методика учитывает изменения в BI-ландшафте, запрос на адаптивность и гибкость, а также необходимость подстраивать инструмент под задачу, а не наоборот. Исследование содержит детальные чек-листы по каждому сценарию, критерии оценки и примеры расчетов.
Пост из серии «никогда бы не подумал». Если попросить назвать крупных производителей самолётов, то скорее всего (не беря советских/российских конструкторов) услышишь названия 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% рынка и продолжает уверенно развиваться.
Всем кому было интересно читать и кто хочет больше узнавать про бизнес и менеджмент - зову на свой канал
Требования по регистрации событий ИБ часто выглядят формально и обобщенно. Но именно здесь во внедрении возникает больше всего вопросов, рисков и договоренностей, которые важно зафиксировать заранее.
Мы поговорили с Лизой, аналитиком по информационной безопасности, о том, как она работает с этими требованиями и что помогает избежать разночтений с заказчиком.
Почему регистрация событий ИБ — это всегда вызов
Событие ИБ — состояние системы, указывающее на важное с точки зрения безопасности действие, например, нарушение политики ИБ или сбой.
Звучит просто, но в реальности возникает множество проблем:
требования часто сформулированы абстрактно — «иные действия пользователей», «события, связанные с безопасностью»;
невыполнение требований ИБ может заблокировать весь проект;
нет универсальной базы — нормативные документы дают общее направление, а у каждого заказчика есть свои внутренние требования и особенности.
Откуда берутся требования
Во внедрении я сталкиваюсь сразу с несколькими источниками:
требования по защите персональных данных — например, приказ ФСТЭК № 21;
документы регуляторов с описанием инцидентов и состава событий;
отдельные требования финансовых организаций;
внутренние документы заказчика, к которым не всегда есть доступ;
особые режимы — государственные информационные системы, требования, которые важно учитывать еще на этапе пресейла.
Недавно в нормативке появились практические ориентиры. ФСТЭК выпустил рекомендации по базовой настройке регистрации событий безопасности — с примерами настройки логирования в ОС.
Как я структурирую требования по событиям ИБ
Чтобы работать с этим массивом, я условно делю требования на четыре группы.
Общие требования
Сроки хранения архивов журналов, источники событий, уровни системы: от ПО до сетевого оборудования.
Общий перечень событий
Самый опасный пункт — «иные действия пользователей». Моя тактика: фиксировать конкретный список событий, показывать демо и добиваться согласования, чтобы исключить разночтения.
Состав полей события безопасности
Важно понимать не только что регистрируется, но и какие атрибуты попадают в лог. Я всегда ставлю себя на место специалиста SOC: хватит ли этих данных, чтобы расследовать инцидент?
Мониторинг и передача в SIEM-систему
Даже здесь возникают сложности — неподдерживаемые протоколы, требования к формату полей и событий, особенности интеграции. Формулировки должны быть максимально точными.
Что я вынесла из практики
Требования в ТЗ — это только часть картины, всегда нужно копать глубже.
Требования меняются по ходу проекта и это нормально.
Все договоренности важно фиксировать письменно.
Нужно учитывать не только нормативные документы, но и локальные требования заказчика.
Про SIEM-интеграцию стоит думать сразу, чтобы не пришлось переделывать позже.
Важно заранее договориться, кто и сколько хранит логи.
→ Подробнее своим опытом Лиза поделилась в статье.
Как я планирую неделю за 5 минут с Claude + TickTick на реальном примере 🙃
Накидал голосом в Claude примерный список задач — без дат, без приоритетов, просто что я думаю нужно сделать
⚠️ Important
У меня очень хорошо описаны правила постановки задач и по моему курсу у Claude тоже много контекста, без этого подобное планирование невозможно
Вот как выглядит диалог с Claude от голосового до записей в календаре ⤵️
👱 «Закинь эти задачи в TickTick на неделю, можешь еще примерно приоритет важности поставить» 🤖 «Ок, создал 17 задач, распределил по дням, расставил приоритеты» Дополнительно Claude уточнил у меня: «Для лендинга мне от тебя нужны даты старта. И еще, механика ранней цены — по местам или по дате?»
Т.е. он не тупо поставил задачи, но и еще доспросил по тем вопросам, где нужно уточнение
👱 «Размажь эти задачи по времени дня релевантно» 🤖 Распределил задачи по рабочему дню: утро и день — мелкие задачи, вечер — вдумчивые. Как ты любишь.
У моего Claude в проекте постановки задач описано много правил по тому, какие типы задач в какое время дня мне больше нравится делать. И он это все учитывает
👱 «Поставь релевантную длительность» 🤖 Проставил start/end для каждой задачи: статья — 3 часа, обновить цены — 30 минут, встреча — 1.5 часа.
Чтобы это были не просто todo в календаре, а именно что занятые тайм слоты
👱 «Распиши по SMART в описании» 🤖 Добавил в каждую задачу S/M/A/R/T — что сделать, как понять что готово, почему реально, зачем нужно, дедлайн.
Это я уже по приколу добавил, на самом деле у него немного другие правила детализации задач. Но сам факт, что при наличии нужного контекста он еще и критерии выполнения может добавить
Все работает через Claude Desktop => Tick Tick MCP => Tick Tick
Конечно, можно все в одном промпте провернуть, но я решил так показать
Вот в итоге все задачи проставлены, интерфейс календаря не открывал
Представлена открытая платформа LifeForge. Этот проект — швейцарский нож для мониторинга жизни и работы. Инструмент заменяет такие сервисы: планировщик задач, трекер привычек, заметки, финансы, цели, обучение, дневник и ещё десятки инструментов — всё в одном месте. Внутри есть контроль задач, проектов и дедлайнов, учёт расходов и бюджета, заметки, идеи, дневник, обучение, флешкарты, база знаний, личные цели и прогресс. Работает локально, без облаков. Можно настроить под себя и отключить лишнее. По сути это Notion + Todoist + трекер привычек + финансы + личная CRM + учебная платформа в одном проекте.
Данные есть, ясности нет: как принимаются сложные решения в IT
Нередко возникает странная ситуация: данных достаточно, аналитика собрана, риски посчитаны, команда сильная - а решение всё равно даётся тяжело или приводит к неожиданным последствиям.
Со стороны кажется, что проблема в расчётах. На практике гораздо чаще она в другом.
Когда информации достаточно, но решения всё равно «ломаются»
В сложных проектах и бизнес-ситуациях данные редко бывают идеальными. Они неполные, противоречивые, запаздывающие. Это нормальное состояние реальности, а не ошибка аналитики.
В инженерных дисциплинах принято проверять модели в приближённых к реальности условиях - через валидацию и эксперименты. В IT-проектах такой «аэродинамической трубы» чаще всего нет.
Решения приходится принимать в условиях неопределённости, без возможности проверить модель в натуральных условиях заранее.
Проблемы начинаются в тот момент, когда решение принимается не из ясности, а под воздействием состояния: дедлайны давят, накапливается усталость, появляется страх ошибки. Возникает желание срочно что-то сделать, чтобы снизить напряжение.
В этот момент формально решение ещё обсуждается, но фактически оно уже принято.
Почему опыт и интеллект не всегда спасают
Парадоксально, но чем выше уровень экспертизы, тем изощрённее могут быть рационализации.
Мозг легко находит логичные объяснения, почему нужно ускориться, почему риски допустимы, почему «потом разберёмся».
Именно поэтому самые дорогие ошибки нередко совершаются не новичками, а опытными специалистами и руководителями - в моменты, когда исчезает пауза между импульсом и действием.
О паузе как инструменте управления
В работе с решениями есть простой, но недооценённый принцип: если между реакцией и действием остаётся пауза - остаётся выбор.
Пауза не даёт готового ответа и не снимает неопределённость. Но она возвращает управление из режима реакции в режим осознанного решения.
Когда паузы нет, решение принимается автоматически: из тревоги, из защиты, из спешки.
Когда пауза есть, появляется возможность задать неудобный вопрос, пересмотреть допущения или честно признать, что данных всё ещё недостаточно.
Почему это важно в IT (и не только)
IT-проекты, как и в других отраслях, редко ломаются из-за одной неверной формулы. Чаще - из-за цепочки решений, принятых слишком быстро или в состоянии повышенного давления.
Устойчивость систем, команд и бизнесов начинается не с идеальной аналитики, а со способности выдерживать неопределённость и не торопиться «закрыть вопрос» любой ценой.
Иногда лучший ход - это не выбор варианта, а умение вовремя остановиться и дать себе время подумать.
Что делать когда памяти на телефоне не хватает - ещё один вариант ;)
---ОФФТОП начало--- Исторически погоня за свободным местом была всегда. Чем больше информации нас окружает, тем больше мы хотим сохранить. И в этой философии каждый человек самостоятельно принимает решения что сохранять и как. Фото и видео (личные, от родственников и друзей), разнообразные документы документы от книг до аудио-видео записей и прочее.
Облако это удобно, но сейчас речь про офлайн решение, которое я использовал лет 15 назад для резервного копирования, и к которому я вернулся сейчас, чтобы не чувствовать ограничений на телефоне с 256гб встроенной памяти. И так уж получилось, что я пользуюсь телефоном, производитель которого отказался от поддержки SD карт, а я не смог пересесть на другие телефоны. ---ОФФТОП конец---
В качестве исходных данных берем телефон, памяти которого со временем становится недостаточно. Раньше я ставил карту памяти, которая больше памяти телефон в несколько раз (телефон 64гб - карта памяти 256гб) и настраивал периодическое копирование из основной памяти на карту памяти.
Таким образом у меня была полная копия данных на карте памяти, которую я мог использовать, если телефон выходил из строя, на другом телефоне. Также я всегда знал что могу удалить файлы из основной памяти телефона, потому что эти файлы уже на карте памяти. Обычно удаляются старые видео, снятые на телефон, которые накапливаются и могут занимать до 30% места на встроенной памяти. Иногда все фото-видео-документы переносились на ПК для архивирования.
Если телефон не поддерживает карту памяти, то можно использовать облако. Но и облако имеет свой предел (той стоимости, которую я готов платить), даже если периодически переносить данные из облака на компьютер.
После очередной (безуспешной) попытки перейти на телефон с SD картой пол года назад, у меня осталась SD карта на 512гб. Карта была подключена через type-c адаптер к телефону и единожды была выполнена полная синхронизация.
Теперь при необходимости почистить место на телефоне, SD карта подключается через адаптер, выполняется синхронизация только новых файлов и традиционно удаляются видео, снятые на камеру телефона и занимающие львиную часть места. Фотографии с телефона не удаляю, ведь по сравнению с видео они занимают гораздо меньше места.
Сейчас используется старый адаптер с переходником, хотя в продаже есть современный адаптер для SD карты с подключением type-c. Этот же адаптер является личной флешкой, т.е. всегда с собой в сумке.
Программ для выполнения синхронизацией папок много и каждый может найти себе удобный вариант. Сам пользуюсь платной версией FolderSync - исхожу из того, что оплачиваешь покупку один раз, а программа продолжает развиваться. Кстати, отдельно при синхронизации по маске * (все папки и файлы), нужно исключать системные папки, типа /.thumbnails/ в корневой папке Pictures.
Общий список исключений (задаётся как регулярное выражение) у меня выглядит так
Ordnerpfad RegEx .*\.database_uuid.*
Ordnerpfad RegEx .*\.nomedia.*
Ordnername RegEx .*\.thumbnails.*
Если появляется сообщение о сбое синхронизации, значит какая то программа использует папку с системным названием, но это большая редкость.
P.S. Многие программы синхронизации поддерживают копирование в SMB (сетевую папку), что также можно использовать для синхронизации данных напрямую с телефона на компьютер через общий WiFi.
P.P.S. Нашел open-source бесплатное решение Syncthing, которым позволяет выполнять синхронизацию между устройствами в интернете через UPnP механизм, но пока ещё не было необходимости его использовать.
Иногда ловлю себя на странной мысли: если бы мне дали возможность забыть один фильм или сериал, чтобы пересмотреть его заново — что бы это было?
Выбор оказывается неожиданно сложным. Потому что я уже знаю, какие эмоции получу, где будет вау-момент, где захочется поставить на паузу и просто посидеть в тишине. Крышесносный боевик, напряженный триллер, запутанный детектив или (куда уж без неё) "Игра престолов"?
И именно поэтому хочется пересмотреть это снова — с чистого листа.
Потом я поймал себя на том, что эта мысль отлично ложится на бизнес и маркетинг. А что если представить, что можно «забыть» один процесс в своём бизнесе? Посмотреть на него так, будто видишь впервые.
Как бы вы его спроектировали сегодня?
Когда мы давно внутри процесса, мы перестаём его замечать. Он становится фоном. Привычкой. Автоматизмом.
А попытка «забыть фильм» — это способ вернуть себе взгляд нового зрителя, а не участника съёмок.
P.S. "Властелина колец" я бы не стал забывать. Мне его и в 30-ый раз пересматривать очень интересно)))
Почти четыре года назад Вика пришла в Naumen стажером, а сегодня — руководит командой, где почти все специалисты начинают свой путь с нуля. Вместо использования универсальных рецептов для руководителей она выстраивала свою систему с упором на поддержку, доверие и постепенное развитие.
Делимся ее ответами на непростые вопросы, с которыми может столкнуться руководитель в команде джунов.
Как понять, что сотрудник застрял в задаче, но боится сказать?
Если человек вдруг перестает обновлять статус или не выходит на связь по задаче — это не всегда прокрастинация. Часто за этим стоит тревога: задача кажется слишком сложной, неясно, с чего начать. В такие моменты я сама инициирую разговор: спрашиваю, что тормозит, помогаю разложить задачу на части. А еще предлагаю начать с простого, чтобы войти в ритм, почувствовать уверенность и потом вернуться к сложному.
Как быть, если команда боится просить помощи, даже когда тяжело?
Я сталкивалась с этим в своей команде: каждый видел, что у других завал, и считал, что жаловаться неуместно. Начала проговаривать на общих созвонах, что просить помощи — нормально, это не слабость. Потом попробовала сама писать в личку с конкретными вопросами. До сих пор периодически пишу: «Привет! Вижу, что у тебя много задач. Давай заберу какую-нибудь?» и почти всегда в ответ получаю ссылку на задачу, которую можно передать. Ведь принять помощь гораздо проще, чем просить о ней самому.
Что делать, если в команде очень разные стили работы?
Кто-то может сам организовать процесс, кому-то нужна поддержка. Я это учитываю: одним ставлю регулярные встречи, другим даю свободу. Подходы — разные, результат — общий. Важно не навязывать единую систему, а подстроиться под ритм человека. Это снижает перегруз и дает опору.
Как говорить о повторяющихся ошибках, чтобы не потерять доверие?
Если ошибка повторяется или нарушаются договоренности, я говорю об этом строго, но без давления. Наедине обсуждаем, почему так произошло и что помешало. Также подробно разбираем, как можно было поступить по-другому. Человек не закрывается и понимает, что ошибка — не повод для страха, а точка роста.
Как помочь, если сотрудник теряет уверенность в себе?
Многие джуны (и я сама раньше) сталкиваются с синдромом самозванца. Они не видят свои достижения, стесняются радоваться успехам. Мы завели доску «победы недели» — каждую пятницу на ретро сотрудники фиксируют свои успехи и рассказывают о них всей команде. Когда признание приходит не только от руководителя, но и от коллег, человек по-настоящему начинает видеть свою ценность. На «1:1» мы тоже обсуждаем сильные стороны с конкретикой и примерами, чтобы сотрудник видел точки роста и сильные стороны.
→ Подробнее своим опытом Вика поделилась в статье.
Инструментальное средство PVS-Studio разрабатывается с учётом требований, предъявляемых к статическим анализаторам в ГОСТ Р 71207—2024. Выявляет критические ошибки и может использоваться при разработке безопасного программного обеспечения по ГОСТ Р 56939—2024.
Я подготовил развёрнутый материал, посвящённый функциональным возможностям PVS-Studio на начало 2026 года с точки зрения перечисленных стандартов, приказа ФСТЭК №117, методического документа "Профиль защиты" и т. д.
Обзор PVS-Studio получился большой и явно не формата статьи для Хабра. Это вообще, скорее, мини-справочник на 66 страниц. В общем, я вас предупредил :) Тех, кто не испугался, а наоборот, заинтересовался, приглашаю познакомиться с материалом по ссылке:
как связаны между собой PVS-Studio и различные ГОСТы;
требования к статическим анализаторам кода и насколько им соответствует PVS-Studio;
разбор технологий анализа, реализованных в PVS-Studio;
примеры выявляемых критических ошибок и что это такое;
характеристики анализатора: языки, поддерживаемые операционные системы, скорость работы, форматы отчётов;
и т. д.
Если вас заинтересовали озвученные здесь темы или у вас появились вопросы, то напишите нам.
P.S. Команда PVS-Studio будет со стендом на ТБ Форум 2026 (18–20 февраля 2026, МВЦ "Крокус Экспо", павильон 2, зал 10). Я там тоже буду. Приходите задавать вопросы на тему публикации, стандартов и вообще.
В рамках «Кругов Громова» сейчас запускаем новое исследование — по российским платформам роботизации бизнес‑процессов (RPA). Хотим собрать честный опыт внедрения: что реально автоматизировали, где программные роботы помогают, а где мешают жить.
Если вы участвовали во внедрении RPA, запускаете и поддерживаете программных роботов (RPA‑ботов) в проде или, наоборот, уже обожглись и отказались от платформы — очень нужны ваши ответы. Опрос занимает 5–10 минут, он про практику, а не про маркетинг.
Результаты войдут в открытое исследование по российским RPA‑платформам на russianbi.ru — в духе прошлых исследовательских кругов: с разбором сильных и слабых сторон и типичных граблей.
Если есть история «как у нас роботы пошли не по плану» или, наоборот, показательный успешный кейс — кратко накидайте в комментарии к этому посту, это тоже поможет исследованию.
Компания Manus* (теперь являющаяся частью Meta*) представила новый инструмент Meeting Minutes, призванный решить проблему «мертвых» заметок. Новый инструмент не просто транскрибирует разговоры, но и превращает живые обсуждения в структурированные данные, позволяя мгновенно переходить от слов к созданию презентаций, веб-сайтов или постов в едином рабочем потоке.
Процесс записи встречи в Manus: простой интерфейс с кнопкой завершения и визуализацией голоса.
Как это работает: от голоса к действию
Основная идея Meeting Minutes — максимальная простота использования во время очных встреч. Процесс работы с инструментом состоит из трех интуитивных шагов:
Запись: Пользователь нажимает иконку записи в приложении, чтобы начать фиксацию разговора.
Транскрипция: Система автоматически переводит речь в текст в реальном времени.
Генерация: После нажатия кнопки «Finish» ИИ анализирует сказанное и генерирует структурированное саммари (резюме) встречи.
Ключевые возможности
Новая функция выделяется на фоне обычных диктофонов и сервисов транскрибации благодаря глубокой интеграции с рабочими процессами Manus:
Умное распознавание спикеров: Система умеет идентифицировать участников беседы. Если в разговоре упоминается имя коллеги (например, «Алексей подготовит отчет»), Manus автоматически распознает это и может назначить соответствующую задачу конкретному пользователю.
Бесшовное исполнение (End-to-End): Это главное отличие инструмента. Результат встречи — не просто текст, а база для действий. Пользователи могут сразу превратить заметки в готовые артефакты: сгенерировать слайды презентации, структуру веб-сайта или список задач, не выходя из контекста обсуждения.
Коллаборация: В созданную задачу можно приглашать других участников встречи для совместной работы над результатами, что превращает запись в единое пространство для командной работы.
Офлайн-надежность: Инструмент разработан с учетом нестабильного соединения. Запись продолжается даже при полной потере интернета. Сеть необходима только для инициации процесса и финального анализа данных в облаке.
Важные детали и ограничения
Несмотря на инновационность, у первой версии Meeting Minutes есть свои особенности, о которых стоит знать пользователям:
Фокус на очных встречах: Инструмент оптимизирован для живых разговоров в одной комнате и не предназначен для записи онлайн-звонков (Zoom, Google Meet).
Отсутствие паузы: В текущей версии нельзя поставить запись на паузу — сессию можно только завершить.
Монетизация: Сама запись голоса бесплатна, однако функции ИИ-анализа и генерации заметок расходуют кредиты пользователя.
Анализ: Плюсы, минусы и перспективы
Преимущества Manus делает шаг к закрытию разрыва между этапом обсуждения и этапом исполнения. В отличие от простых саммаризаторов, этот инструмент сразу интегрирует результаты встречи в производственную цепочку. Возможность работы без постоянного интернет-соединения делает его незаменимым для выездных встреч и командировок.
Недостатки Ограничение использования только оффлайн-встречами отсекает значительную часть сценариев удаленной работы. Отсутствие кнопки паузы может быть неудобным для длительных сессий с перерывами, а система кредитов за анализ потребует от активных пользователей внимательного контроля расходов.
Перспективы В контексте недавнего присоединения Manus* к Meta*, эта технология выглядит как фундамент для будущих интеграций. Можно ожидать появления подобных функций в WhatsApp* или умных очках Ray-Ban*. Фактически, это шаг в сторону «агентного» ИИ — помощника, который не просто пассивно слушает, но и активно помогает выполнять работу.
* Организация Meta, а также ее продукты Facebook и Instagram, признаны экстремистскими и запрещены на территории Российской Федерации.
Каждое решение, которое принимает менеджер, можно отнести к одной из 2 категорий.
Первые - определённые. У них всегда есть факторы, которые однозначно определяют, какое из решений выгодно. Факторы могут быть неизвестны здесь и сейчас, но проведя исследования, углубившись в аналитику, расписав риски - их можно выявить.
А есть решения, факторы за и против которых соотносятся как 50/50. И да, тут тоже речь о всём возможном пространстве факторов, а не только об уже известных. И сколько сил и ресурсов не трать на уточнение - они так и будут колебаться около равновесия.
И главный талант менеджера - уметь с ходу определить, относится ли очередное решение к первой или второй категории, и оценить, стоит ли тут углубление в детали всех потенциально потраченных усилий.
(Услышал эту мысль в кулуарах одного из прошлогодних митапов, авторство уже не вспомню - но идея очень понравилась)
В начале января 2026 года ушёл из жизни Скотт Адамс, который более трёх десятилетий заставлял смеяться над едко-смешным комиксом Dilbert, высмеивающим абсурдность корпоративной жизни.
Адамс работал инженером по прикладным технологиям в Pacific Bell в Сан-Рамоне, штат Калифорния. Его дебют в комиксах состоялся в 1989 году, и на пике своей популярности он появился в более чем 2000 газетах в 65 странах на 25 языках, а аудитория его графических публикаций по всему миру, по оценкам экспертов, превысила 150 миллионов читателей. Несмотря на соответствующий уровень карикатурности, комиксы Адамса остро запечатлели офисную жизнь и задевали за живое класс белых воротничков.
Есть один тип роста, о котором говорят сильно реже, чем про «новых клиентов», «новые лиды» и «новые рынки». Хотя по факту именно он самый логичный.
Как-то я работал над стратегией для управляющей компании коммерческой недвижимости. Компания выросла из подрядчика в полноценного оператора: управление объектами, арендаторами, эксплуатацией, процессами. Всё как положено.
И в какой-то момент возник правильный, но непростой вопрос: «А как расти дальше?»
Очевидный и очень привычный ответ: «Искать новых клиентов». Но более интересный ответ — занять больше места в жизни уже существующих клиентов.
Если посмотреть на бизнес-процесс владельца коммерческой недвижимости, он длинный: выбор участка → строительство → ввод в эксплуатацию → управление → наполнение арендаторами → реконцепция → повторный цикл.
И вот ключевая мысль: если ты сейчас находишься в одном фрагменте этой цепочки, рост не обязательно искать за её пределами. Можно аккуратно расширяться горизонтально, закрывая соседние этапы.
Это и есть интегративный рост. Не «давайте делать всё подряд», а «давайте делать больше для того же клиента».
Мне очень нравится этот подход, потому что он:
- снижает зависимость от бесконечного лидгена, - усиливает LTV без агрессивных продаж, - и, главное, логично считывается рынком.
Фишка в том, чтобы не продать больше, а стать нужнее.
Для поиска такой стратегии можно начать с вопроса: «какую ещё роль мы можем взять на себя для клиента?»
У себя на канале я много пишу о разработке и внедрении документации систем менеджмента, а также улучшении работы систем менеджмента через автоматизацию. Одним из таких направлений сейчас является внедрение ИИ-помощников. Для средних и больших компаний можно создавать решение на базе ИИ в качестве универсального помощника в повседневных задачах. На общедоступны портал компании или мобильное приложение выводится чат-бот с ИИ, который может быстро ответить на вопросы и/или предоставить ссылки на внутренние документы компании (регламенты, инструкции). Кроме очевидной пользы для всех сотрудников, которым трудно ориентироваться в многообразии внутренних документов, большую пользу такой ИИ принесет и тем, кто отвечает за разработку и внедрение регламентов и инструкций. Позволит выстраивать правильную систему без противоречий и с обновляемыми связями. Вот перечень систем, которые позволяют реализовать это на внутренних серверах компании или в облаке.
TEAMLY AI https://teamly.ru/ai Особенности: Один из лидеров на рынке. ИИ обучается исключительно на ваших данных (документы, таблицы) и не использует внешние источники, что минимизирует ошибки и гарантирует конфиденциальность. Отличается глубоким пониманием контекста диалога и строгой системой контроля доступа (сотрудник видит только ту информацию, к которой у него есть права). Безопасность: Данные хранятся на ваших серверах. Интеграции: Встраивается в корпоративные порталы, CRM, мессенджеры. Для кого: Универсальное решение для всех отделов: поддержка, HR, маркетинг, продажи, производство.
KT-Team (ИИ-ассистент для правил) https://www.kt-team.ru/solutions/ai-for-business/ai-corporate-rules-helper Особенности: Специализированный помощник для работы с огромными базами правил, регламентов и инструкций (от 100+ документов). Понимает запросы на естественном языке, даже если формулировка не точная. Идеален для обеспечения соблюдения внутренних стандартов. Плюсы: Автоматически актуализирует ответы при изменении регламентов и предоставляет модуль для тестирования знаний сотрудников. Для кого: Крупные компании с сильно регламентированными процессами (финансы, производство, строительство).
Ontoloo https://ontoloo.ru/ai-chat-bots Особенности: Платформа для создания разных типов ботов (корпоративный, продавец, поддержка). Использует векторные базы данных для интеллектуального поиска по всем корпоративным знаниям. Гибкость: Поддерживает различные LLM (ChatGPT, Gemini, Claude, YandexGPT) и развертывание на собственных серверах. Есть интеграция с Битрикс24. Для кого: Компании, которым важна гибкость выбора модели и многоканальность (веб-сайт, Telegram и др.).
Personik (для обучения и HR) https://personik.ai/solutions/learning Особенности: Сфокусирован на сценариях обучения и адаптации персонала. Позволяет легко создавать интерактивные курсы, тесты и квизы на основе загруженных материалов (инструкций, документации). Форматы: Диалоговые тренажеры, микро-обучение прямо в мессенджерах (Telegram, Viber). Для кого: В первую очередь для HR-департаментов и учебных центров.
Minerva Knowledge https://minervasoft.ru/kms Особенности: Профильный сервис для базы знаний с ИИ-инструментами. Входит в линейку продуктов Minerva, среди которых — Minerva Learn, решении для создания обучающих материалов, тестов и анализа результатов. Плюсы: Семантический поиск по всем типам контента выдает релевантную информацию из базы знаний. Доступна быстрая миграция из Confluence, Notion, Zendesk и других зарубежных систем. Поддерживает диаграммы из Draw.io и PlantUML, доски из Miro, видео с YouTube и другой контент из сторонних сервисов. Можно сделать внешний портал с базой знаний для клиентов и партнеров. Встроенный ИИ дает подсказки из базы знаний в CRM-системе и других программах. Есть мобильные приложения для iOS и Android. Доступно коробочное решение. Для кого: Для компаний, заинтересованных в внедрении универсальных решений. Подходит командам, где минимум 15 сотрудников — меньшее количество лицензий купить нельзя.
IT-компании и их основатели покидают Силиконовую долину в Калифорнии: доля штата в общем объёме занятости в технологическом секторе США снизилась до 15,9% – самого низкого уровня с 2013 года. За последний год в штате сократили более 16 тыс. сотрудников.
Сооснователь Google Сергей Брин покинул Калифорнию на фоне массового оттока самых богатых жителей штата из-за опасений, что для них введут налог на богатство. Брин перевёл в Неваду более десятка организаций. Его компаньон Ларри Пейдж также покинул штат. Брин ищет жильё в Майами – городе, который облюбовали технологические миллиардеры, которые бегут из Калифорнии. Пейдж купил два особняка в Майами за $173,4 млн.
Пейдж и Брин основали Google в 1998 году. Брин ушёл в отставку в 2019 году, но два года назад вернулся в компанию, чтобы помочь ей развивать искусственный интеллект на фоне опасений, что она теряет позиции по отношению к конкурентам. Уход этой пары означает, что никто из пяти самых богатых людей мира не живёт в Калифорнии, несмотря на то, что четверо из них основали здесь свои компании.
Самый богатый человек мира Илон Маск и пятый по этому показателю Ларри Эллисон тоже покинули штат. Мультимиллиардер Джефф Безос основал Amazon в Сиэтле, но большую часть времени живёт во Флориде. Лишь Марк Цукерберг, шестой по богатству человек в мире с состоянием в $229 млрд, продолжает жить в Калифорнии. В штате набирает обороты движение за введение единовременного налога на богатство в размере 5% для всех, чьё состояние превышает $1 млрд. Если этот сбор введут, Брину придётся платить $13 млрд.
Код, архитектура и работа с командами — кажется, эти темы будут актуальны в IT-сообществе еще долго, и 2025 год не стал исключением. В нашем блоге эти темы по итогам года вошли в число самых читаемых.
Ниже мы собрали ссылки на статьи про инструменты разработки, документацию и инженерную коммуникацию. Читайте, сохраняйте, делитесь с коллегами.
Я люблю упорядочивать процессы. На работе я использую мощное ПО с кучей автоматизаций: кайтен и ClickUp. Последний прокачан ИИ ассистентом, очень помогает.
Но что на счет личных задач? Личный таск менеджмент тоже важен, и часто не для того, чтобы достичь супер результат, а просто чтобы не запутаться. И делаю я это все… в Apple напоминаниях, прям вот стандартное приложение в айфоне. Вы знали, что в 2023 его серьезно прокачали? Там теперь есть разделы в списках, шаблоны списков и даже вид канбан досок, и можно еще шарить друг с другом?
На первый взгляд может показаться, что это какое-то задротство. Но на практике это экономит кучу времени и денег. На скриншоте реальный пример, готовлюсь к небольшому путешествию. Первый столбец – сбор документов. Знаете, что всякие помогайки берут за это 25к руб? Причем собираешь в итоге все равно ты сам.
Делаю всегда очень просто: голосом в chat gpt надиктовываю задачу (это для каких-то сложных процессов типа документов на визу), он помогает составить план, разбитый на подзадачи, переношу в apple напоминания. План готов.
Также есть список долгих напоминаний - к этому вообще долго себя пытался приучить. Пример долгих напоминаний: оплатить годовую подписку, заплатить ипотеку (ежемесячное), дать кошке таблетку (через 2 месяца после прививки что-то там надо ей скормить), поменять батарейку в ключе от машины, поменять фильтр для воды дома и так далее.
Это 2 секунды, но ты избегаешь какой-нибудь дичи, которая может с тобой случиться через год. Идея то примитивная, главное заставлять себя это делать.
Немного офтопа. Знаете когда я понял, что буду это делать? Лет 5 назад, в начале апреля катал в Шерегеше, там бывают такие дни, когда температура наверху горы плюс, внизу минус. Внизу куртка становится мокрой, наверху превращается в лед. В итоге к концу дня замерзаешь. Запрыгнул в последний подъемник, чтобы в одиночку катануть на секторе Е по лесу. Пока доехал до низу, дошел до парковки, конечно замерз. И знаете что? И машина не открывалась, потому что батарейка села. Да, есть аварийное открывание, надо ключ разобрать. Но из-за погоды вся дверь покрыта льдом, который надо сначала отцарапать, потому что днем был плюс, а вечером уже минус. Ну и вот ты стоишь отцарапываешь замерзшими пальцами. Если щас скажете, что машина вообще-то предупреждает, когда в ключе низкий заряд – да да, только я в поездки беру второй ключ, который уже весь покоцаный, поэтому я с ним регулярно не езжу и не предупредила. Короче, вот. Тогда я решил, что это ведь совсем не сложно когда я поменяю батарейку сказать: «эй сири, добавь в список долгие напоминания поменять батарейку в ключе через 1 год».
Итого мой личный лайфхак 2025 года: ⁃ Использовать chat gpt, чтобы декомпозировать простые жизненные задачи в набор мелких простых ⁃ Записывать это в apple напоминания ⁃ Накидывать долгие напоминания, чтобы не случалась дичь.
Если вам близок такой формат размышлений, в Telegram я пишу короткие тексты 1-2 раза в неделю: про перегруз, мышление, восстановление и эксперименты на себе. Без мотивационных лозунгов и без “стань лучшей версией”.
