Архетипы проблемных продакт-менеджеров в ИТ-проектах
Одни пишут слишком длинные ТЗ, а другие не пишут их вовсе. Кто-то заставляет коллег перерабатывать или во всём винит разработчиков. Чем они опасны и как с ними работать, объясняет техлид Нил Грин.
Основная задача продакт-менеджера в компании-разработчике ПО — определить бизнес-требования к продукту, пишет Грин. Они как правило тесно взаимодействуют с руководством, партнёрами и клиентами и напрямую влияют на развитие продукта.
Любое их неверное решение, каким бы незначительным ни было, затрагивает весь проект: начиная от сроков и заканчивая качеством.
Нил Грин описал восемь собирательных образов, которые встречались ему по меньшей мере трижды в трёх разных технологических компаниях.
«Диктатор» — не приемлет ничьих идей, кроме своих
- Вероятность исправления: высокая.
- Угроза для проекта: низкая.
По мнению «диктатора», единственная задача разработчиков — исполнять требования продакт-менеджеров.
Из-за этого разработчикам трудно давать «диктатору» обратную связь: о том, сколько может стоить работа, как сделать её быстрее, не снизив при этом ценность продукта, и что изменить, чтобы использовать уже готовые решения.
Чаще всего «диктатор» понимает, что сотрудничать с разработчиками удобно, но считает, что это не стоит того. Вероятная причина его отношения к разработчиками — негативный опыт сотрудничества с ними в прошлом:
- Возможно, разработчики критиковали работу «диктатора».
- Считали его сугубо исполнителем и отстраняли от принятия продуктовых решений.
- Пренебрегали задачами «диктатора», считая их неадекватными или технически невыполнимыми.
Что можно сделать. Привлечь руководство, чтобы оно побеседовало с разработкой. Разработчикам первым пойти на контакт с «диктатором». Проводить совместные совещания, чтобы обсуждать как идеи, так и прогресс.
«Торговый представитель» — думает, как больше продать, а не как развивать продукт
- Вероятность исправления: низкая.
- Угроза для проекта: низкая.
«Торговый представитель» склонен путать управление продуктом с продажами. Он полагает, что его основная задача — доносить до разработчиков частные требования клиентов.
Прислушиваться к потребностям аудитории важно, чтобы получать прибыль. Но у продакт-менеджера должно быть и своё целостное видение продукта.
«Торговому представителю» его не хватает, поэтому он не знает, как развивать продукт. Из-за этого он становится набором разрозненных функций, которые нравятся лишь отдельным пользователям, а не среднестатистической аудитории.
Что можно сделать. Перевести «торгового представителя» из продуктового в маркетинговый отдел, поскольку видение — не навык, которому можно научиться: оно либо есть, либо нет.
«Правая рука» — передаёт требования руководства, но сам ничем не руководит
- Вероятность исправления: высокая.
- Угроза для проекта: низкая.
«Правая рука» не принимает решений сам и все идеи записывает за высшим руководством. Мнение основателей для него — закон, поэтому оспаривать его разработчикам он запрещает. «Правая рука» убеждён, что верно интерпретирует просьбы, однако это зачастую не так.
Он нередко врёт руководителям, что разработчики не хотят общаться с ними напрямую:
- Во-первых, директора всё равно не поймут тонкостей их работы.
- Во-вторых, у разработчиков нет времени на абстрактные обсуждения — они привыкли к конкретике.
Что можно сделать. Исключить посредника в лице «правой руки» и обсуждать идеи с руководством напрямую.
«Абстракционист» — сам не знает, чего хочет, а потом винит других
- Вероятность исправления: нулевая.
- Угроза для проекта: чрезвычайно высокая.
«Абстракционист» сперва полагает, что разработать продукт можно и без ТЗ — достаточно только идеи. Позже разочаровывается в результате и разработчиках, которым приходится всё переделывать. Чем масштабнее проект, тем выше риск ошибиться и труднее что-то исправить.
«Абстракционистов» особенно много в сфере ИТ, потому что:
- Писать ТЗ сложно и долго, а обрисовать идею в общих чертах и раскритиковать чужую работу — легко.
- Его нельзя обвинить в получившемся — это разработчик всё неправильно понял.
Подход «абстракциониста» может сработать, если у проекта нет сроков — тогда, путём проб и ошибок, идею можно «докрутить». Однако большинство компаний следует плану, который «абстракционист» нередко рискует сорвать.
Что можно сделать. Расписывать план действий и просить «абстракциониста» его одобрить. Регулярно обсуждать промежуточные результаты, чтобы исправлять ошибки сразу.
«Хитрый жук» — внедряет масштабные преобразования под видом маленьких правок
- Вероятность исправления: низкая.
- Угроза для проекта: высокая.
В разработке существуют две основные методологии, чтобы контролировать и ограничивать изменения в продукте:
- Гибкая методология. Все члены проекта должны быть в курсе нововведений, чтобы адаптироваться.
- Каскадная методология. Следят за изменениями и одобряют их специальные аналитические комитеты.
Небольшие правки часто пропускают, но к масштабным возникают вопросы. Чтобы избежать вопросов и возможных замечаний, «жук» разбивает свой план на несколько мелких поэтапных задач и не раскрывает главной цели.
Его обман подрывает работу сразу нескольких отделов:
- Проджект-менеджеры рискуют не выполнить поставленные руководством задачи, поскольку правки могут идти вразрез с их ожиданиями.
- Разработчики не могут создать единого решения, а потому внедряют «костыли», которые позже перестают работать.
- Тестировщикам приходится переделывать тестовые сценарии, поскольку они не знают, что и как должно работать после изменений.
Хуже всего то, что своими правками «жук» портит качество исходного кода. Чем больше непродуманных изменений в него вносят разработчики, тем сложнее и дороже их «откатить». В результате «жук» рискует загубить весь проект.
Что можно сделать. Объяснить «жуку», что критика — это нестрашно, и попросить уважать время и силы коллег. Правда, вместо того чтобы прислушаться, «жук» скорее всего станет ещё сильнее ухищряться, лишь бы добиться своего.
«Гадёныш» — накидывает задачи, но не переносит сроки
- Вероятность исправления: нулевая.
- Угроза для проекта: чрезвычайно высокая.
Любой компании важно соблюдать сроки — чтобы не подвести руководство и заказчиков, уложиться в бюджет, а также получить запланированную прибыль.
Поэтому в индустрии разработок «гадёныш» — причина страданий №1: он любит увеличивать число задач, но при этом не продлевает сроки. У команды остаётся два варианта: либо работать быстрее, либо сверхурочно. Чаще всего — второе, хотя даже так она скорее всего не успеет.
Переработки негативно сказываются на всём проекте:
- Часть сотрудников уходит в компании с лучшими условиями.
- Оставшиеся выгорают и работают хуже.
- Вместе с этим падает качество работы в целом.
Что можно сделать. Сократить число задач, продлить сроки или переосмыслить корпоративную культуру: ставить желаемые, а не железные сроки; пересматривать требования, если нужно; не допускать переработок.
«Автор патента» — даёт такие объёмные ТЗ, что все устают читать
- Вероятность исправления: высокая.
- Угроза для проекта: низкая.
На небольших проектах ТЗ часто краткие, а подробнее их обсуждают устно. В крупных командах, особенно работающих удалённо, ТЗ расписывают детальнее, чтобы минимизировать ошибки при разработке.
Разработчики не жалуют длинные ТЗ — они скучные и не оставляют места для творчества. Тестировщики, наоборот: чем чётче прописаны требования, тем легче им создать тестовые сценарии.
Иногда детальная документация необходима. Например, если это hardware-проект с компонентами, установка которых требует чёткой спецификации.
В остальном — нет, поскольку условия, в которых существует компания, часто рискуют измениться: могут появиться новые приоритеты или пропасть техническая возможность. Предугадать всё заранее невозможно.
Объёмы документации, которую готовит «автор патента», порой не соответствуют масштабам проекта, и вносить изменения в неё трудно: какой бы мелкой ни была правка, переработать придётся весь «том».
Что можно сделать. Использовать гибкую методологию вместо каскадной и объяснить «автору», что лучше иметь возможность быстро реагировать на изменения.
«Угодник» — хочет, чтобы руководство и разработчики друг другу уступали
- Вероятность исправления: нулевая.
- Угроза для проекта: высокая.
Своей основной задачей «угодник» считает поиск компромисса между двумя сильными сторонами:
- Руководством, которое понимает, чего хочет.
- И разработчиками, которые знают, как этого добиться.
Чтобы помочь им быстрее договориться, «угоднику» нужны управленческие навыки. Их у «угодника» чаще всего нет, иначе бы его давно взяли в высшее руководство.
В результате стороны вынуждены в чём-то друг другу уступить, поэтому ни руководство, ни разработка не до конца довольны конечным продуктом.
Что можно сделать. Наладить общение руководства с разработчиками или уволить «угодника»: если стороны не находят общий язык, команда будет создавать убыточные проекты.