В современном IT-мире часто возникает путаница между различными ролями. Одним из примеров является роль Delivery Manager, которая имеет некоторые сходства с Project Manager. Хотя обе позиции связаны с управлением проектами, их обязанности и зоны ответственности существенно различаются. В этой статье мы рассмотрим на примерах, что должен делать каждый из этих специалистов в конкретных ситуациях.
Язык программирования, даже общего назначения, - это инструмент. Каждый язык хорош в решении задач своей сферы: C++ позволяет писать эффективные программы, Haskell - писать элегантный параллельный и математический код, C# - создавать программы на гибкой масштабируемой архитектуре. Современные языки заставляют нас мириться с их недостатками: отсутствие нужной системы типов, нехватка синтаксического сахара, отсутствие парадигмы X. Все хоть раз мечтали о языке, который удобен для решения любой задачи.
Я расскажу о своих идеях по созданию универсального языка программирования. Плавно перейдем к идее языка-конструктора. Вас ждет погружение в модульную архитетуру, лямбда-исчисления, байткод, расширяемое программирование
Привет! Меня зовут Артем Герасимов, я владелец продукта SimpleOne SDLC. В статье расскажу о проблеме, с которой сталкивается большинство ИТ-компаний: они тратят миллионы на разработку функций, которыми никто не пользуется.
Есть крутой разработчик Петя. Он проходит отбор на позицию, встречается с тимлидом, показывает, что уверен в себе, много знает и быстро учится, задаёт много вопросов, даже немного критикует.
Казалось бы, всё хорошо: кандидат может бустануть команду, и самого Петю позиция устраивает. Он открывает почту, а там: «Sorry, you’re overqualified».
Возможно, у Пети и правда большой опыт и ему быстро станет скучно. Но есть и другой вариант: нанимающий менеджер просто не стал приглашать специалиста, которого посчитал сильнее самого себя.
Решили как-то предприниматели ИТ-фирму организовать. Офис открыли, дорогим оборудованием обставили, всё по-модному и современному. Тут тебе и чай с печеньками, и комнаты отдыха, и психолог молодая и красивая. Не фирма, а заглядение.
Нашли заказчика — и появился у них новый проект. Чтобы его реализовать, решили нанять одного программиста, такого, чтоб потолковее да по-покладистее, и платить ему решили побольше. В помощь ему взяли дешёвого менеджера проектов. От него требовалось, чтобы выглядел прилично и любую прихоть заказчика выполнял.
И вот нашли менеджера и программиста. Программист весь такой «семь пядей во лбу», рвётся в бой и готов писать хоть сутками. Менеджер — приветливый, дружелюбный и амбициозный. Одна только небольшая проблема — в программировании он полный ноль. Настолько ноль, что когда его спрашиваешь: «Что такое метод пузырька?» — он в ответ загадочно улыбается, достаёт стакан и пол-литра.
И вот начинаются рабочие будни. На любое совещание менеджер берёт с собой программиста. Надо же как-то задачи ставить, а разбираться в том, как и что писать — это не его забота. Его дело — «проект к успеху двигать». Программист же и по совещаниям бегает, и работу работает. Работы становится всё больше и больше, количество совещаний и их длительность тоже постоянно увеличиваются. Чтобы всё успеть, приходится писать в спешке. Местами уже не до идеального кода.
Заказчику, конечно же, промежуточные результаты не показывают. Зачем ему знать внутреннюю кухню? Вдруг заподозрит чего или разочаруется. Как итог, на первом релизе получают кучу замечаний, недовольного заказчика, и менеджер обещает всё переделать, и, конечно же, за счёт фирмы, в которой он работает. Они ведь сделали не то, что он ожидал. В итоге программист работает круглые сутки, чтобы всё исправить, а менеджер его ещё и дёргает по нескольку раз на день, а то вдруг он опять «дров наломает». Худо ли, бедно, всё доделывают-переделывают и показывают заказчику. Он недоволен, но так и быть запускает проект у себя и продолжает оплачивать дальнейшую разработку. А так как объём работ увеличивается и хочется, чтобы качество было получше, он соглашается увеличить финансирование.
Нам часто предлагают врубиться во что-то с места в карьер: «Вот я формулку нарисовал и всем понятно!».
Но не беспокойтесь, в начале же была не формула, в начале было слово, и вот о словах-то мы сейчас и поговорим. Я хочу этой статьей увлечь как гуманитариев, так и айтишников с математиками!
Понимаю, что у вас кружится голова от большого количества новых незнакомых понятий и терминов. Лучший способ все это уложить — пройти стопами тех людей, которые делали простые вещи, но называли это сложным, узнать историю развития и понять, почему все работает так, а не иначе.
Для этого нам придется углубиться в робопсихологию и робопсихиатрию!
В начале было слово...
Тимлид бывает отличным техническим специалистом, но плохим руководителем, если в одиночку тащит проект на себе. Он закрывает чужие задачи, пишет документацию, подключается к каждому созвону и один следит за дедлайнами. Такой режим превращает его в «бутылочное горлышко» — человека, от которого зависит движение проекта.
Раньше я тоже был «горлышком». Однажды руководил сервисом для банка, но заболел ковидом и три дня не мог работать. Проект замер: разработчики ждали указаний, тестировщики сидели без дела, аналитики не могли ничего согласовать. Пришлось с температурой выйти с больничного и вести процесс самому, потому что кроме меня никто не понимал, как в банке устроена работа сервиса регистрации бизнеса.
Меня зовут Степан Сорокин, я delivery manager в Outlines Tech. Ниже поделюсь мнением, как перейти от роли пожарного к роли стратега: научиться делегировать, развивать команду и автоматизировать рутину, чтобы не переписывать код за разработчиков ночью и не выходить на созвоны с температурой. Ещё поделюсь своими артефактами, которые разгружают операционку и оставляют время на стратегию.
На каждом созвоне слышно одни и те же правильные слова:
Надо думать наперед,
Архитектура должна быть мощной,
Давайте писать с запасом на рост.
А к вечеру — очередной релиз на костылях, баги в проде и геройская починка в ночи. И самое забавное, что команда не состоит из новичков. Все прекрасно знают, как делать правильно.
Привет, Хабр! Меня зовут Владимир Добрынин, я ведущий разработчик в МТС 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 в Росгосстрахе. В молодости будучи школьником, еще задолго до появления всяких «Вкусно — и точка», я какое-то время работал в Макдоналдсе. И тогда, конечно, даже не задумывался, что этот опыт окажется полезен в моей дальнейшей карьере в айти. Казалось бы, что общего у фаст-фуда и разработки продукта?
Представьте, что вы работаете по скраму, но без скрам-мастера. Его задачи распределены между участниками команды. Представили? Отлично! Усложним задачу: представьте, что тимлида тоже нет. «Хаос» — скажете вы? Вовсе нет! Мы так работаем уже несколько лет.
Привет, я — Иван Зверев, фулстэк в Додо. Сегодня я расскажу о том, как круто может самоорганизоваться здоровая команда, если довериться ей, обозначить прозрачные правила работы и дать свободу экспериментировать с процессами. Вперёд!
«В последнее время все меньше иностранных компаний остаются доступны в России. В связи со сложными внешнеполитическими процессами, внутренний рынок требует все больше отечественных независимых „импортозамещающих“ разработок во всех сферах производства, включая и горную промышленность.»
Примерно с такой формулировкой к нам обратилось одно крупное предприятие из области добывающей промышленности.
---------------------------------------------------
На большинстве крупных предприятий так или иначе всегда присутствует конвейер. Вещь очень полезная, тем более если необходима постоянная транспортировка материала из цеха в цех, на переработку или куда‑нибудь еще. В нашем случае, точнее в случае заказчика, конвейер установлен в цехе среднего дробления и задача его — загружать руду в мельницу, для получения более мелкой фракции на выходе.
