Как работать с ИТ, когда ты ничего не понимаешь в технике

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

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

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

Думаю, начинать всегда стоит с людей.

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

Формальные процедуры не всегда совпадают с реальными, поэтому консультации более опытных коллег будут совсем не лишними.

Продуктом для вас будет является та система/сервис из-за которого вы и обращаетесь в ИТ. Например, для менеджера по продажам продуктом может быть как CRM- система, в которой он работает, так и сервис, который он продает.

Что я понимаю под фразой "разобраться с продуктом"? Здесь речь не о специфике самого продукта, вы и так должны знать что продаете и/или в какой системе работаете, а о том как с продуктом работает ИТ отдел. Вам нужно понять как делаются доработки и какие для этого задействуется ресурсы.

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

Достаточно часто у ИТ специалистов есть свое представление о том, чем вы должны заниматься (и оно не всегда совпадает с вашим🙂). Чем раньше вы обозначите свою роль и уровень вовлеченности в процессы разработки, тем проще вам будет работать.

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

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

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

Это базовые принципы, которые могут подсказать в какую сторону двигаться, когда совсем непонятно с чего начинать. А дальше выбор за вами - погружаться ли в специфику разработки или остаться на начальном уровне понимания. Я в свое время выбрала погружение и сейчас работаю в сфере продакт менеджмента и довольна тем как сложились обстоятельства😉