Группа управления разработкой

team

Для того, чтобы руководить разработкой продукта, нужно уверенно держать в руках три «руля»:

  1. Административное руководство.
  2. Управление изменениями.
  3. Техническое и архитектурное управление.

Рассмотрим все три «руля» более подробно.

team

Административное руководство.

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

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

Организация — процессы, напрямую не связанные с производством, но влияющие на него. Инфраструктура (рабочие места, обеды, кофе и проч.) и обеспечение коммуникаций.

Кадры — рекрутинг сотрудников, мотивация.

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

Данного перечня работ вполне достаточно для полной загрузки менеджера продукта. При попытке навесить на него второй и третий «рули» возникнет сбивание фокуса и падение производительности всей команды.

team

Управление изменениями.

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

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

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

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

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

team

Техническое и архитектурное управление.

Сюда входит группа работ по обеспечению производства. А именно:

Архитектурное управление — обеспечение технической целостности и непротиворечивости работы модулей системы, структуры базы данных и проч.

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

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

Обучение. Организация обучения джуниоров, повышение квалификации мидлов, поддержание матрицы компетенций.

Управление технической документацией. Организация написания технических спецификаций. Особенно актуально для работы над продуктом, являющимся частью комплекса ПО. Без технических спецификаций (это третий вид документации) реализация взаимодействия продуктов будет затруднена.

Консультации аналитиков, выработка вариантов реализации.

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

Данного перечня работ достаточно для полной загрузки главного разработчика продукта. Этот человек полностью отвечает за группу разработчиков и больше ни за что.

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

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


Опубликовано

в

от

Если хотите получать новые посты на имейл, подпишитесь на рассылку. Пишу нечасто и по делу. 

Предыдущий пост
Сводка типичных ошибок руководителей: нефиксация договоренностей, найм неподходящих сотрудников, в…