Любую задачу надо доводить до состояния: "Если бы я работал один, то запустил бы этот итог в продакшн".
Дизайнер не должен рассчитывать, что кто-то будет смотреть его работу прежде чем показать заказчику.
Программист не должен рассчитывать, что есть QA, который всё найдёт.
Редактор не должен рассчитывать, что есть корректор и главред, которые поправят и дадут обратную связь.
Если каждое звено работает как последний рубеж, тогда общий качественный итог получается гораздо быстрее.
Каждый уровень должен не разбирать грязь от предыдущего уровня, а улучшать итог своей профессиональной компетенцией.
В общем, если выключить у себя уверенность, что кто-то обязательно перепроверит твои итоги, то можно существенно поднять уровень этих самых итогов.
#softskills из давно опубликованного
Дизайнер не должен рассчитывать, что кто-то будет смотреть его работу прежде чем показать заказчику.
Программист не должен рассчитывать, что есть QA, который всё найдёт.
Редактор не должен рассчитывать, что есть корректор и главред, которые поправят и дадут обратную связь.
Если каждое звено работает как последний рубеж, тогда общий качественный итог получается гораздо быстрее.
Каждый уровень должен не разбирать грязь от предыдущего уровня, а улучшать итог своей профессиональной компетенцией.
В общем, если выключить у себя уверенность, что кто-то обязательно перепроверит твои итоги, то можно существенно поднять уровень этих самых итогов.
#softskills из давно опубликованного
Не суетись
Если вы смотрели Шрек-2, то вспомните сцену, в которой Шрек, Фиона и осёл ехали в гости к родителям Фионы. Осёл каждые пять минут спрашивал: "Уже приехали?", "Ну что, уже приехали?", "А сейчас приехали?" ...
Излишняя суета порой накрывает менеджеров (всех мастей): "Ну что, доделал?", "Нарисовал?", "Написал?", "Прошла модерация? А когда? А как ускорить?", "А можешь задержаться?", "Пообедаешь поскорее, чтобы успеть?".
Обычно волны суеты накрывают, когда что-то идёт не по плану: срывается срок, вылезла какая-то гадость на проде, сервак лёг, срочный запрос в поддержку и т.д.
Помню, накрытый волной суеты, ходишь вокруг да около программиста и уточняешь, как тот осёл: Нашёл причину ошибки? А скоро найдёшь? Ну ок, скоро вернусь.
Обычно такая суета никак не ускоряет процесс, а отвлекает на лишние действия и раздражает окружающих. Проще говоря, менеджер задалбывает, а не помогает. Ну и в спешке всегда хромает качество.
Вряд ли, рушится Мир и надо дышать в спину программисту (дизайнеру/копирайтеру ...) — у меня Мир не рушился (хотя казалось иное), в 100% случаев можно было меньше суетиться. Твоих коллег на дольше хватит, если они работают в спокойном режиме.
На что можно заменить суету:
— доверие к исполнителю. Обозначить всю важность ситуации и попросить к определённому сроку предоставить статус по проблеме.
— приготовить план "Б". Часто суетиться и дышать в спину уже поздно — надо готовить вторую версию плана: думать, где можно срезать углы; думать, что делать, если всё же не успеем; думать, что сказать заказчику и т.д.
— обозначить, каким качеством можно пожертвовать ... и как его потом вернуть. Качество, утерянное в авральном режиме, должно быть зафиксировано и возвращено при выходе из этого режима.
— успокоиться самому: "Будет ли важна эта проблема через год?" Обычно, такой вопрос снимает волну суеты и помогает думать яснее.
В общем, менеджер — это оплот спокойствия, а не источник задёрганности.
Вокруг шум. Пусть так
Ни кипишуй. Всё ништяк
(Каста)
#softskills #продакту из давно опубликованного
Если вы смотрели Шрек-2, то вспомните сцену, в которой Шрек, Фиона и осёл ехали в гости к родителям Фионы. Осёл каждые пять минут спрашивал: "Уже приехали?", "Ну что, уже приехали?", "А сейчас приехали?" ...
Излишняя суета порой накрывает менеджеров (всех мастей): "Ну что, доделал?", "Нарисовал?", "Написал?", "Прошла модерация? А когда? А как ускорить?", "А можешь задержаться?", "Пообедаешь поскорее, чтобы успеть?".
Обычно волны суеты накрывают, когда что-то идёт не по плану: срывается срок, вылезла какая-то гадость на проде, сервак лёг, срочный запрос в поддержку и т.д.
Помню, накрытый волной суеты, ходишь вокруг да около программиста и уточняешь, как тот осёл: Нашёл причину ошибки? А скоро найдёшь? Ну ок, скоро вернусь.
Обычно такая суета никак не ускоряет процесс, а отвлекает на лишние действия и раздражает окружающих. Проще говоря, менеджер задалбывает, а не помогает. Ну и в спешке всегда хромает качество.
Вряд ли, рушится Мир и надо дышать в спину программисту (дизайнеру/копирайтеру ...) — у меня Мир не рушился (хотя казалось иное), в 100% случаев можно было меньше суетиться. Твоих коллег на дольше хватит, если они работают в спокойном режиме.
На что можно заменить суету:
— доверие к исполнителю. Обозначить всю важность ситуации и попросить к определённому сроку предоставить статус по проблеме.
— приготовить план "Б". Часто суетиться и дышать в спину уже поздно — надо готовить вторую версию плана: думать, где можно срезать углы; думать, что делать, если всё же не успеем; думать, что сказать заказчику и т.д.
— обозначить, каким качеством можно пожертвовать ... и как его потом вернуть. Качество, утерянное в авральном режиме, должно быть зафиксировано и возвращено при выходе из этого режима.
— успокоиться самому: "Будет ли важна эта проблема через год?" Обычно, такой вопрос снимает волну суеты и помогает думать яснее.
В общем, менеджер — это оплот спокойствия, а не источник задёрганности.
Вокруг шум. Пусть так
Ни кипишуй. Всё ништяк
(Каста)
#softskills #продакту из давно опубликованного
Смекалка
Пожалуй, самое большое отличие проектной и продуктовой деятельности в том, что в продукте смекалка нужна по-любому и в больших объёмах. Смекалка — умение нестандартно решать сложные задачи и выходить из безвыходных положений.
У проекта есть каркас требований в любом случае — заказчик сам в основном решает, что будет в основе его продукта, как продукт продвигать, как завоёвывать любовь пользователей и т.д. В проектной деятельности смекалка нужна, чтобы к сроку сделать проект с хорошим качеством и минимальной себестоимостью. Если с ресурсами всё хорошо, то выходить из безвыходных положений не особо-то и надо — надо дать исполнителям посильные задачи и держать руку на пульсе.
А в продукте всё иначе — вся команда должна быть смекалистой. Если вы посмотрите на истории роста продуктов на ранних стадиях, то большинство Гровс хакингов строятся вокруг того, что кто-то придумал что-то хитрое и оно сработало.
Например, на заре своего существования Амазон заказывал книги в крупной книжной сети (забыл название). И заказать можно было только оптом по 10 штук. Т.е. приходит человек на сайт Амазона, выбирает книгу, заказывает, а дальше Амазон, чтобы ему её доставить, должны были перезаказать её. Но одну перезаказать нельзя — только 10. Что делать?
Стали заказывать 10: 3-4 тех, которые нужны клиентам, а остальное — экземпляры какой-то редкой книги, типа "Справочник редких растений Аризоны". Поставщик извинялся, что не может достать несколько экземпляров справочника (их у него просто не было) и доставлял только то, что нужно было Амазону на самом деле. Смекалка.
Когда я запускал свой первый продукт — b2b система для автоматизации торговых представителей (мобильная торговля Флюгер-Продажи) — то у меня на руках было всего два кейса внедрения и те были проектными. Что делать, чтобы показать, что система достойная?
Я пошёл в Википедию в статью "Мобильная торговля" и добавил в неё раздел: ТОП-10 систем для автоматизации мобильной торговли. Нашу поместил на 5 место, лидеров вперёд. После этого я смог ссылаться, что по данным Википедии мы входим в ТОП-5 лучших систем — потенциальные клиенты со мной стали разговаривать, реагировать на материалы о системе.
Угадайте, какой раздел в этой статье был потом самым редактируемым? Да, через время конкуренты начали двигать места в этом ТОП-10 😂
В общем, ищите возможность развивать в себе смекалку. Смотреть чужие Гровс хакинги можно сколько угодно, но если нет почвы для развития своей смекалки — всё без толку.
#softskills двухлетней выдержки.
Пожалуй, самое большое отличие проектной и продуктовой деятельности в том, что в продукте смекалка нужна по-любому и в больших объёмах. Смекалка — умение нестандартно решать сложные задачи и выходить из безвыходных положений.
У проекта есть каркас требований в любом случае — заказчик сам в основном решает, что будет в основе его продукта, как продукт продвигать, как завоёвывать любовь пользователей и т.д. В проектной деятельности смекалка нужна, чтобы к сроку сделать проект с хорошим качеством и минимальной себестоимостью. Если с ресурсами всё хорошо, то выходить из безвыходных положений не особо-то и надо — надо дать исполнителям посильные задачи и держать руку на пульсе.
А в продукте всё иначе — вся команда должна быть смекалистой. Если вы посмотрите на истории роста продуктов на ранних стадиях, то большинство Гровс хакингов строятся вокруг того, что кто-то придумал что-то хитрое и оно сработало.
Например, на заре своего существования Амазон заказывал книги в крупной книжной сети (забыл название). И заказать можно было только оптом по 10 штук. Т.е. приходит человек на сайт Амазона, выбирает книгу, заказывает, а дальше Амазон, чтобы ему её доставить, должны были перезаказать её. Но одну перезаказать нельзя — только 10. Что делать?
Стали заказывать 10: 3-4 тех, которые нужны клиентам, а остальное — экземпляры какой-то редкой книги, типа "Справочник редких растений Аризоны". Поставщик извинялся, что не может достать несколько экземпляров справочника (их у него просто не было) и доставлял только то, что нужно было Амазону на самом деле. Смекалка.
Когда я запускал свой первый продукт — b2b система для автоматизации торговых представителей (мобильная торговля Флюгер-Продажи) — то у меня на руках было всего два кейса внедрения и те были проектными. Что делать, чтобы показать, что система достойная?
Я пошёл в Википедию в статью "Мобильная торговля" и добавил в неё раздел: ТОП-10 систем для автоматизации мобильной торговли. Нашу поместил на 5 место, лидеров вперёд. После этого я смог ссылаться, что по данным Википедии мы входим в ТОП-5 лучших систем — потенциальные клиенты со мной стали разговаривать, реагировать на материалы о системе.
Угадайте, какой раздел в этой статье был потом самым редактируемым? Да, через время конкуренты начали двигать места в этом ТОП-10 😂
В общем, ищите возможность развивать в себе смекалку. Смотреть чужие Гровс хакинги можно сколько угодно, но если нет почвы для развития своей смекалки — всё без толку.
#softskills двухлетней выдержки.
Базовое требование к сотруднику
В заметке про ожидания от руководителя я не писал ничего, связанного с “понятная постановка задач”. Мне это не нужно. И вот почему: умение правильно понимать задачи — это базовое требование к сотруднику, который выше чем джун по роли.
Если кто-то говорит, что хотел бы, чтобы ему ставили очень чёткие задачи, а лучше по смарту — для меня это маркер “джун”. Начинающим свой трудовой путь сотрудникам действительно нужны чёткие постановки — у них ещё нет навыка выявлять суть задачи. Но этот навык со временем должен появляться, так как он базовый для нормальной работы.
Большинство задач по умолчанию не могут быть чёткими. И чем выше уровень сотрудника, тем ниже чёткость. “Давайте прикрутим какую-нибудь херню, чтобы …” — нормальная постановка для сотрудников уровня middle и выше.
Весь секрет в том, чтобысотрудник задал правильные вопросы по задаче и тем самым сделал её для себя чёткой.
Вспомните любой криминальный фильм: профессиональные киллеры понимают задачу с одного взгляда на фото. Могут уточнить что-то, но без фанатизма.
В общем, если вам нужны постановки по смарту — вы джун.
Не джун сам любую постановку переформулирует в постановку по смарту, задав нужные вопросы или предложив верные сценарии.
#softskills
P.S. Нет ничего плохого в том, чтобы быть джуном в начале трудового пути. Все через это проходим.
В заметке про ожидания от руководителя я не писал ничего, связанного с “понятная постановка задач”. Мне это не нужно. И вот почему: умение правильно понимать задачи — это базовое требование к сотруднику, который выше чем джун по роли.
Если кто-то говорит, что хотел бы, чтобы ему ставили очень чёткие задачи, а лучше по смарту — для меня это маркер “джун”. Начинающим свой трудовой путь сотрудникам действительно нужны чёткие постановки — у них ещё нет навыка выявлять суть задачи. Но этот навык со временем должен появляться, так как он базовый для нормальной работы.
Большинство задач по умолчанию не могут быть чёткими. И чем выше уровень сотрудника, тем ниже чёткость. “Давайте прикрутим какую-нибудь херню, чтобы …” — нормальная постановка для сотрудников уровня middle и выше.
Весь секрет в том, чтобы
В общем, если вам нужны постановки по смарту — вы джун.
Не джун сам любую постановку переформулирует в постановку по смарту, задав нужные вопросы или предложив верные сценарии.
#softskills
P.S. Нет ничего плохого в том, чтобы быть джуном в начале трудового пути. Все через это проходим.
Навык: уметь срывать сроки
Срывать сроки — это неотъемлемая часть работы. Для некоторых она даже более естественная, чем успевать в сроки 😀 Но учат обычно тому, как укладываться в сроки — мало кто рассказывает, что делать, когда в сроки не укладываешься. Если я в роли заказчика, то для меня комфорт работы с исполнителем зависит во многом от того, умеет ли он грамотно срывать сроки.
Сразу скажу: я говорю не про намеренное нарушение сроков работ, а про ситуации, когда что-то пошло не по плану и в срок успеть не получается.
Сегодня затрону гигиенический минимум грамотного срыва срока.
Итак, что делать при срыве срока:
1. Быть объективным. Часто о срыве срока менеджеры узнают несвоевременно. Конкретного метода ранней диагностики срыва срока нет, но есть косвенные признаки. Если нет запаса срока в 10%-15% от рабочего тайминга, то высок риск сорвать.
Если впереди период отпусков — риск сорвать.
Если заказчик не интересуется проектом/задачей — риск сорвать (см. пост про вялого заказчика).
Быть объективным = Как можно раньше признать, что срок сорван.
2. Не паниковать. Когда понимаешь, что срок сорван — надо собраться, а не панику разводить. Не дёргать каждые 5 минут исполнителей, а сделать новую версию плана. Пытаясь "влезть" в сорванный срок менеджеры начинают творить глупости — задалбывают исполнителей. Влезть порой получается, но в режиме задалбывания — почти никогда.
3. Знать новый срок, иметь новый план. Удивительно, но добиться нового срока обычно сложнее, чем прежнего:
— Я не успеваю к 30 марта.
— А к когда успеваешь?
— Ну ... Это ... Не знаю ...
4. Поддерживать контакт с заказчиком задачи/проекта, не обманывать и не пропадать (см. Не пропадать). Самое плохое, что можно сделать — обманывать заказчика:
Звонит заказчик:
— Успеваете?
— Да, должны успеть.
Вешает трубку.
— Эй парни, давайте постараемся. Я сказал, что мы должны успеть.
5. Предлагать решения, а не разводить руками. К завершению одной задачи могло быть привязано начало следующей. Например, заказчик получает сайт и начинает его рекламировать, потому что 12 апреля он должен распродать .... Но ясно, что сайт не будет готов к нужной дате. Плохой исполнитель — вешает на заказчика проблемы. Хороший — предлагает решение.
#совет #softskills из раннего
Срывать сроки — это неотъемлемая часть работы. Для некоторых она даже более естественная, чем успевать в сроки 😀 Но учат обычно тому, как укладываться в сроки — мало кто рассказывает, что делать, когда в сроки не укладываешься. Если я в роли заказчика, то для меня комфорт работы с исполнителем зависит во многом от того, умеет ли он грамотно срывать сроки.
Сразу скажу: я говорю не про намеренное нарушение сроков работ, а про ситуации, когда что-то пошло не по плану и в срок успеть не получается.
Сегодня затрону гигиенический минимум грамотного срыва срока.
Итак, что делать при срыве срока:
1. Быть объективным. Часто о срыве срока менеджеры узнают несвоевременно. Конкретного метода ранней диагностики срыва срока нет, но есть косвенные признаки. Если нет запаса срока в 10%-15% от рабочего тайминга, то высок риск сорвать.
Если впереди период отпусков — риск сорвать.
Если заказчик не интересуется проектом/задачей — риск сорвать (см. пост про вялого заказчика).
Быть объективным = Как можно раньше признать, что срок сорван.
2. Не паниковать. Когда понимаешь, что срок сорван — надо собраться, а не панику разводить. Не дёргать каждые 5 минут исполнителей, а сделать новую версию плана. Пытаясь "влезть" в сорванный срок менеджеры начинают творить глупости — задалбывают исполнителей. Влезть порой получается, но в режиме задалбывания — почти никогда.
3. Знать новый срок, иметь новый план. Удивительно, но добиться нового срока обычно сложнее, чем прежнего:
— Я не успеваю к 30 марта.
— А к когда успеваешь?
— Ну ... Это ... Не знаю ...
4. Поддерживать контакт с заказчиком задачи/проекта, не обманывать и не пропадать (см. Не пропадать). Самое плохое, что можно сделать — обманывать заказчика:
Звонит заказчик:
— Успеваете?
— Да, должны успеть.
Вешает трубку.
— Эй парни, давайте постараемся. Я сказал, что мы должны успеть.
5. Предлагать решения, а не разводить руками. К завершению одной задачи могло быть привязано начало следующей. Например, заказчик получает сайт и начинает его рекламировать, потому что 12 апреля он должен распродать .... Но ясно, что сайт не будет готов к нужной дате. Плохой исполнитель — вешает на заказчика проблемы. Хороший — предлагает решение.
#совет #softskills из раннего
Самопроверка комфортности
Вы когда-нибудь задумывались, а комфортно ли с вами работать? Вы комфортный для рабочих взаимодействий человек?
Если не задумывались, то предлагаю проверить себя по следующим пунктам:
1. Я отвечаю на запросы так же оперативно, как жду ответа на свои запросы.
2. Я формулирую задачи так же ёмко, как хочу, чтобы задачи формулировали для меня.
3. Я отвечаю на запросы так же исчерпывающе, как хочу, чтобы отвечали мне.
4. Я даю коллегам столько же обратной связи, сколько хочу, чтобы давали мне.
5. Тональность моего взаимодействия с коллегами такая же, которую я ожидаю от коллег.
Если по всем пунктам честное ДА - вы даёте коллегам такой же сервис взаимодействия, который ожидаете от них. Это не значит, что вы хороши для взаимодействий в глазах коллег, но значит, что вы не ждёте большего, чем даёте сами.
Если же вы даёте при взаимодействии меньше, чем ждёте в ответ - есть повод задуматься.
#softskills
Вы когда-нибудь задумывались, а комфортно ли с вами работать? Вы комфортный для рабочих взаимодействий человек?
Если не задумывались, то предлагаю проверить себя по следующим пунктам:
1. Я отвечаю на запросы так же оперативно, как жду ответа на свои запросы.
2. Я формулирую задачи так же ёмко, как хочу, чтобы задачи формулировали для меня.
3. Я отвечаю на запросы так же исчерпывающе, как хочу, чтобы отвечали мне.
4. Я даю коллегам столько же обратной связи, сколько хочу, чтобы давали мне.
5. Тональность моего взаимодействия с коллегами такая же, которую я ожидаю от коллег.
Если по всем пунктам честное ДА - вы даёте коллегам такой же сервис взаимодействия, который ожидаете от них. Это не значит, что вы хороши для взаимодействий в глазах коллег, но значит, что вы не ждёте большего, чем даёте сами.
Если же вы даёте при взаимодействии меньше, чем ждёте в ответ - есть повод задуматься.
#softskills
Не суетись
Если вы смотрели Шрек-2, то вспомните сцену, в которой Шрек, Фиона и осёл ехали в гости к родителям Фионы. Осёл каждые пять минут спрашивал: "Уже приехали?", "Ну что, уже приехали?", "А сейчас приехали?" ...
Излишняя суета порой накрывает менеджеров (всех мастей): "Ну что, доделал?", "Нарисовал?", "Написал?", "Прошла модерация? А когда? А как ускорить?", "А можешь задержаться?", "Пообедаешь поскорее, чтобы успеть?".
Обычно волны суеты накрывают, когда что-то идёт не по плану: срывается срок, вылезла какая-то гадость на проде, сервак лёг, срочный запрос в поддержку и т.д.
Помню, накрытый волной суеты, ходишь вокруг да около программиста и уточняешь, как тот осёл: Нашёл причину ошибки? А скоро найдёшь? Ну ок, скоро вернусь.
Обычно такая суета никак не ускоряет процесс, а отвлекает на лишние действия и раздражает окружающих. Проще говоря, менеджер задалбывает, а не помогает. Ну и в спешке всегда хромает качество.
Вряд ли, рушится Мир и надо дышать в спину программисту (дизайнеру/копирайтеру ...) — у меня Мир не рушился (хотя казалось иное), в 100% случаев можно было меньше суетиться. Твоих коллег на дольше хватит, если они работают в спокойном режиме.
На что можно заменить суету:
— доверие к исполнителю. Обозначить всю важность ситуации и попросить к определённому сроку предоставить статус по проблеме.
— приготовить план "Б". Часто суетиться и дышать в спину уже поздно — надо готовить вторую версию плана: думать, где можно срезать углы; думать, что делать, если всё же не успеем; думать, что сказать заказчику и т.д.
— обозначить, каким качеством можно пожертвовать ... и как его потом вернуть. Качество, утерянное в авральном режиме, должно быть зафиксировано и возвращено при выходе из этого режима.
— успокоиться самому: "Будет ли важна эта проблема через год?" Обычно, такой вопрос снимает волну суеты и помогает думать яснее.
В общем, менеджер — это оплот спокойствия, а не источник задёрганности.
Вокруг шум. Пусть так
Ни кипишуй. Всё ништяк
(Каста)
#softskills из давно опубликованного
Если вы смотрели Шрек-2, то вспомните сцену, в которой Шрек, Фиона и осёл ехали в гости к родителям Фионы. Осёл каждые пять минут спрашивал: "Уже приехали?", "Ну что, уже приехали?", "А сейчас приехали?" ...
Излишняя суета порой накрывает менеджеров (всех мастей): "Ну что, доделал?", "Нарисовал?", "Написал?", "Прошла модерация? А когда? А как ускорить?", "А можешь задержаться?", "Пообедаешь поскорее, чтобы успеть?".
Обычно волны суеты накрывают, когда что-то идёт не по плану: срывается срок, вылезла какая-то гадость на проде, сервак лёг, срочный запрос в поддержку и т.д.
Помню, накрытый волной суеты, ходишь вокруг да около программиста и уточняешь, как тот осёл: Нашёл причину ошибки? А скоро найдёшь? Ну ок, скоро вернусь.
Обычно такая суета никак не ускоряет процесс, а отвлекает на лишние действия и раздражает окружающих. Проще говоря, менеджер задалбывает, а не помогает. Ну и в спешке всегда хромает качество.
Вряд ли, рушится Мир и надо дышать в спину программисту (дизайнеру/копирайтеру ...) — у меня Мир не рушился (хотя казалось иное), в 100% случаев можно было меньше суетиться. Твоих коллег на дольше хватит, если они работают в спокойном режиме.
На что можно заменить суету:
— доверие к исполнителю. Обозначить всю важность ситуации и попросить к определённому сроку предоставить статус по проблеме.
— приготовить план "Б". Часто суетиться и дышать в спину уже поздно — надо готовить вторую версию плана: думать, где можно срезать углы; думать, что делать, если всё же не успеем; думать, что сказать заказчику и т.д.
— обозначить, каким качеством можно пожертвовать ... и как его потом вернуть. Качество, утерянное в авральном режиме, должно быть зафиксировано и возвращено при выходе из этого режима.
— успокоиться самому: "Будет ли важна эта проблема через год?" Обычно, такой вопрос снимает волну суеты и помогает думать яснее.
В общем, менеджер — это оплот спокойствия, а не источник задёрганности.
Вокруг шум. Пусть так
Ни кипишуй. Всё ништяк
(Каста)
#softskills из давно опубликованного
Уточните, что такое ...
Пожалуй, самый важный навык, приобретëнный по мере профессионального роста — отсутствие страха показаться глупым, когда ты задаёшь вопросы.
Если мне что-то рассказывают, а я не понял термины — я их уточню.
Если я не уверен, что верно понял смысл — я уточню, рассказав как именно я понял.
Нет никакой причины, по которой кто-либо вообще должен стесняться уточнять, боясь показаться глупым. Не понял — уточни.
Но если ты периодически уточняешь одно и тоже — вот тут, конечно, уже вопросики🤨
#softskills
Пожалуй, самый важный навык, приобретëнный по мере профессионального роста — отсутствие страха показаться глупым, когда ты задаёшь вопросы.
Если мне что-то рассказывают, а я не понял термины — я их уточню.
Если я не уверен, что верно понял смысл — я уточню, рассказав как именно я понял.
Нет никакой причины, по которой кто-либо вообще должен стесняться уточнять, боясь показаться глупым. Не понял — уточни.
Но если ты периодически уточняешь одно и тоже — вот тут, конечно, уже вопросики
#softskills
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Про удобство (Михаил Греков) (MGrekov)
Просить помощь у коллег — это сила или слабость?
Мои наблюдения за коллегами и внешними командами говорят о том, что начинающие (джуны) боятся просить помощь. Наверное, это близко к мысли: "Если я попрошу помощь, то я признаюсь, что не понимаю как делать дальше — меня будут считать тупым!"
Задержусь, ночь потрачу — зато сам, зато смог!
А если задержался, ночь потратил и в итоге не смог? Значит, профукал время. Значит, команде хуже.
Чем сильнее специалист, тем меньше у него пунктиков на тему: подумают, что я тупой. Сильные специалисты быстрее просят помощи у коллег и в итоге, меньше тормозят командную работу. "Я не понимаю, как делать дальше — можешь помочь?" — ничего тупого в этом нет.
Очень важный момент для командной работы — развивать культуру взаимопомощи и активно окунать в эту культуру новых участников команды. Не надо задерживаться и ночами не спать — попроси помощь, так быстрее.
Без перегибов, конечно. Сам попробовал и точно завис — проси помощь. А если не пробовал и сразу просишь — злоупотребление и слабость.
В общем, нет ничего лучше для команды, чем сильная культура искренней взаимопомощи. Просить и предлагать своевременно помощь — сила команды.
#совет #softskills
Мои наблюдения за коллегами и внешними командами говорят о том, что начинающие (джуны) боятся просить помощь. Наверное, это близко к мысли: "Если я попрошу помощь, то я признаюсь, что не понимаю как делать дальше — меня будут считать тупым!"
Задержусь, ночь потрачу — зато сам, зато смог!
А если задержался, ночь потратил и в итоге не смог? Значит, профукал время. Значит, команде хуже.
Чем сильнее специалист, тем меньше у него пунктиков на тему: подумают, что я тупой. Сильные специалисты быстрее просят помощи у коллег и в итоге, меньше тормозят командную работу. "Я не понимаю, как делать дальше — можешь помочь?" — ничего тупого в этом нет.
Очень важный момент для командной работы — развивать культуру взаимопомощи и активно окунать в эту культуру новых участников команды. Не надо задерживаться и ночами не спать — попроси помощь, так быстрее.
Без перегибов, конечно. Сам попробовал и точно завис — проси помощь. А если не пробовал и сразу просишь — злоупотребление и слабость.
В общем, нет ничего лучше для команды, чем сильная культура искренней взаимопомощи. Просить и предлагать своевременно помощь — сила команды.
#совет #softskills
Не пропушишь — не проживёшь
Пропушить — напомнить кому-то, запросить повторно информацию и т.д.
Пуши от продуктов
Обращаю внимание как продукты меня пушат — я не про push-уведомления в приложениях, а в целом про попытки меня вовлечь, не потерять. Мотаю на ус, собираю практики.
👉 Напоминания на почту.
Ну такое, слабо работают, чтобы привлечь. Мягко говоря, почти не работают.
👉 СМС-ки.
Всё ещё работают, но поток большой в последнее время.
Работают обычно 2-м номером: сперва почта, а если я проигнорил — СМС.
👉 Таргетированная реклама.
Догоняют и просят закончить начатое. Яндекс-Практикум через ретаргет просил допройти курс 😂
👉 Звонки. Работают, если продукт мне знаком:
— Альфа (живой человек) звонит и напоминает о продлении ОСАГО (запрашиваю продление и сразу на почту присылают ссылку для оплаты),
— Скаенг (в записи) звонит и напоминает, что оплаченные уроки скоро кончатся (иду и пополняю),
— Вадик из Зерокодинга (в записи) позвонил и позвал на интенсив (не пошёл, но удивился пушу),
— Хостинг. Звонили (в записи) напоминали, что вот-вот и всё закончится (побежал продлевать). Перед этим были почта и СМС, на которые я благополучно забил.
👉 Телеграм-Боты. У продукта есть бот для напоминаний — он пушит. Главное, мягко заставить пользователя на него подписаться.
Если продукт пушит меня умело — я только за. Мне нравится, что звонит робот Скаенга, и оператор из Альфы. А если продукт не умеет умело пушить — не прожить ему в современном мире.
Пуши в работе менеджера
Быть пушером — очень ценное для работы, да и для жизни, качество. По сути, быть пушером — это быть проактивным в вопросе получения информации, которая тебе нужна. Мне периодически пишут в личку всякие рекламные предложения и т.п. — сразу видно, где наняли пушера на работу, а где застенчивый человек. Пушер 10 раз напомнит, запросит, спросит пока не получит ответ. А застенчивый разведёт руками: "Ну я уже напомнил, а мне так и не ответили. Что же я могу сделать ...".
Если вы стесняетесь запросить повторно у клиента оплату, напомнить исполнителю о сроках, запросить статус работ, .... — вы не пушер и на лидирующую позицию претендовать будет тяжело.
#UX #softskills из давно опубликованного
Пропушить — напомнить кому-то, запросить повторно информацию и т.д.
Пуши от продуктов
Обращаю внимание как продукты меня пушат — я не про push-уведомления в приложениях, а в целом про попытки меня вовлечь, не потерять. Мотаю на ус, собираю практики.
👉 Напоминания на почту.
Ну такое, слабо работают, чтобы привлечь. Мягко говоря, почти не работают.
👉 СМС-ки.
Всё ещё работают, но поток большой в последнее время.
Работают обычно 2-м номером: сперва почта, а если я проигнорил — СМС.
👉 Таргетированная реклама.
Догоняют и просят закончить начатое. Яндекс-Практикум через ретаргет просил допройти курс 😂
👉 Звонки. Работают, если продукт мне знаком:
— Альфа (живой человек) звонит и напоминает о продлении ОСАГО (запрашиваю продление и сразу на почту присылают ссылку для оплаты),
— Скаенг (в записи) звонит и напоминает, что оплаченные уроки скоро кончатся (иду и пополняю),
— Вадик из Зерокодинга (в записи) позвонил и позвал на интенсив (не пошёл, но удивился пушу),
— Хостинг. Звонили (в записи) напоминали, что вот-вот и всё закончится (побежал продлевать). Перед этим были почта и СМС, на которые я благополучно забил.
👉 Телеграм-Боты. У продукта есть бот для напоминаний — он пушит. Главное, мягко заставить пользователя на него подписаться.
Если продукт пушит меня умело — я только за. Мне нравится, что звонит робот Скаенга, и оператор из Альфы. А если продукт не умеет умело пушить — не прожить ему в современном мире.
Пуши в работе менеджера
Быть пушером — очень ценное для работы, да и для жизни, качество. По сути, быть пушером — это быть проактивным в вопросе получения информации, которая тебе нужна. Мне периодически пишут в личку всякие рекламные предложения и т.п. — сразу видно, где наняли пушера на работу, а где застенчивый человек. Пушер 10 раз напомнит, запросит, спросит пока не получит ответ. А застенчивый разведёт руками: "Ну я уже напомнил, а мне так и не ответили. Что же я могу сделать ...".
Если вы стесняетесь запросить повторно у клиента оплату, напомнить исполнителю о сроках, запросить статус работ, .... — вы не пушер и на лидирующую позицию претендовать будет тяжело.
#UX #softskills из давно опубликованного
Самое важное знание об эффективности
Сперва начну с самого важного заблуждения: многозадачность.
Человек ни разу не многозадачен. Не верите?
Сделайте простейший эксперимент.
1. Возьмите колоду карт, перемешайте, начтине раскладывать карты по мастям в четыре стопки. У вас легко и просто получится это сделать, без особых пауз.
2. Теперь делайте то же самое. Но параллельно вслух играйте в города: Душанбе-Ереван-Новгород-... . Появятся паузы при раскладке карт: вы либо определяете к какой масти относится карта, либо вспоминаете город.
Мы не многозадачны даже при реализации простейших действий, требующих нашего внимания. Мы можем только переключаться между задачами. Если с этим смириться, то легко понять самое важное знание об эффективности.
Те паузы, которые возникают при переключении между задачами (вспоминаешь город, с зависшей в руках картой) — налог на переключения.
Чем меньше за день вы платите налога на переключения — тем выше ваша эффективность.
Это самое важное знание об эффективности — оно очень простое и все тренеры по личной эффективности рассказывают вокруг да около этого правила.
Есть всего несколько способов снизить суммарный налог.
Очевидные:
1. Одна задача в единицу времени. Этакий последовательный конвейер.
2. Меньше внешних отвлечений. Этакий последовательный конвейер в тихом месте без уведомлений.
3. Снижать количество стресса. Этакий последовательный конвейер в тихом месте без уведомлений с дзеном в голове.
Очевидные способы крайне тяжко реализовать на полную: будут переключения, будут отвлечения и периодически есть стрессы.
Поэтому есть неочевидные способы снизить налог:
1. Смириться, что есть переключения — будет меньше стресса из-за переключений.
2. Тренировать память — будет проще переключаться, меньше деталей будет забываться при прыжках по задачам.
3. Вырабатывать автоматизмы — на автомате делать часть рутинных задач. Опытный водитель может ехать, пить кофе и давать сдачу пассажирам. Новичок с трудом будет только ехать.
4. Совмещать мыслительные задачи с автоматизмами. Если у вас есть ряд рутинных задач, которые вы уже можете делать на автоматизме, то с ними можно сочетать мыслительные задачи (мозг свободен). Но не совмещать без острейшей нужды мыслительное и мыслительное.
5. Планировать меньше задач на единицу времени, выкидывать лишнее, делегировать.
В общем, любая книга по самоэффективности ложится внутрь этой заметки. Сэкономил вам время :)
#совет #softskills из давно опубликованного
Сперва начну с самого важного заблуждения: многозадачность.
Человек ни разу не многозадачен. Не верите?
Сделайте простейший эксперимент.
1. Возьмите колоду карт, перемешайте, начтине раскладывать карты по мастям в четыре стопки. У вас легко и просто получится это сделать, без особых пауз.
2. Теперь делайте то же самое. Но параллельно вслух играйте в города: Душанбе-Ереван-Новгород-... . Появятся паузы при раскладке карт: вы либо определяете к какой масти относится карта, либо вспоминаете город.
Мы не многозадачны даже при реализации простейших действий, требующих нашего внимания. Мы можем только переключаться между задачами. Если с этим смириться, то легко понять самое важное знание об эффективности.
Те паузы, которые возникают при переключении между задачами (вспоминаешь город, с зависшей в руках картой) — налог на переключения.
Чем меньше за день вы платите налога на переключения — тем выше ваша эффективность.
Это самое важное знание об эффективности — оно очень простое и все тренеры по личной эффективности рассказывают вокруг да около этого правила.
Есть всего несколько способов снизить суммарный налог.
Очевидные:
1. Одна задача в единицу времени. Этакий последовательный конвейер.
2. Меньше внешних отвлечений. Этакий последовательный конвейер в тихом месте без уведомлений.
3. Снижать количество стресса. Этакий последовательный конвейер в тихом месте без уведомлений с дзеном в голове.
Очевидные способы крайне тяжко реализовать на полную: будут переключения, будут отвлечения и периодически есть стрессы.
Поэтому есть неочевидные способы снизить налог:
1. Смириться, что есть переключения — будет меньше стресса из-за переключений.
2. Тренировать память — будет проще переключаться, меньше деталей будет забываться при прыжках по задачам.
3. Вырабатывать автоматизмы — на автомате делать часть рутинных задач. Опытный водитель может ехать, пить кофе и давать сдачу пассажирам. Новичок с трудом будет только ехать.
4. Совмещать мыслительные задачи с автоматизмами. Если у вас есть ряд рутинных задач, которые вы уже можете делать на автоматизме, то с ними можно сочетать мыслительные задачи (мозг свободен). Но не совмещать без острейшей нужды мыслительное и мыслительное.
5. Планировать меньше задач на единицу времени, выкидывать лишнее, делегировать.
В общем, любая книга по самоэффективности ложится внутрь этой заметки. Сэкономил вам время :)
#совет #softskills из давно опубликованного
Самопроверка комфортности
Вы когда-нибудь задумывались, а комфортно ли с вами работать? Вы комфортный для рабочих взаимодействий человек?
Если не задумывались, то предлагаю проверить себя по следующим пунктам:
1. Я отвечаю на запросы так же оперативно, как жду ответа на свои запросы.
2. Я формулирую задачи так же ёмко, как хочу, чтобы задачи формулировали для меня.
3. Я отвечаю на запросы так же исчерпывающе, как хочу, чтобы отвечали мне.
4. Я даю коллегам столько же обратной связи, сколько хочу, чтобы давали мне.
5. Тональность моего взаимодействия с коллегами такая же, которую я ожидаю от коллег.
Если по всем пунктам честное ДА - вы даёте коллегам такой же сервис взаимодействия, который ожидаете от них. Это не значит, что вы хороши для взаимодействий в глазах коллег, но значит, что вы не ждёте большего, чем даёте сами.
Если же вы даёте при взаимодействии меньше, чем ждёте в ответ - есть повод задуматься.
#softskills из давно опубликованного
Вы когда-нибудь задумывались, а комфортно ли с вами работать? Вы комфортный для рабочих взаимодействий человек?
Если не задумывались, то предлагаю проверить себя по следующим пунктам:
1. Я отвечаю на запросы так же оперативно, как жду ответа на свои запросы.
2. Я формулирую задачи так же ёмко, как хочу, чтобы задачи формулировали для меня.
3. Я отвечаю на запросы так же исчерпывающе, как хочу, чтобы отвечали мне.
4. Я даю коллегам столько же обратной связи, сколько хочу, чтобы давали мне.
5. Тональность моего взаимодействия с коллегами такая же, которую я ожидаю от коллег.
Если по всем пунктам честное ДА - вы даёте коллегам такой же сервис взаимодействия, который ожидаете от них. Это не значит, что вы хороши для взаимодействий в глазах коллег, но значит, что вы не ждёте большего, чем даёте сами.
Если же вы даёте при взаимодействии меньше, чем ждёте в ответ - есть повод задуматься.
#softskills из давно опубликованного
Смекалка
Пожалуй, самое большое отличие проектной и продуктовой деятельности в том, что в продукте смекалка нужна по-любому и в больших объёмах. Смекалка — умение нестандартно решать сложные задачи и выходить из безвыходных положений.
У проекта есть каркас требований в любом случае — заказчик сам в основном решает, что будет в основе его продукта, как продукт продвигать, как завоёвывать любовь пользователей и т.д. В проектной деятельности смекалка нужна, чтобы к сроку сделать проект с хорошим качеством и минимальной себестоимостью. Если с ресурсами всё хорошо, то выходить из безвыходных положений не особо-то и надо — надо дать исполнителям посильные задачи и держать руку на пульсе.
А в продукте всё иначе — вся команда должна быть смекалистой. Если вы посмотрите на истории роста продуктов на ранних стадиях, то большинство Гровс хакингов строятся вокруг того, что кто-то придумал что-то хитрое и оно сработало.
Например, на заре своего существования Амазон заказывал книги в крупной книжной сети (забыл название). И заказать можно было только оптом по 10 штук. Т.е. приходит человек на сайт Амазона, выбирает книгу, заказывает, а дальше Амазон, чтобы ему её доставить, должны были перезаказать её. Но одну перезаказать нельзя — только 10. Что делать?
Стали заказывать 10: 3-4 тех, которые нужны клиентам, а остальное — экземпляры какой-то редкой книги, типа "Справочник редких растений Аризоны". Поставщик извинялся, что не может достать несколько экземпляров справочника (их у него просто не было) и доставлял только то, что нужно было Амазону на самом деле. Смекалка.
Когда я запускал свой первый продукт — b2b система для автоматизации торговых представителей (мобильная торговля Флюгер-Продажи) — то у меня на руках было всего два кейса внедрения и те были проектными. Что делать, чтобы показать, что система достойная?
Я пошёл в Википедию в статью "Мобильная торговля" и добавил в неё раздел: ТОП-10 систем для автоматизации мобильной торговли. Нашу поместил на 5 место, лидеров вперёд. После этого я смог ссылаться, что по данным Википедии мы входим в ТОП-5 лучших систем — потенциальные клиенты со мной стали разговаривать, реагировать на материалы о системе.
Угадайте, какой раздел в этой статье был потом самым редактируемым? Да, через время конкуренты начали двигать места в этом ТОП-10 😂
В общем, ищите возможность развивать в себе смекалку. Смотреть чужие Гровс хакинги можно сколько угодно, но если нет почвы для развития своей смекалки — всё без толку.
#softskills из давно опубликованного
Пожалуй, самое большое отличие проектной и продуктовой деятельности в том, что в продукте смекалка нужна по-любому и в больших объёмах. Смекалка — умение нестандартно решать сложные задачи и выходить из безвыходных положений.
У проекта есть каркас требований в любом случае — заказчик сам в основном решает, что будет в основе его продукта, как продукт продвигать, как завоёвывать любовь пользователей и т.д. В проектной деятельности смекалка нужна, чтобы к сроку сделать проект с хорошим качеством и минимальной себестоимостью. Если с ресурсами всё хорошо, то выходить из безвыходных положений не особо-то и надо — надо дать исполнителям посильные задачи и держать руку на пульсе.
А в продукте всё иначе — вся команда должна быть смекалистой. Если вы посмотрите на истории роста продуктов на ранних стадиях, то большинство Гровс хакингов строятся вокруг того, что кто-то придумал что-то хитрое и оно сработало.
Например, на заре своего существования Амазон заказывал книги в крупной книжной сети (забыл название). И заказать можно было только оптом по 10 штук. Т.е. приходит человек на сайт Амазона, выбирает книгу, заказывает, а дальше Амазон, чтобы ему её доставить, должны были перезаказать её. Но одну перезаказать нельзя — только 10. Что делать?
Стали заказывать 10: 3-4 тех, которые нужны клиентам, а остальное — экземпляры какой-то редкой книги, типа "Справочник редких растений Аризоны". Поставщик извинялся, что не может достать несколько экземпляров справочника (их у него просто не было) и доставлял только то, что нужно было Амазону на самом деле. Смекалка.
Когда я запускал свой первый продукт — b2b система для автоматизации торговых представителей (мобильная торговля Флюгер-Продажи) — то у меня на руках было всего два кейса внедрения и те были проектными. Что делать, чтобы показать, что система достойная?
Я пошёл в Википедию в статью "Мобильная торговля" и добавил в неё раздел: ТОП-10 систем для автоматизации мобильной торговли. Нашу поместил на 5 место, лидеров вперёд. После этого я смог ссылаться, что по данным Википедии мы входим в ТОП-5 лучших систем — потенциальные клиенты со мной стали разговаривать, реагировать на материалы о системе.
Угадайте, какой раздел в этой статье был потом самым редактируемым? Да, через время конкуренты начали двигать места в этом ТОП-10 😂
В общем, ищите возможность развивать в себе смекалку. Смотреть чужие Гровс хакинги можно сколько угодно, но если нет почвы для развития своей смекалки — всё без толку.
#softskills из давно опубликованного
Как отличить проработанное решение задачи от поверхностного
Если решение проработано, то вопросы к итогу не выбивают исполнителя из колеи. Он знает ответы, так как подбирался к задаче с разных сторон и не хватался за первое решение, которое ему показалось удачным.
В задачах, которые решают дизайнеры, копирайтеры, маркетологи и все, кто создаёт что-то новое, нет правильного решения.
Нельзя прийти к постановщику задачи и сказать: "Вот итог, правильно я сделал?"
Может быть только проработанное решение, которое после принятия, возможно, проверится цифрами.
Есть универсальный вопрос, который позволяет отличить проработанное решение от поверхностного:
"Ты уверен, что лучше эту задачу нельзя было решить ?"
Если решение проработано, то исполнитель расскажет про другие тупиковые ветки решения и почему выбрал то, что сделал.
Если решение поверхностное, то будет что-то вроде: "Ну, я точно не могу сказать. Давай я ещё подумаю?" или "А почему нет? Вроде, нормальное решение".
В общем, прорабатывайте решения и будьте в них уверены. Вдруг спросят: "Ты уверен?"
#softskills из ооочень давно опубликованного
Если решение проработано, то вопросы к итогу не выбивают исполнителя из колеи. Он знает ответы, так как подбирался к задаче с разных сторон и не хватался за первое решение, которое ему показалось удачным.
В задачах, которые решают дизайнеры, копирайтеры, маркетологи и все, кто создаёт что-то новое, нет правильного решения.
Нельзя прийти к постановщику задачи и сказать: "Вот итог, правильно я сделал?"
Может быть только проработанное решение, которое после принятия, возможно, проверится цифрами.
Есть универсальный вопрос, который позволяет отличить проработанное решение от поверхностного:
"Ты уверен, что лучше эту задачу нельзя было решить ?"
Если решение проработано, то исполнитель расскажет про другие тупиковые ветки решения и почему выбрал то, что сделал.
Если решение поверхностное, то будет что-то вроде: "Ну, я точно не могу сказать. Давай я ещё подумаю?" или "А почему нет? Вроде, нормальное решение".
В общем, прорабатывайте решения и будьте в них уверены. Вдруг спросят: "Ты уверен?"
#softskills из ооочень давно опубликованного