Получение результатов от инженеров
Чрезвычайно важно, чтобы колеса крутились, а поезда ходили, поэтому дела, родственные делам скрам-мастера и владельца продукта, в работе менеджера продукта носят тактический характер и основаны на конкретных задачах. Усердия и опыта менеджера обычно достаточно, чтобы вести спринты и управлять списком задач. Но это не относится к его навыкам общения, связанным с управлением людьми и преодолением культурных различий в мультидисциплинарных командах, где люди с разной подготовкой и склонностями часто говорят на совершенно различных «бизнес-диалектах».
Шаг первый – проявить уважение к разработчикам. Уважать – не означает заискивать перед ними или принимать ответ «нет» без объяснений. Но это может означать, что нужно отбросить неудачную позицию некоторых UX-специалистов, которые считают, что они, и только они заботятся о пользователе, об их опыте взаимодействия с продуктом, о качестве, и думают, что разработчики – это кучка бесчувственных автоматов, которые хотят только настрочить код, и дело с концом.
Ключевой способ проявить уважение – выучить их профессиональный жаргон.
Слово «дизайн» означает нечто иное, когда разработчики говорят о своем «техническом дизайне» (техническом задании, документе, отражающем, как они планируют реализовать требования к продукту). Если вы прочитаете им лекцию о том, что они неправильно используют слово «дизайн», и затем на десять минут погрузитесь в историю дизайна и человеческого фактора, то никто от этого не выиграет.
Ваша способность исследовать и понимать потребности и мотивации людей – это те UX-навыки, которые вы можете и должны использовать. Опыт, который вы формируете в этом контексте, – это не программный продукт, а работа с вами.
Если подойти к этому со смирением, то вы обнаружите, что куда лучше станете понимать ваших инженеров и описывать свои цели и потребности в терминах, которые они понимают и ценят.
Для этого потребуется время, много слушания и сознательных усилий для изучения и понимания «народных обычаев» людей, которые отличаются от вас. Конечно, вам будет проще, если вы уже являетесь кем-то вроде ботаника, гика или технофила (и давайте будем честны, скорее всего, так оно и есть). Погрузитесь в эту тему – и вы окажетесь уже на полпути к цели.
ИСТОРИИ ИЗ ЖИЗНИ
Кен Нортон, консультант по продуктам, наставник и преподаватель, много лет проработавший в Google Ventures, сформулировал обслуживающую роль менеджера продукта в форме мантры «принеси пончики»:
«Я верю, что лучшие менеджеры продукта готовы сделать все возможное, чтобы помочь своим командам добиться успеха. Здесь важно осознать, что менеджеры часто должны выполнять работу, которую в противном случае не сделает никто. По определению это может быть грязная, невеселая работа: очистка очереди ошибок, организация репозитория документов, написание ответа на письма службы поддержки клиентов.
Ни одна работа не должна считаться ниже уровня менеджера продукта. Менеджеры – скорее скромные слуги, чем „генеральные директора продукта“. Они ставят свою команду на первое место, делают то, что должно быть сделано, и проявляют такое поведение каждый день.
В 2015 году я готовился к выступлению в бизнес-школе Хааса в Беркли с докладом о продуктовом менеджменте. Я искал риторический прием, чтобы донести это, и я остановился на „принеси пончики“.
Если менеджер не принесет для команды пончики на обед, то кто еще это сделает? Я не знаю, почему я выбрал пончики. В то время моя соревновательная карьера велосипедиста все еще процветала и бублики больше соответствовали моему стилю. Но это были пончики, и концепция прижилась.
Если менеджер продукта помнит, что его роль – сделать все возможное для успешной работы команды, то он на верном пути».
Помимо проявления уважения, скромности и готовности освоить термины разработчиков, менеджер продукта, если он хочет иметь хоть какую-то надежду на то, чтобы привести команду к успешному результату, должен еще заслужить уважение своих разработчиков. Для менеджеров, у которых нет инженерного образования, которые не пишут код и не позиционируются как «технические менеджеры продукта», планка завоевания уважения может стоять высоко.
Поэтому новоиспеченный менеджер продукта, пришедший из UX-дизайна, должен разметить границы некоторой своей технической полноценности, если он не хочет, чтобы его списали как дизайнера-выскочку, который «совсем не разбирается» в технологии или программировании. То же самое всегда приходилось делать бизнес-ориентированным менеджерам.
Но как еще можно доказать эту полноценность, если не возвращаться в школу и не становиться инженером самому? Вы не добьетесь уважения, притворяясь тем, кем вы не являетесь, или кивая в ответ, как будто вы понимаете технический вопрос. И вы никуда не продвинетесь, если будете бояться показаться глупым, задавая вопросы.
Однако вы будете выглядеть знающим, если зададите умные вопросы. А что такое умные вопросы? Когда вы сомневаетесь, то это все те вопросы, которые у вас действительно возникли. Если вам непонятны термины, попросите прояснить их. Покажите, что вы понимаете их возможное значение, но хотите использовать слова более точно. Чем больше вы будете вовлечены в такое общение, тем больше будут укрепляться и углубляться ваши ментальные представления о технической архитектуре, логике, методах, стилях кодирования, сильных сторонах и ограничениях библиотек, а также понимание о способностях вашей команды.
Когда придет время попросить о чем-то новом или предложить идею, у вас получится подогнать свои запросы под ограничения и реалии технического стека, в котором вы работаете, и избежать неловких моментов, спросив, например, можно ли создать для вас летающего пони.
Оценка и согласование
Возможно, вы помните, что во время планирования спринта проводится оценка задач и что роль менеджера продукта предполагает его постоянное участие в обсуждениях этого вопроса с членами команды. Но встреча не должна напоминать торг на базаре.
Менеджер продукта может задать тон тому, как разные мнения и приоритеты будут озвучиваться и взвешиваться. К тому же менеджер должен понимать, что именно вдохновляет разработчиков и что их пугает. Это поможет читать между строк, когда они сопротивляются заданиям, которые вы хотели им дать, или когда их оценка потраченных на задачу усилий вас несколько удивляет.
Оценка – это отдельная тема, чреватая разочарованиями. Сделать оценку по-настоящему хорошо практически невозможно, но это повседневная задача вашей работы, и она становится выполнимой, как только каждый начнет относиться к ней максимально ответственно и разбираться в том, куда вложить время и ресурсы.
И помните, что вы им не начальник. (По крайней мере, в большинстве случаев это так.) Ваша работа – вдохновлять и убеждать, а не командовать.
ИСТОРИИ ИЗ ЖИЗНИ
Однажды со мной работали два инженера, которых я называл про себя «Джек Спрат и его жена»[31], потому что их склонности были очень взаимодополняющими. Одна инженер, назовем ее Шерил, во всем видела риски и раздувала оценки из расчета на то, что дела непременно пойдут не так, как задумано, неизбежно начнутся препятствия и тому подобное, как подсказывал ей многолетний опыт. Другой инженер, назовем его Эдгар, всегда представлял себе прямой путь, с радостью соглашался на всё и был склонен занижать свое время на задачи в четыре раза.
Находясь между ними, я мог разобраться, какие временны́е затраты могут быть реалистичными, и, проводя обсуждение между нами троими, я помогал смягчать их явные перекосы, уравновешивая их аргументами. Не то чтобы они уговаривали друг друга принять другой стиль, заметьте, но мы смогли сгладить некоторые углы.
Среди разработчиков есть старая шутка, которую могут вспомнить фанаты сериала «Звездный путь». Капитан звонил в машинное отделение и спрашивал, сколько потребуется времени, чтобы устранить повреждение. Главный инженер, Скотти, оценивал работу на восемь часов, но ему отвечали: «У тебя есть только два!» – и каким-то образом ему всегда удавалось достичь этих невыполнимых целей.
В детстве я думал, что это было специальным испытанием для того, кто хочет стать прародителем изобретений или героическим руководителем, но, оглядываясь назад, я понимаю, что Скотти просто раздувал свои оценки.
ДЕНЬ ИЗ ЖИЗНИ МЕНЕДЖЕРА ПРОДУКТА, РАБОТАЮЩЕГО В АГЕНТСТВЕ
Ана Хиральдо-Винглер, менеджер продукта в компании Coforma
Я проверяю Slack, когда я просыпаюсь. Подхожу к своему компьютеру за 15–30 минут до первого стендапа и, как только я сажусь, пишу заметки на день в приложении Notes перед началом работы.
Я перехожу к моим заметкам за предыдущий день и копирую все пункты, которые еще не сделаны. Затем переношу их на сегодня.
Для клиентов мы делаем работу, которая отличается от управления продуктом в стартапе. Конкретный клиент, с которым мы работаем, – это правительство. И продукт, над которым работаю я, – замена программного обеспечения 20-летней давности. Так что наши условия в некотором смысле разные.
Это не похоже на работу по созданию ранее не существовавшего продукта.
Как пройдет день на самом деле, зависит от того, в какой точке спринта мы находимся. Первое, о чем я думаю, – это какие ритуалы только что состоялись или планируются. Если я знаю, что через два дня, в пятницу, мы будем проводить проверку по спринту, то в среду я буду готовить доску для ведения встречи.
Я подготовлю доску, чтобы быть уверенной, что все тикеты актуальны, находятся в правильном списке и так далее.