Как «подружить» IT-отдел и бизнес: советы айтишника-психолога

Сегодня IT-технологии лежат в основе каждого бизнес-процесса. Тем не менее, большинство владельцев компаний и директоров не чувствуют себя комфортно в общении с разработчиками. Согласно отчету Dynatrace, 49% IT-директоров вообще считают, что ситуация, когда бизнес и IT-команды работают в отдельных «бункерах», является самым большим препятствием для цифровой трансформации. Поэтому сейчас как никогда важно укреплять сотрудничество между командами и помнить, что IT-отдел следует рассматривать как делового партнера, а не как «поставщика». «Про бизнес» поговорил с frontend-разработчиком компании Start X Юлией Тарасовой, которая самостоятельно изучила языки программирования, имеет научную степень по психологии и опыт работы с X5 Group, Сбербанком, QIWI, МВидео. Эксперт рассказала, как наладить коммуникацию и сотрудничество между менеджментом и программистами, а также поделилась советами по найму «своих» айтишников.

Почему бизнес «не понимает» IT

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

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

Еще одна из популярных причин непонимания — это «технический язык». Довольно часто на обсуждениях разработчики начинают (возможно, сами того не замечая) переходить на технический сленг и забывают, что коллеги не владеют терминологией, а, соответственно, не понимают всей важности аргументов. Яркий пример — слово «фича», которое часто используют айтишники. Дословно его можно объяснить как «новая функциональность» или «часть продукта, которая имеет специфические характеристики». На самом деле таких слов огромное количество и бизнесу действительно порой сложно понять, что оно значит. Это причина работает и в обратную сторону, когда бизнес пытается объяснить что-то, используя свои специфические термины, которые могут быть абсолютно не знакомы программисту. Скажем, врядли разработчик поймет, что такое EBITDA.

Но эффективно преодолеть этот разрыв между IT-специалистами и бизнес-лидерами вполне возможно.

Как выстроить коммуникацию между бизнесом и IT

Выстраивание коммуникации между бизнесом и разработкой стоит начинать с найма человека или нескольких людей, которые обладают компетенциями обеих сторон и может играть роль «переводчика». Таким человеком может быть team lead команды разработки, который «вырос из программистов» и уже выполняет менеджерские задачи, а значит больше погружен в бизнес. Его опыт и приобретенные навыки послужат «мостиком» в обсуждении. Он сможет объяснять обеим сторонам важность того или иного аргумента, в также донесет всю суть на понятном языке для бизнеса и программистов. С таким человеком в команде можно быть уверенным, что на встречах каждый будет услышан и понят.

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

Еще один полезный лайфхак в выстраивании коммуникации — новый опыт. Например, если говорить о стартапах, там разработчик очень близок с бизнесом. Он чувствует боли «молодого» продукта, понимает что важно, а что нет, и в такой ситуации все в команде говорят на одном языке и работают в согласии. В крупных компаниях ситуация иная. Здесь «главенствует» бюрократия, поэтому нужно пройти много согласований и проверок, чтобы привнести какие-то новые идеи в продукт и достучаться до бизнеса. В таких компаниях программист часто чувствует себя пешкой и теряет мотивацию и страсть к продукту. Что можно сделать? Как вариант, бизнес может на день погрузиться в среду команды разработки, узнать, как команда работает изнутри, возможно, попробовать что-то написать сам. Такой формат поможет укрепить и просто человеческие отношения. Для программистов, в свою очередь, тоже можно устроить «бизнес день» и предложить провести презентацию продукта клиенту или представить свои идеи по улучшению. Изначально идея может не понравится, но когда каждая сторона попробует такой опыт и себя в новой роли, ей будет легче понимать боли другой.

Как найти «своего» IT-специалиста: правила найма

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

Каждая компания самостоятельно определяет портрет своего кандидата и решает вопрос с образованием. Например, в крупных IT-компаниях в России (Яндекс, Ozon, Авито) одним из важных этапов собеседования является решение алгоритмических задач. Отношение программистов к алгоритмам — это отдельная тема, вызывающая много споров. Однако, крупные компании больше ценят именно навык мыслить в рамках оптимального решения задач, чем наличие образования.

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

Поэтому при поиске «своего» кандидата важно обращать внимание на то, как он учится. Например, недавно к нам в команду искали джуна и среди всех кандидатов, в том числе имеющих высшее техническое образование, выбрали девушку, окончившую медицинский ВУЗ. Она самостоятельно училась программировать и теперь работает в команде.

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

S — situation — ситуация, в которой оказался кандидат;

T — task — задача, которую он должен был выполнить;

A — action — действия, которые он предпринял;

R — result — окончательный итог ситуации.

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

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

Некоторые компании обращают внимание на средний возраст коллектива. Например, команда в возрасте от 20 до 39 лет будет на «одной волне», разница в возрасте будет незаметна.