Меня зовут Андрей Глушко. Я менеджер ИТ проектов, занимаюсь менторством, прошёл путь от разработчика до руководителя, в своих подходах опираюсь в первую очередь на людей, а потом уже на практики.
Вообще изначально, я хотел написать другую статью, на тему «Как правильно сопровождать сотрудника во время выполнения задачи», но я понял, что перед этим важно написать о принципах, которые будут лежать в основе моих методов сопровождения.
Сопровождение, если говорить формально
Если говорить формально, то сопровождение сотрудника представляет собой процесс поддержки и руководства сотрудника по выполнению поставленной задачи. Оно может включать в себя инструкции, обучение, обратную связь, мониторинг, советы и другие методы, которые помогут сотруднику достичь нужного результата. Цель сопровождения сотрудника заключается в том, чтобы помочь сотруднику как овладеть навыками, умениями и знаниями, необходимыми для выполнения поставленных задач, так и для выполнения сотрудником его личных планов. С другой стороны, целями бизнеса в сопровождении являются укрепление коллектива, выстраивание мотивации сотрудника вместе с мотивацией фирмы, достижение ожидаемых результатов, обеспечение качества результатов. Получается, если работа приобретает образ тандема, то обе стороны от этого только выигрывают.
Моё понимание
Если уже говорить про моё понимание, то для меня, сопровождение сотрудника в процессе выполнения поставленной задачи означает проверку и предоставление поддержки в ходе выполнения поставленных задач. Я вижу это как неотъемлемую часть процесса управления проектами. Моя задача как руководителя ИТ проекта включает в себя отслеживание прогресса выполнения задач сотрудниками и предоставление необходимой им поддержки. Я уверен, что правильное сопровождение помогает сотрудникам работать более эффективно и успешно выполнять поставленные задачи.
Выстраивание основ взаимодействия
Несколько подходов, которые я сам использую, чтобы помочь сотруднику выполнить задачу.
В первую очередь, я считаю, что на проекте, человеку важно дать саму возможность обратиться за помощью, советом, а может быть даже просто побыть для него слушателем(вспоминаем эффект уточки). Однако, даже такой простой метод поддержки требует создания определенных условий. В основном это сводится к тому, чтобы внутри команды выстраивалась доверительная коммуникация. На своём опыте, будучи по обе стороны баррикад, мне, когда я был разработчиком, было порой сложно сказать о своих проблемах, потому что это могло повлечь за собой гораздо больше проблем — к примеру, если обратиться за помощью, то меня могли воспринять как непрофессионала или человека, который несамостоятельный. Помимо этого, фокус уже будет не на том, чтобы завершить задачу, получить опыт, укрепить взаимодействие со своими коллегами, а на том, как бы не показать себя глупым, а если и показать, то суметь защититься без увольнения с работы. Такой настрой внутри фирмы вряд ли даст хорошую мотивацию для сотрудника делиться своими проблемами.
Небольшое отступление: да, я понимаю, что нет смысла уделять очень много внимания вопросу сопровождения именно каждому специалисту, с кем я работаю или буду работать, но я расскажу об этом позже. Сейчас я хочу рассказать в целом про важность сопровождения сотрудника, а потом уже категоризировать различные ситуации, когда и сколько примерно нужно этого сопровождения.
Возвращаясь к теме. Дальше, я считаю, когда мы выстроили хорошую коммуникацию, я могу начать работать над качеством. Вот несколько примеров:
Если человек занимается разработкой, то идти ко мне не всегда будет хорошим вариантом, да я понимаю какие‑то вещи из разработки, но лучше всего в этой ситуации сможет помочь другое экспертное мнение из той же области, например мидл и мидл или мидл и сеньор и тд.
Может ли человек без обращения к кому‑либо, сначала решить самостоятельно свой вопрос? Да, и для этого существует такое понятие, как документация проекта или база знаний по проекту. Если это касается требований клиента или вопросов по технической части, то я стараюсь создать на проекте перечень документов, которые описывают хотя бы самые важные аспекты проекта, как с точки зрения бизнеса, так с точки зрения разработчиков. Это требует несколько десятков человекочасов, однако, как я решил для себя, оно явно того стоит. Единая база знаний вообще очень нужная вещь, которая улучшает понимание и осознанность людей в том, что они делают.
Ещё одним подходом для повышения качества сопровождения сотрудника будут 1on1 митинги. Я стараюсь проводить их не реже(и чаще тоже не стоит) чем раз в 2–3 недели. На них мы обсуждаем, как я мог бы улучшить условия для сотрудника, чтобы он мог меньше отвлекаться на факторы, которые будут его только отвлекать от задач. К примеру, если постоянно падает инфраструктура, нет чётких требования от заказчика, смена приоритизации задач и тд.
Ещё одним подходом, но он достаточно косвенный, я бы назвал совпадение рабочих принципов. Мне намного проще дать человеку то, что я сам понимаю зачем ему что‑то требуется.
Я не говорю о ситуациях, когда человек со временем начинает постоянно надеяться на то, что за него всё сделают, или, когда исполнитель, в случае провала задачи, начинает оправдываться, что ему неправильно подсказали(решения по выполнению задания всё равно принимает он, а не тот, кто ему помогал). Темы про перекладывание ответственности или про превращение кого-то из членов команды в помогайку требуют дополнительных статей.
Трудности в достижении
Теперь к практике. То что я описываю, на бумаге может звучать здорово, но ведь на практике все может быть совсем иначе.
Приведу в пример ситуацию из своего опыта. Заранее скажу, что с разработчиком Александр, о котором пойдёт дальше речь, были проработаны вышеописанные пункты — мы совпадали в большинстве рабочих принципов, он умел говорить о своих проблемах, умел просить о помощи. У нас также была документация по проекту.
Ситуация “Как быть если никто не может помочь?”
На одном из последних мест работы, мы строили пайплайн по работе с моделями машинного обучения, используя достаточно свежий фреймворк Ray, у которого ко всему прочему была несовместимость между его версиями(что в последствие и сыграло роль в решении задачи).
На тот момент, по какой‑то причине, команде не удавалось создавать подпроцессы(в библиотеке они называются workers или actors) для конкретных пайплайнов обработки данных. Разработчик Александр чётко следовал гайдам из документации, но у него не получалось.
Сначала это выражалось в том, что на череде daily standup единственным блокером в задаче была именно эта проблема. Мы начали с самых простых вариантов — задачи на более глубокое изучение библиотеки, задачи на изучение сторонних гайдов на конкретных кейсах(не те, которые «Create your own pipelines in 10 minutes», а которые глубже изучают вопрос). Затем, я начал подключать других разработчиков, но это также не давало результат.
Так, уже над всей командой висел большой блокер, который тормозил в целом проект, из‑за того, что задача настройки пайплайнов была одной из ключевых. На тот момент, мы уже потратили на задачу около 4 спринтов. Позднее, решение было всё‑таки найдено, и оно было донельзя банальным — несовместимость версий: на кластере оператор был одной версии, а actors создавались на основе библиотеки другой версии. После решения, мы двинулись дальше по проекту.
Было ли за это что‑нибудь разработку? Нет, мы просто учли этот опыт в будущем.
Предвидя вопросы «Почему мы не стали использовать другой фреймворк?» или «Почему мы сами не написали конкретно требуемый функционал?». Тогда мне казалось, что это может потребовать больших ресурсов, ведь решение вот‑вот будет найдено.
Хоть статья и не об этом, но что я мог бы сделать тогда иначе?
Поставить вопрос о найме консультанта, возможно двух, чтобы мы могли быстрее закрыть эту задачу и создать дополнительные документы в базе знаний на основе их консультаций.
Заранее предвидеть риск использования нового для нас фреймворка, как итог, указать больше времени на выполнение проекта.
Вместе с этим, решая такой «сложный» блокер, мы получили и ряд положительных моментов:
команда сплотилась, решая одну проблему;
мы смогли проверить навыки нашей коммуникации;
через этот кейс, разработчики смогли понять, что даже в такой крайней ситуации, они могут просить о помощи. И данная ситуация была для них подтверждением, что нашей главной целью было именно решение проблема, а не поиск виновных.
В общем, помимо одного большого минуса в виде задержки сроков, мы получили много плюсов. Если бы, к примеру, наш разработчик стал бы в закрытую пытаться решить проблему, решение могло бы затянуться на ещё более длительный срок.
Вывод по статье
Подводя итог, для меня в основе возможности хорошего сопровождения сотрудника является коммуникация. Что бы не происходило на проекте, если есть возможность и умение это обсудить, то решается большое количество проблем.
Если интересно больше узнать про мои подходы, у меня есть небольшой телеграм канал, где я выкладываюсь чаще, чем на хабре.
На этом у меня все. Буду рад обратной связи!
