Привет, Хабр!

Из заголовка вы уже поняли, о чём сегодня пойдёт речь. Поэтому сразу к делу. 

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

Как в такой ситуации не сломать уже построенную систему? И одновременно принести дополнительную ценность для компании и подчинённых? Разбираемся под катом.

Зачем нужен руководитель?

IT-специалисты очень ценят экспертизу и не признают немотивированного управления. Это особенно хорошо заметно в opensource-проектах, где царит меритократия ― власть компетентных. Попытка управлять в лоб такой командой компетентных IT-шников у руководителя с отсутствующим фундаментальным бэкграундом в конкретной области обречена на провал. Где-то у новоиспечённого босса не хватит знаний, где-то авторитета, где-то банальной уверенности в правильности своего видения.

Казалось бы, тупик, но нет. Вместо босса, работу которого саботируют, или лидера, притвориться которым не хватает знаний, можно стать для подчинённых бизнес-заказчиком и управлять уже не работой команды, а качествами производимого ею продукта или услуги.

Поэтому первый вопрос, который должен задать себе руководитель, звучит так: «Каков конечный результат работы моей команды?» И лучше всего спросить себя об этом ещё до начала исполнения своих обязанностей.

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

Например, конечный результат работы команды data-аналитики может выглядеть так: к 10:00 каждого четверга, когда во всей компании планируются спринты на следующую неделю, у каждого подразделения есть полные, актуальные и достоверные данные для принятия решений. 

Что нужно, чтобы обеспечить этот результат?

Целеполагание и планирование

Как только вы сформулировали необходимый результат работы команды, его нужно развернуть в понятный и реалистичный план достижения. Для этого нужно задать себе вопрос «Что нужно, чтобы обеспечить этот результат?» Чётко ответив на вопрос, вы получите список задач, которые необходимо решить для достижения результата.

Например, для обеспечения еженедельного сбора полных и актуальных данных нужно, чтобы:

• работали все системы, из которых тянутся данные;

• работали все интеграции с этими системами;

• данные в этих системах появлялись вовремя и без ошибок;

• были доступны и корректно работали все инструменты для сбора и анализа данных;

• всем сотрудникам хватало компетенций в их сферах.

Каждую из этих задач следует причесать по методологии SMART, т. е. убедиться, что каждая из задач действительно важна, достижима, измерима, чётко описана и жёстко ограничена по времени. Если вы уже знакомы с этой методологией, то как бы вы переформулировали список задач из примера?

После того как задачи правильно сформулированы, наступает момент, когда нужно думать об управлении временем, а ещё о том, какая абстракция для вас удобнее ― принимать результат решения каждой задачи только целиком или «разрезать» задачи на отрезки фиксированной длины и двигаться к решению задачи чёткими, но мелкими шагами? От ответа на этот вопрос зависит методология контроля и управления проектом, которую вы выберете.

Контроль и анализ

Вполне очевидно, что нужно следить за тем, как продвигается работа. На прошлом шаге мы получили список задач. Мониторинг их выполнения даст нам ответы на  многие вопросы, например «Нужно ли что-то менять, а если нужно ― что и как именно?»

Вопрос важный, потому что при ответе на него начинают вырисовываться приоритеты для руководителя.

1. Первый ― глобальный, стратегический. Что делать с командой, процессом работы и внутренними проектами, чтобы обеспечивать результат.

2. Второй ― тактический. За что браться именно сейчас, чтобы это в наибольшей степени повлияло на получение результата.

3. Третий ― личный. Какие навыки в первую очередь «качать» руководителю, чтобы суметь реализовать оба плана.

Например, вы выясняете, что некоторые данные каждые 2-3 недели перестают нормально тянуться. В них появляются ошибки, из-за которых результат не достигается.

Почему они перестают нормально тянуться? → Потому что меняется API одной из систем, которые используются при сборе данных. Тянем данные как обычно, а ошибку обнаруживаем не сразу. Приходится в спешке пересобирать данные. Не всегда хватает времени.

Почему API меняются? → Потому что поддержка и развитие этой системы находятся в зоне ответственности второй команды, а эта команда меняет их по непонятной вам логике и не предупреждает вас заранее.

Почему мы не знаем заранее об изменениях? → Потому что есть третья команда, которая ставит второй команде asap-задачи. Вторая команда в спешке вносит изменения и либо забывает нас предупредить, либо предупреждает слишком поздно.

Для оптимизации контроля распределения и исполнения задач лучше всего применять одну из существующих Agile-методологий, такую как Kanban или Scrum.

Agile — это набор руководящих принципов, разработанный в 2001 году и опубликованный как Agile-манифест. Согласно Agile, следует, например, разбивать большие проекты на более мелкие, более управляемые части. Scrum и Kanban представляют собой два инструмента Agile. Оба они позволяют «съесть огромного слона, разделив его на части», но деление в них происходит по-разному.

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

В случае же применения методологии scrum (переводится как «схватка») продукт разрабатывается в ходе нескольких циклов с фиксированной продолжительностью, которые называются спринтами и разбивают сложные задачи на небольшие составные «кирпичики». Спринт — это короткий временной интервал, в течение которого scrum-команда выполняет заданный объём работы. Результатом спринта практически всегда является часть рабочего инкремента продукта (тот самый кирпичик). Когда в команде идёт интенсивная работа, необходимо чётко видеть финишную черту, после которой возможен переход к следующей задаче. Использование спринтов помогает получить достаточно чёткое представление о необходимом времени для достижения поставленной цели. Цикличность ― главная черта методологии скрам.

Пользуетесь ли вы методологией Kanban, Scrum или какой-то другой в своих проектах?

Обратная связь

Итак, вы наладили контроль исполнения задач и, конечно же, тут обнаружили какую-то проблему на пути к достижению поставленной цели.

Что можно сделать, чтобы решить проблему, найденную на предыдущем шаге? Вариантов масса.

• Договориться о том, чтобы систему отдали на поддержку вашей же команде, а не второй. Нужно пообщаться с руководителем второй команды и дать ему обратную связь: «Друг, твоя работа сейчас не даёт мне обеспечить результат. Смотри, вот такой вариант могу предложить…»

• Договориться о доступе к доске задач второй команды, чтобы вы могли вовремя ловить те самые asap-задачи и своевременно менять работу своих специалистов. Здесь обратная связь пойдёт уже сразу двум руководителям ― второй и третьей команд.

• Найти причину, по которой эти задачи ставятся второй команде с дедлайном «вчера», и попробовать её устранить. Может быть, третьей команде просто не хватает людей, а у вас как раз есть некоторый избыток сотрудников с малой нагрузкой.

Именно функция обратной связи запускает решение любой проблемы.

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

Мотивация

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

Допустим, третья команда ставит asap-задачи, потому что не справляется с нагрузкой из-за нехватки людей. Дальше из-за этого ломается весь процесс. Окей, вы договорились выделить 20% времени вашего python-разработчика, чтобы он им помогал.

Чтобы помощь была эффективной, руководителю нужно объяснить этому python-разработчику как минимум две вещи.

Первая ― зачем он вдруг получает ещё одного заказчика и начинает работать на него? Какие проблемы это решит? Почему принято именно такое решение, а не другое?

Вторая ― что получит лично этот разработчик? Кстати, необязательно речь о деньгах.

Функция мотивации ― не просто давать больше денег за каждую задачу (хотя и это тоже: люди работают, чтобы зарабатывать деньги). Эта функция заключается в том, чтобы знать мотиваторы каждого сотрудника и давать ему то, в чём он нуждается.

Может быть, разработчику уже скучно работать с одним и тем же стеком, а в другой команде как раз используют новый для него фреймворк. Может быть, он чувствует себя недооценённым, а тут именно он решит застарелую проблему сразу трёх команд.

Мотивация позволяет управлять сотрудниками. Не просто «давать задачи и требовать исполнения», а вдохновлять и получать крутые результаты.

Руководитель ― это скучно? Вовсе нет!

Целеполагание, планирование, обратная связь… А где творчество, где интерес от работы?

Помним, что описанное выше ― базовый подход к работе руководителя. Творчество и интерес, как и в любой другой сфере, появляются вместе с мастерством.

Возвращаясь к примеру выше. Можно копнуть ещё глубже и разобраться ― что за изменения такие внедряются, что перестаёт нормально работать API? Можно выяснить, что часть данных (например, транзакции через мобильное приложение) обрабатывают через самописную CRM, которая на треть состоит из legacy. Это даёт новые ветки возможностей. Например, можно перейти на другую CRM или разобраться в legacy и перестать городить надстройки вокруг него.

Но при этом следует помнить, что мастерство менеджера заключается не в том, чтобы самостоятельно обучить сотрудника или собственноручно переписать legacy. Мастерство менеджера состоит в том, чтобы найти причину проблемы, выбрать оптимальный путь её решения и назначить ответственного за эту задачу. 

Договорённость с другой командой может дать нужный результат за неделю, в отличие от рискованной работы с legacy. Обучение силами эксперта из другой команды может быть качественнее, чем ваше, к тому же оно может помочь укрепить неформальные связи между командами и упростить решение некоторых вопросов в будущем.

Поделитесь своими историями в комментариях о том, как вы впервые начинали руководить командой. Какие методологии и подходы вы применяли и добились ли вы успеха?