В прошлом посте я спрашивал: может ли технарь остановить продажу или его зовут в переговорки только «для галочки» Считаю, что может. Но не потому, что он самый умный в комнате. И не потому, что у него на руках страшные технические термины. А потому, что он научился говорить так, чтобы его «нет» звучало весомо. Одна из главных причин, почему бизнес дожимает технарей, потому что говорят они на разных языках. Когда ИТ или ИБ приходят к коммерческому директору или СЕО, они начинают сыпать терминами: «У нас DPI не тянет», «Надо менять NGFW», «BGP отвалится», «Проц перегружен». В этот момент в голове владельца сидит обезьянка и бьёт в оркестровые тарелки, а сверху звучит одна простая мысль: «Они опять хотят потратить мои деньги на какие-то мигающие коробочки, чтобы им было интереснее играться». Бизнес не покупает железо. Бизнес покупает снижение рисков. И вот здесь начинается разница между технарём, который «мешает продавать», и технарём, которого реально слушают. Сказать «нет» мало. «Нет» без аргумента для бизнеса звучит как каприз. «Нет» с развилкой по срокам, объёму и рискам уже звучит как управленческое решение. Хорошее техническое «нет» выглядит не так: «Хер мы это сделаем в такие сроки». Оно выглядит так: «В эти сроки мы можем качественно сделать А, Б и В. Если хотим оставить ещё Г и Д, нужен другой срок. Если срок не двигается, значит придётся убирать часть требований или отдельно принимать связанный с этим риск». То есть задача технаря не просто тормознуть проект. Задача — разложить требования по критичности, показать цену компромисса и принести бизнесу взрослый выбор. И только после этого у технаря появляется шанс на настоящее право сказать «нет». Не в смысле хлопнуть дверью и всех послать. А в смысле принести понятную бизнесу аргументацию: вот риск, вот цена ошибки, вот последствия для сроков, денег и репутации. Топам абсолютно плевать, что у вас там «мигает лампочками». Если вы хотите, чтобы вам дали бюджет на новую архитектуру или позволили сдвинуть сроки проекта ради качества, забудьте слова «VLAN» и «балансировка». Лучше использовать то, что работает сильнее аббревиатур. Time-to-market. «Если мы сделаем эту архитектуру, новые сервисы будут запускаться на 2 недели быстрее. Дополнительную выручку можно посчитать». Стоимость простоя. «Час простоя обойдётся компании в N миллионов. Новый проект стоит в 10 раз дешевле одного такого часа». Управляемость рисками. «Сейчас атаки всё чаще идут не на кражу, а на уничтожение. Хакеры сжигают бэкапы напалмом. Без воздушного зазора мы просто не восстановимся». Это подтверждает и мой недавний разговор с РБК. Там я объяснял: речь не о паранойе, а о том, останется ли бизнес жить после «чёрного дня». Мы разбирали, почему NGFW не спасёт от «напалма» и почему три ЦОДа бесполезны, если они зависят друг от друга. СЕО должен слышать не про «лампочки», а ответ на вопрос: «Выживем ли мы?» Именно в этот момент технарь перестаёт быть человеком, который «мешает продавать», и становится человеком, который помогает компании не умереть от собственных решений. 🔗 Ссылка на статью РБК: https://nsk.plus.rbc.ru/preview/698d54ae7a8aa919e2cd3b85 А вы на каком языке разговариваете с бизнесом? Приходится рисовать сценарии потерь, чтобы получить «да» на нормальную архитектуру, или уже доверяют вам без калькулятора?