Обновить
219.15

Анализ и проектирование систем *

Анализируй и проектируй

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

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

26 февраля на практическом вебинаре «Как предотвратить провал фичи: чек-лист валидации гипотезы до разработки», вы получите готовое решение — структурированный чек-лист для валидации гипотез до старта разработки. Этот инструмент поможет вам сэкономить ресурсы и избежать ошибок, и он применим как в Agile, так и в Waterfall-среде.

Разберем на практике:

➕ Как появляются фичи: от боли бизнеса до решения.

➕ Что такое настоящая потребность и как её выявить.

➕ Ключевые метрики продукта и проекта для оценки.

➕ Факторы, влияющие на грамотную приоритизацию.

➕ Особенности требований в Agile vs Waterfall.

➕ Рабочие методы валидации требований из практики крупных компаний.

Дата: 26 февраля

⏰ Время: 18:00-19:00 (Мск)

👨‍🎓 Спикер: Басова Екатерина — эксперт по бизнес-анализу и управлению продуктами.

➡️ Записаться

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

Kubernetes: правда такой сложный, каким кажется?

В новом выпуске подкаста «В SREду на кухне» разбираем Kubernetes — честно, по фактам и без лишней теории. Говорим о главном:

  • как выбирать между опенсорсным Kubernetes и вендорскими платформами;

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

  • когда команда действительно готова к своим кластерам.

И пытаемся понять, почему Kubernetes постепенно становится стандартом инфраструктуры, но при этом универсального решения до сих пор не существует.

Ведущие:

  • Михаил Савин, SRE Community Lead в Авито;

  • Андрей Волхонский, руководитель юнита System в Центре разработки инфраструктуры Авито;

  • Александр Глухих, TeamLead в юните Incident & Problem Managment в Авито.

Гость:

  • Юрий Лосев, технический директор в команде Deckhouse во «Флант».

Смотреть VK
Смотреть YouTube

Подписывайтесь на канал AvitoTech в Telegram, там мы рассказываем больше о профессиональном опыте наших инженеров, проектах и работе в Авито, а также анонсируем митапы и статьи.

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

Архитектурный минимум для аналитика: 4 вещи, чтобы понимать систему целиком

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

Роскошный архитектурный минимум для аналитика: понимать систему в целом и не бояться «богов»-архитекторов
Роскошный архитектурный минимум для аналитика: понимать систему в целом и не бояться «богов»-архитек...
habr.com

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

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

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

Разбираемся как принимать звонки в браузере. Основы WebRTC\SIP\RTP.

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

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

Разберем основную схему организации передачи голоса. Браузер по сути работает как SIP‑телефон: сигнализация через WebSocket, медиа — по RTP.

Упрощенно схему работы WebRTC/SIP можно разделить на "регистрацию", "звонок" и "завершение":
Упрощенно схему работы WebRTC/SIP можно разделить на "регистрацию", "звонок" и "завершение":

1. Регистрация в сети

  • Оператор открывает страницу в браузере.

  • Браузер отправляет SIP REGISTER на SIP‑сервер (WebSocket/TLS).

  • SIP‑сервер отвечает 200 OK.

  • В интерфейсе показывается «Вы в сети» — оператор готов к звонкам.

2. Звонок

  • SIP‑сервер отправляет SIP INVITE в браузер.

  • Браузер показывает уведомление «Входящий».

  • Оператор нажимает «Принять».

  • Браузер запрашивает доступ к микрофону (getUserMedia) — внутреннее действие.

  • Браузер отправляет SIP 200 OK + SDP на SIP‑сервер.

  • SIP‑сервер отправляет SIP ACK в браузер.

  • SIP‑сервер даёт команду RTP/SRTP‑шлюзу установить медиа‑сессию.

  • Медиа (RTP/SRTP по UDP) передаётся между браузером и RTP‑шлюзом.

  • Начинается разговор.

3. Завершение звонка

  • Оператор нажимает «Завершить».

  • Браузер отправляет SIP BYE на SIP‑сервер.

  • SIP‑сервер отвечает 200 OK.

  • Передача RTP/SRTP прекращается.

Если тема будет интересна, то далее обсудим схему работы backend'а и варианты развития общей схемы передачи голоса с плюсами, минусами и ограничениями.

В своем канале в Telegram и канале в Max о разработке в стартапах рассказываю еще больше интересного и делюсь опытом, заходите, буду рад!

Спокойных вам релизов и захватывающих решений !

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

Зима в разгаре, а мы нанимаем: новые вакансии в SSP SOFT

Кто мы и чем занимаемся? Лидеры («одни из», конечно) найма ИТ-специалистов на российском рынке за прошлый год мы наняли 179 сотрудников, и уже в январе 2026 к нам присоединились 11 новых гуру!
Занимаемся заказной разработкой ПО и предоставляем крупным клиентам выделенные команды на ИТ-аутсорсинг.

У нас новый московский офис, который открылся в 2025 году у самой Красной площади! А еще есть вакансии в офис в Томске и на удаленку из любой точки России.

Команда в SSP SOFT это реальные проекты, дружная атмосфера, где работать — продуктивно, без выноса мозга и микро-менеджмента. В январе 2026 ищем опытных спецов, кто готов в новое профессиональное будущее вместе с нами.

Самые горячие вакансии прямо сейчас:
(а всего их 11 на начало февраля 2026 - см. ссылку ниже на ХХ-ру)
1️⃣ Fullstack QA Engineer (Node.js)
2️⃣ Java-разработчик
3️⃣ Системный аналитик (ритейл)
4️⃣ Data Разработчик (Oracle, Greenplum)

Что предоставляет экосистема SSP SOFT:
✅ Мы пишем код, который формирует завтрашний день. Никакой скучной рутины.
✅ Центр компетенций и личное менторство ускорят развитие до максимума.
✅ Офис, гибрид или фулл-удаленка? Есть все варианты.
✅ Время — ваш ресурс. Мы его уважаем.

Подробности о вакансиях читайте на нашей странице ХХ.ру, но туда откликаться необязательно. Ждем резюме в ЛС нашей HR Lead Алине (https://t.me/AONikitina).
Не забудьте добавить «секретную фразу» в сопроводительное письмо, «Увидел(а) вашу вакансию на Хабре».

Желаем всем хабровцам успешной карьеры в 2026 году 🚀)

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

💥 Новое в Gramax 💥

  • Модуль метрик в Gramax Enterprise Server. Появились отчеты с метриками просмотров, визитов и посетителей на портале документации. А также статистика поисковых запросов. Отчеты можно фильтровать по дате и пользователям, выбирать период (день, неделя, месяц).

  • Поддержка Git LFS . Добавили возможность работать большими бинарными файлами (изображения, архивы, PDF и др.) через спецификацию Git LFS. 

  • Превью файлов. На портале для читателей доступно превью файлов PDF и DOCX по клику. Читателю не обязательно скачивать файл на компьютер — он может просмотреть его прямо в браузере.

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

  • Ссылки между каталогами. Добавили возможность добавлять относительные ссылки на статьи в других каталогах. 

  • Удаление запроса на слияние. Теперь можно закрыть запрос на слияние в интерфейсе Gramax — он будет удален для всех пользователей после публикации изменений.

  • История комментариев. В просмотре изменений теперь проще отслеживать обновления комментариев: слева появляется иконка комментария, которая показывает, что в тексте изменились или появились комментарии. Там же можно кликнуть по комментарию, открыть его и отредактировать.

Подробнее об изменениях читайте в статье — https://gram.ax/resources/docs/whats-new

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

Работающий продукт невозможен без документации

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

Мой путь в IT привел меня к системному анализу: до этого я пробовал себя и в роли проектного менеджера, и бизнес-аналитика, и даже частично тестировщика. И главная проблема каждого проекта, в разработке которого я участвовал — отсутствие документации.

Не снимаю с себя ответственности: зачастую объем документации зависел от моей работы, однако времени на нее было недостаточно — приходилось совмещать несколько ролей одновременно. Это, конечно же, приводило к путанице и большим проблемам в будущем. Отсутствие покрытия ключевых элементов системы приводит к багам и заваленной вопросами поддержке.

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

Целью другого проекта было его “возрождение” после полутора лет простоя. Багов — куча. Тестировщик спустя четыре месяца все еще ежедневно приходит ко мне с ошибками, на часть из которых мне сложно дать ответ: документация с прошлой разработки отсутствует полностью. Мне задают вопрос “Как должно быть?”, а мы не знаем даже того, для чего это вообще было реализовано. Разработка решения для устранения бага занимает меньше времени, чем поиск информации по этому функционалу.

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

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

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

Теги:
-3
Комментарии2

Как принять 4 проекта в курирование и не свихнуться?

TL;DR

Руководитель дал 4 новых проекта в архитектурный надзор. Держать всё в голове нереально. Изучил индустриальные практики и подготовил процесс приёмки совместно с Claude Code. Выложил в open-source. Буду рад feedback от вас и ваших агентов.

Как всё началось

Руководитель: "Вот тебе 4 проекта - принимай в работу."

Я: "Окей... А что там?"

Руководитель: "Узнаешь."

Контест:

  • 4 проекта

  • Где-то есть пересечение функциональности (где именно - неясно)

  • Команды разные, стек разный, зрелость разная

  • Держать всё это в голове - бесмысленно

Немного поглядел - стало понятно: нужен системный подход.

Что я сделал

1. Изучил индустриальные практики

Посмотрел, как это делают:

  • Futurice Project Handover Checklist

  • TOGAF Architecture Review

  • Harvard EA Checklist

  • Практики из книг (Software Architecture in Practice, Building Evolutionary Architectures)

2. Собрал процесс приёмки и аудита

Готовил совместно с Claude Code. Не в чистом виде, конечно с моей конфигурацией (на текущий момент это 3882 строк rules, skills and commands). Безусловно, вычитывал и редактировал.

Что получилось:

Процесс приёмки проекта

6 фаз:

  1. Инициация (получить вводную, доступы)

  2. Kickoff встреча (PM + Tech Lead)

  3. Сбор информации (документация, код, мониторинг)

  4. Аудит (анализ архитектуры)

  5. Решение о приёмке (принят/с оговорками/не принят)

  6. Онбординг в надзор (регулярные встречи, точки контроля)

Файлы:

Шаблоны аудита системы

Ручной аудит (12 разделов):

  • Структура системы (C4, bounded contexts)

  • Взаимодействие сервисов (sync/async, матрица зависимостей)

  • Паттерны и антипаттерны

  • Observability (метрики, логи, трейсинг, алерты)

  • Устойчивость (SPOF, graceful degradation, DR)

  • Безопасность

  • План улучшений

Автоматическая валидация (215 метрик):

  • Coupling и fan-out

  • Layer violations

  • God classes

  • Топологические метрики

Файлы:

На следующей неделе начинаю приёмку. Посмотрим как процесс сработает в реальности.

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

Вопрос к сообществу

Буду рад feedback от вас и ваших агентов:

  1. Процесс: Что лишнее? Чего не хватает?

  2. Чеклисты: Какие критичные пункты я упустил?

  3. Автоматизация: Используете ли инструменты для валидации архитектуры?

  4. Агенты: Если вы используете AI-агентов для аудита - какие задачи им даёте? Как проверяете результаты?

Open-source шаблоны:

С удовольствием улучшу на основе вашего опыта.

UPD: Если интересно как процесс сработал на практике - подписывайтесь, расскажу после завершения приёмки.
Поддержать меня: https://t.me/MikeShogin

Теги:
-4
Комментарии0

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

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

А? Ничего не щелкает?

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

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

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

Тут-то и нужен FinOps. Только так можно понять, что реально работает, а что просто лежит мертвым грузом. И хорошо еще, если соответствующий инструментарий уже есть. А если нет? Для таких случаев есть FinOps Radar — бесплатный инструмент, который позволит экономить до 30%.

А, если не ясно, как действовать, приходите к нам в комьюнити. Тут мы как раз обсуждаем такие вещи, делимся болью и ищем выходы из разных ситуаций с реальными цифрами и фейспалмами.

В общем, лучше разобраться сейчас, чем потом сидеть и думать, почему у вас все снова самонадулось.

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

Новые вакансии в SSP SOFT на конец января

Кто мы? Лидеры («одни из», конечно) найма ИТ-специалистов на российском рынке за прошлый год мы наняли 179 сотрудников! Занимаемся заказной разработкой ПО и предоставляем крупным клиентам выделенные команды на ИТ-аутсорсинг.

У нас новый московский офис, который открылся в 2025 году у самой Красной площади! А еще есть вакансии в офис в Томске и на удалёнку из любой точки России.

Команда в SSP SOFT это реальные проекты, дружная атмосфера, где работать — продуктивно, без выноса мозга и микро-менеджмента. В январе 2026 ищем гуру, кто готов в новое профессиональное будущее вместе с нами.

1️⃣ Python AI разработчика
2️⃣ Java Tech Lead
3️⃣ Data Разработчика (Oracle, Greenplum) (https://vk.cc/cTLO9g)
4️⃣ Системного аналитика (ритейл) (https://vk.cc/cTLOcv)

Что вас ждет в SSP SOFT:
✅ Рост: Центр компетенций для максимального апгрейда скиллов.
✅ Свобода геолокации: Возможность работать удаленно, гибрид или офис.
✅ Баланс work-life: Работаем, чтобы жить, а не наоборот.

🎁 Приятные бонусы: ивенты для всей команды, ДМС для штата, обучение и бенефиты.

Подробности о вакансиях читайте на нашей странице ХХ.ру, но туда откликаться необязательно. Ждем резюме в ЛС нашему HR Lead Алине (https://t.me/AONikitina).
Не забудьте добавить «секретную фразу» в сопроводительное письмо, «Увидел(а) вашу вакансию на Хабре».

Желаем всем хабровцам успешной карьеры в 2026 году 🚀)

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

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

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

Почему регистрация событий ИБ — это всегда вызов

Событие ИБ — состояние системы, указывающее на важное с точки зрения безопасности действие, например, нарушение политики ИБ или сбой. 

Звучит просто, но в реальности возникает множество проблем:

  • требования часто сформулированы абстрактно — «иные действия пользователей», «события, связанные с безопасностью»;

  • невыполнение требований ИБ может заблокировать весь проект;

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

Откуда берутся требования

Во внедрении я сталкиваюсь сразу с несколькими источниками:

  • требования по защите персональных данных — например, приказ ФСТЭК № 21;

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

  • отдельные требования финансовых организаций;

  • внутренние документы заказчика, к которым не всегда есть доступ;

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

Недавно в нормативке появились практические ориентиры. ФСТЭК выпустил рекомендации по базовой настройке регистрации событий безопасности — с примерами настройки логирования в ОС.

Как я структурирую требования по событиям ИБ

Чтобы работать с этим массивом, я условно делю требования на четыре группы.

Общие требования

Сроки хранения архивов журналов, источники событий, уровни системы: от ПО до сетевого оборудования.

Общий перечень событий

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

Состав полей события безопасности

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

Мониторинг и передача в SIEM-систему

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

Что я вынесла из практики

  1. Требования в ТЗ — это только часть картины, всегда нужно копать глубже.

  2. Требования меняются по ходу проекта и это нормально.

  3. Все договоренности важно фиксировать письменно.

  4. Нужно учитывать не только нормативные документы, но и локальные требования заказчика.

  5. Про SIEM-интеграцию стоит думать сразу, чтобы не пришлось переделывать позже.

  6. Важно заранее договориться, кто и сколько хранит логи.

→ Подробнее своим опытом Лиза поделилась в статье.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Не лайфхаки, а системный подход

К кому идти за ростом — техлиду, delivery или HR? Системный аналитик в статье «Как я перестала искать карьеру и начала видеть систему: системные законы как компас в хаосе матричной структуры» применяет теорию систем к карьере.

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

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

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

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

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

AI не заменяет - AI меняет роль

Спор про скорость - ловушка. Правильный вопрос: что стало узким местом?

55% компаний, которые уволили людей из-за AI, теперь жалеют (Orgvue, 2025). Исследование METR показало странное - разработчики думают что с AI работают на 20% быстрее, а объективно на 19% медленнее (METR, июль 2025).

Хинтон говорит что скоро AI будет делать за минуты работу на месяц. CEO AWS называет отказ от найма джуниоров "одной из самых глупых вещей" (MIT Tech Review).

Кто прав? Мой опыт говорит - оба мимо. AI не заменяет и не замедляет. Он меняет распределение труда.

Что отдал AI

Почти всю черновую аналитику:

  • Spec drafts - первые версии спецификаций по сырым требованиям

  • C4 диаграммы - контейнеры, компоненты, контекст

  • Sequence diagrams - потоки взаимодействия

  • Поисковые запросы - сбор контекста из документации и кодовой базы

  • Тест-кейсы - acceptance criteria по спецификации

Ручное кодирование сократил до точечных мест: интерфейсы, критичные участки, отладка. Всё остальное - через агента.

Звучит как будто всё отдал. Но нет.

Что не отдам

Здоровье. Доктор может использовать AI - это хорошо. Но это должен быть доктор с образованием и опытом. AI как инструмент - да. AI вместо врача - нет.

То же с психологом и коучем. Всё что связано со здоровьем и осознанностью - только к профессионалам.

В коде аналогично: security-критичные участки, интерфейсы с внешними системами, инварианты бизнес-логики - там доля ручной работы и глубокой экспертизы остаётся выше. AI ускорил черновики и сбор вариантов, но ответственность за модель и критерии - на мне.

Про "парадокс продуктивности"

Подозреваю, что люди измеряют "ощущение скорости", а система измеряет "время до принятого PR".

Не согласен с интерпретацией METR.

Раньше: пробуешь 1-2 варианта, выбираешь, идёшь. Натыкаешься на проблемы - третья версия. Четвёртая. Legacy копится.

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

Микро-кейс: фича интеграции с внешним API. Раньше - 3 дня на реализацию, потом 2 дня на переделку когда выяснились edge cases. Сейчас - 1.5 дня, но 40% времени ушло в спецификацию и тест-контракты. Переделок ноль.

Это не замедление. Это сдвиг: меньше "time-to-code", больше "time-to-confident".

Джуниоры: как меняется обучение

CEO AWS: "Как это будет работать через 10 лет, когда никто ничему не научился?"

Согласен. Передача знаний должна быть. С AI можно делать сайты без образования - но индустрия не только про сайты. Есть вещи где нужна математика и computer science.

Но джуниор теперь не "пишет CRUD". Джуниор учится:

  • Формулировать требования так, чтобы агент понял

  • Писать тест-контракты до реализации

  • Дебажить и верифицировать результат

  • Понимать, когда AI галлюцинирует

Сдвиг роли

Меньше клавиатурной работы, больше постановки, проверки и ответственности за инварианты.

Раньше - исполнитель. Теперь - проектировщик и валидатор.

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

Что стало важнее

Системный подход. "Герой-разработчик" и "пожаротушитель" - уходит. Ценятся люди, которые системно решают задачи.

И новый навык: строить свою систему работы с AI.

Это мой актив. Моя интеллектуальная собственность. Я трачу время не только на задачи, но и на эту систему.

Теги:
Всего голосов 9: ↑2 и ↓7-5
Комментарии7

Новый поиск в Gramax!

Мы сделали быстрый офлайн-поиск по всей документации.
Открывается через Cmd/Ctrl+/, навигация стрелками, Enter – переход с подсветкой найденного фрагмента. Подхватывает опечатки и кривую раскладку.

Помогает быстро переключаться между статьями и проектами.
Работает одинаково в приложении и в докпортале.

---
Gramax – это база знаний с хранением контента в Git в Markdown-файлах и с визуальным редактором.
Подробнее о проекте: https://gram.ax/ru

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

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

Используя API HH, я в течение последних 3,5 месяцев отслеживал изменения в количестве открытых вакансий на позиции "системный аналитик" и "бизнес-аналитик" (в соответствии с моей специализацией). Результаты, впрочем, подтвердили озвучиваемый в постах тренд, и поэтому вряд ли кого-либо должны удивить. Однако я всё же решил поделиться с сообществом накопленной статистикой (пусть и небольшой).

Для справки, привожу параметры запроса для выборки:

  • регион: Россия

  • период публикации: 30 дней

  • поле для поиска: в названии вакансии

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

Представлен учебный проект «Числа Python, которые должен знать каждый программист» (Python Numbers Every Programmer Should Know). Проект также доступен на GitHub.

«Существуют цифры\числа\значения, которые должен знать каждый программист на Python. Например, насколько быстро или медленно добавляется элемент в список в Python? А как насчёт открытия файла? Это занимает меньше миллисекунды? Есть ли что‑то, что замедляет этот процесс? Если у вас есть алгоритм, чувствительный к производительности, какую структуру данных следует использовать? Сколько памяти занимает число с плавающей запятой? А как насчёт одного символа или пустой строки? Насколько быстр FastAPI по сравнению с Django? Я хотел бы уделить немного времени и записать показатели производительности, специально ориентированные на разработчиков Python», — сообщил автор проекта Майкл Кеннеди.

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

Новогодняя аномалия в данных мониторинга.

С Новым Годом!
С Новым Годом!

Воспроизвести достаточно просто

  • Скачать и установить Dimension-UI.

  • Развернуть локально PostgreSQL.

  • Запустить в Dimension-UI мониторинг данных PostgreSQL с помощью запроса с интервалом 3 сек.

WITH params AS (
    SELECT 
        15 AS total_frames,
        20 AS canvas_height,
        3  AS frame_duration_sec
),
animation_state AS (
    SELECT 
        (CAST(EXTRACT(EPOCH FROM CURRENT_TIMESTAMP) AS INTEGER) / frame_duration_sec) % total_frames AS frame_idx
    FROM params
),
tree_definition AS (
    SELECT 
        frame_id, 
        y_pos,
        CASE
            -- ═══════════════════════════════════════
            -- ЗВЕЗДА на верхушке
            -- ═══════════════════════════════════════
            WHEN y_pos = 20 AND frame_id = 7 THEN '*'
            
            -- ═══════════════════════════════════════
            -- ВЕРХУШКА елки (острая)
            -- ═══════════════════════════════════════
            WHEN y_pos = 19 AND frame_id = 7 THEN 'G'
            
            -- ═══════════════════════════════════════
            -- ЯРУС 1 (y=16-18) — расширяется книзу
            -- ═══════════════════════════════════════
            WHEN y_pos = 18 AND frame_id BETWEEN 6 AND 8 THEN 'G'
            WHEN y_pos = 17 AND frame_id BETWEEN 5 AND 9 THEN 'G'
            WHEN y_pos = 16 AND frame_id BETWEEN 4 AND 10 THEN 'G'  -- широкий низ яруса
            
            -- Сужение перед ярусом 2
            WHEN y_pos = 15 AND frame_id BETWEEN 5 AND 9 THEN 'G'
            
            -- ═══════════════════════════════════════
            -- ЯРУС 2 (y=12-14)
            -- ═══════════════════════════════════════
            WHEN y_pos = 14 AND frame_id BETWEEN 4 AND 10 THEN 'G'
            WHEN y_pos = 13 AND frame_id BETWEEN 3 AND 11 THEN 'G'
            WHEN y_pos = 12 AND frame_id BETWEEN 2 AND 12 THEN 'G'  -- широкий низ яруса
            
            -- Сужение перед ярусом 3
            WHEN y_pos = 11 AND frame_id BETWEEN 4 AND 10 THEN 'G'
            
            -- ═══════════════════════════════════════
            -- ЯРУС 3 (y=8-10)
            -- ═══════════════════════════════════════
            WHEN y_pos = 10 AND frame_id BETWEEN 3 AND 11 THEN 'G'
            WHEN y_pos = 9  AND frame_id BETWEEN 2 AND 12 THEN 'G'
            WHEN y_pos = 8  AND frame_id BETWEEN 1 AND 13 THEN 'G'  -- широкий низ яруса
            
            -- Сужение перед ярусом 4
            WHEN y_pos = 7 AND frame_id BETWEEN 3 AND 11 THEN 'G'
            
            -- ═══════════════════════════════════════
            -- ЯРУС 4 — нижний, самый широкий (y=4-6)
            -- ═══════════════════════════════════════
            WHEN y_pos = 6 AND frame_id BETWEEN 2 AND 12 THEN 'G'
            WHEN y_pos = 5 AND frame_id BETWEEN 1 AND 13 THEN 'G'
            WHEN y_pos = 4 AND frame_id BETWEEN 0 AND 14 THEN 'G'  -- во всю ширину!
            
            -- ═══════════════════════════════════════
            -- СТВОЛ (y=1-3)
            -- ═══════════════════════════════════════
            WHEN y_pos BETWEEN 1 AND 3 AND frame_id BETWEEN 6 AND 8 THEN 'T'
            
            -- Всё остальное — фон
            ELSE 'S'
        END AS pixel_char
    FROM generate_series(0, 14) AS frame(frame_id)
    CROSS JOIN generate_series(1, 20) AS y(y_pos)
),
pixel_data AS (
    SELECT td.*
    FROM tree_definition td
    JOIN animation_state ast ON td.frame_id = ast.frame_idx
),
layers_logic AS (
    SELECT 
        y_pos,
        pixel_char,
        MAX(CASE WHEN pixel_char IN ('T', 'G', '*') THEN y_pos ELSE 0 END) OVER () as max_obj_height
    FROM pixel_data
)
SELECT 
    CURRENT_TIMESTAMP as dt,
    CASE 
        WHEN pixel_char = 'T' THEN '4_Trunk'
        WHEN pixel_char = 'G' THEN '3_Tree'
        WHEN pixel_char = '*' THEN '2_Star'
        WHEN pixel_char = 'S' THEN 
            CASE WHEN y_pos > max_obj_height 
    

p.s. Данные по запросу любезно предоставлены Claude Opus 4.5.

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

Готово ли ваше облако к 2026 году? Быстрый FinOps-чек-лист

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

Это бесплатный инструмент в формате гугл-таблицы. Прохождение занимает 5–7 минут.

Что дает чек-лист:

  • видно, где процессы уже работают, а где есть пробелы

  • понятно, на каких этапах теряется прозрачность расходов

  • есть конкретные шаги, что имеет смысл внедрять дальше

Чек-лист можно пройти одному, например CTO или Head of Engineering, либо вместе с командой, инженером, архитектором и финансовым специалистом.

Результат, понятный срез текущего состояния и ориентиры, как корректировать облачные расходы в 2026 году.

👉 Забрать чек-лист

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

Компания «Форсайт» представляет новый релиз своего флагманского программного продукта - «Форсайт. Аналитическая платформа» 10.10!

Новая версия 10.10 – это STS-релиз для быстрого развития (Short Term Support), промежуточный выпуск, который включает новые функции перед их интеграцией в релиз с долгосрочной поддержкой.
В версии 10.10 много новых возможностей для визуализации данных в веб-приложении.
Мы сделали удобнее инструмент Self-Service BI – информационные панели:

• добавили гибкую настройку элементов управления
• реализовали настройку параметров вложенных объектов
• добавили в табличный визуализатор условное форматирование и закрепление строк

Мы расширили возможности регламентных отчетов и форм ввода в вебе:
• стало удобнее работать с диаграммами и формулами
• мастер функций пополнился новыми функциями
• расширены возможности настройки печати
• при вводе формулы в строку формул и ячейку таблицы появилось отображение подсказок
• реализовано отображение окна подтверждения перед сохранением и отменой изменённых данных

Что еще нового в релизе 10.10?
• расширены возможности администрирования приложений
• расширена функциональность менеджера обновлений
• реализован новый API платформы для разработки прикладного приложения в системных сборках: Dashboard, Express, Fore, Metabase, RDS, WebForms

Напоминаем, что начиная с выпуска «Форсайт. Аналитическая платформа» 10.11 LTS (апрель 2026 года):
• в стандартной поставке будут отсутствовать настольное приложение для настройки платформы и Конструктор бизнес-приложения версии 9.x;
• будет прекращена поддержка платформы на Astra Linux SE 1.7 в связи с прекращением её поддержки производителем.
Подробнее о новой версии читайте здесь.

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

Аналитический долг в документации (и иных аналитических артефактах)

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

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

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

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

Насколько важно полное соответствие

Идеал не нужен и за него никто никогда не заплатит. Документация, которая на 80% соответствует коду, но содержит все ключевые бизнес-правила и принятые архитектурные решения, будет ценнее, чем документация, на 100% соответствующая коду, но погрязшая в деталях. Необходимо понимать, что есть некая критическая актуальность документации, выход за пределы которой нецелесообразен. Прежде всего актуальными должны быть описания интерфейсов API, схем ключевых бизнес-процессов, core-домена. Остальное можно обновлять по требованию, и это не будет считаться „долгом“, а будет осознанной стратегией.

Что делать для рефакторинга

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

Кто и когда это должен делать

За свою документацию отвечает каждый аналитик. Нужно согласовать с руководством и запланировать время на рефакторинг в общем объёме основных задач, браться за него в те дни, когда аналитическая проработка новой функциональности буксует на месте, либо по требованию разработки, тестирования или службы технической поддержки. Читать документацию и оставлять комментарии должны разработка, тестирование, служба поддержки и product owner.

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

Поэтому читать свою документацию лучше в режиме редактирования (чужую — в режиме комментирования), и сразу отмечать, уточнять и исправлять неясности, сокращать избыточные описания и распутывать спагетти в BPMN и UML-схемах.

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

Теги:
Рейтинг0
Комментарии0

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

Не очень важно, продуктовая или проектная деятельность у компании.

Важно именно закрепление ожиданий.

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

Ровно как работу бэкенда часто можно свести к перекладыванию JSON в записи в БД, а записи в БД в XML; или работу фронтенда можно привести к правилам формирования JSON из данных, введённых пользователем в форме (или отображения данных, полученных в JSON от бэка в интерфейсе), работу системного аналитика можно свести к правилам перекладывания JSON’ок.

Но делать это не нужно. Аналитик фиксирует социальный контракт в рамках конкретного проекта или продукта на конкретный временной промежуток.

Теги:
Рейтинг0
Комментарии0

Как снизить счета за мультиоблако

Как так-то, а?
Как так-то, а?

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

Причин тому 3:

  • Разная тарификация. Один провайдер включает трафик в стоимость ВМ, второй берёт за каждый гигабайт отдельно. Третий считает по часам, четвёртый – по фиксу. Свести все это воедино – задачка со звездочкой.

  • Стоимость межоблачного трафика. Если база живёт в одном облаке, а приложение – в другом, каждый запрос гоняет данные туда-обратно. 

  • Отсутствие прозрачности. Когда никто не знает, во что обходится работа, – это большая проблема. Ведь если не знаешь цифры, то и оптимизировать нечего.

Что с этим делать?

  • Закладывать мультиклауд в архитектуру сразу. Kubernetes, Terraform, инфраструктура как код — это не модные словечки, а реальная защита от vendor lock-in.

  • Считать cost per unit для каждого сервиса.

  • Давать командам бюджеты и показывать реальные цифры. Когда разработчики видят, что их фича жрёт 300 тысяч в месяц, они вдруг начинают задумываться об оптимизации.

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

Есть что сказать по теме мультиклауд? Присоединяйтесь к нашему комьюнити Практики FinOps. Там очень ждут вашего мнения.

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

Мозг не всегда союзник

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

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

Эта статья — для тех, кто устал от собственного «автопилота» и хочет думать осознанно, а не по шаблонам. Статья подойдёт аналитикам, продактам и всем, кто хочет думать шире, чище и системнее — и меньше попадать в ловушки собственного мышления.

Теги:
Рейтинг0
Комментарии0

Когда система зарастает костылями: мысли об архитектуре и способах её лечить

Архитектура редко ломается в одном месте — обычно она тихо зарастает костылями, «временными» решениями и компромиссами. В новой статье нашего корпоративного архитектора «Мысли об архитектуре и о том, как можно побороть в ней проблемы» — разбор того, какие системные проблемы копятся в архитектуре большого банка и что с ними можно сделать на уровне принципов, а не разовых затычек.​

Мысли об архитектуре и о том, как можно побороть в ней проблемы
Меня зовут Максим Седов, я корпоративный архитектор. Хочу рассказать о проблемах, с которыми мы (а м...
habr.com

Делимся практическим применением архитектурных паттернов. И, конечно, не можем обойти стороной тренды — искусственный интеллект и LLM. Итак, о чём пойдёт речь. 

  • Какой была архитектура до 2020 года. 

  • Накопленные за годы проблемы.

  • Куда бы хотели прийти.

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

Теги:
Рейтинг0
Комментарии0

Каждый день вы выбираете: стек технологий, подрядчика, приоритетную задачу. Но на чём основан этот выбор? Чаще — на интуиции, чужом авторитете или табличке в Excel с субъективными плюсами. Результат? Упущенная выгода, техдолг и проекты, которые не окупаются. Субъективное решение — самая дорогая статья расходов в ИТ.

18 декабря в 16:00 (Мск) приглашаем вас на практический вебинар «Принятие оптимальных решений: от интуиции к ROI и ИИ». Мы покажем четкую систему, как перейти от хаоса к математически обоснованному выбору. 

Вы научитесь:

✔️ Создавать объективную параметрическую таблицу с весовыми коэффициентами, которая «изгоняет демонов субъективности».

✔️ Рассчитывать ROI и TCO: переводить любую техническую особенность на язык денег, понятный финансовому директору.

✔️ Использовать ИИ для автоматизации рутинной аналитики и поиска оптимального решения.

🕓 Когда: 18 декабря, 16:00–17:00 (Мск)

👨‍🎓 Спикер: Шеховцов Алексей — эксперт в области управления ИТ и принятия решений.

➡️ Записаться

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

Демонстрационный атлас Luxms BI: лучшие практики в одном месте

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

Атлас содержит более 40 демонстрационных дэшбордов, каждый из которых показывает конкретную функцию Luxms BI: от стилизации таблиц и условий форматирования до использования write-back, LPE-выражений, расширенного расчетного функционала и многого другого.

Каждый дэшборд – это компактный «мини-кейc». Справа – готовая визуализация, слева – объяснение, из чего она состоит и как настроена. Вы сразу понимаете механику, видите конечный результат и можете повторить его у себя в проекте.

Демоатлас Luxms BI
Демоатлас Luxms BI

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

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

Готовые решения, собранные в одном месте, делают работу с платформой намного проще, атлас выполняет роль и некого справочника лучших практик, и источника быстрых находок для разработчиков, аналитиков, или тех, кто только начинает знакомство с Luxms BI.

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

Теги:
Рейтинг0
Комментарии0

Зачем становиться IT-ментором и что на самом деле стоит за этим?

Работа IT-ментора — это не только передача знаний, но и неожиданные вызовы, развитие и личные открытия. В статье «Год в роли IT-ментора: неочевидные выводы, цифры и стоит ли оно того» автор делится опытом первого года в роли ментора: сколько времени это занимает, какие трудности возникают, и почему этот путь того стоит.

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

Если любите IT, хотите развиваться и задумываетесь о роли наставника — эта статья даст полезный взгляд «изнутри» и вдохновит на новые шаги в карьере.

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

💥 Новое в Gramax 💥

Всем привет! Меня зовут Катя, я развиваю Gramax, open source-платформу для управления технической документацией. За последние 3 месяца мы сделали много новых полезных функций, коротко расскажу о самых важных.

  • Интеграция с GitVerse. Теперь в качестве хранилища можно использовать GitVerse. Как подключить GitVerse к Gramax читайте в статье.

  • Поддержка Gitea. Также добавили поддержку Gitea: доступно подключение в качестве хранилища и использование всех возможностей Gramax.

  • Экспорт в PDF и DOCX в собственных стилях. Можно настроить вид документа: добавить титульную страницу, оглавление, номера заголовков, собственные шрифты и отступы и так далее. Для DOCX — с помощью стилей, для PDF — с помощью CSS. Применяется при экспорте из приложения, портала документации и в CI/CD.

  • Новые возможности для статического сайта. В новой версии Gramax CLI поддерживается: развертывание в поддиректориюкастомная страница 404настройка стилейиндексациисбора метрик и логотипа.

  • Предпросмотр загруженных файлов. Теперь при клике на загруженный файл в статье открывается окно предпросмотра. Отображаются файлы форматов DOCX и PDF. Остальные форматы — скачиваются.

  • Улучшения поиска.

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

    • Переход к поисковой фразе. После клика на результат поиска статья откроется на том фрагменте, в котором есть поисковый запрос.

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

    • Поиск по свойствам в приложении. Если на статьях установлены свойства — в поисковой строке можно отфильтровать по ним.

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

  • Улучшения Gramax Enterprise Server.

    • Разворачивание с помощью Helm. Добавили новый способ разворачивания Gramax Enterprise Server в Kubernetes.

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

    • Поиск по вложенным файлам. Теперь поиск учитывает не только контент статьи, но и контент из PDF и DOCX-файлов.

О других изменениях читайте в Release Notes.

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

Делимся записью прошедшего вебинара "Самые необычные применения BI. Решения, которые уже работают".

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

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

Получился насыщенный вебинар, который вдохновляет искать новые точки применения аналитики!

Смотрите вебинар на нашем сайте

Теги:
Рейтинг0
Комментарии0

👉 Декабрь в разгаре, и у нас есть вакансии присоединяйтесь к SSP SOFT 💻


Говорят, что в декабре никто не нанимает, но это не про нас! Приглашаем опытных специалистов присоединиться к команде SSP SOFT 🌐

✨ У нас в SSP SOFT — проекты, которые удивлят своей сложностью, а затем станут точками роста.
✨ С первого дня вы не одни: за вами закрепляется наставник, который помогает входить в работу спокойно и без лишнего напряжения.
✨ Карьерный скачок здесь реален: наш Проектный офис — это не просто управление, а среда, которая ускоряет профессиональное развитие.
✨ Вы сами выбираете формат: работайте удаленно, приходите в офис в Москве (ЦАО) или в Томске — или комбинируйте (по согласованию с тимлидом).
✨ Мы не пропагандируем культ переработок — рабочие процессы настроены, а личное время и забота о здоровье уважаются.

Бонусы тоже есть:
🎁 ДМС (включая стоматологию) для штатных сотрудников
🎁 обучение за счет компании
🎁 бонусные программы
🎁 общие ивенты — от онлайн-квизов до выездных сборов

📢 Вот кого мы ищем в декабре (Подробности о вакансиях читай на ХХ.ру):

  • Python developer (LLM)

  • С# Разработчик (интеграции с Lekton)

  • Администратор второй линии поддержки/Devops специалист

  • Аналитик- консультант 1С

  • Аналитик 1С (Middle)

  • Системный аналитик (Senior)

  • Аналитик 1С (Senior)

  • Разработчик Directum

👉 Присылайте резюме напрямую в ЛС нашему HR Lead Алине. Не забудьте добавить сопроводительное письмо с ключевой фразой «Нашел(ла) вас на Хабре».

Спасибо за интерес к нашим вакансиям и желаем успеха на собесе )

Теги:
Рейтинг0
Комментарии0

Запуски 2025: анализ данных

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

«Обработка естественного языка — NLP» — 2 месяца
Разберёте актуальные задачи NLP: NER, генерацию, машинный перевод, QA-системы. Погрузитесь в работу с LLM, научитесь адаптировать модели под бизнес-кейсы и оценивать их качество.

«Мидл системный аналитик» — 4 месяца
Изучите на практике востребованные технологии и инструменты: MSA, SOAP API, Apache Kafka, Postman, Swagger и другие, чтобы перейти на следующий уровень в профессии.

«Аналитик SOC» — 4 месяца
Научитесь реагировать на угрозы, предотвращать атаки, анализировать события в SIEM, строить цепочки атак и работать с полным циклом реагирования в IRP/SOAR.

«Инженер по глубокому обучению нейросетей» — 2 месяца
Прокачаете фундаментальные навыки Deep Learning. Научитесь работать в PyTorch, обучать нейросети, проектировать архитектуры и устранять неполадки в моделях.

«Компьютерное зрение — CV» — 2 месяца
Освоите методы сегментации и детекции объектов, обучение и адаптацию генеративных моделей, работу с мультимодальными данными и новыми архитектурами CV.

Теги:
Рейтинг0
Комментарии0

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

Как мы создаём и обновляем курсы

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

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

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

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

Как устроены курсы и бесплатные части

В наших курсах есть бесплатные модули — вводные части, на которых можно узнать больше о профессии, освоить базовые термины и выполнить первые задания. В этом материале — о вводном модуле курса «Аналитик данных».

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

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

Я сделал штуку, которая за час-полтора, если хватит денего на серверы то = за минуты, читает ВСЁ, что человек писал во «ВКонтакте» за 12 лет, и выдаёт честное ревью: добряк-ботан, токсичный вояка или шизо-экстремал. Без суда, без сплетен — только цифры и цитаты. Или проверить себя и понять, что нужно удалить некоторые посты от греха подальше. Может у тебя было время когда тебе нравился товарищ Ленин, а сегодня его запретили.

Как работает

  1. Вбиваешь ссылку на страницу (или свой ID).

  2. Сервис скачивает 100 % постов и комментов (официальное VK API, никакого взлома).

  3. Bert + detoxify считают токсичность, темы и сентимент.

  4. Через время получаешь PDF:
    – сколько негатива/позитива;
    – топ-темы (рыбалка, политика, IT, наркота, оружие);
    – риск-флаги (экстремизм, суицид, оружие, наркота) с прямыми цитатами;
    – динамику: «в 2022 стал злее на 37 %».

Пример из жизни
Проверил себя — 8 % токсичности, 0 флагов. Проверил соседа — 38 % токсичности, 1 постов про ствол.

Законно ли?
Собираю только публичное, без переписок. Профиль закрыт — пишет - доступа нет.

Зачем это вообще

  1. HR-отделы — чекнуть кандидата до интервью.

  2. Самопроверка перед поступлением/наймом.

  3. Родители — глянуть, чем реально живёт подросток.

  4. Банки/страховщики — оценить риск-поведение (агрессия/суицид = выше вероятность ДТП).

Что дальше
Если пост наберёт ≥ 300 «вверх» и 50+ комментов «хочу» — допиливаю приложение в продакшн версию для запуска. Если больше - докручу Instagram и TikTok. Своим варианты скидывайте в комменты.

Понадобиться ли вам такой «цифровой зеркал» или это очередной «пылесос для данных»? В комментариях — пишите, кого первым проверить: своё начальство, бывшего или самого себя :)

Теги:
Всего голосов 7: ↑0 и ↓7-7
Комментарии11

Мы конкурируем со сном пользователя.

Этой фразе не менее 10 лет. И я помню, как восхищался этой мыслью - то ли Кука (того, что до сих пор не съели), то ли Харриса (не того, что ставил опыты над Трумэном). Для продакта мысль крайне богатая. Она будто раскрывает весь потенциал нашей работы: после захвата внимания днём тебе не остаётся ничего, кроме как занять пользователя ночью.

Здесь обычно следует возражение:

 «Но люди же сами несут ответственность! У них есть сила воли!».

Конечно, есть. Но мы проектируем интерфейсы, которые эту силу воли подавляют. Бесконечные ленты, autoplay видео, уведомления, вызывающие FOMO (Fear Of Missing Out) - это не нейтральные инструменты. Это дистилляция поведенческой психологии, превращенная в рычаг для удержания внимания. Мы не просто предлагаем сервис, мы проектируем зависимость.

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

В лучшем случае - «Мама Воложа», но и это тоже про примитивизацию и упрощение продуктов.

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

Мы говорим “пользователь”, потому что так легче выключить эмпатию. “Пользователь” -это даже не существо, это сущность с CTR и LTV. “Человек” - это тот, у кого есть усталость, тревога и право на покой.

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

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

И это, конечно, пугающая петля.

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

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

Но почему-то никто не говорит, что продакты придумывают заманухи, воруя наше (свое же) время - единственный по-настоящему невозобновляемый ресурс. И это мошенничеством не считается. И никак не регулируется. Скорее даже поощряется.

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

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

Вот на такие мысли меня натолкнула подготовка вебинара «тайм-менеджмент в реальной жизни» для РБК.

...
https://t.me/howtcp
#комплимент_от_шефа

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

Искусственный интеллект уже сегодня экономит бизнес-аналитикам десятки часов в месяц: генерирует бэклог, user stories, acceptance criteria и даже технические описания — быстро, чётко и без «воды». Но только если вы умеете с ним правильно работать.

27 ноября в 18:00 (Мск) приглашаем на бесплатный вебинар «Генерация документации с помощью ИИ».

Что узнаете на вебинаре:

✔️ Какие ИИ-инструменты реально работают для документации (и какие — пустая трата времени).

✔️ Как подготовить краткий, но достаточный бриф для генерации качественного текста.

✔️ Как избегать главных антипаттернов: «размытых» требований, противоречий и шаблонных формулировок.

✔️ Практические приёмы для получения готовых к использованию артефактов — прямо на вебинаре мы сгенерируем примеры вместе.

🕓 Когда: 27 ноября, 18:00–19:00 (Мск)

👨‍🎓 Спикер: Никулов Владимир — эксперт в области бизнес-анализа.

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

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

Аналитика процессов нового поколения

В Альфе множество сквозных процессов и точек взаимодействия между системами и людьми. BI-инструменты хорошо справляются с агрегацией данных и построением отчетности, но они редко отвечают на вопрос: как на самом деле протекает процесс, где он замедляется и почему возникают отклонения. Чтобы получить объективную картину мы применяем Process mining — технологию, которая позволяет построить модель реального исполнения бизнес-процесса на основе логов событий. 

В статье «Как мы встроили ИИ в Process Mining: децентрализация, одна кнопка инсайтов и путь к агентам» рассказываем, как сделать одним кликом то, на что раньше уходили недели: находить узкие места, строить гипотезы и ускорять анализ бизнес-процессов.

Как мы встроили ИИ в Process Mining: децентрализация, одна кнопка инсайтов и путь к агентам
Привет! Я — Андрей Шалягин, руководитель Офиса цифровизации в Альфа-Банке. Наша команда помогает раз...
habr.com

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

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

👉 Вот и осень пролетела — а у нас еще есть незакрытые вакансии 💻

Приглашаем опытных специалистов присоединиться к команде SSP SOFT 🌐

✨ У нас в SSP SOFT не бывает рутинных задач — только проекты, которые сначала удивляют своей сложностью, а затем становятся точками роста.
✨ С первого дня вы не одни: за вами закрепляется наставник, который помогает входить в работу спокойно и без лишнего напряжения.
✨ Карьерный скачок здесь реален: наш Проектный офис — это не просто управление, а среда, которая ускоряет профессиональное развитие.
✨ Вы сами выбираете формат: работайте удаленно, приходите в офис в Москве (ЦАО) или в Томске — или комбинируйте, как удобно.
✨ Мы не пропагандируем культ переработок — рабочие процессы гибкие, а личное время и забота о здоровье уважаются.

А еще у нас:
🎁 ДМС (включая стоматологию) для штатных сотрудников
🎁 обучение за счет компании
🎁 бонусы
🎁 общие ивенты — от онлайн-квизов до выездных сборов

📢 Прямо сейчас мы ищем (Подробности о вакансиях читай на ХХ.ру):

  • Разработчик Directum

  • Системный аналитик

  • 1С Разработчик (1С: ЗУП)

  • 1С Консультант (ЗУП КОРП)

  • С# Разработчик

  • Senior Java-разработчик

👉 Чувствуешь, что это про тебя? Тогда не теряй время — присылай резюме напрямую в ЛС нашему HR Lead Алине. Не забудь добавить сопроводительное письмо с ключевой фразой «Нашел(ла) вас на Хабре».

Спасибо за интерес к нашим вакансиям и желаем успеха на собесе )

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

Как за 30 минут понять, подходит системный аналитик или нет

Часто подбор специалиста затягивается. Сначала скрининг от рекрутера, потом техблок на час, потом софт-интервью, потом интервью со всеми заинтересованными. В итоге еще до найма кандидат проводит с нами, а мы с ним как минимум 3–4 часа, и это очень далеко не предел. Иными словами, чтобы встретиться с десяткой соискателей и выбрать одного единственного, нужно потратить кучу времени и денег.

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

  1. Опрос по скиллам.

  2. Решение прикладной задачи.

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

Выглядит таймлайн примерно так:

  • 3 минуты — знакомство: тут представляемся и рассказываем о структуре интервью;

  • 10 минут — опрос по скиллам: проходим по чек-листу (можете скопировать его себе) и заполняем соответствующие формы;

  • 10 минут — сбор требований: предлагаем кандидату кейс на автоматизацию процесса, тему намеренно формулируем широко, а дальше обращаем внимание, какие вопросы задает соискатель;

  • 7 минут — вопросы от кандидата и обратная связь.

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

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

Ссылки и всплывающие подсказки в PlantUML

Всем привет!
Продолжаем тему PlantUML. Сегодня за 5 минут и без воды поговорим о Сылках и всплывающих подсказках в PLantUML

1️⃣ Для добавления ссылки и текста ссылки, используйте конструкцию: [[<URL-ссылки> <Текст ссылки>]]
Пример: [[http://plantuml.com Ссылка (без всплывающей подсказки) на plantUML]]

2️⃣Для добавления: всплывающей подсказки к тексту (с ссылкой), используйте конструкцию: [[<URL-ссылки>{<всплывающая подсказка>} <Текст ссылки>]]
Пример: [[http://plantuml.com Ссылка (без всплывающей подсказки) на plantUML]]

3️⃣Для добавления: всплывающей подсказки к тексту (без ссылки), используйте конструкцию: [[{<всплывающая подсказка>} <текст к которому относится всплывающая подсказка>]]
Пример: [[{всплывающая подсказка} Всплывающая подсказка (без ссылки)]]

🔥 Внимание!!! Чтобы всплывающие подсказки работали у заказчика, выгружайте диаграммы в формат SVG

Пример кода ниже (а ссылка тут), а файл с примером в формате SVG тут:

@startuml
Title **Ссылки и всплывающие подсказки в PlantUML**

' Для добавления: ссылки и текста ссылки, используйте конструкцию: `[[<URL-ссылки> <Текст ссылки>]]`
    Alice -> Bob: [[http://plantuml.com Ссылка (без всплывающей подсказки) на plantUML]]

'Для добавления: всплывающей подсказки к тексту (с ссылкой), используйте конструкцию: `[[<URL-ссылки>{<всплывающая подсказка>} <Текст ссылки>]]`
  Alice -> Bob: [[http://plantuml.com{всплывающая подсказка (с ссылкой)} Ссылка (со всплывающей подсказкой) на plantUML]]

' Для добавления: всплывающей подсказки к тексту (без ссылки), используйте конструкцию: `[[{<всплывающая подсказка>} <текст к которому относится всплывающая подсказка>]]``
  Alice -> Bob:  [[{всплывающая подсказка} Всплывающая подсказка (без ссылки)]]

@enduml

Чтобы работали всплывающие подсказки на русском в плагине предпросмотра (в VS Code) добавьте в настройки (settings.json)

{
    "plantuml.diagramsRoot": "docs/diagrams",
    "plantuml.exportOutDir": "docs/diagrams/out",
    "plantuml.exportFormat": "png",
    "plantuml.exportSubFolder": false,
    "plantuml.render": "PlantUMLServer",
    "plantuml.server": "http://www.plantuml.com/plantuml",
    "plantuml.commandArgs": [
        "-charset",
        "UTF-8"
    ]
}
Теги:
Всего голосов 4: ↑2 и ↓20
Комментарии1
1
23 ...