Как девочка, которая (выжила) попала в настоящую IT-компанию, набила шишек и методом проб и ошибок научилась справляться с задачами. Всем привет, меня зовут Мария Высотенко. Я работаю администратором проектов, то есть младшим менеджером, в IT-компании KODE. За двенадцать месяцев в должности я успела приложить руку к шести проектам. Из них два я закрывала самостоятельно: других менеджеров, кроме меня на проекте не было.  Сейчас приходя в новую команду или проект, я свободно представляю себя и свою зону ответственности и повторяю мантру: «Я не волшебник, пока ещё учусь». Но так было не всегда.  Мой путь в KODE — это стадии: щенячий восторг («я работаю в настоящей IT-компании»), охлаждение реальностью, взлёт продуктивности и внезапно для себя… срыв. Найти решения и выход помогли старшие коллеги. Я хотела сделать всё сразу «хорошо» (интересно, кто оценил бы меня по этому критерию): помочь команде, научиться проектировать API и тестировать через подмену значений. Интересное было время.  Мой успокоительный сбор начинающего (волшебника) РМ-а состоял из таких ингредиентов↓  Программист программирует, тестировщик тестирует, менеджер пишет «Когда сделаешь?». Постепенно к каждому PM-у приходит сакральное понимание его позиции. Наше дело — понимать краткосрочные и долгосрочные цели проекта и помогать команде достигать их. Наша главная сила — взгляд на несколько шагов вперёд. Я осознала, что что-то не так, когда на общем синке проджект-менеджеров назвала одной из своих задач «Поиск решений для разработки авторизации в один клик через Гугл», при этом менеджерская задача — подготовка отчета по спринту — была не сделана. В итоге «авторизацию» передали аналитику проекта, в качестве технического специалиста (удивительно) осталась разработчица, а я выдохнула и отправилась писать отчёт. Кстати, первый отчёт на проекте получился совсем простенькой таблицей: список фич, закрытых за две недели, и количество затраченных часов. И этого было достаточно. Теперь, когда на старте проекта ощущаю тревожность и панику, первым делом возвращаюсь к истокам. Закрываю основные задачи, которые может сделать только менеджер проекта. Я больше не прыгаю выше головы — просто делаю хорошо. Когда совсем тяжело — делаю нормально.  Учиться у старших коллег — всегда отличная идея, но не надо стремиться стать ими. На первых порах я старалась повторить всё за моим ментором на проекте, вплоть до tone-of-voice в переписке. С опытом на базовые задачи наслаиваются индивидуальные фишки: находить подход к команде, читать код, помогать аналитику при сборе системных требований или гипнотизировать коллег, чтобы переманить разработчика к себе на проект. Каждый сам для себя нащупывает индивидуальность в работе. Побочное действие оборотного зелья — привыкание, потеря себя, невозможность существовать без примера перед собой. А оно нам надо?  В списке задач менеджера проектов стоит в том числе сохранение контекста и договоренностей. В KODE я отточила навык фиксации решений в письменном виде, ведь это наглядный контекст для команды и заказчика. Требования к проекту чаще складываются на видео-синках — на них докручиваем идеи, в моменте команда разработки сообщает, какие есть технические ограничения у определенного бизнес-видения. Команда сыплет техническими терминами, заказчик, вдохновленный дизайном и далёким дедлайном, предлагает множество идей, на трансляции сменяются экраны с дизайном, майндмэпами, таблицами — даже навык быстрой печати мне не помогает зафиксировать всё.  Чтобы не потерять контекст, я записываю видео созвонов. Для этого я использую встроенную функцию Zoom для записи звонка, плагин Vimeo или программу Movavi. Очевидно и всё же — тестирую работу приложений перед каждым важным звонком.  На всю жизнь запомнишь первую любовь и ту самую беззвучную запись, где вы обсуждали системные требования по новой фиче.  NB: корректно выбираю устройства записи для Vimeo — иногда не пишет микрофон. Movavi записывает весь экран, так как это десктопное приложение — обращаю внимание, чтобы лишнее не попало на запись (Телеграм с перепиской не по теме) . Не хочется краснеть, когда заказчик или команда попросят показать запись. Перед стартом записи обязательно уведомляю всех участников встречи. За все время работы мне ни разу не отказали. На одном из дейли я призналась, что не понимаю зависимостей между ролями в ходе разработки и какие условия надо указать настройках AppStore, чтобы опубликовать приложение для iOS — и общаться с командой стало проще. Менеджер становится более прогнозируемым для команды — легче работать с тем, чьи действия понятны.  Позже поняла, что все наши команды сбалансированы: джуна-менеджера уравнивают опытными спецами других направлений, которые вовремя дадут обратную связь и вернут тебя в правильное русло. Также незримой фигурой присутствует ментор на проекте или выше — ментор в компании. К ним можно обращаться по общим вопросам и, когда прижмёт, по переживаниям, связанным с работой.  Мой Патронус имеет форму менеджера портфеля проектов — это мой ментор. В компании он наблюдает сразу за несколькими проектами, а как ментор — отвечает на технические вопросы и показывает, как можно работать эффективнее.  В самом начале моего пути ментор также проводил со мной ежедневные синки, чтобы узнать моё состояние и помочь расставить приоритеты по задачам. Такие встречи очень помогли адаптироваться.  Я вызывала Патронуса, когда случался затык, а выбранные решения не срабатывали. Совет ментора может сэкономить время, а значит — деньги для проекта. Правда в таком случае надо фильтровать вопросы — ответ может быть в Гугле, базе знаний компании. Или уже внутри тебя.  Этот вывод я считаю самым главным для себя. Мне не удавалось «вовремя» уходить с работы, укладывать задачи в рабочий день, потому что я неверно расставляла приоритеты.  Теперь в начале дня несколько минут я посвящаю составлению плана на день. Группирую задачи по проектам и приоритету: есть ли дедлайн, как влияет на проект. Распределяю их так, чтобы часть дня была занята только задачами по определенному проекту — не происходило переключение контекста.  Для этого под рукой держу блокнот, выписываю задачи, которые в процессе. При этом нужно оставаться на связи, поэтому задачи декомпозирую на более маленькие, по 1-2 часа. Заранее предупреждаю команду, что ближайший час могу отвечать долго.  У меня есть проекты, на которых мое внимание наиболее нужно, например новый заходящий проект. Есть проекты на поддержке, где мы выполнили задачи, сдали проект, но остались в нём в качестве экспертов. Там я спокойно пишу «отвечу в течение дня» — и возвращаюсь, когда поспокойнее. У нас в компании есть система грейдирования с четкими требованиями к каждому уровню, поэтому понимаю, к чему стремиться. В моём отделе эта система представлена 42 критериями!  Я оценила критерии, которые мне надо подтянуть, выбрала обучающие материалы. Метод определения приоритетов ICE помогает мне понять порядок изучения тем — пригодился менеджерский опыт.  ICE — это аббревиатура, состоящая из слов Impact (влияние), Confidence (уверенность), Ease (лёгкость). Каждому критерию ставится оценка от 1 до 10, потом они перемножаются. Чем больше оценка — тем выше приоритет. Метод ICE я адаптировала под себя: перемножила показатели «личный интерес», «применимость на проекте сейчас» и «релевантность для будущей работы». В топ вырвались темы: «Как давать обратную связь», «Настройка менеджерских инструментов», «Как вести переговоры». Изучаю их сейчас. В будущем возьму Change Management и «Управление конфликтами».  Люди действительно замечают наши ошибки и слабости. Это может удручать. Сил придает мысль о том, что это работает и в другую сторону! Как только специалист начинает расти — это заметно окружающим. Вывод, который я сделала: важно дать себе время влиться в процесс и понять правила игры. Каждый день маленькими шагами я делала лучше, чем это было вчера. Без надрыва, в своем темпе, с пониманием, зачем мне это, зачем это проекту.  Постепенно повторение этих пунктов, советы ментора помогли мне выйти на новый уровень ментального спокойствия, грейда и уверенности в себе.  Разработчик цифровых продуктов