#резюме

Привет! Меня зовут Михаил, ищу работу младшим менеджером проектов в IT/FinTech/EdTech.

Мой опыт:
- два года в продажах в Skyeng: писал скрипты, обучал новичков, продавал компаниям корпоративный английский и разрабатывал процессные карты для работы с компаниями;
- окончил курс от Skillbox — "Руководитель digital-проектов" и полгода управляю проектами в Rocket Science: продавал рефакторинг и добивал его, руководил проектами по разработке и поддержке сайтов и мобильного приложения.
Почему я буду полезен: понимаю этапы разработки программного обеспечения, смогу отличить Waterfall от Agile и верно их применить, умею работать с Jira и Asana, пишу ТЗ и ставлю задачи разработчикам.
Коротко о себе: проактивен, коммуникабелен и легко нахожу общий язык с командой, могу убеждать и продавать, не ищу крайних и беру ответственность на себя.

Идеально, если: удаленка, работа над продуктом, зарплата от 40 т.р.

Подробности тут: https://hh.ru/resume/6573ad0aff059127e70039ed1f764a3769306e

Связь: @tentecool / gerun.mikhail@gmail.com

И среди себя и коллег не представляю

Тогда вопрос возник: счётчик просмотра резюме на хх срабатывает только от касания самого резюме или достаточно посмотреть отклик?

Тогда вопрос возник: счётчик просмотра резюме на хх срабатывает только от касания самого резюме или достаточно посмотреть отклик?

касания хватает

менеджер видит все отклики и фрагмент сопроводительного (если оно есть, несколько строк всего). Если ты кликаешь на кандидата (его отклик), то проваливаешься в резюме + сопроводительное –> идет просмотр

Напоминаю, что в пятницу в 8 вечера по МСК у нас созвон

Сегодня, примерно в 22-23 по МСК создам опрос с голосованием по темам.

Голосование закрывается утром, в пятницу. В процессе голосования можно (нужно!) обсуждать темы и их ценность.
Выберем штуки 3-4, для начала.

Какие темы есть сейчас:
- что такое OKR и зачем
- Как работать с гипотезами (правильно понял?)
От @yura_ant
в этот раз Юра не сможет рассказать, но темы пока не снимаю. Расскажите, если знаете вы :)

- Смотрим на табличку метрик от Skyeng и предполагаем, что можно оттуда забрать, а что бред. И почему.
От @khomyakovrp

- Как вы прокачиваетесь в профессиональной сфере. Что дало заметный результат и какой.
- Какие 3-5 советов вы могли бы дать себе в прошлом, в самом начале пути.
От @revealed_dave


Как предложить тему:
Напишите тему в чат и расскажите, почему вы считаете ее интересной. Или не рассказывайте, но тему напишите.

Предлагать тему желательно до начала голосования.

Предложить может кто угодно. Ваши навыки, мировоззрение или любовь к аниме не влияют на возможность предложить тему :)

Не смог пройти мимо) В работе саппорта есть один важный параметр FCR (first call resolution), это процент решённых запросов без переадресации на старшую линию поддержки. У вас проблемы на самом деле нет, картина достаточно стандартная: L1 регистрирует/маршрутизирует + пытается решить. L2 - копает вглубь, пока хватает базовых навыков и доступов, что бы поправить код или решить inc. Как правило L1-L2 отрабатывают достаточно оперативно, у них фокус усилий именно на этом. А вот L3 это реально жеппа. В большинстве случаев L3 это скиловые спецы, у которых ваши тикеты идут третьими с конца по приоритетам и если начинать смещать фокус на устранение Inc, то они скорее всего со временем уйдут, т.к. такая работа это не по уровню, у них задача замерять на основе inc, качество реализованного функционала и копаться в коде будут разве что при устранении корневой причины группы Inc, чем  решать конкретный кейс конкретного пользователя. Это, скажем так, из наблюдений. Чтобы как-то начать исправлять ситуацию, обратиться придется не к технической стороне вопроса, а к организационной и первым делом я бы задумался, как увеличить этот самый FCR. Чуть более 10 лет назад решая такую же задачу я проделывал такую штуку: каждую неделю -две я выдергивал одного сотрудника из L2 и направлял на стажировку к L3, предварительно договорившись с руководителями профильных функций. Основная задача - поиск простых типовых операций, которые можно отнести к рутинным, но результат выполнения которых дает профит. За это время к инженеру L2 прилипало +2 к умениям и +5 к навыкам, после чего он возвращался обратно и уже мог делать самостоятельно чуть больше чем раньше (некоторые проблемы легко решаются путем повышения прав доступа). Потом следующий и т.д. Спустя N времени и прокачки скилов ставится задача составить перечень рутинных операций на L3, которые можно упаковать в простой скрипт и запуск которого не поломает систему, но исправит бажулю, причем не обязательно даже через повышение прав. После получения новых инструментов быстрого вмешательства и исправления с выполнением контрольной процедуры проверки, кол-во запросов на L3 начинает сокращаться. Мотивация для L3 - от них наконец то отстанут с "дурацкими" Inc от клиентов. Для L2 - добавление полномочий, апгрейд навыков, установление новых границ развития навыков + рост кол-ва решённых запросов в нормативное время. Тоже самое с L1. Постепенно нужно приучать операторов выполнять некоторые операции самостоятельно, что бы они смотрели немного глубже в специфику inc, а не просто их форвардили дальше без погружения в детали. Shadow support и reverse shadow support между L2  и L3 это по сути процесс skill transition, но за счёт смещения фокуса (у L2 - Inc, у L3 - проблемы или full debug) скорость решения начинает расти. Shadow support - L2 наблюдает за тем, как L3 осуществляет поддержку, т.е. face-2-face народ сидит и обрабатывает тикеты. Обычно на этом этапе вскрывается весь реальный пипец, который отгребает L3.
Reverse shadow support -  L2 при поддержке L3 пытается обработать тикеты. L3 проверяют и подсказывают. В свое время по такой схеме удалось довести долю FCR до 70% (с 15 примерно) на L1-L2 и запросы стали решаться практически online. А L3 получив больше времени на работу с более серьезными проблемами поняли, что передача рутинных операций на младшие линии бережет их от лишнего геморроя/стресса, поэтому они сами в последствии стараются скинуть с себя этот головняк. Ещё один профит - L3 получает источник для пополнения кадров, потому как где ещё искать спецов с развитым навыком решения Inc, которых можно погружать дальше в разработку не вкладываясь особо в наставничество с минимальным сроком ввода в новую должность. Есть и другие трюки, которые зависят от профиля компании, тематик, специфики запросов, но это уже другая история. Как-то так:)

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

Пригодились, сегодня как раз час посвятили именно темам обучения и развития:)