Привет, Хабр! Меня зовут Даниил Старосек, я работаю аналитиком в проекте ЕФР в Россельхозбанке. Сегодня расскажу вам о работе в условиях the roof is on fire. Поскольку мне не совсем комфортно говорить о себе в первом лице, будем использовать условное растение, которое зовут Митроша. Митроша попытается показать вам, что испытательный срок — на самом деле это круто, и происходящий вокруг хаос ни что иное, как время возможностей. Каждый сам для себя решает — быть собачкой из мемов, сидящей в окне и пытающейся делать вид, что все нормально, работать по инструкции и ждать, что все наладится (а что будет потом — не важно), или же быть укротителем хаоса!
Несколько небольших вводных.
У нас новый крутой проект.
Полностью новая команда.
Как всегда, сжатые сроки.
Конкретно у Митроши (и не только, учитывая юность команды) — испытательный срок.
Испытательный срок — всегда достаточно серьезный стресс. Порой на новом месте бывает максимально некомфортно. Кроме того, когда приходишь на новый проект нередко сталкиваешься со всеобщим беспорядком. Мало кто понимает, что прямо сейчас в данный момент нужно делать, что делать потом, кто все это должен делать. Из‑за этого довольно сильно растекаются границы проекта, и не только.
Интро
Митроша уже что‑то умеет в аналитике, в ИТ‑сфере работает около 6 лет, запустил несколько продуктовых проектов, работал в edTech и уже успел окунуться в банковскую сферу, работал с базами данных. Ему нравится работать в ИТ. Он хочет изучать новые технологии, развиваться, быстрее расти и вливаться в новые проекты. Думаю, это естественное желание для всего живого на Земле — расти больше, сильнее и быстрее.
Какие у Митроши сложности.
Он трясется — стресс из‑за нового места работы.
Проект только стартовал, а уже нужен результат — Митроша не с нуля пришел на проект, условно, он пришел летом, а проект запустили зимой. Команды нет, а точку контрольную к текущему моменту уже нужно выполнять. То есть работы уже должны быть выполнены, но команда только собралась. Отсюда вытекает и следующая сложность.
Новая команда — как и Митроша, большинство сокомандников новички, не работавшие ранее в компании. Соответственно, никто особо не ведает процессов связанных с разработкой, принятых в компании.
Менеджмент. По моему мнению, достаточно сложно сказать, что в сфере ИТ менеджмент сейчас в пике своей формы. Митрошу это тоже стороной не обошло.
Работа в проекте
Митроша попал на проект ЕФР — единое фронтальное решение. Это система, которой пользуются сотрудники в офисах РСХБ. Вы пришли в офис, присаживаетесь к операционисту, он вас обслуживает. Чтобы сотруднику банка не держать все в голове, а шел по сценарию, есть ЕФР, агрегирующее всю работу операциониста.
Система ЕФР была монолитным решением. Впоследствии его решили поделить на микросервисы. Кроме этого в системе необходимо реализовать новый функционал. Мы планируем выдавать так называемую продуктовую матрицу. То есть клиент приходит, изъявляет свои желания. Мы собираем от него минимальную информацию и подбираем максимально выгодный для клиента продукт. Зачастую в банке огромное количество различных продуктов, и есть варианты, заточенные под конкретный тип клиентов.
И вот Митроша работает в проекте неделю, у него все замечательно. Думаю, это стандартный процесс онбординга для многих из нас. Пришел в новую компанию, знакомишься с коллегами, изучаешь документацию, читаешь инструкции и так далее.
Однако вскоре более опытные коллеги уходят в отпуск на две недели, и Митроша вместе с 4 разработчиками остается один на всю общую команду около 35 человек! Непозволительная роскошь говорить ребятам: «А давайте приостановим процессы на пару недель, пока коллеги выйдут из отпуска». Поэтому Митроша начинает тушить пожары: бегать к коллегам из других команд, ковыряться в документации, искать, как помочь коллегам, чтобы не тормозился проект. Это все дело проходит с переменным успехом.
В процессе такой авральной работы Митроша успел сделать некоторые выводы.
В самом начале очень здорово определить границы своих компетенций, а также границы проекта. Конкретно в нашем проекте кроме системного аналитика, то есть Митроши, есть еще и бизнес‑аналитик. То есть мы уже можем проложить четкую границу между их компетенциями. В частности, системный аналитик не обязан ходить к бизнесу. Он ходит к конкретному специалисту, отвечающему за определенный результат. Также аналитик не занимается проработкой архитектурного решения, для этого есть архитектор, и так далее.
Не всё в твоих силах. Митроше не нужно отчаиваться, если он не справился с какой‑то работой. Не всё в твоих силах, особенно если ты проработал до этого всего неделю. Ты толком свои инструкции не успел осознать и прочитать.
Контакт с ЛПР — нужен. Очень важной оказалась аббревиатура, пришедшая к нам из продаж. ЛПР — лицо, принимающее решения. Оказалось, что Митроше стало намного проще жить, когда он нашел ЛПР и наладил с ними контакт. И это не всегда самый высокий по должности сотрудник. А вот коллега, работающий параллельно, может быть в курсе всех процессов.
Полезно понимать мотивацию каждого участника: product manager, product owner, архитектор, тестировщик и так далее. В определении мотивации очень хорошо помогает метод шести шляп. Надевая на себя одну шляпу мы, например, прикидываемся тестировщиком и думаем, как мир выглядит с его стороны. То же самое для менеджера задач и других. Тестировщик, например, хочет, чтобы не было ошибок при тестировании, и все найденные баги были исправлены. Однако аналитик может воспринимать скрупулезность и дотошность тестировщика как излишнюю придирчивость. Когда мы понимаем, что мотивация вполне адекватная, жить становится всем лучше и проще.
Confluence? Не, не слышал
Митроша искренне полагал, что он сейчас откроет Confluence, а там все есть. Как же классно будет работаться и проект стремительно взлетит.
Тем не менее Митроша пришел к выводу, что нужно думать не о потомках, а о наследниках! И когда просят скинуть ссылку на материалы в Confluence — лучше вместо ссылки говорить путь. Если ссылку кинули, ты прямо по ней перешел, один раз прочитал и/или где‑то сохранил. А вот разобравшись с оглавлением в Confluence, можно сформировать в голове структуру и путь к нужной информации.
Далее Митроша решил, что нужно делать инструкции. Зачастую инструкции написаны юридическим языком, состоят минимум из 20 страниц и с ними в целом очень сложно работать. А по‑настоящему нужных инструкций, таких как создать встречу, назначить комнату для вебинара и так далее делают очень мало, и эти вещи как правило передаются из уст в уста. Митроша сделал нужные человеческие инструкции и внезапно кратно вырос уровень уважения к нему. Поэтому Митроша решил оставлять цифровой след в компании, став создателем и составителем полезных материалов в Confluence.
Строй собственный план
Очень полезным для Митроши оказалось умение строить свой собственный план. Нужно не просто умение планировать, но и упорство достигать запланированных точек в поставленные самим собой сроки, а также не смещать их с появлением новых проектов. В хаосе не у всех есть свой план, либо он чисто формальный и точки фактически не достигаются.
Что было дальше?
После всех выводов, умозаключений и действий Митроша стал like a boss. Он наделал инструкций, помог всей команде наметить критический функционал, согласовать его и составить примерный план достижения цели. После всего этого к Митроше начали обращаться другие сотрудники, поскольку он может предпринять простые действия и реально помочь.
Что тут может пойти не так? Все просто — Митрошу заваливают вопросами и просьбами о помощи. Все думают, что раз он написал инструкции, значит все знает и может помочь по любым вопросам. Вскоре происходит переполнение такими запросами, работать становится некогда, Митроша всех консультирует и потихоньку выгорает.
Митроша нашел для себя выход — воспользоваться методологией scrum. Нужно разбить проект на составляющие части. Взять фреймворк работы, повесить отдельные микрозадачи на сотрудников и считать, что через две недели (у нас двухнедельные спринты) те или иные задачи должны быть выполнены. После собраться на ретроспективы и обсудить, кто что успел сделать. Митроше такая система сильно помогла.
Итоги
Что хотелось бы сказать в итоге. На самом деле испытательный срок — время возможностей. «Зеленый» еще сотрудник может очень хорошо себя проявить, увеличивая свой вес в команде. В то же время пока он на испытательном сроке всегда есть возможность сказать, что он недавно работает и ему нужно больше времени, чтобы разобраться. В командах профессионалов все очень адекватно реагируют, когда новичок говорит «я еще не разобрался». И никто не настаивает, что сотрудник на испытательном должен все знать уже через пару недель работы.
Хаос — время для роста. Пойдем от противного. В компании идеально налажены процессы, все делают свою работу, все расписано по обязанностям и времени. Вырасти в таких условиях сложно, поскольку взрывного роста без особых условий не будет. А вот когда вокруг царит хаос, никто не знает, что делать, и есть срочные задачи — самое время, чтобы проявить инициативу и получить импульс для ускорения вверх. За короткое время из отношения «он новый и пока ничего не умеет» сотрудник перерастает в «он очень ценный и много чего умеет делать».
Зафиксируем советы от Митроши.
Примеряйте роли — используйте метод «шести шляп» для понимания мотивации коллег.
Делайте понятные и четкие инструкции.
Стройте планы — штука не очень простая, но в ситуации the roof is on fire выступает мощным брандспойтом, которым этот fire можно потушить.
Остались вопросы? Давайте обсудим!)