Ахахаха

Тут проджекты, проджекты ≠ JS разработчики.
JS разработчики в @javascript_jobs.

@liyayankova

Поняла, спасибо большое!

раскрой,пожалуйста,какой путь или алгоритм создания имени ты видишь

Раскройте, пожалуйста, как стать знаменитым и богатым

да почему-ж, не это ведь подразумевали под своей формулировкой. Даже если это, интересно, что ретроспективно думаете

Спасибо, посмотрел, это как раз то, что искал, и ментора подходящего нашёл. 💪🏼 так то опыт  менеджером\руководителем проекта в строительстве 7 лет. Поэтому не рано) самое то 😉

Спасибо) поменял немного подход) будут конкретные вопросы обращусь) 7 лет проектов в строительстве и 0 в IT. Проблема только в этом ( была); отсутствие опыта конкретно в IT.

#вакансия #projectmanager
Здравствуйте!

Ищем: Project manager

💰З/П: 90 000–150 000 ₽
🌎Город: Омск
(Можно удаленно)

Мы продуктовая дирекция "Кредиты" ГК Компании. Основной задачей подразделения является разработка кредитного модуля автоматизированной банковской системы.

📍Обязанности📍:
- Участие в формировании списка задач команды, приоритизация работ, распределение задач в команде, контроль результата.
- Контроль за обеспечением необходимого проектного документооборота (протоколы, акты, СТП, ТЗ, все необходимые документы).
- Увеличение эффективности команды (повышение качества, сокращение трудозатрат на выполнение задачи).
- Налаживание взаимодействия внутри команды, командообразование.
- Взаимодействие с Заказчиком, менеджерами проектов, директором дирекции, смежными командами.

🗝Требования🗝:
- участие в проектной деятельности по разработке ПО от 1 года;
- опыт управления командой от 1 года;
- высшее образование (предпочтительно экономическое или техническое);
- Выполнение функций тим лида будет плюсом.

🔗Преимуществом будет🔗:
- опыт разработки на Oracle либо опыт работы системным аналитиком.

🎗Условия🎗:
- корпоративные скидки от компаний-партнеров (льготное ипотечное и потребительское кредитование, скидки на перелеты рейсами S7);
- программа ДМС;
- возможности для профессионального развития: являемся постоянными участниками, партнерами и организаторами крупных отраслевых мероприятий, сотрудники компании регулярно выступают спикерами на IT-конференциях;
- собственный Учебный Центр, электронная библиотека;
- дружный коллектив, обмен мнениями и опытом, возможность найти друзей по интересам среди коллег;
- работу в современном светлом офисе в центре города с уютной кухней и зоной отдыха (сейчас мы работаем удаленно);
- официальное трудоустройство, полный социальный пакет;
- релокационный пакет для кандидатов из других городов.

С удовольствием отвечу на все ваши вопросы:
📨 Saneeeees@gmail.com
@francoe_ur

10-15к/мес.? 😳😳😳

А вдруг у них на менеджера 10-15 проектов в месяц приходится)))

Умение проверять работу - скорее всего, тестера нет

Да ладно, всё равно на этапе просмотра портфолио не пройдём 😔

Корпоративные информационные системы с веб-мордой подойдут?

#вакансия #project #remote #удаленка #Agile #USA

Американская ИТ-компания, развивающая собственный продукт, в поисках Scrum Master / Project Manager.
Условия:
🔸Полностью удаленка
🔸Полная занятость, гибкий график
🔸Оплата в USD
🔸Возможность релокации в США и Канаду

Требования:
🔹Английский язык не менее Upper-Intermediate, способность общаться на английском
🔹Глубокое понимание ценностей и принципов Agile
🔹 Опыт работы в роли Скрам Мастера или Agile-коуча не менее 1 года
🔹 Опыт запуска команд с использованием гибких подходов
🔹 Опыт проведения Sprint Planning, PBR, Sprint Review, Sprint Retrospective
🔹 Умение строить RoadMap
🔹 Опыт работы в Jira
- знание Scaled Agile фреймворков будет плюсом

➡️ Пишите в личку: @kvpavel

Привет! У нас есть правила оформления вакансий и резюме.

Отредактируйте и мы его разместим в канал @projects_jobs_feed, или удалим через 5-10 минут если нет.

@revealed_dave
Дэйв, привет. Вспомнил, что ты упоминал работу с инцидентами, а у меня она как раз актуальна. Но раньше я особо не погружался.

Вопрос такой.
У нас в kpi и время реагирования на инцидент, и время его решения (когда всё починено и на проде).

Тех Дир недовольна нашими показателями (3 часа до выкатки на прод, в среднем), хочет плана по улучшениям.

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

Короче, вопрос: где искать точки роста в ускорении работы с инцидентами?

Не смог пройти мимо) В работе саппорта есть один важный параметр 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, которых можно погружать дальше в разработку не вкладываясь особо в наставничество с минимальным сроком ввода в новую должность. Есть и другие трюки, которые зависят от профиля компании, тематик, специфики запросов, но это уже другая история. Как-то так:)

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

Проблемы (корневые причины инцидентов) есть, но с ними пока, кажется, миримся просто.

Но сама механика обучения кажется может быть скопирована на наши реалии с небольшой адаптацией.