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

Всем привет! За полтора года наша команда разработки в YADRO написала с нуля четыре полноценных приложения для операционной системы kvadraOS. Проекты разные по объему, требованиям и связям с системой, но всех их объединяет современный стек (Kotlin + Compose) и чистая архитектура.

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

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

Всем привет! Меня зовут Антон Чижов, я руковожу в MWS центром практик agile. Вместе с Александром Демидовым, директором по разработке MWS, расскажем о продуктовом инженере — новой роли, которая открывает для опытных специалистов более гибкие варианты карьерного трека. 

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

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

У каждого, кто работает с высоконагруженными системами, своя коллекция боевых шрамов. Знаете эти истории про инциденты, когда всё идёт совсем не по плану? У меня тоже есть такая — очень показательная. Правильные инструменты, лучшие практики, опытная команда — и всё равно куча проблем. Это хороший повод рассказать, почему даже самых продвинутых инструментов может быть недостаточно, когда не видишь всей картины.

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

Представьте, что вы покупаете мотоцикл. Чего вы от него ожидаете? Чтобы он мог разгоняться до 180км/час и при этом не разваливался? Чтобы к нему можно было прикрепить коляску? И не забудем про систему безопасности.

Эти требования не описывают основную функцию мотоцикла — перемещать человека из точки А в точку Б — но они важны для удовлетворения ваших потребностей, как водителя.

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

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

С 2021 года сотрудники в разных исследованиях всё чаще говорят: «я хочу регулярный, полезный фидбэк». В разных выборках от 80% до 96% респондентов отмечают пользу обратной связи и её влияние на мотивацию. Но статистика показывает ужасную разницу между желанием и реальностью: по данным Gallup и Happy Job, более 75% сотрудников не получают достаточно обратной связи, и лишь около 16% считают её действительно полезной.

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

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

Договор вводит в оборот и хранит интеллектуальные права на товарный знак и другие объекты. Вы монетизируете интеллектуальную собственность.

В 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 и найм не «самых крутых», а подходящих под задачи и ценности. Продуктивность измеряется не строками кода и не тайтлами, а влиянием на бизнес; остальное — лишь прокси-метрики.