К основному содержимому
#Management

Как формировать структуру команд под запросы бизнеса - часть 3

#Management #Leadership #Project #ProjectManagement #Software

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

  • Есть конкретная целевая аудитория продукта
  • Есть примерное понимание какие фичи, стори, JTBD (jobs to be done) мы хотим реализовать
  • Есть желание выкатывать эти изменения небольшими порциями и тестировать как они работают
  • Есть понимание, что план может гибко меняться в процессе движения С таким набором ожиданий становится ясно, что проектный подход нам не подходит. В итоге, мы приходим к продуктовым процессам разработки, про которые я рассказывал в докладе "Совершенствование потока разработки программного обеспечения", где я рекомендовал почитать книгу "Making Work Visible" от Доминики Деграндис, про которую я писал раньше. Но вообще есть несколько подходов к тому как организовывать работу и планировать время ее выполнения. Однако важно помнить про ироничный закон Паркинсона

Работа заполняет время, отпущенное на неё Этот закон дает понять почему планирование работы с буферными запасами проблема, а именно так часто планируют в проектном управлении. Но если планировать работу задач на команду в режиме push, то можно столкнуть с тем, что требования к командам и их производительность не сбалансированы, что не позволяет выполнить все задачи вовремя. В итоге, нам нужна система с pull режимом, когда люди вытягивают новую задачу по мере завершения предыдущей. Такой системой, например, является Kanban. Но важно понимать какие задачи попадают в такой процесс - важно не соглашаться на все подряд, а обдуманно давать добро только на самые важные в конкретный момент и делать это визуально. Для этого надо организовать систему рабочего потока, выполняющую следующие задачи

  • Делает работу видимой
  • Ограничивает количество незавершенной работы
  • Оценивает рабочий поток и управляет им
  • Эффективно определяет приоритеты
  • Вносит коррективы на основе метрик и обратной связи

И проблема со временем и его утеканием обязана следующим пяти факторам

  • Too WIP - история про незавершенную работу, бутылочное горлышко и закон Литтла.
  • Unknown dependencies - здесь про архитектурные проблемы и зависимости между системами и разными командами.
  • Unplanned work - незапланированная работа крадет время у запланированной. Этим она делает систему непредсказуемой, а главное для нас — это прогнозируемость и ожидания.
  • Conflicting priorities - если все задачи приоритетные, то ни одну из них нельзя назвать реально важной. Без внятных приоритетов людям приходится пытаться сделать слишком много сразу, что автоматически приводит к росту WIP, который замедляет всю систему.
  • Neglected work - часто такая работа проявляется в форме техдолга, который накапливался в системе, когда люди только клепали фичи без работы по повышению технического совершенства системы. Вообще, часто проседает важная но не срочная работа, которую так любят откладывать … пока она не перерастет в экстренную ситуацию, когда станет незапланированной работой, от которой нельзя отказаться.

В итоге, я всегда стремился выстроить продуктовые кросс-функциональные команды, используя Kanban подходы. В целевом виде эти команды являлись stream-aligned командами из Team topologies (подробнее в обзоре 1, 2, 3). Про то, как я строил продуктовую разработку я рассказывал в контексте нашего веба Tinkoff.ru в двух давних докладах

#Management #Leadership #Project #ProjectManagement #Software