Навык: прибирать за собой

Заранее я понял, что дорогу залатали: щебень и нашлëпки смолы раскиданы после ремонта. Сбавил скорость, чтобы щебень из под колес меньше отлетала. "Неужели так сложно прибрать за собой!?" — подумалось.

Очень важный, сразу незаметный, трудноразвиваемый навык корнями из детства — прибирать за собой. Оставить чистыми с понятными названиями слои в дизайн-проекте, не накапливать ненужную документацию по проекту, подчистить тестовые данные перед выкладкой в прод — это всё про "прибирать за собой".

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

Пока ты работаешь один — ещё можно смириться со слабым навыком (тебе удобно, ты сам помнишь), но когда в команде — мусорить уже нельзя. Командные игроки мусорят меньше: программисты, например. А ребята, которые на проекте/продукте в одном экземпляре — ещё те собиратели хлама: менеджер, дизайнер, аналитик ...

Гигиенический минимум навыка:
💎 Договориться с командой. Можно это назвать регламентом, стандартом и как угодно — договориться о наименованиях, раскладке информации, правилах чистки за собой.

💎 Разумно именовать всё: начиная от тем писем и заканчивая элементами в дизайн макете.

💎 Создавать иерархию информации: проектные, тематические, периодические папки. Складывать всё не абы куда, а в иерархию.

💎 Не накапливать мусор. Память компьютера всё стерпит, а вот поисковые возможности того, кто ищет — нет. С годами мусор не отличается от нормальных данных и приходится в нём покопаться, чтобы понять что к чему. По разным исследованиям некоторые сотрудники тратят на поиск в корпоративной информации до 40% своего времени.

💎 Не проходить мимо. Увидел в проекте/продукте мусор или не понятно что: приберись, переименуй, и всем советуй так делать.

В общем, старайтесь оставлять после себя информацию, которую и через 5 лет поймёте и вы, и коллеги, и кто угодно. Память стирает грани между мусором и итогами.

#совет #softskills

​​Просить помощь у коллег — это сила или слабость?

Мои наблюдения за коллегами и внешними командами говорят о том, что начинающие (джуны) боятся просить помощь. Наверное, это близко к мысли: "Если я попрошу помощь, то я признаюсь, что не понимаю как делать дальше — меня будут считать тупым!"

Задержусь, ночь потрачу — зато сам, зато смог!

А если задержался, ночь потратил и в итоге не смог? Значит, профукал время. Значит, команде хуже.

Чем сильнее специалист, тем меньше у него пунктиков на тему: подумают, что я тупой. Сильные специалисты быстрее просят помощи у коллег и в итоге, меньше тормозят командную работу. "Я не понимаю, как делать дальше — можешь помочь?" — ничего тупого в этом нет.

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

Без перегибов, конечно. Сам попробовал и точно завис — проси помощь. А если не пробовал и сразу просишь — злоупотребление и слабость.

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

#совет #softskills

Не пропушишь — не проживёшь

Пропушить — напомнить кому-то, запросить повторно информацию и т.д.

Пуши от продуктов

Обращаю внимание как продукты меня пушат — я не про push-уведомления в приложениях, а в целом про попытки меня вовлечь, не потерять. Мотаю на ус, собираю практики.

👉 Напоминания на почту.
Ну такое, слабо работают, чтобы привлечь. Мягко говоря, почти не работают.

👉 СМС-ки.
Всё ещё работают, но поток большой в последнее время.
Работают обычно 2-м номером: сперва почта, а если я проигнорил — СМС.

👉 Таргетированная реклама.
Догоняют и просят закончить начатое. Яндекс-Практикум через ретаргет просил допройти курс 😂

👉 Звонки. Работают, если продукт мне знаком:
— Альфа (живой человек) звонит и напоминает о продлении ОСАГО (запрашиваю продление и сразу на почту присылают ссылку для оплаты),
— Скаенг (в записи) звонит и напоминает, что оплаченные уроки скоро кончатся (иду и пополняю),
— Вадик из Зерокодинга (в записи) позвонил и позвал на интенсив (не пошёл, но удивился пушу),
— Хостинг. Звонили (в записи) напоминали, что вот-вот и всё закончится (побежал продлевать). Перед этим были почта и СМС, на которые я благополучно забил.

👉 Телеграм-Боты. У продукта есть бот для напоминаний — он пушит. Главное, мягко заставить пользователя на него подписаться.

Если продукт пушит меня умело — я только за. Мне нравится, что звонит робот Скаенга, и оператор из Альфы. А если продукт не умеет умело пушить — не прожить ему в современном мире.


Пуши в работе менеджера
Быть пушером — очень ценное для работы, да и для жизни, качество. По сути, быть пушером — это быть проактивным в вопросе получения информации, которая тебе нужна. Мне периодически пишут в личку всякие рекламные предложения и т.п. — сразу видно, где наняли пушера на работу, а где застенчивый человек. Пушер 10 раз напомнит, запросит, спросит пока не получит ответ. А застенчивый разведёт руками: "Ну я уже напомнил, а мне так и не ответили. Что же я могу сделать ...".

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

#UX #softskills

Самое важное знание об эффективности

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

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

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

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

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

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

Очевидные:

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

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

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

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

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

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

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

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

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

#совет #softskills

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

И если спросить менеджеров: какой навык самый важный в повседневной работе?
То очень многие скажут, что навыки коммуникации.

Что же такое навыки коммуникации?
Если продакт или кто-то уверяет, что у него бОльшая часть дня проходит в коммуникациях, то хорошо ли это?

Может и хорошо, но а что если суперкоммуникатор имеет кучу коммуникаций потому что:
😳 не умеет фиксировать договорённости и из-за этого вынужден постоянно проговаривать одно и тоже?

😳 не умеет слушать и запоминать главное и из-за этого мучает всех постоянными вопросами?

😳 не умеет ёмко представлять информацию и вместо одного слайда делает и рассказывает 17?

😳 не умеет выбирать способ коммуникации и вместо 10 минут устного обсуждения полдня переписывается?

😳 не умеет писать в чат и вместо одного сообщения с парой предложений кидает 15 сообщений в виде словосочетаний?

😳 не умеет сказать нет и ходит по всем планёркам, даже на которых справятся без него?

😳 не умеет организовывать и искать информацию и всех дёргает вопросами, где то найти, где это?

😳 не умеет находить людей для решения вопроса и по цепочке добирается до нужного, пройдя через кучу коллег?

В общем, бОльшая часть дня в коммуникациях — это нифига не хорошо! Навык коммуникации — это не про количество коммуникаций, а про их качество. Всё должно работать, даже если менеджер внезапно заболеет или уедет на Бали.

Навык коммуникации — это слушать и слышать, запоминать и фиксировать, выбирать правильный канал коммуникации, быть ёмким, а не расплывчатым.
Хорош тот, у кого коммуникации выстроены так, что бOльшая часть времени остаётся для другой работы.

Посты в канале по теме:
Запоминать и резюмировать
Навык резюмировать
Культура e-mail переписки (в картинках)

#softskills

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

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

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

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

#softskills из давно опубликованного

Не суетись

Если вы смотрели Шрек-2, то вспомните сцену, в которой Шрек, Фиона и осёл ехали в гости к родителям Фионы. Осёл каждые пять минут спрашивал: "Уже приехали?", "Ну что, уже приехали?", "А сейчас приехали?" ...

Излишняя суета порой накрывает менеджеров (всех мастей): "Ну что, доделал?", "Нарисовал?", "Написал?", "Прошла модерация? А когда? А как ускорить?", "А можешь задержаться?", "Пообедаешь поскорее, чтобы успеть?".

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

Помню, накрытый волной суеты, ходишь вокруг да около программиста и уточняешь, как тот осёл: Нашёл причину ошибки? А скоро найдёшь? Ну ок, скоро вернусь.

Обычно такая суета никак не ускоряет процесс, а отвлекает на лишние действия и раздражает окружающих. Проще говоря, менеджер задалбывает, а не помогает. Ну и в спешке всегда хромает качество.

Вряд ли, рушится Мир и надо дышать в спину программисту (дизайнеру/копирайтеру ...) — у меня Мир не рушился (хотя казалось иное), в 100% случаев можно было меньше суетиться. Твоих коллег на дольше хватит, если они работают в спокойном режиме.

На что можно заменить суету:
— доверие к исполнителю. Обозначить всю важность ситуации и попросить к определённому сроку предоставить статус по проблеме.

— приготовить план "Б". Часто суетиться и дышать в спину уже поздно — надо готовить вторую версию плана: думать, где можно срезать углы; думать, что делать, если всё же не успеем; думать, что сказать заказчику и т.д.

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

— успокоиться самому: "Будет ли важна эта проблема через год?" Обычно, такой вопрос снимает волну суеты и помогает думать яснее.

В общем, менеджер — это оплот спокойствия, а не источник задёрганности.

Вокруг шум. Пусть так
Ни кипишуй. Всё ништяк
(Каста)

#softskills #продакту из давно опубликованного

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

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

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

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

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

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

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

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

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

#softskills двухлетней выдержки.

Базовое требование к сотруднику

В заметке про ожидания от руководителя я не писал ничего, связанного с “понятная постановка задач”. Мне это не нужно. И вот почему: умение правильно понимать задачи — это базовое требование к сотруднику, который выше чем джун по роли.

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

Большинство задач по умолчанию не могут быть чёткими. И чем выше уровень сотрудника, тем ниже чёткость. “Давайте прикрутим какую-нибудь херню, чтобы …” — нормальная постановка для сотрудников уровня middle и выше.

Весь секрет в том, чтобы сотрудник задал правильные вопросы по задаче и тем самым сделал её для себя чёткой.

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

В общем, если вам нужны постановки по смарту — вы джун.
Не джун сам любую постановку переформулирует в постановку по смарту, задав нужные вопросы или предложив верные сценарии.

#softskills

P.S. Нет ничего плохого в том, чтобы быть джуном в начале трудового пути. Все через это проходим.

Навык: уметь срывать сроки

Срывать сроки — это неотъемлемая часть работы. Для некоторых она даже более естественная, чем успевать в сроки 😀 Но учат обычно тому, как укладываться в сроки — мало кто рассказывает, что делать, когда в сроки не укладываешься. Если я в роли заказчика, то для меня комфорт работы с исполнителем зависит во многом от того, умеет ли он грамотно срывать сроки.

Сразу скажу: я говорю не про намеренное нарушение сроков работ, а про ситуации, когда что-то пошло не по плану и в срок успеть не получается.

Сегодня затрону гигиенический минимум грамотного срыва срока.

Итак, что делать при срыве срока:

1. Быть объективным. Часто о срыве срока менеджеры узнают несвоевременно. Конкретного метода ранней диагностики срыва срока нет, но есть косвенные признаки. Если нет запаса срока в 10%-15% от рабочего тайминга, то высок риск сорвать.
Если впереди период отпусков — риск сорвать.
Если заказчик не интересуется проектом/задачей — риск сорвать (см. пост про вялого заказчика).

Быть объективным = Как можно раньше признать, что срок сорван.

2. Не паниковать. Когда понимаешь, что срок сорван — надо собраться, а не панику разводить. Не дёргать каждые 5 минут исполнителей, а сделать новую версию плана. Пытаясь "влезть" в сорванный срок менеджеры начинают творить глупости — задалбывают исполнителей. Влезть порой получается, но в режиме задалбывания — почти никогда.

3. Знать новый срок, иметь новый план. Удивительно, но добиться нового срока обычно сложнее, чем прежнего:

— Я не успеваю к 30 марта.
— А к когда успеваешь?
— Ну ... Это ... Не знаю ...

4. Поддерживать контакт с заказчиком задачи/проекта, не обманывать и не пропадать (см. Не пропадать). Самое плохое, что можно сделать — обманывать заказчика:

Звонит заказчик:
— Успеваете?
— Да, должны успеть.
Вешает трубку.
— Эй парни, давайте постараемся. Я сказал, что мы должны успеть.

5. Предлагать решения, а не разводить руками. К завершению одной задачи могло быть привязано начало следующей. Например, заказчик получает сайт и начинает его рекламировать, потому что 12 апреля он должен распродать .... Но ясно, что сайт не будет готов к нужной дате. Плохой исполнитель — вешает на заказчика проблемы. Хороший — предлагает решение.

#совет #softskills из раннего

Самопроверка комфортности

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

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

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

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

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

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

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

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

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

#softskills

Не суетись

Если вы смотрели Шрек-2, то вспомните сцену, в которой Шрек, Фиона и осёл ехали в гости к родителям Фионы. Осёл каждые пять минут спрашивал: "Уже приехали?", "Ну что, уже приехали?", "А сейчас приехали?" ...

Излишняя суета порой накрывает менеджеров (всех мастей): "Ну что, доделал?", "Нарисовал?", "Написал?", "Прошла модерация? А когда? А как ускорить?", "А можешь задержаться?", "Пообедаешь поскорее, чтобы успеть?".

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

Помню, накрытый волной суеты, ходишь вокруг да около программиста и уточняешь, как тот осёл: Нашёл причину ошибки? А скоро найдёшь? Ну ок, скоро вернусь.

Обычно такая суета никак не ускоряет процесс, а отвлекает на лишние действия и раздражает окружающих. Проще говоря, менеджер задалбывает, а не помогает. Ну и в спешке всегда хромает качество.

Вряд ли, рушится Мир и надо дышать в спину программисту (дизайнеру/копирайтеру ...) — у меня Мир не рушился (хотя казалось иное), в 100% случаев можно было меньше суетиться. Твоих коллег на дольше хватит, если они работают в спокойном режиме.

На что можно заменить суету:
— доверие к исполнителю. Обозначить всю важность ситуации и попросить к определённому сроку предоставить статус по проблеме.

— приготовить план "Б". Часто суетиться и дышать в спину уже поздно — надо готовить вторую версию плана: думать, где можно срезать углы; думать, что делать, если всё же не успеем; думать, что сказать заказчику и т.д.

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

— успокоиться самому: "Будет ли важна эта проблема через год?" Обычно, такой вопрос снимает волну суеты и помогает думать яснее.

В общем, менеджер — это оплот спокойствия, а не источник задёрганности.

Вокруг шум. Пусть так
Ни кипишуй. Всё ништяк
(Каста)

#softskills из давно опубликованного

​​Просить помощь у коллег — это сила или слабость?

Мои наблюдения за коллегами и внешними командами говорят о том, что начинающие (джуны) боятся просить помощь. Наверное, это близко к мысли: "Если я попрошу помощь, то я признаюсь, что не понимаю как делать дальше — меня будут считать тупым!"

Задержусь, ночь потрачу — зато сам, зато смог!

А если задержался, ночь потратил и в итоге не смог? Значит, профукал время. Значит, команде хуже.

Чем сильнее специалист, тем меньше у него пунктиков на тему: подумают, что я тупой. Сильные специалисты быстрее просят помощи у коллег и в итоге, меньше тормозят командную работу. "Я не понимаю, как делать дальше — можешь помочь?" — ничего тупого в этом нет.

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

Без перегибов, конечно. Сам попробовал и точно завис — проси помощь. А если не пробовал и сразу просишь — злоупотребление и слабость.

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

#совет #softskills

Не пропушишь — не проживёшь

Пропушить — напомнить кому-то, запросить повторно информацию и т.д.

Пуши от продуктов

Обращаю внимание как продукты меня пушат — я не про push-уведомления в приложениях, а в целом про попытки меня вовлечь, не потерять. Мотаю на ус, собираю практики.

👉 Напоминания на почту.
Ну такое, слабо работают, чтобы привлечь. Мягко говоря, почти не работают.

👉 СМС-ки.
Всё ещё работают, но поток большой в последнее время.
Работают обычно 2-м номером: сперва почта, а если я проигнорил — СМС.

👉 Таргетированная реклама.
Догоняют и просят закончить начатое. Яндекс-Практикум через ретаргет просил допройти курс 😂

👉 Звонки. Работают, если продукт мне знаком:
— Альфа (живой человек) звонит и напоминает о продлении ОСАГО (запрашиваю продление и сразу на почту присылают ссылку для оплаты),
— Скаенг (в записи) звонит и напоминает, что оплаченные уроки скоро кончатся (иду и пополняю),
— Вадик из Зерокодинга (в записи) позвонил и позвал на интенсив (не пошёл, но удивился пушу),
— Хостинг. Звонили (в записи) напоминали, что вот-вот и всё закончится (побежал продлевать). Перед этим были почта и СМС, на которые я благополучно забил.

👉 Телеграм-Боты. У продукта есть бот для напоминаний — он пушит. Главное, мягко заставить пользователя на него подписаться.

Если продукт пушит меня умело — я только за. Мне нравится, что звонит робот Скаенга, и оператор из Альфы. А если продукт не умеет умело пушить — не прожить ему в современном мире.


Пуши в работе менеджера
Быть пушером — очень ценное для работы, да и для жизни, качество. По сути, быть пушером — это быть проактивным в вопросе получения информации, которая тебе нужна. Мне периодически пишут в личку всякие рекламные предложения и т.п. — сразу видно, где наняли пушера на работу, а где застенчивый человек. Пушер 10 раз напомнит, запросит, спросит пока не получит ответ. А застенчивый разведёт руками: "Ну я уже напомнил, а мне так и не ответили. Что же я могу сделать ...".

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

#UX #softskills из давно опубликованного

Самое важное знание об эффективности

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

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

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 из ооочень давно опубликованного