Жесткая расстановка приоритетов
Расстановка приоритетов означает выполнение задач, которые наиболее важны, в первую очередь. Если вы производите продукты, это означает, что прежде всего должно делаться то, что представляет наибольшую ценность для клиента.
По моему опыту, искусство принимать решения, связанные с приоритетами, является одним из навыков, которые даются командам с особым трудом. Причина в том, что эти решения иногда бывают очень сложными. Хотя обычно это входит в базовые обязанности менеджера по продукту, я обнаружил, что в лучших командах каждый член прямо-таки маниакально расставляет приоритеты, ориентируясь на те же цели, что и его коллеги, и работая с ними в связке.
Эта статья посвящена основам расстановки приоритетов.
Основы расстановки приоритетов
Приоритизация в управлении продуктом может быть разделена на две области:
- Приоритизация между проектами — это определение того, какой проект вашей команде стоит взять в работу следующим.
- Приоритизация работы в рамках одного проекта — здесь цель заключается в том, чтобы максимально эффективно выполнить один проект.
Как мы увидим, способы, с помощью которых мы должны решать каждую из этих проблем, сильно отличаются. Объясняется это тем, что они предполагают различные решения.
При определении приоритетности проектов вы должны принять одно важное решение: во что моя команда будет вкладываться в первую очередь? Чтобы найти правильный подход к этому вопросу, представьте, что собираете паззл. Строго следуйте схеме, чтобы отыскать все кусочки, и когда они сложатся в нужной последовательности, у вас будет ответ.
Когда же вы расставляете приоритеты в рамках проекта, вам придется сотни раз принимать одно и то же решение: точно ли это необходимо? Правильный подход заключается в следующем: нужно осознать, что процесс производства продукта всегда спонтанен и выработать жесткий образ мышления, который позволит быстро принимать решения, отделяя необходимое от факультативного.
Расстановка приоритетов между проектами
Строго следуйте схеме, чтобы сложить паззл: во что моя команда будет вкладываться в первую очередь?
Ответ на этот вопрос может потребовать от вас суровости, но сам по себе процесс не особенно сложный:
- Оцените рентабельность инвестиций для каждого проекта
- Примените три ограничения: зависимости, временные рамки и состав команды.
- Соберите паззл — выстроите последовательность проектов, основываясь на окупаемости инвестиций и ограничениях
Я предполагаю, что большинство из этих идей не являются новыми для читателей, поэтому мы пройдемся по ним вскользь.
1. Оцените рентабельность инвестиций
Основой для приоритизации проектов является рентабельность (окупаемость) инвестиций (ROI); она измеряется как величина потребительской ценности, которую ваша команда создает за единицу времени. Ваша цель в том, что касается приоритизации — всегда выполнять ту работу, которая даст максимум потребительской ценности.
Чтобы выделить приоритетные проекты, вам необходимо оценить два момента:
- Объем потребительской ценности, которая будет получена;
- Количество времени, которое потребуется для завершения проекта.
Как только у вас появятся все эти данные по каждому проекту, вы можете просто сравнить их, а затем — вуаля — приоритеты как на ладони.
Разумеется, оценить воздействие и усилия сложно, но если считать, что вероятность ошибиться у вас каждый раз одинаковая, то в качестве сравнительного упражнения вычисление окупаемости — вполне законный метод приоритизации проектов.
Совет: сделали оценку усилий и воздействия? Удвойте первое значение, а второе поделите на два — и вы окажетесь гораздо ближе к реальности.
2. Примените ограничения
Поскольку в жизни все не так гладко, как в электронной таблице, существуют также ограничения, которые необходимо учитывать при расстановке приоритетов. Основные ограничения, с которыми вам придется иметь дело — это зависимости, временные рамки и состав команды.
Зависимости
Зависимость возникает, когда необходимо завершить один этап работы, чтобы продвинуться с другим этапом.
Предположим, ваша команда занимается разработкой мобильных приложений и вы хотите сделать так, чтобы на смартфонах клиенты могли производить оплату одним нажатием на кнопку. Вы вычислили, что данный проект окупится лучше всех других, и поэтому хотите внедрить эту функцию как можно скорее.
Однако для этого ваша компания должна в первую очередь иметь возможность вообще принимать платежи, над чем сейчас работает другая команда. Зависимость от других отделов означает, что вы пока ничего не можете сделать, поэтому правильным решением с точки зрения приоритизации будет отложить функцию платежа в один клик и взяться за следующий по окупаемости проект.
В процессе производства продуктов зависимости неизбежны, и чем успешнее становится продукт, тем они многочисленнее, ведь больший масштаб предполагает более сложные системы. В крупных компаниях понимание зависимостей и работа с ними часто являются наиболее важными составляющими приоритизации.
Замечу в скобках: многие думают, что у стартапов такие высокие темпы, потому что люди там работают усерднее и более амбициозны. На самом деле, разница в скорости работы происходит из-за того, что у стартапов гораздо меньше зависимостей (и клиентов, которые будут недовольны, если что-то пойдет не так), так что им проще доводить задачи до ума.
Обратные зависимости
Бывают моменты, когда у вас есть проект, который будет очень полезен для других команд в достижении их целей. В таких случаях зависимостью являетесь вы.
Если вы рассчитываете рентабельность проекта для компании в целом, а не только своего продукта — а нужно делать именно так, — то вам следует вычислить суммарную рентабельность инвестиций не только вашего проекта, но и всех зависимых от него, которые вы «разморозите», чтобы правильно расставить приоритеты для своей команды.
Всякий раз, когда я вижу, как команда работает на то, чтобы «разморозить» других, я проникаюсь к этим людям уважением — это говорит о зрелости в продуктовом мышлении. Такие команды можно назвать невоспетыми героями, теми, кто приносит продуктовой компании больше всего пользы.
Временные рамки
Временные рамки — это стандартное ограничение, которое мы все на себе испытали. Дело принимает особенно серьезный оборот, когда есть риск, что вы потратите деньги, не успев внедрить самую окупаемую функцию, и все будет кончено.
В такой ситуации правильным решением, конечно, будет выбрать самый рентабельный из проектов, которые реально закончить в эти сроки.
Состав команды
Не все команды равны, и иногда состав команды будет влиять на ваши решения относительно того, какой проект нужно взять в работу.
Возьмем для примера команду, которая чуть ли не целиком состоит из новых в компании людей — например, стайку стажеров (ничего плохого не хочу сказать о стажерах, 50% всего программного обеспечения делают именно они).
В таких ситуациях вам следует остерегаться ставить в приоритет проект, который содержит множество рисков для клиентов, даже если он имеет максимальный показатель окупаемости инвестиций. Вместо этого вам будет выгоднее приоритизировать проект, не затрагивающий никаких критически важных фрагментов кода или пользовательского опыта, потому что тогда вероятность плохого исхода уменьшается в разы.
Помогите командам новичков в первую очередь немного освоиться, успешно выкатив несколько небольших проектов. Как только у них появятся какие-то благополучно внедренные функции в анамнезе, они смогут перейти к более сложным проектам.
Приоритизация между проектами: сложите паззл целиком и приступайте к работе
Я преуменьшаю объем работ, необходимый для сбора всей информации, указанной выше, но как только все это будет у вас на руках, останется только сложить кусочки.
Расставляем приоритеты внутри проекта
Когда работа над проектом уже начата, расстановка приоритетов отличается на фундаментальном уровне. Она становится более спонтанной. Решения необходимо принимать каждый день, а на глубокий анализ каждой проблемы, какой мы проводили на стадии выбора проекта, уже не хватает времени. К тому же, в этот период команда на нервах — ведь все эти решения как-то будут сказываться на реальных клиентах, и временами может казаться, что на кону репутация каждого из задействованных в стартапе.
Единственный способ сладить со скоростью и хаотичностью процесса создания продукта — выработать жесткий подход, в рамках которого вся работа, которую осуществляет команда, будет отслеживаться и каждое действие будет ставиться под вопрос: действительно ли это необходимо?
Принять жесткий подход значит признать реальное положение вещей, осознать, что вам предстоит ежедневно делать трудный выбор, на чем сосредоточить силы. Осознать, что намерение выпустить идеальный продукт — это иллюзия, что запуск всегда требует компромиссов.
Жесткий подход вызван желанием довести продукт до запуска. Ожидания инвесторов и клиентов так давят на команду, что в итоге многим попросту становится страшно выводить продукт на рынок. Они начинают заморачиваться мелочами до такой степени, что работа практически не движется. Они теряют из виду то, что действительно имеет значение — потребительская ценность за единицу времени — и начинают гнаться за совершенством.
Покажите мне команду, у которой на стадии запуска нет багов, и я скажу: им давным-давно следовало бы выкатить продукт.
На самом деле, сама спонтанность приоритизации внутри проекта делает любую попытку определить фиксированную последовательность действий бессмысленной. Более продуктивная стратегия — помочь команде усвоить концепции разработки продукта, которые пригодятся им, чтобы жестко отвечать на вопрос: «А это точно необходимо?». Вот те из них, которые мы рассмотрим в этой статье:
- Создаем систему приоритизации
- Используем предположения о продукте, чтобы выстроить баланс между качеством и скоростью
- Временная стоимость запуска
1. Создаем систему приоритизации
Любое ПО по умолчанию — та еще головная боль. В нем и сейчас есть баги, а со временем их будет становиться только больше. Если команда, столкнувшись с новым багом, не может быстро определить, стоит ли его исправлять, то её способность сосредотачиваться на самых важных задачах будет подорвана.
Вы не можете себе позволить собирать совещание и обсуждать приоритеты каждый раз, как обнаружится очередной баг, так что оптимальным выходом будет внедрить систему, по которой можно определять, какие баги прорабатывать сразу, а на какие махнуть рукой.
В качестве примера — вот система, которая оказалась полезной для моей команды.
Ось X представляет процент пользователей, на которых повлияет баг, ось Y — насколько серьезным будет это влияние. Красная точка обозначает сам баг.
Чтобы применять эту систему, совместно с командой определите, какие уровень серьезности и процент пользователей будут считаться максимально допустимыми (в нашем случае это «пользователи не могут провести платеж» и 5% соответственно). Далее разбейте поле на зоны и договоритесь, какие действия будут предприниматься для каждой. Набор действий обязательно должен включать в себя «отправить в бэклог и не трогать».
Если вы не пожалеете на это времени и сил, ваша команда станет настоящей машиной по устранению багов, а вероятность того, что кто-то работает над незначительным багом, будет устранена на системном уровне.
2. Используем предположения о продукте, чтобы выстроить баланс между качеством и скоростью
Часто приходится слышать истории о том, какой ужасный код писали основатели стартапа на ранних этапах. Потом, когда компания достигла успеха, этот код являлся новым программистам команды в кошмарах.
Что, основатели не умели писать код? Не исключено. Но скорее всего на тот момент им просто было плевать на качество кода, так как вероятность того, что продукт окажется успешным, была крайне мала. Поэтому они делали упор на скорость и проверку идеи.
Каждая команда неминуемо в чем-то жертвует качеством, чтобы запустить продукт. Ей приходится решать, где провести черту, и по большей части это определяется тем, как расставлены приоритеты — что считается ключевым для качества продукта.
Вот хороший способ найти для себя приемлемую точку на спектре «скорость-качество»: основывайтесь на своих предположениях о продукте. Предположения о продукте — это те основополагающие мнения касательно проблемы пользователей или планируемого решения, которых вы придерживаетесь.
В качестве простого примера можно привести компанию Facebook на заре её деятельности. Предполагаемая проблема формулировалась как «люди хотят общаться друг с другом онлайн». Получив подтверждение, что эта проблема актуальна, они стали придумывать идеи для продукта, например, возможность добавлять других пользователей в друзья — иными словами, делать предположения о том, как решить поставленную проблему.
Если вы проанализируете свой продукт, то увидите, что ситуация с предположениями может быть следующей:
- Сама проблема, которую вы хотите решить, является предположением
- Решение, которое вы предлагаете для известной проблемы, является предположением
- Ни проблема, ни решение не являются предположением (вы точно знаете, что нужно делать и почему)
Если вы находитесь на левой стороне спектра, то у вас есть предположение, что пользователи сталкиваются с некоторой проблемой, но вы не знаете, насколько оно соответствует действительности. В таком случае вам лучше по максимуму срезать углы и выкатить продукт как можно быстрее, чтобы свести к минимуму риск, что вы решаете несуществующую проблему.
Напротив, если вы на правом конце спектра, то есть уверены и в актуальности проблемы, и в том, как создать правильное решение, тогда стоит обеспечить максимально возможное качество — ведь вы знаете, что продукт будет успешным, а значит нужен хороший задел на будущее.
Часто компании создают отдельные команды для экспериментов и для работы над «ядром». Как мне кажется, подобная структура организации свидетельствует о том, что у большинства команд нет понимания спектра предположений о продукте и, соотвественно, они не способны сделать однозначный выбор в пользу скорости или качества.
3. Временная стоимость запуска
ПО имеет ценность для пользователей только после запуска.
А значит, мы должны уметь определять ценность раннего запуска продукта для пользователей. Я уже говорил об этой концепции в одной из своих предыдущих статей.
Для примера: команды часто сталкиваются с непростым выбором — стоит ли внедрять функцию для 80% клиентов, при этом задерживая её для оставшихся 20%. Обычно такая ситуация складывается тогда, когда её реализация для этих 20% потребует нишевого функционала, создание которого займет в два раза больше времени (по сравнению с тем, что было реализовано для 80%).
Давайте разложим оба варианта по полочкам.
Глядя на диаграмму, мы видим, что в первом случае 80% пользователей выигрывают — они получают доступ к функционалу раньше и имеют возможность извлечь больше ценности. В противном случае им пришлось бы ждать. Тогда, получается, и гадать нечего — надо выбирать первый вариант? Не совсем. Выбор остается сложным, так как:
- 20% пользователей, которые останутся неохваченными, определенно поймут, что вы приняли решение их не поддерживать, и придут в ярость. С их точки зрения, лучше вы бы вообще ничего не делали.
- 80% пользователей, для которых функция будет подключена, на самом деле не ощутят, что что-то выиграли от того, что получили доступ к ней раньше.
Как ни парадоксально, в сумме эти два эффекта дают следующий результат: принимая решение предоставить пользователям больше ценности на определенном отрезке времени, мы разозлим больше народу, чем если бы ничего не делали. Дожили.
Тем не менее, в таких случаях я обычно советую командам проявить жесткость и запускать продукт. И вот почему:
- Если бы пользователи знали контекст и могли принять решение за нас, подавляющее большинство проголосовало бы за запуск.
- В долгосрочной перспективе, если команда будет последовательно придерживаться такой стратегии, то постепенно соотношение случаев, когда конкретный пользователь оказывается в числе 80% и 20% соответственно, выровняется. В результате, эффект накапливается, и пользователи получают больше ценности по экспоненте за заданный период, чем получили бы от компании, которая предпочитает всегда ждать, пока не сможет охватить 100% клиентской базы.
Выбор в пользу раннего запуска — одна из тех идей, которые легко осмыслить, но сложно воплотить в жизнь из-за того дискомфорта, который они вызывают. Те, кто умеет жестко расставлять приоритеты, поймут что к чему и смогут действовать в интересах пользователей.
Приоритизация внутри проекта: жесткий подход противоестественен
Рассмотренные концепты — это то, в полезности чего я имел возможность убедиться на собственном опыте. Есть и другие, а все предложенное мной можно корректировать в процессе применения.
К сожалению, большая часть компаний не испытывает желания принимать жесткий подход к расстановке приоритетов, несмотря на то, что это ключевой принцип для тех, кто создает продукты.
Например, в крупных организациях то и дело выкатываются новые функции; большая часть работников узнает об этом не раньше, чем сами пользователи. Как вы думаете, увидят ли они в таких условиях, что их коллеги сумели потратить на запуск в три раза меньше времени, чем потратили бы другие на их месте? Вряд ли. Зато они заметят, чего не хватает в конечном продукте, пусть даже все эти недочеты были пропущены командой умышленно.
И наоборот, вылизанный до блеска продукт внутри компании, как правило, хвалят. Одно плохо: понадобилось два года, чтобы довести его до запуска. Жаль, что мы не задумываемся о том, сколько пользователей от нас отвернулись, потому что отчаялись его дождаться.
Мотивируйте вашу команду становится лучше — то есть жестче.
Приоритизация — это искусство
Время — это самый ценный ресурс, которая ваша компания имеет в своем распоряжении. Если в ваши обязанности входит распределение этого времени, вам нужно по максимуму развить этот навык. Это искусство, которое можно целенаправленно постигнуть на практике.
Напоследок предлагаю вам еще один тезис на тему приоритетов: всегда существует способ достигнуть поставленной цели быстрее, чем вы запланировали.
Всегда. Вам просто нужно его найти. Вам просто нужно задать вопрос: «Как нам это сделать в два раза быстрее?» в конце совещания — и каким-то чудесным образом команда придумает выход.
Я два года занимаюсь запуском продуктов и еще не разу не сталкивался с такой ситуацией, чтобы команда не смогла придумать, как предоставить пользователю ту же ценность с меньшими временными затратами. Случаев, чтобы команда расставила приоритеты идеально, мне тоже не попадалось — что лишний раз подтверждает сказанное выше.
Если принять, что выход есть всегда, то самое разумное — активно и жестко расставлять приоритеты, неважно в работе ли уже проект или вы еще выбираете, каким из стартапов заняться.
Даже если ваш проект — это целое государство.
Автор: