Про удобство (Михаил Греков)

2022-08-09 17:49:13 Про сложность

Чем проще — тем жизнеспособней. Это простая истина. Но допустим вы делаете какой-то сложный ИТ-продукт: куча логики, интеграций-шмиграций и прочего. Одним словом: всё не просто. Как быть?

Базовые правила касательно разработки сложных продуктов:

Сложность не должна попасть на уровень пользователя
Не надо прикрываться сложной логикой и архитектурой, оправдывая перегруженный и запутанный интерфейс. Вам всё равно придётся упростить в итоге и вы найдёте способ это сделать, потому что сложные продукты не взлетают. Упритесь, но уйдите от сложности сразу.
Логика не должна звучать сложно
Если внутри команды логику какой-то функциональности с ходу мало кто понимает — надо выкинуть эту логику и придумать другую. Если описание “звучит сложно”, значит там зарыта проблема.
От простого к сложному
Поясняйте команде сложные вещи простыми примерами. Технически всё может быть сложно (под капотом), но всё сложное в итоге должно быть описано простыми словами. Любое описание сложной функциональности должно начинаться с простого пояснения. Если простое пояснение невозможно придумать, то см. пункт выше
Всё можно упростить
Если вы не упростите — упростит кто-то другой и выкинет вас.

В общем, сложные ИТ-продукты выживают, если пользователь не замечает, что они сложные. Открыть/Комментировать

2022-08-08 15:03:10 ​​Ребята из Surf попросили рассказать про их канал Продуктовое видение в IT — пошёл почитать и залип на полчаса. В частности, вычитал про подходы к проектированию приложений, которыми смогут пользоваться люди старшего возраста (делюсь):

Безопасное исследование и простота выполнения задач — предоставлять знакомые и простые функции.
Редкие обновления. Чем старше человек, тем тяжелее ему воспринимать новую информацию и создавать новые связи для решения новых задач. К приложению важно выработать лояльность и доверие, а частый апдейт может только насторожить пользователей.
Честность очень важна — что написано на кнопке, то и должно происходить. Взаимодействие с приложением не должно вызывать ощущения обманутых ожиданий. Иначе у пользователя многократно усиливается тревога, а мотивация пользоваться приложением исчезает.
Социальное доказательство. Людям свойственно опираться на опыт других. Этот паттерн играет важную роль и в проектировании приложения для пожилых — им важно видеть подтверждение правильности своего выбора и действий. Они будут внимательно изучать отзывы, рейтинги, читать или смотреть обзоры.
Крупный шрифт. В приложении, особенно том, что помогает работать с деньгами, важен крупный и контрастный шрифт.
Больше слов. То, что сейчас интуитивно понятно уже среднему возрасту, находится вне контекста пожилых людей. Например, им сложно использовать крестик при закрытии вкладки или привычней пользоваться кнопками, а не свайпом. Поэтому заботой о них будет объяснение незнакомых терминов и тем самым создание чувства безопасности при работе с приложением.

В общем, канал интересный и полезный — подписывайтесь. У ребят огромный опыт разработки мобильных приложений: это они сделали приложения Магнита, Лабиринта, Рив Гош, Риглы, Бетховена и ещё многие другие, что точно есть у вас в телефоне. Открыть/Комментировать

2022-08-05 18:06:11 Как там Айти Кадр?
Если кто ещё не знает — есть у меня пет-проект Айти Кадр, itkadr.ru. Это сервис, где можно найти Айти-наставника и записаться к нему на занятия или консультацию.

Для меня Айти Кадр не бизнес, а скорее продукт для души и прокачки навыков, которые сложно прокачать в b2b.

Так вот, сервис живой — регулярно приходят новые наставники и происходят записи. И это при том, что я давно про него не пишу и никак не рекламирую. Просто те, кто занимались — рекомендуют друзьям и коллегам.

У меня куча гипотез по развитию сервиса, но очень мало времени на это. Даже наставников сейчас размещаю с задержкой. А сервис в развитии нуждается: УТП уже иной, тексты устарели, главная инфоцыганщиной попахивает, навигация плоховата, стек можно обновить.

Иногда я приглашал мне помочь дизайнеров и продактов, которые хотят поработать в свободном режиме: отработать новый навык на практике, свободно принимать решения, пополнить портфолио или резюме достижениями. Рутинно-обычные задачи тоже есть: инфу разместить, рассылку запилить и т.п.

Взамен я предлагал что-то типа наставничества: вместе штурмим гипотезы, делюсь опытом, обсуждаем какие-то рабочие кейсы. Мне помогали продакты Валентин и Ксения, но оба пошли на повышение в российский ФААНГ и их время для меня иссякло (надеюсь, что и моё участие им помогло в росте).

В общем, если есть желающие развивать Айти Кадр и развиваться от этого — пишите в личку @GrekovM
Только укажите, зачем вам это вообще надо

P.S. Получил 10 предложений Чувствую, что начнётся новый крутой виток развития Айти Кадр. Не переключайтесь )

#itkadr Открыть/Комментировать

2022-06-22 18:48:34 Вижу тест → хочу пройти.

Всегда приятно пройти профессиональный тест и понять, что ты на все (ну ладно, почти все) вопросы смог ответить верно. Сегодня прошёл тест от Нетологии для продактов — 10 вопросов на подумать. Вопросы про масштабирование продукта, запуск новой фичи и остановку оттока пользователей из приложения. 7 минут делов.

Попробуйте себя проверить — особенно актуально для тех, кто примеряет на себя профессию менеджера продуктов. В конце теста дают промокод на скидку в 10К на курс «Product manager»

https://netolo.gy/iCJ ← ссылка на тест. Открыть/Комментировать

2022-06-16 16:14:35 Запуск дня — GoPractice сегодня анонсировали запуск симулятора SQL для продуктовой аналитики, созданный для продактов, маркетологов и UX-исследователей. Я проходил в GoPractice Симулятор управления продуктом и вообще подписан на ребят — с удовольствием расскажу про новый симулятор.

У меня лично весьма поверхностные знания SQL (базовые). Но даже с базовыми знаниями, имея коннект к базе данных, я могу в Metabase (это открытая BI) довольно много данных из базы вытянуть и покрутить.

Если вы сами не можете в SQL и вынуждены дёргать аналитиков, а потом ждать итога — идите в SQL симулятор от GoPractice.

Симулятор учит самостоятельно составлять запросы, доставать и чистить данные, рассчитывать ключевые метрики. А уже на основе этого быстрее отвечать на важные вопросы о продукте и маркетинге.

Важное отличие симулятора в том, что это не «SQL для чайников», а SQL для конкретных задач в рамках продуктовой аналитики.

Внутри примерно 400 заданий и 50 часов обучения (2-3 недели активной работы).

Читайте, пробуйте: https://gopractice.ru/course/sql/ Открыть/Комментировать

2022-06-15 13:00:00 Постараюсь попасть на вебинар Юлии Билинкис про дорожные карты продукта (они же roadmap). Судя по анонсу, с роадмапом моего продукта что-то не так

Вот #анонс вебинара с моими вопросами:

Основная проблема с дорожными картами продукта в нетерпимости к неопределенности, которая приводит к тому, что многие команды начинают копировать бэклог продукта в дорожную карту. Однако дорожная карта — это не список функций и не релизный план (А что же тогда ?).

Дорожная карта продукта описывает проблемы, которые необходимо решить, возможности для реализации и доводит до всех стратегию продукта (Разве проблемы не часть бэклога? А новые фичи? Возможности — в смысле ресурсы или что-то иное?).

18 июня Юля Билинкис (CEO StrategicMove, ex-CPO) проведет вебинар на тему "Как поставить цели и создать дорожную карту продукта?"

О чем пойдет речь:

Как выстроить продуктовые процессы в команде, декомпозировать стратегию через дорожную карту и цели команд, создать и защитить дорожную карту, основанную на ценности для клиента и бизнеса

10:30 Как выстроить продуктовые процессы в команде

11:30 Как декомпозировать стратегию через дорожную карту и цели команды и продукта

12:30 Как создать дорожную карту, основанную на ценности для клиента и бизнеса

13:30 Ответы на вопросы и рассмотрение ваших кейсов

Регистрация по ссылке:
https://strategicmove.ru/roadmap_webinar Открыть/Комментировать

2022-06-14 10:01:00 Как оценивать задачи
Считаю одним из лучших профессиональных качеств — умение оценивать задачу. Любую задачу: описанную подробно, описанную абы как, сказанную устно … Это прям фундамент.

Но многие ссут оценивать: стелят, стелят соломку.

“Нууу, тут пока не понятно, я даже не знаю сколько примерно это может занять …”
“Да там такое легаси, что я даже боюсь предположить сколько времени надо …”.

Если хотите выглядеть профи — научитесь оценивать задачи. Делается это просто:

1. Не можете оценивать сходу — просите время на оценку: “Я сейчас не могу оценить — мне надо 2 часа, чтобы сделать оценку”.

2. Декомпозируйте — разбивайте большую задачу на составляющие и оценивайте их.

3. Оценивайте вилкой: от — до. ОТ = когда всё пойдёт хорошо. ДО = когда всё пойдёт капец как хреново (сбудутся все риски).

4. Докиньте сверху 10-20% (некоторые накидывают до
100%).

5. Если брали время на оценку, то предоставьте док с декомпозицией и оценкой, а не просто: “Нууу, тут хреналион часов”. Тому, кто хотел оценку будет важно понимать, какие задачи много весят — возможно их можно заменить/отложить/купить.

6. Если оценить просят здесь и сейчас: “Прикинь хотя бы примерно”, значит важно понимать порядок оценки (неделя, месяц, год, жизнь). Прикиньте минимальную оценку, умножьте её на два и скажите: Не меньше чем “Х”. Этого часто достаточно, чтобы принять решение.

7. Надо следовать своим оценкам. А если что-то идёт не так, то своевременно переоценивать.

В общем, если боитесь оценивать задачи — представьте, что нанимаете ремонтников, которые ну никак не могут даже прикинуть сроки вашего ремонта. Наняли бы их? Открыть/Комментировать

2022-06-09 15:18:02 Когда сценарий для будущего блокбастера «Чужой» (1979) был почти готов, его авторы придумали к нему питч всего лишь из трех слов: «Челюсти в космосе».

После ошеломительного успеха фильма «Челюсти» (1975) продюсерам сразу становилось ясно, о чем новый фильм.
До сих пор этот питч служит ярким примером краткого, емкого и доходчивого изложения сути проекта. Открыть/Комментировать

2022-06-07 12:09:01 Любую задачу надо доводить до состояния: "Если бы я работал один, то запустил бы этот итог в продакшн".

Дизайнер не должен рассчитывать, что кто-то будет смотреть его работу прежде чем показать заказчику.
Программист не должен рассчитывать, что есть QA, который всё найдёт.
Редактор не должен рассчитывать, что есть корректор и главред, которые поправят и дадут обратную связь.

Если каждое звено работает как последний рубеж, тогда общий качественный итог получается гораздо быстрее.
Каждый уровень должен не разбирать грязь от предыдущего уровня, а улучшать итог своей профессиональной компетенцией.

В общем, если выключить у себя уверенность, что кто-то обязательно перепроверит твои итоги, то можно существенно поднять уровень этих самых итогов.

#softskills из давно опубликованного Открыть/Комментировать

2022-05-27 15:01:14 ​​#анонс
31 мая будет митап "Как создать продукт, в который влюбится каждый". Будет полезно проджект и продакт менеджерам, исследователям.

AGIMA х INTEGRAL DESIGN вместе c экспертами из М.Видео-Эльдорадо, Alfa Research Center расскажут, что делает продукт востребованным и желанным.

Темы докладов:

- О чем молчат для вас клиенты.
- Как за полтора года встроить CX/UX-исследования в работу продуктовых команд в большом бизнесе.
- Как создать востребованный продукт в условиях неопределенности.
- Подходы в дизайне: от поиска решений до красоты интерфейсов.

31 мая, старт в 18:00 по Москве. Не пропустите!

Регистрация: https://u.to/6xMrHA. Открыть/Комментировать