Технические навыки в IT-компании растут почти сами. Разработчики читают документацию, смотрят доклады, разбираются в новом фреймворке за выходные. Компания платит за курсы и конференции, и это работает.
Проблемы начинаются в другом месте. Заказчик недоволен, хотя код написан хорошо. Демо провалилось, потому что команда полчаса рассказывала про архитектуру, а клиент хотел увидеть, как это работает. Сильный разработчик стал тимлидом, и через полгода из его команды ушли двое.
Всё это про коммуникацию, и учить ей технических специалистов можно, если делать это на их языке.
Обучение сотрудников IT-компании чаще всего нужно не по технологиям, а по коммуникации: уточнение требований, демо для заказчика, код-ревью, работа тимлида и английский для созвонов. Такие занятия работают, когда строятся на реальных рабочих ситуациях команды, а не на ролевых играх из учебника.
Обучение сотрудников IT-компании: почему разработчики не любят soft skills
Скепсис технических команд к таким тренингам понятен. Многие из них видели программы с ролевыми играми, где взрослых людей просят «поделиться чувствами». Для инженера это выглядит как потеря дня.
Второе возражение звучит так: «Мне платят за код, а не за разговоры». Оно справедливо ровно до того момента, когда код приходится переписывать, потому что требования поняли неправильно.
Лучше работает разбор конкретных рабочих ситуаций: уточнение требований, оценка сроков, демо, код-ревью, разговор с заказчиком о срыве. Когда занятие строится вокруг того, что команда делает каждую неделю, польза от него понятна без объяснений.
Уточнение требований и оценка сроков
Большая часть конфликтов с заказчиком начинается на этапе, когда задачу ещё не начали делать. Бизнес сформулировал её одним предложением, разработчик понял по-своему, и через две недели обе стороны недовольны.
Навыки, которые здесь нужны:
- задавать уточняющие вопросы так, чтобы заказчик не почувствовал себя экзаменуемым;
- проговаривать своими словами, что будет сделано, и получать подтверждение;
- называть допущения явно, а не держать их в голове;
- давать оценку сроков с диапазоном и объяснять, от чего он зависит.
Отдельная тема: как говорить «нет» или «не к этой дате». Технические специалисты часто соглашаются на нереальный срок, чтобы избежать неприятного разговора, и потом этот разговор всё равно происходит, только в худший момент.
Пресейл, аккаунт-менеджеры и разговор о скоупе
В компаниях, которые делают проекты на заказ, есть роли на стыке техники и продаж: пресейл-инженеры, аккаунт-менеджеры, руководители проектов. От них зависит, какие обещания получит клиент и сможет ли команда их выполнить.
Типичная проблема такая: на пресейле обещают больше, чем заложено в оценку, чтобы выиграть проект. Дальше команда полгода живёт в режиме «доделываем бесплатно», а отношения с заказчиком портятся.
На обучении разбирают несколько тем. Как выяснить реальную задачу клиента до того, как предлагать решение. Как объяснить нетехническому заказчику, почему одна кнопка стоит две недели работы. Как вести переговоры об изменениях объёма и оформлять их, чтобы новые запросы не превращались в бесплатную работу. Как сообщить о срыве срока так, чтобы клиент остался.
Здесь хорошо работает разбор реальных переписок и протоколов встреч компании. Люди видят, в какой момент разговор пошёл не туда.
Демо и презентация решений
Разработчик, который показывает результат спринта, обычно рассказывает то, что ему интересно: как устроено решение, какие были сложности, что пришлось переписать. Заказчику интересно другое: что теперь может пользователь и какую его проблему это решает.
На обучении разбирают, как перестроить демо под аудиторию. Сначала сценарий пользователя, потом результат, техника только по вопросам. Как отвечать, когда что-то сломалось прямо на показе. Как говорить о том, что не успели.
Навык презентации у технических людей развивается быстро: материал и понимание предмета у них есть, не хватает только структуры. Общие принципы мы описывали в статье про навыки презентации, а для IT-команд они применяются к демо, питчам и защите архитектурных решений.
Код-ревью и обратная связь внутри команды
Код-ревью в команде может быть главным инструментом роста, а может стать местом, где копятся обиды. Разница в том, как пишутся комментарии.
«Это неправильно, переделай» и «Здесь при большом объёме данных запрос будет медленным, давай вынесем в отдельный метод» содержат одно и то же замечание. Первый вариант вызывает защиту, второй объясняет, почему и что делать.
Технические специалисты быстро схватывают эту разницу, если разбирать реальные комментарии из их репозиториев, без имён. Обычно хватает одного занятия, чтобы тон ревью в команде заметно изменился.
Шире тема обратной связи касается тимлидов: как говорить с разработчиком о сорванных сроках, о качестве кода, о том, что он мешает команде. Это уже управленческий навык, о нём ниже.
Тимлид: из сильного разработчика в руководителя
Стандартная история в IT: лучшего разработчика назначают тимлидом. Он продолжает писать сложные части сам, потому что так быстрее, делегирует только простое, а на разговоры с командой времени не остаётся. Через полгода команда зависит от одного человека, а он выгорает.
Программа для новых тимлидов обычно включает:
- переход от «делаю сам» к «команда делает»: что делегировать и как проверять, не переделывая;
- регулярные встречи один на один, чтобы они не превращались в статус по задачам;
- разговоры о проблемах: сроки, качество, конфликты между разработчиками;
- защита команды от хаотичных запросов со стороны бизнеса;
- участие в найме и вводе новых людей.
Путь от специалиста к руководителю похож во всех отраслях. Мы подробно разбирали его в статье от линейного менеджера к лидеру. В IT к этому добавляется специфика: руководитель должен сохранять техническую экспертизу, иначе команда перестанет его уважать.
Английский для митингов и документации
Многие казахстанские IT-компании работают на зарубежных заказчиков или входят в международные группы. Ежедневные созвоны, переписка в трекере, документация, код-ревью, собеседования, всё это часто идёт на английском.
Разработчики обычно хорошо читают технический английский. Сложности начинаются в устной речи: быстро ответить на вопрос на созвоне, объяснить проблему, возразить заказчику, поучаствовать в обсуждении, а не молчать до конца встречи.
Что работает лучше общего курса:
- небольшие группы с разбором реальных ситуаций команды: stand-up, планирование, демо, ретроспектива;
- тренировка коротких устных ответов и уточнений;
- письменная часть: описание задачи, комментарий к ревью, письмо заказчику о сдвиге сроков;
- подготовка к собеседованиям для тех, кто проходит интервью с иностранной стороной.
Для компаний-резидентов технопарков и тех, кто работает с международными клиентами, у нас есть гайд по выбору тренингов английского.
Техническое собеседование
В растущей IT-компании разработчики и тимлиды постоянно участвуют в найме. Собеседование при этом проводят так, как когда-то проводили с ними: набор задачек, вопросы на знание фреймворка и вердикт «слабый» без объяснений.
Проблем здесь две. Компания теряет хороших кандидатов, которые после неприятного интервью выбирают другое предложение. И нанимает не тех, потому что проверяли умение решать задачи у доски, а не умение работать в команде.
Короткое обучение интервьюеров обычно включает: структуру собеседования, одинаковую для всех кандидатов; вопросы о реальном опыте вместо гипотетических; оценку по заранее согласованным критериям; обратную связь кандидату. Одно-два занятия с разбором записей собеседований дают заметный эффект.
Удалённые и гибридные команды
В IT многие команды работают частично или полностью удалённо. Это меняет коммуникацию: меньше случайных разговоров, больше переписки, выше риск, что человек выпадет из команды и никто не заметит.
Темы, которые здесь полезно разобрать: как писать сообщения, чтобы их не приходилось уточнять; как вести созвон, чтобы на нём говорили не только двое; как тимлиду замечать, что с человеком что-то не так, если видишь его только в квадратике на экране.
Сам формат обучения тоже подстраивается. Для распределённых команд подходят онлайн-модули по полтора-два часа с практикой между ними, а не многочасовые вебинары.
Как оценить результат
IT-компании любят метрики, и для обучения их тоже можно найти. До старта выбирают показатели, на которые программа должна повлиять, и возвращаются к ним через два-три месяца.
Примеры: число задач, возвращённых на доработку из-за неверно понятых требований; оценка заказчиком демо или спринта; результаты опросов вовлечённости в команде; текучесть в командах новых тимлидов; для английского результаты входного и выходного тестирования и наблюдение руководителя на созвонах.
Как и везде, обучение влияет на эти цифры вместе с другими факторами. Но без замера через год трудно объяснить, зачем компания тратила деньги.
Сколько времени это занимает
Программа для IT-команды запускается быстрее, чем в производственных отраслях, потому что людей проще собрать онлайн.
Неделя-две уходит на диагностику: разговоры с руководителями, несколько интервью с разработчиками и тимлидами, просмотр примеров переписки, демо и ревью. Потом адаптация программы под стек, заказчиков и процессы компании.
Навыки коммуникации удобно тренировать модулями по полтора-два часа раз в неделю в течение полутора-двух месяцев. Английский идёт дольше: заметный результат в устной речи на созвонах обычно появляется через три-четыре месяца регулярных занятий.
Ошибки, которые повторяются
Тренинг «для всех» с ролевыми играми. Технические специалисты отключаются через час, и следующий тренинг воспринимают с ещё большим скепсисом.
Учат разработчиков и не учат тимлидов. Команда пытается общаться по-новому, а руководитель продолжает раздавать задачи в чате без объяснений.
Английский только по общему учебнику. Через год у людей растёт уровень теста, но они по-прежнему молчат на созвонах.
Разовое мероприятие без продолжения. Без коротких повторов и практики между встречами навыки не закрепляются.
Вопросы и ответы
Какие soft skills нужны разработчикам в первую очередь?
Уточнение требований и оценка сроков, презентация результата заказчику и корректная обратная связь на код-ревью. Эти навыки напрямую влияют на переделки и отношения с клиентом.
Нужно ли отдельное обучение новым тимлидам?
Да. Сильного разработчика назначают руководителем, а делегировать, проводить встречи один на один и разбирать проблемы в команде его никто не учил. Без этого команда быстро начинает зависеть от одного человека.
Какой английский нужен IT-команде?
Устный рабочий: стендапы, планирование, демо, ответы на вопросы заказчика. Читают документацию разработчики обычно хорошо, а говорить на созвонах им трудно.
Как проводить обучение для распределённой команды?
Онлайн-модулями по полтора-два часа раз в неделю с практикой между встречами. Многочасовые вебинары для удалённых команд работают плохо.
Caspian Training Group 25 лет проводит корпоративное обучение в Казахстане, более 850 компаний обучались у нас, в том числе банки и финтех, например Kaspi и Банк ЦентрКредит. Для IT-компаний мы готовим программы по коммуникации с заказчиком, презентации решений, обучению тимлидов и английскому для созвонов и документации. Работаем в Алматы и Атырау, для распределённых команд онлайн. Посмотреть форматы и обсудить задачу.