Всем привет! Меня зовут Артём Матюшечкин, я менеджер разработки из команды Толк.ИИ в продукте Контур.Толк — это сервис видеоконференцсвязи для общения и работы. Наша команда сделала суммаризацию, обновила и ускорила сегментацию виртуальных фонов, внедрила шумоподавление в продукт. В этой статье поделюсь опытом управления такой командой, которая пыталась одновременно уместить в себе требования бизнеса и технологий.
Привет, Хабр! Меня зовут Алексей Грохотов, я разрабатываю продукт Сфера.Архитектура в ИТ‑холдинге Т1. Перед нашей командой стояла задача перенести документы из Orbus iServer в Сфера.Архитектуру. Iserver — это набор инструментов для описания, поддержки и трансформации архитектуры предприятия. Он в значительной степени интегрирован с Microsoft Office, например, все схемы в этом инструментарии создаются в Visio.
Я должен был проанализировать схемы Visio и извлечь необходимую информацию из этих документов. Объекты, соответствующие «прямоугольничкам и стрелочкам» Visio, уже хранились у нас в базе. Мне нужно было соотнести их с фигурами и стрелками схемы, записать для этих объектов геометрическое и текстовое содержание фигур, а также некоторые их специфические свойства. Ещё нужно было определить порты — «стыковочные места» по периметрам фигур, к которым присоединяются стрелки, а также найти надписи у стрелок и фигур. И после этого сохранить в базу данных всю найденную информацию.
Продолжение статьи о разработке B2B платформы международной торговли
Прошло несколько месяцев с момента публикации первой части, где мы рассказали о концепции и начальном этапе разработки LiqTrade. За это время проект прошел путь от MVP до полноценной production‑ready платформы.
В этой статье я хочу поделиться реальными проблемами, с которыми мы столкнулись, и способами их решения. Никакого идеализированного «как всё прекрасно работает» — только честный разбор косяков, рефакторинга и технического долга.
Дисклеймер: Если вы ищете статью в стиле «10 строк кода, и ваш стартап взлетел» — это не здесь. Здесь будет про то, как мы 3 раза переписывали систему ролей, боролись с circular dependencies и почему наш bundle вырос до 1.2 МБ (спойлер: мы его победили).
Представьте, что вы лидер молодого, но быстрорастущего стартапа в области ML. Вам предстоит собрать команду, и вы думаете о том, каких специалистов вам предстоит найти:
- Data Scientist — для создания прототипов моделей машинного обучения, подходящих по задачи вашего проекта;
- ML Engineer — для внедрения в эксплуатацию моделей и сценариев, масштабирования;
- Data Engineer — для создания ETL‑процессов, систематизации сбора и хранения данных;
- DevOps/MLOps — для автоматизации процессов и развития инфраструктуры;
- SRE — для обеспечения мониторинга и надёжности вашей инфраструктуры.
Организовать работу всех направлений с нуля будет задачей не из лёгких. Но как принять этот вызов, если вы не обладаете экспертизой во всех направлениях?
За последние ~5 лет я много раз сталкивался с задачей собирать логи: обычно из маленьких или средних по размеру кодовой базы проектов. Отправлять логи из кода не проблема, у Java и Go для этого есть библиотеки практически из коробки. А вот разворачивать что-то для их сбора — головняк. Понятно, что решаемый (ещё до ChatGPT, а сейчас так тем более), но всё же. Все системы логов, прежде всего, ориентированы на большой-большой enterprise мир и его требования, а не на простых смертных с несколькими палками, клеем и дедлайном "вчера".
Запуск ELK для меня каждый раз испытание: куча настроек, нетривиальный деплой, а при заходе в UI разбегаются глаза от вкладок. С Loki и Graylog — немного проще, но всё равно функций сильно больше, чем мне нужно. При этом разделять логи между проектами, добавлять других пользователей в систему так, чтобы они не видели лишнего — тоже не самый очевидный процесс.
Поэтому примерно год назад я решил, что сделаю свою систему для сбора логов для себя: максимально простую в использовании и запуске. Чтобы разворачивалась на сервере одной командой, вообще без настроек и без лишних вкладок в интерфейсе. Собственно, так появился и теперь вышел в open source Log Bull: система для сбора логов для разработчиков с проектами middle-sized размера.
(спойлер: в конце будет ссылка на GitHub)
Таск-менеджеры вроде Jira — хороший инструмент для ведения проектов. Вот только есть одна проблема — на них очень быстро забивают. В первую очередь — проектные менеджеры (на всякий случай: я тоже забиваю). Когда проект стартует, менеджер с командой, как правило, делают волевую попытку декомпозировать его на эпики и задачи. Каждая задача получает красивое описание, а иногда даже назначенных исполнителей и дедлайны.
Потом проект стартует…
Внезапно меняются требования и бэклог, появляются дополнительные зависимости. Часть задач внезапно оказывается ненужной, ещё более внезапно меняются менеджеры и ключевые участники. Рано или поздно таски начинают зарастать мхом: апдейты не комментируются, статусы не двигаются.
В какой-то момент наиболее ответственный член команды решает устроить субботник и позакрывать то, что уже сделано. Отсюда — популярность следующих вопросов в поддержке Jira:
Привет, Хаброжители! Хотите узнать, как вывести продукт на новый уровень и сделать его более эффективным с точки зрения бизнеса? Тогда разработка, основанная на гипотезах (Hypothesis Driven Development, HDD) от Алекса Коуэна станет незаменимым подходом в управлении продуктом.
Этот новый метод, ориентированный на тщательное экспериментирование и тестирование гипотез, используется для сокращения потерь, достижения высоких результатов и формирования работоспособных команд.
Алекс Коуэн подчеркивает важность проверки гипотез на всех этапах жизненного цикла продукта и дает практические советы по применению подхода. Вы узнаете, как применять HDD на разных стадиях процесса разработки продукта — от идеи до проектирования, от проектирования до написания кода, от написания кода до развертывания и от релиза до проверки гипотез.
Книга будет полезна всем, кто стремится разрабатывать продукты, которые действительно нужны рынку, минимизировать риски и принимать стратегические решения на основе данных, а не предположений.
Большинство инженеров начинают путь с простой задачи — сделать так, чтобы ничего не падало. И в этом нет ничего плохого. Мы ставим мониторинг, настраиваем алерты и радуемся когда всё «зеленое».
Но что делать когда этого не достаточно и пользователи все равно жалуются?
Привет! Меня зовут Илья, я директор департамента разработки в ЮMoney. За каждым малозаметным обновлением может стоять месяц работы: проработка архитектуры, дизайна, код-ревью и множество проверок безопасности. В ЮMoney мы смогли совместить тщательный контроль с бешеной скоростью — и делаем до 100 релизов в день. Расскажу, как мелкие задачи спасают от больших рисков и что помогает нам «катиться» быстрее.
Иногда всё начинается с аплодисментов: в команду приходит «стратег» из консалтинга, топы в восторге, обещают «новый уровень». А заканчивается — бесконечными презентациями, бессмысленными фичами и выгоранием. Я прожил это несколько раз и хочу рассказать, почему операционная система консультанта несовместима с живым продуктом — и что можно сделать, чтобы выжить.
Привет всем! Меня зовут Гриша Капцов, я работаю в Отделе координации и поддержки продуктовых команд в МТС Web Services. В прошлом посте рассказывал, как мы с командой прокачали свой навык повелевания хаосом. А сегодня хочу обсудить ситуации, когда один «незаменимый» сотрудник становится угрозой.
Представьте, что в вашей системе поднимается критический инцидент. Прод ложится, алерты строчат, клиенты негодуют. Вы открываете чат, а единственный человек, который знает, как это чинить, в отпуске. Или уволился. Или не выходит на связь. И что делать без него — вообще ноль идей.
Ситуация может показаться гипотетической, но в сфере ИТ-эксплуатации это ежедневный риск, просто не всегда реализующийся. У вас может быть сильная команда и крутые инженеры, но при этом — один человек на зону знаний, отсутствие структурированной документации и полная слепота к ключевым уязвимостям.
Предотвратить такие сценарии можно, если отслеживать «фактор автобуса», или Bus Factor — показатель зависимости проекта от отдельных членов команды. Ниже я расскажу, почему эта метрика особенно критична для эксплуатационных команд и как ее измеряем мы. Давайте назовем кейс «This is эксплуатация!».
Мы с командой, как и многие, вели рабочие переписки в Telegram. Постоянно теряли задачи во флуде и мемах, забывали о договорённостях и тратили часы на поиски нужных сообщений.
Тогда мы решили взять лучшее от Telegram и сделали свой корпоративный мессенджер — который помогает фокусироваться на работе.
На связи Святослав Сычев, инженерный менеджер, ответственный за результаты и развитие нескольких команд, разрабатывающих высоконагруженные системы в Mindbox.
В этой статье расскажу, что помогло нам пройти путь от хаоса и перегрузки техдолгом к устойчивому процессу, где бизнес доверяет разработке как партнёру:
• как радикальные решения могут улучшить ситуацию с техдолгом;
• почему термин «техническая задача» только мешает;
• как продавать бизнесу задачи, которые кажутся «чисто техническими»;
• почему выделять определённую часть времени на техдолг — недостаточно;
• как ускорить отдачу техдолга за счёт усиления фокуса;
• как лиду перейти от ручного контроля к автономной работе команды.
Не думал, что мне еще раз придется возвращаться к теме собеседований, но похоже она меня преследует. Теперь уже на моем текущем месте работы HR внезапно выдали рекомендации:
1. Проведение собеседований обязательно с включенной камерой
2. Избегание типичных вопросов, чередование тем.
3. Секция лайв-кодинга при проведении технических собеседований;
4. Проведение мероприятий по выявлению читеров как апофеоз.
Ранее я рассказывал об относительно малоизвестной и ныне удалённой строке-заполнителе в Android, использовавшейся в качестве пасхалки. Это был выдуманный оператор сотовой связи под названием El Telco Loco. Сегодня я расскажу о методах и других частях публично доступного Android API, которые могут показаться больше смешными, чем полезными. Это пасхальные яйца, шутки, видимые только разработчикам приложений для Android, но не обычным пользователям.
Представьте, что библиотеки можно устанавливать / настраивать и удалять (на любом языке и в любом фреймворке) так же легко, как любое приложение или игру на телефоне или компьютере?
Эта статья о том, как мы можем это сделать.
Или другими словами, framework Agentic Executables (далее - "AE") рассматривают библиотеки как исполняемые программы со структурированными, понятными для AI агента инструкциями. Вместо того чтобы полагаться на документацию написанную для людей, AI-агенты следуют стандартизированным .md файлам для автономной установки, настройки, интеграции, обновления и удаления библиотек.
Я решил разделить статью на несколько частей:
Последние два года я руковожу компанией, специализирующейся на контрактной разработке механических и мехатронных компонентов. Мы работаем с оборудованием для медицины, ветеринарии и неразрушающего контроля, а также производим опытные образцы и малые партии.
Контрактная разработка и мелкосерийное производство требуют особого подхода: задачи здесь уникальны, а контроль за сроками и бюджетом требует особого внимания.
В этой статье я поделюсь опытом внедрения сквозной системы управления компанией, используя инструменты Kanban. Мы построили ее так, чтобы она была одновременно простой, гибкой и масштабируемой.
Или как объяснить менеджменту, почему лучше перестать пушить внедрение ИИ в разработку.
Ниже я разбираю основные проблемы и приземляю их на реальные исследования.
ИИ сейчас на пике внимания, и всё больше компаний видят в нём кнопку “ускорить прибыль”. Но если заглянуть в два свежих осенних отчёта по рынку ИИ, картина получилась тревожной: в каждом третьем ответе системы — дезинформация, а 95% корпоративных внедрений не приносят пользы.
В чём корень? Погоня за лайками, кликами и красивыми циферками KPI. Когда алгоритм “затачивают” только под отчётность, теряется главное — реальный результат.
Если хочется, чтобы искусственный интеллект работал на пользу, а не просто “гонял данные”, есть краткий маршрут:
1. Забудьте о vanity-метриках — оценивайте технологии через их прямое влияние на прибыль, удержание клиентов и сокращение расходов.
2. Простройте визуальную карту процессов — только так можно контролировать, где теряются ресурсы и как реально работает ИИ в ваших бизнес-процессах.
3. Внедряйте новинки поэтапно: запускайте на конкретных участках, анализируйте ошибки и только потом масштабируйте то, что действительно влияет на результат.
Toyota не построила свой лайфстайл “японского качества” без визуальных схем — у них видно каждое звено процесса. McDonald’s стал легендой, стандартизировав каждый шаг и избавившись от хаоса на кухне. А в Amazon автоматизация сработала только тогда, когда был прорисован буквально каждый маршрут товара на складе.
В конечном счёте у любого лидера есть два маршрута: либо быстро монетизировать “чёрный ящик” в ущерб доверию, либо выстроить честную, прозрачную машину, которая будет работать долгие годы. Большие перемены всегда идут через осознанные решения и интеллект — человеческий и машинный.
Как нас попытались «положить» при запуске: история одного DDoS
Всем привет Мы — команда разработки ии‑ассистента для поиска работы, это третья статья, посвященная нашему продукту.
Я уже писал о внутрянке продуктовой и технической части, поэтому сегодня решил поделиться кейсом нашего третьего запуска, когда нас атаковали хакеры..
