В календаре нашлось место для всех, кроме человека, которому этот календарь принадлежит. Александр рассказывает, как поставил себе 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