Комментарии 13
Управлять процессом, не понимая его, нельзя, по тем же самым причинам, по которым нельзя построить управляющую обратную связь для чёрного ящика. Из таких попыток происходят все анекдоты об “эффективных менеджерах”.
Это всё равно что заведующим отделением в больницу поставить человека без медицинского образования и опыта работы. Он не будет понимать не только что происходит, но и вообще половины слов окружающих. И либо вообще сразу всё сломает, либо будет тупо повторять слова начальства, либо попадёт в манипулятивную зависимость от своих сведущих подчинённых.
Продакт-менеджер, не умеющий программировать – не нужная ни одной из сторон прокладка между тимлидером и финансовым директором.
ты еще скажи - это как министром обороны сделать гражданского
С министром обороны особая тема. Гражданского министра обороны назначают, чтобы у него не было слишком тесных связей с генералами и в стране не случился военный переворот, а не потому, что это эффективно для военного дела. То есть, по существу, это как раз мера ограничения результативности работы организации.
Министром обороны - легко. А вот начальником Генштаба - нет.
как мне кажется здесь нужна золотая середина , вернее, что бы человек просто у мел думать , анализировать . Мой любимый пример из опыта, это Тинькофф , практически все сотрудники очень технически прокачены и не знали как работает инвестиционный бизнес и благодаря такому набору получился лучший продукт на рынке . Был и другой опыт когда хорошо знали свою проф. сферу но у команд была очень ужасная экспертиза в IT и продукт вышел , даже не знаю какое более мягкое слово подобрать .
Еще это зависит от самого продукта. Если аудитория продукта или сервиса - разработчики, то ПМ должен быть полноценным разработчиком, далеко не начального уровня, без всяких скидок. Иначе ни о какой адекватной стратегии и бизнес-целях вообще не может быть речи.
если это стартап аля убер - должен ли продакт быть из таксистов?
Этот вопрос отлично иллюстрирует мой тезис. Как и то, что далеко не каждый разработчик способен мыслить в категориях бизнеса.
Если кратко, то любые стратегические решения должны отражать понимание предметной области, в рамках которой существует продукт. Для внешнего наблюдателя, любая сложность может быть скрыта, но для внутренних процессов - всякие нюансы и тонкости чаще всего имеют определяющее значение. Люди не занимающиеся разработкой непосредственно, часто вообще не видят всех этих нюансов. Я, за свою карьеру, встречал множество случаев, когда даже высший менеджмент в продуктовой IT-компании, имел представление о внутренних процессах, как бы лучше выразится... очень мифологическое.
Почти все ПМы, с которыми я работал, так или иначе были на уровне "я когда-то давно программировал". Но был один, который захотел углубиться в современную разработку, и я где-то полгода его "натаскивал", мы даже сделали один проект вместе, где он сам кое-что реализовал. Короче, я как-то ушёл в отпуск, одному заказчику потребовалась пара специфических фишек, ну он и сделал всё сам (а нафига ж мне код ревью и тесты, когда я сам себе менеджер?). Когда я вернулся, мне было чем заняться, неделю исправляя всё, что он наваял. При этом он вёл несколько проектов, и в каждом активно "поучаствовал", после чего команда собралась и вежливо ему объяснила, что рвение его, безусловно похвально, но лучше бы ему держать свои руки на некотором расстоянии от клавиатуры и менеджерские лычки в общем случае мидла из джуна не делают.
В целом, такое решение понятно: общие технические навыки команды повышаются, что позволяет создавать более сложные продукты.
А получается в результате примерно так:
Hidden text
Например, тот же SQL поможет вам понять, как именно клиенты взаимодействуют с вашей продукцией, и учесть эти данные. То есть вы не только будете лучше подготовлены к принятию решений, но и сможете объяснить вашей команде, почему именно вы их приняли.
В маленьком стартапе - возможно. А если у вас информация из полусотни систем собирается в пару тысяч таблиц хранилища данных?
Резюмируя: в маленькой компании - да, продакту/ПМ/архитектору приходится глубоко погружаться в процесс разработки. Но если это происходит в крупной компании, то это говорит о том, что что-то там в процессах разработки пошло не так с определенного момента развития.
в крупных компаниях там может быть другая боль) под каждую элементарную функцию ищут человека , а то и несколько , а это увеличивает количество коммуникаций в команде и порой приводит к тяжелым последствиям. Но в целом да если компания большая и там продакт пм глубоко копает , то вероятно он продуктом занимается в разы меньше чем нужно .
Должен ли продакт-менеджер уметь программировать?