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

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

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

Заслуживает ли карьера руководителя твоего внимания?

Почему ты пашешь за троих, а повышают коллегу?

А что, если ты всегда хотел в менеджмент — но не понимал, с чего начать?

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

Кто сказал, что айтишники не идут в беттинг? В PARI инженеры работают с big data, а не ставками, обсуждают пайплайны вместо коэффициентов и играют в футбол между деплоями. 

Разбираем, как компания построила IT-команду, которой не страшно соревноваться даже с бигтехом.

Привет, Хабр! Меня зовут Леша Жиряков, я руковожу бэкенд-направлением витрины KION, возглавляю гильдию по Python и пишу для блога MWS на Хабре. Сегодня на собственном примере покажу, какие задачи может вести CTO в крупной технологической компании, почему его день расписан по минутам, как распределяются ресурсы между командами и что делать, когда важный микросервис вдруг перестает видеть базу данных. Если будут вопросы по теме — пишите в комментариях, постараюсь обо всем подробно рассказать. 

Я видел сотни команд, которые пытались внедрить систему управления и бросали через пару месяцев. Каждый раз звучал один и тот же вопрос: как сделать так, чтобы команда начала работать в системе?

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

Привет, Хабр! Меня зовут Василий Сизов. По образованию я инженер-конструктор, а сейчас работаю тимлидом в ВТБ и занимаюсь машинным обучением в CRM и проектами с LLM. 

В какой-то момент мне доверили кросс-функциональную команду — и тут пришлось разбираться не только в моделях, но и в процессах, которые обеспечивают их жизнеспособность. В этой статье расскажу, как мы пересобрали эти процессы и сократили Time to Market на 20%. Возможно, вы узнаете в этих историях свои задачи и вызовы – и найдете идеи, которые помогут их решить.

Привет, Хабр! Меня зовут Игорь Акимов, CEO Abasis.AI. Мы в последний год смотрим, как российский и не только бизнес пытается оседлать хайп-трейн с надписью «Искусственный Интеллект»

И знаете, что? Чаще всего это выглядит как карго-культ. Все бегают, кричат "Надо срочно всем использовать AI! Сейчас все будут работать в 2 раза быстрее!", покупают лицензии ChatGPT и аналогов всему офису и ждут чуда. Но будем честны: у 9 из 10 компаний получается не «цифровая трансформация», а дорогостоящий «театр инноваций».

Крупные компании используют Jira по привычке — инструмент создавали для небольших команд, но его пытаются применять и в энтерпрайзе. Если вы управляете масштабными продуктами и используете масштабированные фреймворки (SAFe, LeSS и другие), вам нужны специализированные решения, и Jira с этим не справляется.

Меня зовут Артем Герасимов, я владелец продукта SimpleOne SDLC. Внедрял гибкие методологии в различных компаниях — от 50 до 1000 человек. В нескольких из них ускорил выпуск новой функциональности в четыре раза, что помогло компании адаптироваться под сложный рынок. Работал с Jira как администратор, настраивал её для получения статистики по командам. Сталкивался с ограничениями этого решения и в маленьких компаниях, и в крупных.

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

Всем привет! Меня зовут Александр Соколов, я эксперт центра практик DevOps в МТС Web Services (MWS). В 2020 году в МТС началась масштабная унификация внутренних процессов. По задумке, целью этой трансформации было сделать экосистему наших продуктов по-настоящему технологичной, быстрой, управляемой и гибкой. В компании выделили направления, которым особенно нужно развитие, среди которых был и DevOps. Затем два года мы разрабатывали, пилотировали и внедряли стандарты и практики для более чем 400 продуктов экосистемы.

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

Если вы руководите компанией от 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 годами практики с языком ДРАКОН - честно, с раскрытием конфликта интересов и границ применимости метода.​

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

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

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

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

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

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

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

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

Привет, Хабр. Меня зовут Полина Захарова-Щукина, я 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. Это к тому, что все мы «стоим на плечах гигантов» и благодарны за советы старших товарищей.

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