Часть 3 (финальная), продолжение записи лекции «Как создавать полезные продукты»:
Тестирование гипотез:
Есть 3 инструмента. Обычно они используются друг за другом, но не стоит доходить до маразма :) Они отличаются степенью точности и трудозатратностью.
- Предварительный анализ:
Если у вас уже существующий продукт, то у вас наверняка уже есть какие-то логи, AppMetrica или что-то такое, то вы можете посмотреть, что вообще происходит в продукте, и поймете, что важнее для пользователей.
- Качественные исследования (интервью пользователей):
В Яндексе для этого есть отдельная комната, где мы спрашиваем людей о том, какие проблемы у них есть, уточняем, подойдет ли им вот «такое» или «такое» решение.
В начале тестирования важно проверить, что этот тот человек, который вам нужен: сделать какое-то проверочное задание или задать контрольные вопросы. После этого уже можно делать выводы, можем ли мы этому человеку доверять.
На этом этапе можно достаточно дешево можно в фотошопе или Скетче нарисовать прототип , сделать его кликабельны в InVision и дать посмотреть пользователю.
По результатам мы уже можем понять, чем можно помочь, как можно решить задачу пользователя. В итоге формируем минимальный ценный продукт.
- Количественные исследования (A/B тестирование):
Преимущество в том, что можно проверить гипотезы на большом количестве человек. Если коротко: у нас есть группа А - у которых ничего не меняется, и группа В такого же размера - экспериментальная группа с нашей новинкой.
Для этих групп мы считаем метрики. Важно не забывать про статистическую значимость. Статистическая значимость в Яндексе обычно используется 99.9%, что соответствует P-value < 0.01.
Если все это совместить с тем, о чем мы говорили до этого, о том как можно формировать идеи, о том как их тестировать, то все это может выглядеть так:
- У вас есть идея, которую вы можете описать за 1-2 часа вместе с друзьями и коллегами;
- Начнете задавать вопросы: А какие вещи мы считаем более рискованными? Какие вопросы мы должны задать к этим утверждениями?
- Протестируете решение;
- Соберете прототип;
- Проведете количественно тестирование.
И ещё книги по теме:
«The Most Powerful Way to Turn Clicks Into Customers (Dan Siroker and Pete Koomen)»,
High Output Management (Andrew S. Grove)
Презентация Ильи тут - https://yadi.sk/i/gWcgZW803Neq5R
#product #book
@projectsproducts
Тестирование гипотез:
Есть 3 инструмента. Обычно они используются друг за другом, но не стоит доходить до маразма :) Они отличаются степенью точности и трудозатратностью.
- Предварительный анализ:
Если у вас уже существующий продукт, то у вас наверняка уже есть какие-то логи, AppMetrica или что-то такое, то вы можете посмотреть, что вообще происходит в продукте, и поймете, что важнее для пользователей.
- Качественные исследования (интервью пользователей):
В Яндексе для этого есть отдельная комната, где мы спрашиваем людей о том, какие проблемы у них есть, уточняем, подойдет ли им вот «такое» или «такое» решение.
В начале тестирования важно проверить, что этот тот человек, который вам нужен: сделать какое-то проверочное задание или задать контрольные вопросы. После этого уже можно делать выводы, можем ли мы этому человеку доверять.
На этом этапе можно достаточно дешево можно в фотошопе или Скетче нарисовать прототип , сделать его кликабельны в InVision и дать посмотреть пользователю.
По результатам мы уже можем понять, чем можно помочь, как можно решить задачу пользователя. В итоге формируем минимальный ценный продукт.
- Количественные исследования (A/B тестирование):
Преимущество в том, что можно проверить гипотезы на большом количестве человек. Если коротко: у нас есть группа А - у которых ничего не меняется, и группа В такого же размера - экспериментальная группа с нашей новинкой.
Для этих групп мы считаем метрики. Важно не забывать про статистическую значимость. Статистическая значимость в Яндексе обычно используется 99.9%, что соответствует P-value < 0.01.
Если все это совместить с тем, о чем мы говорили до этого, о том как можно формировать идеи, о том как их тестировать, то все это может выглядеть так:
- У вас есть идея, которую вы можете описать за 1-2 часа вместе с друзьями и коллегами;
- Начнете задавать вопросы: А какие вещи мы считаем более рискованными? Какие вопросы мы должны задать к этим утверждениями?
- Протестируете решение;
- Соберете прототип;
- Проведете количественно тестирование.
И ещё книги по теме:
«The Most Powerful Way to Turn Clicks Into Customers (Dan Siroker and Pete Koomen)»,
High Output Management (Andrew S. Grove)
Презентация Ильи тут - https://yadi.sk/i/gWcgZW803Neq5R
#product #book
@projectsproducts
Yandex Disk
How to Create Products Customers Love v7.pdf
View and download from Yandex Disk
В марте запускается повторно курс, который будет полезен и продактам и проджектам, особенно в начале пути или тем, кто только начал интересоваться гибкими методологиями:
«Getting Started with Agile and Design Thinking»
https://www.futurelearn.com/courses/agile-meets-design-thinking/#section-topics
#project #product #foundation
«Getting Started with Agile and Design Thinking»
https://www.futurelearn.com/courses/agile-meets-design-thinking/#section-topics
#project #product #foundation
FutureLearn
Agile and Design Thinking - Online Course
Learn the basics of agile and design thinking, and how to create better digital products with this online course.
Недавно разговаривала с человеком, который хочет стать менеджером проектов в IT, у него есть схожий опыт работы, но в другой сфере.
И одна из причин смены его области работы была в том, что не хочется больше работать с людьми, которые пытаются тебя обмануть, больше на тебе заработать или даже получить взятку.
Обычно в крупных компаниях и тем более в тех, чьи акции котируются на бирже NASDAQ (например, МТС, Яндекс, Facebook,…) есть Правила корпоративной этики, что в целом должно исключать такие неприятные ситуации.
А для PM есть еще дополнительный стандарт, с которым соглашаются и по которому должны работать все сертифицированные специалисты PMI. Это «Кодекс профессиональной этики и поведения»
Полный текст на русском можно почитать по ссылке: http://www.pmi.org/-/media/pmi/documents/public/pdf/ethics/pmi-code-of-ethics.pdf?sclangtemp=ru-RU
Составители говорят, что «настоящий Кодекс поможет нам принимать мудрые решения, особенно в трудных ситуациях, когда наша целостность и наши ценности будут поставлены под угрозу.»
На самом деле, просто если вы будете следовать этим правилам, то людям будет приятнее и понятнее с вами работать.
Вот несколько пунктов из Кодекса:
- Мы делаем то, что обещаем;
- Мы храним доверенную нам частную и конфиденциальную информацию;
- Мы ведем себя профессионально, даже когда это не взаимно;
- Мы не ведем себя оскорбительно по отношению к другим;
- Мы не нанимаем и не увольняем, не поощряем и не наказываем сотрудников, а также не заключаем и не отклоняем контракты, основываясь на личных соображениях, включая среди прочего фаворитизм, непотизм и взяточничество;
- Мы не практикуем непорядочного поведения, преследующего личные цели или достижение целей за счет других;…..
#project #product
@projectsproducts
И одна из причин смены его области работы была в том, что не хочется больше работать с людьми, которые пытаются тебя обмануть, больше на тебе заработать или даже получить взятку.
Обычно в крупных компаниях и тем более в тех, чьи акции котируются на бирже NASDAQ (например, МТС, Яндекс, Facebook,…) есть Правила корпоративной этики, что в целом должно исключать такие неприятные ситуации.
А для PM есть еще дополнительный стандарт, с которым соглашаются и по которому должны работать все сертифицированные специалисты PMI. Это «Кодекс профессиональной этики и поведения»
Полный текст на русском можно почитать по ссылке: http://www.pmi.org/-/media/pmi/documents/public/pdf/ethics/pmi-code-of-ethics.pdf?sclangtemp=ru-RU
Составители говорят, что «настоящий Кодекс поможет нам принимать мудрые решения, особенно в трудных ситуациях, когда наша целостность и наши ценности будут поставлены под угрозу.»
На самом деле, просто если вы будете следовать этим правилам, то людям будет приятнее и понятнее с вами работать.
Вот несколько пунктов из Кодекса:
- Мы делаем то, что обещаем;
- Мы храним доверенную нам частную и конфиденциальную информацию;
- Мы ведем себя профессионально, даже когда это не взаимно;
- Мы не ведем себя оскорбительно по отношению к другим;
- Мы не нанимаем и не увольняем, не поощряем и не наказываем сотрудников, а также не заключаем и не отклоняем контракты, основываясь на личных соображениях, включая среди прочего фаворитизм, непотизм и взяточничество;
- Мы не практикуем непорядочного поведения, преследующего личные цели или достижение целей за счет других;…..
#project #product
@projectsproducts
Понравилась статья на Medium про сценарии, о которых не нужно забывать, когда разрабатываете дизайн продукта/проекта.
Классный чеклист, который стоит взять в работу. Пригодится и менеджерам, и проектировщикам интерфейсов, дизайнерам.
Вот несколько пунктов из статьи - то о чем мы всегда должны помнить при проектировании интерфейсов:
1. The Splash Screen
2. The Forgot Password Flow
3. The “Thanks for Signing Up” Page
4. The Welcome Email
5. The Terms of Service & Privacy Pages
6. The User Onboarding
…..
50. The “Delete and Recover” Flow
Вообще при создании проектов и продуктов приходится рисовать миллионы макетов, продумывать множество кейсов, и очень полезно, особенно в больших командах, иметь чеклист, где будут перечислены особенности вашей системы, которые могут касаться не только UX, например:
- если у вас пользователи с разными ролями, то как для каждой из ролей будет вести себя система?
- если вы взаимодействуете со сторонними сервисами, то что вы покажете юзеру, если одна из них перестанет отвечать?
- если у вас интерфейс на нескольких языках, но одна статья еще не переведена?
- а если на сайт одновременно зайдет 10.000 человек, то мы справимся?
- и тд и тп.
Ссылка на статью:
https://medium.com/ux-power-tools/50-things-you-probably-forgot-to-design-7a288b0ef914
Вопросы отправляйте на почту elena.kotina@gmail.com
@projectsproducts
#project #product
Классный чеклист, который стоит взять в работу. Пригодится и менеджерам, и проектировщикам интерфейсов, дизайнерам.
Вот несколько пунктов из статьи - то о чем мы всегда должны помнить при проектировании интерфейсов:
1. The Splash Screen
2. The Forgot Password Flow
3. The “Thanks for Signing Up” Page
4. The Welcome Email
5. The Terms of Service & Privacy Pages
6. The User Onboarding
…..
50. The “Delete and Recover” Flow
Вообще при создании проектов и продуктов приходится рисовать миллионы макетов, продумывать множество кейсов, и очень полезно, особенно в больших командах, иметь чеклист, где будут перечислены особенности вашей системы, которые могут касаться не только UX, например:
- если у вас пользователи с разными ролями, то как для каждой из ролей будет вести себя система?
- если вы взаимодействуете со сторонними сервисами, то что вы покажете юзеру, если одна из них перестанет отвечать?
- если у вас интерфейс на нескольких языках, но одна статья еще не переведена?
- а если на сайт одновременно зайдет 10.000 человек, то мы справимся?
- и тд и тп.
Ссылка на статью:
https://medium.com/ux-power-tools/50-things-you-probably-forgot-to-design-7a288b0ef914
Вопросы отправляйте на почту elena.kotina@gmail.com
@projectsproducts
#project #product
Medium
50 Things You [Probably] Forgot To Design
Every PM: “I’m not mad, I’m just disappointed…”
#project
Подготовила подборку про то как стать сертифицированным специалистом в сфере управления проектами.
Наиболее известные сертификаты в России:
- Project Management Professional (PMP) от PMI (на базе стандарта по управлению проектами The Guide to the PMBOK® - на русском про сертификацию можно почитать тут https://pmi.ru/certificates/
- PRINCE2™ by APM Group - коротко тут https://newmotivations.ru/ru/prince2/
- IPMA (Россия в IPMA представлена национальной ассоциацией управления проектами СОВНЕТ) - http://www.sovnet.ru/specialists/
- РМЕ® (это российский сертификат от PM Expert) - http://www.pmexpert.ru/services/certification/pme/
- ПМ СТАНДАРТ (еще один российский сертификат от «Центра оценки и развития проектного управления») - https://www.isopm.ru/sertifikatsiya/information/
Количество специалистов с разными сертификатами:
Подготовила подборку про то как стать сертифицированным специалистом в сфере управления проектами.
Наиболее известные сертификаты в России:
- Project Management Professional (PMP) от PMI (на базе стандарта по управлению проектами The Guide to the PMBOK® - на русском про сертификацию можно почитать тут https://pmi.ru/certificates/
- PRINCE2™ by APM Group - коротко тут https://newmotivations.ru/ru/prince2/
- IPMA (Россия в IPMA представлена национальной ассоциацией управления проектами СОВНЕТ) - http://www.sovnet.ru/specialists/
- РМЕ® (это российский сертификат от PM Expert) - http://www.pmexpert.ru/services/certification/pme/
- ПМ СТАНДАРТ (еще один российский сертификат от «Центра оценки и развития проектного управления») - https://www.isopm.ru/sertifikatsiya/information/
Количество специалистов с разными сертификатами:
Как сформулировать свое видение о будущем продукте?
Есть фреймворк для создания бизнес-модели «Lean Canvas» (автор Ash Maurya, это адаптация Business Model Canvas), в которой есть блоки ключевых вопросов, которые помогают сформулировать ваши гипотезы для MVP (Minimum Viable Product):
1. Какие есть проблемы пользователя? («какие три ключевые проблемы мы хотим решить?»)
2. Кто ваши Целевые клиенты?
3. Решение. (Как пользователь решает эти проблемы сейчас? Если человек эту проблему сейчас вообще не решает, то она ему скорее всего не важна. А как предлагаете решать ее вы?)
4. Конкурентное преимущество? (Почему клиенты должны выбирать вас?)
5. Пути к пользователю - каналы. (Они все могут стоить разных денег)
6. Структура расходов и Структура доходов (рекламная модель, подписка, …)
7. Ключевые метрики (хорошо бы привязывать к каждому блоку этой модели)
8. Скрытое преимущество (Чем уникальным обладаете именно вы? Уникальна технология/патент, крутая команда, большая аудитория,…)
Таким образом на одном листе А4 у вас будет полное представление о вашем продукте.
Обратите внимание, что лишь 1/9 часть этой модели занимает описание решения, которые вы предлагаете пользователям.
И тут нужно вспомнить цитату Дэйва МакКлура (500 Startups): Вашим покупателям неинтересно ваше решение. Их интересуют только их проблемы.
При разработке продукта не забывайте об остальных частях вашей бизнес-идеи.
Ссылка на модель на русском языке:
http://ru.wiki.rademade.com/uploads/ckeditor/pictures/584a81a93152b744a4d44d4b/contentTable28rus1.jpg
Кстати, есть онлайн проект самого Ash https://leanstack.com, где вы можете создать свою доску Lean Canvas. Ну и конечно есть много аналогичных сервисов, например realtimeboard.com и другие.
#product
@projectsproducts
Есть фреймворк для создания бизнес-модели «Lean Canvas» (автор Ash Maurya, это адаптация Business Model Canvas), в которой есть блоки ключевых вопросов, которые помогают сформулировать ваши гипотезы для MVP (Minimum Viable Product):
1. Какие есть проблемы пользователя? («какие три ключевые проблемы мы хотим решить?»)
2. Кто ваши Целевые клиенты?
3. Решение. (Как пользователь решает эти проблемы сейчас? Если человек эту проблему сейчас вообще не решает, то она ему скорее всего не важна. А как предлагаете решать ее вы?)
4. Конкурентное преимущество? (Почему клиенты должны выбирать вас?)
5. Пути к пользователю - каналы. (Они все могут стоить разных денег)
6. Структура расходов и Структура доходов (рекламная модель, подписка, …)
7. Ключевые метрики (хорошо бы привязывать к каждому блоку этой модели)
8. Скрытое преимущество (Чем уникальным обладаете именно вы? Уникальна технология/патент, крутая команда, большая аудитория,…)
Таким образом на одном листе А4 у вас будет полное представление о вашем продукте.
Обратите внимание, что лишь 1/9 часть этой модели занимает описание решения, которые вы предлагаете пользователям.
И тут нужно вспомнить цитату Дэйва МакКлура (500 Startups): Вашим покупателям неинтересно ваше решение. Их интересуют только их проблемы.
При разработке продукта не забывайте об остальных частях вашей бизнес-идеи.
Ссылка на модель на русском языке:
http://ru.wiki.rademade.com/uploads/ckeditor/pictures/584a81a93152b744a4d44d4b/contentTable28rus1.jpg
Кстати, есть онлайн проект самого Ash https://leanstack.com, где вы можете создать свою доску Lean Canvas. Ну и конечно есть много аналогичных сервисов, например realtimeboard.com и другие.
#product
@projectsproducts
Кстати, к Новому году как раз :)
Нашла подробную статью с примером заполнения Lean Canvas для Санта Клауса: http://ru.wiki.rademade.com/lean-canvas-santa
#product
@projectsproducts
Нашла подробную статью с примером заполнения Lean Canvas для Санта Клауса: http://ru.wiki.rademade.com/lean-canvas-santa
#product
@projectsproducts
Продолжу выкладывать записи лекции.
Сегодня «Школа менеджмента Яндекса — О продуктовом мышлении.» (Юрий Подорожный)
Со временем сложность систем имеет свойство накапливаться.
В связи с этим нужно вспомнить слова Джона Галла (теоретика в области систем):
«Сложная система, созданная с нуля, никогда не заработает.
Начинать надо с работающей простой системы.»
Всегда важно начинать с простой работоспособной системы.
В какой-то момент развития вашей системы вокруг становятся много людей, и у каждого из них свое мнение о развитии продукта и создания новых фич.
Аргументы, которые вам могут приводить:
- «Просят пользователи»
- «Есть у конкурентов»
- «Требует начальство»
- «Василий написал, что это круто»
- «Команда хочет»
- «Пишут в интернете»
- «Просит наш главный клиент».
И продакт-менеджеру (или человеку ответственному за продукт) нужно уметь ответить нет.
Мораль: необходимо развить в себе умение говорить «нет». Не «позже» или «может быть», а «нет».
Если мы научились говорить «нет», то как же дальше выбирать, что стоит делать, а что нет?
Поговорим теперь о важном и неважном.
И тут есть несколько вопросов, которые нужно себе задавать:
- Насколько это соотносится с вашим видением продукта?
Опросы, мнения пользователей, метрики и т.д. — это далеко не
всё.
Любой может провести опрос, посмотреть на метрики или найти аналитику.
Только вы определяете какую проблему решает ваш продукт и
как он это делает.
- Будет ли это иметь смысл через 5 лет?
- Что произойдёт, если этого не делать? (проиграем ли мы конкурентам? продолжит ли наш продукт существовать?)
- Увеличит ли это прибыль?
- Сколько будет стоить поддержка? (хватит ли у вас ресурсов, чтобы поддерживать эту фичу в следующем году или следующие 10 лет?)
Продолжение следует…
Ссылка на видео - https://www.youtube.com/watch?v=m8h_KsDovRw&list=PLEs8EuAPI73Bj78n7-BIW3s1we0r15yJl&index=3
#product
@projectsproducts
Сегодня «Школа менеджмента Яндекса — О продуктовом мышлении.» (Юрий Подорожный)
Со временем сложность систем имеет свойство накапливаться.
В связи с этим нужно вспомнить слова Джона Галла (теоретика в области систем):
«Сложная система, созданная с нуля, никогда не заработает.
Начинать надо с работающей простой системы.»
Всегда важно начинать с простой работоспособной системы.
В какой-то момент развития вашей системы вокруг становятся много людей, и у каждого из них свое мнение о развитии продукта и создания новых фич.
Аргументы, которые вам могут приводить:
- «Просят пользователи»
- «Есть у конкурентов»
- «Требует начальство»
- «Василий написал, что это круто»
- «Команда хочет»
- «Пишут в интернете»
- «Просит наш главный клиент».
И продакт-менеджеру (или человеку ответственному за продукт) нужно уметь ответить нет.
Мораль: необходимо развить в себе умение говорить «нет». Не «позже» или «может быть», а «нет».
Если мы научились говорить «нет», то как же дальше выбирать, что стоит делать, а что нет?
Поговорим теперь о важном и неважном.
И тут есть несколько вопросов, которые нужно себе задавать:
- Насколько это соотносится с вашим видением продукта?
Опросы, мнения пользователей, метрики и т.д. — это далеко не
всё.
Любой может провести опрос, посмотреть на метрики или найти аналитику.
Только вы определяете какую проблему решает ваш продукт и
как он это делает.
- Будет ли это иметь смысл через 5 лет?
- Что произойдёт, если этого не делать? (проиграем ли мы конкурентам? продолжит ли наш продукт существовать?)
- Увеличит ли это прибыль?
- Сколько будет стоить поддержка? (хватит ли у вас ресурсов, чтобы поддерживать эту фичу в следующем году или следующие 10 лет?)
Продолжение следует…
Ссылка на видео - https://www.youtube.com/watch?v=m8h_KsDovRw&list=PLEs8EuAPI73Bj78n7-BIW3s1we0r15yJl&index=3
#product
@projectsproducts
YouTube
002. Школа менеджмента — О продуктовом мышлении. Юрий Подорожный
Рассказ о методах мышления при принятии решений о развитии продукта. Как отделять важное от неважного, выбирать приоритеты и доводить проекты до реализации.
https://yadi.sk/i/XTn44y8S3NmteL
https://yadi.sk/i/XTn44y8S3NmteL
Часть 2, продолжение записи лекции «О продуктовом мышлении»:
Переходим ближе к практике.
Поговорим об идеальном пути.
Если идти ровно по продуктовой воронке, то получается идеальный продукт, но когда он сталкивается с реальным миром, то все начинает идти не так. А все потому, что пользователи часто используют продукт не так, как вы задумали.
И если идти по идеальной воронке, то часто бывают проблемы на стыке взаимодействий:
1. Дизайнер подумал только про идеальный сценарий.
2. Разработчик нашёл и другие сценарии, но у него нет
времени думать о том как решить проблему.
3. Разработчик предполагает как должно быть. И делает как
считает нужным.
4. Так ошибка проектирования становится ошибкой в продукте.
Чтобы такого не было, очень полезно задавать себе вопросы:
- Что если пользователь не читал инструкцию?
- Что если во время отправки данных пропало соединение?
- Что если пользователь прервался во время выполнения
действия?
- Что если пользователь не подтвердил адрес почты?
- Что случится, если в этом месте всё пойдёт не по плану?
- Что если изменится место или контекст пользователя?(человек будет использовать ваше приложение из другой страны или города?)
Еще расскажу про самые распространённые сценарии, которые стоит учитывать при разработке:
- Пустые экраны
- «Ничего не найдено» в результатах поиска
- Отображение ошибок (валидация, получение, отправка)
- Потеря соединения с интернетом
- Местоположение пользователя
- Контекст пользователя
- Локализация (текст на другом языке может занимать сильно больше места, чем вы оставили на макете)
О сценариях, про которые не стоит забывать, я писала в посте - https://tttttt.me/projectsproducts/30
Кроме этого полезно пользоваться методом от обратного. Когда вы задаете себе вопрос: «Как сделать самый неудобный интерфейс на свете?» (Почитать подробнее: Ководство Артемия Лебедева. § 150. От обратного - https://www.artlebedev.ru/kovodstvo/sections/150/)
Резюмируя: Мир не идеален, поэтому помните о пограничных случаях. Ожидайте неожиданное.
Продолжение следует…
Ссылка на презентацию - https://yadi.sk/i/XTn44y8S3NmteL
#product #book
@projectsproducts
Переходим ближе к практике.
Поговорим об идеальном пути.
Если идти ровно по продуктовой воронке, то получается идеальный продукт, но когда он сталкивается с реальным миром, то все начинает идти не так. А все потому, что пользователи часто используют продукт не так, как вы задумали.
И если идти по идеальной воронке, то часто бывают проблемы на стыке взаимодействий:
1. Дизайнер подумал только про идеальный сценарий.
2. Разработчик нашёл и другие сценарии, но у него нет
времени думать о том как решить проблему.
3. Разработчик предполагает как должно быть. И делает как
считает нужным.
4. Так ошибка проектирования становится ошибкой в продукте.
Чтобы такого не было, очень полезно задавать себе вопросы:
- Что если пользователь не читал инструкцию?
- Что если во время отправки данных пропало соединение?
- Что если пользователь прервался во время выполнения
действия?
- Что если пользователь не подтвердил адрес почты?
- Что случится, если в этом месте всё пойдёт не по плану?
- Что если изменится место или контекст пользователя?(человек будет использовать ваше приложение из другой страны или города?)
Еще расскажу про самые распространённые сценарии, которые стоит учитывать при разработке:
- Пустые экраны
- «Ничего не найдено» в результатах поиска
- Отображение ошибок (валидация, получение, отправка)
- Потеря соединения с интернетом
- Местоположение пользователя
- Контекст пользователя
- Локализация (текст на другом языке может занимать сильно больше места, чем вы оставили на макете)
О сценариях, про которые не стоит забывать, я писала в посте - https://tttttt.me/projectsproducts/30
Кроме этого полезно пользоваться методом от обратного. Когда вы задаете себе вопрос: «Как сделать самый неудобный интерфейс на свете?» (Почитать подробнее: Ководство Артемия Лебедева. § 150. От обратного - https://www.artlebedev.ru/kovodstvo/sections/150/)
Резюмируя: Мир не идеален, поэтому помните о пограничных случаях. Ожидайте неожиданное.
Продолжение следует…
Ссылка на презентацию - https://yadi.sk/i/XTn44y8S3NmteL
#product #book
@projectsproducts
Telegram
Games of Projects and Products
Понравилась статья на Medium про сценарии, о которых не нужно забывать, когда разрабатываете дизайн продукта/проекта.
Классный чеклист, который стоит взять в работу. Пригодится и менеджерам, и проектировщикам интерфейсов, дизайнерам.
Вот несколько пунктов…
Классный чеклист, который стоит взять в работу. Пригодится и менеджерам, и проектировщикам интерфейсов, дизайнерам.
Вот несколько пунктов…
Часть 3 (заключительная), продолжение записи лекции «О продуктовом мышлении»:
А теперь пойдем дальше, когда мы уже поняли, что важное и не важное и пошли реализовывать.
Тут хочется рассказать историю про корабль Васса, который строили 3 года в Швеции (1625г), на первом же своем выходе корабль утонул.
Проводили расследование «Почему утонул корабль?». Расследование выяснило, что это была «Божья воля».
Позднее выяснились факты строительства самого корабля:
- Длина корабля менялась дважды по ходу строительства
- Добавили ещё одну палубу для пушек
- Количество пушек менялось несколько раз
- Позолоченные статуи, резные скульптуры. Дорого-богато
- Документации не было. Конструктор умер за год до трагедии
- Ширину корабля втайне от короля увеличили на 2,5 метра
Какие выводы можно сделать из этой истории?
- Фиксируйте объём работы
- Ведите документацию
- Тестируйте на реальных пользователях
- Вникайте в устройство вещей.
И еще совет:
Применяйте метод Сакити Тоёда:
«Задавая вопрос «Почему?» 5 раз, вы определяете характер проблемы, решение становится понятным.»
И в заключение еще одна цитата:
«Верить или не верить, это не имеет никакого значения. Интересно лишь задавать себе всё больше и больше вопросов.»- Бернар Вербер.
Ссылки на видео и презентацию были в постах выше.
#product
@projectsproducts
А теперь пойдем дальше, когда мы уже поняли, что важное и не важное и пошли реализовывать.
Тут хочется рассказать историю про корабль Васса, который строили 3 года в Швеции (1625г), на первом же своем выходе корабль утонул.
Проводили расследование «Почему утонул корабль?». Расследование выяснило, что это была «Божья воля».
Позднее выяснились факты строительства самого корабля:
- Длина корабля менялась дважды по ходу строительства
- Добавили ещё одну палубу для пушек
- Количество пушек менялось несколько раз
- Позолоченные статуи, резные скульптуры. Дорого-богато
- Документации не было. Конструктор умер за год до трагедии
- Ширину корабля втайне от короля увеличили на 2,5 метра
Какие выводы можно сделать из этой истории?
- Фиксируйте объём работы
- Ведите документацию
- Тестируйте на реальных пользователях
- Вникайте в устройство вещей.
И еще совет:
Применяйте метод Сакити Тоёда:
«Задавая вопрос «Почему?» 5 раз, вы определяете характер проблемы, решение становится понятным.»
И в заключение еще одна цитата:
«Верить или не верить, это не имеет никакого значения. Интересно лишь задавать себе всё больше и больше вопросов.»- Бернар Вербер.
Ссылки на видео и презентацию были в постах выше.
#product
@projectsproducts
Сегодня про книгу «Спринт» (Джейк Кнапп, Джон Зерацки, Брейден Ковитц. Все трое – сотрудники Google)
Спринт является составной частью широко известной концепции Scrum, но авторы его модифицировали.
Это 5 дней работы команды (до семи человек), которые занимаются только заранее обозначенными задачами.
Все расписано по дням:
- Понедельник - ставим цель (долгосрочную, на полгода-год).
- Вторник – каждый делает “набросок финального решения”.
- Среда - выбираем только один набросок.
- Четверг - делаем максимально возможный прототип. прорабатываем сториборд.
- Пятница - тестируем (всего 5 человек на тест! так как “85% проблем выявляются после интервью всего с пятью пользователями”.) и решаем, будет ли проект жить.
при тестировании главную ценность представляет именно спонтанная реакция потребителей
Пара цитат:
“Приступая к проведению «спринта» для своих стартапов, мы разрываем порочный круг бесконечных дебатов и делаем за неделю то, на что ушло бы несколько месяцев”.
“В целом демократия – прекрасная вещь, если речь идет об управлении государством, но она совершенно неуместна при проведении «спринтов»”.
#book
@projectsproducts
Спринт является составной частью широко известной концепции Scrum, но авторы его модифицировали.
Это 5 дней работы команды (до семи человек), которые занимаются только заранее обозначенными задачами.
Все расписано по дням:
- Понедельник - ставим цель (долгосрочную, на полгода-год).
- Вторник – каждый делает “набросок финального решения”.
- Среда - выбираем только один набросок.
- Четверг - делаем максимально возможный прототип. прорабатываем сториборд.
- Пятница - тестируем (всего 5 человек на тест! так как “85% проблем выявляются после интервью всего с пятью пользователями”.) и решаем, будет ли проект жить.
при тестировании главную ценность представляет именно спонтанная реакция потребителей
Пара цитат:
“Приступая к проведению «спринта» для своих стартапов, мы разрываем порочный круг бесконечных дебатов и делаем за неделю то, на что ушло бы несколько месяцев”.
“В целом демократия – прекрасная вещь, если речь идет об управлении государством, но она совершенно неуместна при проведении «спринтов»”.
#book
@projectsproducts
Когда писала про лекцию Юры Подорожного в Яндексе, обратила внимание на сайт, на который у него была ссылка:
http://www.productstrategymeanssayingno.com/
Это страница ярко иллюстрирующая одну мысль: «Продакт-менеджеру нужно уметь говорить нет!».
Сайт говорит: Saying no is hard, but a great product manager isn’t afraid to make tough decisions to keep their product bloat-free.
А здесь подробный рассказ про то, когда же нужно говорить «Да»:
https://blog.intercom.com/rarely-say-yes-to-feature-requests/
Собственно ровно это и было в лекции Юры, но если вы хотите почитать подробнее оригинал Интеркома, то ссылка выше.
#product
@projectsproducts
http://www.productstrategymeanssayingno.com/
Это страница ярко иллюстрирующая одну мысль: «Продакт-менеджеру нужно уметь говорить нет!».
Сайт говорит: Saying no is hard, but a great product manager isn’t afraid to make tough decisions to keep their product bloat-free.
А здесь подробный рассказ про то, когда же нужно говорить «Да»:
https://blog.intercom.com/rarely-say-yes-to-feature-requests/
Собственно ровно это и было в лекции Юры, но если вы хотите почитать подробнее оригинал Интеркома, то ссылка выше.
#product
@projectsproducts
Менеджер по продукту знает, куда ведёт продукт, а менеджер проекта знает, как успешно привести проект к финишу.
И оба должны быть сильными командными игроками, лидерами (в хорошем смысле), мотиваторами.
Смотрим новый ролик с примером отличного менеджера :)
https://www.youtube.com/watch?v=9MO1aY1xC80
#project #product
@projectsproducts
И оба должны быть сильными командными игроками, лидерами (в хорошем смысле), мотиваторами.
Смотрим новый ролик с примером отличного менеджера :)
https://www.youtube.com/watch?v=9MO1aY1xC80
#project #product
@projectsproducts
YouTube
Motivation - leader and teamwork! animation video
Don't stick with one way! find alternatives to reach your destination
Я уже писала про то, что бывают разные типы жизненных циклов проекта. И в зависимости от это типа нужно выбирать подход, методологию и фреймворк, с помощью которых будете управлять проектом.
Нашла у себя среди записей заметку:
Последние несколько лет в США было много исследований, направленных на изучение преимуществ "гибких" методологий по сравнению с традиционной водопадной моделью. Например, согласно “7th Annual State of Agile Development Survey” (Version One):
84% респондентов (разработчиков) признали, что подход "Agile" более эффективный, чем традиционный подход.
Кроме того, 70% опрошенных в этом же исследовании признали, что "Agile"-проекты намного быстрее реализуются.
А вот исследование российского рынка от компании ScrumTrek в 2017 году:
- Средний опыт применения Agile в России: у людей – 3 года, у компаний – 2,5.
- Мы отстаем на 1-2 года от среднего по миру опыта.
- Год назад финансы и телеком начали осваивать Agile: новичков там 56-59%.
- И в разработке ПО по-прежнему бурный рост: 31% с опытом не больше 1,5 года.
Ссылка на полный отчет - https://scrumtrek.ru/userfiles/reports/AgileSurvey17.pdf
#project
@projectsproducts
Нашла у себя среди записей заметку:
Последние несколько лет в США было много исследований, направленных на изучение преимуществ "гибких" методологий по сравнению с традиционной водопадной моделью. Например, согласно “7th Annual State of Agile Development Survey” (Version One):
84% респондентов (разработчиков) признали, что подход "Agile" более эффективный, чем традиционный подход.
Кроме того, 70% опрошенных в этом же исследовании признали, что "Agile"-проекты намного быстрее реализуются.
А вот исследование российского рынка от компании ScrumTrek в 2017 году:
- Средний опыт применения Agile в России: у людей – 3 года, у компаний – 2,5.
- Мы отстаем на 1-2 года от среднего по миру опыта.
- Год назад финансы и телеком начали осваивать Agile: новичков там 56-59%.
- И в разработке ПО по-прежнему бурный рост: 31% с опытом не больше 1,5 года.
Ссылка на полный отчет - https://scrumtrek.ru/userfiles/reports/AgileSurvey17.pdf
#project
@projectsproducts
Кстати, из тех же отчетов, о которых писала выше:
В 7th and 8th Annual State of Agile Development Survey (Version One) самые популярные гибкие методологии: "Extreme Programming" (XP), "Scrum", "Lean Development", "Feature Driven-Development" (fdd) and "Kanban".
И в России ничего нового: доля Scrum составляет 48%, причем с ростом зрелости компании в Agile процент компаний, использующих Scrum, становится чуть выше.
#project
@projectsproducts
В 7th and 8th Annual State of Agile Development Survey (Version One) самые популярные гибкие методологии: "Extreme Programming" (XP), "Scrum", "Lean Development", "Feature Driven-Development" (fdd) and "Kanban".
И в России ничего нового: доля Scrum составляет 48%, причем с ростом зрелости компании в Agile процент компаний, использующих Scrum, становится чуть выше.
#project
@projectsproducts
Книга «Заряженные на результат. Культура высокой эффективности на практике» (Нил Доши, Линдси Макгрегор).
Лучше всего работает 3 типа мотивации («прямые мотивы»):
- Игра (когда работа просто доставляет удовольствие),
- Цель (когда ты действительно ценишь результат своего труда) ,
- Самореализация (когда достигаешь чего-то важного для себя).
Деньги и премии - это хорошо, но только в комбинации с вышеперечисленными типами мотивации.
Несколько цитат:
“Организации часто полагаются на деньги как на главный движущий фактор активности персонала. Однако многие по собственному опыту знают, что мотивация имеет намного более сложную природу”.
“Когда миссия организации совпадает с ценностями ее команды и клиентов, включается мотив цели”.
“Ощущение игры возникает, когда вы занимаетесь своим делом просто потому, что оно вам нравится. Сама работа становится для вас наградой. Ученые описывают такого рода мотивацию как «внутреннюю»”.
Вообще в целом кажется, что книга пропагандирует адаптивный тип корпоративной культуры. Но я не думаю, что она действительно подходит всем компаниям. Но для IT - да, внешняя среда меняется быстро, и сотрудники должны уметь самостоятельно быстро принимать решения.
Если еще короче:
Лучше всего способствует высоким трудовым результатам мотив игры, когда сотрудник просто увлечен своим делом.
Но при этом у человека на любой должности и в любом отделе должна быть возможность подняться по карьерной лестнице. Например, для исследователей и ученых должны быть престижные и высокооплачиваемые должности, в том числе такие, где им не нужно будет заниматься административными делами.
#book
Вопросы (как и всегда) отправляйте на почту elena.kotina@gmail.com
@projectsproducts
Лучше всего работает 3 типа мотивации («прямые мотивы»):
- Игра (когда работа просто доставляет удовольствие),
- Цель (когда ты действительно ценишь результат своего труда) ,
- Самореализация (когда достигаешь чего-то важного для себя).
Деньги и премии - это хорошо, но только в комбинации с вышеперечисленными типами мотивации.
Несколько цитат:
“Организации часто полагаются на деньги как на главный движущий фактор активности персонала. Однако многие по собственному опыту знают, что мотивация имеет намного более сложную природу”.
“Когда миссия организации совпадает с ценностями ее команды и клиентов, включается мотив цели”.
“Ощущение игры возникает, когда вы занимаетесь своим делом просто потому, что оно вам нравится. Сама работа становится для вас наградой. Ученые описывают такого рода мотивацию как «внутреннюю»”.
Вообще в целом кажется, что книга пропагандирует адаптивный тип корпоративной культуры. Но я не думаю, что она действительно подходит всем компаниям. Но для IT - да, внешняя среда меняется быстро, и сотрудники должны уметь самостоятельно быстро принимать решения.
Если еще короче:
Лучше всего способствует высоким трудовым результатам мотив игры, когда сотрудник просто увлечен своим делом.
Но при этом у человека на любой должности и в любом отделе должна быть возможность подняться по карьерной лестнице. Например, для исследователей и ученых должны быть престижные и высокооплачиваемые должности, в том числе такие, где им не нужно будет заниматься административными делами.
#book
Вопросы (как и всегда) отправляйте на почту elena.kotina@gmail.com
@projectsproducts
В книге «Заряженные на результат» наткнулась на упоминание принципа Питера (как-то раньше это прошло мимо меня), который на русском звучит так:
«В иерархической системе каждый индивидуум имеет тенденцию подняться до уровня своей некомпетентности».
Согласно принципу Питера (1960гг.), человек, работающий в любой иерархической системе, повышается в должности до тех пор, пока не займёт место, на котором он окажется не в состоянии справиться со своими обязанностями.
Обоснование автор получил, рассмотрев типичный порядок выдвижения работников на определённую должность:
- Компетентные повышаются
- Некомпетентные не понижаются
- Отказ от повышения маловероятен
В итоге в компании работают те, кто поднялся до уровня некомпетентности, и будет работать до тех пор пока не уйдет на пенсию, не умрет или не будет повышен формально («отфутболен на чердак»).
Итальянские ученые даже провели исследование (“The Peter Principle Revisited: A Computational Study”):
применив агентное моделирование, создали систему, в которой соблюдается принцип Питера. На этой модели они показали, что лучшая тактика — повышать человека СЛУЧАЙНО!!!
За эту работу они получили шнобелевскую премию 2010 года в области менеджмента.
Считается, что это «шутка, над которой стоит задуматься».
#project #product
«В иерархической системе каждый индивидуум имеет тенденцию подняться до уровня своей некомпетентности».
Согласно принципу Питера (1960гг.), человек, работающий в любой иерархической системе, повышается в должности до тех пор, пока не займёт место, на котором он окажется не в состоянии справиться со своими обязанностями.
Обоснование автор получил, рассмотрев типичный порядок выдвижения работников на определённую должность:
- Компетентные повышаются
- Некомпетентные не понижаются
- Отказ от повышения маловероятен
В итоге в компании работают те, кто поднялся до уровня некомпетентности, и будет работать до тех пор пока не уйдет на пенсию, не умрет или не будет повышен формально («отфутболен на чердак»).
Итальянские ученые даже провели исследование (“The Peter Principle Revisited: A Computational Study”):
применив агентное моделирование, создали систему, в которой соблюдается принцип Питера. На этой модели они показали, что лучшая тактика — повышать человека СЛУЧАЙНО!!!
За эту работу они получили шнобелевскую премию 2010 года в области менеджмента.
Считается, что это «шутка, над которой стоит задуматься».
#project #product
Я уже писала про то, что одной из важнейших стадий разработки продукта является построение на ранней стадии гипотез о том, каким он должен быть.
А вот выдержка из рассказа Эрика Риса (Eric Ries) про MVP (the minimum viable product):
Существует подход в разработке «release early, release often», который многие знакомые практикуют.
Но недостаточно просто следовать RERO-принципу, так как в итоге вы будете бегать по кругу: выкладывать код с небольшими фичами, получать фидбек, проводить фокус-группы, но в итоге все придет к тому, что у вас не будет глобального долгосрочного видения того, что вы делаете.
Идея минимального жизнеспособного продукта (MVP) в том, что вы можете сказать:
мы хотим создать такой продукт, который будет решать проблему клиентов, и наши «ранние пользователи/последователи» уже смогут использовать это решение, и готовы за него заплатить.
Начать проверку вашего продукта можно с создания целевой страницы (landing page) с возможностью подписаться на новости о выпуске продукта, или просто текст с его описанием.
Если вы пустили трафик на эту страницу, и увидели, что 0% целевой аудитории подписываются на новости, то скорее всего вся идея нашего продукта была ошибочной.
Но если Вы не обескуражены тем, что никто не заинтересовался вашим лэндингом, и продолжаете работу над следующей итерацией, делаете продукт более сложным, и если после 10й итераций у вас так и не появилось «благодарной аудитории» вам стоит сказать себе:
«Хм, мы движемся не в том направлении. На самом деле, мы прошли точку минимального жизнеспособного продукта. Это просто **НЕ жизнеспособный продукт.**»
#product
А вот выдержка из рассказа Эрика Риса (Eric Ries) про MVP (the minimum viable product):
Существует подход в разработке «release early, release often», который многие знакомые практикуют.
Но недостаточно просто следовать RERO-принципу, так как в итоге вы будете бегать по кругу: выкладывать код с небольшими фичами, получать фидбек, проводить фокус-группы, но в итоге все придет к тому, что у вас не будет глобального долгосрочного видения того, что вы делаете.
Идея минимального жизнеспособного продукта (MVP) в том, что вы можете сказать:
мы хотим создать такой продукт, который будет решать проблему клиентов, и наши «ранние пользователи/последователи» уже смогут использовать это решение, и готовы за него заплатить.
Начать проверку вашего продукта можно с создания целевой страницы (landing page) с возможностью подписаться на новости о выпуске продукта, или просто текст с его описанием.
Если вы пустили трафик на эту страницу, и увидели, что 0% целевой аудитории подписываются на новости, то скорее всего вся идея нашего продукта была ошибочной.
Но если Вы не обескуражены тем, что никто не заинтересовался вашим лэндингом, и продолжаете работу над следующей итерацией, делаете продукт более сложным, и если после 10й итераций у вас так и не появилось «благодарной аудитории» вам стоит сказать себе:
«Хм, мы движемся не в том направлении. На самом деле, мы прошли точку минимального жизнеспособного продукта. Это просто **НЕ жизнеспособный продукт.**»
#product