Портал №1 по управлению цифровыми
и информационными технологиями

Работать меньше, чтобы сделать больше

Все, а больше всех инвесторы и спонсоры, хотят, чтобы вся команда работала над новыми задачами, фичами, эпиками не останавливаясь.

Тем не менее, несмотря на столь жгучее желание, команда не сможет выделить все свое время на новые разработки. Причин тому несколько:

  1. Баги случаются, и когда они случаются, то они становятся приоритетом. Нестабильное или нефункциональное хоть в чем-то приложение генерирует не только прямые потери через снижение продаж, но и снижает конверсию, отталкивает лояльных пользователей, вызывает недоверие клиентов.
    Что делать? — Резервировать время/ресурс, организовывать Emergency lane.
  2. Разработка состоит не только из downstream разработки и доставки. В области discovery, в upstream активностях возникает потребность в ресурсах команды: сделать оценки, сформировать гипотезы, принять архитектурные решения, корректно декомпозировать задачи. Проигнорируйте это, и вся ваша команда встанет и выйдет, когда в очередной раз будет наблюдать главного антагониста фильма «Нечто» в беклоге.

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

  3. Членам команды нужно общаться между собой, организовывать свою работу, решение рабочих вопросов, обсуждать решения и прототипы, проводить code review и анализ последствий принятых ранее решений. 

    Что делать? — Ничего не делать, это время нужно для того, чтобы работа была сделана. Все, что вы можете — отслеживать неэффективные коммуникации или обсуждения вопросов, которые, возможно, не должны были бы беспокоить вашу команду. 

  4. Техдолг. Он есть, и он будет продолжать есть: снижать вашу производительность и скорость разработки, повышать число дефектов, снижать эффективность тестирования, мешать измерениям и мониторингу. Радуйтесь, если весь ваш технический долг — последствия осмысленных решений, ведь так бывает не всегда.

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

  5. Переработки, бесконечный бег на месте и выгорание. Гонки — это временное мероприятия. «24 часа Ле-Мана» на протяжении недель и месяцев не будут выдерживать даже стальные кони, не говоря уже о людях.
    Что делать? — Работать с вашими коллегами плечо к плечу, доверять их эмоциям и настроениям. Давать возможность выдохнуть, сменить фокус, переключить контекст. Белки в колесе — последнее что вам будет нужно, если ключевые разработчики попросят остановить поезд.

 

Вместо резюме: Смотрите на вашу команду открытыми глазами, изучайте ситуацию системно, измеряйте честно, доверяйте метрикам и людям.

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

Для каждой команды, культуры, приложения, накопленного наследия и контекта требуемая доля мощностей будет своей.
 

Учебные курсы и сертификация
специалистов по ИТ-менеджменту

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

  • Рубрики

  •  
  • Авторы

  •  
  • Самое свежее

  •  
  • Вход

  • DevOps
    Kanban
    ITSM
    ITIL
    PRINCE2
    Agile
    Lean
    TOGAF
    COBIT