Архетипы проблемных продакт-менеджеров в ИТ-проектах Статьи редакции

Одни пишут слишком длинные ТЗ, а другие не пишут их вовсе. Кто-то заставляет коллег перерабатывать или во всём винит разработчиков. Чем они опасны и как с ними работать, объясняет техлид Нил Грин.

Основная задача продакт-менеджера в компании-разработчике ПО — определить бизнес-требования к продукту, пишет Грин. Они как правило тесно взаимодействуют с руководством, партнёрами и клиентами и напрямую влияют на развитие продукта.

Любое их неверное решение, каким бы незначительным ни было, затрагивает весь проект: начиная от сроков и заканчивая качеством.

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

• Вероятность исправления: высокая.
• Угроза для проекта: низкая.
  

По мнению «диктатора», единственная задача разработчиков — исполнять требования продакт-менеджеров.

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

Чаще всего «диктатор» понимает, что сотрудничать с разработчиками удобно, но считает, что это не стоит того. Вероятная причина его отношения к разработчиками — негативный опыт сотрудничества с ними в прошлом:

• Возможно, разработчики критиковали работу «диктатора».
• Считали его сугубо исполнителем и отстраняли от принятия продуктовых решений.
• Пренебрегали задачами «диктатора», считая их неадекватными или технически невыполнимыми.

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

• Вероятность исправления: низкая.
• Угроза для проекта: низкая.
  

«Торговый представитель» склонен путать управление продуктом с продажами. Он полагает, что его основная задача — доносить до разработчиков частные требования клиентов.

Прислушиваться к потребностям аудитории важно, чтобы получать прибыль. Но у продакт-менеджера должно быть и своё целостное видение продукта.

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

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

• Вероятность исправления: высокая.
• Угроза для проекта: низкая.
  

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

Он нередко врёт руководителям, что разработчики не хотят общаться с ними напрямую:

• Во-первых, директора всё равно не поймут тонкостей их работы.
• Во-вторых, у разработчиков нет времени на абстрактные обсуждения — они привыкли к конкретике.

Что можно сделать. Исключить посредника в лице «правой руки» и обсуждать идеи с руководством напрямую.

• Вероятность исправления: нулевая.
• Угроза для проекта: чрезвычайно высокая.

«Абстракционист» сперва полагает, что разработать продукт можно и без ТЗ — достаточно только идеи. Позже разочаровывается в результате и разработчиках, которым приходится всё переделывать. Чем масштабнее проект, тем выше риск ошибиться и труднее что-то исправить.

«Абстракционистов» особенно много в сфере ИТ, потому что:

• Писать ТЗ сложно и долго, а обрисовать идею в общих чертах и раскритиковать чужую работу — легко.
• Его нельзя обвинить в получившемся — это разработчик всё неправильно понял.

Подход «абстракциониста» может сработать, если у проекта нет сроков — тогда, путём проб и ошибок, идею можно «докрутить». Однако большинство компаний следует плану, который «абстракционист» нередко рискует сорвать.

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

• Вероятность исправления: низкая.
• Угроза для проекта: высокая.
  

В разработке существуют две основные методологии, чтобы контролировать и ограничивать изменения в продукте:

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

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

Его обман подрывает работу сразу нескольких отделов:

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

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

Что можно сделать. Объяснить «жуку», что критика — это нестрашно, и попросить уважать время и силы коллег. Правда, вместо того чтобы прислушаться, «жук» скорее всего станет ещё сильнее ухищряться, лишь бы добиться своего.

• Вероятность исправления: нулевая.
• Угроза для проекта: чрезвычайно высокая.

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

Поэтому в индустрии разработок «гадёныш» — причина страданий №1: он любит увеличивать число задач, но при этом не продлевает сроки. У команды остаётся два варианта: либо работать быстрее, либо сверхурочно. Чаще всего — второе, хотя даже так она скорее всего не успеет.

Переработки негативно сказываются на всём проекте:

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

Что можно сделать. Сократить число задач, продлить сроки или переосмыслить корпоративную культуру: ставить желаемые, а не железные сроки; пересматривать требования, если нужно; не допускать переработок.

• Вероятность исправления: высокая.
  
• Угроза для проекта: низкая.

На небольших проектах ТЗ часто краткие, а подробнее их обсуждают устно. В крупных командах, особенно работающих удалённо, ТЗ расписывают детальнее, чтобы минимизировать ошибки при разработке.

Разработчики не жалуют длинные ТЗ — они скучные и не оставляют места для творчества. Тестировщики, наоборот: чем чётче прописаны требования, тем легче им создать тестовые сценарии.

Иногда детальная документация необходима. Например, если это hardware-проект с компонентами, установка которых требует чёткой спецификации.

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

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

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

• Вероятность исправления: нулевая.
  
• Угроза для проекта: высокая.

Своей основной задачей «угодник» считает поиск компромисса между двумя сильными сторонами:

• Руководством, которое понимает, чего хочет.
• И разработчиками, которые знают, как этого добиться.

Чтобы помочь им быстрее договориться, «угоднику» нужны управленческие навыки. Их у «угодника» чаще всего нет, иначе бы его давно взяли в высшее руководство.

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

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

#разработка #продактменеджмент