Интервью с Элиной Ишмуратовой, директором дивизиона «Троя» в digital-интеграторе Notamedia.
Цель проектной команды в ИТ-компании в сфере заказной разработки — решить задачу пришедшего клиента максимально эффективным и полезным для его бизнеса способом. Это логично и понятно: появился клиент, у него есть потребность — мы ее слышим, обсуждаем и предлагаем варианты реализации. Очевидно, что от того, кто именно будет работать в команде, зависит результат работы в целом, но вот как именно он зависит и как это работает — не все понимают. Чтобы это выяснить, мы поговорили с директором дивизиона «Троя» компании Notamedia Элиной Ишмуратовой — о том, как находить нужных людей и подбирать команду для работы над ИТ-проектами.
Элина, давай сразу обозначим — мы говорим про продуктовую команду или проектную?
У нас, если мы говорим про моё направление, не продуктовая разработка — наша команда делает один проект, потом переключается на другой проект. То есть мы не зафиксированы на каком-то определенном продукте. Есть направления, которые мы реализовывали уже несколько раз (например, разработка систем управления инцидентами), но ценность наших команд именно в том, что мы можем взять практически любой проект и любое направление.
Мы сейчас говорим про команду крепких универсалов. Она успешно реализовала один проект, завтра уже активно вовлечена в разработку совершенно другого функционала, послезавтра отдохнула и готова к дальнейшим подвигам.
Для меня в ИТ-проектах одним из ключевых сотрудников является тимлид. Это по-сути, моя правая рука. Во-первых, это техническая компетенция. Я могу управлять проектом, могу провести аналитику, даже потестировать, но в части разработки – я на 100% полагаюсь на тимлида и его решения.
Во-вторых, это ответственность за всю разработку: он берет на себя техническое управление командой, оставляя руководителю его основные и ключевые задачи.
Как могло бы быть без тимлида?
Могло бы быть подобие вавилонской башни. У нас все разработчики обладают экспертностью и высокой компетенцией. Но в любом случае финальное решение по технической реализации всегда стоит за тимлидом, который будет нести за него ответственность. Кроме того, на старте проекта, особенно в условиях, когда параллельно делается все, чтобы успеть к срокам, необходимо принимать грамотное архитектурное решение и закладывать фундамент проекта.
А без тимлида это делать сложно.
Да, тимлид, он как прораб на стройке. То есть мы бы, условно, начинали с крыши строить, а потом делали стены. А нужно, чтобы пришел тимлид и сказал: так, сначала мы закладываем фундамент, потом первый этаж, второй и так далее. Работаем с такими инструментами, а процесс будет у нас такой.
При этом важно сразу понимать, что тимлид управляет проектом внутри команды, но не проектом в целом — это задача как раз руководителя проекта или иногда руководителя дивизиона (если он сам ведёт особо важный проект). В идеале тимлид присутствует на встречах с клиентом, но судьбу проекта должен решать именно руководитель.
На что ты обращала внимание, кроме технических навыков?
Для меня крайне важно, какой это человек сам по себе. Потому что тимлид, который руководит всей разработкой – это правая рука директора дивизиона. Для меня важно, чтобы мы двигались в одном направлении и у нас была одна картина мира.
Общее правило при выборе техлида работает так: сначала смотрим, проходит ли человек порог по техническим требованиям, знает ли он нужный стек и как у него вообще с квалификацией. Понятно, что если он прошёл минималку, то всё, что выше, будет плюсом, поэтому на этом этапе неважно, насколько он хорош — достаточно, чтобы он прошёл фильтр (который может быть и очень сложным, тут базовый фильтр ≠ простой фильтр).
А вот когда соискатель прошёл первый этап, нужно смотреть, насколько вам лично будет комфортно с ним работать, потому что именно с ним вы будете общаться основное время работы по проекту. Если общение идёт со скрипом — не берите, ищите другого специалиста.
Итак, ты наняла техлида. Что дальше?
Далее необходимо формировать оптимальную команду. Но тут тоже важно соблюдать динамику найма, потому что чем больше и чаще ты берёшь людей, тем больше ресурсов ты тратишь на погружение их в проект.
К примеру, когда мы все заняты работой над проектом, и к нам каждую неделю приходит новый человек, то каждую неделю нужно потратить определённое количество часов, чтобы рассказать ему, что это за проект, погрузить его в специфику и так далее. Этим обычно занимается тимлид, но иногда мы росли настолько быстро, что мне тоже требовалось в этом участвовать.
Ты участвуешь в поиске и найме новых разработчиков?
Нет, этим занимается тимлид — это его будущие ребята, ему за них отвечать, поэтому логично, что за дальнейший найм разработчиков отвечает он.
Вообще, это странно, когда руководитель ищет людей в команду, которыми он не будет управлять напрямую или постоянно работать с ними. Другое дело — аналитики или менеджеры проектов. С ними мне нужно быть в постоянном контакте, поэтому их нанимаю я лично или принимаю активное участие в общении с кандидатами.
Были ли у тебя в плане найма какие-то промахи, когда ты наняла человека, а потом поняла, что зря это сделала и вообще поспешила?
Да, был случай с аналитиком. Я уделила мало внимания собеседованию, у меня тогда не было времени, и больше сосредоточилась на оценке тестового задания. Мне оно показалось хорошим, но человек оказался совсем не тем, кого мы ожидали. С тех пор я не беру на работу человека, не пообщавшись с ним лично достаточно времени, чтобы понять, сработаемся мы или нет.
Тут можно вспомнить простое, но жёсткое и эффективное правило: нанимай медленно, увольняй быстро. Если вы поняли, что ошиблись с выбором, что человек не приносит компании то, ради чего его нанимали, то самый лучший способ — расстаться с сотрудником, дать ему шанс эффективнее реализовать себя в другом месте, а в команду взять того, кто действительно подходит.
Давай поговорим про руководителей. На что ты обращаешь внимание при выборе человека на менеджерскую должность?
Если мы говорим про руководителя проекта, для меня крайне важна организованность человека.
Это легко понять даже по тому, как он выстраивает предложения, как рассказывает про свои кейсы. Если излагает системно: не скачет с темы на тему, отвечает последовательно на вопросы, рассказывает про инструменты и движется от начала к результату — то я понимаю, что человек организован.
А вот если он начинает «ну, я вот там что-то поделал, потом там, команда подхватила, и я убежал в другое место делать всё там» — для меня это сигнал, что он точно не подходит как руководитель проекта.
Ну и опять же, как и с тимлидом — обязательно смотрим на то, комфортно нам будет работать вместе вдолгую или нет. Если нет — нам все равно придется расстаться в конце концов, но до этого может пострадать и команда, и клиентский проект.
Приведи пример любого задания, которое ты даешь менеджеру и смотришь, как он на это отреагирует или справится.
Будущих руководителей проектов я обычно прошу формировать устный или письменный план проекта, корректно разделить этапы с учетом того, что у нас есть бэкенд, фронтенд, дизайн и другие роли.
Или даю простой кейс, банальный. Например, завтра у вас релиз для заказчика, а сегодня вечером там нашли 16 багов, что делать? И когда кандидат отвечает: «Надо позвонить заказчику и отменить релиз», — всё, для меня это сигнал провала.
В работе менеджмента первое — это приоритизация и анализ рисков. Может оказаться, что критичный баг у тебя один, его надо поправить, а 15 – ерунда и не влияет на релиз. На самом деле эти задания звучат сейчас очень просто, но, на удивление, около половины кандидатов не могут дать на них правильные ответы.
Давай зайдем с другой стороны. Было у тебя такое, что ты берешь проект и понимаешь, что в команде не хватает человека, чтобы закрыть новую компетенцию для проекта?
Конечно.
Здесь нужно понять, во-первых, срок, на который будет нужна эта компетенция, во-вторых, принесет ли она в дальнейшем ценность в других проектах или в портфеле действующих проектов. Например, если это аналитик по большим данным, который мне нужен только в одном проекте на месяц, нанимать его не имеет смысла. Если у нас в компании есть такая компетенция в других проектных командах, я попробую договориться и «арендовать» сотрудника.
Второй вариант — взять сотрудника на аутсорсе, чтобы закрыть компетенцию на время проекта. У нас это встречается редко, но такая возможность тоже есть.
Есть ещё третий вариант — привлечь сотрудника клиента, если компетенция есть в команде заказчика, но это требует отдельных договоренностей. Бывает, что у клиента, например, нет внутренней команды разработки, но есть аналитики. Пару раз у нас были такие кейсы, сработали хорошо, и клиент тоже остался доволен: отмечали, что сотрудник как будто прошёл курсы повышения квалификации :-)
Что нужно учитывать при найме? Что стоить фильтровать или на что нужно сразу обращать внимание, когда человек откликается на вакансию?
Смотрите на мотивацию. На самом деле видов мотиваций много, больше 10. Кому-то нужно, чтобы его хвалили. Кому-то нужен статус, другим — деньги, а остальное неважно.
Часто мотивация проявляется в процессе общения. Например, когда спрашиваешь, почему вы покинули предыдущее место работы, а в ответ слышишь, что человек, грубо говоря, десять раз за год попросил повышение зарплаты, и на одиннадцатый ему отказали. Понятно, что у него финансовая мотивация.
А это плохо — чисто денежная мотивация?
Безусловно, финансовая сторона – это очень важно, тут мы никого не обижаем, но постановка этого вопроса во главу угла – не про мою команду. У нас в команде собраны люди, у которых горят глаза, ребята ориентированы на крутой результат, и он их мотивирует. Я никогда при общении не лгу, что у нас суперлайтовая история — наоборот, сразу говорю, что проекты очень сложные, нагруженные, но и очень крутые.
В частности, мы, в том числе, делаем проекты для Правительства России, там огромный уровень ответственности. Во-вторых, делаем технически сложные проекты, разносторонние, выкладываемся на 100% — за счет этого у каждого очень быстро растет компетенция.
Когда я говорю об этом на собеседовании, а у кандидата загораются глаза и он говорит: «Блин, круто, да, хочу что-то новое узнать, хочу там уже работать», – то все отлично.
Получается, команда действительно работает как команда — это многое определяет?
Недавно я общалась с одним сотрудником, и он сказал, что за весь свой опыт работы не встречал такого потрясающего коллектива, где все друг другу помогают и никто ни с кем не ругается. Такая обратная связь для меня очень много значит. И это во многом определяет наши высокие результаты работы.
При этом у нас полная открытость: если у кого-то возникают идеи, он тут же их высказывает, и мы их коллективно обсуждаем. Меняем процессы, если ребята говорят, что так будет лучше. И никто не боится высказываться и ошибаться: разбираем ошибку и делаем выводы.
Напоследок, короткий совет: как же всё-таки правильно подбирать команду на проект?
Совет, на самом деле будет простой, но от этого не менее рабочий — просто представьте, что вам нужно будет с этой командой оказаться в каких-то крайне сложных обстоятельствах. Пройти огонь и воду, быть с командой не только, когда всё хорошо, но и когда всё плохо. И второе – подбирайте близких себе по духу людей, тогда вместе вы справитесь с любым проектом.
