Эффективная работа в команде строится на «трех китах»: доверии, четких целях и умении конструктивно общаться. Именно продуктивное взаимодействие с коллегами позволяет быстрее и качественнее достигать общих результатов.
Собрали подборку книг, которые помогут отработать эти навыки на практике.
«Наука общения», Ванесса Ван Эдвардс
Практическое руководство о том, как начинать разговор, производить первое впечатление, считывать эмоции и невербальные сигналы, поддерживать интерес собеседника и увереннее чувствовать себя на встречах, переговорах и мероприятиях.
«Пять пороков команды», Патрик Ленсиони
Бизнес-роман о руководителе, которая помогает конфликтующей команде вернуть эффективность. На примере этой истории автор разбирает пять ключевых проблем. Вторая часть книги помогает диагностировать эти проблемы и работать с ними.
«Идеальный командный игрок», Патрик Ленсиони
Книга о трех качествах, которые помогают эффективно работать с другими. Автор объясняет, как оценить собственные сильные стороны, понять, какие качества стоит развивать, и выстраивать взаимодействие внутри команды.
«Правила команды. Искусство думать вместе», Максим Поташев, Павел Ершов
Авторы рассказывают о жизненном цикле команды, распределении ролей, разных стилях мышления, лидерстве и коллективном решении сложных задач. В книге есть тесты для определения своей роли и зон развития.
«Как создать настоящую команду», Дэвид Шервин, Мэри Шервин
Сборник практических алгоритмов и рабочих ритуалов, которые помогают команде договариваться об общих правилах и ценностях, принимать решения, давать обратную связь и справляться с конфликтами.
Считаем окупаемость WMS через бизнес-процессы: новый выпуск подкаста «Сначала процессы»
В управленческом отчёте маржа и операционные расходы выглядят предсказуемо. На складе часть убытков проходит по статьям, которые в эту отчётность не попадают.
Это шестой выпуск подкаста INTEKEY «Сначала процессы» и второй в тематической серии про окупаемость WMS. Предыдущий выпуск серии считал окупаемость через персонал: зарплаты, текучку, стоимость найма. Этот рассматривает только механику складской рутины, без учёта людей.
Новый выпуск подкаста "Сначала Процессы". Окупаемость WMS через изолированный критерий "бизнес-процессы".
Сравнение «12 млн за WMS — дорого» строится относительно нуля. На практике склад уже платит эту сумму каждый день: транспортные компании получают деньги за повторные рейсы из-за ошибок, банки — проценты по кредитам на закупку товара, который физически есть на складе, но его не могут найти.
Брак комплектации 1,5–2% на первый взгляд означает высокую точность. Полная стоимость одной ошибки складывается из нескольких шагов: повторная поездка, приёмка возврата, пересборка заказа, время менеджера на разговор с клиентом, корректировочные документы в бухгалтерии. Для российского B2B это около 4 000 ₽ за случай. При 500 отгрузках в день и 2% брака — больше 200 ошибок в месяц, около 800 000 ₽.
Товар физически лежит на складе, но недоступен для продажи, пока не отражён в системе. Приёмка на 150–250 строк силами трёх человек занимает около 4 часов: разгрузка, подсчёт, разбор накладных, звонки поставщику при расхождениях. Всё это время товар не виден отделу продаж. WMS с ASN (предварительным уведомлением об отгрузке) делает товар доступным к продаже в момент сканирования на воротах и сокращает процесс до 1,5 часов — около 460 000 ₽ в месяц освобождённого ресурса.
Инвентаризация с остановкой склада повторяется четыре раза в год. Прямые расходы на одну такую операцию — около 250 000 ₽ (переработки, доплаты, простои), то есть миллион в год. Цикличный фоновый пересчёт через ТСД убирает необходимость останавливать склад: расхождения фиксируются по мере появления, а не раз в квартал.
Точность остатков около 91% на ручном складе создаёт разрыв между системой и реальностью: закупщик видит в ERP отсутствие товара и заказывает новую партию, хотя старая лежит в другом углу склада. При запасе 90 млн ₽ разрыв 8,5% замораживает около 7,5 млн ₽. При стоимости капитала для бизнеса около 25% годовых это около 160 000 ₽ в месяц дополнительных расходов.
Биржа Инфостарта: новые задачи по 1С за 15-22 июля
На Бирже заказов Инфостарта за неделю с 15 по 22 июля появились новые проекты для разработчиков, аналитиков и консультантов 1С. В подборке - настройка отчетов и обменов, работа с банковскими выписками, перенос данных, интеграции с CRM и диагностика ошибок в учетных системах.
На этой неделе заказчикам нужны специалисты для следующих задач:
Биржа заказов Инфостарта помогает компаниям находить специалистов под задачи по 1С, а исполнителям - выбирать проекты по своей специализации и загрузке. На площадке размещают разовые задачи, консультации, доработки, запросы на сопровождение и участие в проектных командах.
Для заказчиков доступны исполнители разного формата - от частных специалистов до проектных ИТ-команд. Можно напрямую обмениваться контактами, работать без комиссии площадки и при необходимости использовать безопасную сделку.
Импортозамещение: «лишь бы российское» уже недостаточно
Наконец посчитали, что российский ИТ-рынок в 2025 году вырос на 13% и превысил 4 трлн рублей. Быстрее всего росли сегменты программного обеспечения и ИТ-услуг, а одним из главных драйверов оставалось импортозамещение.
Но сама цифра роста не означает, что заказчики готовы покупать любое решение с пометкой «российское». Часть динамики связана с ростом цен. При этом бюджеты стали жёстче, а крупные программы всё чаще разбивают на этапы. Рынок переходит от срочной замены зарубежных продуктов к промышленной эксплуатации отечественного стека.
Лицензия – только входной билет
Если ещё несколько лет назад основной вопрос звучал так: «Чем срочно заменить зарубежный продукт?», то сегодня заказчики оценивают уже не сам факт замены, а готовность решения к промышленной эксплуатации:
Как решение встроится в существующую инфраструктуру?
Кто отвечает за сопровождение при сбоях и обновлениях?
Как система восстанавливается после ошибочного изменения?
Можно ли масштабировать внедрение без роста операционных рисков?
Стоимость проекта определяется не только лицензией. Дальше – интеграция, тестирование, обучение команды, сопровождение разнородного стека, костыли, а возможно, и простои. Отдельная статья расходов – цена неудачного восстановления.
Каталог как проверка зрелости внедрения
Особенно хорошо зрелость внедрения проверяется на службе каталогов. Перенести пользователей, группы и политики в новый Linux-каталог недостаточно. До запуска нужно проверить не только авторизацию и интеграции, но и поведение системы после ошибки:
создание резервных копий и восстановление отдельных объектов и атрибутов;
сохранность прав доступа и членства в группах, корректность репликации;
мониторинг массовых и ошибочных изменений;
понятный порядок действий администратора после инцидента.
Простой тест часто показывает больше, чем длинная презентация: удалить тестовую группу, изменить несколько атрибутов, нарушить членство и пройти весь путь восстановления. Если этот сценарий не проверяли до запуска, его придётся осваивать уже во время простоя.
Иначе получается новый офис, в который уже перевели всех сотрудников, но забыли проверить, работает ли туалет. Формально переезд завершён. Эксплуатация говорит обратное.
Зрелое импортозамещение начинается не с выбора продукта, а с продуманного внедрения: проверки совместимости, распределения зон ответственности, отработанных сценариев восстановления и понимания цены ошибки.
Неэффективный процесс редко выглядит сломанным: работа продолжается, задачи выполняются, команда привыкает к лишним шагам, ожиданию и согласованиям. В результате все больше времени уходит на соблюдение порядка, а не на саму задачу.
Отказаться от такого процесса сложно — каждое правило когда-то появилось по понятной причине, а его отмена кажется риском. Поэтому команда продолжает исправлять отдельные части, хотя проблема уже в самом подходе.
Собрали 5 признаков, что процесс пора не дорабатывать, а пересматривать целиком.
1️⃣ Процесс занимает все больше времени
Одна и та же задача требует больше действий, участников и согласований, хотя сам результат не изменился.
Важно смотреть не только на общее время выполнения, но и на то, из чего оно складывается. Если на работу уходит час, а еще день — на ожидание ответа, передачу задачи и согласования, проблема может быть не в сложности задачи.
2️⃣ Команда избегает процесс
Люди выбирают другие способы решить задачу, потому что установленный порядок оказывается слишком долгим или неудобным.
Например, вместо оформления заявки через несколько этапов пишут коллеге в рабочий чат. Если это происходит постоянно, описанный процесс уже не совпадает с тем, как команда работает на самом деле.
3️⃣ Каждое исправление создает новые проблемы
Добавили согласование для повышения качества — выросло время ожидания. Сократили количество проверок — начали пропускать ошибки.
Так происходит, когда команда улучшает отдельный этап, но не учитывает весь путь задачи. Проблема не исчезает, а перемещается в другую часть процесса.
4️⃣ Процесс больше не соответствует работе команды
Процесс создавался под задачу, команду или архитектуру, которых уже нет. Со временем условия изменились, а порядок работы остался прежним.
В итоге команда тратит ресурсы на поддержку решения, которое не приносит прежней пользы.
5️⃣ Новым сотрудникам сложно включиться в работу
Чем сложнее процесс, тем больше времени требуется, чтобы разобраться во всех правилах, документах, доступах и согласованиях.
Если новый сотрудник несколько месяцев изучает устройство работы и только после этого переходит к реальным задачам, систему стоит упростить или пересобрать.
С чего начать пересмотр процесса
Определите, какой результат должен давать процесс и от каких рисков он защищает.
Сравните описанный порядок с тем, как команда работает на самом деле.
Проверьте, что произойдет, если временно убрать один из этапов.
Иногда лучшее, что можно сделать — не дополнительная проверка, согласование или регламент, а отказ от того, что уже перестало работать.
Про утопию «люди думают, а роботы работают», или про то, как корпорации пытаются вернуть вотерфолл
Сегодня роботы берут на себя всё больше работы. Реализация, которая ещё вчера стоила много недель работы высокооплачиваемых специалистов, теперь занимает минуты и почти ничего не стоит. И кажется, что ещё чуть-чуть и мы придём к идеалу, о котором мечтают многие: человек думает, а машина реализует.
Но вот в чём дело, пока реализация была сложной и долгой, она незаметно выполняла две важные задачи. Во-первых, заставляла репетировать: когда впереди недели труда, страшно потратить их впустую, и приходится сначала прогнать дело в дешёвом материале, на бумаге, в разговоре, в голове. Знакомое каждому мучение перед сложной задачей, когда откладываешь, завариваешь третий кофе, открываешь и закрываешь пустой файл, потому что непонятно, с чего начать, это не только прокрастинация, но и первый такт работы. Во-вторых, думание происходило уже внутри процесса: материал сопротивлялся, что-то не сходилось, и в каждом таком «не сходится» вспыхивала мысль. Полдня писал код, упёрся, пошёл спрашивать совет у коллеги и на второй своей фразе сам увидел ответ. Согласитесь, большую часть своих лучших решений вы придумали не до работы, а в процессе неё.
Т.е. мысль не лежит готовой, дожидаясь исполнителя. Она совершается в самом действии, будь то черновик, спор, ёрзание перед пустым листом бумаги или возня с сопротивляющимся материалом. Вотерфолльная идиллия с чётким разделением на этапы «человек формирует намерение, затем агенты реализуют по плану» (пример 1, пример 2, их много) возможна лишь в случаях с высоким уровнем определённости, а значит без потенциала для рождения инновационных решений. Такое подходит только монополиям и компаниям, живущим на ренте.
В этом свете можно с бо́льшим пониманием отнестись к пожилым преподам в универах, которые отмечали посещение на лекциях и заставляли писать конспекты от руки. Выглядит как глупая метрика для зачёта: зачем писать от руки, если можно заснять на телефон, да и в учебнике же всё есть. Но ручное письмо, если и не гарантирует понимания материала, то даёт ему шанс случиться. Способ примитивный. Но хоть какой-то.
Поэтому повсеместное внедрение AI-агентов ускорит лишь отдельные участки конвейеров поставки ценности, те, что уже поняты и описаны. Но создание ценности целиком быстрее не станет: конвейеры были ограничены не скоростью рук, а скоростью осмысления, и вот её AI-агенты никак не изменили.
Раз за разом наблюдаю один и тот же сценарий: у человека есть задача, он её как‑то решает, и это уныло. Например, он ведёт огромную таблицу в Экселе.
Человек думает, как это упростить, и ответ в последнее время всегда один — внедрить нейросеть. Человек идёт к начальству, получает одобрямс и начинает внедрять LLM, но с наскока и в лоб это не срабатывает — нейросеть врёт, теряет контексты, делает не то и не так.
Тогда человек долго и мучительно разбирается, как работают нейросети и почему они не работают так, как ему хочется. Роется в источниках и мучает сами же нейросети, но, цитирую: «они объясняют слишком сложно».
Наконец, человеку кто‑то подсказывает, что нужны агенты. Или скиллы, или ещё какая‑то надстройка над нейросетью. На этом этапе человек начинает писать серию статей о том, как он устал/сумел/не сумел внедрять нейросети и сейчас поделится всем, что узнал. Пишет буквально, как он долго и мучительно внедряет нейросети там, где их не надо внедрять.
Потому что для его задачи существуют готовые, надёжные, проверенные годами, поддерживаемые решения автоматизации. Например, человек внедряет нейросети там, где нужно вести базу знаний или открывать заслонку воздуховода раз в 2 минуты.
Почему это плохо Потому что база знаний в каком‑нибудь Вики‑подобном проекте займёт несколько гигабайт, а прямо в Постгресс — несколько мегабайт. Уместится на флешку. А с нейросетью нужен сервер за пару миллионов рублей. Или облако за несколько сотен в год. Плюс электроэнергия и настройка, контур безопасности и девопсы. Плюс затраты времени, а значит — денег компании, — на работу с ошибками и разбор последствий этих ошибок.
Потому что открывать заслонку воздуховода раз в 2 минуты можно механически, вообще без всяких серверов, достаточно клепсидры и пары рычагов. Не нужно тратить электроэнергию, вычислительные мощности и нанимать специальную команду, которая будет обслуживать серверную стойку.
Как так‑то? Как‑то так... Что помешало человеку погуглить спросить у тех же нейросетей, как решать задачу? Нейросети знают про Вики, Конфлюэнс и Постгресс... Что? А бес его знает...
Самое фиговое, что это происходит в мировом масштабе. Миллионы и миллиарды человекочасов и ресурсов уходят в никуда.
WMS как инструмент контроля затрат на персонал: считаем окупаемость
WMS традиционно относят к статье IT-расходов. Это задаёт неверную точку отсчёта: систему сравнивают с другим ПО, а не с реальной альтернативой — расширением штата.
В новом выпуске подкаста «Сначала процессы» считаем окупаемость через персонал.
Несколько вопросов, которые мы разбираем:
— Почему при росте объёмов дополнительные люди в смене не дают пропорционального роста выработки?
— Куда уходит рабочее время руководителя смены, если задачи раздают голосом и в мессенджерах?
— Что происходит с операционной устойчивостью склада, когда директор по логистике, в чьей голове живёт вся бизнес-логика, уходит?
— Почему ФОТ непредсказуем от месяца к месяцу — и можно ли это контролировать?
— При кадровом дефиците в 30–50% стратегия «нанять ещё людей» остаётся планом?
К выпуску — статья с расчётами по пяти сценариям и Excel-калькулятором.
AviTalk: как за три месяца объединить два продукта и не сломать команду
Новый выпуск AviTalk — разговор с CTO направления «Авито Товары» Александром Швецом. Ведущий — Виктор Раев, руководитель разработки юнита Services Base.
Александр рассказывает, как устроена разработка в Авито Товарах: категорийный подход, слияние продуктов после объединения Яндекс Еды и Delivery Club, и почему опыт из бигтеха плохо переносится на решения «на веру» в стартапе. Отдельно — про AI в процессах команды: как быстро внедрять прототипы, зачем нужна «примерка» товаров и одежды через нейросети и куда вообще движутся такие эксперименты.
Кроме продуктовой части — разговор о людях: с чем сталкивается разработчик, дорастающий до руководителя, как справляться с синдромом самозванца и стрессом, и что Александр посоветовал бы себе в начале карьеры.
На Бирже заказов Инфостарта опубликована новая подборка задач по 1С за неделю с 9 по 15 июля. В списке - доработки типовых и отраслевых решений, обмены, перенос данных, настройка документооборота, участие во внедрении ERP и консультации.
Биржа помогает заказчикам находить специалистов под конкретные задачи, а исполнителям — выбирать проекты по своей специализации и загрузке.
На Бирже заказов Инфостарта можно найти исполнителя для консультации, исправления ошибки, доработки конфигурации, настройки обмена, переноса данных, сопровождения или участия во внедрении. Для исполнителей это источник задач разного масштаба — от небольших доработок до проектной работы.
Вчера был на презентации нового цифрового продукта.
Ребята проделали огромную работу!
продумали сложную логику,
разложили систему на огромное количество элементов,
реализовали возможность доступа к каждому элементу,
связали все эти элементы в единую систему,
современный дизайн,
куча раскрывающихся менюшек,
бесконечное количество возможностей смотреть на систему под разными углами.
Единственное, что они не сделали - не собрали из всего этого Продукт, которым можно пользоваться. Это решение не про "понятно" и "удобно", а про интеллектуальный вызов!
Ощущение такое, что тебе надо ехать, а перед тобой лежит очень сложный и современный автомобиль, разобранный по деталькам, причем часть деталей еще у тебя с собой в сумках и рюкзаке.
Так вот, чтобы ехать - надо разобраться (инструкцию пока никто не написал) какие детальки откуда и собрать всё это в целостную конструкцию. Смотря на все это великолепие (а ехать то надо) - хочется из "галок и палок" соединить два лежащих колеса в подобие самоката и на толкаче поспешить к нужной цели...
Выражение приписывают Генриху Альтшуллеру, основателю ТРИЗ
Tesla опубликовала видеоролик с показом демонтажа производственной линии по сборке электромобилей Model S и Model X на своем заводе во Фримонте в Северной Калифорнии.
Процесс происходил в рекордные сроки в связи с перепрофилированием завода на выпуск человекоподобных роботов Tesla Optimus. Работы по демонтажу завершились за 46 суток. При этом была проведена разборка бетонных котлованов с использованием специальной тяжёлой техники, демонтаж роботизированных манипуляторов и конвейеров, а также расчистка пространства для установки новых производственных линий.
Почему хорошие вопросы ценятся не меньше хороших ответов
Вопрос может направить работу в нужную сторону, а может растянуть обсуждение на несколько кругов уточнений. Часто все упирается не в сложность задачи, а в то, насколько понятно сформулирован запрос.
Хороший вопрос не обязан быть длинным. Достаточно обозначить, что происходит, где нужна помощь и какого результата вы ждете. Так собеседнику проще включиться, дать точный ответ и не тратить время на догадки.
Вот несколько ошибок, из-за которых вопросы чаще запутывают, чем помогают.
Спрашиваем «как», не разобравшись с «зачем»
❌ «Как нам реализовать эту фичу?»
✔️ «Какую задачу решаем этой фичей? Есть ли другие способы?»
В первом варианте обсуждение сразу уходит в реализацию, хотя цель еще не до конца понятна. Во втором — сначала проясняем задачу, а уже потом выбираем решение. Так меньше риск потратить время на работу, которая не закрывает настоящую потребность.
Не проверяем, был ли похожий опыт в команде
❌ «Как правильно настроить X?»
✔️ «Кто-нибудь в команде уже настраивал X или сталкивался с похожей задачей?»
Документация и самостоятельный поиск полезны, но иногда быстрее сначала проверить, был ли похожий опыт внутри команды. Возможно, кто-то уже сталкивался с такой задачей, знает внутренние договоренности, помнит ограничения или может подсказать, где не стоит терять время.
Не даем контекста
❌ «У меня ошибка, можете помочь?»
✔️ «Получаю ошибку X при действии Y. Уже проверил A и B, но проблема осталась. Вот лог / скрин / ссылка. Подскажите, где еще посмотреть?»
Вопрос без контекста заставляет собеседника сначала разбираться в исходных данных: что произошло, где именно, после каких действий и что уже пробовали. Чем понятнее вводные, тем быстрее человек сможет перейти к сути и предложить решение.
Просим оценку, когда нужна обратная связь
❌ «Правильно ли я сделал?»
✔️ «Что можно улучшить в этом решении? Есть ли риски, которые я не учел?»
Вопрос «правильно ли?» часто сводит ответ к короткому «да» или «нет». Но в работе важны нюансы: возможные риски, альтернативы, слабые места. Если сразу попросить не оценку, а обратную связь, обсуждение получится полезнее.
Не задаем фокус для ответа
❌ «Что думаешь?»
✔️ «Посмотри, пожалуйста, логику: понятно ли, какую проблему решаем и почему предлагаем именно такое решение?»
«Что думаешь?» кажется удобным вопросом на все случаи, но в нем слишком много свободы для ответа. Собеседник может оценить формулировки, логику, детали реализации, сроки и при этом не попасть в то, что действительно важно. Когда фокус задан сразу, обратная связь получается точнее.
На Бирже заказов Инфостарта опубликована новая подборка задач для 1С-специалистов. За неделю появились проекты по УТ, УНФ, БП, ЗУП, обменам между базами, XML-выгрузкам, печатным формам и интеграциям с внешними сервисами.
Биржа заказов Инфостарта это площадка для задач по 1С: от точечных консультаций и небольших доработок до внедрений, интеграций, разработки отчетов и сопровождения корпоративных систем.
На площадке можно работать напрямую с подрядчиком, обмениваться контактами, смотреть рейтинг и кейсы исполнителей. Комиссия с заказов не взимается, а безопасная сделка доступна по желанию сторон.
Финальный дополнительный вебинар прошёл при участии ведущих экспертов: Дмитрия Шмойлова, Алексея Щербакова и Виталия Вареницы. Участники обсудили практику сертификации, новые национальные стандарты и методику подготовки, опыт компаний, а также подводные камни аудита и преимущества внедрения РБПО.
Общее количество вебинаров — 30. Каждому из 25 процессов ГОСТа посвящён отдельный вебинар и ещё 5 записано дополнительно на смежные темы. Запись всех вебинаров и подборка дополнительной информации доступна по ссылке: ГОСТ56939.РФ.
Методика ВУ и НДВ в ПО приведена в соответствие с ГОСТ Р 56939—2024
Материалы будут полезны всем, кто знакомится с темой РБПО и заинтересован во внедрении зрелых подходов в работу по созданию и сопровождению качественных программных продуктов. Материал по ГОСТ Р 56939—2024 весьма актуален, так как 12 мая 2026 утверждена обновлённая "Методика ВУ и НДВ в ПО". См. заметку "Методика выявления уязвимостей и недекларированных возможностей — 2026".
НЕкурс про РБПО
Суммарное время предлагаемых к изучению вебинаров составляет около 50 часов. Это достаточно большая задача, поэтому мы решили помочь и разбили материалы на отдельные уроки по РБПО. Возможно, так вам будет проще усваивать материал, а интерфейс позволяет отмечать, с чем вы уже ознакомились.
Прилетело и в очередной раз и резануло по живому...
Системность - это ... (продолжите фразу)
Системность - это модное словечко из лексикона "эффективных менеджеров", которое скорее вводит в заблуждение, чем отражает суть.
Под системностью на бытовом уровне люди понимают наличие порядка, основанного на определенной логике.
Реже - наличие системного подхода, где любая ситуация воспринимается, как комплекс взаимосвязанных элементов и чтобы добиться желаемого результата следует рассмотреть все составляющие системы и надсистемы с прогнозом их поведения в зависимости от разных вариантов воздействия.
Вот только системный подход - это системный подход, а системность - это признак системы. И как признак системы это ...
НЕ ПРО ПОРЯДОК!
Системы вообще никакого отношения к порядку не имеют - любая система стремится к хаосу (тут умное слово - энтропия).
И только лишь работа с системой предполагает упорядочивание элементов и связей - чтобы во всём этом разобраться.
некоторый полет мысли имени очень искусственного как бы интеллекта
Тамагочи, но вместо котика – команда разработчиков. И она выгорает, пока вы читаете этот пост
Помните тамагочи? Пищащий брелок, который тихо умирал, если про него забыть на выходных.
Мы сделали такой же. Только вместо котика у вас разработчик и команда. Вместо «покормить» – 1-on-1, код-ревью, менторство и релизы. Забьете на пару дней – вернетесь к просевшему доверию и зреющему конфликту.
И живет это все прямо в терминале на сайте. Без установки, без регистрации, без «оставьте почту».
Тамагочи в терминале
Что это
team – симулятор тимлида в консольном режиме нашего сообщества. Не модалка с кнопками: вы открываете фейковый (но честно рабочий) терминал и печатаете команды.
team new – и у вас есть напарник-стажер и живая команда.
Дальше вы его растите от стажера до CTO.
Цель проста на словах: дорастить человека до уровня «тимлид» и выкатить пять релизов, не развалив команду по дороге.
Почему это тамагочи, а не просто игра
Вот тут начинается интересное. Состояние живет в localStorage и распадается в реальном времени.
Пропали на день – доверие просело, конфликт подрос, напарник задремал. Пропали надолго – рискуете вернуться к game over: команда либо выгорела, либо развалилась от конфликтов.
Это питомец, который ждет. И портится без вас.
Дилеммы из реальных споров
Периодически прилетает инцидент. Звезда принесла оффер +40% и мнется. Прод упал в пятницу в 18:00. Двое неделю спорят: монолит против микросервисов. Выбираете вариант – получаете последствия в метриках и в журнале команды.
И часть инцидентов подтягивается из живого бэклога вопросов нашего сообщества. То есть в игру попадают дилеммы, которые реально обсуждали практикующие тимлиды, а не выдуманные кейсы из учебника.
Как сыграть
Никакой установки. Открываете терминал и печатаете team:
Почему OKR может не работать в B2B2C и что с этим делать
Большинство примеров OKR написаны про SaaS или e-commerce. Там все понятно: есть продукт, есть пользователь, есть метрика. Но что делать, если у вас два типа клиентов одновременно, непрямая дистрибуция и монетизация зависит от решений стратегического партнера?
Расскажем на реальном кейсе.
Контекст
CROSSHUB — российская IT-компания, которая разрабатывает решения для кросс-продаж в крупных федеральных компаниях. Бизнес-модель - B2B2C: с одной стороны крупные партнеры — банки, телеком, автопроизводители, с другой — конечные пользователи. Монетизация непрямая, ценность нужно доказывать сразу на двух уровнях.
Команда сильная, бизнес прибыльный и растущий. Но при всем этом ключевые цели стабильно достигались с задержкой. Не потому что люди не понимали стратегию — каждый руководитель понимал ее по-своему. Разные интерпретации приоритетов при общей вовлеченности давали именно такой эффект: все работают, а фокус размыт.
Почему классический OKR не ложится
Компания несколько раз пробовала внедрить OKR с внешними консультантами. Каждый раз одна и та же история: фреймворк в теории работает, но примеры из книжек и курсов не адаптированы под B2B2C. Попытка натянуть стандартный шаблон на нестандартную модель приводила к целям, которые формально правильные, но оторваны от реальности бизнеса.
Проблема не в методологии. Проблема в том, что перед постановкой целей нужна синхронизация — общее понимание того, где компания сейчас и куда движется. Без этого OKR превращается в упражнение по заполнению таблиц.
Что сделали
Запрос к Product Lab был на внедрение OKR. Но уже в первый день стратегической сессии стало понятно: идти по стандартному плану не имеет смысла. Переформатировали программу прямо в процессе.
Вместо классической OKR-работы провели интенсивное стратегическое проектирование за два дня. Ключевые этапы:
Определили две метрики: финансовую и нефинансовую как единые ориентиры для всей команды. Это то, что в продуктовом подходе называют North Star Metric: одна точка, на которую смотрят все, независимо от функции.
Декомпозировали метрики ретроспективно и на будущие периоды в разрезе сегментов. Это дало команде общий язык для разговора о результатах — не «мы хорошо поработали», а «вот что изменилось в цифрах и почему».
Применили фреймворк «4 корзинки» из методологии Product Focus для определения стратегических направлений. Он позволяет расставить приоритеты с учетом реальных ограничений модели, а не в вакууме.
На этой базе сформулировали цели и ключевые результаты — уже осмысленные, а не скопированные из чужих примеров.
Что получилось
Команда вышла с синхронизированным пониманием приоритетов и адаптированной стратегией. Не универсальной, а под свою модель, свои ограничения и свой этап зрелости.
Все участники поставили сессии 10 из 10. По словам заказчика — лучший опыт работы с внешними консультантами за историю компании.
«Теория сразу переходит в область практики. Гибкость подхода, скорость погружения в наш бизнес — это очень ценно» — Наталья Грудинина, директор по маркетингу и новым продуктам
«Вижу реальную пользу. Много инструментов, легко переключается, создает комфортную атмосферу для дискуссии» — Анна Пчелинцева, CEO
Вывод
Если бизнес-модель нестандартная — сначала синхронизация по стратегии, потом OKR. Иначе даже правильно написанные цели будут работать c каждым по-своему.
И еще один момент: скорость адаптации фасилитатора к контексту бизнеса важнее знания фреймворка наизусть. Инструмент всегда можно подстроить, если понимаешь, под что именно.
Представлен открытый проект Council of High Intelligence. Это локальный совет ИИ‑мудрецов, который поможет принять любое решение и найти идеальный исход событий:
в проекте заявлены 18 ИИ‑мудрецов: Марк Аврелий, Аристотель, Сократ, Сунь‑Цзы, Лао‑Цзы, Ричард Фейнман и Линус Торвальдс и другие;
ИИ-мудрецы максимально продумывают каждый шаг, спорят друг с другом в парах и выдают идеальное решение вопроса;
одни мудрецы находят риски, вторые — давят на практичность, третьи — высказывают сомнения;
устанавливается и запускается одной командой в Claude Code или Codex.
Лайфхак для мозга:как закрывать задачи и не терять эффективность.
Вам знакомо чувство, когда 10 мелких незавершенных задач буквально живут в голове и забирают внимание, даже когда ты занята другим.
Это эффект Зейгарник или налог на внимание. Каждая незакрытая задача в списке тихо съедает часть рабочей памяти, весь день, фоном. Почему так происходит?
Мозг тянется к задачам с ощущением веса и масштаба, потому что там есть понятная награда — чувство, что сделал что-то значимое. Мелкая задача этого не обещает, и мозг её тихо игнорирует, раз за разом выбирая что-то покрупнее.
Единственное, что здесь работает — убрать у мозга возможность выбирать. Если задача занимает меньше двадцати минут, она уходит в работу первой, до всего остального. Так мелкие вещи перестают съедать фоновое внимание, которое нужно для по-настоящему сложных решений.
ИИ для Университета 4.0, а «Королев ИИ» для МГТУ им. Н.Э. Баумана
Ключевой вызов для любого вуза, стремящегося к лидерству, — это не просто автоматизировать отдельные процессы, а создать единую «нервную систему», которая пронизывает все сферы деятельности: от образования и науки до управления и работы с талантами. Именно такую задачу мы ставим перед собой в МГТУ им. Н.Э. Баумана, разрабатывая научно-образовательную платформу «Королев ИИ».
Эта платформа — не просто набор модных чат-ботов. Это многоуровневая архитектурная среда, которая агрегирует и семантически обогащает данные, развёртывает специализированные сервисы на основе больших языковых моделей (LLM) и предоставляет единые интерфейсы для студентов, преподавателей, учёных и сотрудников. По сути, мы создаём «интеллектуальное ядро» цифровой экосистемы Университета 4.0.
«Королев ИИ»: архитектура будущего
В основе платформы лежит трехуровневая архитектура, которая обеспечивает её масштабируемость и адаптивность.
1. Уровень сбора и агрегации данных. Здесь формируется цифровой профиль каждого участника образовательного процесса. Это не просто сухие данные об успеваемости, а глубокий семантический анализ: тексты работ, участие в проектах, интересы и даже стиль мышления. LLM анализируют этот массив, выявляя латентные характеристики и создавая многомерный портрет человека.
2. Уровень интеллектуальных сервисов. Это «фабрика моделей» и «озеро научных знаний». Здесь развёртываются специализированные LLM-сервисы: от генерации персонализированных образовательных траекторий и адаптивного контента до интеллектуальной поддержки научных исследований и автоматизации управленческих процессов. Мы протестировали более 30 больших языковых моделей и создали первый рабочий прототип ИИ-ассистента, который понимает голос, обрабатывает запрос и даёт ответ естественным голосом.
3. Уровень взаимодействия. Это единая точка входа для всех пользователей. Студент получает персонализированного наставника, преподаватель — ассистента для автоматизации рутины, а учёный — инструмент для ускорения исследований.
Платформа «Королев ИИ» — это инструмент для достижения стратегических целей Программы развития МГТУ до 2030 года. Вот лишь несколько примеров того, как LLM меняют привычные процессы:
Образование. Мы решаем фундаментальную проблему «масштабируемой персонализации». ИИ-ассистент работает 24/7, помогая каждому из тысяч студентов осваивать материал в комфортном темпе. Платформа «Путь инженера» позволяет выявлять талантливых школьников и сопровождать их на всём пути: «школа — университет — индустрия».
Наука и инновации.LLM становятся катализатором продуктивности учёного. Сервисы семантического поиска, генерации гипотез и кода, поддержки публикационной активности помогают увеличить объём НИОКР и повысить количество публикаций в ведущих журналах. Мы создаём «озеро научных знаний», которое позволяет капитализировать интеллектуальный потенциал научных школ.
Управление и кадры. Интеллектуальная автоматизация документооборота, прогнозная аналитика и ИИ-агенты для консультирования сотрудников помогают сократить долю административного персонала при одновременном повышении качества сервисов.
Доверенный и этичный ИИ
Мы понимаем, что внедрение ИИ несёт не только возможности, но и риски. Поэтому этика — не внешнее ограничение, а внутренний принцип проектирования. В архитектуру каждого сервиса мы встраиваем механизмы объяснимости, аудита и защиты персональных данных.
Что дальше?
Мы уже прошли путь от идеи до действующего прототипа. Впереди — масштабирование, интеграция с отечественными программно-аппаратными комплексами и тиражирование нашего опыта. «Королев ИИ» — это не просто проект. Это прообраз новой операционной модели технического университета эпохи экономики данных, где технологии работают на человека, расширяя его творческие и когнитивные возможности.
Дальше разговор пойдет про OpenClaw/Hermes подобные системы. Т.е это переход от агентных систем по типу Claude Code/Codex к проактивным персональным агентам
В моей классификации это переход с уровня 8 на уровень 9
Коротко о том, в чем разница уровня 8 и уровня 9
Уровень 8 — например Claude Code / Codex / Cursor и тому подобные. За качество отвечают — Моделька + Harness + еще по мелочи
Уровень 9 — например Hermes / OpenClaw. За качество отвечают — Все то же самое, что и на уровне 8 + слой личной памяти + мессенджер + коннекторы в ваши сервисы + персональные skills
У меня у самого подобный агент уже был 3 месяца и крутился на OpenClaw. Но для написания статьи решил еще и Hermes попробовать
Кстати спойлер — разницы между Hermes и OpenClaw практически нет. Просто Hermes лишен кучи функций, что можно счесть как за плюс, так и за минус. Но зато у него есть Self Healing механизм, которого нет у OpenClaw
------------------
Ниже — про наполнение моего агента и что он умеет А именно на это и уходит основное время при создании персонального агента
Личные системы - finances — ведёт мои финансы в Notion: расходы, доходы и отчёты - ticktick — управление моим тасктрекером TickTick: списки на день, создание задач и подзадач, ну и все такое - google-calendar — полный контроль гугл календаря, где я ставлю совместные события и расписания с учениками - weekly-summary — собирает недельный обзор из задач, календаря, финансов, почты, аналитики и SEO по сайту + истории сессий, чтобы я посмотрел на прошедшую неделю целиком
Мое обучение - google-forms — читает анкеты и ответы участников - notion — ведет базу по моим ученикам - ga4 — аналитика моих сайтов в гугл аналитике - seo-monitor — SEO/GEO мониторинг сайта ilia-pro-ai.com. - youtube — навык по работе с YouTube, упаковка каждого нового видоса и сбор данных
Работа с документами - google-sheets — работает с таблицами: ученики, оплаты, анкеты, аудиты. - google-docx — создает классные контракты/договора
Соцсети - linkedin — читает мой LinkedIn-профиль, посты и engagement. - threads — работает с черновиками / публикациями /метриками в Threads - threads-writer — пишет драфты постов для Threads из идей, ссылок, статей.
Жизневое - concert-monitor — мониторит концерты в Bangkok/Thailand по моим артистам. - local-entertainment-research — еженедельный мониторинг кино, события и евентов на неделю - shopping-product-research — экспериментальный набор скиллов по работе агента с маркетплейсами, пока в процессе - online-ordering-automation — экспериментальный набор скиллов по заказу еды/продуктов - outreach-deeplinks — делает кликабельные ссылки для WhatsApp/LINE/tel с готовым текстом
B2B / ресёрч - b2b-outreach-research — ищет компании, ЛПР, каналы связи и углы для outreach в LinkenIn - apify — навык работы с Apify для скрейпинга любого сайта
Сегодня еще наконец-таки подрубил Telegram к нему и запустил его туда как пользователя — теперь мой агент может еще и так
1. Смотреть список всех моих диалогов
2. Читать историю конкретного чата. Например:
Расскажи, что за последние 2 дня ученики написали в чатике AI Advanced Alumni
3. Искать по Telegram-истории. Например:
Поищи я там где то мес назад скидывал контракт для Hochland, но не могу чатик найти
5. Смотреть каналы как пользователь и делать по ним дейли саммари
6. Скачать любые медиа из чатов Файлы, голосовые, фото, видео — если нужно обработать/распознать/суммаризировать
7. Писать всем подряд тоже может, но есть вероятность словить бан за такое
———————
P.S.В комментах скину домашку, которую можно выполнить, чтобы завести подобного агента и сделать более менее рабочим
ГОСТ Р 56939-2024 на практике: что мы сделали, чтобы получить сертификат РБПО
🔎 Контекст У Cloud.ru есть платформа, созданная специально для заказчиков, которые обязаны соблюдать особые требования к хранению данных и разработке ПО. Вся инфраструктура, которую они используют, должна быть аттестована на соответствие стандартам безопасности, а платформенные сервисы должны пройти жесткую проверку у регуляторов. Ранее платформа уже получала сертификат ФСТЭК России №4979, но при внесении определенной массы изменений в продукт, процесс требуется пройти заново, а сделать это невозможно без привлечения сторонней лаборатории и многомесячных ожиданий. Чтобы иметь возможность развивать продукт более оперативно, требовалось сертифицировать не только платформу для создания частного, гибридного или распределенного облака Cloud.ru Evolution Stack, но и все процессы вокруг нее, т.е. подтвердить соответствие ГОСТу Р 56939-2024.
🚀 Задача Стандарт требует выстроить25 взаимосвязанных регламентов и поддерживать более 200 артефактов в актуальном состоянии постоянно. Но этого мало: ведь стандарт есть, но конкретной методологии его реализации не существует, нужно было приземлить элементы процесса на орг.структуру нашей компании. Осложнялось всё тем, что в любой крупной ИТ-компании команды непрерывно перетасовываются, ответственные меняются, а любое кадровое изменение должно быть тут же отражено во всей документации сразу.
Аудиторы во время сертификации проверяют всё: опрашивают разработчиков, смотрят трекер задач, оценивают стек применяемых технологий, сверяют, соответствуют ли реальные процессы тому, что закреплено «на бумаге». Соответственно, ситуации, когда документация устаревает быстрее, чем обновляется, а новые исполнители не успевают вникнуть в свои обязанности, нужно было истребить полностью.
☁️ Что мы сделали Применили существующую в компании BPM-систему как единый источник правды: описали в ней ключевые процессы РБПО, зафиксировали роли, связали их с командами через орг.структуру, разместили все артефакты, точки контроля и указали их взаимосвязи. Следующим этапом автоматизировали конвертацию и публикацию свежих документов: по расписанию из BPM-модели экспортируется HTML, который автоматически конвертируется в Markdown и публикуется во внутреннюю Wiki. Изменился владелец роли — один раз вносишь правки в BPM, все документы актуализируются и тут же становятся доступны всем и каждому. Чтобы новички не впадали в ступор от количества регламентов, поверх Wiki добавили ассистента с RAG под капотом. Можно написать в корпоративный чат любой вопрос и получить структурированную информацию о том, кто за что отвечает и как действовать в любой ситуации, причем сразу со ссылками на конкретный документ в базе знаний.
🦾 Что получили в итоге В компании появилась полная живая и взаимосвязанная база элементов, включающая организационные единицы, роли, артефакты и инструкции по процессам. То есть на аудите мы показываем не просто набор Word'овских файлов, а живую модель с автоматически собранными артефактами. Каждый сотрудник, причастный к процессу безопасной разработки ПО, четко знает, что в какой ситуации делать и уверен в том, что данные не устарели. ИИ-ассистент сокращает время погружения в регламенты и процессы с дней до пары десятков минут, что значительно упрощает онбординг при смене роли.
Также такой подход позволил снизить затраты на устранение уязвимостей, поскольку их выявление предусмотрено на самых ранних стадиях процесса. Мы получили подтверждение качества платформы и стали первым облачным провайдером в России с сертификатом РБПО. У нас появилось больше контроля над собственным релизным циклом и теперь мы можем планировать обновления на годы вперед.
В вебинаре обсуждается, что на самом деле даёт сертификат и почему он не гарантирует безопасность ПО. Какие программы обязаны проходить проверку, а какие — нет. Чем отличается сертификация от аттестации, и что происходит после получения сертификата. На эти и другие вопросы ответили в бонусном вебинаре цикла с Виталием Вареницей, ведущим специалистом ЗАО "НПО "Эшелон" по сертификации и тестированию на проникновение ПО
Общее количество вебинаров — 30. Каждому из 25 процессов ГОСТа посвящён отдельный вебинар и ещё 5 записано дополнительно на смежные темы. Запись всех вебинаров и подборка дополнительной информации доступна по ссылке: ГОСТ56939.РФ.
Методика ВУ и НДВ в ПО приведена в соответствие с ГОСТ Р 56939—2024
Материалы будут полезны всем, кто знакомится с темой РБПО и заинтересован во внедрении зрелых подходов в работу по созданию и сопровождению качественных программных продуктов. Материал по ГОСТ Р 56939—2024 весьма актуален, так как 12 мая 2026 утверждена обновлённая "Методика ВУ и НДВ в ПО". См. заметку "Методика выявления уязвимостей и недекларированных возможностей — 2026".
НЕкурс про РБПО
Суммарное время предлагаемых к изучению вебинаров составляет около 50 часов. Это достаточно большая задача, поэтому мы решили помочь и разбили материалы на отдельные уроки по РБПО. Возможно, так вам будет проще усваивать материал, а интерфейс позволяет отмечать, с чем вы уже ознакомились.
Что с хабром ? Написал пост о том что выложил в opensource простенький ssh клиент и получил кучу дизлайков.
За что ? Я ничего не продаю, это ssh клиент которым я сам пользуюсь, пользуются еще несколько людей, через него удобно работать с туннелями и смотреть какой из сервисов отвалился
Не туду лист, не какое-то бессмысленное навайбкоженное ПО с подпиской - все бесплатно, 0 рублей - заинтересовало пользуйся, нет - не пользуйся, максимум что я прошу - звезду на гитхабе.
Как тогда делиться своими наработками, проектами, получать по ним обратную связь, если вокруг сколько негатива! Если интересен проект, вот он на Github вот еще одно opensource приложение для транскрибации которое я развиваю
Я хочу обратную связь от сообщества, в правильном ли я направлении иду Всем ПИС!
Недопущение реализации угроз безопасности, связанных с эксплуатацией неподдерживаемой версии ПО.
Общее количество вебинаров — 30. Каждому из 25 процессов ГОСТа посвящён отдельный вебинар и ещё 5 записано дополнительно на смежные темы. Запись всех вебинаров и подборка дополнительной информации доступна по ссылке: ГОСТ56939.РФ.
Методика ВУ и НДВ в ПО приведена в соответствие с ГОСТ Р 56939—2024
Материалы будут полезны всем, кто знакомится с темой РБПО и заинтересован во внедрении зрелых подходов в работу по созданию и сопровождению качественных программных продуктов. Материал по ГОСТ Р 56939—2024 весьма актуален, так как 12 мая 2026 утверждена обновлённая "Методика ВУ и НДВ в ПО". См. заметку "Методика выявления уязвимостей и недекларированных возможностей — 2026".
НЕкурс про РБПО
Суммарное время предлагаемых к изучению вебинаров составляет около 50 часов. Это достаточно большая задача, поэтому мы решили помочь и разбили материалы на отдельные уроки по РБПО. Возможно, так вам будет проще усваивать материал, а интерфейс позволяет отмечать, с чем вы уже ознакомились.
До сих пор оценка эффективности нейросетей и ML-моделей в бизнесе часто напоминала гадание. Команды хвастались «высокой точностью модели», а финдиректора разводили руками, не понимая, где реальные деньги.
Чтобы разобраться с этим вопросом, команда Альфа-Банка совместно с Альянсом в сфере ИИ, Ассоциацией ФинТех и двумя десятками ведущих компаний разработали методику расчёта финансового эффекта от ИИ-проектов и упаковали её в документ под названием «Методология оценки финансовой эффективности от ИИ/ГенИИ».
Это детальный гайд на 88 страниц о том, как прекратить считать «виртуальные деньги» и начать управлять ИИ как жестким инвестиционным портфелем. В документе подробно описаны ответы на вопросы «Какими метриками можно оценить фин. эффект от ИИ?», «Какими методами можно посчитать эффект от ИИ?», «Как избежать двойного посчёта эффекта от проекта?», добавлены примеры расчётов на примере кейсов внедрений и описаны типовые ошибки.
Методология прошла публичную проверку на совместном митапе с Альянсом в сфере искусственного интеллекта, и мы можем с уверенностью сказать, что она работает. Документ опубликован, переходите по ссылке, и применяйте у себя.
Очень критически надо читать умные статьи про найм персонала. Потому что на примере этой статьи с Хабра, можно сделать серьезные выводы и ошибиться.Как компании теряют прибыль из-за ошибок в подборе и почему это редко видно сразу https://habr.com/ru/articles/1044856/
У автора есть одно допущение, которое не обозначено в статье, но считаю, что важно его обозначить - наличие на рынке труда того самого идеального кандидата. Это допущение, однако, является не более чем заблуждением или когнитивным искажением. На самом деле идеального кандидата просто не существует, а если даже он есть, что вы можете ему предложить? Идеальную работу? Что-то сомневаюсь... Таким образом на рынке труда работодатель должен искать не лучших из лучших, а лучших, среди тех, кто есть. А есть на рынке труда не самые лучшие кадры, скорее наоборот, всех хороших уже расхватали. Значит остались только худшие. Поэтому лучше следовать принципу, что всегда и везде мы выбираем лучшего из худших, а не самого идеального. Тогда будет проще выстроить процессы найма, адаптации, испытательного срока и т.д., не тратя много сил и ресурсов на поиск, не теряя время и деньги за тот период, пока кандидат не найден и вакансия висит. Иначе поиск затянется, работа не будет выполняться, бизнес-цели не будут достигаться.
Организация систематического и углублённого поиска ошибок и уязвимостей в ПО при его эксплуатации в целях упреждающего реагирования: обработки ошибок кода ПО и его конфигураций (настроек) до того, как они будут выявлены сторонними лицами и повлекут инциденты информационной безопасности.
Общее количество вебинаров — 30. Каждому из 25 процессов ГОСТа посвящён отдельный вебинар и ещё 5 записано дополнительно на смежные темы. Запись всех вебинаров и подборка дополнительной информации доступна по ссылке: ГОСТ56939.РФ.
Методика ВУ и НДВ в ПО приведена в соответствие с ГОСТ Р 56939—2024
Материалы будут полезны всем, кто знакомится с темой РБПО и заинтересован во внедрении зрелых подходов в работу по созданию и сопровождению качественных программных продуктов. Материал по ГОСТ Р 56939—2024 весьма актуален, так как 12 мая 2026 утверждена обновлённая "Методика ВУ и НДВ в ПО". См. заметку "Методика выявления уязвимостей и недекларированных возможностей — 2026".
НЕкурс про РБПО
Суммарное время предлагаемых к изучению вебинаров составляет около 50 часов. Это достаточно большая задача, поэтому мы решили помочь и разбили материалы на отдельные уроки по РБПО. Возможно, так вам будет проще усваивать материал, а интерфейс позволяет отмечать, с чем вы уже ознакомились.
Давайте представим, что софтинка про документооборот - это рыба в воде. С жабрами, такая, хвостом и плавниками - прям адаптированная вся.
А теперь, представим, что управление задачами - это горный барс - стремительный, ловкий и хищный, красивым мехом покрытый.
Продолжаем дальше - бухгалтерский учет - пусть будет мудрым кротом, который организует схематоз проходов под землей - все корешки под контролем.
И вот все три сущности у нас есть, встает вопрос - как это всё связать друг с другом?
Удача то какая - все три решения заявляют - “У нас есть интеграции”!
Вот только среда существования у всех разная, функционал, предназначение, базовая логика - всё разное! И что надо? Вытаскивать рыбу на сушу или закапывать барса под землю? С чем “интегрировать” жабры? Со слепыми глазами?
Чтобы сочленить разные инструменты необходимо понимание-модель-схема верхнеуровневой рабочей системы, а ее ни в одном из перечисленных инструментов. Нет по определению. Они все специализированные и в чужом огороде не разбираются.
PS: И чо? Задача - интересная. Работаю в эту сторону :)
Формат: блиц по 7 минут, только личный опыт и кейсы, без воды. ~45 минут выступления подряд без вопросов, ~45 минут — обсуждение и вопросы. Всё бесплатно.
Программа на 18 июня:
• «ACP как база для агентской автоматизации» Алексей Самойлов, Techlead в Fastronome
• «Системный дизайн через AI-скиллы и MCP: от требований до архитектурного решения» Виталий Юшкевич, Lead engineer в Pugofka
• «Опыт применения AI в стартапе инфраструктурной платформы» Георгий Меликов, no-ops платформа Exordos
• «Организация правил работы с проектами в Claude» Денис Савицкий, разработчик в DeltaSoft
• «Опыт применения AI для анализа фродовых регистраций» Дмитрий Дунаев, Дата инженер в ССР
Ксения Погорельских, хостинг-сервисDeploy-f-, название доклада уточняется (расскажу про факапы, про эксперимент, где 30 агентов-тестировщиков нон-стоп ищут баги, а агент-разработчик эти баги исправляет и отдает на ретест. И почему эти агенты долго не могли выдать мне ветку с фиксами, готовую к мержу в мастер).
Приходи, регистрируйся, это можно сделать через таймпад, или через наш чат, Devhands AI Club. Если интересно участвовать в качестве блиц-спикера - присылай заявку на следующий митап. Темы, которые мы хотим обсуждать:
• Кейс: рассказ о запущенных проектах, опыт внедрения и adoption в компаниях
• Цикл разработки: Agentic SDLC, SDD, ADR, автоматизация QA (unit, smoke, e2e, нагрузочное), деплой, работа с инцидентами, sandboxing, security
• Локальные модели: модели, железо, сетапы, скорость и стоимость.
• Ошибки, которые я не повторю. Ошибки, которые я не повторю. Ошибки, которые я не повторю. Ошибки, которые я не повторю. Ошибки, которые я не повторю.
Написал бесплатное приложение для транскрибации — ⚡️ Talkis. Делал для себя как open‑source альтернативу платным сервисам по подписке.
Что оно умеет:
Расшифровывает созвоны (Zoom, Discord, Telegram и др.) в реальном времени прямо на лету.
Вытаскивает текст из любых готовых аудио‑ и видеофайлов.
Умная диктовка: наговариваете мысли голосом, а приложение причесывает и форматирует текст под нужный стиль.
Как это работает: модели можно крутить либо полностью локально на вашем железе (вообще бесплатно), либо подключить свои API‑ключи и платить копейки за токены без наценок сервисов.
Проект открытый. Буду очень благодарен за обратную связь, баг‑репорты и звездочку на GitHub — для развития проекта это сейчас самое важное.
Руководитель, который не ошибается — и другие мифические существа
Затягивать неприятные решения. Говорить «да», когда надо «нет». Нанимать людей, похожих на себя. Верить, что процесс как-нибудь заработает сам. Всё это — классические управленческие ошибки, которые совершают даже опытные руководители. И о которых не очень принято говорить вслух.
В новом выпуске «Свободного слота» — Андрей Колесников, SRE DevOps Lead в Авито и соведущий подкаста «В SREду на кухне». Разбираем топ управленческих косяков — и честно признаёмся в своих.
Что обсудили
Можно ли вообще научиться на чужих ошибках — или только на своих? Где грань между взвешенным решением и банальным затягиванием. Как говорить «нет» так, чтобы не прослыть неудобным руководителем. И как признавать ошибки до того, как с ними уже пришли к тебе — а не после.
Обеспечение технической поддержки ПО при его эксплуатации с целью устранения выявляемых в ходе использования и обновления ПО недостатков.
Общее количество вебинаров — 30. Каждому из 25 процессов ГОСТа посвящён отдельный вебинар и ещё 5 записано дополнительно на смежные темы. Запись всех вебинаров и подборка дополнительной информации доступна по ссылке: ГОСТ56939.РФ.
Цикл вебинаров проведён компанией ООО "ПВС" совместно с учебным центром "Маском". Организаторами выступили Андрей Карпов и Виталий Пиков. Совместно с приглашёнными экспертами различных компаний мы рассмотрели 25 процессов, приведённых в ГОСТ Р 56939—2024.
Материалы будут полезны всем, кто знакомится с темой РБПО и заинтересован во внедрении зрелых подходов в работу по созданию и сопровождению качественных программных продуктов. Материал по ГОСТ Р 56939—2024 весьма актуален, так как 12 мая 2026 утверждена обновлённая "Методика ВУ и НДВ в ПО". См. заметку "Методика выявления уязвимостей и недекларированных возможностей — 2026".
P.S. Суммарное время предлагаемых к изучению вебинаров составляет около 50 часов. Это достаточно большая задача, поэтому мы решили помочь и разбили материалы на отдельные уроки по РБПО. Возможно, так вам будет проще усваивать материал, а интерфейс позволяет отмечать, с чем вы уже ознакомились.
Каждый год на рынок выходит более 30 000 новых продуктов, но успеха добиваются лишь 15–20% из них. Часто проблема не в качестве продукта, а в том, что рынок меняется быстрее, чем команды успевают адаптироваться к новым запросам пользователей и технологиям.
В таких условиях важно не только следить за конкурентами, но и замечать сигналы, которые только начинают набирать силу.
Ксюша, руководитель продукта Project Ruler, поделилась практическим подходом к трендвотчингу: где искать ранние сигналы, как системно работать с трендами и какие изменения уже сейчас заметны на рынке управления проектами.
Что такое трендвотчинг
Трендвотчинг — это системный навык замечать ранние изменения в технологиях, поведении пользователей и бизнес-контексте до того, как они становятся очевидными для всех.
Это не фиксация текущего состояния рынка, а попытка понять, куда он движется дальше.
Почему простого анализа конкурентов уже недостаточно
Конкурентный анализ показывает, что происходит на рынке прямо сейчас. Но он редко помогает понять, куда рынок движется дальше.
Трендвотчинг позволяет смотреть шире:
какие технологии становятся доступнее;
какие решения набирают популярность в смежных индустриях;
какие темы растут в поиске и популярны в отраслевых обзорах.
Так можно заметить изменения раньше, чем они станут массовыми.
Где искать ранние сигналы
Один источник редко дает полную картину, поэтому я стараюсь комбинировать разные форматы.
Чаще всего использую:
Product Hunt, Trend Hunter и Springwise — чтобы следить за новыми продуктами и идеями;
Google Trends и Яндекс.Вордстат — чтобы анализировать интерес пользователей;
консалтинговые отчеты и отраслевые исследования — чтобы видеть долгосрочные изменения рынка.
Как понять, что тренд действительно важен
Чтобы понять, насколько тренд действительно волнует пользователей, важно подкреплять наблюдения количественными данными.
Практический подход примерно такой:
Сформулируйте базовый запрос, используя ключевые слова и фразы, связанные с вашей отраслью.
Расширьте его синонимами и альтернативными формулировками.
Сравните данные по регионам и сегментам аудитории.
Посмотрите динамику и сезонные всплески интереса.
Автоматизируйте мониторинг, создав дашборды и оповещения.
Как встроить трендвотчинг в рабочий процесс
Чтобы работа с трендами не превращалась в хаотичный серфинг, полезно автоматизировать сбор сигналов. Здесь помогают RSS-фиды и ридеры, которые собирают статьи, рассылки и обновления в одном месте.
Когда сигналы собраны, их можно структурировать с помощью:
Trend Canvas — для глубокого анализа тренда;
упрощенного SWOT-анализа — для быстрой первичной оценки.
Чек-лист работы с трендами
Формулировка цели и задач исследования.
Сканирование сигналов — системный поиск и сбор информации.
Интерпретация и систематизация.
Оценка и приоритизация.
Эксперименты и тесты — прототипы, MLP, пилоты.
Масштабирование и интеграция.
Какие тренды уже заметны на рынке
Один из самых заметных трендов сегодня — развитие low-code и no-code подходов.
Пользователи ожидают, что сложные процессы можно будет настраивать быстрее и без глубокой технической подготовки.
Крупные игроки уже активно развивают это направление, а аналитики прогнозируют дальнейший рост рынка в ближайшие годы.
Параллельно растет интерес к автоматизации, встроенным ИИ-функциям и более гибким системам управления проектами.
Почему выигрывают внимательные
Трендвотчинг не помогает предсказать будущее со стопроцентной точностью. Но помогает раньше замечать изменения, проверять гипотезы и принимать решения.
Выигрывают не те, кто просто хорошо делает свою работу, а те, кто умеет смотреть чуть дальше других и внедрять тренды раньше конкурентов.
Но не всегда важно быть первым. Иногда достаточно быть тем, кто заметил сигнал и сумел превратить его в осмысленное продуктовое решение :)
Как сейчас помню. Прилетает баг. Пользователь-кассир видит закупочную цену. Исправил. Прилетает баг. Пользователь-управляющий видит не закупочную цену, а цену продажи. Фиксить нельзя рефакторить.
М-да, предшественники старались знатно, чтобы сделать такое колесо обозрения костылей и вложенных условных операторов. Но ничего! Уж я-то всё всем докажу и всё везде исправлю навсегда!
Настарался не менее знатно, что-то постоянно не сходилось. Ну, не могли полтора десятка человек быть абсолютным злом. Или я в самом загадочном месте планеты, или причина в другом. Я стал искать, перебирать бэклог, группировать бэклог и вышел на… планирование. На его отсутствие.
Ладно, не вышел. Был свидетелем. Как от спринта к спринту задачи не были связаны друг с другом. Сегодня мы делаем турникет, завтра апельсин, потом кузнечика, потому что срочно нужна наковальня, а у нас итерационный продукт! Если останется время, то переведём бабушку с ангуляра на рякт, если нет — дедушку, но закончить до сентября! Что будет через два месяца? Верно, бабка с дедом посреди дороги висят на турнике в шубах на рыбьем меху. А? Поняли? Поняли? Рыбий мех — кузнечный мех! Это аджайл, мамкина норка! Нет времени уточнять, тебе ещё апельсин чистить.
И вроде бы фантастика, ложь, абсурд! Но одна недоделанная фича сменяет другую и мы из созвона в созвон гоняем запятую по «фиксить нельзя рефакторить», ведём разговоры о техническом долге. Только долг оказывается концептуальным.
Как и в любой сказке, в стране копирующих продуктов привычные нам вещи отзеркалены, так и концептуальный долг представляет собой не эхо ошибок, а отсутствие будущего из-за виляния — как хвостом — настоящего. В котором табаки-менеджменту снится, что он запускает ракеты, но всё равно просыпается убыточным стартапом.
Вы помните этого персонажа из Книги Джунглей. Не шибко опасен, не шибко умен, но он повсюду со своими мантрами. Если концепцию продукта можно представить в виде компаса, по которому можно сверяться и потому свободно перемещаться по пути к большой цели, то табаки-менеджмент не имеет такого компаса, он ориентируется на слухи: куда подул ветер, туда и развернут продукт. Это бизнес! Бизнес зовут! Подобное мельтешение ведёт к джунглям из спагетти-кода, что при первом приближении кажется техническим долгом.
Табаки-менеджмент этому рад, он может даже с пониманием относиться к рефакторингу, но при всей внешней дружелюбности он одёрнет вашего коллегу и попросит сделать вот эту срочную фичу и разобраться вот с этим важным клиентом. Клиент ушёл, фича никому не нужна, а ваш рефакторинг — это ваш рефакторинг.
Обеспечение защиты ПО, в том числе документации ПО, от угроз, возникающих в процессе передачи ПО пользователю.
Общее количество вебинаров — 30. Каждому из 25 процессов ГОСТа посвящён отдельный вебинар и ещё 5 записано дополнительно на смежные темы. Запись всех вебинаров и подборка дополнительной информации доступна по ссылке: ГОСТ56939.РФ.
Цикл вебинаров проведён компанией ООО "ПВС" совместно с учебным центром "Маском". Организаторами выступили Андрей Карпов и Виталий Пиков. Совместно с приглашёнными экспертами различных компаний мы рассмотрели 25 процессов, приведённых в ГОСТ Р 56939—2024.
P.S.
Суммарное время предлагаемых к изучению вебинаров составляет около 50 часов. Их можно смотреть на ускорении. Однако даже в этом случае с учётом дополнительных материалов и отсылок на внешние ресурсы изучение займёт около двух рабочих недель.
Это достаточно большая задача, поэтому мы решили помочь и разбили материалы на отдельные уроки. Так будет проще усваивать материал, а интерфейс позволяет отмечать, с чем вы уже познакомились.
Собрались как то Росатом, Камаз, Северсталь и РЖД, чтобы разработать отечественный стандарт Бережливого производства - ГОСТ Р 56020.
Сделали сначала первую версию от 2014 года.
Потом через несколько лет доработали и выпустили следующую - от 2020 года.
И вот в этом современном стандарте от монстров отечественной экономики используется перечень потерь из середины прошлого века...
Зачем критический подход? Видимо решили, что лучше оставить узкоспециализированный набросок от Тойоты, чем разработать нечто актуальное, логичное, удобное и более универсальное, чем конвейер с запчастями от автомобилей...
Хотя там весьма "современно" - много синонимов, выделенных в отдельные позиции и без какого-либо подхода к систематизации - просто список, как старику японцу приснилось.
Вот исходный тойотовский список из 7ми:
перепроизводство
избыток запасов
лишнее перемещение объектов (логистика)
задержки и простои
лишняя обработка
лишние движения человека
дефекты и брак
Вот, на мой взгляд, более адекватный для работы вариант:
использование неактуальной технологии
избыточность (операции, ресурсы, страховка)
ошибки и нарушения
упущенные возможности и простои
Чем меньше в списке позиций - тем проще его запомнить и применять на практике.
Чем лучше систематизация, тем более целостная получается модель.
Организация приёмки ПО с целью недопущения недостатков кода ПО перед его предоставлением пользователям.
Общее количество вебинаров — 30. Каждому из 25 процессов ГОСТа посвящён отдельный вебинар и ещё 5 записано дополнительно на смежные темы. Запись всех вебинаров и подборка дополнительной информации доступна по ссылке: ГОСТ56939.РФ.
Цикл вебинаров проведён компанией ООО "ПВС" совместно с учебным центром "Маском". Организаторами выступили Андрей Карпов и Виталий Пиков. Совместно с приглашёнными экспертами различных компаний мы рассмотрели 25 процессов, приведённых в ГОСТ Р 56939—2024.
P.S.
Суммарное время предлагаемых к изучению вебинаров составляет около 50 часов. Их можно смотреть на ускорении. Однако даже в этом случае с учётом дополнительных материалов и отсылок на внешние ресурсы изучение займёт около двух рабочих недель.
Это достаточно большая задача, поэтому мы решили помочь и разбили материалы на отдельные уроки. Так будет проще усваивать материал, а интерфейс позволяет отмечать, с чем вы уже познакомились.
Разработчикам программного обеспечения средств защиты информации рекомендуется использовать положения настоящей Методики для организации внутренних процессов жизненного цикла программного обеспечения в соответствии с ГОСТ Р 56939-2024 "Защита информации. Разработка безопасного программного обеспечения. Общие требования".
Разработка WMS и логика склада: интервью с основателем INTEKEY
Разрабатывать систему управления складом сложно, если команда не знает, как склад работает в реальности.
На канале TransRussia Connect вышло небольшое интервью с Денисом Сумелевым, основателем компании INTEKEY. Поговорили о специфике отрасли: как разработка софта пересекается с физической логистикой.
О чем идет речь в видео: — Зачем ИТ-компании держать в штате 90% бывших директоров складов. — Почему перед внедрением программы нужно пересобрать логистические процессы руками. — Как выстраивать систему внутри самой ИТ-компании, чтобы автоматизатор не был «сапожником без сапог».
