О чем статья

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

Приноси пользу и не упускай ее из виду

Это точно совет для всех. Очевидная, кажется, вещь. Но иногда мы об этом забываем. 

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

Можно специально напоминать себе время от времени: так вот же зачем мы делаем этот проект, вот в чем польза, пусть у нас всё получится!

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

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

Так же и с нашими проектами — если помнить, что и зачем мы делаем, вероятность того, что у нас действительно получится то, что нужно, намного увеличивается. Давайте строить храмы, а не таскать камни :)

Повышай прозрачность

Твоя прозрачность — это когда со стороны видно, что ты делаешь. Повышая её, ты автоматически увеличиваешь уровень доверия со стороны тех, с кем работаешь.

Прозрачность для команды

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

Прозрачность для клиента

Клиент тут — это хоть внешний, хоть внутренний заказчик. 

Потрать чуть больше времени, когда пишешь письмо клиенту, добавь полезных деталей. Если нужно, напиши дополнительное письмо. Когда клиент знает, что происходит на проекте, он спокоен. Доверие к тебе и команде растёт.

Прозрачность для босса

В нашей культуре не принято хвалиться. Считается хорошим тоном скромно промолчать, когда ты сделал что-то хорошее. Но в работе такая установка может мешать. Начальник рад, когда все под контролем. Ему важно в любой момент времени понимать, что происходит на проекте и с твоей командой. Регулярно встречайся с начальником, общайся с ним в мессенджере, поддерживай коммуникацию любым удобным вам способом.

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

Контролируй

Здесь я собрал скучноватые, но важные вещи, которые обязательно должны быть. Если вы знаете, что такое управление проектами в сфере веб-разработки, можете смело переходить к следующему совету.

На старте проекта 

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

В процессе работ

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

Ближе к финишу

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

Делись ответственностью, а не раздавай задачи

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

Пусть оценивает тот, кто будет делать

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

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

Принимать решения вместе

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

Защищай команду от ненужного стресса

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

Стресс может появиться от чего угодно: личные конфликты в команде, непосредственный доступ к разработчикам извне (клиент написал программисту напрямую, тот начал переживать и т.д.). Твоим коллегам будет сложно сосредоточиться, если голова занята мыслями вроде: «Блин, мне нужно успеть вот это и вот то, а еще сейчас клиент попросил вот это сюда добавить». Желания и просьбы клиента должны волновать в первую очередь тебя. Разработчик же должен максимально эффективно решать технические задачи.

Что делать с внешними источниками стресса

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

Внутренние конфликты

Защитой от внутренних стрессов служат регулярные встречи с командой. Их можно проводить в формате бесед «один на один» или просто вместе обедать. 

Не все стрессовые ситуации получится легко разрешить. Советуйся со старшими товарищами, если они есть в вашей компании!

Полезный стресс

Иногда стресс может быть полезным, и защищаться от него не нужно. Например, когда на проекте возникли серьёзные проблемы. 

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

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

Выводы

Желание принести пользу, повышение прозрачности, разделение ответственности с командой и защита от ненужных стрессов помогут тебе стать отличным тимлидом или руководителем проектов!

Успехов.

Источник иллюстраций: https://shakespeareillustration.org/