IT-инфраструктура для бизнеса и творчества

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

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

Фильм «Несносные боссы»

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

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

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

«Диктатор» — не приемлет ничьих идей, кроме своих

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

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

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

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

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

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

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

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

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

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

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

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

«Правая рука» — передаёт требования руководства, но сам ничем не руководит

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

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

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

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

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

«Абстракционист» — сам не знает, чего хочет, а потом винит других

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

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

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

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

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

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

«Хитрый жук» — внедряет масштабные преобразования под видом маленьких правок

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

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

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

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

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

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

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

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

«Гадёныш» — накидывает задачи, но не переносит сроки

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

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

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

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

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

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

«Автор патента» — даёт такие объёмные ТЗ, что все устают читать

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

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

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

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

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

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

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

«Угодник» — хочет, чтобы руководство и разработчики друг другу уступали

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

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

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

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

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

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

{ "author_name": "Полина Лааксо", "author_type": "editor", "tags": ["\u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u043a\u0430","\u043f\u0440\u043e\u0434\u0430\u043a\u0442\u043c\u0435\u043d\u0435\u0434\u0436\u043c\u0435\u043d\u0442"], "comments": 29, "likes": 28, "favorites": 117, "is_advertisement": false, "subsite_label": "dev", "id": 274758, "is_wide": true, "is_ugc": false, "date": "Thu, 29 Jul 2021 12:32:13 +0300", "is_special": false }
(function () { let cdnUrl = `https://specialsf378ef5-a.akamaihd.net/SelectelBranding/images/` let previousArticleNumber = null let currentArticleNumber = 0 let platform = 'Desktop' let articles = [ // { // name: 'camera', // url: `${cdnUrl}CameraCat`, // text: 'умную камеру для\u00A0наблюдения за\u00A0котиками', // link: '1', // }, { name: 'chill', url: `${cdnUrl}ChillCat`, text: 'трекер, который подскажет, когда пора отдохнуть', link: 'https://vc.ru/promo/288561-eye-tracker', }, // { // name: 'cloud', // url: `${cdnUrl}CloudCat`, // text: 'котика: даёшь ему «пять», а\u00A0он делает бэкап в облако', // link: '3', // } ] let buttonCycle = document.querySelector('.button--cycle') let textField = document.querySelector('.selectel-footer-subtitle') let imageAgent = document.querySelector('.image--agent') let banner = document.querySelector('.selectel-footer') buttonCycle.addEventListener('click', cycleClick) let media = window.matchMedia("(max-width: 570px)") media.addEventListener('change', matchMedia) function matchMedia() { if (media.matches) { platform = 'Mobile' } else { platform = 'Desktop' } update() } matchMedia() function cycleClick(event) { if (event) { event.preventDefault() event.stopPropagation() } window.open('https://vc.ru/tag/selectelDIY', '_blank') //cycle(event) } function cycle(event) { // incrementArticleNumber() textField.innerHTML = generatedText() imageAgent.src = articles[currentArticleNumber].url + platform + '.svg?5' imageAgent.setAttribute("class", "") imageAgent.classList.add('image--agent', articles[currentArticleNumber].name) banner.href = articles[currentArticleNumber].link } function update() { banner.href = articles[currentArticleNumber].link imageAgent.src = articles[currentArticleNumber].url + platform + '.svg?5' textField.innerHTML = generatedText() } function incrementArticleNumber() { previousArticleNumber = currentArticleNumber if (currentArticleNumber >= articles.length - 1) { currentArticleNumber = 0 } else { currentArticleNumber++ } } function generatedText() { let defaultText if (platform === 'Desktop') { defaultText = `Мы тут собрали %text%. Хотите почитать?` } else { defaultText = `Мы тут собрали %text%.` } return defaultText.replace('%text%', articles[currentArticleNumber].text) } function getRandom(min, max) { min = Math.ceil(min) max = Math.floor(max) return Math.floor(Math.random() * (max - min + 1)) + min } (function create() { currentArticleNumber = getRandom(0, articles.length - 1) cycle() let page = document.querySelector('.page--entry') if (page) { function insertAfter() { let parents = page.querySelectorAll('[data-id="7"]') let referenceNode = parents[0] referenceNode.parentNode.insertBefore(banner, referenceNode.nextSibling); loaded() } setTimeout(() => insertAfter(), 0) } }()) function loaded() { banner.classList.add('loaded') } loadImages([ `${cdnUrl}CameraCatDesktop.svg`, `${cdnUrl}ChillCatDesktop.svg`, `${cdnUrl}CloudCatDesktop.svg`, `${cdnUrl}CameraCatMobile.svg`, `${cdnUrl}ChillCatMobile.svg`, `${cdnUrl}CloudCatMobile.svg`, ]) function loadImages(urls) { return Promise.all(urls.map(function (url) { return new Promise(function (resolve) { var img = document.createElement('img'); img.onload = resolve; img.onerror = resolve; img.src = url; }); })); } }())
0
29 комментариев
Популярные
По порядку
Написать комментарий...

Диктатор

13

А это вообще классика почти для всех руководящих должностей. Особенно, если эти люди не совсем понимают, как устроен процесс изнутри (да, такие тоже бывают)

1

Вспомнилась картинка ) 

11

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

Мистер Грин вообще вкурсе сколько всего видов продакта есть?

8

👍🏻

0

Когда же этот хайп с продакт-менеджерами кончится

3

И этот хайп с agile и коучами. Честно говоря, надоело уже — только мешают работать. Если с обязательным наличием ТОЛКОВОГО продакт-менеджера я еще могу согласиться, то все эти дейли, эджайлы, груминги, коучи не нужны — лишний слой абстракции, замедляющий работу и вносящий в работу команды хаос.

3

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

7

В идеале, чтобы на них присутствовали ТОЛЬКО те люди, которые компетентны принять решение и не отвлекать всю остальную команду. Зачем мне слушать информацию о проблемах, которые ко мне никак не относятся ? Если есть проблема, не надо всех отвлекать, нужно идти (пешком, в мессенджере или по почте) к ответственному по этой проблеме: не выдают сервера — идти к админам, не ясные формулировки в документации — идти к тем, кто составлял ее. Если непонятно, к кому обращаться, идти к своему тимлиду. Один 15-минутный дейли — это 15 минут (и это в лучшем случае! в идеальной картине мира!) + еще 15 минут возвращения в контекст своей задачи + 15 минут ожидания дейли, когда толком уже не сосредоточишься на своей задаче. К дейли прибавляются планирование, ретро и груминги — это уже как минимум минус полдня из 2-х недель. Хотя постановкой моих задач и корректировкой моих планов мне эффективнее было бы заниматься лично с тим-лидом и с немногими причастными к этим задачам. Самый ад — когда все эти agile-ритуалы разбросаны по спринту, фрагментируя ценное рабочее время и усложняя работу над задачами, требующими длительной концентрации внимания. К этим agile-ритуалам могут присоединяться участия в собеседованиях, без которых действительно не обойтись, если я пока еще единственный или ведущий, например, мобильный разработчик, и набираю с тим-лидом в нашу команду новых разработчиков. К agile-ритуалам могут прибавляться и совещания с коллегами, когда необходимо совместно решить реальную проблему и когда эффективнее проговорить все голосом. Работал в командах, где прекрасно обходились без agile-ритуалов. Если нужны были общие совещания, ну были планерки раз в неделю и все. Этого достаточно, чтобы направлять команду и каждому видеть общий вектор развития. ред.

0

И? Вот эти 45 сэкономленных минут - насколько вы в них были эффективны? На предыдущей работе? На позапрошлой?

Я не отстаиваю ничью позицию и не спорю. Но давайте честно?

0

А ты чего переживаешь?! Ответ: не кончится

0

Интересная статья для самоанализа. Спасибо.

4

Был на практике случай, попался Хитрый жук, Автор патента, Гадёныш и Правая рука в одном лице. Бодались мы с ним долго, но он, с*ка, победил и команда из 4 ведущих разработчиков уволилась. С точки зрения руководства - идеальный менеджер.

2

Не согласен с тем, что "видение – не навык". Если вовлечено интересоваться отраслью (и соседними отраслями) и тенденциями рынка, накладывая их на регулярные исследования, то видение начнет магическим образом проявляться..))

2

мне тоже кажется, что этому можно и нужно обучаться в процессе работы. это не врожденный дар

0

Описано очень узко. На практике может сочитаться много типов, зависит от ситуации)

1

собственно, как начальники отделов, директора и обычные работники могут совмещать разные типы) по идее, негативных и малополезных персонажей должен отфильтровывать сильный hr-отдел, но и там не без проблем, и всё реально зависит от конкретно взятой фирмы для разбора 🤷‍♂️

0

Откуда эта инфа? Что за частный бред?

1

В каждой строке чувствую боль разработчика :)

0

Обратная связь)

2

Ну здесь, как говорится, точка зрения зависит от точки сидения. Разве когда-нибудь обычный работник бывает доволен тем, кто им руководит?) 

1

Не поняла, кто должен принимать меры, описанные в соответствующем абзаце.

0

как вариант, тимлиды или руководители проекта :)

0

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

3

Да нет, здравое зерно есть. Таких посредников можно исключать. И я исключал. Но основной массе IT такая политика и ролевые игры нафиг не нужны, конечно (своих задач хватает).
Это будет делать только человек, которому не безразлично будущее компании. И который уже накопил достаточно лояльности/авторитета для подобных действий. И было бы прекрасно, если HR хоть немного фильтровал подобных неадекватов, но увы и ах.

0

В роли кого вы исключали «посредника»? Какие у вас были полномочия, чтобы исключать менеджера продукта? Особенно если в компании этот менеджер предусмотрен.

0

В роли руководителя (от отдела до департамента IT). Тимлиду само собой подобное действо смерти подобно.

1

Комментарий удален

Обозвал менеджера продукта земляным червяком и доволен)) гуру, сразу видно)

0

Статья про руководителей проектов. Архетипы - то, что делает любой менеджер.

0
Читать все 29 комментариев
Новый тренд в UI: обзор неоморфного дизайна
Как облегчить планирование в редакции: опыт «Лайфхакера»
7 друзей планеты: как экологические стартапы спасают природу и зарабатывают деньги

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

Пять брендов, которые выпускают одежду, аксессуары и декор из мусора

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

Еду к деду
Как использовать облачные технологии для роста бизнеса в 2022 году: расскажем на Yandex Scale

А ещё представим новые продукты.

Банк России утвердил порядок тестирования неквалифицированных инвесторов

Банк России утвердил в новой редакции стандарт, который устанавливает порядок тестирования неквалифицированных инвесторов для допуска к совершению сделок со сложными финансовыми инструментами.

Задания от самого титулованного программиста в мире и 3,72 млн призовых: каким был VK Cup в этом году

Зачем в VK Cup ежегодно участвуют тысячи специалистов из разных стран и чем запомнится турнир в этом году? Отвечаем на главные вопросы.

Подмосковное УФАС уличило «Магнит» и «Пятёрочку» в завышении цен на некоторые продукты Статьи редакции

Если ритейлеры не снизят цены, им грозит уголовное дело.

Кто такой конкурентный разведчик, чем он занимается и сколько зарабатывает Статьи редакции

Рассказ интернет-разведчика и руководителя компании «Интернет-Розыск» Игоря Бедерова — о том, как он раскрыл секретное подразделение МВД, искал киберпреступников и начал разрабатывать ПО для поиска информации в интернете.

Игорь Бедеров «Интернет-Розыск»
МТС перебил вводной кабель в квартиру, когда проводил интернет

Компания обесточила квартиру на несколько дней и отказывается компенсировать ремонт

Без сложных слов и длинных предложений: чем проще говорит директор, тем выше доходность акций компании Статьи редакции

Японская компания Nomura Holdings проанализировала речи руководителей 1000 фирм с самыми рентабельными акциями в США. Акции компаний, чьи директора использовали запутанные формулировки, приносили инвесторам в полтора раза меньше доходов, рассказало Bloomberg.

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

Элизабет Холмс
основательница Theranos
null