Руководство группой разработчиков

Как управлять командой разработки

Привет! Я Иван Антипин, заместитель директора департамента разработки в AGIMA. За свою карьеру я поработал с десятками команд. Где-то был разработчиком, где-то тимлидом, где-то помогал извне. У меня был миллион возможностей разобраться, как люди ведут себя в коллективе. Но всё же не на все вопросы существуют четкие ответы: что такое команда, как она работает, как ей управлять. Об этом мы подробно рассказываем на нашем курсе для тимлидов и на митапах. А в этой статье я попробую описать те методы и подходы, которые лично мне кажутся полезными и правильными.

Что делает из группы команду

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

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

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

Такая интерпретация команды лежит в основе фреймворка Team Canvas. Он предполагает, что формализованное представление о команде — это совокупность атрибутов. Какие это атрибуты, можно понять из схемы:

Миссия и цель

Из картинки понятно, что сердце любой команды — это предназначение. Проще говоря, это миссия и цель. Большинство авторов различают эти понятия между собой. Сравните:

Разницу сложно описать, но довольно легко почувствовать. Миссия намного сложнее. Она есть только у зрелых команд. Это ответ на вопрос «Зачем мы здесь каждый день?». Зачастую миссия спускается в команду через корпоративную культуру и не всегда проговаривается вслух. Часто команда понимает ее интуитивно. Или не понимает вовсе. Выполнить миссию тяжело, если вообще возможно.

А вот цель принципиально достижима. Поэтому команда может работать без миссии, но не может работать без цели. Цель — то, что заставляет команду сплотиться и работать сообща. Ее обычно ставят по системе SMART. Она должна быть:

• ограничена во времени;

• достижима:

• измерима.

Хорошие примеры командной цели — выпустить MVP к концу лета или повысить Retantion продукта за 2 месяца.

Ценности

Важный атрибут команды — ценности. Люди должны быть согласны в принципиальных вопросах. От этого зависит, как они будут общаться и понимать друг друга. Ценности исходят из культуры и воспитания человека. Часто они связаны с возрастом членов команды. Могут быть личными (взаимоуважение, честность) или профессиональными (пишем только чистый код, используем только современный стек). Повлиять на них внутри рабочего процесса практически невозможно.

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

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

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

Правила и практики

Этот атрибут команды, как по мне, сейчас уже не так актуален. Он предполагает, что внутри команды должны быть устоявшиеся профессиональные традиции и обычаи, нормы. Но в современном мире рабочий фреймворк, будь то Agile или Kanban, определяет практики. А правила задаются корпоративными регламентами и установками.

Но иногда важно дополнять правила компании внутренними командными традициями. Клубы по интересам (у нас, например, есть TeamLead Club, Managers Club и архитектурные комитеты), вылазка на природу раз в год, дневная зарядка всем отделом — общие ритуалы объединяют. Иногда они появляются спонтанно, а иногда стоит внедрить что-то специально.

Роли и навыки

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

• в работе делает упор на сильные стороны человека;

• слабые стороны улучшает за счет индивидуальных планов развития.

Проще говоря, тимлид понимает Soft Skills и Hard Skills каждого члена команды и учитывает их при планировании работы.

Как развивается команда

Чтобы сделать из коллектива команду, важно понимать, как команда развивается. У каждой команды есть свой жизненный цикл. Понять его поможет вот такой график:

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

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

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

Из этого графика можно извлечь одно важное правило:

Производитель команды на этапе формирования всегда падает.

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

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

Формирование команды

Team Canvas и жизненный цикл команды — два важнейших инструмента в руках лидера. Их нужно применять одновременно и очень вдумчиво. Начинается всё с формирования коллектива. Уже на уровне найма мы можем предсказывать, как долго она будет бурлить или во что в итоге вырастет. Поэтому подходить к подбору нужно аккуратно.

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

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

Как управлять командой

Если правильно подобрали команду, то управлять ей будет комфортно и интересно. Но с чего начать этот процесс? Я считаю, что начать стоит с управления самим собой. Самодисциплина и точный план действий помогут держать команду и понимать, что с ней делать даже в самые тяжелые кризисы. Для этого важно готовить инфраструктуру:

• правила,

• регламенты,

• встречи,

• алгоритмы,

• чек-листы и т. д.

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

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

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

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

Стили лидерства

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

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

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

Личность тимлида

Решить, какой стиль и когда уместнее, можно только оценивая все обстоятельства сразу: настрой команды, этап формирования, ценности и личные цели каждого участника процесса. Поэтому все эти условия нужно улавливать, чувствовать и понимать.

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

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

Мне кажется, все люди делятся на два типа:

1. Одни объясняют свое решение словами «Я думаю, что…».

2. Другие — словами «Я чувствую, что…».

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

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

Кризис сплочает правильно сформированную команду, а не проверяет ее на прочность.

Если вы тимлид, ответьте себе на вопрос: «Что я скажу команде, если случится так, что нам будет поработать все выходные?». Или представьте, что должен сказать вам тимлид, чтобы вы вышли в выходной на работу. Требовать и угрожать, просить или умолять, а может быть, что-то еще? Удивительно – любой из вариантов может быть правильным.

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

Создание безопасной среды обсуждения и культура принятия командных решений — ответственность тимлида. 

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

Юрий Кербицков

Руководитель группы разработки компании ICL Системные технологии

По данным Хабра, средняя зарплата тимлидов по разработке составляет 200 тысяч рублей. Высокий уровень зарплаты предполагает соответствующий уровень квалификации и ответственности. Навыки управления людьми, кураторство проектов, к которым примыкает и антикризисный менеджмент, — вот минимальный список требований к позиции на сегодня. Поэтому прежде чем брать на себя такой функционал крайне важно и полезно будет изучить опыт других специалистов из этой области, ознакомиться со списком необходимых компетенций и ответить для себя на главный вопрос: «Какая она — эффективная команда разработчиков, и что я могу в неё привнести?».

Как тимлиду строить команду?

Определить размер

При построении команды с нуля нужно определить её оптимальный размер. От этого будут зависеть процессы управления в ней. Когда команда небольшая, можно дотянуться рукой до каждого, поработать над его мотивацией, уделить время, пообщаться. Человек может одновременно удерживать до 7 контактов: свыше этого рубежа такая схема уже неэффективна. По мере увеличения команды приходится перестраиваться. Вектор изменений будет зависеть как от внутренних, так и от внешних условий труда.

Определить состав

Следует определить состав команды, требуемый уровень специалистов. Чтобы делать любой проект, нужен определённый набор компетенций. В продуктовом подходе есть инструмент — Звёздная карта — который позволяет сформировать матрицу компетенций, требующихся для реализации проекта. Смотря на эту карту, можно закрывать компетенции и впоследствии сформировать кроссфункциональную команду.

Быть готовым к потерям

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

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

ВАЖНО во избежание неконгруэнтности подбирать людей, близких команде по ценностям и взглядам на жизнь. Если есть потребность в создании команды для краткосрочного проекта и нет нужды в процессах её выстраивания, можно опереться только на компетенции членов. Но если команда нужна на долгосрочную перспективу, она должна быть синхронизирована по ценностям. Человек, который не вписывается в общую систему ценностей, в любом случае уйдёт. Рано или поздно.

Сделать акцент на коммуникациях

Когда команда уже сформирована, важно уделить особое внимание внутренним коммуникациям. На этапе притирки возможны конфликты. И здесь важно не сводить их на нет, позволять им протекать естественным путём, контролируя и не допуская эскалаций. Так команда сможет эффективно пройти этап шторминга и выйти на перфоманс.

Какие навыки нужны тимлиду?

Soft skills

Руководитель группы разработки должен быть лидером и обладать соответствующими качествами: уметь не только управлять процессами, но и брать ответственность за их результат; гореть тем, что делает, заражая при этом других, наставлять сотрудников. Ко всему прочему руководитель должен обладать базовыми знаниями психологии. Без этого тяжело выстроить работу с людьми.

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

Hard skills

Хард скиллы важны, но не так принципиальны для тимлида. Как говорил Стив Джобс, «бессмысленно нанимать толковых людей и указывать им, что делать». Необходимо брать людей, чтобы они говорили, что делать. В идеале тимлид должен быть компетентным и обладать экспертными знаниями в процессах разработки. И понимать, как делается продукт. Вовсе необязательно знать все нюансы: это может быть верхнеуровневое понимание ситуации, но во всей её целостности, с учетом взаимосвязей и взаимовлияния отдельных элементов.

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

ВАЖНО разделять тимлидов и техлидов. К этим двум позициям предъявляются разные требования к уровню компетенций. Техлид, как эксперт, который ведёт за собой технологическую экспертизу и пишет код, должен обладает лидерскими качествами в хард скиллах. При этом он практически не занимается менеджментом, и, соответственно, не должен обладать этими навыками. Тимлид же занимается преимущественно управлением. Поэтому в карте компетенций основной упор делается именно на people-менеджменте.

С какими задачами сталкивается тимлид и как их решать?

Научить команду самостоятельности

Задача тимлида — сделать так, чтобы команда работала самостоятельно даже при его уходе/отсутствии. Эта функция руководителя группы напрямую зависит от того, как построены процессы работы внутри компании.

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

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

Сотрудничество со смежными командами

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

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

Определить внутренние правила игры

Так как я предпочитаю в первую очередь ориентироваться на потребности пользователей и клиентов, а уже потом на сроки и бюджеты, в управлении командой разработки я использую принципы и ценности Agile. Мне важно, чтобы продукт приносил реальную пользу, и при этом был использован оптимальный объём ресурсов.

У нас две команды разработчиков. Обе работают по Scrum. Одна пишет сервис на C#, другая на Java. Сперва мы разбили зоны функциональности. А впоследствии фиксировали контракты, договаривались, как они будут выглядеть, расходились, и далее совместно фиксировали результат. Если говорить о внутрикомандной работе, то у нас преобладают горизонтальные взаимодействия. Коллеги приходят ко мне как к эксперту за советом, рекомендацией, но не за готовым решением.

А каким вы видите идеального тимлида?

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

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

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

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

Итак, что за этапы:

• Задача в работе
• Декомпозиция
• Разработка
• Ревью кода
• Тестирование
• Релиз
• Мониторинг
• Ретроспектива

Задачу взяли в работу

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

Зачем это нужно. Проектирование нужно, чтобы оценить сложность задачи и рассчитать необходимые ресурсы.

Декомпозиция

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

Зачем нужно. Каждую мини-задачу можно разрабатывать отдельно и релизить отдельно.

Разработка

В чём суть. Обычно по понедельникам разработчики разбирают задачи на спринт или руководитель группы назначает разработчикам задачи.

Зачем это нужно. Код сам себя не напишет.

Code Review

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

Зачем это нужно. Это помогает избегать соблазна оставить всё как есть, ведь «и так работает». Да и выпущенному коду обычно не хочется возвращаться.

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

Как проходит ревью:

1. Вы пишете код;
2. Покрываете его unit-тестами;
3. Собираете все изменения по коммитам (git commit) и отправляете в ветку в общем репозитории (git push);
4. На основе сделанных изменений создаете MR (merge request);
5. Кто-то из коллег-разработчиков берет Ваш MR и проверяет его, оставляя комментарии по спорным и проблемным местам;
6. Вы исправляете все недочеты и обновляете MR;
7. Ревьюер (не обязательно тот же самый человек) снова отсматривает ваш код и принимает его.

Тестирование

В чём суть. Проверить, что всё работает как надо.

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

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

Релиз

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

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

В это время команда изучает логи ошибок приложения (Error logs), графики, проводит Smoke-тестирование и так далее — в общем всё то, что позволяет принять решение о качестве выпущенного релиза. На основании этого этапа принимается решение о закрытии релиза или о его откате.

👉 Smoke-тестирование — максимально быстрые автотесты, которые показывают, что основная функциональность работает.

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

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

Мониторинг и оценка ценности

В чём суть. Оценка проделанной работы. Обычно на этом этапе собираются необходимые метрики и данные для бизнеса.

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

Ретроспектива

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

Зачем это нужно. Ретроспективы помогают своевременно устранить мешающие процессы и закрепить эффективные.

На этом всё. Запомните _г_лавное — процессы отличаются, но основы везде примерно одинаковые. Если вы понимаете, из чего состоит разработка, а не просто пишете код, то сможете добиться в IT большего.

---

«Доктайп» — журнал о фронтенде. Читайте, слушайте и учитесь с нами.

ТелеграмПодкастБесплатные учебники

3 типа команд в Agile: универсалы, специалисты и гибридная команда

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

В идеальном мире Agile-подхода у команд существует 3 типа структуры — рассказываем про каждую отдельно.

Универсалы

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

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

Специалисты

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

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

Гибридная команда

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

Но, если ваша цель — надежный и многосоставной продукт, оно того стоит. Такой подход обеспечивает качественную разработку программного обеспечения для больших сложных проектов, это подтверждает наш опыт и даже научные исследованияhttps://www.researchgate.net/publication/249703186_Hybrid_Agile_Development_and_Software_Quality.

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

Как это работает в Purrweb

На самом деле, три четко разграниченных типа команд существуют только в книгах по Agile. В реальности команда разработчиков — это  сложный микроорганизм, со своими правилами и особенностями. Со временем мы четко разделили роли в IT-команде и наладили быструю и прозрачную коммуникацию внутри. Это позволяет нам работать с любыми проектами, вне зависимости от сложности, размера и бюджета. 

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

Какие бывают роли в IT-командах

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

Вот классический набор:

• владелец продукта
• проектный менеджер
• аккаунт-менеджер
• UI/UX дизайнеры
• разработчики
• QA инженеры 

Владелец продукта (product owner, PO)

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

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

Аккаунт-менеджер

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

Проектный менеджер (project manager, PM)

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

Если вы слышите, как кто-то кричит: «Нам нужно ускориться», «Давайте сначала просчитаем риски», «Что-то работает не так», — вероятно, проджект-менеджер где-то близко.

UI/UX дизайнеры 

Эта часть команды просыпается утром и сразу думает о пользователе. Она подключается к разработке программного обеспечения на ранних этапах и следит, чтобы все в приложении было простым и понятным. Им помогают UI/UX копирайтеры, которые следят за текстом в решении и знают, как уместить важное объявление в push-уведомление, чтобы его открыли и прочитали.

Разработчики

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

QA инженеры

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

Как это работает в Purrweb

На пути к идеальной структуре мы сделали несколько ошибок и многому научились. Этот опыт помог нам узнать больше об управлении процессами разработки и разграничивать роли в IT-команде.

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

В Purrweb мы доверяем роль владельца продукта нашим заказчикам, потому что они знают подробности идеи лучше нас. Это не означает, что мы нанимаем их на работу 😅 Когда к нам приходит клиент, у него есть идея, а у нас — экспертиза и опыт. Поэтому мы даем возможность заказчикам «владеть продуктом»: отвечать на наши вопросы и выбирать финальные концепты, при этом учитывая наши советы и предложения. 

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

У разработчиков Purrweb тоже есть свои правила: в их команде есть тимлид, который отвечает за управление процессом разработки и контролирует промежуточные результаты. Кроме того, мы предпочитаем сами обучать новичков работать с фулстеком 😈.

Как понять, что перед вами эффективная организация команды разработчиков?

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

При аутсорсинге разработки программного обеспечения следует обратить внимание на несколько вещей:

• Налажена ли у них коммуникация? Посмотрите, как члены команды общаются между собой. Да, программисты не роботы и столкновения на рабочем месте неизбежны, даже при разработке программного обеспечения. Но в здоровых, хорошо организованных командах есть инструменты, как договариваться и разрешать конфликты. Можно сразу спросить: «Ребята, а как вы коммуницируете между собой? Какие приложения используете, чтобы оставаться в курсе рабочего процесса?». Если вам расскажут про Slack, Jira и Targetprocess — направление уже верное.
• Как они распределяют рабочие роли? Главное правило хорошей Agile-команды — отсутствие хаоса. Процесс разработки программного обеспечения должен быть структурирован, а каждый участник — знать, что он должен делать и к кому обращаться за советами. Чтобы проверить, как это устроено, вы можете просто спросить команду, как выглядит их рабочий процесс, кто отвечает за каждый шаг и кому вы можете задать вопрос о промежуточных результатах.

• Есть ли у них общие цели? Большинству Agile-команд не нужны четкая иерархия и строгий контроль, потому что у них общие цели и они знают, ради чего работают каждый день. Например, в Purrweb наша цель — помочь стартапам быстро проверить свои бизнес-идеи, и если вы спросите кого-либо из нашей 100 членов команды, они скажут вам тоже самое.
• Могут ли они быть независимыми? При разработке программного обеспечения строгий надзор не приносит никакой пользы ни клиенту, ни команде. Чтобы следить за каждым движением, со стороны заказчика потребуется много времени, которого у стартаперов обычно нет. А для команд пристальный контроль может демотивировать и мешать креативности. В общем, хорошая команда должна уметь работать независимо, чтобы вам не приходилось тратить все силы на управление процессами разработки. 

Итоги

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

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

Хотите познакомиться с нашей командой и получить помощь в проверке идеи для вашего стартапа? Напишите нам!

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

Manao — это компания, ориентированная на разработку веб-решений в формате субподряда. Мы близки к средней прослойке IT-компаний: у нас нет заоблачных показателей, масштаб работы Manao вполне доступен многим — то есть наш опыт применим на практике для большинства подрядчиков.

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

Наша команда отличается моноспециализацией: 12 программистов и 3 верстальщика. Маркетинг и PR отдали на откуп внештатному специалисту. HR-функции выполняют сами руководители. Каких-то экзотических должностей нет, и мы не планируем вводить их в будущем. Большая часть команды — люди, которые давно работают с нами. Другая небольшая часть коллектива периодически обновляется. Притом «свежую кровь» мы генерируем с помощью обучения молодых специалистов.

---

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

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

• В рядах разработчиков действительно есть немало интровертов. Но только не тех, что стесняются общения даже со своими старыми коллегами. Отнюдь — у нас очень доброжелательные и открытые к диалогу и любой помощи люди. Интроверсия чаще всего проявляется в вопросах публичности: программисты редко бывают готовы становиться медийными личностями, чтобы обращаться к аудитории от лица своей компании. Соответственно, это накладывает определённые ограничения на PR-активности или маркетинг.

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

---

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

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

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

Я уделяю довольно много времени общению со своими сотрудниками, чтобы своевременно делать «замеры» их настроения и поддерживать морально. Во время последнего кризиса, когда мы вынуждены были покинуть офис, я лично заезжал к каждому из коллег, чтобы передать документы и обменяться новостями.

Не менее важно — при принятии многих управленческих решений мы учитываем мнение сотрудников:

В итоге 57% коллектива проголосовало за вариант «Остаюсь на удалёнке». И вот, спустя почти 2 месяца после проведения опроса, мы в действительности всё ещё продолжаем работать из дома, лишь изредка пытаясь устроить встречу в офисе, чтобы просто увидеться и обсудить новости.

---

Мы никогда не требуем справки с больничными листами, зная, что их можно сделать почти в любой платной клинике. Как и говорилось выше, у нас вообще нет проявлений «имитации» работы или её отсутствия. Все честны друг перед другом, никто ничего не скрывает. Хочешь взять выходной, не теряя доход? Без проблем — дадим возможность отработать упущенный день. Хочешь отдохнуть за свой счет? Легко. И не нужно ничего придумывать. Просто запусти соответствующий процесс в Битрикс24.

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

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

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

---

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

В остальном нас всегда спасали наши лучшие друзья — Skype и Zoom.

Вообще общаться с агентствами и интеграторами довольно просто — в основном мы легко понимаем друг друга, так как являемся коллегами и работаем на одном рынке.

---

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

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

---

Новые знания позволяют держать команду в тонусе и обеспечивают профессиональную актуализацию разработчиков. На этот счёт у нас есть общее правило:

Если участник команды обнаруживает что-то интересное, то сразу же делится этим с другими. «Жадность» в этом случае не одобряется.

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

---

Если посмотреть наш аккаунт в Instagram, то может показаться, что вся жизнь Manao состоит из праздников, корпоративов, поздравлений, подарков и образовательных активностей (исследования, статьи, книги). Но если бы это было так, то мы не смогли бы ежегодно отгружать нашим партнёрам десятки тысяч человекочасов. Мы не забываем о главной цели нашего нахождения в офисе — о реализации клиентских проектов.

Что помогает нам достигать этих целей:

 Поддержка достаточного уровня загруженности. Когда мы видим, что в производственном графике могут образоваться пробелы, то сразу же активизируем маркетинговые активности, возвращаемся к диалогу со старыми партнёрами. Весь рабочий день пить чай — история не про нас. Единственное, что можем себе позволить в свободное время — разрабатывать тиражные решения для Битрикс24.

 Контроль со стороны менеджеров. У нас их немного. Но они есть, и они не дают «просиживать штаны» разработчикам.

 Наличие QA-специалиста, который следит за качеством услуг.

 Фиксация времязатрат по задачам. Да, иногда можно скинуть в общий чат смешную картинку, сыграть вечером с коллегами в Counter Strike или World of Warcraft, взять отгул на целый день, пригласить всех на pizza-party в обед (кстати, у нас есть даже специальный график мем-дежурств, где указано, кто и когда делится забавными находками). Но нельзя провести рабочий день, закрыв задачи всего за 1–2 часа. Это сразу будет означать низкую вовлечённость специалиста и отсутствие результативности (а, значит, и низкий показатель возврата инвестиций с точки зрения вложения ресурсов компании в специалиста).

---

Мнение автора и редакции может не совпадать. Хотите написать колонку для Нетологии? Читайте наши условия публикации. Чтобы быть в курсе всех новостей и читать новые статьи, присоединяйтесь к Телеграм-каналу Нетологии.

Управление командой специалистов — непростая задача. О том, как превратить группу разработчиков в единую команду, проведя ее через все этапы развития, мы недавно рассказывали в подробной статье на «Хабре».

Сегодня поговорим о том, какие soft-скиллы должны быть у руководителя, как, где и почему их необходимо применять. Эта тема затрагивается не так часто, поэтому сегодня мы при помощи Андрея Рыжкина, ИТ-директора Agima, решили расставить все точки над i.

Менеджер или технический специалист?

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

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

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

Оптимальный вариант — назначить руководителем команды разработчиков человека с хорошей технической базой, опытом и заметными лидерскими/административными качествами.

С чем придется столкнуться руководителю? От компании к компании этот список может варьироваться, но вот список стандартных обязанностей руководителя команды разработчиков:

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

Примеры из практики? А пожалуйста

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

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

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

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

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

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

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

В целом, хороший руководитель должен:

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

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

Софт-скиллы руководителя команды разработчиков

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

И напоследок — несколько советов тем читателям, кто хочет стать хорошим руководителем команды разработчиков:

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

Каждый день мы сталкиваемся с программными продуктами, будь то приложения, программы, игры, сайты и прочее. За разработкой таких известных сервисов, как Instagram, Google, YouTube и других стоят люди, много людей. Разработчики собираются в команды, и для скооперированной и эффективной работы им нужен руководитель — тимлид. Именно о должности руководителя команды разработки в IT мы расскажем в нашем обзоре.

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

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

Определение должности тимлида

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

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

Должность тимлида является высшей в иерархии разработчиков. В большинстве случаев карьера разработчика выглядит так:

1. Стажер.
2. Junior (новичок).
3. Middle (средний уровень).
4. Senior (высокий уровень, сложные задачи, самостоятельная работа).
5. Team lead (руководитель команды, постановщик задач).

Тимлид — это англицизм, произошедший от словосочетания team lead (leader). Прямой его перевод: ведущий команды, лидер команды.

Теперь конкретнее о том, что делает тимлид. Если использовать метафору, то руководитель команды разработки выполняет роль ее “интерфейса”. Получая задания от заказчиков и менеджеров, он не просто доносит их до специалистов, но и распределяет, кто, чем, когда и как будет заниматься. Для полноценного контроля за процессом создания чего-либо, у тимлида есть права формировать команду разработчиков и использовать ее членов по своему усмотрению.

Грубо говоря, люди являются его инструментами, и в случае неудовлетворительного результата ответственность нести будет именно “мастер”, а не “инструменты”, которыми он работал.

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

Основные составляющие деятельности тимлида

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

Итак, у опытного и успешного руководителя команды разработки есть 4 профессиональных качества:

1. Лидерские качества.
   Чтобы эффективно управлять людьми, руководитель команды разработки должен быть хорошим лидером. Любой лидер разбирается в людях и использует именно тот подход воздействия, который подойдет для подконтрольного сотрудника. Опытные специалисты советуют проявлять искреннюю заинтересованность в проекте и его успехе, дабы “заражать” и заряжать других разработчиков. Немаловажно быть профессионалом с технической стороны, и не для того чтобы заниматься всеми элементами проекта собственноручно, а для того чтобы сотрудники тянулись и чувствовали лидерство (в какой-то мере даже профессиональное превосходство) тимлида во всем.
2. Определение компетентности разработчиков, формирование команды и совмещение специалистов между собой.
   Тимлид должен уметь подбирать необходимых специалистов как самостоятельно, так и с помощью HR-менеджера/IT-рекрутера. Речь идет не только о формировании команды разработки с нуля, но и о быстром и качественном закрытии одной или нескольких позиций.
   У каждого тимлида может быть разный подход, который зависит от опыта работы, предпочтений и ситуации. Мы говорим про наем уже готовых профессионалов и воспитание нужных кадров самостоятельно. Но и это еще не все. Многие руководители команды разработки допускают типовые ошибки. Например, думают, что нынешних сотрудников хватит для создания проекта, хотя на самом деле их недостаточно. То есть, важно уметь определять, нужен специалист или нет, нужно заменить кого-то, переобучить, нанять, уволить или сделать что-то еще.
3. Грамотное использование ресурсов.
   Помимо самих кадров, тимлид распоряжается еще одним важным ресурсом — временем. Он должен уметь оценивать имеющееся время на работу, и распределять по нему задачи. Обычно оценкой ресурсов занимаются сами разработчики, примерно определяя сроки выполнения той или иной работы. Также встречается подход, когда необходимое время определяют всей командой на совещаниях. Бывает и так, что мнение разработчиков расходится, либо не соответствует объективной оценке. В такой момент вмешивается тимлид, изучает ситуацию и дает свою оценку, которая является неоспариваемой и должна приниматься всеми. Руководитель команды разработки обычно легко справляется с грамотным распределением ресурсов, если под его началом компетентные специалисты, которые считают его лидером (второй и первый пункт).
4. Контроль настроения внутри команды.
   Итак, о том, что важно налаживать связь между разработчиками и тимлидом, мы уже сказали. Но не менее важно контролировать взаимодействие сотрудников между собой. Настроение команды разработчиков и отношение специалистов друг к другу играет большую роль. Обычно серьезный конфликт можно решить лишь избавившись от одного из его участников. Если оба профессионалы, то проект сильно пострадает от подобного. Поэтому надо стараться реагировать максимально быстро и попытаться решить конфликт. Именно решить его, а не замять или сделать так, чтобы сотрудники скрывали что-то от руководителя. Для того чтобы избегать возникновения конфликтных ситуаций, стоит правильно соотносить характеры членов команды между собой. Причем мы говорим не только о том, чтобы специалисты подходили друг к другу как личности, но и о разумном выборе состава разработчиков. Например, один зануда не влияет негативно на настроение команды, но два таких уже могут испортить рабочий процесс.

“Родные” обязанности руководителя команды разработки относятся исключительно к грамотному управлению специалистами. Все остальные действия считаются дополнительными, и чаще всего тимлид сам возлагает их на себя исходя из опыта, умений и интереса.

Team lead, tech lead и project/product manager — в чем разница?

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

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

Иногда должность руководителя команды разработки путают с профессиями project manager и product manager, но это совершенно разные деятельности. Тимлид берет на себя исключительно руководство над разработчиками, и может принимать участие в процессе создания программного продукта. Менеджер же (и проекта, и продукта) придумывает концепцию, продвижение, применение проекта или продукта, и почти не участвует в технических вопросах. Также он может работать не только в IT-индустрии.

Если крупная компания хочет создать продукт или проект (в сфере IT), то сначала за него принимается менеджер, который при необходимости может нанять тимлида. Он, в свою очередь, будет отвечать только за команду и то, чем она занимается.

Важные личные качества

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

Список личных качеств:

• ответственность;
• многозадачность;
• коммуникабельность;
• мотивированность и увлечение проектом;
• аналитический склад ума;
• настроенность на результат;
• умение правильно распределять время и задачи между другими людьми (делегирование полномочий);
• дипломатичность;
• принятие решений.

Плюсы и минусы должности

Несмотря на то, что эта должность престижная, в ней есть не только достоинства, но и недостатки. Советуем изучить их субъективно, спрашивая у себя: «А насколько этот плюс или этот минус важен конкретно для меня?»

Список плюсов:

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

Список минусов:

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

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

Работа руководителем команды разработки

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

Управление командой разработки проходит в офисных помещениях, где находится бóльшая часть сотрудников. Некоторые могут работать удаленно или быть специалистами, которых наняли на один проект, но костяк обычно в офисе.

Тем не менее сам тимлид далеко не всегда сидит в кабинете в рабочее время. Встречи с заказчиками и специалистами, поездки для заключения договоров и прочие действия входят в список его дел.

Один из главных инструментов тимлида — использование методологий по созданию продукта или проекта. Это относится к любому руководителю команды разработки. Самые популярные методологии: Agile, Scrum и Kanban. У каждого из вариантов есть свои манифесты и принципы разработки, которые помогают направить команду специалистов в нужное русло и не сбиваться с пути. Например, не забывать, что продукт создается в первую очередь для людей и их взаимодействия с инструментами и процессами.

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

• брокерские и финансовые компании;
• банки;
• студии по разработке программного обеспечения;
• студии и компании, связанные с работой в индустрии информационных технологий;
• крупные бизнес-корпорации;
• различные сервисы и компании, деятельность которых включает работу с IT, но не строится вокруг них;
• игровые студии.

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

Заработная плата

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

Чтобы определить, сколько зарабатывает тимлид, мы обратились к сайтам с вакансиями. Исследовав суммы, которые предлагают работодатели, можно выявить средний показатель. Для проведения аналитики команда сайта Professii-Online использовала 2 портала: HeadHunter и Trud Россия.

Начнем с Trud, потому что на сайте есть блок со статистикой заработных плат. По нему видно, что средняя оплата труда по должности составляет 76 000 рублей.

Ссылка на страницу со статистикой: https://russia.trud.com/salary/692/52965.html

Примите во внимание, что статистические данные собраны на основе всего лишь 38 вакансий. Это крайне маленькая выборка, поэтому перейдем к следующему порталу.

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

Ссылка на страницу с вакансиями: https://hh.ru/search/vacancy?clusters=true&ored_clusters=true&enable_snippets=true&salary=&st=searchVacancy&text=руководитель+команды+разработки

Примеры вакансий:

Получилось, что средняя заработная плата руководителя команды разработки на HeadHunter составляет около 160 тысяч рублей. Это высокая оплата труда, что справедливо, учитывая управляющую должность и огромную зону ответственности.

Сколько зарабатывает team lead в США?

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

Для анализа использовались данные с двух сайтов:

• По данным портала Indeed: 48 260$ в год. Ссылка на страницу: https://www.indeed.com/career/team-leader/salaries;

• По данным портала glassdoor: 48 262$ в год. Ссылка на страницу: https://www.glassdoor.com/Salaries/team-lead-salary-SRCH_KO0,9.htm.

Округлим сумму до 50 000$ в год, и разделим на 12, чтобы получить заработную плату за месяц. Выходит 4 166$ в месяц. В переводе на рубли это около 305 000 рублей. При сравнении со средней зарплатой в 160 000 рублей разница большая, но не такая огромная (в процентном соотношении), как в других направлениях из сферы информационных технологий.

Уровень востребованности

К сожалению, надежных сервисов по оценки уровня востребованности должности нет, но мы любим показатели в цифрах, а не просто оценочные суждения по типу “высокая/средняя/низкая востребованность”. Использовать будем уже привычные сайты HeadHunter и Trud.

На HeadHunter больше всего вакансий по запросу “руководитель команды разработки”, другие названия по типу “team lead”, “teamlead” и “тимлид” выдают меньше результатов. Итак, на HeadHunter есть 22 509 объявлений от работодателей (на момент написания статьи).

Ссылка на страницу: https://hh.ru/search/vacancy?clusters=true&ored_clusters=true&enable_snippets=true&salary=&st=searchVacancy&text=руководитель+команды+разработки

Это высокий показатель, но:

• на HeadHunter многие вакансии дублируются спустя несколько страниц;
• в результаты запроса попали вакансии, совершенно не относящиеся к должности руководителя команды разработки, например, project-manager, старший программист, руководитель службы безопасности и прочие объявления от работодателей;
• количество вакансий меняется ежедневно

Учитывая все вышеописанное, на деле вакансий по должности тимлида значительно меньше. Но даже если уменьшить количество объявлений по должности до 10 000, это все равно показатель высокой востребованности.

На сайте Trud вакансий еще больше, чем на HeadHunter — 26 389.

У этого портала тоже есть свои особенности, которые надо учитывать. Во-первых, Trud является агрегатором, который собирает объявления от работодателей с других сайтов. Значит, те же вакансии от HeadHunter попали в результаты запроса на Trud. Во-вторых, в число найденных вакансий входят удаленные, архивированные и закрытые. Скорее всего, актуальных объявлений от работодателей именно по должности руководителя команды разработки на Trud чуть больше, нежели на HeadHunter.

Общий итог: востребованность специалистов высокая. Учитывая, что компаний и учреждений, связанных с созданием, поддержанием или работой с программным обеспечением очень много, такой результат логичен.

Поиск работы

Вакансии по должности руководителя команды разработки можно найти на порталах, посвященных поиску работы (причем как общего назначения, так и именно в сфере IT):

• HeadHunter;
• Habr Карьера;
• GeekJob;
• Trud Россия;
• Rabota.ru;
• TrudVsem;
• Avito Работа;
• Карьерист.ру;
• Зарплата.ру;
• IT Jobs Worldwide (международный портал на английском).

Далеко не всегда тимлид устраивается на работу стандартным способом через подбор вакансии и прохождение собеседования. Бывает и так, что руководителем команды разработки становятся после получения повышения с должности senior или другой руководящей (старший программист, координатор, руководитель отдела тестирования или что-то похожее).

Как стать тимлидом

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

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

Ранее мы уже говорили, что для того чтобы стать тимлидом нужно быть senior-разработчиком. Это не правило, но чаще всего руководителями становятся именно таким способом.

Если же вы хотите стать тимлидом не имея опыта работы в сфере информационных технологий, то сначала нужно пройти этапы разработчика разного уровня, начиная от junior. Конкретный вид деятельности (веб, разработка ПО, тестирование и т.д.) не имеет значения, главное, чтобы вы принимали участие в разработке и работали в IT.

Обучение на руководителя команды разработки

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

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

Высшее образование

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

На сайте Postupi.Online есть соответствующая страница со списком подходящих ВУЗов: https://postupi.online/professiya/rukovoditel-razrabotki-programmnogo-obespecheniya/

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

Онлайн-курсы

Единственный полноценный вариант обучения — это онлайн-курсы, потому что они составлены конкретно для должности тимлида. Естественно, берут туда людей с соответствующим уровнем подготовки. Например, тех, кто уже работает тимлидом и хочет повысить свой уровень, либо же middle и senior разработчиков, которые в будущем хотят стать тимлидами.

Удобство онлайн-курсов в том, что они дают возможность обучаться удаленно и в любое удобное для ученика время: он либо присутствует на вебинаре в режиме онлайн, либо смотрит запись. Даже если это второй случай, то студент все равно принимает полноценное участие в процессе обучения. Он общается с другими учениками, может переписываться с преподавателями и менторами, получает не только знания и навыки о должности, но и помощь при устройстве на работу.

Качественные курсы тимлидов и их краткое описание:

1. Программа обучения “Профессия TeamLead” от Skillbox.

Онлайн-курс длительностью полгода с подробным разбором практических кейсов и выступлениями известных — в сфере IT — спикеров. Обучающая программа состоит из 28 тематических модулей и 82 онлайн-занятий.

Ссылка на образовательный курс и подробная информация: https://skillbox.ru/course/teamlead/

2. Обучающая программа “Управление командами” от Skillbox.

Небольшой образовательный курс, который длится 3.5 месяца. Он предназначен не только для руководителей команды разработки, но и для всех, кто хочет научиться управлять командами. На курсе нет занятий, посвященных техническим умениям тимлида, рассматривается именно управленческая часть работы.

Ссылка на программу обучения и детальные сведения: https://skillbox.ru/course/team-management/

3. Онлайн-курс “Управление командами digital-специалистов” от Skillbox.

Еще одна общая образовательная программа для управленцев. Она посвящена управлению командами в сфере digital. Обучение занимает 1 месяц.

Ссылка на обучающую программу и дополнительная информация: https://skillbox.ru/course/digital-teams-management/

4. Обучающая программа “Как стать результативным руководителем” от Нетологии.

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

Ссылка на программу обучения и детальные сведения: https://netology.ru/programs/top-manager

Самообучение

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

Самообразование — это скорее дополнительный метод освоения деятельности. Он может эффективно работать в случае, когда вы уже middle или senior, но для того чтобы стать руководителем команды разработки вам не хватает знаний управленца. Изучая материалы, будь то видео, книги или статьи, вы сможете получить необходимую информацию.

Имейте в виду, что поиск качественных материалов для обучения дело нелегкое, ведь сложно определить качество информации, не разбираясь в теме (в той же управленческой). Чтобы хотя бы немного помочь дорогим читателям, команда сайта Professii-Online отобрала несколько материалов для самостоятельного обучения.

Книги:

• Эффективный руководитель (П. Ф. Друкер);
• Принципы (Рэй Далио);
• Харизма Лидера (Радислав Гандапас);
• Ген директора (Владимир Моженков);
• Быть начальником — это нормально (Брюс Тулган);
• Руководство по DevOps (Ким, Дебуа, Уиллис, Хамбл).

Статьи:

• “Как стать тимлидом” на Habr;
• “Как стать тимлидом” от Александра Поломодова;
• “Из джуниора в тимлида” с дорожной картой должности от сайта KT.Team.

Видео:

• Лекция “Как стать тимлидом” с ведущим Андреем Рыжкином;
• Вебинар от Skillbox “Как стать тимлидом”;
• Конференция “Настоящий тимлид: необходимый набор знаний”;
• Конференция “Рецепты классного тимлида” от руководителя команды разработки Badoo (дейтинг сервис);
• Урок “Первые шаги тимлида” от Skillbox;
• Урок по методологиям “Agile и Scrum”;
• “Как управлять проектами при помощи Agile” от Skillbox.

Полезные ссылки по теме

Ссылки на интересные и полезные материалы для тех, кто интересуется должностью руководителя команды разработки:

• Статья “Как я стал тимлидом, или 8 вещей о которых мне забыли сказать”;
• Статья “Теперь я тимлид, но почему мне так плохо? Практические советы”;
• Статья “7 советов начинающему тимлиду”;
• Статья “7 заблуждений начинающего тимлида”;
• Платные плейлисты Podlodka Crew для тимлидов (например, о том, как найти работу или расти в глазах руководства).

Каналы и чаты в Telegram для тимлидов

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

Список каналов и чатов:

• Канал Тимлид Очевидность — канал руководителя команды разработки с мыслями и мнением;
• Канал Про руководство разработчиками — заметки о работе тимлида;
• Чат Боль Тимлида от конференции Teamlead conf;
• Чат Teamlead Bootcamp для обсуждения дорожной карты руководителя команды разработки;
• Чат TeamLead SPB meetup с петербургскими руководителями.

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

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

А заинтересовала ли вас деятельность руководителя команды разработки? Расскажите в комментариях!

Видео по теме

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

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

Как успешно управлять процессом разработки и не настроить против себя всю команду?

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

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

Уважайте их профессионализм

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

Понимайте их мотивацию

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

Не бойтесь задавать вопросы

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

Давайте им то, что им нужно…

Прежде всего полный список требований и точную обратную связь. Список требований необходим для создания высококачественного программного обеспечения, поэтому составьте как можно более полный перечень желаемых функциональных возможностей и потребительских свойств. Задавайте вопрос «почему?», чтобы выявить истинные проблемы и потребности, которые должны быть удовлетворены в результате выполнения проекта. Без этой информации разработчикам придется действовать наугад, и их конечный продукт может оказаться совсем не тем, что хотел получить заказчик. 

К тому же разработчиком очень помогает качественная обратная связь. Поэтому вместо того, чтобы сказать: «Это нужно ускорить», скажите: «Заказчику нужно, чтобы программа загружалась за 1 секунду или еще быстрее». Пользуйтесь цифрами везде, где только можно, чтобы сделать требования максимально конкретными.

…и защищайте от ненужного

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

Не вздумайте недооценивать свои возможности

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

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

Используйте удобный софт для управления проектами

Пока разработчики занимаются созданием программных продуктов, вылавливают баги и внедряют рекомендации, работая в JIRA, вы, как менеджер проекта, следите за распределением ресурсов и ходом выполнения проекта  в Wrike. Двусторонняя синхронизация Wrike и JIRA позволяет менеджерам и руководителям следить за ходом работ, расставлять приоритеты и отправлять разработчикам отзывы с помощью Wrike, в то время как разработчики могут отвечать на их запросы, не выходя из JIRA. Воспользуйтесь бесплатной пробной версией Wrike Enterprise, чтобы испытать эти возможности вместе со своей командой разработчиков. Интеграция инструментов упростит управление персоналом проекта.

Источники: Gigster.com, TechCrunch.com, CIO.com, Foredecker