Управление проектами *

В 2020–2021 годах казалось, что Agile-коуч нужен каждой компании. Стартапы, корпорации, банки, ритейл, госсектор одновременно приобщались к Agile: нанимали коучей, запускали трансформации и рисовали красивые роадмапы изменений.

А дальше что-то пошло не так.

С 2023 года вакансий стало меньше, требования ужесточились, а бюджеты начали сжиматься. И в комьюнити всё громче зазвучали вопросы: «Agile умирает или это взросление? А что будет с профессией Agile Coach дальше?».

Привет, Хабр! Меня зовут Константин Левкин, я Head of Agile в Райффайзен Банке. Не смог пройти мимо этой темы и решил основательно разобраться и собрать факты о том, что происходило в последние годы. Как изменился рынок труда, что происходит с зарплатами, ролями, какие региональные различия возникают и есть реальные результаты прошедших трансформаций. Хочу поделиться нарытыми данными и выводами на их основе. Совсем далёкие прогнозы в наши нестабильные времена делать опрометчиво, поэтому ограничусь своим видением изменений в профессии Agile Coach до 2029 года.

Во многих местах статьи есть умышленный уклон на данные рынка США, так как многие тренды в IT проходят путь США-Европа-Россия за 2-3 года. То есть та реальность и те данные в отчетах по рынку США сегодня, вполне могут стать нашей реальностью через пару лет.

Если сильно упростить, Agile прошёл тот же путь, что и многие управленческие идеи до него.

2019–2020
Agile это про команды. Scrum, спринты, ретроспективы, velocity.
Agile-коуч — это фасилитатор и тренер.

2021–2022
Рынок перегревается. Спрос растёт быстрее качества. Зарплаты Agile-коучей в США за два года вырастают на 30–50%.

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

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

Эта разница почти всегда упирается не в опыт, а в критическое мышление.

Привет! Меня зовут Виталий, и я управляю проектами в KTS. 

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

По счастливому совпадению в прошлом феврале я попал на курс СТО от Стратоплана, о чем рассказывал на Хабре в своей предыдущей статье. На курсе я взаимодействовал с бывшими и действующими техдирами крупных компаний, работал с ними в командах, обменивался с ними опытом.

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

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

Я почти каждую свою статью начинаю с одного и того же уточнения: я не разработчик. И это не попытка снять с себя ответственность. Это важная рамка.

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

Ниже — не пересказ отчётов аналитических агентств (хотя для написания статьи я изучила не один) и не прогноз «как будет правильно». Это попытка разобрать, где именно современные идеи про маркетинг как систему ломаются при внедрении — и почему компании к этому часто оказываются не готовы.

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

Люди добрые, не ругайте вы меня почем зря за предположение, что ваши Эксель таблички ненормальные, статью до конца не дочитав... Но, к сожалению и с вероятностью 90%, они действительно таковы.

Эта статья всего лишь крик души специалиста, который устал. Дико устал. Чудовищно устал от того, что ему каждый день приходится смотреть на десятки ужасных таблиц в его любимейшем Экселе (ну и Гугл доксе заодно). Ещё больше его удручает, что даже на курсах по повышению грамотности экселя об элементарных вещах сказать забывают. Как результат – текущие от боли глаза. Ну почему?! Почему такие простые вещи никто нигде не рассказывает?!

Добрый человек, не поленись. Дочитай. И твои таблицы станут на порядок лучше и понятнее не только для тебя, но и для всех окружающих!

Периодически слышу, как мне говорят: «В Jira неудобно управлять бэклогом, стандартный список задач мне не нравится». Дело доходит даже до выписывания задач в Excel. Тогда зачем нам таск-трекер?

Сегодня попробую рассказать о решении, которым сам пользуюсь, а именно про применение Structure.

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

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

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

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

Когда я только пришла в Kaiten, нам нужно было выстроить четкую структуру HR-процессов. За 3 месяца мы создали эффективную систему с канбан-досками и автоматизацией задач. В статье расскажу, как у нас все устроено.

Новая история от продуктового лидера, который строил-строил лояльность в продукте, да так и не достроил.

Спойлеры:

3 измерения: Потребность → Цель → Мотивация 

5 типов клиентов (неприбыльные, пленники, новые, постоянные, лояльные) 

Формула пленников

Правило 70/30 для драйверов мотивации 

3 грабли, которые стоит избежать 

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

Меня зовут Евгений Иванов, я Agile Cluster Lead кластера Облачные технологии в компании MWS Cloud — команды, которая создала MWS Cloud Platform. И в этой статье я расскажу, почему мы считаем наш кластер анклавом процессных практик и какие плюшки и сложности мы с этого имеем. На тему наших процессов мой коллега Саша Стерлигов уже написал подробную статью. Почитайте.

Привет, Хабр! 

Меня зовут Константин Евсеев, я тружусь в компании VisionLabs, которая специализируется на технологиях биометрии и компьютерного зрения. В этом посте расскажу о проекте, к воплощению которого я хотел приложить руку еще за четыре года до его появления. Конкретно — о разработке системы для заселения в отель по биометрии. Почему? Все просто: если ты инженер и видишь, что что-то можно улучшить, то руки чешутся, пока не сделаешь. 

Этой статьёй я открываю новый цикл «Проект для Исполнителя». Цикл этот я готовил давно, записывал наброски. Но когда захотел выбрать пять правил для первой статьи, то неожиданно увидел, что их у Исполнителя много, и все они важные и правильные. Пришлось некоторые объединить, менее важные — оставить на потом. Остались универсальные, годные не только для команды Исполнителя, но и для всего проекта.

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

А я сажаю рядом Оппонента и даю ему возможность пару раз оспорить каждое правило.

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

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

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

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

В крупных проектах управлять качеством вручную — весьма нетривиальная задача: объем требований и фичей, уточнений и доработок, баков и фиксов растет нелинейно, а риски — экспоненциально. В таких условиях необходимо структурировать процесс обеспечения качества (QA), чтобы предотвратить эффект «снежного кома», который может «завалить» тестировщиков — сначала фрустрацией от рутины, а потом недовольством заказчика.

Во всех обсуждениях ценности ИИ-помощников в разработке ПО мне встречается одна печальная история: разработчик-джун, вооружившийся каким-нибудь LLM-инструментом, создаёт для своих коллег или мейнтейнеров опенсорс-проекта огромный нетестированный PR, ожидая, что всё остальное решится благодаря процессу код-ревью.

Такое поведение грубо, оно заставляет других людей впустую тратить время и идёт вразрез с долгом разработчика ПО.

Ваша задача — выпускать код, который доказанно работает.

Мы, разработчики ПО, не просто производим код; сегодня даже можно сказать, что для этого предназначены LLM. Мы должны выпускать код, который работает, и приложить к нему доказательство его работы. Если вы этого не делаете, то просто сбрасываете бремя настоящей работы на того, кто должен будет проверять ваш код.

Привет, Хабр! На связи Игорь Батулин — руководитель группы разработки виртуального хостинга в Рунити. Недавно в другой статье я рассказывал, как написал приложение для поиска маршрута в рогейне — делал его для себя, чтобы ориентироваться на дистанции. Опыт оказался удачным, и я продолжил собственную разработку — решил разобраться с личными финансами. 

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

Когда говорят о женском лидерстве, чаще всего обсуждают квоты, инклюзию и корпоративную культуру. Это важно, но с точки зрения бизнеса и HR в какой-то момент возникает более приземлённый вопрос: какие конкретно компетенции отличают женщин, которые уверенно выходят в управленческий контур, от тех, кто остаётся на линейных ролях?

Чтобы ответить на него, полезно отойти от общих рассуждений и посмотреть на данные.

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

Эта статья — не техническая документация для системных администраторов. Это гайд для владельцев бизнеса и ИТ-директоров, которые хотят понять природу «тормозов» в 1С, чтобы эффективно ставить задачи своим техническим специалистам или подрядчикам. Мы намеренно не углубляемся в синтаксис SQL-запросов, а фокусируемся на точках контроля, организационных причинах сбоев и экономике владения системой.