Как руководителю не из IT-сферы управлять айтишниками в компании — отвечают эксперты

Существует миф о том, что руководить IT-компанией должен человек, имеющий профильный бэкграунд: личный опыт работы с технологиями, в разработке и т.п. И, соответственно, люди, не имеющие такого бэкграунда, сталкиваются с непреодолимыми сложностями в управлении коллективом айтишников. Я, как руководитель, имеющий такой кейс в личном опыте (в 2016 году и пришла в Банки.ру из банковского сектора), готова опровергнуть этот миф.

У любой компании есть цели и стратегия. И задача любого руководителя – из IT или нет – на их основе сформулировать vision (видение) компании на долгосрочный период. Какие продукты будет развивать компания, к каким результатам стремиться, какую value она несет клиентам. А затем донести это видение до каждого, вне зависимости от специализации.

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

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

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

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

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

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

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

В небольших компаниях дело часто обстоит иначе. Там обычно существует 1-2 штатных айтишника или же эта часть работ отдана на аутсорс, а за взаимодействие отвечает специально назначенный сотрудник. Лично мне успешное руководство IT-сотрудниками при такой конфигурации не встречалось. Обычно не-IT руководитель не хочет, а часто и не может вникнуть достаточно глубоко в специфику работы. В таком случае все его руководство сводится к выпуску разного рода решений, методичек и прочих регламентов, контролю за маркировкой серверных стоек и розеток, проведением инвентаризации железа и т. д. Понятно, что к реальному обеспечению работоспособности компании все эти мероприятия имеют весьма примерное отношение, и предназначены прежде всего для того, чтобы руководитель вел отчетность о проделанной им работе. Здесь успешное сотрудничество зависит от доброй воли, компетенции и лояльности IT-сотрудника, так как он фактически самостоятельно отвечает за работоспособность доверенных ему структур.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Есть мнение, что каждая компания сейчас по определению софтверная и пользователи являются заказчиками технологий. Сейчас разработчики регулярно и часто обновляют свою продукцию по запросу от пользователей, что являются основным стимулом развития технологий сегодня. Цифровые технологии используются практически везде и глубина погружения пользователя в технологию не поверхностная: пользователи стали настолько продвинутыми, что их компетенции можно читать в таких же матрицах, как и IT-специалистов. Поэтому я не вижу какой-то явной разницы, что айтишниками нужно управлять так-то, а не-айтишниками так-то, ведь отделять одних от других на уровне управления кадрами и талантами сейчас не нужно, ибо они тесно взаимосвязаны между собой. Раньше внутри компании был «сисадмин» – вот он и его команда считались айтишниками. Сейчас, конечно, всё совсем иначе.

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

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

Сначала я работал директором по развитию ISPsystem. И мне важно было разобраться, что такое хостинг и контрольные панели. Я понимал, что это, но поверхностно. А без глубокого знания рынка, целевой аудитории и т. д. продвигать продукт и развивать компанию тяжело. Поэтому читал документацию, статьи, книги, форумы. Возглавил компанию только через несколько лет, и этот временной лаг очень помог.

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

Но не везде были нужные люди, и мне все равно приходилось глубоко погружаться в работу. В то время сильно менялись процессы, появлялись новые люди и новые отделы. Когда запускали отдел UX, читал много книг про UX, внедряли Scrum — читал про Scrum. Начали писать автотесты на Python, я дома по ночам изучал Python. Со временем люди заняли свои места и теперь мне намного меньше приходится разбираться в подкапотной магии отделов. Как раз та ситуация, когда есть команда и ты работаешь на полном доверии с ней. Поэтому люди — главное, что есть.

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

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

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

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

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

Прежде, чем приходить с предложением внедрить ту или иную идею, бизнес-подразделение должно определить проблему, которую планирует решить с помощью новой фичи, и ее провалидировать, т.е. ответить на вопросы:
а) проблема действительно существует?
b) какого размера проблема или ожидаемая прибыль?
с) может быть проблему можно решить без разработки?
d) и самое неприятное – что будет, если идею не реализовывать?

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

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

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

Главное – правильно организовать процесс разработки. Как ни странно, при работе с командой программистов вам понадобится выбрать модель организации их рабочего процесса. И первым сюрпризом для вас будет, что тут не работают принципы, которые вы изучали на MBA и потом успешно применяли в отделе продаж, в отделе финансов, в отделе логистики, в любом другом отделе. У программистов это все не работает. Как быть? Первый совет: возьмите готовую методологию, предназначенную для организации рабочего процесса у разработчиков, благо их сейчас очень много: Scrum, Agile и т.п. Для их изучения вам обязательно понадобится прочитать пару книг и пройти пару платных курсов.

Но не все так просто. Вам будет казаться, что эти методологии не совершенны. Выбрав одну из них, вы захотите её модифицировать, под предлогом, что ваш бизнес не такой, как все остальные и поэтому вам жизненно необходимо внедрить свои фишки. Или вам будет казаться, что методология несовершенна, а вы настолько гениальны, что можете её усовершенствовать и сделать лучше. Но все это иллюзия. Поэтому, мой второй и самый главный совет – не пытайтесь придумывать свое. Делайте строго по канонам методологии так, как описано в книжке. Тупо и в лоб. Я потратил 2,5 года, изобретая свои велосипеды и модифицируя готовые методологии «под себя». И каждый раз получалось плохо. В итоге вернулся к тому, что стал действовать на 100% так, как описано в книжках. И знаете что? Все стало круто!

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

Программисты – перфекционисты. Многие программисты по своей природе стремятся к бесконечному совершенству. При этом они не умеют считать затраченное время на достижение идеального результата. Каждый второй разработчик готов по 10 раз переделывать одно и то же, лишь бы получилось идеально. Что с этим делать? Во-первых, нужно такие ситуации выявлять. А во-вторых, нужно помогать программистам искать баланс между совершенством и стоимостью достижения совершенства. Как? Я делаю так: задаю программисту вопрос: а можем ли мы это не переделывать? А какие будут последствия, если мы это не переделаем? В зависимости от ответа оцениваю риски и принимаю решение. Главное при принятии решения — искренне вникнуть в проблему и встать на сторону программиста.

Стенка для мяча. Если вы хотите управлять программистами, то вам понадобится стенка для мяча. Не в буквально смысле, а в переносном. Что это значит? Иногда у программиста или даже у целой команды происходит творческий ступор, они начинают искать выход из него и еще больше «закапываются». Вам нужно научиться вовремя выявлять тяжелые стадии «самозакапывания» и становиться стенкой для мяча. Как это? Вам нужно поговорить с программистами. Позадавать свои дилетантские вопросы, предложить свои глупые идеи относительно архитектуры, высказать свое обывательское мнение. В общем, всячески с помощью вопросов-ответов дать программисту почеканить об вас проблему. Вы не поверите, это работает: в 95 процентов случаев из 100 после такой процедуры программисты сами найдут лучшее решение.

Учитесь понимать программистов. Как бы вам ни хотелось, но к программистам нужно вырабатывать особое отношение. Не такое, как к остальным отделам вашей компании. Для это вам нужно их лучше понимать. В свое время понять программистов мне помогла книга «Как работает гугл». Всем рекомендую её почитать. Лично мне эта книга помогла понять: почему программисты всегда срывают сроки? Почему стандартные методы менеджмента и мотивации персонала с программистами не работают или работают хуже. Почему…. Почему… В общем, многие почему ушли после этой книги.

У нас нет как таковых айтишников в команде in-house, поэтому, по вопросам разработки мы работаем с агентствами. Управлять сложно, сначала было много аккаунт-менеджеров: мы в письме описывали запрос, через несколько часов к нам возвращался аккаунт, говорил что задача в работе и сроки будут чуть позже… Потом возвращались со сроками и , далеко не всегда получалось успеть до дедлайна. Процесс показался нам слишком долгим и мы решили его оптимизировать: взяли по 1 проектному менеджеру у каждого агентства и перенесли все задачи из почты – в систему ведения задач ( мы остановились на TeamWork). Так мы стали лучше контроллировать работу IT и сроки. По итогу месяца на статусе мы видим просроченные и закрытые во время задачи и, по результатам можем эффективно оценивать работу агентства.

До создания Крипто Технолоджи я работал в финансовой сфере, где взаимодействие с ИТ-специалистами было опосредованно. Открыв майнинг-компанию, которая разрабатывает как hardware, так и software, я понял, что к ИТ-специалистам нужен особый подход. Это – отдельная каста, зачастую капризных и непредсказуемых, но талантливых и умных людей. Чтобы заинтересовать грамотного разработчика вакансией и мотивировать на работу нужно не только хорошо платить за результат работы, но создавать комфортные условия в офисе.

Часто ИТ-специалистами руководят люди, которые не сильно разбираются в разработке. Поэтому важно правильно ставить задачи: разбить крупную цель на несколько небольших, писать техническое задание как можно более подробно и простым языком, желательно вначале утвердить дизайн-макет прототипа, т.е. где какие кнопки будут, какие функции будут доступны пользователю. Контролировать результат работы сотрудников лучше через таск-менеджеры. А еще, чтобы найти общий язык с разработчиками и понимать, как устроен весь рабочий процесс нужно обязательно изучить Agile и Scrum. По этой методологии сейчас работает практически каждая IT компания. Это удобно, эффективно и крайне интересно.

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

Однако на практике часто бывают ситуации, когда у вас просто нет ресурсов, чтобы нанять такого человека, перекрывающего эту разность языков и взглядов на мир «бизнес vs ИТ-блок». Но и в этом случае у хорошего лидера и вовлеченной команды есть все шансы на успех. Главное, поймите: все технологичные люди очень системны и достаточно конкретны. Поэтому им нельзя ставить задачи из серии «я хочу, чтобы здесь было красиво или удобно». Это не значит, что вами должна быть полностью проработана архитектура и фактически прототип решения, но все пожелания и ожидания результатов от команды надо транслировать максимально четко, системно и открыто. Для этого сначала нужно поработать с самим собой, сформировав определенное видение того, чего вы хотите добиться на выходе, четкие ожидания от продукта деятельности технической команды. Если вы не сможете понять, какой продукт вам нужен в итоге, то получить какой-то результат будет сложно: либо с вами не будут работать (самые честные), либо будут работать спустя рукава, либо будут просто тянуть деньги.

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

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

У меня есть несколько инструментов для контроля разработчиков:
1) Хабстаф – тайм-трекер, делает скриншоты, таймит задачи, показывает активность сотрудников.
2) Трелло – задачник – удобный и быстрый инструмент для отслеживания задач, хода задач и их стадии.
3) Отчет в GoogleDocs – таблица, где считаются часы по каждому проекту в отдельности, по каждому сотруднику кол-во часов за месяц, так же в ней начисляется зарплата и формируются другие отчеты.

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

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