На каждом созвоне слышно одни и те же правильные слова:
Надо думать наперед,
Архитектура должна быть мощной,
Давайте писать с запасом на рост.
А к вечеру — очередной релиз на костылях, баги в проде и геройская починка в ночи. И самое забавное, что команда не состоит из новичков. Все прекрасно знают, как делать правильно.
Привет, Хабр! Меня зовут Владимир Добрынин, я ведущий разработчик в МТС Web Services. Наша команда занимается плагинами DevTools, которые упрощают и ускоряют создание софта, в том числе за счет сокращения рутинных операций.
У нас уже есть целое семейство внутренних инструментов. Один из них — DevTools Copilot, который непосредственно из среды разработки позволяет взаимодействовать с LLM в режиме чата. А теперь мы реализовали DevTools Code Review, который помогает проводить самостоятельное код-ревью. В этой статье расскажу, как работает плагин и чего мы с его помощью добились.
Привет, Хабр!
Сегодня разберём на практике один из самых недооценённых, но при этом максимально полезных инструментов в арсенале любого тимлида — Delegation Poker из подхода Management 3.0. Это не игра ради фасилитации, а вполне рабочая методика, чтобы прозрачно и конструктивно обсудить распределение ответственности в команде. Без «угадай, чего я от тебя жду», без абстрактного «будь проактивным» и без пассивной агрессии на ретро.
Привет, я Денис Сумелев, генеральный директор компании ООО «ИНТЕКЕЙ», ИТ интегратора и разработчика системы управления складом - INTEKEY WMS. Последние 15 лет занимаюсь консалтингом и автоматизацией складов — от небольших распределительных центров до крупных логистических комплексов.
Хочу поговорить с вами об автоматизации склада с архитектурной точки зрения. Почему одни решения работают годами без сбоев, а другие превращаются в бесконечную доработку? Почему ERP часто не справляется с задачами WMS, даже если её «прокачали»? И как выбрать систему, которая не устареет через пару лет? Постараюсь развеять Мифы о WMS функционале в ERP системах.
Я буду говорить со своей колокольни интегратора. Про причины разрабатывать WMS на основе ERP я расскажу в следующей статье, мы это тоже умеем и иногда делаем. Уверен, у вас есть свои аргументы и опыт — мне тоже интересно их услышать.
Постараюсь писать без отсылок к нашей системе, я мог бы долго хвалить её, ведь свои дети всегда кажутся самыми умными и красивыми. Но сделаю это только в начале и в конце. За годы мы не только разработали одно из лучших решений в соотношении цена/качество/сроки внедрения, с полноценной интеграцией с 1С, гибким API для любых учётных систем и современными технологиями и архитектурой, но и внедрили её на огромном количестве складов различных размеров — от Uniliver до небольших региональных складов. Но сегодня не про нас, а про принципиальные различия систем.
За хайпом вокруг AI‑агентов скрывается фундаментальный сдвиг — переход от «экономики инструментов» к «экономике результатов». Эта статья представляет фреймворк «Трех горизонтов» для оценки бизнес‑амбиций и помогает технологическим лидерам сделать стратегический выбор: стать «Мастером», оптимизирующим процессы, или «Архитектором», строящим новые бизнес‑модели.
Всем привет! Меня зовут Александр Стерлигов, я руковожу проектным офисом в MWS Cloud Platform. Мы начали строить новое облако в 2023 году, и всего за год наша команда выросла со 150 до 520 человек.
Быстрый рост всегда приносит новые возможности, но вместе с ними приходят и серьёзные вызовы. Нужно не только расширять штат, но и превращать группы незнакомых людей в слаженные команды, сохранять управляемость и прозрачность процессов, избегая хаоса. Всё это при том, что перед нами стояла амбициозная цель — вывести в продакшен собственную облачную платформу. В Q2 2025 мы успешно запустили её фундаментальную часть — IaaS.
В этой статье я хочу поделиться нашим опытом: какие ошибки чаще всего совершают быстрорастущие команды, как выстраивать процессы, которые масштабируются вместе с организацией, и какие практики помогли нам сохранить эффективность даже при пятикратном росте.
Привет, Хабр!
Поскольку первая встреча прошла очень полезно и интересно, мы решили повторить и снова в эфире телеграм-канала Dev Q&A продолжили дискуссию о микросервисах и скорости разработки. Собрались технические эксперты из BPMSoft, DevTale, Revizto и Диасофт (в лице меня). Обменялись практическими примерами на тему как же упростить жизнь разработчикам и получать результат быстрее, дешевле и качественнее.
Ваш бизнес — это Лебедь, Рак и Щука. И как вы устали быть кучером.
Мы привыкли думать, что проблемы бизнеса - в людях или в рынке. Но что, если корень зла лежит в другом - в хаосе, который мы сами же и создаем, пытаясь управлять компанией?
Это не просто метафора, это диагноз для 9 из 10 компаний:
🗣️ Коммуникационный коллапс: Ваши отделы - это Лебедь, Рак и Щука, которые тянут бизнес в разные стороны. Продажи, производство и финансы говорят на разных языках, а вы разрываетесь между ними, туша пожары.
⚙️ Иллюзия контроля: Вы тонете в регламентах, таблицах Excel и красивых, но оторванных от реальности дашбордах. Вы думаете, что управляете, но на самом деле лишь наблюдаете за хаосом, который, как зыбучие пески, засасывает лучших сотрудников и вашу мотивацию.
💸 Масштабирование хаоса: Бизнес растет, но радости нет - есть только паника. Вы пытаетесь управлять ростом, нанимая новых людей в сломанную систему, и в итоге «воз» вашего бизнеса просто разваливается на взлете.
В своей новой статье я показываю, почему большинство управленческих методик — это попытка починить двигатель, когда проблема в шасси. И предлагаю альтернативу - не «еще одну систему», а способ мышления, который позволяет видеть, понимать и улучшать вашу компанию как единое целое.
Готовы перестать быть героем басни Крылова и стать, наконец, главным конструктором своей ракеты?
Привет, Хабр! Меня зовут Мария Бурханова, я технический писатель, старший руководитель ИТ-направления документирования Platform V в СберТехе. На TechWriter Days я рассказывала, как техническому писателю научиться читать и понимать сложные нотации, чтобы сделать документацию простой и понятной.
Сегодня хочу рассказать, зачем техпису нужны нотации и почему их так много, какие знания о нотациях точно пригодятся и как применить эти знания на практике.
Статья будет полезна техническим писателям, аналитикам, разработчикам и всем интересующимся этой темой. Вы научитесь читать диаграммы и схемы в разных нотациях и эффективно использовать их для создания понятной и структурированной документации.
Привет Хабр! Меня зовут Владимир Понаревский, я руковожу разработкой бэкенда антиспама в Mail. За моими плечами более десяти лет опыта управления самыми разными людьми и процессами, от которых зависит информационная безопасность миллионов пользователей почты. Сегодня мы поговорим о том, с чем рано или поздно сталкивается каждый руководитель: когда в команде или организации что-то начинает работать не так, как задумывалось.
Привет, Хабр! Я Федор, ProductOwner в Росгосстрахе. В молодости будучи школьником, еще задолго до появления всяких «Вкусно — и точка», я какое-то время работал в Макдоналдсе. И тогда, конечно, даже не задумывался, что этот опыт окажется полезен в моей дальнейшей карьере в айти. Казалось бы, что общего у фаст-фуда и разработки продукта?
Представьте, что вы работаете по скраму, но без скрам-мастера. Его задачи распределены между участниками команды. Представили? Отлично! Усложним задачу: представьте, что тимлида тоже нет. «Хаос» — скажете вы? Вовсе нет! Мы так работаем уже несколько лет.
Привет, я — Иван Зверев, фулстэк в Додо. Сегодня я расскажу о том, как круто может самоорганизоваться здоровая команда, если довериться ей, обозначить прозрачные правила работы и дать свободу экспериментировать с процессами. Вперёд!
«В последнее время все меньше иностранных компаний остаются доступны в России. В связи со сложными внешнеполитическими процессами, внутренний рынок требует все больше отечественных независимых „импортозамещающих“ разработок во всех сферах производства, включая и горную промышленность.»
Примерно с такой формулировкой к нам обратилось одно крупное предприятие из области добывающей промышленности.
---------------------------------------------------
На большинстве крупных предприятий так или иначе всегда присутствует конвейер. Вещь очень полезная, тем более если необходима постоянная транспортировка материала из цеха в цех, на переработку или куда‑нибудь еще. В нашем случае, точнее в случае заказчика, конвейер установлен в цехе среднего дробления и задача его — загружать руду в мельницу, для получения более мелкой фракции на выходе.
Привет! Меня зовут Анна, я маркетолог команды цифровой трансформации Ареал.
Более чем за 20 лет работы у нас сложилась система шагов и правил для дизайн-процессов. Единые стандарты позволяют команде говорить на одном языке, вести прозрачный диалог с клиентами, быстро ориентироваться в стартовавшем или новом проекте.
В статье я расскажу, как выглядит жизненный цикл интерфейса, и каких правил мы придерживаемся, чтобы соблюдать единообразие и не нарушать методологию.
Мы работаем в Figma, но систему можно организовать в любом редакторе.
Спам-звонки, фишинговые ссылки, рекламный трафик и утечки данных — все это не просто источники раздражения, а реальная угроза для мобильных абонентов. Большинство решений защищает на уровне смартфона, нагружая устройство. В МТС пошли другим путем: объединили телеком и IT-функции в тарифе, где можно настроить безопасность на уровне сети оператора. Пользователи могут управлять защитой через мобильное приложение и блокировать вредоносный трафик до его попадания на телефон.
Так появилась Membrana — сервис, фильтрующий голосовые и сетевые данные по настройкам пользователя. В этом материале расскажем, как в общем работает эта система, а в следующих более детально посмотрим, как она работает «под капотом».
Производственная система «Росатом» (ПСР) – это культура бережливого производства и система непрерывного совершенствования процессов для обеспечения конкурентного преимущества на мировом уровне.
Она была разработана на базе лучших образцов отечественного и зарубежного опыта, в частности, системы научной организации труда, производства и управления (НОТПиУ) Министерства среднего машиностроения СССР и Toyota Production System японской автомобильной компании «Тойота».
Шалом алейкум, Хабр! В интересное время живём. Наши «любимые» ведомства делают всё, чтобы общение стало максимально «доступным» — но исключительно в тех местах, где удобнее контролировать. Пока уголовной статьи за дискредитацию этих усилий нет, напишу этот пост.
А если без шуток — блокировка звонков в Telegram и WhatsApp резко сделала актуальным вопрос: где теперь созваниваться? Мы привыкли решать рабочие дела в телеге или вотсапе, а теперь приходится крутиться. Меня лично накрыло вчера: Google Meet внезапно отвалился, и урок английского сорвался.
Поэтому собрал небольшой топ сервисов, где звонить можно без VPN и танцев с бубном. Ниже — список, проверенный на себе и коллегах. В конце бонус — варианты связи для родителей и бабушек.
TL;DR
Автоматическое ревью кода с помощью ИИ уже работает в продакшене крупнейших компаний. Microsoft обрабатывает 600 000 пулл-реквестов в месяц, экономя сотни тысяч часов. ByteDance достигла 75% точности с 12 000 активных пользователей еженедельно. Google автоматизировал 7,5% всех комментариев ревьюеров. В статье — детальный разбор архитектур, метрики эффективности и пошаговое руководство по внедрению с расчётом окупаемости.
Многие конторы ставят трекеры, чтобы наблюдать за работой сотрудников — кто‑то скриншотит экраны каждые 3 секунды, кто‑то следит за простоем курсора мыши. Многие верят, что именно так можно повысить эффективность. Откуда они вообще это взяли? И так ли это? Рассматриваю вопрос мониторинга с точки зрения науки о поведении людей на работе — организационной психологии. Делаю обзор исследований, шучу сомнительные шутки, обсуждаю альтернативы — и это все под катом.
Кажется, выстраиваешь стартап на доверии, а потом внезапно обнаруживаешь, что главный технический специалист… не оставил тебе даже пароля от GitHub. Ни в шутку, ни в полсилы. Всё, с чем работала команда: домены, серверы, CI/CD, база клиентов, мониторинг - оказалось привязано к личным аккаунтам подрядчика. Контроль потерян. А вернуть всё не факт, что возможно.
И самое болезненное: с юридической точки зрения уязвимы не только основатели, но и инвесторы, заказчики, партнёры. Ни один NDA тут не спасёт, если изначально не были расставлены границы доступа, конкретный перечень информации и ответственности. В этом тексте не морализаторство, а подробный разбор, как такие истории случаются, чем они грозят и что можно сделать заранее, чтобы однажды не зависеть от настроения одного человека.
