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

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

1. Документ – иначе бы этого не произошло

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

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

Урок здесь прост: Заключение соглашений – это не бюрократия, а форма уважения. Когда есть документ, обсуждают не люди, а факты. И нервы остаются целыми.

2. Если что-то можно автоматизировать, так и должно быть.

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

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

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

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

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

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

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

4. Пересмотр – это не критика, а способ роста

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

Разработчики не занимаются «убеждать», они занимаются «улучшением». И эта установка меняет всё.

Если бы менеджеры смотрели на свои процессы с тем же спокойствием, с которым разработчики меняют код, многие команды жили бы счастливее 🙂

5. Срок службы CI/CD

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

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

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

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

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

Техническое мышление – это не сухость или проекты. Речь идет о уважение к логике, времени и повторениюИ если бы менеджеры начали немного больше думать о развитии, мы, возможно, перестали бы воспринимать хаос как часть профессии.