Я не разработчик. Но после переезда в Европу в моём окружении появилось много специалистов из IT — от разработчиков и тимлидов до консультантов. Я сама остаюсь в маркетинге и, скорее, гуманитарий, но разговоры с ними неизбежно заставляют задуматься: почему у айтишников так часто горят проекты, ломаются коммуникации и выгорают даже самые умные люди? Чему не-IT можем научиться?

Я собрала наблюдения и выводы из десятков разговоров, встреч и совместных проектов — и буду рада, если вы в комментариях напишете, так ли это со стороны тех, кто в индустрии изнутри.

1. Документируй — иначе этого не было

Разработчики не верят в «мы же это обсуждали». Если код не закоммичен — его нет. Если поведение системы не описано — его никто не поймёт.

Менеджеры часто живут в другой реальности: задачи в чатах, решения в голове, итоги на совещаниях без протоколов. В итоге через месяц никто не помнит, кто что обещал, а виноват — всегда тот, кто первым устал спорить.

Урок отсюда простой: фиксировать договорённости — не бюрократия, а форма уважения. Когда есть документ, спорят не люди, а факты. И нервы остаются целее.

2. Если что-то можно автоматизировать — это нужно автоматизировать

У хорошего разработчика зуд начинается, когда он делает одну и ту же задачу трижды. Менеджеры же могут годами собирать отчёты вручную и даже гордиться своей усидчивостью.

Автоматизация — это не про лень, а про внимание к ценности времени. У разработчиков есть внутреннее табу на бессмысленные повторения, и этот принцип стоило бы встроить в управленческую культуру.

Если вы повторяете одну и ту же операцию больше двух недель — задумайтесь, почему она до сих пор не автоматизирована. Даже если это шаблон письма, который можно сохранить, или скрипт на пару строк.

3. Рефакторинг — это не прихоть, а необходимость

В коде, как и в управлении, хаос растёт незаметно. Сначала добавляешь пару «временных решений», потом ещё одно «потом переделаем», и внезапно система перестаёт быть управляемой.

Разработчики знают: без регулярного рефакторинга проект умирает от собственной сложности. Менеджерам стоит перенять этот подход.

Рефакторинг в управлении — это чистка процессов, пересмотр ролей, избавление от ритуалов, которые уже не работают. И да, это требует времени. Но если не делать этого, организация превращается в аналог legacy-кода: работает, пока кто-то не нажмёт лишнюю кнопку.

4. Review — не критика, а способ расти

Код-ревью — один из самых ценных ритуалов в инженерной культуре. Это не про «поймать ошибку», а про совместное улучшение результата. В маркетинге и менеджменте же обратная связь часто воспринимается как личная атака.

У разработчиков нет задачи «переубедить» — есть задача «улучшить». И эта установка меняет всё.

Если бы управленцы делали review своих процессов с таким же спокойствием, с каким разработчики правят код, многие команды жили бы счастливее :)

5. CI/CD жизни

Continuous Integration и Continuous Delivery — подход, при котором продукт обновляется постоянно, маленькими порциями, а не редкими грандиозными релизами.

В менеджменте часто наоборот: накопим идеи, проведём стратегическую сессию, устроим «перезапуск компании» — а потом снова утонем в операционке.

Делать маленькие улучшения регулярно гораздо эффективнее, чем ждать «идеального момента». Этот принцип отлично работает и в жизни, и в процессах: не реорганизация раз в год, а по 1% улучшений каждую неделю.

Вместо вывода

Менеджеры и разработчики часто говорят на разных языках, но цель у нас общая — сделать систему работающей. Только одни чинят код, а другие — коммуникации.

Инженерное мышление не про сухость или схемы. Оно про уважение к логике, времени и повторяемости. И если менеджеры начнут мыслить чуть более «по-разработчески», мы, возможно, перестанем воспринимать хаос как часть профессии.