Спасибо за отзыв! Согласен, можно было бы дополнительно к систематизации накопившегося опыта, провести исследование, разработать новую методологию типизации личности руководителей проектов, проверить ее работоспособность на большой выборке респондентов и опубликовать результаты. Но такую задачу себе не ставили, да и ресурсы для такой работы нужны совершенно другого масштаба.
Спасибо, иллюстрации нам самим очень понравились. Суть чайки именно в том, чтобы внезапно ворваться, навести шуму-шороху и также внезапно улететь. А было это нужно команде/проекту/клиенту — не важно:))
Все мы немного Франкенштейны:))) Так как в каждом есть понемногу от каждого типажа, главное уметь управлять этими состояниями и усиливать нужно в зависимости от состояния проекта.
Тут не столько проблемы с языком, сколько проблема обилия терминов обозначающих руководителя проектов, которые в обиходе не только в нашей компании, но и в сфере в целом: РМ, РП, менеджер, рук-ль проекта и т.д. Поэтому при написании статьи даже не обратили внимания на то, что используем разные обозначения, учтем на будущее, спасибо.
nick00, спасибо за комментарий, интересная классификация компании. Согласен, что среда сильно влияет на каждого сотрудника компании, однако в нашей статье речь именно о характеристиках управленцев, которые не зависят от среды компании, а присущи именно самим людям. В большинстве случаев в человеке сочетаются несколько типажей, какие-то ярко выражены, какие-то слабо. Культура компании должна влиять на развитие каждого сотрудника в нужном ей (бизнесу) ключе, а еще лучше, если развитие сотрудника сочетается с целями компании и самого человека. Это уже вопрос внутренней корп культуры и работы с персоналом. Вопрос супер актуальный, важный и интересный, но явно выходит за рамки нашей статьи:)
Хороший вопрос, спасибо. Суть в том, что описанные характеристики присутствуют в каждом управленце в разной степени. Лучше всего это видно со стороны, т.е. членам команд, с которыми работает данный управленец. Здорово, когда человек сам осознает и чувствует, как его воспринимает команда, еще круче, если он этим управляет и когда надо становится «Чайкой», «Мамой-уткой», «Пингатором», «Мотиватором» и т.д. За себя отвечу, что стремлюсь как раз к варианту осознания и управления состояниями. Если наберется полезный набор техник в этой части, то обязательно поделюсь этим здесь.
И в целом, вопрос нужна ли вам продуктовая команда имеет очень короткий ответ - нужна, если вы пилите продукт. То есть сам вопрос и проблематика поставлены идеологически не верно. Хотя, возможно, цель статьи как раз и была навести потенциальных заказчиком на вывод, что не нужна, а надо брать проекты в Agima? Но как по мне, так все равно не получилось.
Цель статьи помочь систематизировать свои действия при запуске продукта в разных ситуациях, очевидно вы не входите в ЦА, у вас и так все хорошо.
Второй момент, который выдает незнаение предмета с головой - это предложение поделить на две команды: дизайн и разработку. Узнаю проджекта! Но так делать нельзя, вы должны поделить задачи вертикально между командами, а не горизонтально, иначе не будет синергии кросс-функциональной команды, да и информация будет теряться.
Видимо у вас есть негативный опыт при отсутствии позитивного. У нас с коллегами по рынку есть кейсы успешных совместных запусков больших продуктов, когда как раз одна команда отвечает за интерфейс, а другая за его реализацию. Потеря информация исключается корректной орагнизацией работы команды и инструментарием, а синергия не в компаниях, а в конкретных людях. Опять же здесь сильное влияние имеет роль РМа/SMа в целом управленца, который организует работу команду и не только работу.
Очень сильно выдает незнание терминологии, например, growth team - это не команда, которая создает продукт. Growth - это команда, которая растит уже существующий продукт, который доказал свою эффективность и потребительскую ценность, но уперся в некоторый потолок развития и ему нужен новый качественный скачок, они занимаются в первую очередь оптимизацией продукта: SEO, пользовательские пути, поиск узких мест в конверсии.
Согласшусь, что growth team не про создание продукта, а про развитие, об этом также написано в статье, возможно вы не дочитали до этого места. В моем примере шла речь больше о составе команды и ее специфике, которая способна проверить гипотезы как существующего продукта с целью его развития, так и в целом гипотезу продукта: стоит его запускать или нет. Интересное утверждение про то, что growth team занимается SEO, если поделитесь опытом на каком-то кейсе, буду признателен.
Все пытался понять, почему всю статью мы вроде про продукты, но нет - про проекты. А потом увидел подпись автора - Head of PMO и все встало на свои места, проджекты в подавляющем большинстве не умеют в продукт, они не умеют в ценность, они только про сроки и бабки.
Все верно, моя роль и обязанности — организация процессов и поиск оптимальных решений. Статья как раз об этом: как подобрать команду по запуску продукта, а не как его делать.
Все верно, аутсорс заведомо меньше мотивирован сделать хорошо. Т.к. чаще всего в стартовых договоренностях между заказчиком и исполнителем оперируют только бюджетами и сроками. Если на старте добавить мотивацию, основанную на продуктовых мтериках, то можно прийти к успеху. Постараюсь написать о таких кейсах и нашей практике в след. раз.
Да, конечно можно, вот пример из относительно недавних: https://habr.com/ru/company/agima/blog/598537/ Пришел клиент без команды —> мы запустили MVP —> выстроили процессы —> передали развитие продукта сформировавшейся к этому времени внутренней команде.
Спасибо за отзыв! Согласен, можно было бы дополнительно к систематизации накопившегося опыта, провести исследование, разработать новую методологию типизации личности руководителей проектов, проверить ее работоспособность на большой выборке респондентов и опубликовать результаты. Но такую задачу себе не ставили, да и ресурсы для такой работы нужны совершенно другого масштаба.
Спасибо за отзыв, мы старались:)
Количество типов получилось таким случайно. Интересный ресурс, спасибо, прикольный тест и интерпретация результатов.
Тогда бы форварднул сюда обратную связь о себе от какой-либо из команд:)
Сочетание нескольких описанных характеристик с изменяемыми пропорциями в зависимости от характера проекта и его стадии.
Все правильно, вы верно уловили суть. Дальше путь развития управленца — управлять этими состояниями для достижения лучшего результата.
Спасибо, иллюстрации нам самим очень понравились. Суть чайки именно в том, чтобы внезапно ворваться, навести шуму-шороху и также внезапно улететь. А было это нужно команде/проекту/клиенту — не важно:))
Все мы немного Франкенштейны:))) Так как в каждом есть понемногу от каждого типажа, главное уметь управлять этими состояниями и усиливать нужно в зависимости от состояния проекта.
Возможно на ваше восприятие повлияли анимэшные иллюстрации, но мы в целом так и хотели, чтобы материал воспринимался легче.
Тут не столько проблемы с языком, сколько проблема обилия терминов обозначающих руководителя проектов, которые в обиходе не только в нашей компании, но и в сфере в целом: РМ, РП, менеджер, рук-ль проекта и т.д. Поэтому при написании статьи даже не обратили внимания на то, что используем разные обозначения, учтем на будущее, спасибо.
nick00, спасибо за комментарий, интересная классификация компании. Согласен, что среда сильно влияет на каждого сотрудника компании, однако в нашей статье речь именно о характеристиках управленцев, которые не зависят от среды компании, а присущи именно самим людям. В большинстве случаев в человеке сочетаются несколько типажей, какие-то ярко выражены, какие-то слабо. Культура компании должна влиять на развитие каждого сотрудника в нужном ей (бизнесу) ключе, а еще лучше, если развитие сотрудника сочетается с целями компании и самого человека. Это уже вопрос внутренней корп культуры и работы с персоналом. Вопрос супер актуальный, важный и интересный, но явно выходит за рамки нашей статьи:)
gleb_l, спасибо, рады, что вам понравилось, будем очень признательны, если поделитесь опытом использования бинго;)
Хороший вопрос, спасибо. Суть в том, что описанные характеристики присутствуют в каждом управленце в разной степени. Лучше всего это видно со стороны, т.е. членам команд, с которыми работает данный управленец. Здорово, когда человек сам осознает и чувствует, как его воспринимает команда, еще круче, если он этим управляет и когда надо становится «Чайкой», «Мамой-уткой», «Пингатором», «Мотиватором» и т.д.
За себя отвечу, что стремлюсь как раз к варианту осознания и управления состояниями. Если наберется полезный набор техник в этой части, то обязательно поделюсь этим здесь.
Спасибо за подробный комментарий.
Отвечу по пунктам:
Цель статьи помочь систематизировать свои действия при запуске продукта в разных ситуациях, очевидно вы не входите в ЦА, у вас и так все хорошо.
Видимо у вас есть негативный опыт при отсутствии позитивного. У нас с коллегами по рынку есть кейсы успешных совместных запусков больших продуктов, когда как раз одна команда отвечает за интерфейс, а другая за его реализацию. Потеря информация исключается корректной орагнизацией работы команды и инструментарием, а синергия не в компаниях, а в конкретных людях. Опять же здесь сильное влияние имеет роль РМа/SMа в целом управленца, который организует работу команду и не только работу.
Согласшусь, что growth team не про создание продукта, а про развитие, об этом также написано в статье, возможно вы не дочитали до этого места. В моем примере шла речь больше о составе команды и ее специфике, которая способна проверить гипотезы как существующего продукта с целью его развития, так и в целом гипотезу продукта: стоит его запускать или нет.
Интересное утверждение про то, что growth team занимается SEO, если поделитесь опытом на каком-то кейсе, буду признателен.
Все верно, моя роль и обязанности — организация процессов и поиск оптимальных решений. Статья как раз об этом: как подобрать команду по запуску продукта, а не как его делать.
Все верно, аутсорс заведомо меньше мотивирован сделать хорошо. Т.к. чаще всего в стартовых договоренностях между заказчиком и исполнителем оперируют только бюджетами и сроками.
Если на старте добавить мотивацию, основанную на продуктовых мтериках, то можно прийти к успеху. Постараюсь написать о таких кейсах и нашей практике в след. раз.
Да, конечно можно, вот пример из относительно недавних: https://habr.com/ru/company/agima/blog/598537/
Пришел клиент без команды —> мы запустили MVP —> выстроили процессы —> передали развитие продукта сформировавшейся к этому времени внутренней команде.