Когда тихий DevOps берёт слово
У самого тихого человека на встрече может быть подробное представление о том, как всем остальным следует работать. Особенно если он DevOps: с кластером уже разобрался, теперь можно присмотреться к обязанностям CTO. В шутке есть узнаваемая управленческая деталь. Спокойный специалист может не стремиться захватить разговор, но видеть системные ограничения лучше тех, кто говорит громче.
Например, DevOps молчит на обсуждении нового запуска, а потом коротко объясняет, что выбранная схема создаст ночные дежурства и риск для стабильности.
Я бы в такой момент дала ему слово и попросила отделить наблюдение от предлагаемого решения. Это не значит автоматически передавать инфраструктурному эксперту роль руководителя. Смысл в том, чтобы не путать сдержанность с отсутствием позиции. Принимать решение всё равно предстоит с учётом цели продукта, рисков и ответственности за результат.
Полный разговор — «ИТ-коктейль», выпуск 2: https://rutube.ru/video/01f2414cca6736a7598bdda82b2e0fe9/
Сайт: https://queenit.info/
У разговора о безопасной разработке есть вполне человеческое начало: никто не любит переделывать уже сделанную работу. Саша в первом выпуске предлагает опереться именно на это. Обсудить важные требования раньше, чтобы потом не возвращать команде готовое решение с длинным списком изменений.
Представим новую функцию, которая использует пользовательские данные. Если вопросы о составе данных и доступе возникают только перед запуском, команда уже вложилась в конкретный вариант. Приходится менять решение, пересматривать сроки и объяснять, почему очевидные теперь вопросы не появились раньше.
Я бы пригласила коллег из ИБ в разговор в тот момент, когда ещё выбираем подход. Показала бы задачу пользователя, предполагаемый путь данных и места, где команда пока сомневается. От них хотелось бы получить понятные требования и варианты, а не просто отметку о прохождении согласования.
Раннее обсуждение не отменяет последующих проверок и не гарантирует отсутствие изменений. Оно даёт больше возможностей заметить существенное требование, пока его ещё можно учесть без пересборки готового решения.
Важно и не перестараться: большой комитет на каждую небольшую правку способен съесть всю пользу. Договорённость должна помогать команде понимать, когда и с каким вопросом подключать коллег.
Полный разговор — «ИТ-коктейль», выпуск 1: https://rutube.ru/video/a996b0169f47b8df40c78e284240b862/
Полный первый выпуск в Telegram: https://t.me/IT_koktel/47
Сайт https://queenit.info/
Не понравилась задача? Связь прервалась?
Иногда связь особенно хрупка в тот момент, когда разговор становится неудобным. Задачу обсуждают, участник внезапно исчезает, а потом возвращается с безупречным: «А можно повторить?» В жизни это может быть технический сбой, усталость или несогласие. Комический фрагмент полезен именно потому, что напоминает: руководитель видит поведение, но не всегда знает его причину.
Например, после новой приоритетной задачи человек перестал отвечать на созвоне и начал пропускать сроки. Прежде чем судить о мотивах, стоит зафиксировать решение письменно и отдельно спросить, что мешает выполнить задачу.
Я бы завершала сложный созвон короткой записью: что решили, кто владелец, какой следующий шаг и где можно возразить. Это снижает число «повторите» и оставляет место для честного несогласия. Если договорённости систематически срываются, обсуждать это всё равно нужно — по конкретным фактам.
Полный разговор — «ИТ-коктейль», выпуск 2: https://rutube.ru/video/01f2414cca6736a7598bdda82b2e0fe9/
Закрытый периметр звучит успокаивающе. Но руководителю нужен ещё один ответ: как быстро команда узнает, что внутри происходит что-то не то? В этом фрагменте Таня говорит о мониторинге и времени обнаружения — о части защиты, которая должна продолжать работать и после нежелательного события.
Для меня это повод спросить не только о наличии системы, но и о людях вокруг неё. Кто получает сигнал? Как понимает его важность? Что происходит, если ответственный недоступен? Как команда узнаёт, что сообщение действительно принято в работу?
Представим: событие зафиксировано, уведомление ушло в нужный канал, а разбор начался значительно позже, потому что каждый ожидал реакции другого. Технически цепочка почти вся сработала. Организационно у неё остался разрыв.
Я бы разобрала такой путь на согласованном учебном примере: от события до первого осмысленного действия. Отдельно посмотрела бы, что команда видит, чего не видит и какие вопросы требуют участия профильного специалиста.
Мониторинг не даёт обещания заметить абсолютно всё. И один успешно пройденный сценарий не подтверждает готовность к любому случаю. Но он помогает обсуждать конкретный процесс реакции, а не успокаиваться самим фактом покупки инструмента.
Полный разговор — «ИТ-коктейль», выпуск 1: https://rutube.ru/video/a996b0169f47b8df40c78e284240b862/
Полный первый выпуск в Telegram: https://t.me/IT_koktel/47
У привычной ИТ-системы иногда появляется второе название — то, которое ей даёт финансовый директор, впервые увидев стоимость. В истории Тани инструмент совместной работы превращается в «досочки за миллионы». Кажется, ещё немного — и команде выдадут маркеры.
Шутка хорошо подсвечивает проблему: мы давно понимаем назначение продукта, но не всегда умеем объяснить, какую работу он поддерживает. Название лицензии в бюджете само по себе ничего не говорит о пользе для компании.
Представим, что инструмент нужен нескольким командам для планирования и хранения решений. Я бы начала с фактического использования: кто в нём работает, какие задачи решает и какие возможности остаются невостребованными. Затем посмотрела бы на варианты — изменить набор лицензий, сократить лишнее или попробовать замену на одном процессе.
В сравнении важно учитывать и переход: перенос материалов, обучение людей, восстановление привычных связей между инструментами. Более дешёвая подписка не обязательно означает более дешёвое изменение. Но и привычность продукта не делает любую цену оправданной.
Хороший разговор о бюджете оставляет место обоим вопросам: зачем нам это нужно и можем ли мы получить нужный результат другим способом. Без обиды за любимые досочки.
Полный разговор — «ИТ-коктейль», выпуск 1: https://rutube.ru/video/a996b0169f47b8df40c78e284240b862/
Полный первый выпуск в Telegram: https://t.me/IT_koktel/47
Иногда первый шаг в безопасности — выделить ей место в собственном календаре. Я спросила Сашу Оводова, что небольшой бизнес может сделать, потратив время и внимание. Его ответ — понять, что способно остановить компанию, и регулярно возвращаться к этой теме.
За простым вопросом «что у нас с бэкапами?» сотрудникам слышится важный сигнал: руководителю это действительно нужно. Но мне хочется развить мысль. Если вопрос звучит регулярно, а на ответ не находится времени, внимание быстро становится формальностью.
Представим небольшую компанию, где ИТ занимается один специалист или внешний подрядчик. Я бы выбрала для первого обсуждения один важный процесс. Что случится при его остановке? Какие варианты продолжения работы известны? Что уже проверено, а что пока существует только как предположение?
По итогам полезно договориться об одном посильном действии и сроке возвращения к результату. Не пытаться за встречу составить идеальную программу защиты всей компании. И не ожидать, что сотрудник выполнит дополнительную работу без времени и ресурсов.
Внимание руководителя не заменяет компетенцию специалистов. Его задача — помочь теме стать частью управления: дать место для обсуждения, услышать ограничения и принимать решения по ним, а не только задавать вопросы.
Полный разговор — «ИТ-коктейль», выпуск 1: https://rutube.ru/video/a996b0169f47b8df40c78e284240b862/
Полный первый выпуск в Telegram: https://t.me/IT_koktel/47
В календаре нашлось место для всех, кроме человека, которому этот календарь принадлежит. Александр рассказывает, как поставил себе KPI — обедать каждый день в офисе, не справился и снизил цель до «есть в рабочее время каждый день». Смешно, потому что слишком узнаваемо. За историей стоит вопрос о пределах управленческой занятости.
Например, руководитель переносит обед ради срочного созвона, потом ещё одного, а через месяц считает отсутствие перерыва личной особенностью.
Я бы посмотрела на расписание как на распределение ресурса: где есть время подумать, восстановиться и подготовиться к решениям. Перерыв не обязан быть одинаковым для всех и не лечит перегрузку сам по себе. Но если в календаре не помещается даже базовая пауза, это сигнал проверить приоритеты и объём встреч. Мне в этом разговоре интересно, какие встречи действительно требуют нашего участия, а какие продолжают жить по привычке.
Полный разговор — «ИТ-коктейль», выпуск 2: https://vkvideo.ru/video-239932699_456239021
Продукт проходит через несколько подразделений, а ответственность за него часто заканчивается на передаче задачи. Бизнес формулирует запрос, дизайн делает свою часть, разработка ждёт уточнений, сопровождение получает последствия. Каждый может показать выполненную работу, но общий результат задерживается. Александр Колмаков говорит о командной работе поверх организационных границ: важно помнить, что все делают одно дело.
Например, изменение в продукте требует решения бизнеса, макета дизайна, реализации и поддержки после запуска. Если каждая группа оптимизирует только свой участок, проблема возникает между ними.
Я бы заранее договаривалась о сквозном результате, зависимостях и владельце решения на стыке. Полезно обсуждать не только «что передали», но и что произойдёт с соседней командой после передачи. Это требует времени и не устраняет конфликт интересов автоматически. Но без такого разговора заборы становятся частью процесса, а не просто метафорой.
Полный разговор — «ИТ-коктейль», выпуск 2: ВК: https://vkvideo.ru/video-239932699_456239021
Дзен: https://dzen.ru/video/watch/6aa260aad4f6a573dbc16481
«Сделайте хорошо» — удивительно ёмкое техническое задание. В нём помещаются все ожидания и почти не остаётся шансов им соответствовать. Бизнес может искренне считать, что сформулировал запрос: ведь понятно же, что такое хорошо. Для разработки это часто означает другое — несколько версий результата, каждая из которых кажется очевидной только одной стороне.
Например, бизнес ждёт снижение времени оформления заказа, дизайн — новый экран, а команда разработки — чёткие ограничения по срокам и интеграциям. Все работают добросовестно, но договорённость существует только в головах.
Я бы до старта фиксировала не идеальный документ, а минимальную общую рамку: какую проблему решаем, для кого, по каким признакам поймём, что получилось, что точно не входит в задачу и кто принимает спорное решение. Это не бюрократия ради бюрократии. Такая рамка экономит разговоры после запуска. Совет не отменяет неопределённость: он делает её видимой и управляемой.
Полный разговор — «ИТ-коктейль», выпуск 2: ВК: https://vkvideo.ru/video-239932699_456239021
Дзен: https://dzen.ru/video/watch/6aa260aad4f6a573dbc16481
Перед списком средств защиты стоит задать вопрос о самом бизнесе: что мы не сможем заново собрать завтра? В выпуске Таня объясняет это на примере HeadHunter. Накопленные данные и история взаимодействий создают ценность, которая не появляется просто после развёртывания системы.
Мне кажется важным этот поворот разговора. У компаний могут быть похожие технологии, но разные последствия потери информации или остановки процесса. Поэтому чужой список приоритетов полезно обсуждать, а не механически переносить к себе.
Представим компанию, где важная часть знаний о клиентах хранится в нескольких источниках. Я бы предложила вместе с владельцем процесса разобраться: какие сведения нужны для продолжения работы, что можно получить повторно, что воссоздать трудно и кто знает, насколько актуальны доступные копии.
Следующий шаг — связать ответы с конкретными действиями команды и проверить выбранный порядок восстановления там, где это уместно и безопасно. Само наличие файла с названием «резервная копия» ещё не отвечает на вопрос, сможет ли бизнес им воспользоваться.
Здесь важно не подменять разговор страшным прогнозом. Ценность такого разбора — в ясных приоритетах: что защищаем в первую очередь, почему именно это и какие вопросы пока требуют отдельной проверки.
Полный разговор — «ИТ-коктейль», выпуск 1: https://rutube.ru/video/a996b0169f47b8df40c78e284240b862/
Полный первый выпуск в Telegram: https://t.me/IT_koktel/47
Присутствие сотрудника иногда успокаивает руководителя сильнее, чем любой отчёт. Дверь открывается: за столом человек, монитор включён, картина убедительная. Можно сообщить наверх, что сто дорогих специалистов на месте и работают с девяти до шести. А мы-то знаем: спать можно и с открытыми глазами. Шутка смешная, пока не становится системой управления.
Например, команда ежедневно присутствует в офисе, но выпуск задерживается: решения ждут согласования, задачи переходят между подразделениями, а результат для пользователя не приближается.
Я бы в такой ситуации смотрела на путь работы: что обещали выпустить, где возникла задержка, кто ждёт решения и что получит бизнес.
Это не означает, что присутствие неважно или офис вреден. Оно просто не заменяет результат. Руководителю полезно разделять наблюдаемую занятость и достигнутый эффект. Иначе спокойствие появляется раньше продукта, а проблемы — позже.
Полный разговор — «ИТ-коктейль», выпуск 2: ВК: https://vkvideo.ru/video-239932699_456239021
Дзен: https://dzen.ru/video/watch/6aa260aad4f6a573dbc16481
План реагирования становится особенно ценным, когда некогда выяснять, где он лежит и кто вправе принимать решения. Таня Фомина в первом выпуске говорит о подготовке, которая выходит за пределы технической команды: цепочка эскалации, полномочия, коммуникации и участие руководителей в учениях.
Я бы проверила такой план на простом условном сценарии: три часа ночи, основной ответственный недоступен. Кто получает следующий звонок? Какие решения этот человек может принять? Как подключаются коллеги, которые отвечают за общение с клиентами?
На спокойной встрече эти вопросы могут казаться очевидными. Но разные участники иногда подразумевают разные ответы. Один ждёт отдельного согласования, другой уверен, что действие уже началось. Третий вообще узнаёт о происходящем из общего чата.
Поэтому полезно пройти сценарий вместе и записать обнаруженные пробелы: неактуальный контакт, непонятное полномочие, зависимость от одного человека. У каждого пробела должен появиться следующий шаг, а у команды — время повторной проверки.
Такой разговор не доказывает готовность ко всем инцидентам. Зато помогает не тратить первые минуты реальной проблемы на организационные вопросы, которые можно было решить заранее. Именно об этой части подготовки мне хочется напоминать руководителям.
Полный разговор — «ИТ-коктейль», выпуск 1: https://rutube.ru/video/a996b0169f47b8df40c78e284240b862/
Полный первый выпуск в Telegram: https://t.me/IT_koktel/47
Самая неприятная версия «я же говорила» возникает после инцидента. Бюджет не согласовали, риск остался, а предупреждение внезапно оказалось недостаточно убедительным. В первом выпуске я задаю этот вопрос прямо: что происходит с ответственностью, когда деньги на безопасность годами уступают другим задачам?
В такой ситуации одного названия технической проблемы часто мало. Представим, что руководителю предлагают вложиться в устойчивость сервиса. Для него это конкурирует с новой функцией, от которой ждут продаж. Разговор станет предметнее, если объяснить, какие операции зависят от сервиса, что команда сможет делать при сбое и где останется ограничение даже после вложений.
Я бы принесла несколько вариантов: что можно улучшить сейчас, что требует отдельного бюджета и что мы осознанно оставляем на потом. Вместе с последствиями каждого решения, ответственным и датой повторного обсуждения. Если точная оценка неизвестна, это тоже нужно сказать, а не заменять её уверенным числом.
Такая запись не является индульгенцией для ИТ и не решает вопрос ответственности за всех участников. Она помогает сохранить общий смысл решения. Чтобы через полгода обсуждать изменение обстоятельств, а не спорить, кто что имел в виду под словами «пока потерпит».
Полный разговор — «ИТ-коктейль», выпуск 1: https://rutube.ru/video/a996b0169f47b8df40c78e284240b862/
Полный первый выпуск в Telegram: https://t.me/IT_koktel/47
Можно обложиться дашбордами и всё равно не приблизить команду к результату. Дмитрий Бадун предлагает CTO смотреть на Time to Market — время, за которое задача доходит до пользователя. Это полезный поворот: проведённая встреча, закрытая карточка и длинный список действий ещё не означают, что бизнес получил нужное решение.
Например, функция формально прошла все статусы, но задержалась на согласовании дизайна или вышла с таким количеством ограничений, что её приходится переделывать. Тогда одна скорость без контекста обманывает.
Я бы задавала к ней следующий вопрос: за счёт чего мы ускорились? Слаженной работы, перегрузки отдельных людей или переноса сложности в следующий релиз? Time to Market не отменяет показатели качества, стабильности и технического долга. Это ориентир для разговора, а не кнопка управления. Руководителю важно видеть полный путь до пользователя и цену выбранной скорости.
Полный разговор — «ИТ-коктейль», выпуск 2: ВК: https://vkvideo.ru/video-239932699_456239021
Дзен: https://dzen.ru/video/watch/6aa260aad4f6a573dbc16481
Первый выпуск мы начали с коктейля, которому гости сразу отказались доверять. А потом сами же устроили в нём инцидент. Получилась довольно точная иллюстрация того, как легко спокойствие принять за доказательство безопасности.
Пока всё работает, разговор о защите часто проигрывает более заметным задачам. Новый интерфейс можно показать. Отсутствие инцидента выглядит так, будто ничего особенного и не происходит. Хотя за этим могут стоять и хорошие практики, и просто удача — внешне они иногда похожи.
Представим небольшой интернет-магазин. Заказы приходят, сотрудники работают, доступы выдаются по мере необходимости. Если спросить «у нас всё безопасно?», ответ получится слишком общим. Я бы предложила разобрать конкретную ситуацию: что произойдёт, если завтра один из привычных сервисов станет недоступен? Кто заметит, какие операции остановятся, с кем придётся связываться?
Это не попытка устроить проверку с неожиданными вопросами. Смысл — увидеть зависимости, которые в обычный день почти незаметны, и договориться, кто отвечает за следующий шаг.
Коктейль, конечно, не объясняет всю архитектуру Zero Trust. Зато отлично помогает начать разговор, который иначе легко отложить до первого тревожного звонка.
Полный разговор — «ИТ-коктейль», выпуск 1: https://rutube.ru/video/a996b0169f47b8df40c78e284240b862/
Полный первый выпуск в Telegram: https://t.me/IT_koktel/47