Важные подходы к планированию ИТ-проектов
1. Планировать сроки должны программисты, а не менеджеры.
Частая ошибка, когда руководитель проекта, не понимающий должным образом объем и специфику задач, устанавливает сроки проекта не в соответствии с опытом, возможностями и компетенциями команды, а опираясь на собственные представления, желания или запросы клиента. Расхождения запланированных и реальных сроков составляет 40-80%.
2. Необходимо заранее определять примерные сроки сдачи всего проекта и реальное время решения задачи.
Игнорирование процедуры планирования приводит к расхлябанности, низкой мотивации разработчиков в предшествующие дедлайну периоды, к непониманию командой, что делать, куда двигаться и что нужно получить в итоге. В объединениях, где примерные сроки сдачи проекта не определяются, желательно задуматься о том, что подобный хаос до добра не доведет.
3. Проект разбивайте на мелкие этапы с четкими целями и обязательным обсуждением результатов.
Применение принципа необходимо для противодействия закону Паркинсона, определяющему, что общий объём работы всегда будет увеличиваться, чтобы заполнить всё выделенное на работу время. Следуя совету, можно избежать желания усердно трудиться лишь незадолго до срока сдачи проекта.
4. Члены команды должны максимально плотно взаимодействовать друг с другом.
Прежде всего повышается сплоченность коллектива и стимулируется оказание взаимопомощи. При недостаточном общении между членами объединения отсутствует «командный дух», обеспечивающий слаженную работу. Совместная продуктивная деятельность удовлетворяет социальные потребности человека в ощущении значимости выполняемого труда.
5. Включайте резерв времени для покрытия форс-мажора, новых требований заказчика, отпусков и праздников, на интеграцию и тестирование.
На первоначальном этапе планирования нельзя предусмотреть все ситуации. Поэтому нужно зарезервировать время про запас, чтобы команде не пришлось торопиться и, как следствие, совершать ошибки. Не стоит игнорировать необходимость отладки и доведения ПО до уровня стабильной работы и приемлемого количества багов.
6. Нельзя торопиться, нарушать план и уменьшать время разработки ПО.
Частая ошибка менеджеров, думающих, что программисты смогут потянуть любые сроки. Завышенный темп приводит к увеличению количества ошибок в коде. На отладку и исправление в будущем потребуется значительно больше времени, чем получится сэкономить подобным образом.
7. Расставляйте приоритеты задачам и концентрируйтесь на главном.
Старайтесь в первую очередь реализовывать наиболее важный функционал. Имейте ввиду, что какими-то фичами в процессе разработки придется пожертвовать, равно как и реализацией части идей. А расставить приоритеты возможно исключительно через общение и обмен мнениями.
1. Планировать сроки должны программисты, а не менеджеры.
Частая ошибка, когда руководитель проекта, не понимающий должным образом объем и специфику задач, устанавливает сроки проекта не в соответствии с опытом, возможностями и компетенциями команды, а опираясь на собственные представления, желания или запросы клиента. Расхождения запланированных и реальных сроков составляет 40-80%.
2. Необходимо заранее определять примерные сроки сдачи всего проекта и реальное время решения задачи.
Игнорирование процедуры планирования приводит к расхлябанности, низкой мотивации разработчиков в предшествующие дедлайну периоды, к непониманию командой, что делать, куда двигаться и что нужно получить в итоге. В объединениях, где примерные сроки сдачи проекта не определяются, желательно задуматься о том, что подобный хаос до добра не доведет.
3. Проект разбивайте на мелкие этапы с четкими целями и обязательным обсуждением результатов.
Применение принципа необходимо для противодействия закону Паркинсона, определяющему, что общий объём работы всегда будет увеличиваться, чтобы заполнить всё выделенное на работу время. Следуя совету, можно избежать желания усердно трудиться лишь незадолго до срока сдачи проекта.
4. Члены команды должны максимально плотно взаимодействовать друг с другом.
Прежде всего повышается сплоченность коллектива и стимулируется оказание взаимопомощи. При недостаточном общении между членами объединения отсутствует «командный дух», обеспечивающий слаженную работу. Совместная продуктивная деятельность удовлетворяет социальные потребности человека в ощущении значимости выполняемого труда.
5. Включайте резерв времени для покрытия форс-мажора, новых требований заказчика, отпусков и праздников, на интеграцию и тестирование.
На первоначальном этапе планирования нельзя предусмотреть все ситуации. Поэтому нужно зарезервировать время про запас, чтобы команде не пришлось торопиться и, как следствие, совершать ошибки. Не стоит игнорировать необходимость отладки и доведения ПО до уровня стабильной работы и приемлемого количества багов.
6. Нельзя торопиться, нарушать план и уменьшать время разработки ПО.
Частая ошибка менеджеров, думающих, что программисты смогут потянуть любые сроки. Завышенный темп приводит к увеличению количества ошибок в коде. На отладку и исправление в будущем потребуется значительно больше времени, чем получится сэкономить подобным образом.
7. Расставляйте приоритеты задачам и концентрируйтесь на главном.
Старайтесь в первую очередь реализовывать наиболее важный функционал. Имейте ввиду, что какими-то фичами в процессе разработки придется пожертвовать, равно как и реализацией части идей. А расставить приоритеты возможно исключительно через общение и обмен мнениями.
👍1
Вредные советы для продактов и их решения
1. Когда хочется общаться, а не работать — используйте фокус-группы из своих друзей и знакомых. Не бойтесь: Groupthink (по-русски: стадное мышление) с вами просто не может случиться.
Нет! : если у вас нет возможности проводить полноценное интервью, работать с фокус-группой можно. Однако не стоит набирать её из своих друзей. Лучше всего пригласить независимых представителей потенциальной аудитории. Приглашайте разных людей, ведь пользователи тоже будут отличаться. Так у вас получится собрать максимум информации.
2. Не воспринимайте фидбек серьёзно. Обидеть менеджера по продукту может каждый. Позже, когда продукт будет уже запущен, клиент увидит, что всё работает. А результат — именно то, что он на самом деле хотел.
Нет!: Воспринимайте фидбек серьёзно. Даже если он кажется вам глупым, подобное может написать технически неграмотный пользователь в дальнейшем. Конечно, если отзыв неадекватный, это следует обсудить с заказчиком. Однако постарайтесь найти причину такого фидбека в любом случае. Определите истинную проблему клиента.
3. Тестируйте все проблемы на полноценном MVP. Только полная реализация в железе и коде, только хардкор. Ручной режим не покажет всех ошибок, а вы ведь проводите тесты наверняка.
Нет!: тестируйте мелкие добавления вручную. Это сэкономит время и силы команды намного больше, чем создание MVP каждый раз. Нужно только найти в команду нормального тестировщика, тогда проблем не возникнет.
4. Лайфхак для тех, кто работает с B2B-продуктами. За успешное тестирование гипотезы о востребованности разработки всегда можно выдать продажи через «откат».
Нет!: никогда не подавайте результаты от продаж через «откат» как успехи в тестировании. Это непрофессионально и незаконно. Когда-нибудь всё раскроется, в лучшем случае — вылетите с работы.
5. Ставьте акценты правильно. Продавайте фичи, а не ценности. В конце концов, зря вы их что ли придумывали? Не объясняйте смысл, не всем дано понять гениальное. Повезёт — разберутся на практике.
Нет!: За каждой фичей должна стоять какая-то ценность. Важно делать акцент именно на второе. Вы предлагаете не просто функционал, код или дизайн, а решение какой-то проблемы. Заказчику не всегда очевидно, для чего нужна кнопка, скрипт и т. д., поэтому объясняйте ему с помощью таких понятий, как ценность, проблема, решение и действие.
6. Даже не начинайте считать экономическую модель. Рассчитывать unit-экономику сложно и, вообще, вы не математик. Если случится так, что стоимость приложения в итоге превысит доход от него — проблема в клиенте.
Нет!: считать unit-экономику нужно. К вам обращаются за услугой и доверяют проект, поэтому невнимательно относиться к нему нельзя. Особенно — к финансовой части. Важно рассчитать потенциальную прибыль, доход от одного пользователя или продажи. Это поможет правильно распределить ресурсы команде и грамотно вложить средства клиенту.
7. Дайте полную свободу команде. Хватит названивать и писать разработчикам. Уже не маленькие, сами справятся. Команду, вообще, можно не беспокоить вплоть до дня сдачи продукта. Да, вы ответственный за проект, но всегда может быть человеческий фактор.
Нет!: продукт-менеджер обязан контролировать команду. Для этого не обязательно стоять с палкой возле двери (хотя, если ваши вкусы специфичны…), можно использовать Jira, рабочие столы на общем сервере или флипчарты. Это необходимо, чтобы координировать каждого члена команды в рамках спринтов: не давать зарабатываться, опаздывать, делать что-то не то.
На этот пост вдохновил доклад руководителя разработки из X5 Tech. В подкасте описываются любимые (и не всегда очевидные) способы, которыми технические специалисты способны сильно испортить жизнь себе и коллегам, и которыми они наверняка продолжат пользоваться в 2023 году. В основе — собственный практический опыт, наблюдения и полезные кейсы других команд. Рекомендую к прослушиванию.
1. Когда хочется общаться, а не работать — используйте фокус-группы из своих друзей и знакомых. Не бойтесь: Groupthink (по-русски: стадное мышление) с вами просто не может случиться.
Нет! : если у вас нет возможности проводить полноценное интервью, работать с фокус-группой можно. Однако не стоит набирать её из своих друзей. Лучше всего пригласить независимых представителей потенциальной аудитории. Приглашайте разных людей, ведь пользователи тоже будут отличаться. Так у вас получится собрать максимум информации.
2. Не воспринимайте фидбек серьёзно. Обидеть менеджера по продукту может каждый. Позже, когда продукт будет уже запущен, клиент увидит, что всё работает. А результат — именно то, что он на самом деле хотел.
Нет!: Воспринимайте фидбек серьёзно. Даже если он кажется вам глупым, подобное может написать технически неграмотный пользователь в дальнейшем. Конечно, если отзыв неадекватный, это следует обсудить с заказчиком. Однако постарайтесь найти причину такого фидбека в любом случае. Определите истинную проблему клиента.
3. Тестируйте все проблемы на полноценном MVP. Только полная реализация в железе и коде, только хардкор. Ручной режим не покажет всех ошибок, а вы ведь проводите тесты наверняка.
Нет!: тестируйте мелкие добавления вручную. Это сэкономит время и силы команды намного больше, чем создание MVP каждый раз. Нужно только найти в команду нормального тестировщика, тогда проблем не возникнет.
4. Лайфхак для тех, кто работает с B2B-продуктами. За успешное тестирование гипотезы о востребованности разработки всегда можно выдать продажи через «откат».
Нет!: никогда не подавайте результаты от продаж через «откат» как успехи в тестировании. Это непрофессионально и незаконно. Когда-нибудь всё раскроется, в лучшем случае — вылетите с работы.
5. Ставьте акценты правильно. Продавайте фичи, а не ценности. В конце концов, зря вы их что ли придумывали? Не объясняйте смысл, не всем дано понять гениальное. Повезёт — разберутся на практике.
Нет!: За каждой фичей должна стоять какая-то ценность. Важно делать акцент именно на второе. Вы предлагаете не просто функционал, код или дизайн, а решение какой-то проблемы. Заказчику не всегда очевидно, для чего нужна кнопка, скрипт и т. д., поэтому объясняйте ему с помощью таких понятий, как ценность, проблема, решение и действие.
6. Даже не начинайте считать экономическую модель. Рассчитывать unit-экономику сложно и, вообще, вы не математик. Если случится так, что стоимость приложения в итоге превысит доход от него — проблема в клиенте.
Нет!: считать unit-экономику нужно. К вам обращаются за услугой и доверяют проект, поэтому невнимательно относиться к нему нельзя. Особенно — к финансовой части. Важно рассчитать потенциальную прибыль, доход от одного пользователя или продажи. Это поможет правильно распределить ресурсы команде и грамотно вложить средства клиенту.
7. Дайте полную свободу команде. Хватит названивать и писать разработчикам. Уже не маленькие, сами справятся. Команду, вообще, можно не беспокоить вплоть до дня сдачи продукта. Да, вы ответственный за проект, но всегда может быть человеческий фактор.
Нет!: продукт-менеджер обязан контролировать команду. Для этого не обязательно стоять с палкой возле двери (хотя, если ваши вкусы специфичны…), можно использовать Jira, рабочие столы на общем сервере или флипчарты. Это необходимо, чтобы координировать каждого члена команды в рамках спринтов: не давать зарабатываться, опаздывать, делать что-то не то.
На этот пост вдохновил доклад руководителя разработки из X5 Tech. В подкасте описываются любимые (и не всегда очевидные) способы, которыми технические специалисты способны сильно испортить жизнь себе и коллегам, и которыми они наверняка продолжат пользоваться в 2023 году. В основе — собственный практический опыт, наблюдения и полезные кейсы других команд. Рекомендую к прослушиванию.
Яндекс Музыка
YaTalks 2022: Владимир Маслов - Вредные советы д...
YaTalks: ReRun • Подкаст • 9336 подписчиков • Сезон 2
❤1👍1
Как рассказать про стратегию продукта на английском?
1. Определите проблему
Во-первых, определите болевую точку вашего потенциального клиента. Когда вы разрабатываете свою презентацию о продажах, ориентируйтесь на проблему, с которой в данный момент сталкивается ваша аудитория, и подкрепляйте свои утверждения данными:
“This is also the challenge that you plan to solve with your offering”
2. Сформулируйте свое ценностное предложение
Затем сформулируйте свое ценностное предложение. Ценностное предложение, также известное как уникальное торговое предложение, - это заявление, подчеркивающее ценность, которую ваш бизнес, продукт или услуга могут предоставить своим клиентам.
In your value proposition, mention how your offering can help solve the problem you’ve identified in step one. Be sure to share the features of the offering and its benefits.
For example, your value proposition could look like this:
Our [Company Name] assists [audience] with [pain point] in order to help achieve [benefits].
3. Vision
Итак, все идет отлично и у вас интересуются, каким вы видите свое будущее либо будущее вашего проекта. Здесь уже время не историй, а фактов, подсчетов и прогнозов.
“Our estimations tell us that we may be able to scale faster than any other web app company did before us.”
“At this rate, we will hit and exceed our numbers by March.”
“Provided we maintain current growth, we’ll be able to maximize our profit enough to open 5 new locations globally.”
“Our market research has proven that there will most likely be more demand for this service in the future 3 years.”
4. Предлагайте решения
Выделив проблему (ы), подумайте о том, как ваш продукт или услуга могут предложить вашей аудитории решение. Чтобы сделать это, разбейте свое ценностное предложение на решения, связанные с преимуществами, такие как:
X helps Y save time and money
X helps Y grow business by Z amount
Tip: Make sure your solutions are easy to understand and don’t offer too many choices.
5. Покажите social proof
Воспользуйтесь социальными доказательствами, предоставив отзывы, рекомендации и истории клиентов, которые показывают, как ваш продукт или услуга помогли аналогичным компаниям добиться успеха.
Showcase the data behind why your offering is beneficial to your audience and support your solutions listed in step four.
6. Заканчивайте с CTA и будьте открыты для вопросов
Продолжайте разговор, задавая открытые вопросы. Затем переведите потенциального клиента к следующему шагу с четким CTA, например: “Sounds like we’re on the same page. Are you free for another follow-up call next Tuesday after you’ve had time to look at the numbers?”
“I got to go, but I don’t wanna lose you. Could we exchange contact info?”
“What would be the best way to contact you?”
“Feel free to message me on LinkedIn.
“Hit me up on Facebook with any questions you may have.”
“I’ll follow up with you in an email with my resume/presentation/ the details regarding our future partnership.”
Хотите обучиться пичтингу стратегии продукта и самопрезентации? Для вас запустился курс «Английский для продакт-менеджеров» Яндекс Практикума. Обучение построено вокруг рабочих ситуаций и полезных для карьеры навыков:
Самопрезентация. Демонстрация лидерских качеств на встречах. Рассказ о себе на собеседовании и при знакомстве с командой.
Питч стратегии продукта. Ответы на product sense questions на собеседовании. Защита дорожной карты перед стэйкхолдерами.
Навигация в спорных ситуациях. Переговоры о ресурсах и сроках со стейкхолдерами. Работа с немотивированными командами. Обсуждение проблем и идей на ретро.
Питчинг локальных и глобальных трендов. Обсуждение ценностей, которые вызывают доверие пользователей, на собеседовании и во время нетворкинга.
Запишитесь на бесплатную консультацию. Кураторы определят ваш уровень языка и расскажут подробнее про обучение.
1. Определите проблему
Во-первых, определите болевую точку вашего потенциального клиента. Когда вы разрабатываете свою презентацию о продажах, ориентируйтесь на проблему, с которой в данный момент сталкивается ваша аудитория, и подкрепляйте свои утверждения данными:
“This is also the challenge that you plan to solve with your offering”
2. Сформулируйте свое ценностное предложение
Затем сформулируйте свое ценностное предложение. Ценностное предложение, также известное как уникальное торговое предложение, - это заявление, подчеркивающее ценность, которую ваш бизнес, продукт или услуга могут предоставить своим клиентам.
In your value proposition, mention how your offering can help solve the problem you’ve identified in step one. Be sure to share the features of the offering and its benefits.
For example, your value proposition could look like this:
Our [Company Name] assists [audience] with [pain point] in order to help achieve [benefits].
3. Vision
Итак, все идет отлично и у вас интересуются, каким вы видите свое будущее либо будущее вашего проекта. Здесь уже время не историй, а фактов, подсчетов и прогнозов.
“Our estimations tell us that we may be able to scale faster than any other web app company did before us.”
“At this rate, we will hit and exceed our numbers by March.”
“Provided we maintain current growth, we’ll be able to maximize our profit enough to open 5 new locations globally.”
“Our market research has proven that there will most likely be more demand for this service in the future 3 years.”
4. Предлагайте решения
Выделив проблему (ы), подумайте о том, как ваш продукт или услуга могут предложить вашей аудитории решение. Чтобы сделать это, разбейте свое ценностное предложение на решения, связанные с преимуществами, такие как:
X helps Y save time and money
X helps Y grow business by Z amount
Tip: Make sure your solutions are easy to understand and don’t offer too many choices.
5. Покажите social proof
Воспользуйтесь социальными доказательствами, предоставив отзывы, рекомендации и истории клиентов, которые показывают, как ваш продукт или услуга помогли аналогичным компаниям добиться успеха.
Showcase the data behind why your offering is beneficial to your audience and support your solutions listed in step four.
6. Заканчивайте с CTA и будьте открыты для вопросов
Продолжайте разговор, задавая открытые вопросы. Затем переведите потенциального клиента к следующему шагу с четким CTA, например: “Sounds like we’re on the same page. Are you free for another follow-up call next Tuesday after you’ve had time to look at the numbers?”
“I got to go, but I don’t wanna lose you. Could we exchange contact info?”
“What would be the best way to contact you?”
“Feel free to message me on LinkedIn.
“Hit me up on Facebook with any questions you may have.”
“I’ll follow up with you in an email with my resume/presentation/ the details regarding our future partnership.”
Хотите обучиться пичтингу стратегии продукта и самопрезентации? Для вас запустился курс «Английский для продакт-менеджеров» Яндекс Практикума. Обучение построено вокруг рабочих ситуаций и полезных для карьеры навыков:
Самопрезентация. Демонстрация лидерских качеств на встречах. Рассказ о себе на собеседовании и при знакомстве с командой.
Питч стратегии продукта. Ответы на product sense questions на собеседовании. Защита дорожной карты перед стэйкхолдерами.
Навигация в спорных ситуациях. Переговоры о ресурсах и сроках со стейкхолдерами. Работа с немотивированными командами. Обсуждение проблем и идей на ретро.
Питчинг локальных и глобальных трендов. Обсуждение ценностей, которые вызывают доверие пользователей, на собеседовании и во время нетворкинга.
Запишитесь на бесплатную консультацию. Кураторы определят ваш уровень языка и расскажут подробнее про обучение.
practicum.yandex.ru
Английский для IT-специалистов
Курсы от Яндекс Практикума
Как собрать рабочую команду по модели Белбина
Порядок отбора участников напрямую зависит от задачи компании и начинать отбор рекомендуется с наиболее значимых командных ролей для определённой цели. А дальше, под характеристики ведущих ролей, подбираются остальные члены команды, которые дополнят и сбалансируют первых участников. Разберём на примерах:
- Если стоит задача «вывод нового продукта на рынок» или «разработка антикризисной стратегии», то первыми скрипками выступят интеллектуальные роли: Генератор идей, Аналитик-стратег и Специалист. Генератор выдвинет идею, Аналитик проанализирует рынок и предоставит заключение, насколько идея Генератора жизнеспособна, а Специалист даст свои рекомендации по реализации задуманного.
- Для задач «поиск новых партнёров/поставщиков» или «открытие нового магазина/филиала» незаменимыми будут социальные роли: Исследователь ресурсов, Координатор и Душа команды, ведь как раз они ориентированы на налаживание контактов между людьми и выстраивание долгосрочных деловых отношений.
Лайфхаки модели
1. Если несколько человек в рабочей команде дублируют друг друга по ролям и функциям — возникает неэффективное распределение ресурсов внутри группы, снижается общая результативность. Теория Белбина о командных ролях создана, чтобы решить эту проблему;
2. Модель Белбина состоит из 9-ти типов и поделена на 3 группы: интеллектуальные роли — Генератор идей, Аналитик-стратег, Специалист; социальные роли — Душа команды, Исследователь ресурсов, Координатор; роли действия — Мотиватор, Реализатор, Педант;
3. Для того чтобы выявить командные роли у сотрудников, рекомендуется использовать тестовую оценку персонала. Для разных ролей важны разные факторы, поэтому оценка должна быть комплексной и рассматривать человека по трём направлениям: мотивация, интеллект, личность;
4. После оценки можно формировать команду. Начинайте с самой важной роли для проекта, а затем подбирайте остальных участников так, чтобы они дополняли качества друг друга и нейтрализовали недостатки. Здесь важен баланс сил всей команды;
5. Модель командных ролей Белбина поможет сформировать органичную рабочую команду, которая будет способна эффективно справляться с поставленными задачами и регулярно приносить пользу компании.
Порядок отбора участников напрямую зависит от задачи компании и начинать отбор рекомендуется с наиболее значимых командных ролей для определённой цели. А дальше, под характеристики ведущих ролей, подбираются остальные члены команды, которые дополнят и сбалансируют первых участников. Разберём на примерах:
- Если стоит задача «вывод нового продукта на рынок» или «разработка антикризисной стратегии», то первыми скрипками выступят интеллектуальные роли: Генератор идей, Аналитик-стратег и Специалист. Генератор выдвинет идею, Аналитик проанализирует рынок и предоставит заключение, насколько идея Генератора жизнеспособна, а Специалист даст свои рекомендации по реализации задуманного.
- Для задач «поиск новых партнёров/поставщиков» или «открытие нового магазина/филиала» незаменимыми будут социальные роли: Исследователь ресурсов, Координатор и Душа команды, ведь как раз они ориентированы на налаживание контактов между людьми и выстраивание долгосрочных деловых отношений.
Лайфхаки модели
1. Если несколько человек в рабочей команде дублируют друг друга по ролям и функциям — возникает неэффективное распределение ресурсов внутри группы, снижается общая результативность. Теория Белбина о командных ролях создана, чтобы решить эту проблему;
2. Модель Белбина состоит из 9-ти типов и поделена на 3 группы: интеллектуальные роли — Генератор идей, Аналитик-стратег, Специалист; социальные роли — Душа команды, Исследователь ресурсов, Координатор; роли действия — Мотиватор, Реализатор, Педант;
3. Для того чтобы выявить командные роли у сотрудников, рекомендуется использовать тестовую оценку персонала. Для разных ролей важны разные факторы, поэтому оценка должна быть комплексной и рассматривать человека по трём направлениям: мотивация, интеллект, личность;
4. После оценки можно формировать команду. Начинайте с самой важной роли для проекта, а затем подбирайте остальных участников так, чтобы они дополняли качества друг друга и нейтрализовали недостатки. Здесь важен баланс сил всей команды;
5. Модель командных ролей Белбина поможет сформировать органичную рабочую команду, которая будет способна эффективно справляться с поставленными задачами и регулярно приносить пользу компании.
Дайджест событий от меня
Много ссылок, хочется поделиться всем:
1. Начал вести блог на vc и поделился первым кейсом от себя по разделу Избранное в интернет-магазине (3500+ посмотров). В день публикации статья на какое-то время попала в ТОП-2. Там я постарался увлекательно описать, как продуктовый подход может реально повлиять на выручку даже в таком разделе, как Избранное - читайте по ссылке. А больше кейсов и эфиров будет на канале @sergeyproduct, приходите за консультациями и инсайтами, стоимость первой консультации можете определить вы.
2. У проекта Product well done очень хороший отклик, есть первые отзывы, которые говорят о пользе наших экспресс-прожарок (например, вот). Также идем в сторону подкастов и развиваем YouTube направление (есть 1,2К просмотров всего), уже есть первые запросы на платные аудиты. Я все больше верю в этот формат и буду внедрять его в свою работу и образовательные проекты.
3. Собрал концентрированный мини-курс по прайс-интервью и механикам ценообразования. Много пишу про это на своих каналах также. Если кому-то тема интересна и вы хотите стать первым слушателем курса (за донат после изучения), пишите в личку.
Делитесь знаниями и ссылкой на канал!
Много ссылок, хочется поделиться всем:
1. Начал вести блог на vc и поделился первым кейсом от себя по разделу Избранное в интернет-магазине (3500+ посмотров). В день публикации статья на какое-то время попала в ТОП-2. Там я постарался увлекательно описать, как продуктовый подход может реально повлиять на выручку даже в таком разделе, как Избранное - читайте по ссылке. А больше кейсов и эфиров будет на канале @sergeyproduct, приходите за консультациями и инсайтами, стоимость первой консультации можете определить вы.
2. У проекта Product well done очень хороший отклик, есть первые отзывы, которые говорят о пользе наших экспресс-прожарок (например, вот). Также идем в сторону подкастов и развиваем YouTube направление (есть 1,2К просмотров всего), уже есть первые запросы на платные аудиты. Я все больше верю в этот формат и буду внедрять его в свою работу и образовательные проекты.
3. Собрал концентрированный мини-курс по прайс-интервью и механикам ценообразования. Много пишу про это на своих каналах также. Если кому-то тема интересна и вы хотите стать первым слушателем курса (за донат после изучения), пишите в личку.
Делитесь знаниями и ссылкой на канал!
Как оптимизировать процесс проверки гипотез
Ресурсы продакт-менеджера ограничены — он не сможет проверить все гипотезы из бэклога. Поэтому важно научиться оценивать влияние гипотезы на ключевую метрику ещё до тестов — так можно выбрать самые перспективные и не тратить время на проверку слабых идей.
Как это сделать:
⁃ Углубитесь в проблемы. Прежде чем брать гипотезу в тест, проверьте, существует ли проблема, на которой она основана. Часто для этого нужно провести дополнительное исследование: это отнимет ресурсы, но выйдет дешевле, чем тестировать бесперспективную гипотезу.
⁃ Опирайтесь на бенчмарки. Попросите ориентир у более опытных коллег, смотрите выступления продактов с кейсами, гуглите, общайтесь с людьми из других компаний. Если бенчмарк выглядит нереалистичным, адаптируйте его на основе своего опыта.
- Делайте допущения: лучше посчитать верхнеуровнево, чем вовсе не считать. У вас получатся примерные расчёты, но даже их часто хватает, чтобы трезво взглянуть на гипотезу и сравнить её потенциал с другими.
⁃ Приоритезируйте гипотезы по важности и лёгкости внедрения. Регулярно сравнивайте гипотезы между собой, чтобы рационально расходовать ресурсы.
Если гипотеза сложная, тестируйте её MVP. Выделите главную сутевую часть гипотезы — то изменение, которое она привнесёт в продукт — и тестируйте только его. Это позволит получить более точную оценку потенциала гипотезы.
⁃ Прикинуть влияние гипотезы на метрику, чтобы не тратить ресурсы на слабые идеи. Например, когда из десятков гипотез в бэклоге нужно выбрать всего одну–две, которые принесут максимум результата за короткий промежуток времени. На доскональную проверку сразу всех нет времени и ресурсов.
Ресурсы продакт-менеджера ограничены — он не сможет проверить все гипотезы из бэклога. Поэтому важно научиться оценивать влияние гипотезы на ключевую метрику ещё до тестов — так можно выбрать самые перспективные и не тратить время на проверку слабых идей.
Как это сделать:
⁃ Углубитесь в проблемы. Прежде чем брать гипотезу в тест, проверьте, существует ли проблема, на которой она основана. Часто для этого нужно провести дополнительное исследование: это отнимет ресурсы, но выйдет дешевле, чем тестировать бесперспективную гипотезу.
⁃ Опирайтесь на бенчмарки. Попросите ориентир у более опытных коллег, смотрите выступления продактов с кейсами, гуглите, общайтесь с людьми из других компаний. Если бенчмарк выглядит нереалистичным, адаптируйте его на основе своего опыта.
- Делайте допущения: лучше посчитать верхнеуровнево, чем вовсе не считать. У вас получатся примерные расчёты, но даже их часто хватает, чтобы трезво взглянуть на гипотезу и сравнить её потенциал с другими.
⁃ Приоритезируйте гипотезы по важности и лёгкости внедрения. Регулярно сравнивайте гипотезы между собой, чтобы рационально расходовать ресурсы.
Если гипотеза сложная, тестируйте её MVP. Выделите главную сутевую часть гипотезы — то изменение, которое она привнесёт в продукт — и тестируйте только его. Это позволит получить более точную оценку потенциала гипотезы.
⁃ Прикинуть влияние гипотезы на метрику, чтобы не тратить ресурсы на слабые идеи. Например, когда из десятков гипотез в бэклоге нужно выбрать всего одну–две, которые принесут максимум результата за короткий промежуток времени. На доскональную проверку сразу всех нет времени и ресурсов.
Как бороться с усталостью от принятия решений
1. Избегайте ненужных решений
Марк Цукерберг носит одинаковую одежду каждый день, чтобы не думать, что надеть и не тратить на новые решения время и силы. Звучит немного экстремально (сам я так не делаю), но смысл понятен — если вы и так ставите себе цели каждый день, тратьте как можно меньше ресурсов на неважные. Заранее откажитесь от выбора, где это возможно. Я стараюсь использовать инструменты с меньшим количеством опций/настроек/примочек.
2. Приоритезируйте список задач
Выбрать самую важную цель на данный момент — это тоже решение и не самое простое. Причем не откладывайте ее. В моем списке на каждый день заранее есть одна ключевая задача — и мне не нужно решать, делать её или нет.
3. Приступайте к сложной задаче как можно раньше
От сложного решения вы постараетесь убежать в любом случае. Сопротивляться этому легче утром, когда усталости еще нет. Спланируйте день так, чтобы сложные задачи были первыми в списке. Мне не зависать на незапланированных задачах помогает схема: Просмотреть почту “по диагонали” на предмет срочных писем → Ответить на пару вопросов в почте и устно → Приступить к самому важному.
4. Скажите себе "стоп"
Тянетесь к телефону посмотреть Инстаграм? Открываете почту каждые десять минут? Ищете простую задачу, позволяющую быстро поставить галочку “Сделано” в списке задач? Вы устали и уходите от принятия сложных решений. Остановитесь. Идите попейте чай. Или выйдите из офиса и прогуляйтесь. Помните о технике УПРЛС : Устал Принимать Решения — Ложись Спать.
5. Уделите время своему well-being, даже если некогда
Сфокусироваться на самом важном хорошо помогают wellness-практики — особенно, если ими заниматься постоянно. Многие компании сейчас внедряют в корпоративную культуру частного психолога или закупают абонементы в фитнес-клубы. Но это все звучит как утопия, когда у вас переговоры в 10 часов вечера или рабочие выходные.
Поэтому очень важно уметь перезаряжаться самому. Есть ряд SOS-упражнений, которые не займут более 15-20 минут. Например, можно помедитировать. Я уже писал: медитации прокачивают внимательность, а еще они помогают перестать осуждать себя и повышают стрессоустойчивость.
1. Избегайте ненужных решений
Марк Цукерберг носит одинаковую одежду каждый день, чтобы не думать, что надеть и не тратить на новые решения время и силы. Звучит немного экстремально (сам я так не делаю), но смысл понятен — если вы и так ставите себе цели каждый день, тратьте как можно меньше ресурсов на неважные. Заранее откажитесь от выбора, где это возможно. Я стараюсь использовать инструменты с меньшим количеством опций/настроек/примочек.
2. Приоритезируйте список задач
Выбрать самую важную цель на данный момент — это тоже решение и не самое простое. Причем не откладывайте ее. В моем списке на каждый день заранее есть одна ключевая задача — и мне не нужно решать, делать её или нет.
3. Приступайте к сложной задаче как можно раньше
От сложного решения вы постараетесь убежать в любом случае. Сопротивляться этому легче утром, когда усталости еще нет. Спланируйте день так, чтобы сложные задачи были первыми в списке. Мне не зависать на незапланированных задачах помогает схема: Просмотреть почту “по диагонали” на предмет срочных писем → Ответить на пару вопросов в почте и устно → Приступить к самому важному.
4. Скажите себе "стоп"
Тянетесь к телефону посмотреть Инстаграм? Открываете почту каждые десять минут? Ищете простую задачу, позволяющую быстро поставить галочку “Сделано” в списке задач? Вы устали и уходите от принятия сложных решений. Остановитесь. Идите попейте чай. Или выйдите из офиса и прогуляйтесь. Помните о технике УПРЛС : Устал Принимать Решения — Ложись Спать.
5. Уделите время своему well-being, даже если некогда
Сфокусироваться на самом важном хорошо помогают wellness-практики — особенно, если ими заниматься постоянно. Многие компании сейчас внедряют в корпоративную культуру частного психолога или закупают абонементы в фитнес-клубы. Но это все звучит как утопия, когда у вас переговоры в 10 часов вечера или рабочие выходные.
Поэтому очень важно уметь перезаряжаться самому. Есть ряд SOS-упражнений, которые не займут более 15-20 минут. Например, можно помедитировать. Я уже писал: медитации прокачивают внимательность, а еще они помогают перестать осуждать себя и повышают стрессоустойчивость.
🔥2
Чек-лист правил супероффера
⁃ Откажитесь от формального языка. Tone of voice — это голос вашей компании, бренда и он обязательно должен быть единым во всех элементах коммуникации, в том числе и в деловых переписках. Только есть важный нюанс — за красивой историей не потеряйте основной посыл и не сильно выходите за рамки формата джоб оффера. Ваша цель — не просто интересно подать предложение о работе, но и рассказать всю важную информацию. Поэтому желательно соединить текст, написанный в формате истории, с официальными данными. Идеально, если оффер будет более-менее стандартным с креативными деталями, а сторителлинг использован для презентации или видеоряда.
⁃ Учитывайте потребности, цели и желания кандидата, обязательно прописывайте задачи на адаптацию (в идеале 3-6-12 месяцев). При описании используйте именно те слова, которыми говорил с вами кандидат.
⁃ Ставьте дедлайн. Здесь срабатывает то, что в маркетинге называют триггером дефицита — жесткое ограничение во времени, которое мотивирует принять решение здесь и сейчас, в нашем случае — согласиться на оффер и подписать его. Для этого в конце письма напишите конкретные дату и время, до которых предложение будет актуальным.
⁃ Сделайте корпоративный шаблон оффера: это работает по такой формуле: красивое оформление + продающий вопрос = новый, счастливый сотрудник. И неважно, идет сотрудник на административную должность или креативно-творческую, ведь всем приятнее видеть яркую картинку с информацией, чем просто текст.
⁃ Не забывайте прописывать преимущества компании/продукта/команды, не забывайте главного — это презентация для соискателя, а не клиента или партнера. Добавлять в нее десятки показателей, аналитику, сложные термины — не лучшее решение. В крайнем случае используйте для этого только самые важные параметры и оформите всё в виде понятной инфографики. фото офиса, фото рабочего места кандидата (можно сделать это мило — с табличкой «Мы ждем тебя», «Это твой рабочий дом», «Тут не хватает тебя», если такое отношение принято в вашей компании), забавный рассказ о коллегах (кто чем отличился, кто что любит, кто чем занимается), смешные рабочие моменты в виде коротких видео, рассказ о ценностях, миссии компании, целях сотрудников;
⁃ Выгоды сотрудника — это материальная и нематериальная мотивация. Важно рассказать сразу о двух, но больше внимания уделить именно Total Rewards, которые еще называют бенефитами и плюшками. Ведь часто человек готов работать за оплату на 10-15% ниже рыночной при условии, что в компании хорошо развита корпоративная культура и система нематериальной мотивации.
IT — рынок кандидатов с большим опытом и хорошим портфолио. Компании борются за кандидатов, предлагая им все более и более выгодные условия. Как в этой гонке за сильными специалистами сделать оффер, который примут, не выходя за рамки бюджета?
⁃ Откажитесь от формального языка. Tone of voice — это голос вашей компании, бренда и он обязательно должен быть единым во всех элементах коммуникации, в том числе и в деловых переписках. Только есть важный нюанс — за красивой историей не потеряйте основной посыл и не сильно выходите за рамки формата джоб оффера. Ваша цель — не просто интересно подать предложение о работе, но и рассказать всю важную информацию. Поэтому желательно соединить текст, написанный в формате истории, с официальными данными. Идеально, если оффер будет более-менее стандартным с креативными деталями, а сторителлинг использован для презентации или видеоряда.
⁃ Учитывайте потребности, цели и желания кандидата, обязательно прописывайте задачи на адаптацию (в идеале 3-6-12 месяцев). При описании используйте именно те слова, которыми говорил с вами кандидат.
⁃ Ставьте дедлайн. Здесь срабатывает то, что в маркетинге называют триггером дефицита — жесткое ограничение во времени, которое мотивирует принять решение здесь и сейчас, в нашем случае — согласиться на оффер и подписать его. Для этого в конце письма напишите конкретные дату и время, до которых предложение будет актуальным.
⁃ Сделайте корпоративный шаблон оффера: это работает по такой формуле: красивое оформление + продающий вопрос = новый, счастливый сотрудник. И неважно, идет сотрудник на административную должность или креативно-творческую, ведь всем приятнее видеть яркую картинку с информацией, чем просто текст.
⁃ Не забывайте прописывать преимущества компании/продукта/команды, не забывайте главного — это презентация для соискателя, а не клиента или партнера. Добавлять в нее десятки показателей, аналитику, сложные термины — не лучшее решение. В крайнем случае используйте для этого только самые важные параметры и оформите всё в виде понятной инфографики. фото офиса, фото рабочего места кандидата (можно сделать это мило — с табличкой «Мы ждем тебя», «Это твой рабочий дом», «Тут не хватает тебя», если такое отношение принято в вашей компании), забавный рассказ о коллегах (кто чем отличился, кто что любит, кто чем занимается), смешные рабочие моменты в виде коротких видео, рассказ о ценностях, миссии компании, целях сотрудников;
⁃ Выгоды сотрудника — это материальная и нематериальная мотивация. Важно рассказать сразу о двух, но больше внимания уделить именно Total Rewards, которые еще называют бенефитами и плюшками. Ведь часто человек готов работать за оплату на 10-15% ниже рыночной при условии, что в компании хорошо развита корпоративная культура и система нематериальной мотивации.
IT — рынок кандидатов с большим опытом и хорошим портфолио. Компании борются за кандидатов, предлагая им все более и более выгодные условия. Как в этой гонке за сильными специалистами сделать оффер, который примут, не выходя за рамки бюджета?
Какой должен быть аналог Jira?
В основе Jira — канбан‑ и скрам‑доски, дополненные множеством вспомогательных средств. Все задачи в рамках проекта делятся на несколько общих функциональных групп: front‑end, back‑end, QA, mobile, web, и т. д. Затем таски систематизируются в порядке работы над ними: Например, общий список поставленных задач, находящиеся в работе, требующие согласования, завершенные.
Отличительная черта Jira — необходимость предварительной настройки проекта: организация продуктовых команд, определение ролей участников, взаимозависимостей подпроектов и задач. Впрочем, все эти настройки легко меняются и в процессе работы.
Это и многое другое делает Jira основным рабочим пространством, в котором каждый, от руководителя до рядового исполнителя, может получить всю текущую информацию о задачах, которые предстоит выполнить.
Проанализировав несколько новых российских решений, могу заключить, что TeamStorm, пожалуй, удобнее всего подошла к подходу, реализованному в Jira. Это не просто система управления проектами и задачами, а решение класса Collaborative Work Management, ориентированное на организацию совместной работы в рамках проектов.
Важное отличие TeamStorm в том, что это решение on‑premise. Размещается оно на собственных серверах компании. Каждый проект в системе уникален в части бизнес‑процессов, типов задач и этапов их выполнения, вложенности, определения сроков и состава команд. Проекты можно настраивать под нужды конкретного отдела в соответствии с его спецификой и бизнес‑процессами, используя:
⁃ Настройку любых типов задач под нужды команды
⁃ Встроенную поддержку Agile-методологий Scrum и Kanban
⁃ Возможность анализировать любые параметры выполнения задачи или проекта
⁃ Интеграцию с внешними системами и расширяемость
⁃ Учет рабочего времени и управление ресурсами
В результате задачи по мере их постановки сразу попадают в иерархию проекта, которую можно представить и в виде таблицы, и как канбан‑доску. Доступно и управление по методологии agile, с формированием спринтов и ведением бэк‑логов.
Также инструмент помогает автоматизировать предсказуемые процессы, сделать коммуникацию между участниками команд прозрачной и структурированной и расставлять приоритеты, не терять фокус и успешно завершать проекты.
В основе Jira — канбан‑ и скрам‑доски, дополненные множеством вспомогательных средств. Все задачи в рамках проекта делятся на несколько общих функциональных групп: front‑end, back‑end, QA, mobile, web, и т. д. Затем таски систематизируются в порядке работы над ними: Например, общий список поставленных задач, находящиеся в работе, требующие согласования, завершенные.
Отличительная черта Jira — необходимость предварительной настройки проекта: организация продуктовых команд, определение ролей участников, взаимозависимостей подпроектов и задач. Впрочем, все эти настройки легко меняются и в процессе работы.
Это и многое другое делает Jira основным рабочим пространством, в котором каждый, от руководителя до рядового исполнителя, может получить всю текущую информацию о задачах, которые предстоит выполнить.
Проанализировав несколько новых российских решений, могу заключить, что TeamStorm, пожалуй, удобнее всего подошла к подходу, реализованному в Jira. Это не просто система управления проектами и задачами, а решение класса Collaborative Work Management, ориентированное на организацию совместной работы в рамках проектов.
Важное отличие TeamStorm в том, что это решение on‑premise. Размещается оно на собственных серверах компании. Каждый проект в системе уникален в части бизнес‑процессов, типов задач и этапов их выполнения, вложенности, определения сроков и состава команд. Проекты можно настраивать под нужды конкретного отдела в соответствии с его спецификой и бизнес‑процессами, используя:
⁃ Настройку любых типов задач под нужды команды
⁃ Встроенную поддержку Agile-методологий Scrum и Kanban
⁃ Возможность анализировать любые параметры выполнения задачи или проекта
⁃ Интеграцию с внешними системами и расширяемость
⁃ Учет рабочего времени и управление ресурсами
В результате задачи по мере их постановки сразу попадают в иерархию проекта, которую можно представить и в виде таблицы, и как канбан‑доску. Доступно и управление по методологии agile, с формированием спринтов и ведением бэк‑логов.
Также инструмент помогает автоматизировать предсказуемые процессы, сделать коммуникацию между участниками команд прозрачной и структурированной и расставлять приоритеты, не терять фокус и успешно завершать проекты.
Про интервью Миши Карпова у Котелова
В январе по сути я открыл рубрику продактов на подкасте Котелов, а сейчас уже могу посмотреть интервью с Мишей Карповым. Захотел добавить из своего интервью с Мишей пару вопрос-ответов:
Какие метрики в образовательном курсе самые важные?
Тут, конечно, зависит от стадии компании — т.к. набор метрик на ранних этапах и в моменты стабилизации и роста будут меняться.
1) сначала важны метрики market-fit: найти свою аудиторию, понять какой формат продукта им лучше подходит — тут стоит смотреть на переход от занятию к занятию и выполнение ДЗ (как опережающий показатель), на LTV, на повторные оплаты, на фидбэк и на реферальность
2) на более поздних этапах вы уже лучше понимаете ваш продукт и важны операционные метрики роста — что при масштабировании не проседает качество услуги, что низкий % возвратов, что рост выручки идёт с нужно скоростью
3) если мы говорим про расширение бизнеса — то тут часто снова идёт откат к поиску новых ниш-направлений и метрик market-fit для них
Таким образом, в компании должен быть баланс RUN-метрик (операционных) и CHANGE-метрик (более стартаперских).
Если бы ты делал рейтинг продакт-менеджеров, то по каким критериям бы ранжировал?
Конечно, запросы и челленджи продактов очень разные и сильно зависят от компании (от стадии роста компании, от сферы, от b2b/b2c)
Поэтому, если делать рейтинг, то можно подойти с 2 сторон:
1) делить по "доказанным достижениям" в разрезе разных сегментов-категорий (b2b/b2c, стартапы/корпорации, рф/зарубежка), когда ребята как-то описывают их кейсы, а дальше решают либо жюри, либо голосование, либо микс этих оценок (тут может быть много нюансов, тк на стороне продактов из известных компаний может быть "сила бренда", хотя ребята из малых компаний могут быть не менее крутыми)
2) делать какой-то соревновательный формат (как у программистов) — когда нужно за определённое время прорешать N бизнес-кейсов и на основе их делать рейтинг.
Какие стартапстори для тебя самые любимые и почему?
Мне нравятся истории про зарубежку и про малые команды. Мне близка история быть "гражданином мира", чтобы не быть зависимым от проживания или бизнеса в какой-то конкретной стране, поэтому мне близки истории про зарубежку — поэтому мы активно развиваем ProductStar не только в РФ, но и зарубежом. Пожив в Китае, я интересую в целом бизнесом в Азии, из полезных ресурсов с историями команд посоветую портал TechInAsia. С интересом общаюсь с российскими командами, которые вышли на зарубежку, например, Miro. Малые команды драйвят меня скоростью и сплочённостью команды — думаю это отголоски VK, когда там было ещё до 100 человек.
В январе по сути я открыл рубрику продактов на подкасте Котелов, а сейчас уже могу посмотреть интервью с Мишей Карповым. Захотел добавить из своего интервью с Мишей пару вопрос-ответов:
Какие метрики в образовательном курсе самые важные?
Тут, конечно, зависит от стадии компании — т.к. набор метрик на ранних этапах и в моменты стабилизации и роста будут меняться.
1) сначала важны метрики market-fit: найти свою аудиторию, понять какой формат продукта им лучше подходит — тут стоит смотреть на переход от занятию к занятию и выполнение ДЗ (как опережающий показатель), на LTV, на повторные оплаты, на фидбэк и на реферальность
2) на более поздних этапах вы уже лучше понимаете ваш продукт и важны операционные метрики роста — что при масштабировании не проседает качество услуги, что низкий % возвратов, что рост выручки идёт с нужно скоростью
3) если мы говорим про расширение бизнеса — то тут часто снова идёт откат к поиску новых ниш-направлений и метрик market-fit для них
Таким образом, в компании должен быть баланс RUN-метрик (операционных) и CHANGE-метрик (более стартаперских).
Если бы ты делал рейтинг продакт-менеджеров, то по каким критериям бы ранжировал?
Конечно, запросы и челленджи продактов очень разные и сильно зависят от компании (от стадии роста компании, от сферы, от b2b/b2c)
Поэтому, если делать рейтинг, то можно подойти с 2 сторон:
1) делить по "доказанным достижениям" в разрезе разных сегментов-категорий (b2b/b2c, стартапы/корпорации, рф/зарубежка), когда ребята как-то описывают их кейсы, а дальше решают либо жюри, либо голосование, либо микс этих оценок (тут может быть много нюансов, тк на стороне продактов из известных компаний может быть "сила бренда", хотя ребята из малых компаний могут быть не менее крутыми)
2) делать какой-то соревновательный формат (как у программистов) — когда нужно за определённое время прорешать N бизнес-кейсов и на основе их делать рейтинг.
Какие стартапстори для тебя самые любимые и почему?
Мне нравятся истории про зарубежку и про малые команды. Мне близка история быть "гражданином мира", чтобы не быть зависимым от проживания или бизнеса в какой-то конкретной стране, поэтому мне близки истории про зарубежку — поэтому мы активно развиваем ProductStar не только в РФ, но и зарубежом. Пожив в Китае, я интересую в целом бизнесом в Азии, из полезных ресурсов с историями команд посоветую портал TechInAsia. С интересом общаюсь с российскими командами, которые вышли на зарубежку, например, Miro. Малые команды драйвят меня скоростью и сплочённостью команды — думаю это отголоски VK, когда там было ещё до 100 человек.
Как продуктовый подход помог при разработке сервиса «Европротокол онлайн»
Мне очень нравятся статьи с кейсами. Далее будет кейс от разработчиков Госуслуг с продуктовым подходом для сервиса «Европротокол онлайн».
1. Из-за сложности оформления европротокола и необходимости организации взаимодействия между разными независимыми организациями было несколько подходов к реализации сервиса. В итоге было принято решение собрать команду, по-новому взглянуть на то, что сделано, и уже после этого довести сервис до конечного пользователя.
2. Продуктовый подход подразумевает, что во главе угла ставится реальная польза продукта, сервиса, услуги. Разработчик наравне с заказчиком разделяет ответственность за финальный результат. Мы изучаем рынок, формулируем и валидируем гипотезы через эксперименты, прорабатываем пользовательские пути и готовим решение с учётом минимальных сроков и бюджетов.
3. Ключевой момент — польза: проведение исследований. Нам важно было получить ответы на следующие вопросы:
• Есть ли у пользователей потребность в электронном европротоколе в приложении «Госуслуги Авто»?
• На какую долю рынка (количество оформленных европротоколов) мы можем рассчитывать?
• Что мотивирует/демотивирует водителей использовать электронный европротокол?
• Какое время потребуется водителю для заполнения европротокола в нашем приложении?
• Какой формат оформления удобен: когда два пользователя, каждый со своего устройства, заполняют бланк, или когда один заполняет, а второй подтверждает?
4. Использованный подход дал нам ряд важных преимуществ:
• экономию бюджета за счёт раннего выявления слабых мест и реализации более удобного варианта сервиса;
• быструю разработку и скорый time to market за счёт полного понимания требований к продукту и конкретно к каждому члену команды;
• целевое позиционирование сервиса и быстрый рост его востребованности за счёт точного выявления ключевых потребностей пользователей и прямого, неискажённого восприятия их в процессе разработки.
Рекомендую посмотреть полный текст новой статьи на Хабре, где Наталья Рудометова, старший менеджер по продукту РТЛабс, рассказывыет и показывает, что стоит за тем, чтобы упросить такой, чаще всего неприятный, процесс?
Какие грабли собрала команда, чему научилась и что получилось в конце? Читайте по ссылке.
Информация предоставлена АО "РТ Лабс"
Мне очень нравятся статьи с кейсами. Далее будет кейс от разработчиков Госуслуг с продуктовым подходом для сервиса «Европротокол онлайн».
1. Из-за сложности оформления европротокола и необходимости организации взаимодействия между разными независимыми организациями было несколько подходов к реализации сервиса. В итоге было принято решение собрать команду, по-новому взглянуть на то, что сделано, и уже после этого довести сервис до конечного пользователя.
2. Продуктовый подход подразумевает, что во главе угла ставится реальная польза продукта, сервиса, услуги. Разработчик наравне с заказчиком разделяет ответственность за финальный результат. Мы изучаем рынок, формулируем и валидируем гипотезы через эксперименты, прорабатываем пользовательские пути и готовим решение с учётом минимальных сроков и бюджетов.
3. Ключевой момент — польза: проведение исследований. Нам важно было получить ответы на следующие вопросы:
• Есть ли у пользователей потребность в электронном европротоколе в приложении «Госуслуги Авто»?
• На какую долю рынка (количество оформленных европротоколов) мы можем рассчитывать?
• Что мотивирует/демотивирует водителей использовать электронный европротокол?
• Какое время потребуется водителю для заполнения европротокола в нашем приложении?
• Какой формат оформления удобен: когда два пользователя, каждый со своего устройства, заполняют бланк, или когда один заполняет, а второй подтверждает?
4. Использованный подход дал нам ряд важных преимуществ:
• экономию бюджета за счёт раннего выявления слабых мест и реализации более удобного варианта сервиса;
• быструю разработку и скорый time to market за счёт полного понимания требований к продукту и конкретно к каждому члену команды;
• целевое позиционирование сервиса и быстрый рост его востребованности за счёт точного выявления ключевых потребностей пользователей и прямого, неискажённого восприятия их в процессе разработки.
Рекомендую посмотреть полный текст новой статьи на Хабре, где Наталья Рудометова, старший менеджер по продукту РТЛабс, рассказывыет и показывает, что стоит за тем, чтобы упросить такой, чаще всего неприятный, процесс?
Какие грабли собрала команда, чему научилась и что получилось в конце? Читайте по ссылке.
Информация предоставлена АО "РТ Лабс"
Кому подходит Scrum, а кому Kanban?
- Scrum хорошо подходит в условиях неопределенности. Когда у вас есть только гипотезы, и вы еще не знаете верны они или нет. Акцент на скорости, метриках продукта и обратной связи от пользователей. Задача сформировать гипотезы в виде User Stories (US) и как можно быстрее запустить спринт. Мы тратим время на ресурсоемкие ритуалы Scrum. Именно они помогают сырую US как-то оценить, вовремя подправить и быстро обновить на проде, что позволяет своевременно собрать метрики, и сделать выводы.
Без настройки продуктовых метрик и без интервью с пользователями не обойтись. Чем быстрее и качественнее мы будем собирать данные, тем быстрее и правильнее будут наши решения. Ритуалы: Poker планирование и замер скорости путем закрытия Story Points на ежедневных встречах (Stand Up). Анализируем Burn Down Chart на ретроспективе.
- Kanban лучше подходит когда задачи расписаны на месяцы и каждый шаг необходимо согласовывать. Мы растягиваем процесс, но в итоге имеем согласованный и качественный релиз. Подробная доска поможет вам и ЗЛ увидеть узкие места. Установите WIP-лимиты (Work In Progress), например: больше одной задачи разработчикам в работу не брать.
Процесс закрытия задач последовательный, согласованный и поэтому требует больше времени. Вы можете параллельно запускать в работу несколько US, возвращать задачу на предыдущий этап и добавлять в любое время новую. Постоянно настраивать и улучшать доску под себя и свои нужды, устраняя узкие места и обеспечивая непрерывный поток. Мы знаем кто, что и когда делает и видим все этапы конвейера.
Если вас замучали «эджайлом» или вы сами мучаете им вашу команду, то этот выпуск подкаста «Магнитное Поле» – для вас! Потому что в нем Всеволод Сыров (Agile lead Магнита) как раз объясняет, нужен ли в каждой команде agile, как собрать идеальную команду и выстроить в ней процессы, как найти ее проблемы и решить, а также каким образом все-таки убедить всех «стейкхолдеров» договориться.
Это уже пятый выпуск подкаста «Магнитное Поле», который совместно записывают Завтракаст и IT-команда ритейлера Магнит. В предыдущих выпусках обсуждали Data Governance, современные облачные решения и микросервисы, IT HR, ecom и многое другое, так что стоит обратить внимание.
Ссылка в подкаст-сервисе и на YouTube-канале Завтракаста.
- Scrum хорошо подходит в условиях неопределенности. Когда у вас есть только гипотезы, и вы еще не знаете верны они или нет. Акцент на скорости, метриках продукта и обратной связи от пользователей. Задача сформировать гипотезы в виде User Stories (US) и как можно быстрее запустить спринт. Мы тратим время на ресурсоемкие ритуалы Scrum. Именно они помогают сырую US как-то оценить, вовремя подправить и быстро обновить на проде, что позволяет своевременно собрать метрики, и сделать выводы.
Без настройки продуктовых метрик и без интервью с пользователями не обойтись. Чем быстрее и качественнее мы будем собирать данные, тем быстрее и правильнее будут наши решения. Ритуалы: Poker планирование и замер скорости путем закрытия Story Points на ежедневных встречах (Stand Up). Анализируем Burn Down Chart на ретроспективе.
- Kanban лучше подходит когда задачи расписаны на месяцы и каждый шаг необходимо согласовывать. Мы растягиваем процесс, но в итоге имеем согласованный и качественный релиз. Подробная доска поможет вам и ЗЛ увидеть узкие места. Установите WIP-лимиты (Work In Progress), например: больше одной задачи разработчикам в работу не брать.
Процесс закрытия задач последовательный, согласованный и поэтому требует больше времени. Вы можете параллельно запускать в работу несколько US, возвращать задачу на предыдущий этап и добавлять в любое время новую. Постоянно настраивать и улучшать доску под себя и свои нужды, устраняя узкие места и обеспечивая непрерывный поток. Мы знаем кто, что и когда делает и видим все этапы конвейера.
Если вас замучали «эджайлом» или вы сами мучаете им вашу команду, то этот выпуск подкаста «Магнитное Поле» – для вас! Потому что в нем Всеволод Сыров (Agile lead Магнита) как раз объясняет, нужен ли в каждой команде agile, как собрать идеальную команду и выстроить в ней процессы, как найти ее проблемы и решить, а также каким образом все-таки убедить всех «стейкхолдеров» договориться.
Это уже пятый выпуск подкаста «Магнитное Поле», который совместно записывают Завтракаст и IT-команда ритейлера Магнит. В предыдущих выпусках обсуждали Data Governance, современные облачные решения и микросервисы, IT HR, ecom и многое другое, так что стоит обратить внимание.
Ссылка в подкаст-сервисе и на YouTube-канале Завтракаста.
❤1👍1
Дизайн-аутсорсинг в тренде
Вот важные инсайты:
— Актуальность аутсорсинга на рынке растет. Особенно это касается крупного бизнеса с развитой офлайн и диджитал-коммуникацией в разных каналах и сформировавшейся дизайн-системой.
— Внешнюю команду привлекают, когда нужен быстрый и качественный результат, когда нет необходимости расширять свой штат или самостоятельно искать подходящих специалистов.
— Выбирая сотрудников на аутсорс, компании обращают внимание на их умение планировать бюджет наперед, грамотно выстраивать все процессы.
— Среди студий набирает популярность тренд на сближение с клиентом: общение на равных и персональный мэтч.
Также благодаря исследованию, появился пилот — тестовый формат взаимодействия для новых клиентов. Это демо-версия будущей работы, которая позволяет реализовать небольшой объем задач на коротком отрезке времени и почувствовать коннект с подрядчиком.
Еще больше инсайтов читайте в статье на vc.
Вот важные инсайты:
— Актуальность аутсорсинга на рынке растет. Особенно это касается крупного бизнеса с развитой офлайн и диджитал-коммуникацией в разных каналах и сформировавшейся дизайн-системой.
— Внешнюю команду привлекают, когда нужен быстрый и качественный результат, когда нет необходимости расширять свой штат или самостоятельно искать подходящих специалистов.
— Выбирая сотрудников на аутсорс, компании обращают внимание на их умение планировать бюджет наперед, грамотно выстраивать все процессы.
— Среди студий набирает популярность тренд на сближение с клиентом: общение на равных и персональный мэтч.
Также благодаря исследованию, появился пилот — тестовый формат взаимодействия для новых клиентов. Это демо-версия будущей работы, которая позволяет реализовать небольшой объем задач на коротком отрезке времени и почувствовать коннект с подрядчиком.
Еще больше инсайтов читайте в статье на vc.
vc.ru
Аутсорсинг в дизайне: как устроена и кому подходит дизайн-поддержка? — Дизайн на vc.ru
Наша студия дизайна maryco взяла интервью у крупных игроков рынка Skillhunt, «Сравни», TRASSIR Cloud, «Анабар», Training Data, а ключевыми инсайтами поделилась в этой статье.
Пять стратегических причин, по которым действительно стоит создавать новую бизнес-модель
⁃ Когда есть шанс за счет инновационного продукта удовлетворить нужды большой группы потенциальных потребителей, рынка для которых пока нет — существующие предложения слишком дороги или сложны для них. Речь идет, скажем, о возможности «демократизировать» продукт на развивающихся рынках, примером чего служит автомобиль Nano компании Tata Motors.
⁃ Когда есть шанс хорошо заработать на принципиально новой технологии, создав для нее новую бизнес-модель (Apple и плееры mp3), или выгодно воспользоваться опробованной технологией на совершенно новом рынке (скажем, применив военные технологии в «гражданских» товарах или наоборот).
⁃ Когда есть шанс создать продукт/услугу для выполнения «работы», которую прежде никто не пытался выполнять вообще или выполнять именно таким образом. Чаще всего такая возможность выпадает в отраслях, которые чересчур увлекаются сегментацией товаров и потребителей. Из-за этого компаниям приходится постоянно совершенствовать свои продукты, и в результате то, что еще недавно было новым и престижным, становится стандартным. Предназначая свои продукты для выполнения той или иной «работы», компания может изменить рентабельность отрасли.
⁃ Когда бизнесу угрожают инноваторы, нацеленные на нижний ценовой сегмент. Если автомобиль Nano, как и задумано, окажется по карману рядовым индийцам, это сильно усложнит жизнь другим автопроизводителям. Похоже, тогда события будут развиваться по сценарию 30-летней давности: тогда металлургические мини-заводы, производившие дешевую и поначалу не слишком качественную сталь, начали вытеснять комбинаты с полным циклом.
⁃ Когда смещается «центр тяжести» конкурентной борьбы. Со временем, и это неизбежно, изменяются сами представления о приемлемом качестве продукта, то есть о стандартах для того или иного рынка. В результате продукция основных игроков отрасли «подтягивается» к этим стандартам и вся она становится более или менее одинаковой. Компании Hilti нужно было изменить бизнес-модель отчасти потому, что на глобальный рынок вышли «дешевые» производители; со своей продукцией нижнего ценового диапазона, но приемлемого при такой стоимости качества они начали потихоньку оттеснять в сторону производителей дорогого высококлассного оборудования.
⁃ Когда есть шанс за счет инновационного продукта удовлетворить нужды большой группы потенциальных потребителей, рынка для которых пока нет — существующие предложения слишком дороги или сложны для них. Речь идет, скажем, о возможности «демократизировать» продукт на развивающихся рынках, примером чего служит автомобиль Nano компании Tata Motors.
⁃ Когда есть шанс хорошо заработать на принципиально новой технологии, создав для нее новую бизнес-модель (Apple и плееры mp3), или выгодно воспользоваться опробованной технологией на совершенно новом рынке (скажем, применив военные технологии в «гражданских» товарах или наоборот).
⁃ Когда есть шанс создать продукт/услугу для выполнения «работы», которую прежде никто не пытался выполнять вообще или выполнять именно таким образом. Чаще всего такая возможность выпадает в отраслях, которые чересчур увлекаются сегментацией товаров и потребителей. Из-за этого компаниям приходится постоянно совершенствовать свои продукты, и в результате то, что еще недавно было новым и престижным, становится стандартным. Предназначая свои продукты для выполнения той или иной «работы», компания может изменить рентабельность отрасли.
⁃ Когда бизнесу угрожают инноваторы, нацеленные на нижний ценовой сегмент. Если автомобиль Nano, как и задумано, окажется по карману рядовым индийцам, это сильно усложнит жизнь другим автопроизводителям. Похоже, тогда события будут развиваться по сценарию 30-летней давности: тогда металлургические мини-заводы, производившие дешевую и поначалу не слишком качественную сталь, начали вытеснять комбинаты с полным циклом.
⁃ Когда смещается «центр тяжести» конкурентной борьбы. Со временем, и это неизбежно, изменяются сами представления о приемлемом качестве продукта, то есть о стандартах для того или иного рынка. В результате продукция основных игроков отрасли «подтягивается» к этим стандартам и вся она становится более или менее одинаковой. Компании Hilti нужно было изменить бизнес-модель отчасти потому, что на глобальный рынок вышли «дешевые» производители; со своей продукцией нижнего ценового диапазона, но приемлемого при такой стоимости качества они начали потихоньку оттеснять в сторону производителей дорогого высококлассного оборудования.
Какие фразы помогают донести точку зрения и инсайты
I suppose (that) — Я полагаю (считаю, думаю) - По сути, то же самое, что и «I think».
I suppose, you have a back-up plan. — Я так думаю, у тебя есть запасной план.
I belive (that) — Я думаю, полагаю, считаю (букв.: «Я верю»)
belive that some of your calculations might be slightly incorrect. — Я полагаю, что некоторые из ваших подсчетов могут быть немножко неверны.
I suspect (that) — Я подозреваю
I guess (that) — Я думаю. «Guess» буквально значит «догадываться», но в современном английском, особенно, американском варианте, это выражение очень часто используют как синоним «I think».
I reckon (that) — Думаю, что. Выражение «I reckon» (букв. «я считаю, полагаю») используется как синоним «I think», «I guess», но оно характерно для южных штатов США (хотя встречается и за их пределами).
I’m sure (that) — Я уверен
I have no doubt (that) — Я не сомневаюсь, что. Еще один способ выразить уверенность, пожалуй, даже более твердую, чем «I’m sure».
I am positive (that) — Я твердо уверен, что
In my opinion — По моему мнению. «Opinion» — это мнение, точка зрения. Вы также можете сказать «In my humble opinion» — «По моему скромному мнению».
From my point of view (perspective) — С моей точки зрения. «Point of view» — это точка зрения, а «perspective» — подход к рассмотрению какого-то вопроса. В контексте выражения мнения эти слова — синонимы.
As for me — Как по мне / Что касается меня; «As for me» — это простой неформальный способ выразить мнение.
To my mind — По-моему, по моему мнению. «Mind» — это буквально «разум, ум». Другими словами, «to my mind» значит «по моему мнению», «по-моему».
My impression is (that) — У меня такое впечатление, что. Используется, когда мы делимся мнением, своей точкой зрения.
To my knowledge — Насколько я знаю. Несмотря на то, что «mind» и «knowlege» значат похожие вещи (ум и знание), выражение «to my knowledge» имеет несколько другое значение, чем «to my mind». Оно значит «насколько я знаю».
As far as I know — Насколько я знаю
As far as I remember — Насколько я помню
As far as I can see — Насколько я вижу
It seems to me (that) — Мне кажется, что
appears to me (that) — Кажется / Похоже на то, что / Мне представляется, что
«It appears» и «It seems» близки по смыслу, но не идентичны. «It seems» — это просто «кажется», а «it appears» — это когда у вас сложилось некое впечатление на основе чего-то увиденного, услышанного, на основе догадки или информации.
It looks like — Похоже, что. «It looks like» или просто «Looks like» — очень употребительное в повседневной речи выражение. Разумеется, ему не место в официальной речи или тексте.
With all due respect — При всем моем уважении; Как и его аналог в русском языке, это выражение — вежливый способ возразить, не согласиться. Часто за ним следует «I think/suppose/believe that».
Язык — основной инструмент продакта. Даже на русском непросто выразить свои мысли так, чтобы всё было понятно и никого не задело. А если продакт общается с командой на английском, дело становится ещё сложнее.
В карточках собрали пять ситуаций, где продакту важно точно и аккуратно донести свою мысль, чтобы всё заработало. А ещё — рассказали о том, как получить скидку 20% на курс английского для продактов. Если вам такое интересно — добро пожаловать на сайт.
→ Курс «Продакт-менеджер».
→ Курс «Английский для менеджеров продукта».
→ Правила акции.
I suppose (that) — Я полагаю (считаю, думаю) - По сути, то же самое, что и «I think».
I suppose, you have a back-up plan. — Я так думаю, у тебя есть запасной план.
I belive (that) — Я думаю, полагаю, считаю (букв.: «Я верю»)
belive that some of your calculations might be slightly incorrect. — Я полагаю, что некоторые из ваших подсчетов могут быть немножко неверны.
I suspect (that) — Я подозреваю
I guess (that) — Я думаю. «Guess» буквально значит «догадываться», но в современном английском, особенно, американском варианте, это выражение очень часто используют как синоним «I think».
I reckon (that) — Думаю, что. Выражение «I reckon» (букв. «я считаю, полагаю») используется как синоним «I think», «I guess», но оно характерно для южных штатов США (хотя встречается и за их пределами).
I’m sure (that) — Я уверен
I have no doubt (that) — Я не сомневаюсь, что. Еще один способ выразить уверенность, пожалуй, даже более твердую, чем «I’m sure».
I am positive (that) — Я твердо уверен, что
In my opinion — По моему мнению. «Opinion» — это мнение, точка зрения. Вы также можете сказать «In my humble opinion» — «По моему скромному мнению».
From my point of view (perspective) — С моей точки зрения. «Point of view» — это точка зрения, а «perspective» — подход к рассмотрению какого-то вопроса. В контексте выражения мнения эти слова — синонимы.
As for me — Как по мне / Что касается меня; «As for me» — это простой неформальный способ выразить мнение.
To my mind — По-моему, по моему мнению. «Mind» — это буквально «разум, ум». Другими словами, «to my mind» значит «по моему мнению», «по-моему».
My impression is (that) — У меня такое впечатление, что. Используется, когда мы делимся мнением, своей точкой зрения.
To my knowledge — Насколько я знаю. Несмотря на то, что «mind» и «knowlege» значат похожие вещи (ум и знание), выражение «to my knowledge» имеет несколько другое значение, чем «to my mind». Оно значит «насколько я знаю».
As far as I know — Насколько я знаю
As far as I remember — Насколько я помню
As far as I can see — Насколько я вижу
It seems to me (that) — Мне кажется, что
appears to me (that) — Кажется / Похоже на то, что / Мне представляется, что
«It appears» и «It seems» близки по смыслу, но не идентичны. «It seems» — это просто «кажется», а «it appears» — это когда у вас сложилось некое впечатление на основе чего-то увиденного, услышанного, на основе догадки или информации.
It looks like — Похоже, что. «It looks like» или просто «Looks like» — очень употребительное в повседневной речи выражение. Разумеется, ему не место в официальной речи или тексте.
With all due respect — При всем моем уважении; Как и его аналог в русском языке, это выражение — вежливый способ возразить, не согласиться. Часто за ним следует «I think/suppose/believe that».
Язык — основной инструмент продакта. Даже на русском непросто выразить свои мысли так, чтобы всё было понятно и никого не задело. А если продакт общается с командой на английском, дело становится ещё сложнее.
В карточках собрали пять ситуаций, где продакту важно точно и аккуратно донести свою мысль, чтобы всё заработало. А ещё — рассказали о том, как получить скидку 20% на курс английского для продактов. Если вам такое интересно — добро пожаловать на сайт.
→ Курс «Продакт-менеджер».
→ Курс «Английский для менеджеров продукта».
→ Правила акции.
Telegram
Sergey Koloskov in Better write product manager
Как будет развиваться нетворкинг-менеджмент?
Перефразировав известную аксиому о том, что удача приходит к тем, кто ее не ждет, можно сказать, что лучший нетворк случается там, где его не ищешь.
Да, привычнее считать, что самые полезные знакомства происходят на специальных мероприятиях, в программе которых указано про «качественный нетворкинг», все приходят туда со стопкой визиток и целью установить пару десятков связей и потом «никогда не есть в одиночестве».
Тренды текущего Нетворк-менеджемента вижу в следующем:
1. Сообщество и рост при помощи сообщества становится основой для большего числа компаний
2. Набирает обороты маркетинг, основанный на сообществах
3. Комьюнити-менеджмент сближается с инфлюенс-маркетингом и адвокацией персонала
4. Мероприятия всё больше интегрируются с сообществами
5. Появляются «поп-ап» комьюнити
6. Сообщества становятся аналогом поисковикам и SEO
7. Рост числа подписок, микроплатежей и сообществ DAO
8. Технологии: битва между «все в одном» и «лучший в своем роде»
9. Посредственные сообщества вымирают
10. Люди мигрируют из социальных сетей в небольшие качественные сообщества
11. Бренды коллекционируют готовые сообщества
12. Аналитика сообществ взрослеет
13. ИИ не заменит комьюнити-менеджеров, но дополнит их
14. Лидеры сообщества по-прежнему будут иметь решающее значение для успеха сообщества
Слабые же связи, в том числе спонтанные знакомства, часто «выстреливают» инсайтами, совместными проектами, новыми возможностями и вообще новыми орбитами для личностного и бизнес-роста.
Почему так происходит? Потому что вы соприкасаетесь с совершенно незнакомым опытом, в котором можете разглядеть полезное для себя, найти то, что называют точкой соприкосновения. И при этом вам, вероятно, достаточно этой точки, расширять границы общения от вас не требуется.
Даже краткосрочное получение совместного опыта, как во время недели на катамаранах на Сейшелах, создает условия для естественного нетворкинга никогда не пересекающихся в «обычной деловой жизни» людей. При этом именно в таких условиях они говорят о главном для себя, о том, что не озвучишь больше нигде, рассуждают вслух о том, о чем говорили лишь сами с собой. Комментарий к этим мыслям, узнавание, что кто-то думал о том же, что и я, и продвинулся дальше, дает молниеносную реакцию для нового взгляда на себя, дело, траекторию развития бизнеса.
Перефразировав известную аксиому о том, что удача приходит к тем, кто ее не ждет, можно сказать, что лучший нетворк случается там, где его не ищешь.
Да, привычнее считать, что самые полезные знакомства происходят на специальных мероприятиях, в программе которых указано про «качественный нетворкинг», все приходят туда со стопкой визиток и целью установить пару десятков связей и потом «никогда не есть в одиночестве».
Тренды текущего Нетворк-менеджемента вижу в следующем:
1. Сообщество и рост при помощи сообщества становится основой для большего числа компаний
2. Набирает обороты маркетинг, основанный на сообществах
3. Комьюнити-менеджмент сближается с инфлюенс-маркетингом и адвокацией персонала
4. Мероприятия всё больше интегрируются с сообществами
5. Появляются «поп-ап» комьюнити
6. Сообщества становятся аналогом поисковикам и SEO
7. Рост числа подписок, микроплатежей и сообществ DAO
8. Технологии: битва между «все в одном» и «лучший в своем роде»
9. Посредственные сообщества вымирают
10. Люди мигрируют из социальных сетей в небольшие качественные сообщества
11. Бренды коллекционируют готовые сообщества
12. Аналитика сообществ взрослеет
13. ИИ не заменит комьюнити-менеджеров, но дополнит их
14. Лидеры сообщества по-прежнему будут иметь решающее значение для успеха сообщества
Слабые же связи, в том числе спонтанные знакомства, часто «выстреливают» инсайтами, совместными проектами, новыми возможностями и вообще новыми орбитами для личностного и бизнес-роста.
Почему так происходит? Потому что вы соприкасаетесь с совершенно незнакомым опытом, в котором можете разглядеть полезное для себя, найти то, что называют точкой соприкосновения. И при этом вам, вероятно, достаточно этой точки, расширять границы общения от вас не требуется.
Даже краткосрочное получение совместного опыта, как во время недели на катамаранах на Сейшелах, создает условия для естественного нетворкинга никогда не пересекающихся в «обычной деловой жизни» людей. При этом именно в таких условиях они говорят о главном для себя, о том, что не озвучишь больше нигде, рассуждают вслух о том, о чем говорили лишь сами с собой. Комментарий к этим мыслям, узнавание, что кто-то думал о том же, что и я, и продвинулся дальше, дает молниеносную реакцию для нового взгляда на себя, дело, траекторию развития бизнеса.
Выстраивание грамотной стратегии развития интернет-продукта с помощью метрик и OKR
Использование информации, собранной с помощью метрик — правильное решение для онлайн-бизнеса. На практике работа с аналитическими данными может выглядеть примерно так:
1. Определите точный объем затрат. Рассчитайте, сколько средств вам понадобится для организации бизнес-процессов.
2. Изучите статистические данные, произведите расчеты основных показателей и составьте прогноз спроса на определенные товары в интернет-магазине. Параллельно рассчитайте объем прибыли.
3. Учитывая прогноз, определите, сколько средств предстоит вложить в закупку товара. Понимая разницу между доходом и совокупным объемом затрат, можно будет подсчитать сумму, которую предстоит потратить на развитие онлайн-магазина и привлечение покупателей.
4. Обязательно рассмотрите метрики поведения пользователей на сайте интернет-магазина. Выявите проблемные части веб-ресурса, оперативно устраните недочеты. Если все хорошо, клиенты успешно взаимодействуют с онлайн-магазином, целесообразно выделить средства на внедрение новых эффективных решений.
5. Внимательно изучите целевую аудиторию. Разработайте идею рекламной кампании, определитесь с платформой для размещения и рассчитайте, сколько денег для этого потребуется. Запускайте рекламу только на тех площадках, которые приводят вам потенциальных клиентов.
6. Собирайте информацию по метрикам систематически. При необходимости сразу же реагируйте на ситуацию, вносите изменения и составляйте объективные прогнозы. Насколько часто целесообразно проводить анализ данных по метрикам, каждому предстоит определить опытным путем. Но на стартовом этапе работы делать это нужно как можно чаще. Старайтесь не реже одного раза в неделю изучать соотношение прибыли и расходов, каждый день следить за эффективностью рекламных кампаний. Мониторинг данных по метрикам можно проводить реже, когда бизнес-проект устойчиво «встанет на ноги».
Использование информации, собранной с помощью метрик — правильное решение для онлайн-бизнеса. На практике работа с аналитическими данными может выглядеть примерно так:
1. Определите точный объем затрат. Рассчитайте, сколько средств вам понадобится для организации бизнес-процессов.
2. Изучите статистические данные, произведите расчеты основных показателей и составьте прогноз спроса на определенные товары в интернет-магазине. Параллельно рассчитайте объем прибыли.
3. Учитывая прогноз, определите, сколько средств предстоит вложить в закупку товара. Понимая разницу между доходом и совокупным объемом затрат, можно будет подсчитать сумму, которую предстоит потратить на развитие онлайн-магазина и привлечение покупателей.
4. Обязательно рассмотрите метрики поведения пользователей на сайте интернет-магазина. Выявите проблемные части веб-ресурса, оперативно устраните недочеты. Если все хорошо, клиенты успешно взаимодействуют с онлайн-магазином, целесообразно выделить средства на внедрение новых эффективных решений.
5. Внимательно изучите целевую аудиторию. Разработайте идею рекламной кампании, определитесь с платформой для размещения и рассчитайте, сколько денег для этого потребуется. Запускайте рекламу только на тех площадках, которые приводят вам потенциальных клиентов.
6. Собирайте информацию по метрикам систематически. При необходимости сразу же реагируйте на ситуацию, вносите изменения и составляйте объективные прогнозы. Насколько часто целесообразно проводить анализ данных по метрикам, каждому предстоит определить опытным путем. Но на стартовом этапе работы делать это нужно как можно чаще. Старайтесь не реже одного раза в неделю изучать соотношение прибыли и расходов, каждый день следить за эффективностью рекламных кампаний. Мониторинг данных по метрикам можно проводить реже, когда бизнес-проект устойчиво «встанет на ноги».
Лайфхаки, которые необходимы для перехода в продакт-менеджеры или аналитики
В последнее время приходит очень много обращений и запросов на консультации по вопросам, как переходить в новую профессию. Открыт к этим запросам, а потому и собрал несколько лайфхаков:
⁃ Если есть возможность, лучше не подсаживаться на «денежную иглу» неплохой работы, а сразу потратить время, подготовиться и устроиться на лучшую. Считаю, что так можно расти сильно быстрее. Если нет такой возможности, то нужно учиться работать по 60-80 часов в неделю
⁃ Проходить собеседования — отдельный самостоятельный навык, который отличается от навыка работать по специальности. Я при поиске первой работы продактом прошел более 150 отборов. Между ними много общего, но прокачивать их надо по-разному.
⁃ Чтобы не перегореть за время активной подготовки к новой работе, лучше идти в комфортном темпе. По этой причине можно готовиться самостоятельно, а, например, не идти на курсы.
⁃ Обратите внимание на самое важное. Это может прозвучать банально, но аналитическое мышление и problem-solving — возможно, самые важные вещи в работе аналитиком и продактом
⁃ Не будьте токсиками, будьте людьми, с которыми приятно работать, которым не страшно задать любой, даже самый глупый, вопрос, с которыми комфортно решать проблемы. Помогайте заинтересованным людям в тематических сообществах, и, возможно, кто-то из них станет вашим коллегой в будущем, и вы вместе будете делать клёвый продукт.
⁃ Основная проблема - это необходимость практики. Даже начинающему специалисту недостаточно читать книги и смотреть обучающие видео, чтобы улучшать свои навыки. В стартапе, если вы готовы с головой погрузиться в работу и брать большое количество задач. На стажировке, это отличная возможность войти в профессию: к вам приставят более опытного продакта, который делегирует вам часть своих обязанностей. В пет-проекте (мой выбор, кстати),что позволяет пройти все стадии развития продукта: от создания идеи и MVP, до поиска точек роста и новых возможностей. И курсы, где все необходимые знания собраны в единую программу, рассчитанную на поэтапное освоение профессии. Большинство курсов построены с упором на практику, а поддержка ментора позволит разобраться с непонятными вопросами.
Интересен также опыт как перешёл в IT в 30 лет продуктовый аналитик Avito Алексей Авраменко — читайте по ссылке.
В последнее время приходит очень много обращений и запросов на консультации по вопросам, как переходить в новую профессию. Открыт к этим запросам, а потому и собрал несколько лайфхаков:
⁃ Если есть возможность, лучше не подсаживаться на «денежную иглу» неплохой работы, а сразу потратить время, подготовиться и устроиться на лучшую. Считаю, что так можно расти сильно быстрее. Если нет такой возможности, то нужно учиться работать по 60-80 часов в неделю
⁃ Проходить собеседования — отдельный самостоятельный навык, который отличается от навыка работать по специальности. Я при поиске первой работы продактом прошел более 150 отборов. Между ними много общего, но прокачивать их надо по-разному.
⁃ Чтобы не перегореть за время активной подготовки к новой работе, лучше идти в комфортном темпе. По этой причине можно готовиться самостоятельно, а, например, не идти на курсы.
⁃ Обратите внимание на самое важное. Это может прозвучать банально, но аналитическое мышление и problem-solving — возможно, самые важные вещи в работе аналитиком и продактом
⁃ Не будьте токсиками, будьте людьми, с которыми приятно работать, которым не страшно задать любой, даже самый глупый, вопрос, с которыми комфортно решать проблемы. Помогайте заинтересованным людям в тематических сообществах, и, возможно, кто-то из них станет вашим коллегой в будущем, и вы вместе будете делать клёвый продукт.
⁃ Основная проблема - это необходимость практики. Даже начинающему специалисту недостаточно читать книги и смотреть обучающие видео, чтобы улучшать свои навыки. В стартапе, если вы готовы с головой погрузиться в работу и брать большое количество задач. На стажировке, это отличная возможность войти в профессию: к вам приставят более опытного продакта, который делегирует вам часть своих обязанностей. В пет-проекте (мой выбор, кстати),что позволяет пройти все стадии развития продукта: от создания идеи и MVP, до поиска точек роста и новых возможностей. И курсы, где все необходимые знания собраны в единую программу, рассчитанную на поэтапное освоение профессии. Большинство курсов построены с упором на практику, а поддержка ментора позволит разобраться с непонятными вопросами.
Интересен также опыт как перешёл в IT в 30 лет продуктовый аналитик Avito Алексей Авраменко — читайте по ссылке.
vc.ru
Как я перешёл в IT в 30 лет — бесплатно, без смс и без выгорания — Карьера на vc.ru
Привет! Меня зовут Лёша Авраменко, я хочу поделиться своим опытом перехода в IT. Раньше я работал в банке в отделе рисков, а с января 2022-го вышел продуктовым аналитиком в Авито.
Подборка книг для роста в сфере анализа требований
1. «Разработка требований к программному обеспечению» Карл Вигерс и Джой Битти
Классика среди всех книг по разработке требований. В книге подробно даются процессы сбора, выявления, обработки требований и работы с ними. По каждому процессу показан пример работы.
Благодаря книге можно получить определенные методы, которые помогут сократить сроки разработки и уменьшить количество ошибок. Книга довольно трудна для первого прочтения, поэтому начинать лучше с книг под пунктами два и три.
2. «Психбольница в руках пациентов, или почему высокие технологии сводят нас с ума» Алан Купер
Алан Купер первым заговорил о том, что проектирование продуктов должно осуществляться до непосредственной разработки и является этапом первостепенной важности. Большинство продуктов функционирует и взаимодействует с пользователями только на основе задумки создателей, игнорируя реальные потребности использования.
Из книги следует мысль, что для продукта повышение качества взаимодействия важнее, чем снижение издержек. Для конечных пользователя удобный продукт всегда предпочтителен, чем неудобный многофункциональный.
3. «UX-дизайн. Практическое руководство по проектированию опыта взаимодействия» Расс Унгер и Кэролайн Чендлер. Отличная книга для совсем начинающих специалистов. В книге даются основы основ проработки бизнес-идеи, определения требований, проведению интервью, подготовке документации и формированию взаимодействия пользователей и продукта.
Книга помогает понять, с чего следует начать в первую очередь, как одни этапы разработки продукта взаимодействуют с другими. Очень много примеров и шаблонов. Практически сразу же после прочтения книги можно приступить к работе.
4. «Современные методы описания функциональных требований к системам» Алистер Коберн
В оригинале книга называется "Writing Effective Use Cases", что наиболее полно отражает ее суть. В книге описаны методы и примеры создания юз кейсов на основе практического опыта автора. Книга помогает понять, как использовать юз кейсы при описании сложных многофункциональных систем и вариантов взаимодействия с ними.
5. «Пользовательские истории. Искусство гибкой разработки ПО» Джефф Паттон
Книга рассказывает про пользовательские истории (юзер стори) как о методе описания требований к проектируемому продукту.
Пользовательские истории довольно просто и доходчиво дают понимание заказчику, команде, пользователям о задачах и функциях разрабатываемой системы. Пользовательские истории находятся на более высоком уровне абстракции. На их основе удобно описывать сценарии взаимодействия (юз кейсы).
1. «Разработка требований к программному обеспечению» Карл Вигерс и Джой Битти
Классика среди всех книг по разработке требований. В книге подробно даются процессы сбора, выявления, обработки требований и работы с ними. По каждому процессу показан пример работы.
Благодаря книге можно получить определенные методы, которые помогут сократить сроки разработки и уменьшить количество ошибок. Книга довольно трудна для первого прочтения, поэтому начинать лучше с книг под пунктами два и три.
2. «Психбольница в руках пациентов, или почему высокие технологии сводят нас с ума» Алан Купер
Алан Купер первым заговорил о том, что проектирование продуктов должно осуществляться до непосредственной разработки и является этапом первостепенной важности. Большинство продуктов функционирует и взаимодействует с пользователями только на основе задумки создателей, игнорируя реальные потребности использования.
Из книги следует мысль, что для продукта повышение качества взаимодействия важнее, чем снижение издержек. Для конечных пользователя удобный продукт всегда предпочтителен, чем неудобный многофункциональный.
3. «UX-дизайн. Практическое руководство по проектированию опыта взаимодействия» Расс Унгер и Кэролайн Чендлер. Отличная книга для совсем начинающих специалистов. В книге даются основы основ проработки бизнес-идеи, определения требований, проведению интервью, подготовке документации и формированию взаимодействия пользователей и продукта.
Книга помогает понять, с чего следует начать в первую очередь, как одни этапы разработки продукта взаимодействуют с другими. Очень много примеров и шаблонов. Практически сразу же после прочтения книги можно приступить к работе.
4. «Современные методы описания функциональных требований к системам» Алистер Коберн
В оригинале книга называется "Writing Effective Use Cases", что наиболее полно отражает ее суть. В книге описаны методы и примеры создания юз кейсов на основе практического опыта автора. Книга помогает понять, как использовать юз кейсы при описании сложных многофункциональных систем и вариантов взаимодействия с ними.
5. «Пользовательские истории. Искусство гибкой разработки ПО» Джефф Паттон
Книга рассказывает про пользовательские истории (юзер стори) как о методе описания требований к проектируемому продукту.
Пользовательские истории довольно просто и доходчиво дают понимание заказчику, команде, пользователям о задачах и функциях разрабатываемой системы. Пользовательские истории находятся на более высоком уровне абстракции. На их основе удобно описывать сценарии взаимодействия (юз кейсы).
Как управлять удаленной командой в текущих реалиях
Принцип 1. К каждому сотруднику — свой подход. Оцените зрелость вашей удаленной команды. В ней одновременно могут быть и опытные специалисты с высокой самомотивацией, которые понимают цели и задачи бизнеса, и рядовые сотрудники, с которыми важно работать внимательнее. Проранжируйте членов команды с точки зрения их опыта, уровня мотивации и ответственности, чтобы найти баланс дисциплины и самоконтроля, необходимый каждому из них.
Принцип 2. Уважайте культурные особенности региона
В каждой компании есть корпоративная культура, которая задает определенные рамки коммуникации и подходы к работе. Однако помимо этого существует так называемый национальный культурный код, который не меняется десятилетиями, если вообще меняется. И самый умный выход — повернуть национальное многообразие удаленной команды в пользу бизнеса. Направляйте нужных людей для решения нужных задач и комбинируйте противоположные точки зрения.
Принцип 3. Поддерживайте коммуникацию с удаленными командами убедительнее, чем со стандартными
Многочисленные исследования подтверждают, что наши слова и голос отвечают только за половину передачи сообщения. Другая половина — невербальные сигналы: поза, положение относительно собеседника, выражение лица, взгляд. Очевидно, что в этом плане дистанционная коммуникация неполноценна, и чтобы сделать ее эффективной, нужно больше усилий.
Принцип 4. Выстраивайте горизонтальные связи
Удаленная команда тем эффективнее, чем крепче горизонтальные связи внутри нее. Здесь нет отличия от стандартных команд, но с одним исключением: с удаленной командой ситуация обстоит сложнее, ведь сотрудник офиса в Волгограде вряд ли выпьет утренний кофе с коллегой с Урала. Чтобы нивелировать это, вовлекайте разных членов своей команды в кросс-функциональные проекты — если необходимо, выдумывайте их. Такие проекты не только позволят сотрудникам лучше узнать бизнес, но и повысят мотивацию.
Принцип 5. Даже если команда удаленная, организуйте личные встречи по крайней мере раз в год
Составьте рабочее расписание, в которое будет включена сессия знакомства. Кроме нее включите в повестку дня воркшопы или брейнсторминг, которые помогут членам команды сформулировать глобальные цели и обсудить проблемы. И, конечно, важен неформальный тимбилдинг: совместные развлечения сплачивают команду.
Совершенно новый вызов - релокации, встал перед руководителями IT-команд в прошлом году. Когда команда релоцируется, то неизбежно меняются подходы к управлению.
Принцип 1. К каждому сотруднику — свой подход. Оцените зрелость вашей удаленной команды. В ней одновременно могут быть и опытные специалисты с высокой самомотивацией, которые понимают цели и задачи бизнеса, и рядовые сотрудники, с которыми важно работать внимательнее. Проранжируйте членов команды с точки зрения их опыта, уровня мотивации и ответственности, чтобы найти баланс дисциплины и самоконтроля, необходимый каждому из них.
Принцип 2. Уважайте культурные особенности региона
В каждой компании есть корпоративная культура, которая задает определенные рамки коммуникации и подходы к работе. Однако помимо этого существует так называемый национальный культурный код, который не меняется десятилетиями, если вообще меняется. И самый умный выход — повернуть национальное многообразие удаленной команды в пользу бизнеса. Направляйте нужных людей для решения нужных задач и комбинируйте противоположные точки зрения.
Принцип 3. Поддерживайте коммуникацию с удаленными командами убедительнее, чем со стандартными
Многочисленные исследования подтверждают, что наши слова и голос отвечают только за половину передачи сообщения. Другая половина — невербальные сигналы: поза, положение относительно собеседника, выражение лица, взгляд. Очевидно, что в этом плане дистанционная коммуникация неполноценна, и чтобы сделать ее эффективной, нужно больше усилий.
Принцип 4. Выстраивайте горизонтальные связи
Удаленная команда тем эффективнее, чем крепче горизонтальные связи внутри нее. Здесь нет отличия от стандартных команд, но с одним исключением: с удаленной командой ситуация обстоит сложнее, ведь сотрудник офиса в Волгограде вряд ли выпьет утренний кофе с коллегой с Урала. Чтобы нивелировать это, вовлекайте разных членов своей команды в кросс-функциональные проекты — если необходимо, выдумывайте их. Такие проекты не только позволят сотрудникам лучше узнать бизнес, но и повысят мотивацию.
Принцип 5. Даже если команда удаленная, организуйте личные встречи по крайней мере раз в год
Составьте рабочее расписание, в которое будет включена сессия знакомства. Кроме нее включите в повестку дня воркшопы или брейнсторминг, которые помогут членам команды сформулировать глобальные цели и обсудить проблемы. И, конечно, важен неформальный тимбилдинг: совместные развлечения сплачивают команду.
Совершенно новый вызов - релокации, встал перед руководителями IT-команд в прошлом году. Когда команда релоцируется, то неизбежно меняются подходы к управлению.
👍1
Как ускорять А/В-тестирование
В своих выступлениях я часто говорю, что А/В-тест - достаточно долгий инструмент для проверки гипотез. Но есть лайфхаки, как его можно ускорить:
1. Определите ключевые метрики: перед началом тестирования определите, какие метрики будут являться ключевыми для оценки результатов. Это поможет сократить объем тестирования и сфокусироваться на наиболее значимых метриках. Определите наиболее важные изменения: сфокусируйтесь на наиболее значимых изменениях, которые могут повлиять на ключевые метрики. Это поможет сократить время на разработку и тестирование.
2. Уменьшите размер выборки: уменьшение размера выборки поможет ускорить А/B-тестирование, но необходимо убедиться, что результаты остаются статистически значимыми.
3. Используйте CUPED - это метод, который позволяет уменьшить влияние искажений на результаты исследования, связанных с различными факторами, которые могут повлиять на конечный результат. Он основан на использовании контрольной группы, которая исключена из эксперимента, но используется для сравнения с тестовой группой и оценки эффекта воздействия на тестовой группе. Кроме того, метод CUPED использует методы разности в различных периодах времени для более точной оценки эффекта воздействия.
4. Используйте стратификацию - это метод, который используется для улучшения точности результатов, путем разделения выборки на группы (страты), имеющие общие характеристики. Каждая страта может быть подвергнута отдельному анализу, и в конечном итоге результаты могут быть обобщены для всей выборки. Этот метод позволяет более точно определить различия между группами и улучшить точность выводов на основе выборки.
5. Отсеките выбросы. Выброс - это экстремальные значение в данных, которые находятся далеко за пределами других наблюдений. Например, в приложении пользователи тратят в среднем от 8 до 12 долларов, и внезапно появляется пользователь, который заплатил 100 долларов. Выбросы в данных А/Б-тестов увеличивают дисперсию метрики и длительность теста, а также смещают оценку среднего. Это может привести, в итоге, к неверному решению о принятии проверяемой гипотезы
6. Используйте многоразовые шаблоны: создание многоразовых шаблонов для элементов дизайна и контента сайта или приложения может значительно сократить время на разработку и внедрение изменений.
7. Используйте предварительное тестирование: проведите предварительное тестирование, чтобы проверить, какие изменения наиболее эффективны, прежде чем начать полноценное A/B-тестирование
В своих выступлениях я часто говорю, что А/В-тест - достаточно долгий инструмент для проверки гипотез. Но есть лайфхаки, как его можно ускорить:
1. Определите ключевые метрики: перед началом тестирования определите, какие метрики будут являться ключевыми для оценки результатов. Это поможет сократить объем тестирования и сфокусироваться на наиболее значимых метриках. Определите наиболее важные изменения: сфокусируйтесь на наиболее значимых изменениях, которые могут повлиять на ключевые метрики. Это поможет сократить время на разработку и тестирование.
2. Уменьшите размер выборки: уменьшение размера выборки поможет ускорить А/B-тестирование, но необходимо убедиться, что результаты остаются статистически значимыми.
3. Используйте CUPED - это метод, который позволяет уменьшить влияние искажений на результаты исследования, связанных с различными факторами, которые могут повлиять на конечный результат. Он основан на использовании контрольной группы, которая исключена из эксперимента, но используется для сравнения с тестовой группой и оценки эффекта воздействия на тестовой группе. Кроме того, метод CUPED использует методы разности в различных периодах времени для более точной оценки эффекта воздействия.
4. Используйте стратификацию - это метод, который используется для улучшения точности результатов, путем разделения выборки на группы (страты), имеющие общие характеристики. Каждая страта может быть подвергнута отдельному анализу, и в конечном итоге результаты могут быть обобщены для всей выборки. Этот метод позволяет более точно определить различия между группами и улучшить точность выводов на основе выборки.
5. Отсеките выбросы. Выброс - это экстремальные значение в данных, которые находятся далеко за пределами других наблюдений. Например, в приложении пользователи тратят в среднем от 8 до 12 долларов, и внезапно появляется пользователь, который заплатил 100 долларов. Выбросы в данных А/Б-тестов увеличивают дисперсию метрики и длительность теста, а также смещают оценку среднего. Это может привести, в итоге, к неверному решению о принятии проверяемой гипотезы
6. Используйте многоразовые шаблоны: создание многоразовых шаблонов для элементов дизайна и контента сайта или приложения может значительно сократить время на разработку и внедрение изменений.
7. Используйте предварительное тестирование: проведите предварительное тестирование, чтобы проверить, какие изменения наиболее эффективны, прежде чем начать полноценное A/B-тестирование