В информационной безопасности больше нет внутренних тем. От зрелости подрядчиков до поведения сотрудников — все напрямую влияет на устойчивость бизнеса. Компании выстраивают доверие внутри экосистем, ищут баланс между контролем и удобством, осторожно пробуют ИИ и пересматривают отношение к open source. Известный эксперт по кибербезопасности Артем Калашников объясняет IT-World, почему ИБ должна проектироваться вместе с бизнесом, что мешает автоматизировать контроль и как культура становится реальным инструментом, а не лозунгом. Первое правило — договориться о каналах коммуникации. Нужно четко определить, какие считаются официальными: мессенджеры, почта, корпоративные системы. Если это зафиксировано (лучше всего — в договоре), обсуждение вопросов идет быстрее. Второе правило — зоны ответственности. Каждый ключевой процесс должен быть закреплен за конкретным человеком еще на этапе анализа. Этот специалист становится «точкой входа» в коммуникации и удерживает согласованное видение. Он сопровождает каждую коммуникацию до завершения — так мы гарантируем, что цели достигаются и не остаются в подвешенном состоянии. Третье правило — встречи. Эффективность падает, когда участвует больше пяти человек (максимум семь, но только если часть участников наблюдатели). Мало кто задумывается: час встречи для компании, особенно с участием высокопоставленных лиц, может стоить сотни тысяч рублей. Поэтому приглашать стоит только тех, кто принимает решения по теме. Главное — заботиться о комфорте другой стороны. Никогда нельзя ставить в тупик неподготовленных людей и требовать решений «здесь и сейчас». Поэтому простое правило: все, что можно решить письменно, нужно решать письменно. А если встреча все же проводится, то должна быть заранее направленная повестка, протокол по итогам и фиксация итогов. Казалось бы, простые «гигиенические правила», но на практике именно их игнорирование чаще всего убивает проект. Как говорить с заказчиком о проблемах Отдельный вопрос — как обсуждать с заказчиком проблемы: рассказывать сразу или, наоборот, хранить молчание и пытаться закрыть вопрос любой ценой? По опыту — многое зависит от типа компании. В коммерческих структурах обычно ценят прямоту и открытый диалог. В крупных корпорациях или госсекторе резкая откровенность воспринимается хуже, там требуется более осторожный стиль подачи. Но главное — никогда нельзя «вываливать» проблему и перекладывать ее на заказчика. Корректный подход — прийти с готовыми вариантами ее решения. Например: «Есть риск. Вот три сценария, у каждого свои плюсы и минусы. Давайте обсудим». Тогда заказчик видит, что ситуацию держат под контролем. Приносить вместе с проблемой решение — это знак профессионализма, заботы о заказчике и уважения к его работе. Ведь у него такие же KPI, давление и риски, как и у нас. Еще одна важная вещь — личный контакт. Не стоит впервые поднимать проблему на общем статус-митинге при топ-менеджерах. Для этого должна работать прямая связка между проектными менеджерами: можно написать или позвонить коллеге со стороны заказчика, обсудить ситуацию заранее и подготовить варианты. Тогда, когда вопрос выйдет в публичное поле, у всех будет общее понимание и готовый план действий. Баланс прост: проблемы нельзя замалчивать, но и паники быть не должно. Если что-то пошло не так В процессе реализации почти всегда возникают новые идеи и уточнения. Если ключевые задачи решены, и заказчик получает около 80% задуманного, систему уже можно считать работающей: бизнес получает эффект, а дальше заказчик решает — развивать её дальше или зафиксировать результат. Другое дело, когда получилось совсем «не то». Это значит, что в самом начале никто не задал правильных вопросов: все кивнули, побежали делать — и ушли мимо цели. Такой сценарий — худший из возможных. К счастью, он редкий: почти всегда в команде находится хотя бы один человек, который вовремя скажет: «Стоп, давайте уточним». У любого проекта есть предел прочности. Но если совпадает слишком много негативных факторов — слабый тимлид, плохая коммуникация, увольнения, ошибки субподрядчиков — проект начинает тонуть. Чтобы этого не допустить, главное правило: нельзя молчать. С заказчиком нужно разговаривать напрямую, как только появляется ощущение, что дело идет не так, иначе через несколько месяцев будет только хуже. Тут принцип такой же, как с врачом: почувствовал недомогание — иди сразу. Итоговый чек-лист Итак, как на практике избежать расхождения ожидания и реальности? Помогает опыт — чем больше реализованных проектов, тем легче предугадывать риски. Но даже если его еще немного, проверять себя можно по чек-листу: если соблюдать все эти правила, то на выходе система даст ожидаемый эффект. Не принимайте за ТЗ готовое решение по мнению клиента — совместно сформулируйте проблему или цель. Спрашивайте: какой эффект нужен бизнесу? Заранее учитывайте уникальные бизнес-процессы клиента и переводите особенности в измеримые показатели (в идеале денежные). Оценку показывайте клиенту через цепочку: решение — процесс — влияние — деньги. Назначьте ответственных за ключевые процессы еще на этапе анализа. С самого начала зафиксируйте каналы коммуникации. Проводите встречи эффективно: не больше 5-7 участников, всегда с повесткой и протоколом, все, что можно решить письменно — решайте письменно. Принцип врача: почувствовали проблему — обсуждайте сразу, иначе будет поздно. Но соблюдайте баланс: проблемы нельзя замалчивать, но и панику создавать не нужно. Обсуждайте сложности сначала в личном контакте, а не на общем совещании. Приносите клиенту не только проблему, но и варианты решений. Помните: «совсем не то» происходит, если в начале не задали правильных вопросов. Опубликовано 31.10.2025 Source: https://www.it-world.ru/cionews/hk0qmcxmm00k80wcskogcgw8wcg4os4.html