Comments 28
Остается пожалеть разработчика Васю. Ему на шею посадили еще одного суетолога.
Ведь Вася хочет просто писать код (с)!
Когда же наконец отстанут от Васи и дадут ему просто писать код </i>
А если серьезно, то разобраться в том, что именно, для кого и зачем разрабатывать - это тоже важная часть работы. И успех в этом деле напрямую влияет на то, будет ли код Васи приносить пользу людям.
Даниэль, спасибо, интересная статья!
Даниэль, спасибо, интересная статья!
Как говорилось некоторые время тому назад - любое кроилово ведёт к попадалову...
Напихать несколько ролей в одну должность за одну зп, конечно, выглядит экономически привлекательным, но никогда не работало хорошо ) всегда будет перекос в какую-то одну предметную область, а остальные будут страдать.
Кесарю кесарево, ещё пару тысяч лет назад в Евангелие писали)) но "эффективные менеджеры" непременно мудрее всех наших предков, не правда ли))
Напихать несколько ролей в одну должность за одну зп, конечно, выглядит экономически привлекательным, но никогда не работало хорошо ) всегда будет перекос в какую-то одну предметную область, а остальные будут страдать.
Вот смотрите... Допускаю, что для некоторых специфических продуктов было бы оправданным на роль PM искать специалиста с технической историей роста. Но ведь в статье недаром обосновывается насущная необходимость для так называемого TPM владеть чуть ли не двумя десятками технических навыков, и это если только по крупному считать, там еще подпункты есть. Причем убрать ничего нельзя, в статье специально подчеркивается, что это необходимый минимум.
Это гораздо больше похоже на примечание к служебной записке о необходимости введения новой должности. Поэтому и название новое, с большой буковкой «T”. И еще, особо оговаривается, что «в природе не может существовать Junior Technical Product Manager». Это тоже косвенно говорит о новой должности.
Потому я выше разработчику Васе и посочувствовал...
А можно и прямо автора попросить уточнить... TPM это тот же PM, просто с допнагрузкой, или их теперь двое «пээмить» будут?
TPM это тот же PM, просто с допнагрузкой, или их теперь двое «пээмить» будут?
Мне кажется, что тут нет однозначного ответа, который подошел бы ко всем ситуациям. Где-то один TPM делает все и норм. А где-то работает связка PM + TPM, где первый, например, больше занимается вопросами привлечения. А где-то вообще несколько TPM - я видел разные конфигурации:)
Да, безусловно, есть в этом что-то.
Но с другой стороны, эта роль как будто просто попадает в общий тренд "генерализации" профессий. Мало быть специалистом в одной специализации, для "успеха" надо шарить ещё и в смежных. 10-15 лет назад было нормой, что разработкой занимаются одни люди, а эксплуатацией системы другие - сейчас это скорее исключение. Такая же история и в менеджменте.
Зависит от сложности задачи.
Если человек живет дома один, он сам себе готовит, убирает и стирает и еще посуду после себя моет. Нанимать отдельно повара, уборщицу, посудомойку и бухгалтера очевидный перебор.
Купил домик побольше, завел жену и детишек 5 штук - вот и домработница лишней не будет. Но отдельный повар с бухгалтером все еще "оверкилл".
Купил особняк и живешь там всем кланом с родственниками до 4 колена - пора и повара отдельного нанимать с уборщицей и развивать "фэмили офис" в целом.
В ИТ все точно так же, есть продукты где хватит 1 ТПМ и норм потянет.
Продукт вырос - пора тимлида нанять и на него управление командой перевесить.
Еще вырос? Пора аналитика искать, чтобы часть сложных спецификаций делал тщательно. А на следующем шаге уже и чистого продакта нанимать, который только дискавери и будет заниматься.
Это понятно, только автор ссылается как раз на сложный технический продукт.
.Думаю причина скорее в "многие инженеры имеют собственный взгляд на коммуникацию и общение". Т.е. проблемам в самой коммуникации. И это добавляет особы сюр такой позиции, когда тпм, вместо выстраивания коммуникации с инженерами, забивает на их потребности и начинает сам принимать решения о том, что для них лучше. Собственно тем самым превращая процесс создания действительно нужного клиенту продукта в имитацию бурной деятельности.
У меня сейчас вот эта роль +роль аналитика и следователя. Маплюсь хорошо, но не полностью:) И целей чуть больше. Как продакт выстраиваю процессы так, чтобы TTM продуктового эксперимента был часы, а не месяц+, протаскиваю новые для компании технологии через MVP фичи, провожу семинары по ним, как могу влияю на delivery процесс, но с этим туго пока.
Есть вторая активность как и следователя. Она отчасти маппится на первую. Например, делаешь небольшой продукт, у которого TTM по мелким фичам 15 минут. С другой стороны фронт мобильного приложения, который релизится раз в 2 недели с долгим дорогим регрессом и сборкой фич от нескольких команд. Челендж - выпускать небольшие фичи связанные с фронтом за часы вместо месяца.
Удалено
Спасибо за статью. Было бы здорово осветить в статье или в комментах вопрос как попасть на эту позицию и стоит ли (на хх.ру по TPM всего два десятка стоящих позиций на всю РФ в отличие от тысяч вакансий условных разрабов или ПМ). Т.е. мне кажется, что проще готовому продакту пообщаться пару часов с разрабами, чтобы понять по верхам технические детали продукта или взять пару курсов по теме. А перейти из разрабов в TPM очень сложно, т.к. это переход с нуля в совершенно другую область (в продакты) и причем сразу на сеньор позицию (junior TPM не бывает) - такое hrы не пропустят еще на этапе скрининга CV.
Я тут мимокрокодил, как бывший разраб и ныне ТПМ скажу, что взять и зайти на вакансию ТПМ не имея до этого соответственного опыта очень рискованно и тяжко. Я не про формальный опыт на должности, а про опыт выполнения такой роли.
Сам собеседую людей с рынка на позиции ТПМ и часто встречаю кейс, когда человек, формально разраб/СА/продакт или кто-то еще, по описанию работы и набору обязанностей работает как ТПМ, просто должность называется иначе, а ответственность несет как полноценный тех продакт на своем текущем месте.
Итого: из пустоты взять и шагнуть в позицию ТПМ плохая идея, но постепенно клониться в эту роль набирая себе подходящие ответственности по факту и потом уже формально перекрашивая должность - рабочая схема. Потому профессия и формализовалась в отдельное название и должность, потому что роль уже существовала и большое количество людей ее выполняли находясь на других должностях. Как ранее DevOps появились именно потому, что уже был ряд людей, которые будучи разрабами уэе выполняли часть роли Ops, и хотели именно таким комбо и заниматься полноценнно, а не "просто код писать".
Привет, я занимаюсь процессами найма и роста TPM, попробую прокомментировать.
Действительно, просто перейти на продуктовую позицию скорее всего не получится. Как я вижу, самые рабочие методы такие:
Продолжаете работать в текущей позиции, и по договорённости с текущим продактом и ресурсным руководителем постепенно берете часть продуктовых задач на себя для наработки опыта. Обычно проблем с "поделиться задачами" не бывает, потому что продуктовых задач всегда полно
Pet-проект. Прекрасен тем, что можно пробовать себя в какой угодно роли без рисков
Вызваться исполнять роль продакта, если она требуется в текущей команде. Например, если нужно создать новый продукт
Каждый из этих способов должен сопровождаться изучением продуктовых навыков. Я видела примеры, где, например, разработчик или тимлид были назначены на роль продакта, но не занимались самообразованием в области управления продуктом - выглядит всё это грустно. А вместе с образованием выходит очень даже неплохо! Может, Даниэль расскажет как-нибудь про свой путь из SRE в TPM.
По поводу "проще готовому продакту пообщаться пару часов с разрабами, чтобы понять..." и "перейти из разрабов в TPM очень сложно" - не согласна. На практике вижу, что приобретение знаний и навыков IT гораздо более трудоёмко по сравнению с приобретением компетенций продакта. Можете ли представить, что продакт k8s - это обычный продакт без бэкграунда в IT, который просто пару часов пообщался с разрабами?)
Даниэль, статья отличная, спасибо!
Узнала себя, хорошая статья) Привет, коллега!
Technical Product Manager — кто это, а главное, зачем?