Управление разработкой *

Если вы руководите компанией от 50 до 1000+ сотрудников и чувствуете, что теряете контроль — эта статья для вас. Ваш бизнес уже слишком большой для «управления в лоб», но ещё не структурирован, как корпорация. Результат? Сотрудники работают «как считают нужным», новички тратят месяцы на обучение вместо того, чтобы приносить прибыль, а при увольнении опытного специалиста его знания исчезают навсегда.​

Статья раскрывает конкретное решение с проверенным ROI: замкнутый цикл описания бизнес-процессов на визуальном языке ДРАКОН. В отличие от сложных корпоративных систем (BPMN, Camunda), требующих специалистов, миллионных бюджетов и долгих внедрений, ДРАКОН основан на когнитивной эргономике — схемы понятны с первого взгляда, создаются за 1-2 часа и не требуют специального обучения персонала.​

Вы получите пошаговый план запуска за 5 рабочих дней с первыми результатами через 2 недели. Бюджет - всего 755 тысяч рублей в первый год против 2,1 миллиона на BPMN-стек, с экономией более 1,3 миллиона ежегодно.​

В статье - реальные кейсы: сетевая компания СТО «Фильтр» (450+ сотрудников) получила ROI +137%, сократила ошибки на 83% и время обучения новичков с 5 дней до 1 дня. Аквапарк «Лазурный» (200+ сотрудников) создал полную «Книгу алгоритмов» на 158 страниц и снизил критические ошибки на 70+%.​

Вы узнаете, почему традиционные BPMN-модели устаревают через месяц и содержат ошибки в 42-86% случаев, как работает «замкнутый цикл», превращающий схемы в живой инструмент управления, и когда ДРАКОН не подходит (авиация, банки с жёсткими стандартами).​

Статья из серии написана консультантом с 30-летним опытом и 10 годами практики с языком ДРАКОН - честно, с раскрытием конфликта интересов и границ применимости метода.​

Прочтите, если хотите превратить хаос в порядок, а порядок - в рост, не потратив миллионы на консультантов.

Привет, меня зовут Артем, и я работаю в Авито с 2016 года. Это вторая часть истории про шардирование сервиса объявлений Авито Доставки, где мы расскажем о реализации шардирования и полученном результате. В первой части мы обрисовали проблему масштабирования сервиса, рассказали о том какие у нас были варианты решения, почему выбрали шардирование, поговорили про нюансы шардирования и составили план реализации.

Привет, Хабр! Меня зовут Александр Коротков, я — тимлид продуктовой команды в Т-Банк и член программного комитета конференции DevOps Conf. Разрабатывал системы автоматизации тестирования, пять лет посвятил работе над IDP, лидировал разработку бизнесовой платформы. Эта статья родилась из моего доклада для DevOps Conf. Но, если честно, тема давно сидела в голове. Я много раз наблюдал в индустрии один и тот же сценарий: платформы начинают строить с амбициями, но потом что-то ломается — развитие замирает, платформа превращается в тяжёлую обузу или её и вовсе переписывают с нуля. Почему так происходит? Где те самые «невидимые грабли», на которые снова и снова наступают разные команды?

Будет полезно не только тем, кто строит платформы напрямую — CTO, Head of Platform, DevOps-инженерам и разработчикам платформенных решений, но и всем, кто сталкивается с инфраструктурой и хочет заранее видеть потенциальные проблемы.

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

Мем про «10×-разработчика» живёт не просто так — такие люди встречаются. Но это не то, чем можно управлять. Софт делает команда, а скорость задаёт система вокруг неё. В статье — как навести порядок в этой системе, чтобы «обычные» инженеры стабильно давали сильный результат: короткий путь «коммит → прод», быстрый откат вместо героизма, наблюдаемость по умолчанию, удобный платформенный self-service и найм не «самых крутых», а подходящих под задачи и ценности. Продуктивность измеряется не строками кода и не тайтлами, а влиянием на бизнес; остальное — лишь прокси-метрики.

Современные нейросети снижают порог входа в разработку. Теперь не обязательно быть программистом, чтобы автоматизировать рутину. В этой статье я расскажу, как, будучи руководителем проекта, создал корпоративного бота на n8n и Пачке с помощью ChatGPT и OpenRouter. От хаоса с устройствами до автоматизированной системы бронирования, JSON-запросов и PostgreSQL.

Мы создали мессенджер, в котором работать удобнее, чем в Telegram. 

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

Привет, меня зовут Артем, и я работаю в Авито с 2016 года. Начинал как тестировщик, затем вырос в backend-инженера, с 2019 года пишу на golang, а сейчас руковожу командой разработки в Авито Доставке в роли техлида. В этой статье поделюсь опытом шардирования нашего основного сервиса delivery-item: зачем мы это сделали, как подошли к задаче, с какими граблями столкнулись и как всё выглядит спустя почти два года.

Привет, Хабр. Меня зовут Полина Захарова-Щукина, я Product owner в Carrot quest, отвечаю за развитие продукта, позиционирование и монетизацию.

Я проанализировала, как устроена монетизация в топовых продуктах: Notion, Figma, Slack, Miro, Loom, Intercom, Mixpanel, Canva, Manychat, Airtable, Zoom и Grammarly: начиная с того, как они презентуют цены на лендингах, до того как они выстраивают воронку апсейла и где именно заложены триггеры роста выручки. Отдельно вынесла паттерны монетизации AI-функций.

Вот 9 паттернов, которые стоит перенять продактам и PMM-ам, чтобы выстроить тарифы в своих продуктах наиболее эффективным образом.

Cloud Gaming и VDI — разные технологии, применяемые для разных задач и даже для разной целевой аудитории. Вместе с тем, если заглянуть к ним под капот, можно увидеть, что у технологий есть много общего — например, одинаковые принципы стриминга видеопотока, методы сжатия передаваемых по сети данных и борьбы с потерями сетевых пакетов. Таким образом, при разработке Cloud Gaming можно отчасти опираться на технологии, примененные в VDI, и наоборот. Именно так мы и поступили при создании сервиса VDI (Cloud Desktop) для облака VK Cloud.

Привет, Хабр. Меня зовут Кирилл Черников. Я руководитель Команды клиентской разработки в VK Tech. В этой статье я расскажу об особенностях Cloud Gaming и VDI, о разнице в требованиях к сервисам, сложностях адаптации игрового решения к задачам VDI и о полученных результатах на примере сервиса VK Play Cloud и платформы VK Cloud.

Очень часто основная сложность заключается в том, что команды берут в работу задачи, которые находятся в отрыве от ключевой цели, определённой бизнесом. Четкое понимание ответа на вопрос «Зачем мы это делаем?» даст не только большей координации в работе, но и большего экономического эффекта от выполнения тех или иных инициатив. Практика показала, что внедрение методологии OKR и её активное продвижение внутри компании помогает привнести ясность в работу сотрудников.

Разработать электронную начинку радиоэлектронного прибора — половина дела. Вторая половина — корпус.

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

Приветствую Хабр, это моя первая статья и я решил поделиться своим личным опытом развития в IT, подхода к управлению и любви к волшебству кода.

Немного обо мне. Меня зовут Юрий, через месяц будет 16 лет с моей первой записи в трудовой книжке о работе в IT. Закончил мехмат, немного занимался наукой, работал в крупном американском аутсорсе, затем в красно-синем российском банке и последние 8 лет тружусь в технологических и AI стартапах. Да, столько опыта, а хоть что то написать решил только сейчас. В общем погнали.

Я лично не разделяю руководство в директивном смысле и лидерство на какие то разные сущности и считаю, что это лишь разные грани одного и тоже умения сподвигать людей выполнять коллективно задачи, превосходящие возможности одного человека. Это можно сравнить с кластерными технологиями как в режиме single‑master так и в режиме multi‑master.

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

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

Все разработчики знают, что такое техдолг.

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

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

История Solar appScreener началась в одной из российских IT-компаний, в которой тогда работала команда основателей «Солара». Они занимались консалтинговым бизнесом и наблюдали кардинальные изменения на рынке, которые стали почвой для будущей разработки продукта в сегменте application security.

К 2014-2015 гг. проблема безопасной разработки приложений стала острой и заметной не только для отраслевого сообщества, но и регулярно привлекала внимание общественности. Более чем в 75% успешных кибератак уже тогда эксплуатировались «дыры» в ПО, которое в то время было самых слабым звеном с т.з. технической защиты. Например, 15% от всего количества опубликованных уязвимостей приходилось на уязвимости для платформы Android. Громким событием первой половины 2010-х также был хакерский взлом AppStore, в ходе которого в ряд приложений был внедрен вредоносный код XCodeGhost.

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

Так возникла идея российского AppSec-продукта: для отечественных компаний, на родном языке, с понятными рекомендациями, четким анализом и наукоемкими технологиями под капотом.

Любой тимлид когда-то был джуном, а многие крепкие команды начинали как стартап на энтузиазме. Пока вас трое-пятеро — всё просто: драйв, мемы, кофе на кухне и общее чувство плеча. Но команда растёт — и вот вместо «давайте быстро созвонимся» появляются OKR, аллхэндсы и три уровня согласований.

Главная задача руководителя при этом не меняется: как замотивировать людей, чтобы им было интересно работать. И, увы, универсальной кнопки не существует — то, что отлично работает в стартапе из десяти человек, не взлетает в корпорации на тысячи. Впрочем, если бы все было так просто...

Меня зовут Антон Дмитриев и я хэд разработки Почтовых систем МойОфис — гибкой системы с почтой, календарем, контактами, задачами и документами. Основное ядро продукта написано на Go, но технологический стек включает Python, C++, JavaScript/TypeScript и React.

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

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

Автоматизация CI/CD для embedded-систем решает эти проблемы, хотя требует начальных усилий на настройку инфраструктуры.

Почему одни команды релизят предсказуемо и без героизма, а другие тушат пожары на продакшене каждую неделю?

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

Исследование 100+ респондентов.

Всем привет! Меня зовут Саша Симоненко, и я операционный директор кибербез компании Xilant. Эта статья родилась из моего сентябрьского выступления на конференции KazHackStan 2025 в Алматы, где рассказывал, как качественные бизнес-требования помогают избежать проблем с безопасностью.

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

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