За время работы в поддержке GlowByte я познала навыки технического менеджмента. Это касается как Agile-проектов, так и support. Были периоды, когда в моей работе преобладало больше менеджерских задач, чем технических: нужно было проводить онбординг проекта, решать критические ситуации заказчика, выстраивать процессы эффективной коммуникации, ходить на 8 встреч в день и т. д. И я была рада получить такой опыт. Поэтому хочу рассказать историю про повышение soft-скилов.


Клише из резюме

Давным давно мне казалось, что софт-скилы – это что-то незначительное, неважное. Это то, о чем ты в своем резюме пишешь шаблонными фразами: “общительный”, “амбициозный”, “ответственный” или “умение работать в команде”, “умение управлять своим временем”. Мне всегда казалось, что такими словами может описать себя каждый, что это простые школьные навыки, которые не стоят особого внимания.

Пройдя определенный путь профессионального развития, мои понятия о навыках значительно поменялись. Каждый вкладывает свою глубину в тот или иной софт-скил, и в каждом софт-скиле, насколько бы он ни был абстрактным, есть шкала прогрессивности. Это я четко понимаю сейчас и, анализируя прошлое, осознаю, что я бы могла сказать о себе того времени как об “амбициозной” и “ответственной”, но точно не “общительной”, да и характеристика “умение добиваться результата” тоже была не про меня. Но, повторюсь, в моих резюме из прошлого все это было и казалось органичным.


Коммуникация

В GlowByte я научилась писать структурированные письма, чтобы была явно отражена и моя позиция по вопросу, и требования к отвечающему. Я научилась “доставать” людей без стеснений и угрызений совести, если мне не ответили, ответили поверхностно или не достаточно хорошо. Отработала умение поддерживать деловой вежливый тон, но при этом выражать свою четкую позицию. “Умение добиваться результата” в письмах – done.

Я научилась вести встречи, говорить без пауз, давать собеседнику вставить слово на онлайн-встрече и возразить. Под “вести встречи” я имею ввиду не просто слушать, но и быть ведущим. В самом начале я приходила на встречи (внутренние и внешние) только слушателем, мое активное участие было минимальным. Когда мне давали слово, я морально готовилась к ответу “как не в себя”, проговаривала речь в голове. Сейчас все ответы проходят нативно, без долгих размышлений над тем, как выстроить коммуникацию.

Затем я стала ведущим: сначала рассказывала на внутренних встречах про статус своих задач, потом информировала заказчика о статусе задач нашей команды, а далее навык развился – я стала объяснять, показывать, высказывать идеи, слушать предложения и дискутировать с коллегами и заказчиками по рабочим вопросам. “Умение вести устную коммуникацию” – done.


Менеджмент задач

Я научилась вести пайплайн ServiceDesk-задач и пользоваться моднейшими Agile-технологиями. Специфика моей работы в GlowByte предполагает прием заявок 5-6 заказчиков и решение инцидентов. При этом, бывало, на двух проектах одновременно случались критические инциденты и обоим заказчикам нужна была помощь срочно.

Я научилась балансировать между заказчиками, не сливать SLA, приоритизировать свои активности и не упускать оставленных на потом дел. Помимо заявок с SLA в Jira, у меня были сторонние активности: разработка инструментов для автоматизации поддержки, аудиты на проектах заказчика, решение каких-то иных проектных задач, которые не ложились удобно в макет ServiceDesk. Сначала на эти активности не хватало времени, потому что весь рабочий день был занят заявками. Эту проблему мне предстояло решить тем, чтобы начать вести пайплайн работ по таким активностям с помощью Agile и спринтов.

Сейчас я планирую спринты в Notion, на что уходит определенное количество времени. Еще часть времени посвящаю распределению задач между всей командой, а также проверке эффективности выполнения этих задач и встречам для синхронизации действий. Этот подход успешно работает, помогает искать баланс между ServiceDesk-задачами и Agile и позволяет отслеживать успех нашей неосновной деятельности, которая полностью описывается сейчас в Agile-структуре.


Команда

Любая команда начинается с найма. Анализируя свое первое собеседование в GlowByte в качестве собеседующего, я понимаю, что сейчас сделала бы все по-другому: обратила бы внимание на другие качества сотрудника, подобрала команду совершенно иначе.

Итак, после найма следует длительный процесс обучения сотрудника, его онбординга в проекты и задачи. На этом этапе у меня родились первые идеи сделать мою персональную базу знаний (о ней я рассказала в предыдущей части) публичной. Далее нужно было придумать KPI для каждого сотрудника, начать проводить встречи one-to-one, следить за развитием и желанием человека работать. Каждая новая мысль и идея про человека в моей команде рождала разного рода рефлексию: что бы сделала я на его месте, достаточно ли я хороша как куратор, не чувствует ли сотрудник скуку в задачах, не надоело бы мне работать на его месте и т. д. Я читала много историй о других людях, управляющих командами, сравнивала с собой и делала выводы.


Делегирование

Обычно я делаю свою работу хорошо. Казалось бы, кто кроме тебя может сделать ее лучше? Но в какой-то момент задач стало так много, что их нужно было делегировать, но я боялась это делать, волнуясь о качестве. Первые месяцы в GlowByte я буквально отрывала задачи от сердца и перепроверяла много раз результат выполнения, дорабатывала их за других. Поразмыслив, научилась делегировать правильно: направлять, а не делать самостоятельно, детализировать достаточно хорошо, чтобы мои ожидания соответствовали ожиданиям коллеги, перестала играть в перфекциониста и начала смотреть на результат, а не на лучшие технические подходы, красивые решения и процесс разработки/ исправления бага в коде.

Также меня тяготило, что люди не хотят расти, не стремятся делать больше и лучше. Задалась вопросом: как мотивировать? Сработал подход делегирования большей ответственности: если человек отвечает за проект, он делает задачи на нем лучше, чем если бы он отвечал за одну обособленную задачу на проекте. Кстати, такой подход сработал и на мне. Пока я просто решала заявки в Jira, я не была настолько мотивирована предлагать новые идеи, вникать в чужие проблемы и делать что-то дополнительно: мне не хотелось выходить из зоны своей ответственности и зоны комфорта.


Операционная рутина и микроменеджмент

В команде, которую я курировала, было максимум 6 человек. Были времена, когда 20 часов из 40 в неделю уходило на звонки с ребятами: нужно было курировать всех, чтобы не было простоя, решать множество операционных задач и помогать в технических. Нередко мне казалось, что я что-то делаю не так, раз у меня все валится из рук. Но постепенно я научилась справляться с многозадачностью, читать информацию по диагонали и выхватывать из всего только важное, не забывать ничего из того, что пообещала сделать в потоке встреч и разговоров в чатах, – и теперь могу написать в своем резюме: “стрессоустойчивость и многозадачность”.

Что еще мне помогло? Встречи между собой для обмена опытом таких же кураторов, как и я. Конечно, всегда кажется, что “трава в чужом саду зеленее”, но на чужих проблемах тоже можно научиться справляться с задачами. Скажу откровенно: вначале меня бесило то, что приходилось заниматься микроменеджментом: читать каждую заявку на каждом из 6 проектов, контролировать работу всех участников команды и передавать по нескольку раз на доработку. Нужно было придумывать, как строить коммуникацию, быть своего рода надзирателем над всеми и вся. Я читала негатив в интернете о том, что микроменеджмент – это зло, и при этом сама была микроменеджером. Однако позже я поняла, что такие мои задачи были актуальны лишь потому, что команда была незрелой. Позже, когда удалось подтянуть ребят и технически, и по софт-скилам, количество микроменеджмента уменьшилось – пришло доверие к команде, и я начала делегировать микроменеджерские задачи другим ребятам.


Консалтинговые проекты

Как я уже говорила, проект сопровождения начинается с онбординга: нужно погрузить себя и команду в техническую часть, организовать процессы (как мы можем общаться с заказчиком, как будем решать инциденты, какие доступы к серверам нам нужны и т. д.). Этот процесс не такой очевидный, как кажется по описанию. Здесь есть много подводных камней, которые впоследствии могут привести к недовольству заказчика качеством оказываемого сервиса. Потому все нужно решать на этапе приемки проекта.

Я изобрела велосипед – придумала карту приемки проекта, которую, конечно, впоследствии обсудила и доработала с другими коллегами из GlowByte. Вместе мы сформировали целый процесс по приемке проектов на сопровождение и успешно используем его в работе.


Estimate

Как ни странно, но пришлось научиться оценивать во времени свои задачи и задачи своей команды. Сначала я подсчитывала, сколько времени займет решение инцидента, затем – сколько времени уйдет на решение инцидента у участника моей команды. Потом я стала делать оценки работ для заказчика, защищать эти оценки и объяснять, что именно мы собираемся делать по той или иной смете. Конечно, не обошлось без ошибок. Были случаи, когда оценки оказывались настолько низкими, что какие-то непредвиденные риски приводили к перерасходу ресурсов. Но навык анализировать трудозатраты пришел с опытом – я научилась составлять ресурсные планы по команде, прогнозировать трудозатраты на пару месяцев вперед.


И снова коммуникация

Никогда не думала, что я вообще могу выступать публично. Но все бывает в первый раз. Как-то одному из наших заказчиков потребовался воркшоп о наших интеграциях. На момент появления этой задачи я сама ничего не знала про систему, что в ней можно и нельзя. Но я знала, где все это можно найти. Потратила два рабочих дня на чтение документации, анализ системы и подготовку презентации, а затем – еще и много часов на разработку структуры рассказа. Мне кажется, это была самая длинная и трудозатратная подготовка ко встрече в моей жизни. Я хотела сделать все максимально хорошо и качественно. И у меня это получилось: я рассказывала 2,5 часа о системе 15 представителям крупного банка и смогла ответить на все уточняющие вопросы. После этого публичные выступления (done!) не так меня волновали и я не раз проводила митапы на 30+ человек для внутреннего обучения или помогала ребятам из своей команды подготовиться к публичным выступлениям.

Конечно, по всем перечисленным выше пунктам я не достигла совершенства. Порой я даже думаю, что ничего не умею и все у меня получается не так, как надо. Но я учусь и развиваюсь, посещаю конференции о менеджменте и управлению командой, смотрю их записи на YouTube, маленькими шагами внедряю новые подходы, улучшаю свои скилы.

В заключение скажу, что менеджмент для меня стал философией. Над вопросами эффективного менеджмента я могу спорить сама с собой и с другими людьми, пробовать различные подходы в проектах и команде, управлять тоном голоса, фразами, сутью в коммуникациях. Однако не считаю, что я была бы хороша как менеджер, если бы у меня были только софт-скилы. Глубокое понимание технического аспекта помогает комбинировать подходы управления в каждой конкретной ситуации или проблеме.


Теги: менеджментsoft-skillsmanagementteamworksupportделегированиекейс-менеджменткейсуправление проектамиуправление людьми