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

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

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

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

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

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

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

Можно ли создать гармоничную экосистему взаимодействия внутри проектной команды, когда слова «гармония» и «проект» это разнопланетные категории? Меня зовут Индира, я администратор IT-проектов, и в этой статье хочу поделиться своим опытом, наблюдениями и выводами о том, как найти гармоничный подход к каждому члену в команде.

Представьте, что вы лидер молодого, но быстрорастущего стартапа в области ML. Вам предстоит собрать команду, и вы думаете о том, каких специалистов вам предстоит найти:

- Data Scientist — для создания прототипов моделей машинного обучения, подходящих по задачи вашего проекта;

- ML Engineer — для внедрения в эксплуатацию моделей и сценариев, масштабирования;

- Data Engineer — для создания ETL‑процессов, систематизации сбора и хранения данных;

- DevOps/MLOps — для автоматизации процессов и развития инфраструктуры;

- SRE — для обеспечения мониторинга и надёжности вашей инфраструктуры.

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

(спойлер: в конце будет ссылка на GitHub)

Таск-менеджеры вроде Jira — хороший инструмент для ведения проектов. Вот только есть одна проблема — на них очень быстро забивают. В первую очередь — проектные менеджеры (на всякий случай: я тоже забиваю). Когда проект стартует, менеджер с командой, как правило, делают волевую попытку декомпозировать его на эпики и задачи. Каждая задача получает красивое описание, а иногда даже назначенных исполнителей и дедлайны.

Потом проект стартует…

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

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

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

Но что делать когда этого не достаточно и пользователи все равно жалуются?

Ну и что делать, если в вашей компании — несколько тысяч программистов, сотни команд и десятки стримов? И вам нужно… Нет, не нужно — жизненно необходимо, чтобы они все работали как единый, отлаженный, настроенный механизм.

Разработка в Газпромбанке — это процесс, в котором задействовано более 3500 инженеров, пять департаментов, 59 стримов и 200+ кросс-функциональных команд.

При этом был период, когда наши команды создавали ПО разрозненно, стандарта разработки не было, практики и технологии у всех свои. Велосипеды, как в анекдоте, были у всех, но ездили по-разному. Билды проходили тесты, которые не должны были пройти, и возвращались «на доработку» едва ли не перед запланированным релизом. Что же делать, как же быть?

Да. Нужен стандарт. И нужны автоматизированные средства поддержки стандарта.

Нам не подошли ни одни из существующих Quality Gates — мы сформировали собственный набор практик проверки качества продукта (билда, сборки — всего того, чему требуется многоуровневое тестирование). Теперь у нас выросшая в семь раз частота деплоев и шикарные фильтры, построенные на тестах.

Почему мы не купили готовое решение? Что сделали? Как? Расскажем.

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

Это первая из запланированных статей по внедрению практики использования языка Archimate для различных ИТ-ролей. Конкретно этот материл будет полезен прежде всего бизнес-аналитикам для повышения уровня компетенций и дополнения используемых инструментов моделирования бизнес-процессов (подробней про апгрейд роли было здесь).

Привет всем! Меня зовут Гриша Капцов, я работаю в Отделе координации и поддержки продуктовых команд в МТС Web Services. В прошлом посте рассказывал, как мы с командой прокачали свой навык повелевания хаосом. А сегодня хочу обсудить ситуации, когда один «незаменимый» сотрудник становится угрозой. 

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

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

Предотвратить такие сценарии можно, если отслеживать «фактор автобуса», или Bus Factor — показатель зависимости проекта от отдельных членов команды. Ниже я расскажу, почему эта метрика особенно критична для эксплуатационных команд и как ее измеряем мы. Давайте назовем кейс «This is эксплуатация!».

Мы с командой, как и многие, вели рабочие переписки в Telegram. Постоянно теряли задачи во флуде и мемах, забывали о договорённостях и тратили часы на поиски нужных сообщений.

Тогда мы решили взять лучшее от Telegram и сделали свой корпоративный мессенджер — который помогает фокусироваться на работе.

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

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

• как радикальные решения могут улучшить ситуацию с техдолгом;

• почему термин «техническая задача» только мешает;

• как продавать бизнесу задачи, которые кажутся «чисто техническими»;

• почему выделять определённую часть  времени на техдолг — недостаточно;

• как ускорить отдачу техдолга за счёт усиления фокуса;

• как лиду перейти от ручного контроля к автономной работе команды.

Чтоб сделать, чтобы базой знаний реально пользовались? Один из путей — дать возможность и наполнения, и получения ответов в привычном интерфейсе, без захода в дополнительные приложения.

Вот уже несколько лет каждые сутки сотрудники информационной службы Хабра внимательно ищут десятки новых интересных технических инфоповодов, большая часть из которых становятся новостями, лонгридами или переводами. С 2014 года в инфослужбе Хабра для постановки задач и работы с авторами использовалась бесплатная версия решения от Asana. С конца марта 2025 года вместо этой платформы в инфослужбе Хабра решили перейти на сервис по управлению тасками Kaiten («Кайтен»). Как это происходило — будет рассказано далее.

В первой части мы озвучили следующие тезисы:

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

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

- тесты ломают разработчики, поэтому им за них отвечать - все виды тестов должны писать и поддерживать разработчики;

- с полным автоматическим регрессом можно и нужно ставиться в прод после каждого изменения в кодовой базе;

- главный шаблон поставки в прод изменений - конвейер развертывания (Deployment Pipeline);

- конвейер делится на 2 главные фазы: commit stage и acceptance stage;

- первая фаза - быстрые тесты (до 5 минут), чтобы быстро узнать, что ветка сломана и её надо скорее чинить;

- вторая фаза - приёмочные тесты (до 1 часа), чтобы узнать, можно ли ставить в прод изменения.

Про быстрые тесты мы поговорили во второй части. Пришло время поговорить про короля автотестов - приёмочное тестирование.

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

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

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

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

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

Заходите утром в Jira, Asana или Yandex Tracker. Перед вами — бесконечный список задач, раскрашенных в цвета приоритетов, разбитый на спринты и эпики. Каждое действие нужно залогировать, каждый комментарий — оставить в тикете, а каждую «помидорку» — учесть в тайм-трекере. Знакомое чувство легкой тоски, стыда за незакрытые задачи и раздражения от бесконечных уведомлений? Поздравляю, вы не одиноки. Это — синдром современного высококвалифицированного специалиста, которого пытаются загнать в систему, созданную для управления… заводскими рабочими начала XX века.

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

Статистика показывает, что 42% стартапов терпят неудачу из-за отсутствия потребности рынка. А причина этому, пренебрежение изучению своего целевого рынка. Предприниматели, которые инвестируют не менее 10% своего бюджета в исследование рынка, показывают на 30% более высокий уровень успеха.

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

С приходом ИИ, скорость и влияние внешних факторов только усугубляется. Я думаю, каждый человек видит насколько каждая новая модель ChatGPT, Grok, Gemini, Genspark и других инструментов, выбирает из себя многих специалистов и компании. То, на что требовалось ранее годы, теперь делается за месяцы. Те, кто стали в волне рынка еще год-два назад и залетели на пике, сейчас пожимают кассовые разрывы и не могут найти клиентов.

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

Цель статьи – сравнить принятие решение и проектный треугольник, чтобы показать условия, при которых можно выбирать зону риска для принятия более качественного управленческого решения. Я пишу эту статью как размышление, а не как научное исследование. Классический проектный треугольник управления проектом достаточно известен: объем, сроки, ресурсы. На практике, для обеспечения качества мы пытаемся контролировать два наиболее значимых аспекта треугольника (хотя надеетесь контролировать все три). В теории мы определяем объем фиксировано, устанавливаем сроки и планируем ресурсы. Таким образом мы пытаемся сохранить все параметры проекта неизменными. Часто в процессе все начинает идти не совсем по плану, и мы начинаем работать с отклонениями и рисками, которые возникают по мере реализации проекта. Как мне рассказывал один из руководителей проектного офиса, в годовой перспективе фиксация объема, ресурсов и времени путем описания требований, создание дизайна, расчет ресурсов и планирование занимают примерно восемь месяцев в году. Таким образом, для реализации остается четыре месяца в годовом горизонте. Не будем касаться актуальности решения спустя год такого планирования и аспектов целесообразности в изменчивом мире. Классический подход вполне имеет место на свое существование. Перед началом введем несколько определений: Объем – это тот список работ, задач или необходимый состав операций который необходимо выполнить. Время – это время которое мы планируем затратить на проект или любые временные ограничения. Ресурс – это в первую очередь совокупные затраты на проект, затраты на персонал, сам персонал который нам необходим, а также иные виды ресурсов или материалов которые нам понадобиться для получение готового объема задач. Если представить проект как треугольник то мы сможем нарисовать вот такой рисунок.

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

Существует несколько распространённых сценариев, но тот, о котором я хочу поговорить, касается ситуации, когда менеджеры формируются в организациях с жёстким централизованным планированием («роли, основанные на координации»), а затем оказываются на достаточно высокой позиции или в компании с организацией “снизу вверх”, где от них ожидают не координации, а именно лидерства («роли, основанные на лидерстве»).