В 24 года я боялся делегировать задачи, а сейчас руковожу проектами в IT-компании со штатом более 750 человек

Мультисервисная платформа WEEEK для управления проектами пообщалась с ведущим менеджером проектов и руководителем программы ГК Юзтех, Василием Моисеевым, и выяснила, зачем менеджеру нужно просить большую зарплату, почему нельзя пропускать рабочие встречи с командой и отчего работа в выходные – это зло.

В моей работе самое приятное, когда ты хорошо сделал работу, проект идет в проектных ограничениях, а команда работает в нормальном режиме без овертаймов. Если все складывается именно так, значит ты все делаешь правильно. Один из самых интересных моментов, на мой взгляд, когда приходится решать нестандартные задачи в рамках команды или проекта, улучшать бизнес показатели. А вот самое скучное и рутинное для меня – это планирование, подготовка отчетов и работа с договорами, но без этого никуда. Правда, после того, как ты сделал хороший план и защитил его, приходит удовлетворение от проделанной работы.

Вырасти в моей работе мне позволило понимание того, что надо всегда выбирать сложный путь и просить большую зарплату. Сложный путь = сложные задачи, они дают возможность быстро набраться опыта. Большая зарплата — работодатель подсознательно всегда старается оправдать зарплату работника, и если она высокая (а может и завышенная), то будет стараться вам поручать наиболее ответственные и объемные проекты, а это опять ваш форсированный рост. Так что выбивать большую зарплату полезно не только из-за меркантильных желаний, но и в виде стимулирования своего развития.

Я видел много одаренных ребят, которые не занимались вопросом увеличения своей зарплаты. Кто-то стеснялся, кого-то она устраивала. А одновременно с этим были рядом менее одаренные, но более пробивные и им в итоге поручали сложные задачи и именно они набирались опыта и становились руководителями одаренных. Чем больше вам платят, тем больше с вас и спрос. Мне кажется все, что я перечислил выше, универсальные подходы и относится к любой профессии человека.

За время работы руководителем проектов пришлось научиться очень многому: оценке и планированию, выстраиванию процессов, работе с рисками, работе с людьми и ожиданиями и т.д. А также еще одному важнейшему навыку руководителя – это умению говорить “нет”, как заказчику, так и коллегам внутри команды. При этом, конечно, “нет” должно быть по делу и аргументировано. Возможно, такое умение вам покажется незначительным, но его отсутствие всегда приводит к анархии на проекте, и он переходит в тип, описанный в книге "Путь камикадзе". Любое предприятие, где руководитель не умеет говорить “нет”, на мой взгляд, обречено на банкротство.

Руководитель без навыка делегирования, конечно, не руководитель совсем. У кого-то этот навык есть с пеленок — я таким людям искренне завидую. У меня, к сожалению, было не так.

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

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

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

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

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

• Если планируете fix-price проект, то не ленитесь и планируйте его сразу в MS Project. Только этот продукт позволяет всесторонне оценить сроки, стоимость, какие ресурсы на какой стадии вводить и множество других аспектов. О полноценном аналоге этого продукта я не слышал.
• Онлайн калькуляторы дат. Такие сервисы позволяют оперативно высчитывать рабочие дни относительно производственного календаря, что часто экономит много времени (сколько осталось рабочих дней до определенной даты, сколько рабочих дней между двумя конкретными датами и т.п.).
• Облачные сервисы заметок. Совершенно точно найдётся информация, которую вы не сможете хранить на Wiki проекта, в этом случае эти сервисы придут вам на помощь и обеспечат её доступность даже вне офиса.
• Фиксация статусов. На статусах с командой или заказчиком постоянно возникают задачи, которые нужно выполнить или проконтролировать. Весь статус не имеет смысла протоколировать, а вот записать кто, что вам обещал и к какому числу — необходимо. Из-за обилия постоянно поступающей информации, если её не записывать, в голове достаточно легко возникает мешанина. Для каждого типа статуса можно вести свою табличку, где в первом столбце фиксируется дата статуса, во втором — вопросы, которые вы хотите поднять на совещании, а в третьем до чего договорились. В нём же фиксируются и задачи.

• Удалённый доступ к рабочему компьютеру. Руководитель проекта — один из критически важных членов проектной команды, если он заболеет или уволится, это может привнести много проблем на проекте. От второго сложно защититься, а от первого надо защищаться в первую очередь самому менеджеру. Если он заболеет, он должен быть уверен, что сможет хотя бы в ограниченном объеме обеспечить управление проектом удаленно из дома и для этого лучше озаботиться заранее и настроить удаленный доступ к рабочему компьютеру.

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

Расскажу, какие есть у нас и почему они должны быть и у вас тоже, если вы разрабатываете программного обеспечение:

• Репозиторий кода (при любой длительности проекта) — тут все элементарно, если вы утратите разработанные материалы (спецификации, код, инструкции, дизайн и т.д.), то проект придется начинать сначала. Также отсутствие репозитория неимоверно усложнит работу команде разработчиков. Следовательно, он должен быть на всех проектах, а его отсутствие — это неоправданный риск.

• Багтрекинговая система — или как она по-русски называется «Система отслеживания ошибок». Это своего рода кровеносная система проекта, она позволяет ставить задачи, отслеживать их выполнение и ход проекта в целом, собирать различную статистику, управлять приоритетами и множество других вещей.

• Wiki — хранение всей часто используемой информации по проекту (инструкции, список команды, отпуска членов команды, адреса стендов, реквизиты тестовых учёток и много чего ещё). Все хранится в одном месте, структурировано и не требует много времени на поиск.

• Continuous Integration (CI) — практика разработки программного обеспечения, которая заключается в слиянии рабочих копий в общую основную ветвь разработки несколько раз в день и выполнении частых автоматизированных сборок проекта для скорейшего выявления потенциальных дефектов и решения интеграционных проблем. Некоторые команды не спешат внедрять CI, ссылаясь на отсутствие времени, но, на самом деле, они съедают в разы больше времени, не используя этот инструмент.
• Статус митинги — в разных компаниях их часто называют по-разному, но суть от этого не меняется. Такие митинги проводят с определенной периодичностью, желательно каждый день в первой половине дня и в определенное время. На них каждый член команды коротко рассказывает, чем занимался, что планирует делать и есть ли у него какие-то проблемы. Эти митинги можно проводить как очно, так и удаленно посредством современных сервисов групповых звонков. Основная суть — оперативно получать информацию о ходе проекта и также оперативно вносить коррективы. А еще — это повышение уровня информированности членов команды о ходе проекта (повышает их мотивацию). Эти митинги не должны занимать много времени, максимум 15 минут. На митингах не обсуждаются детали и проблемы, а только фиксируется их наличие, чтобы вы после могли собраться только с теми людьми, кто необходим и не тратили время остальных. Если команда большая, то дробите митинги: менеджер проводит статусы с руководителями направлений, а они — со своими людьми.
  

Часто я наблюдаю, как руководители проектов:

• Проводят статусы долго. Это очень выматывает даже тех, кто не участвует в обсуждении. Их производительность в этот день падает, не говоря уже о том, что пока они на статусе, они не делают свою работу.
• Часто отменяют\переносят\опаздывают с началом. Это все убивает смысл этих собраний. Такие ситуации должны быть исключением.

В нашей компании мы используем много зарубежного программного обеспечения для организации работ. После 24 февраля возникло много рисков, что этот софт могут заблокировать или не продлить лицензию на его использование. Во избежание таких проблем мы, как минимум, задублировали каналы коммуникации в общественных мессенджерах — для некоторых проектов мы создали дублирующие чаты в мессенджере Telegram. Также начали периодически сохранять всю почтовую переписку на жестких дисках рабочих компьютеров.

Полноценный переход на какой-то отечественный софт не производили, но, видимо, в ближайшее время придется.

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

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

А по поводу отпуска, если вы хотите хорошо отдохнуть, то к нему надо тщательно готовиться:

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

В отпуске, конечно, надо отдыхать, но бывают разные ситуации, и бывает необходимо выходить на связь. Я читаю почту и мессенджеры, но всем очень советую этого не делать — вернетесь из отпуска совершенно не отдохнувшим.

Выгорание в наше время — это большая проблема для специалистов интеллектуального труда. Но это всегда результат того, что есть какая-то проблема. Чтобы этого не было, надо предотвратить её появление.

Проблемы могут быть разные. Вот несколько, которые приходят мне в голову:

• Есть проблема на проекте\работе, которая как заноза сидит и зудит под кожей, высасывая из вас все энергетические соки — надо эту проблему определить и сфокусироваться на ее решении, привлекая всех, кого можете — руководство, заказчика, проектную команду и т.п.
• Вы перегружены задачами — составить список всех задач, которые вы решаете. Если вы руководитель, то переложите часть этих задач на других людей, тем самым разгрузив себя. Если вы не руководитель, то с этим списком выходите на своего руководителя и решайте, как можно часть ваших задач перераспределить на других людей.
• Вы недовольны текущей ситуацией — определите, что не устраивает и чего вы хотите, составьте план и начните его реализовывать.

У выгорания всегда есть причины, надо их только определить.

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

• Накопить энергию. Хороший приток новой чистой внутренней энергии можно получить благодаря новым впечатлениям. К примеру, на выходных выбраться в соседний город, в котором вы никогда не были и погулять по нему.
• Просто пойти погулять по лесу, подышать свежим воздухом, это очень успокаивает.
• Найти новое увлечение, концентрируясь на котором вы будете на время забывать про проблемы.
• Понять, что текущие проблемы рано или поздно пройдут и забудутся — ничего вечного не бывает. Проблема, которая сейчас из вас высасывает соки, через год будет просто смешным воспоминанием.
• Заняться спортом — любой спорт для тела как антидепрессант, плюс, вы еще и улучшаете свое здоровье.
• Высыпаться.