Организация команд в IT — проблема. Недостаточно найти адекватных специалистов с релевантным опытом, хотя и с этим есть большие трудности, важно еще, чтобы они сработались и дали результат, который ожидает от них заказчик.
Мы в «Автомакон» 13 лет помогаем предприятиям России и стран СНГ автоматизировать производственные процессы, создаем технологичные проекты на базе ИИ, мобильные приложения, сайты. За последние годы особенно хорошо продвинулись в том, как улучшать внутренние процессы взаимодействия. У нас есть некоторый опыт, который может быть полезен начинающим предпринимателям, профессионалам с небольшим опытом работы в командах и всем, кто делает первые шаги в IT.
Меня зовут Александр Нуждин, я ведущий аналитик, методолог и функциональный архитектор в компании «Автомакон», принимал участие в проектах для одного из крупнейших ритейлеров России — ВкусВилл. В статье поделюсь личным опытом и наблюдениями, как найти команду из людей, которые будут «гореть» проектом и при этом не выгорать.
О чём будем говорить:
«Один в поле не воин».
Принципы работы в команде.
Ответственность и распределение ролей.
Что делать, когда все плохо.
Как жить не только работой.
Как мы подбираем идеальную команду и как применяем наши принципы и ценности
В команде мечты каждый честен, работает на результат, уважает другого и ценит компанию. Кажется, это что-то на «единорожьем».
Кратко, в переводе на «человеческий», это звучит так:
Мы не подбираем команды из кого попало.
Если собирать команды как винегрет по принципу «Кто свободен, того к нам», то, ожидаемо, это приведёт к тому, что через месяц половины команды уже не будет. И здесь причина не в том, что на проект приложения для сети супермаркетов подбирают команду из фронтендера, копирайтера и маркетолога, а в том, что у людей должны быть одинаковые ценности и взгляды на процессы.
На сложных проектах мы подбираем команду на долгосрок, и уделяем больше времени подбору.
Большая часть проектов у нас длится месяцами, а иногда годами. Например, когда для ВкусВилл мы делали приложение для доставки, на него ушел год, и, в итоге, одна из команд стала внутренним подразделением де факто. В стабильных командах со зрелыми участниками удается закрывать задачи в срок и поддерживать необходимый «микроклимат» все это время.
Во время сбора команды мы доносим правила «игры» до всех заранее. И, естественно, вслух и при всех, а не письмом с пометкой «Важно».
Ведь какие-то вещи, которые абсолютно понятны нам, могут оказаться совершенно неочевидными для сотрудников. Особенно для новичков. Например, мы обязательно говорим о правиле «Не успеваешь — скажи», и постоянно о нем напоминаем. Ведь зная о проблеме, её можно начать решать раньше.
Здесь появляется принцип — ответственность за результат.
Если где-то ошибся, то придется потратить много времени на переделывание. Если признаться сразу, то косяк можно устранить быстро.
Но кому-то не позволяет гордость, неуверенность в своей экспертизе, других тревожит, что их могут выгнать из команды. Мы все подвержены страху признаться в ошибках, но умалчивание приводит к большим проблемах, которые затрагивают всех участников и вредят заказчику.
Однажды в период закрытия периода разработчик сказал, что нашел ошибку, которая привела к неверному результату, но заказчик об этом еще не знает. Мы в экстренном порядке провели доработки, которые исправили ситуацию. Заказчику была озвучена ситуация, с уже проработанным планом действий.
У нас в команде не принято перекладывать вину на коллег, даже за самые горькие ошибки мы не ругаем, поэтому неожиданных сюрпризов на полпути у нас почти не бывает. Специалист, который нацелен на рост и развитие, как раз и учится на ошибках — за плечами профессионала их тысячи. Ошибки — часть работы, ничего идеального не бывает, взаимоуважение и честность дороже.
Главное, не повторять ошибки и не давать ложных обещаний.
Например, если мы замечаем, что коллега неоднократно подводил по срокам, мы с ним расстаемся. На ранних стадиях эту проблему выявить практически невозможно, ведь все стараются работать хорошо и показывают себя только с лучшей стороны.
Только наблюдая за работой и результатами, можно понять соответствует ли человек заявленным условиям. Мы твердо убеждены, все выиграют, если каждый будет честен с самим собой и другими.
С честности мы сразу и начинаем.
Работает это так: при подборе мы всегда честно рассказываем о проекте и трудностях, которые придется решать. Сразу и без туманных описаний: вот здесь проект на стадии завершения, ему уже год и закончится он примерно через полгода, а здесь — новый проект, но примерно месяц большой загрузки не будет.
Всегда предупреждаем, что бывают авралы. Но и также говорим, что стараемся соблюдать баланс в это время:
Даем решать ключевые задачи, чтобы не расходовать силы специалистов на мелкие и далеко не всегда обязательные задачи.
Разговариваем с заказчиками, объясняя, что люди не роботы. Если не договариваем заказчику о чем-то или умалчиваем о возможных проблемах, а затем резко ставим его перед фактом, то есть большая вероятность, что с нами расстанутся и разнесут нелестную молву.
Не демонизируем клиентов перед командами, а стараемся найти решение совместными усилиями. Если команда в курсе всех основных этапов реализации проекта, гораздо легче решить какие-либо спорные ситуации и избежать катастрофы.
Вопросы возможного выгорания мы решаем следующим образом: усиливаем команду (приглашаем дополнительных сотрудников), делегируем, перераспределяем обязанности между участниками.
А после 22-го декабря у нас вообще «блок» — это значит, что ничего в прод не помещаем. На своем опыте мы поняли, что даже если надо, то перед НГ только фиксим баги. А если багов нет — закрываем техдолг. Другими словами, делаем всё, что не влияет на функционал. Это помогает нам не выгорать.
При этом релизы и успешное завершение проектов мы отмечаем. Это не считая корпоративов, «утренних подъемов» по пятницам (викторина), онлайн-баров, клубов по интересам, совместных походов на Эльбрус, поездок (были в Мексике и Италии).
Как говорили классики, отдых — это смена деятельности. Вот мы ее и меняем, чтобы не выгореть на работе, как-то поговорить друг с другом в неформальной обстановке, узнать кто чем живет.
Кстати, про отдых.
Отпуск. Как и все, мы заполняем календарь отпусков. Задача нашего руководства — верно прогнозировать загруженность специалистов, быть готовым к отсутствию части специалистов в период отпусков и праздников. Мы закладываем время на отпуски в планирование бэклога и спринтов.
Бывают нестандартные ситуации, когда специалисту требуется отлучиться по семейным обстоятельствам или здоровью. Для нас нормально идти навстречу коллегам, в этом случае как раз помогает грамотное распределение ролей — лидер команды всегда понимает, кем можно заменить специалиста на время его отсутствия.
Здесь работает еще один принцип — гибкость и адаптация.
Бывает так, что в долгих проектах результат через год совсем не совпадает с тем, что ожидалось на этапе идеи. Обычно это происходит потому, что у заказчика появляется новый функционал, например, надо добавить накопительные баллы в приложение, а это переделка и бэка, в том числе.
Эти абстрактные понятия стараемся выловить на этапе собеседования — стараемся дать совсем нестандартную задачу. Нам не нужно решение, а важно понять, как человек начинает мыслить, как он ищет пути выхода из ситуации. Чем меньше прямолинейных попыток найти решение, тем лучше.
Пометка: автору поставить пример такой задачи (и/или ответ интересный)
В компании приветствуется инициативность, отзывчивость и открытость.
Нормально что-то не знать и обратиться за помощью к более опытным коллегам. Если кто-то из команды находит более оптимальное решение задачи, его обязательно выслушают и воспользуются рекомендациями. Важно давать людям возможность влиять на качество продукта и проявлять себя. Например, когда я что-то не знаю, и этого нет в документации, то я всегда обращусь к коллегам, кто компетентен в вопросе. Также всегда помогу тем, кто обращается за помощью.
Из этого же вытекает следующее правило, которым я руководствуюсь — работаю как для себя, выполняю задачи как для своего личного проекта, чтобы было не стыдно поместить его в портфолио и поделиться результатами с другими.
На все эти принципы, принятые в компании, мы и опираемся в подборе. При этом в подборе команды разработчиков у нас принимают участие не только HR, но и будущий руководитель и/или лидер команды. Принимают участие именно непосредственное — не отдают ТЗ и ждут когда рекрутер «принесет» кандидата, а помогает с описанием вакансии, отсматривает резюме, проводит собеседования. Так кандидату сразу понятно, с кем он будет работать, а нам — сработаемся или нет.
Как распределять роли в команде?
Для начала — почему бы не спросить у самого человека? Ведь твоя текущая роль — это не навсегда. Почему бы не поменять?
Например, мы даем каждому участнику команды возможность выбрать комфортную для себя роль, например, когда аналитик хочет стать тестировщиком. Тогда при смене ролей проводим собеседование на новую роль.
Людям интересно проявлять свои способности и работать над тем, что увлекает с головой. Например, у нас есть ребята, что совсем не любят писать документацию, при этом все задачи выполняют очень качественно. Мы по максимуму освободили их от писанины.
Иногда люди меняют команду, например, в прошлом сентябре аналитик из одной команды ушла в другую). О такой ротации публично «объявляется» раз в квартал.
Если же в компании, по какой-то причине, такой свободы выбора нет, то тимлид должен самостоятельно проанализировать то, что у специалиста получается лучше всего, и дать ему соответствующие задания. Люди остаются в итоге с теми, кто предлагает лучшие условия для раскрытия потенциала и реализации амбиций. По нашему опыту, IT-специалисты отдают предпочтению горизонтальному типу карьеры, повышают экспертность. Будет отлично, если получится давать задачи на вырост.
Что, если задач мало?
Если задач на вырост мало, то от скуки люди разбегаются. Все как в организме: если нет движения — мышцы атрофируются (органы тоже, кстати). Мы разбавляем рутину увлекательными задачами и проектами. Даже в период турбулентности, когда пришлось временно «заморозить» часть проектов, всегда было чем заняться. В такой период можно вернуться к решению отложенных задач, если они еще актуальны. Мы стараемся держать более-менее ровную загрузку, поэтому рабочие места не пустуют.
Обычно на потом мы откладываем работу с документацией. «Потом» наступает, когда задач мало.
На этом все. Будем рады, если вы поделитесь своим опытом создания команд и работы над проектами. Подробнее о проектах можно ознакомиться в наших предыдущих статьях.