Про удобство (Михаил Греков)
19.2K subscribers
176 photos
19 videos
2 files
511 links
Про продуктоводство, UX, работу с b2b-продуктом, кейсы из жизни и пользование Озон.

Пишет Михаил Греков, Head of product BI Analytic Workspace aw-bi.ru

🔥 Второй канал: Продуктовошная @suda_smotri

Сотрудничество — @GrekovM
Download Telegram
Самое важное знание об эффективности

Сперва начну с самого важного заблуждения: многозадачность.
Человек ни разу не многозадачен. Не верите?

Сделайте простейший эксперимент.

1. Возьмите колоду карт, перемешайте, начтине раскладывать карты по мастям в четыре стопки. У вас легко и просто получится это сделать, без особых пауз.
2. Теперь делайте то же самое. Но параллельно вслух играйте в города: Душанбе-Ереван-Новгород-... . Появятся паузы при раскладке карт: вы либо определяете к какой масти относится карта, либо вспоминаете город.

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

Те паузы, которые возникают при переключении между задачами (вспоминаешь город, с зависшей в руках картой) — налог на переключения.
Чем меньше за день вы платите налога на переключения — тем выше ваша эффективность.
Это самое важное знание об эффективности — оно очень простое и все тренеры по личной эффективности рассказывают вокруг да около этого правила.

Есть всего несколько способов снизить суммарный налог.

Очевидные:

1. Одна задача в единицу времени. Этакий последовательный конвейер.
2. Меньше внешних отвлечений. Этакий последовательный конвейер в тихом месте без уведомлений.
3. Снижать количество стресса. Этакий последовательный конвейер в тихом месте без уведомлений с дзеном в голове.

Очевидные способы крайне тяжко реализовать на полную: будут переключения, будут отвлечения и периодически есть стрессы.

Поэтому есть неочевидные способы снизить налог:

1. Смириться, что есть переключения — будет меньше стресса из-за переключений.

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

3. Вырабатывать автоматизмы — на автомате делать часть рутинных задач. Опытный водитель может ехать, пить кофе и давать сдачу пассажирам. Новичок с трудом будет только ехать.

4. Совмещать мыслительные задачи с автоматизмами. Если у вас есть ряд рутинных задач, которые вы уже можете делать на автоматизме, то с ними можно сочетать мыслительные задачи (мозг свободен). Но не совмещать без острейшей нужды мыслительное и мыслительное.

5. Планировать меньше задач на единицу времени, выкидывать лишнее, делегировать.

В общем, любая книга по самоэффективности ложится внутрь этой заметки. Сэкономил вам время :)

#совет #softskills из давно опубликованного
Самопроверка комфортности

Вы когда-нибудь задумывались, а комфортно ли с вами работать? Вы комфортный для рабочих взаимодействий человек?

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

1. Я отвечаю на запросы так же оперативно, как жду ответа на свои запросы.

2. Я формулирую задачи так же ёмко, как хочу, чтобы задачи формулировали для меня.

3. Я отвечаю на запросы так же исчерпывающе, как хочу, чтобы отвечали мне.

4. Я даю коллегам столько же обратной связи, сколько хочу, чтобы давали мне.

5. Тональность моего взаимодействия с коллегами такая же, которую я ожидаю от коллег.

Если по всем пунктам честное ДА - вы даёте коллегам такой же сервис взаимодействия, который ожидаете от них. Это не значит, что вы хороши для взаимодействий в глазах коллег, но значит, что вы не ждёте большего, чем даёте сами.

Если же вы даёте при взаимодействии меньше, чем ждёте в ответ - есть повод задуматься.

#softskills из давно опубликованного
Смекалка
Пожалуй, самое большое отличие проектной и продуктовой деятельности в том, что в продукте смекалка нужна по-любому и в больших объёмах. Смекалка — умение нестандартно решать сложные задачи и выходить из безвыходных положений.

У проекта есть каркас требований в любом случае — заказчик сам в основном решает, что будет в основе его продукта, как продукт продвигать, как завоёвывать любовь пользователей и т.д. В проектной деятельности смекалка нужна, чтобы к сроку сделать проект с хорошим качеством и минимальной себестоимостью. Если с ресурсами всё хорошо, то выходить из безвыходных положений не особо-то и надо — надо дать исполнителям посильные задачи и держать руку на пульсе.

А в продукте всё иначе — вся команда должна быть смекалистой. Если вы посмотрите на истории роста продуктов на ранних стадиях, то большинство Гровс хакингов строятся вокруг того, что кто-то придумал что-то хитрое и оно сработало.

Например, на заре своего существования Амазон заказывал книги в крупной книжной сети (забыл название). И заказать можно было только оптом по 10 штук. Т.е. приходит человек на сайт Амазона, выбирает книгу, заказывает, а дальше Амазон, чтобы ему её доставить, должны были перезаказать её. Но одну перезаказать нельзя — только 10. Что делать?

Стали заказывать 10: 3-4 тех, которые нужны клиентам, а остальное — экземпляры какой-то редкой книги, типа "Справочник редких растений Аризоны". Поставщик извинялся, что не может достать несколько экземпляров справочника (их у него просто не было) и доставлял только то, что нужно было Амазону на самом деле. Смекалка.

Когда я запускал свой первый продукт — b2b система для автоматизации торговых представителей (мобильная торговля Флюгер-Продажи) — то у меня на руках было всего два кейса внедрения и те были проектными. Что делать, чтобы показать, что система достойная?

Я пошёл в Википедию в статью "Мобильная торговля" и добавил в неё раздел: ТОП-10 систем для автоматизации мобильной торговли. Нашу поместил на 5 место, лидеров вперёд. После этого я смог ссылаться, что по данным Википедии мы входим в ТОП-5 лучших систем — потенциальные клиенты со мной стали разговаривать, реагировать на материалы о системе.

Угадайте, какой раздел в этой статье был потом самым редактируемым? Да, через время конкуренты начали двигать места в этом ТОП-10 😂

В общем, ищите возможность развивать в себе смекалку. Смотреть чужие Гровс хакинги можно сколько угодно, но если нет почвы для развития своей смекалки — всё без толку.

#softskills из давно опубликованного
Как отличить проработанное решение задачи от поверхностного
Если решение проработано, то вопросы к итогу не выбивают исполнителя из колеи. Он знает ответы, так как подбирался к задаче с разных сторон и не хватался за первое решение, которое ему показалось удачным.

В задачах, которые решают дизайнеры, копирайтеры, маркетологи и все, кто создаёт что-то новое, нет правильного решения.
Нельзя прийти к постановщику задачи и сказать: "Вот итог, правильно я сделал?"
Может быть только проработанное решение, которое после принятия, возможно, проверится цифрами.

Есть универсальный вопрос, который позволяет отличить проработанное решение от поверхностного:
"Ты уверен, что лучше эту задачу нельзя было решить ?"

Если решение проработано, то исполнитель расскажет про другие тупиковые ветки решения и почему выбрал то, что сделал.
Если решение поверхностное, то будет что-то вроде: "Ну, я точно не могу сказать. Давай я ещё подумаю?" или "А почему нет? Вроде, нормальное решение".

В общем, прорабатывайте решения и будьте в них уверены. Вдруг спросят: "Ты уверен?"

#softskills из ооочень давно опубликованного
Уточните, что такое ...

Пожалуй, самый важный навык, приобретëнный по мере профессионального роста — отсутствие страха показаться глупым, когда ты задаёшь вопросы.

Если мне что-то рассказывают, а я не понял термины — я их уточню.

Если я не уверен, что верно понял смысл — я уточню, рассказав как именно я понял.

Нет никакой причины, по которой кто-либо вообще должен стесняться уточнять, боясь показаться глупым. Не понял — уточни.

Но если ты периодически уточняешь одно и тоже — вот тут, конечно, уже вопросики 🤨

Боитесь показать глупыми, задавая вопросы?

#softskills из давно опубликованного
Please open Telegram to view this post
VIEW IN TELEGRAM