Должен ли менеджер по продукту уметь создавать код?
Является ли хот-дог бутербродом? Является ли универсальное конечным или бесконечным? Кто закрывает дверь после того, как водитель автобуса выходит из автобуса?
Есть некоторые вечные вопросы, на которые мы можем никогда не ответить.
В мире разработки продуктов отношения между менеджером по продукту и разработчиками открыли еще одну противоречивую поговорку: сколько должен знать руководитель проекта о коде?
Простой поиск в Google может показаться необходимостью или даже стимулом к выживанию. Вывод основан на предполагаемой взаимосвязи: если вы умеете кодировать, вы будете хорошим менеджером по продукту.
В этих размышлениях мало нюансов, потому что Интернет не отмечает частичные мнения - но в какой момент это действительно так?
Как менеджер по продукту, вы вынуждены быть универсалом. Предположение, что простое знание того, как писать код, каким-то образом поставит вас в один ряд с вашими инженерами, не только ошибочно, но и часто вызывает трения в технических решениях, которые вы считаете основанными на упрощенном понимании кода.
Прекрасно знать, как объявлять переменную в Javascript, но любое решение, принятое в отношении кода, может иметь миллионы небольших последствий, которые существуют вне этих одного или двух в скрипте.
Написание кода - не о том, что находится перед вами - есть много внутренних процессов, которые даже одна неправильная строка кода может привести к сбою.
Так что же может сделать менеджер по продукту?
Хотя менеджеру по продукту не обязательно знать, как писать код, целесообразно постоянно интересоваться контекстом кода.
Сколько нужно времени, чтобы изменить ярлык? Насколько сложным является изменение, которое включает в себя добавление совершенно нового столбца в базу данных? Какие процедуры используются для создания отчета или дополнительного электронного письма? Что, если я хочу добавить новую функциональность, которая должна быть доступна только для одного типа пользователей, но не для остальных?
Знание кода менеджером продукта становится утилитой, как только он становится способным понять, как определенные структуры влияют на системные объекты, с которыми сталкиваются пользователи.
В идеальной среде менеджер по продукту может просто написать технические спецификации, передать их, а команда инженеров предоставит график, по которому они способны выполнить проект. В большинстве сред такое отсутствие общения приводит к катастрофе.
Знание контекста технологических стеков спасет всех в процессе - если менеджер продукта узнает из развертывания, что пользователь хочет что-то, что либо невозможно, либо зависит от того, как построена система, либо будет связано с тем, чего еще нет в коде, он может распоряжаться этими знаниями для планирования и предоставления функции, а не просто для того, чтобы сказать команде, что им нужно что-то завершить, потому что пользователь посчитал это достойным. Они могут управлять сроками или создавать правильные предостережения.
Точно так же, если менеджер продукта решит в середине сборки, что он хочет добавить новую функциональность, но ничего не знает о коде, он может не только увеличить конечный срок до нескольких недель, но также может посеять недоверие среди команды разработчиков.
Суть в том, что идеальная роль менеджер продукта - давать правильные обещания.
Обещание слишком многого и не вовремя выполненная доставка создают нарушение доверия. Скромные обещания и интенсивная доставка - это неплохо, но это может создать новые ожидания для вашей команды, которые может будет труднее распутать и потенциально даже привести к сгоранию.
Владейте кодом достаточно, чтобы понять, имеет ли смысл обещание, которое вы даете. Если вы хотите узнать больше, просто поймите, что вам все равно постоянно придется обращаться к инженерам. Вы можете иметь мнение как менеджер продукта, который ценит код, но у вас, вероятно, никогда не будет окончательного мнения.
Ваша работа как менеджера по продукту заключается в том, чтобы знать, на кого опираться, и знать, когда решение имеет достаточно информации для продвижения вперед.
Вы любите код и не можете перестать думать о решениях по коду? Учтите, что, возможно, роль менеджера по продукту - это просто ступенька к чему-то другому.