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