Как я выиграл оценочную игру (и вы тоже можете)

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

Но не все функции одинаковы, и не все согласны с приоритетом. Поэтому вы обращаетесь к команде разработчиков, чтобы они помогли вам отсортировать функции в зависимости от усилий и воздействия. Так начинается кошмар.

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

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

Как менеджер по продукту, столкнувшийся с менеджером по разработке, вы находитесь в крайне невыгодном положении. Фундаментальная проблема - это дисбаланс мощности - ваша команда разработчиков будет писать код.

Скорее всего, вас будут обвинять в задержках. И они это знают.

Почему оценки разработчиков такие жесткие?

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

Большинство советов, которые вы получите по поводу оценок разработчиков, - это убедиться, что: 1) вы знаете, что вы должны построить, 2) выявите риски, которые могут сделать эти оценки недействительными, 3) добавить буфер для решения проблем, которые могут возникнуть. вверх.

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

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

Помните закон Мерфи:

«Все, что может пойти не так, пойдет не так» - Мерфи

Инфляция как переговоры

Я не говорю, что так поступают все, но это редкий разработчик, который не использует оценки, чтобы повлиять на направление проекта.

Это просто: если вы не хотите этого делать, скажите, что это огромное количество.

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

  • Представьте свои (гораздо меньшие) оценки
  • Получите второе мнение от другой команды разработчиков
  • Задавайте все более педантичные вопросы об усилиях
  • Попытайтесь договориться о некоторых функциональных возможностях, выходящих за рамки (например, «Что делать, если не нужно сортировать?»)
  • Повторите: "Вы уверены, что это действительно так много работы?" снова и снова

Конечно, ничего из этого не работает, кроме как усиливать напряженность и еще больше откладывать планирование.

Моя любимая правдивая история оценки

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

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

Никто не мог этого понять. На каждой встрече он дрался с людьми.

Я видел это раньше, поэтому попробовал что-то другое. Я сел с ним и сказал:

«Послушайте, вы почти уверены, что этот проект действительно рискованный. Я не имею права спорить с вами. Но я хочу помочь ».

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

«Я хочу найти для вас кое-что из неизвестного. Мне просто нужно знать, что я ищу. Если вы хотите составить список рисков, я проведу любое исследование, чтобы получить ответы, которые помогут обосновать оценки. Иметь дело?"

Ему понравилась эта идея. Он вернулся к клавиатуре и принялся за работу. И я продолжил работать над другими вещами.

Через несколько дней, меньше чем через неделю, он остановил меня в коридоре.

«Готово», - сказал он мне.

Я был в восторге. «Хорошо, я сразу займусь этим».

«Нет, ты не понимаешь. Весь проект готов. Это было банально ».

Что? Это был проект, у которого были все пугающие риски и дикие оценки. 3 месяца работы. Я изо всех сил старался сдержать замешательство.

«Оказывается, я ошибался. Как только я начал записывать риски, я понял это ».

И все они благополучно отправились.

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

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

Ваша задача как менеджера по продукту - развеять эти опасения.

Как к этому подойти?

  • Абсолютно четкие приоритеты - ваша самая важная работа
  • Не нападайте и не спрашивайте: "Почему он такой большой?" поскольку это ставит команду в оборону
  • Задавайте вопросы о неизвестном, рисках, неопределенностях
  • Иди, найди им ответы!

Приоритеты должны быть задокументированы, записаны в хорошо известном месте и обновлены. Они должны иметь смысл и основываться на какой-то логике и данных, а не только на мнениях.

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

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

Таким образом, выигрывают все.