Обновить
512K+

Управление проектами *

Как заставить всё работать

632,09
Рейтинг
Сначала показывать
Порог рейтинга

ИИ для Университета 4.0, а «Королев ИИ» для МГТУ им. Н.Э. Баумана

Ключевой вызов для любого вуза, стремящегося к лидерству, — это не просто автоматизировать отдельные процессы, а создать единую «нервную систему», которая пронизывает все сферы деятельности: от образования и науки до управления и работы с талантами. Именно такую задачу мы ставим перед собой в МГТУ им. Н.Э. Баумана, разрабатывая научно-образовательную платформу «Королев ИИ».

Эта платформа — не просто набор модных чат-ботов. Это многоуровневая архитектурная среда, которая агрегирует и семантически обогащает данные, развёртывает специализированные сервисы на основе больших языковых моделей (LLM) и предоставляет единые интерфейсы для студентов, преподавателей, учёных и сотрудников. По сути, мы создаём «интеллектуальное ядро» цифровой экосистемы Университета 4.0.

«Королев ИИ»: архитектура будущего

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

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

2. Уровень интеллектуальных сервисов. Это «фабрика моделей» и «озеро научных знаний». Здесь развёртываются специализированные LLM-сервисы: от генерации персонализированных образовательных траекторий и адаптивного контента до интеллектуальной поддержки научных исследований и автоматизации управленческих процессов. Мы протестировали более 30 больших языковых моделей и создали первый рабочий прототип ИИ-ассистента, который понимает голос, обрабатывает запрос и даёт ответ естественным голосом.

3. Уровень взаимодействия. Это единая точка входа для всех пользователей. Студент получает персонализированного наставника, преподаватель — ассистента для автоматизации рутины, а учёный — инструмент для ускорения исследований.

Платформа «Королев ИИ» — это инструмент для достижения стратегических целей Программы развития МГТУ до 2030 года. Вот лишь несколько примеров того, как LLM меняют привычные процессы:

Образование. Мы решаем фундаментальную проблему «масштабируемой персонализации». ИИ-ассистент работает 24/7, помогая каждому из тысяч студентов осваивать материал в комфортном темпе. Платформа «Путь инженера» позволяет выявлять талантливых школьников и сопровождать их на всём пути: «школа — университет — индустрия».

Наука и инновации. LLM становятся катализатором продуктивности учёного. Сервисы семантического поиска, генерации гипотез и кода, поддержки публикационной активности помогают увеличить объём НИОКР и повысить количество публикаций в ведущих журналах. Мы создаём «озеро научных знаний», которое позволяет капитализировать интеллектуальный потенциал научных школ.

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

Доверенный и этичный ИИ

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

Что дальше?

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

Теги:
+1
Комментарии2

Про персональных агентов и что он умеет у меня

Дальше разговор пойдет про 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.В комментах скину домашку, которую можно выполнить, чтобы завести подобного агента и сделать более менее рабочим

Теги:
+5
Комментарии5

ГОСТ Р 56939-2024 на практике: что мы сделали, чтобы получить сертификат РБПО

🔎 Контекст
У Cloud.ru есть платформа, созданная специально для заказчиков, которые обязаны соблюдать особые требования к хранению данных и разработке ПО. Вся инфраструктура, которую они используют, должна быть аттестована на соответствие стандартам безопасности, а платформенные сервисы должны пройти жесткую проверку у регуляторов. Ранее платформа уже получала сертификат ФСТЭК России №4979, но при внесении определенной массы изменений в продукт, процесс требуется пройти заново, а сделать это невозможно без привлечения сторонней лаборатории и многомесячных ожиданий. Чтобы иметь возможность развивать продукт более оперативно, требовалось сертифицировать не только платформу для создания частного, гибридного или распределенного облака Cloud.ru Evolution Stack, но и все процессы вокруг нее, т.е. подтвердить соответствие ГОСТу Р 56939-2024.

🚀 Задача
Стандарт требует выстроить 25 взаимосвязанных регламентов и поддерживать более 200 артефактов в актуальном состоянии постоянно. Но этого мало: ведь стандарт есть, но конкретной методологии его реализации не существует, нужно было приземлить элементы процесса на орг.структуру нашей компании. Осложнялось всё тем, что в любой крупной ИТ-компании команды непрерывно перетасовываются, ответственные меняются, а любое кадровое изменение должно быть тут же отражено во всей документации сразу.

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

☁️ Что мы сделали
Применили существующую в компании BPM-систему как единый источник правды: описали в ней ключевые процессы РБПО, зафиксировали роли, связали их с командами через орг.структуру, разместили все артефакты, точки контроля и указали их взаимосвязи. Следующим этапом автоматизировали конвертацию и публикацию свежих документов: по расписанию из BPM-модели экспортируется HTML, который автоматически конвертируется в Markdown и публикуется во внутреннюю Wiki. Изменился владелец роли — один раз вносишь правки в BPM, все документы актуализируются и тут же становятся доступны всем и каждому. Чтобы новички не впадали в ступор от количества регламентов, поверх Wiki добавили ассистента с RAG под капотом. Можно написать в корпоративный чат любой вопрос и получить структурированную информацию о том, кто за что отвечает и как действовать в любой ситуации, причем сразу со ссылками на конкретный документ в базе знаний. 

🦾 Что получили в итоге
В компании появилась полная живая и взаимосвязанная база элементов, включающая организационные единицы, роли, артефакты и инструкции по процессам. То есть на аудите мы показываем не просто набор Word'овских файлов, а живую модель с автоматически собранными артефактами. Каждый сотрудник, причастный к процессу безопасной разработки ПО, четко знает, что в какой ситуации делать и уверен в том, что данные не устарели. ИИ-ассистент сокращает время погружения в регламенты и процессы с дней до пары десятков минут, что значительно упрощает онбординг при смене роли. 

Также такой подход позволил снизить затраты на устранение уязвимостей, поскольку их выявление предусмотрено на самых ранних стадиях процесса. Мы получили подтверждение качества платформы и стали первым облачным провайдером в России с сертификатом РБПО. У нас появилось больше контроля над собственным релизным циклом и теперь мы можем планировать обновления на годы вперед. 

🧠 Рефлексия
Можем смело рекомендовать аналогичный пайплайн командам, которые: 

  • сами готовятся к сертификации процессов РБПО;

  • хотят упростить адаптацию сотрудников на новых ролях; 

  • хотят убрать «слепые зоны» из разработки;

  • ищут способ более предметно демонстрировать работу руководству или инвесторам. 

Теги:
Всего голосов 3: ↑3 и ↓0+5
Комментарии1

РБПО по ГОСТ Р 56939—2024: вебинар №26 из 30 — Сертификация ПО согласно требованиям ФСТЭК и МО

Предлагаю вашему вниманию запись вебинара, где мы разбираем безопасную разработку ПО. Мы добрались до дополнительных (бонусных) вебинаров цикла. Рассмотрим "Сертификация ПО согласно требованиям ФСТЭК и Минобороны". На YouTube. Слайды.

В вебинаре обсуждается, что на самом деле даёт сертификат и почему он не гарантирует безопасность ПО. Какие программы обязаны проходить проверку, а какие — нет. Чем отличается сертификация от аттестации, и что происходит после получения сертификата. На эти и другие вопросы ответили в бонусном вебинаре цикла с Виталием Вареницей, ведущим специалистом ЗАО "НПО "Эшелон" по сертификации и тестированию на проникновение ПО

Общее количество вебинаров — 30. Каждому из 25 процессов ГОСТа посвящён отдельный вебинар и ещё 5 записано дополнительно на смежные темы. Запись всех вебинаров и подборка дополнительной информации доступна по ссылке: ГОСТ56939.РФ.

Методика ВУ и НДВ в ПО приведена в соответствие с ГОСТ Р 56939—2024

Материалы будут полезны всем, кто знакомится с темой РБПО и заинтересован во внедрении зрелых подходов в работу по созданию и сопровождению качественных программных продуктов. Материал по ГОСТ Р 56939—2024 весьма актуален, так как 12 мая 2026 утверждена обновлённая "Методика ВУ и НДВ в ПО". См. заметку "Методика выявления уязвимостей и недекларированных возможностей — 2026".

НЕкурс про РБПО

Суммарное время предлагаемых к изучению вебинаров составляет около 50 часов. Это достаточно большая задача, поэтому мы решили помочь и разбили материалы на отдельные уроки по РБПО. Возможно, так вам будет проще усваивать материал, а интерфейс позволяет отмечать, с чем вы уже ознакомились.

Теги:
Всего голосов 2: ↑2 и ↓0+4
Комментарии0

Что с хабром ?
Написал пост о том что выложил в opensource простенький ssh клиент и получил кучу дизлайков.

За что ? Я ничего не продаю, это ssh клиент которым я сам пользуюсь, пользуются еще несколько людей, через него удобно работать с туннелями и смотреть какой из сервисов отвалился

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

Как тогда делиться своими наработками, проектами, получать по ним обратную связь, если вокруг сколько негатива!
Если интересен проект, вот он на Github вот еще одно opensource приложение для транскрибации которое я развиваю

Я хочу обратную связь от сообщества, в правильном ли я направлении иду
Всем ПИС!

Теги:
Всего голосов 9: ↑9 и ↓0+12
Комментарии5

РБПО по ГОСТ Р 56939—2024: вебинар №25 из 30 — Обеспечение безопасности при выводе программного обеспечения из эксплуатации

Предлагаю вашему вниманию запись вебинара, где мы разбираем безопасную разработку ПО. Вебинар посвящен процессу из раздела 5.25. – "Обеспечение безопасности при выводе программного обеспечения из эксплуатации". На YouTube. Слайды. Это последний вебинар про процессы стандарта. Следующие пять будут бонусными.

Цели 25-го процесса по ГОСТ Р 56939—2024:

Недопущение реализации угроз безопасности, связанных с эксплуатацией неподдерживаемой версии ПО.

Общее количество вебинаров — 30. Каждому из 25 процессов ГОСТа посвящён отдельный вебинар и ещё 5 записано дополнительно на смежные темы. Запись всех вебинаров и подборка дополнительной информации доступна по ссылке: ГОСТ56939.РФ.

Методика ВУ и НДВ в ПО приведена в соответствие с ГОСТ Р 56939—2024

Материалы будут полезны всем, кто знакомится с темой РБПО и заинтересован во внедрении зрелых подходов в работу по созданию и сопровождению качественных программных продуктов. Материал по ГОСТ Р 56939—2024 весьма актуален, так как 12 мая 2026 утверждена обновлённая "Методика ВУ и НДВ в ПО". См. заметку "Методика выявления уязвимостей и недекларированных возможностей — 2026".

НЕкурс про РБПО

Суммарное время предлагаемых к изучению вебинаров составляет около 50 часов. Это достаточно большая задача, поэтому мы решили помочь и разбили материалы на отдельные уроки по РБПО. Возможно, так вам будет проще усваивать материал, а интерфейс позволяет отмечать, с чем вы уже ознакомились.

Теги:
Всего голосов 1: ↑1 и ↓0+3
Комментарии0

Как посчитать, приносит ИИ пользу или нет?  

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

Чтобы разобраться с этим вопросом, команда Альфа-Банка совместно с Альянсом в сфере ИИ, Ассоциацией ФинТех и двумя десятками ведущих компаний разработали методику расчёта финансового эффекта от ИИ-проектов и упаковали её в документ под названием «Методология оценки финансовой эффективности от ИИ/ГенИИ».

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

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

Теги:
Всего голосов 1: ↑1 и ↓0+3
Комментарии0

Очень критически надо читать умные статьи про найм персонала.
Потому что на примере этой статьи с Хабра, можно сделать серьезные выводы и ошибиться.Как компании теряют прибыль из-за ошибок в подборе и почему это редко видно сразу https://habr.com/ru/articles/1044856/

У автора есть одно допущение, которое не обозначено в статье, но считаю, что важно его обозначить - наличие на рынке труда того самого идеального кандидата.
Это допущение, однако, является не более чем заблуждением или когнитивным искажением.
На самом деле идеального кандидата просто не существует, а если даже он есть, что вы можете ему предложить? Идеальную работу? Что-то сомневаюсь...
Таким образом на рынке труда работодатель должен искать не лучших из лучших, а лучших, среди тех, кто есть. А есть на рынке труда не самые лучшие кадры, скорее наоборот, всех хороших уже расхватали. Значит остались только худшие.
Поэтому лучше следовать принципу, что всегда и везде мы выбираем лучшего из худших, а не самого идеального. Тогда будет проще выстроить процессы найма, адаптации, испытательного срока и т.д., не тратя много сил и ресурсов на поиск, не теряя время и деньги за тот период, пока кандидат не найден и вакансия висит. Иначе поиск затянется, работа не будет выполняться, бизнес-цели не будут достигаться.

Теги:
Всего голосов 4: ↑2 и ↓2+2
Комментарии0

РБПО по ГОСТ Р 56939—2024: вебинар №24 из 30 — Поиск уязвимостей в программном обеспечении при эксплуатации

Предлагаю вашему вниманию запись вебинара, где мы разбираем безопасную разработку ПО. Вебинар посвящен процессу из раздела 5.24. – "Поиск уязвимостей в программном обеспечении при эксплуатации". На YouTube. Слайды.

Цели 24-го процесса по ГОСТ Р 56939—2024:

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

Общее количество вебинаров — 30. Каждому из 25 процессов ГОСТа посвящён отдельный вебинар и ещё 5 записано дополнительно на смежные темы. Запись всех вебинаров и подборка дополнительной информации доступна по ссылке: ГОСТ56939.РФ.

Методика ВУ и НДВ в ПО приведена в соответствие с ГОСТ Р 56939—2024

Материалы будут полезны всем, кто знакомится с темой РБПО и заинтересован во внедрении зрелых подходов в работу по созданию и сопровождению качественных программных продуктов. Материал по ГОСТ Р 56939—2024 весьма актуален, так как 12 мая 2026 утверждена обновлённая "Методика ВУ и НДВ в ПО". См. заметку "Методика выявления уязвимостей и недекларированных возможностей — 2026".

НЕкурс про РБПО

Суммарное время предлагаемых к изучению вебинаров составляет около 50 часов. Это достаточно большая задача, поэтому мы решили помочь и разбили материалы на отдельные уроки по РБПО. Возможно, так вам будет проще усваивать материал, а интерфейс позволяет отмечать, с чем вы уже ознакомились.

Теги:
Всего голосов 1: ↑1 и ↓0+3
Комментарии0

Интеграции - Есть! Толку - нет :(

Давайте представим, что софтинка про документооборот - это рыба в воде. С жабрами, такая, хвостом и плавниками - прям адаптированная вся.

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

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

И вот все три сущности у нас есть, встает вопрос - как это всё связать друг с другом?

Удача то какая - все три решения заявляют - “У нас есть интеграции”!

Вот только среда существования у всех разная, функционал, предназначение, базовая логика - всё разное! И что надо? Вытаскивать рыбу на сушу или закапывать барса под землю? С чем “интегрировать” жабры? Со слепыми глазами?

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

PS: И чо? Задача - интересная. Работаю в эту сторону :)

Теги:
Всего голосов 1: ↑1 и ↓0+3
Комментарии0
18 июня, начало в 18:30 (Мск), онлайн, Zoom
18 июня, начало в 18:30 (Мск), онлайн, Zoom

Приходите на второй открытый онлайн Devhands AI Meetup #2!

📅 Когда: 18 июня, начало в 18:30 (Мск)

🔗 Где: Zoom (запись через таймпад

Формат: блиц по 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

Агенты: возможности/недостатки, опыт, сравнение, новинки, баги 

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

Локальные модели: модели, железо, сетапы, скорость и стоимость. 

Ошибки, которые я не повторю. Ошибки, которые я не повторю. Ошибки, которые я не повторю. Ошибки, которые я не повторю. Ошибки, которые я не повторю.

Теги:
Всего голосов 18: ↑17 и ↓1+24
Комментарии0

Написал бесплатное приложение для транскрибации — ⚡️ Talkis. Делал для себя как open‑source альтернативу платным сервисам по подписке.

Что оно умеет:

  • Расшифровывает созвоны (Zoom, Discord, Telegram и др.) в реальном времени прямо на лету.

  • Вытаскивает текст из любых готовых аудио‑ и видеофайлов.

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

Как это работает: модели можно крутить либо полностью локально на вашем железе (вообще бесплатно), либо подключить свои API‑ключи и платить копейки за токены без наценок сервисов.

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

🤩 GitHub  📥 Скачать

Теги:
Всего голосов 10: ↑9 и ↓1+11
Комментарии2

Руководитель, который не ошибается — и другие мифические существа

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

В новом выпуске «Свободного слота» — Андрей Колесников, SRE DevOps Lead в Авито и соведущий подкаста «В SREду на кухне». Разбираем топ управленческих косяков — и честно признаёмся в своих.

Что обсудили

Можно ли вообще научиться на чужих ошибках — или только на своих? Где грань между взвешенным решением и банальным затягиванием. Как говорить «нет» так, чтобы не прослыть неудобным руководителем. И как признавать ошибки до того, как с ними уже пришли к тебе — а не после.

Слушайте и смотрите новый выпуск на площадках:

📺 YouTube
🔵 ВК Видео
📌 RuTube
🎧 Яндекс Музыка
Ⓜ️ Mave

Ещё больше новостей — в нашем телеграм-канале

«Свободный слот» — терапевтичный контент для тимлидов и тех, кто хочет ими стать

Теги:
Всего голосов 16: ↑16 и ↓0+20
Комментарии0

Ближайшие события

РБПО по ГОСТ Р 56939—2024: вебинар №22 из 30 — Обеспечение поддержки программного обеспечения при эксплуатации пользователями

Предлагаю вашему вниманию запись вебинара, где мы разбираем безопасную разработку ПО. Вебинар посвящен процессу из раздела 5.22. – "Обеспечение поддержки программного обеспечения при эксплуатации пользователями". На YouTube. Слайды.

Цели 22-го процесса по ГОСТ Р 56939—2024:

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

Общее количество вебинаров — 30. Каждому из 25 процессов ГОСТа посвящён отдельный вебинар и ещё 5 записано дополнительно на смежные темы. Запись всех вебинаров и подборка дополнительной информации доступна по ссылке: ГОСТ56939.РФ.

Цикл вебинаров проведён компанией ООО "ПВС" совместно с учебным центром "Маском". Организаторами выступили Андрей Карпов и Виталий Пиков. Совместно с приглашёнными экспертами различных компаний мы рассмотрели 25 процессов, приведённых в ГОСТ Р 56939—2024.

Материалы будут полезны всем, кто знакомится с темой РБПО и заинтересован во внедрении зрелых подходов в работу по созданию и сопровождению качественных программных продуктов. Материал по ГОСТ Р 56939—2024 весьма актуален, так как 12 мая 2026 утверждена обновлённая "Методика ВУ и НДВ в ПО". См. заметку "Методика выявления уязвимостей и недекларированных возможностей — 2026".

P.S. Суммарное время предлагаемых к изучению вебинаров составляет около 50 часов. Это достаточно большая задача, поэтому мы решили помочь и разбили материалы на отдельные уроки по РБПО. Возможно, так вам будет проще усваивать материал, а интерфейс позволяет отмечать, с чем вы уже ознакомились. 

Теги:
Всего голосов 3: ↑3 и ↓0+5
Комментарии0

Как замечать тренды раньше конкурентов

Каждый год на рынок выходит более 30 000 новых продуктов, но успеха добиваются лишь 15–20% из них. Часто проблема не в качестве продукта, а в том, что рынок меняется быстрее, чем команды успевают адаптироваться к новым запросам пользователей и технологиям.

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

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

Что такое трендвотчинг

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

Это не фиксация текущего состояния рынка, а попытка понять, куда он движется дальше.

Почему простого анализа конкурентов уже недостаточно

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

Трендвотчинг позволяет смотреть шире:

  • какие технологии становятся доступнее;

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

  • какие темы растут в поиске и популярны в отраслевых обзорах.

Так можно заметить изменения раньше, чем они станут массовыми.

Где искать ранние сигналы 

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

Чаще всего использую:

  • Product Hunt, Trend Hunter и Springwise — чтобы следить за новыми продуктами и идеями;

  • Google Trends и Яндекс.Вордстат — чтобы анализировать интерес пользователей;

  • консалтинговые отчеты и отраслевые исследования — чтобы видеть долгосрочные изменения рынка.

Как понять, что тренд действительно важен

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

Практический подход примерно такой:

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

  2. Расширьте его синонимами и альтернативными формулировками.

  3. Сравните данные по регионам и сегментам аудитории.

  4. Посмотрите динамику и сезонные всплески интереса.

  5. Автоматизируйте мониторинг, создав дашборды и оповещения.

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

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

Когда сигналы собраны, их можно структурировать с помощью:

  • Trend Canvas — для глубокого анализа тренда;

  • упрощенного SWOT-анализа — для быстрой первичной оценки.

Чек-лист работы с трендами

  • Формулировка цели и задач исследования.

  • Сканирование сигналов — системный поиск и сбор информации.

  • Интерпретация и систематизация.

  • Оценка и приоритизация. 

  • Эксперименты и тесты — прототипы, MLP, пилоты.

  • Масштабирование и интеграция.

Какие тренды уже заметны на рынке

Один из самых заметных трендов сегодня — развитие low-code и no-code подходов.

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

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

Параллельно растет интерес к автоматизации, встроенным ИИ-функциям и более гибким системам управления проектами.

Почему выигрывают внимательные

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

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

Но не всегда важно быть первым. Иногда достаточно быть тем, кто заметил сигнал и сумел превратить его в осмысленное продуктовое решение :)

Теги:
Всего голосов 3: ↑2 и ↓1+3
Комментарии0

В стране копирующих продуктов.

Как сейчас помню. Прилетает баг. Пользователь-кассир видит закупочную цену. Исправил. Прилетает баг. Пользователь-управляющий видит не закупочную цену, а цену продажи. Фиксить нельзя рефакторить.

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

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

Ладно, не вышел. Был свидетелем. Как от спринта к спринту задачи не были связаны друг с другом. Сегодня мы делаем турникет, завтра апельсин, потом кузнечика, потому что срочно нужна наковальня, а у нас итерационный продукт! Если останется время, то переведём бабушку с ангуляра на рякт, если нет — дедушку, но закончить до сентября! Что будет через два месяца? Верно, бабка с дедом посреди дороги висят на турнике в шубах на рыбьем меху. А? Поняли? Поняли? Рыбий мех — кузнечный мех! Это аджайл, мамкина норка! Нет времени уточнять, тебе ещё апельсин чистить.

И вроде бы фантастика, ложь, абсурд! Но одна недоделанная фича сменяет другую и мы из созвона в созвон гоняем запятую по «фиксить нельзя рефакторить», ведём разговоры о техническом долге. Только долг оказывается концептуальным.

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

Вы помните этого персонажа из Книги Джунглей. Не шибко опасен, не шибко умен, но он повсюду со своими мантрами. Если концепцию продукта можно представить в виде компаса, по которому можно сверяться и потому свободно перемещаться по пути к большой цели, то табаки-менеджмент не имеет такого компаса, он ориентируется на слухи: куда подул ветер, туда и развернут продукт. Это бизнес! Бизнес зовут! Подобное мельтешение ведёт к джунглям из спагетти-кода, что при первом приближении кажется техническим долгом.

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

Теги:
Всего голосов 3: ↑3 и ↓0+5
Комментарии0

РБПО по ГОСТ Р 56939—2024: вебинар №21 из 30 — Безопасная поставка программного обеспечения пользователям

Предлагаю вашему вниманию запись вебинара, где мы разбираем безопасную разработку ПО. Вебинар посвящен процессу из раздела 5.21. – "Безопасная поставка программного обеспечения пользователям". На YouTube. Слайды.

Цели 21-го процесса по ГОСТ Р 56939—2024:

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

Общее количество вебинаров — 30. Каждому из 25 процессов ГОСТа посвящён отдельный вебинар и ещё 5 записано дополнительно на смежные темы. Запись всех вебинаров и подборка дополнительной информации доступна по ссылке: ГОСТ56939.РФ.

Цикл вебинаров проведён компанией ООО "ПВС" совместно с учебным центром "Маском". Организаторами выступили Андрей Карпов и Виталий Пиков. Совместно с приглашёнными экспертами различных компаний мы рассмотрели 25 процессов, приведённых в ГОСТ Р 56939—2024.

P.S.

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

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

Подробнее: НЕкурс про разработку безопасного программного обеспечения (РБПО).

Теги:
Всего голосов 3: ↑2 и ↓1+3
Комментарии0

Собрались как то Росатом, Камаз, Северсталь и РЖД, чтобы разработать отечественный стандарт Бережливого производства - ГОСТ Р 56020.

Сделали сначала первую версию от 2014 года.

Потом через несколько лет доработали и выпустили следующую - от 2020 года.

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

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

Хотя там весьма "современно" - много синонимов, выделенных в отдельные позиции и без какого-либо подхода к систематизации - просто список, как старику японцу приснилось.

Вот исходный тойотовский список из 7ми:

  • перепроизводство

  • избыток запасов

  • лишнее перемещение объектов (логистика)

  • задержки и простои

  • лишняя обработка

  • лишние движения человека

  • дефекты и брак

Вот, на мой взгляд, более адекватный для работы вариант:

  • использование неактуальной технологии

  • избыточность (операции, ресурсы, страховка)

  • ошибки и нарушения

  • упущенные возможности и простои

Чем меньше в списке позиций - тем проще его запомнить и применять на практике.

Чем лучше систематизация, тем более целостная получается модель.

Теги:
Всего голосов 7: ↑4 и ↓3+3
Комментарии7

РБПО по ГОСТ Р 56939—2024: вебинар №20 из 30 — Обеспечение безопасности при выпуске готовой к эксплуатации версии программного обеспечения

Предлагаю вашему вниманию запись вебинара, где мы разбираем безопасную разработку ПО. Вебинар посвящен процессу из раздела 5.20. – "Обеспечение безопасности при выпуске готовой к эксплуатации версии программного обеспечения". На YouTube. Слайды.

Цели 20-го процесса по ГОСТ Р 56939—2024:

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

Общее количество вебинаров — 30. Каждому из 25 процессов ГОСТа посвящён отдельный вебинар и ещё 5 записано дополнительно на смежные темы. Запись всех вебинаров и подборка дополнительной информации доступна по ссылке: ГОСТ56939.РФ.

Цикл вебинаров проведён компанией ООО "ПВС" совместно с учебным центром "Маском". Организаторами выступили Андрей Карпов и Виталий Пиков. Совместно с приглашёнными экспертами различных компаний мы рассмотрели 25 процессов, приведённых в ГОСТ Р 56939—2024.

P.S.

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

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

Подробнее: НЕкурс про разработку безопасного программного обеспечения (РБПО).

P.P.S. Знакомство с ГОСТ Р 56939-2024 – всё более актуальная задача

Информационное сообщение ФСТЭК России от 28 мая 2026 г. N 240/24/3693.

Разработчикам программного обеспечения средств защиты информации рекомендуется использовать положения настоящей Методики для организации внутренних процессов жизненного цикла программного обеспечения в соответствии с ГОСТ Р 56939-2024 "Защита информации. Разработка безопасного программного обеспечения. Общие требования". 

Теги:
Всего голосов 3: ↑3 и ↓0+5
Комментарии0

Разработка WMS и логика склада: интервью с основателем INTEKEY

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

На канале TransRussia Connect вышло небольшое интервью с Денисом Сумелевым, основателем компании INTEKEY. Поговорили о специфике отрасли: как разработка софта пересекается с физической логистикой.

О чем идет речь в видео:
— Зачем ИТ-компании держать в штате 90% бывших директоров складов.
— Почему перед внедрением программы нужно пересобрать логистические процессы руками.
— Как выстраивать систему внутри самой ИТ-компании, чтобы автоматизатор не был «сапожником без сапог».

Теги:
Всего голосов 1: ↑1 и ↓0+3
Комментарии0