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