В IT-проектах серьезные проблемы редко начинаются с очевидной ошибки. Обычно это набор небольших недосмотров: не уточнили требование, не проверили ограничение старой системы, не заметили зависимость от подрядчика.
И это нормально: люди не всегда сразу понимают, что перед ними ошибка. Иногда это выглядит как техническая особенность, временный сбой или привычное ограничение системы. Иногда сотрудник видит проблему, но считает, что успеет исправить ее сам. А иногда уже понимает, что риск влияет на результат, но тянет с признанием: не хочет выглядеть виноватым, боится реакции руководителя или надеется, что ситуация как-то выровняется.
Цифровой продукт почти никогда не живет отдельно: он связан с CRM, ERP, личными кабинетами, платежными сервисами, аналитикой, внутренними регламентами, требованиями информационной безопасности и работой внешних подрядчиков.
Поэтому небольшая проблема на одном участке может быстро выйти за его пределы. На стыке систем она начинает влиять на сроки, данные, безопасность, работу смежных команд и обязательства перед заказчиком..
Ошибка, риск и момент эскалации
В проектах Notamedia.Integrator мы работаем и с разработкой решений с нуля, и с уже существующим цифровым контуром заказчика. Во втором случае все обычно сложнее. У компании уже есть старые системы, внутренние ограничения, несколько подрядчиков, разрозненные данные, разные уровни доступов и сроки, которые редко можно назвать комфортными.
В такой среде мы можем дорабатывать действующие решения, проводить аудит, выстраивать интеграции, создавать новые сервисы и приводить цифровые продукты в соответствие с требованиями информационной безопасности. Но управлять такими проектами только по финальной приёмке нельзя.
Если руководитель узнаёт о серьёзной проблеме в конце, это значит, что раньше уже что-то не сработало. Не оценили риск. Не отследили зависимость. Не зафиксировали решение. Не назначили владельца. Не подняли вопрос на нужный уровень.
При этом не каждую сложность нужно сразу нести генеральному директору. В проекте постоянно возникают рабочие вопросы, и сильная команда должна уметь решать их самостоятельно. Но есть понятная граница. Если проблема начинает влиять на сроки, бюджет, архитектуру, безопасность, данные, обязательства перед заказчиком или работу других команд, это уже не просто рабочий нюанс. Это риск, которым нужно управлять.
Задача руководителя здесь не в том, чтобы требовать от людей безошибочности. Это бесполезное требование. Задача в другом: заранее договориться, какие ситуации команда решает сама, а какие обязана эскалировать.
"Руководитель должен быть готов не только к хорошему сценарию. В сложном проекте план Б – это не пессимизм, а нормальная часть управления", – отмечает Алексей Власов, генеральный директор Notamedia.Integrator.
Почему люди молчат
Одна из самых удобных управленческих иллюзий звучит так: если о проблеме никто не сообщил, значит, проблемы нет. На практике обычно есть три сценария.
В первом случае человек просто не видит ошибку.
Для него это техническая особенность, временный сбой или привычное ограничение системы. Он может искренне считать, что всё идёт нормально. Здесь давление мало что исправит. Нужны чек-листы, ревью, понятные критерии качества, регулярные синхронизации и участие более опытных специалистов. То есть процесс, который помогает увидеть проблему раньше.
Во втором случае человек проблему видит, но не считает ее серьезной.
Он думает, что исправит позже, что дефект ни на что не повлияет или что заказчик все равно не заметит. Такое часто происходит, когда сотрудник видит только свой участок и не понимает общую картину проекта. Поэтому в интеграционных командах важно объяснять не только что нужно сделать, но и как конкретное решение связано с другими системами, сроками и обязательствами.
Третий сценарий – самый неприятный.
Человек понимает, что проблема уже влияет на результат, но сознательно молчит. Боится критики, ответственности, потери доверия или статуса.
В исследованиях для этого используют термин "психологическая безопасность". Звучит немного академично, но для бизнеса смысл довольно простой: сотрудник должен иметь возможность сообщить о риске раньше, чем тот превратится в аварийную ситуацию. Если человек боится сказать: "Здесь мой косяк", "Мы ошиблись в оценке" или "Срок уже под угрозой", руководитель работает с красивой, но выдуманной картиной.
А управлять выдуманной картиной невозможно. Можно проводить встречи, обновлять статусы и смотреть на зеленые индикаторы. Но сроки, бюджет и ожидания заказчика от этого не становятся более реальными.
Доверие – это не отсутствие проблем
В бизнесе доверие часто воспринимают как что-то связанное с комфортом и хорошей атмосферой в команде. В IT-проектах смысл другой. Доверие появляется не тогда, когда проблем нет, а тогда, когда о проблемах говорят достаточно рано.
В реальной работе редко бывает так, что все риски заранее видны, все решения идеально задокументированы, а каждый участник проекта сразу понимает последствия своих действий. Всегда есть неопределенность: меняются требования, появляются новые вводные, возникают зависимости от других команд и подрядчиков. Поэтому важна не идеальная система без ошибок, а способность команды быстро показать реальное состояние проекта.
В интеграционных проектах особенно важно не потерять эту связь между проблемой и решением. Когда несколько систем, команд и подрядчиков работают вместе, небольшая недоговоренность может проявиться только спустя время – уже на этапе тестирования или запуска. Поэтому часть работы руководителя – создавать условия, в которых плохая новость появляется не в день релиза, а тогда, когда еще есть возможность что-то изменить.
При этом доверие не отменяет дисциплину. Решения нужно фиксировать, ответственность должна быть понятной, а критичные риски – видимыми для тех, кто может на них повлиять. Но смысл этих процессов не в том, чтобы найти виноватого после проблемы, а в том, чтобы быстрее принимать решения.
В IT невозможно сделать так, чтобы ничего никогда не ломалось. Но можно сделать так, чтобы команда не тратила время на скрытие проблемы и быстрее переходила к ее решению.
По данным PwC Global CEO Survey 2026, 66% руководителей компаний за последний год сталкивались с вопросами доверия со стороны стейкхолдеров. В числе таких вопросов – безопасность ИИ, конфиденциальность данных, прозрачность бизнеса и устойчивость компании.
Как руководитель снижает цену ошибки
Сегодня управление сложными IT-проектами – это в первую очередь управление рисками. Можно выстроить процессы, настроить контроль и сделать прозрачные статусы, но это не отменяет главного: ошибки все равно будут.
Задача руководителя не в том, чтобы создать проект, где ничего никогда не ломается. Такой модели не существует. Задача – заранее понимать, где проект может столкнуться с проблемой, и иметь варианты действий.
На практике это означает одно: держать план Б по критичным участкам проекта.
Особенно это важно при работе с действующими системами, где всегда есть история предыдущих решений, ограничения инфраструктуры и накопленный технический долг.
В сложных проектах выигрывает не тот, у кого никогда не возникает проблем. Выигрывает тот, кто раньше других понимает, что проблема появилась, и быстрее принимает решение.
