Синтаксис против семантики: Почему разработчики слышат то, что им говорят, а менеджеры — то, что хотят
Или: Как профессиональная деформация превращает живое общение в выполнение технического задания
Представьте себе двух людей.
Первый — разработчик. Он пишет код. Для него === — это строгое равенство, а == — это уже «ну, вообще-то может быть, но лучше не надо». Если в функции ожидается число, а приходит строка — будет ошибка. Чётко, однозначно, предсказуемо.
Второй — менеджер или заказчик. Он общается с людьми. Для него «сделаем» может означать «попробуем», «надо бы» — это «забудь», а «в идеале хорошо бы» — вообще ничего не значит.
И вот эти двое встречаются.
Разработчик слышит слова и воспринимает их буквально, как строки кода. Менеджер произносит слова, вкладывая в них полутона, намёки и страховочные варианты.
Дальше начинается то, что психологи называют профессиональной деформацией, а разработчики — «почему они всё время врут».
Эта статья — попытка разобраться:
Начнём с главного.
Профессиональная деформация — это когда навыки и установки, полезные в работе, начинают проникать в другие сферы жизни и там создают проблемы.
У разработчиков это проявляется особенно ярко. Потому что их рабочий инструмент — язык с абсолютно строгой семантикой.
В коде:
Когда человек годами живёт в такой системе, его мозг привыкает: слова имеют точные значения. И если кто-то сказал «сделаем», значит, сделаем. Если «готово» — значит, готово. Если «в понедельник» — значит, в понедельник.
А теперь перенесём это в реальный мир, где люди говорят:
Разработчик слышит: набор слов, из которых нельзя составить исполняемый код. Он теряется. Он не понимает, что от него хотят. А менеджер искренне считает, что «всё чётко объяснил».
Давайте разберём конкретные фразы, которые в устах менеджера означают одно, а в голове разработчика — совсем другое.
Менеджер имеет в виду: «Давайте пока оставим эту задачу в бэклоге, потом посмотрим по приоритетам».
Разработчик слышит: «Будет сделано, но способ пока не определён». И начинает прикидывать, как это реализовать технически.
Результат: через неделю менеджер удивляется, почему разработчик уже что-то начал делать, а разработчик обижается, что его работу не ценят.
Менеджер имеет в виду: «Мы хотим, чтобы вы были лояльны, иногда работали бесплатно и входили в положение, когда у нас задержки с оплатой».
Разработчик слышит: «Мы будем делить риски и прибыль на равных». (См. предыдущую статью про этимологию слова «товарищ».)
Результат: когда выясняется, что «партнёрство» не подразумевает доли в бизнесе, разработчик чувствует себя обманутым.
Менеджер имеет в виду: «Мне нужно отчитаться перед начальством, поэтому отвлекись от всего и сделай это быстрее обычного».
Разработчик слышит: «Система горит, пользователи не могут зайти, деньги теряются».
Результат: разработчик бросает всё, работает ночью, сдаёт результат утром, а потом выясняется, что «срочно» было просто потому, что менеджер забыл сказать заранее.
Менеджер имеет в виду: «Это было бы круто, но, скорее всего, не в этом релизе».
Разработчик слышит: «Это требование, которое нужно реализовать». И начинает проектировать архитектуру под эту фичу.
Результат: переделки, срыв сроков, взаимные претензии.
Менеджер имеет в виду: «Я не хочу брать на себя ответственность за это решение, поэтому прикрываюсь клиентом».
Разработчик слышит: «У нас есть реальный запрос от пользователя, который нужно удовлетворить».
Результат: реализуется странная фича, которая никому не нужна, но «клиент просил».
Менеджер имеет в виду: «Я не хочу думать, предложи варианты, а я выберу».
Разработчик слышит: «Принимай решение самостоятельно, я доверяю твоему опыту».
Результат: разработчик предлагает технически оптимальное решение, менеджер его отвергает, потому что оно «не вписывается в бизнес-процессы», но виноватым остаётся разработчик.
Важно понимать: в 90% случаев менеджеры не пытаются специально манипулировать разработчиками. Они просто говорят на своём языке, который сформирован их профессиональной средой.
Что формирует язык менеджера:
Проблема в том, что разработчик живёт в другой системе координат. Для него «да» — это «да», «нет» — это «нет». Любая неопределённость — это баг, который нужно устранить.
Здесь мы подходим к самому тонкому моменту.
Есть менеджеры, которые действительно используют размытость формулировок для манипуляции. Они говорят «сделай быстро», а когда быстро не получается — «я имел в виду качественно, а не быстро». Они говорят «решай сам», а потом предъявляют за неправильное решение.
И есть менеджеры, которые просто не умеют иначе. Они искренне считают, что «подумай сам» — это проявление доверия, а «в идеале хорошо бы» — это просто пожелание, а не требование.
Как отличить одно от другого?
Некомпетентный менеджер — тоже может быть проблемой. Но с ним хотя бы можно договориться, если перевести общение в письменный вид и научиться задавать уточняющие вопросы.
Это банально, но работает. После любого устного обсуждения пишите резюме:
Если менеджер не поправил — значит, согласен. Потом будет сложно сказать «я не то имел в виду».
Не стесняйтесь переспрашивать:
Да, это бесит менеджеров. Но это лучше, чем потом переделывать.
Учитесь расшифровывать:
Фраза «сделать форму обратной связи» может означать что угодно. Договоритесь заранее:
Это скучно. Но это единственный способ избежать ситуации, когда вы сделали, а менеджер говорит «не то».
Разработчики часто стесняются признаться, что не поняли задачу. Им кажется, что это признак непрофессионализма.
На самом деле, признак профессионализма — задавать вопросы до того, как начал делать, а не после.
Давайте будем честны до конца. Разработчики тоже не ангелы. И у них есть свои приёмы:
Разница в том, что разработчики обычно манипулируют временим и ресурсами, а менеджеры — смыслами и ответственностью.
В одном старом анекдоте программиста спрашивают:
— Как ты понимаешь фразу «Я тебя люблю»?
— Это безусловный оператор перехода к выполнению блока действий с неопределённым временем окончания.
Менеджер скажет иначе:
— «Я тебя люблю» — это маркер лояльности, который мы используем для укрепления долгосрочных отношений в рамках корпоративной этики.
И оба будут правы. И оба не поймут друг друга.
Так что, коллеги, давайте договариваться на берегу. Записывайте, уточняйте, переспрашивайте. И помните: хороший менеджер — тот, кто говорит то, что думает. Хороший разработчик — тот, кто думает, прежде чем сказать.
А всё остальное — это просто синтаксические ошибки в общении.
P.S. Если вы узнали в этой статье своего менеджера — не спешите его ненавидеть. Покажите ему текст. Может быть, он просто не знает, как вы воспринимаете его слова. Иногда достаточно одного разговора, чтобы переключиться с режима «манипуляция» на режим «сотрудничество».
P.P.S. А если вы узнали себя — значит, вы уже на пути к исцелению. Добро пожаловать в реальный мир, где слова значат то, что значат. Почти всегда.
🧩 Пролог: Два мира — два подхода к реальности
Представьте себе двух людей.
Первый — разработчик. Он пишет код. Для него === — это строгое равенство, а == — это уже «ну, вообще-то может быть, но лучше не надо». Если в функции ожидается число, а приходит строка — будет ошибка. Чётко, однозначно, предсказуемо.
Второй — менеджер или заказчик. Он общается с людьми. Для него «сделаем» может означать «попробуем», «надо бы» — это «забудь», а «в идеале хорошо бы» — вообще ничего не значит.
И вот эти двое встречаются.
Разработчик слышит слова и воспринимает их буквально, как строки кода. Менеджер произносит слова, вкладывая в них полутона, намёки и страховочные варианты.
Дальше начинается то, что психологи называют профессиональной деформацией, а разработчики — «почему они всё время врут».
Эта статья — попытка разобраться:
- Какие слова и фразы гарантированно будут поняты разработчиком неправильно?
- Почему «размытые формулировки» — это не всегда манипуляция, но часто — способ снять с себя ответственность?
- И как разработчику сохранить адекватность, не превращаясь в параноика?
🎭 Акт 1: Профессиональная деформация — когда молоток видит везде гвозди
Начнём с главного.
Профессиональная деформация — это когда навыки и установки, полезные в работе, начинают проникать в другие сферы жизни и там создают проблемы.
У разработчиков это проявляется особенно ярко. Потому что их рабочий инструмент — язык с абсолютно строгой семантикой.
В коде:
- if (user.active) — это всегда правда или ложь. Третьего не дано.
- let result = calculate() — результат гарантированно будет тем, что вернула функция.
- console.log('Готово') — сообщение появится в консоли. Всегда. Без вариантов.
Когда человек годами живёт в такой системе, его мозг привыкает: слова имеют точные значения. И если кто-то сказал «сделаем», значит, сделаем. Если «готово» — значит, готово. Если «в понедельник» — значит, в понедельник.
А теперь перенесём это в реальный мир, где люди говорят:
«Надо бы подумать над этим вопросом в контексте наших стратегических задач, но с учётом текущей загрузки, наверное, имеет смысл синхронизироваться позже».
Разработчик слышит: набор слов, из которых нельзя составить исполняемый код. Он теряется. Он не понимает, что от него хотят. А менеджер искренне считает, что «всё чётко объяснил».
🚩 Акт 2: Слова-ловушки — что разработчик слышит на самом деле
Давайте разберём конкретные фразы, которые в устах менеджера означают одно, а в голове разработчика — совсем другое.
1. «Как-нибудь сделаем»
Менеджер имеет в виду: «Давайте пока оставим эту задачу в бэклоге, потом посмотрим по приоритетам».
Разработчик слышит: «Будет сделано, но способ пока не определён». И начинает прикидывать, как это реализовать технически.
Результат: через неделю менеджер удивляется, почему разработчик уже что-то начал делать, а разработчик обижается, что его работу не ценят.
2. «Партнёрство»
Менеджер имеет в виду: «Мы хотим, чтобы вы были лояльны, иногда работали бесплатно и входили в положение, когда у нас задержки с оплатой».
Разработчик слышит: «Мы будем делить риски и прибыль на равных». (См. предыдущую статью про этимологию слова «товарищ».)
Результат: когда выясняется, что «партнёрство» не подразумевает доли в бизнесе, разработчик чувствует себя обманутым.
3. «Срочно»
Менеджер имеет в виду: «Мне нужно отчитаться перед начальством, поэтому отвлекись от всего и сделай это быстрее обычного».
Разработчик слышит: «Система горит, пользователи не могут зайти, деньги теряются».
Результат: разработчик бросает всё, работает ночью, сдаёт результат утром, а потом выясняется, что «срочно» было просто потому, что менеджер забыл сказать заранее.
4. «В идеале хорошо бы»
Менеджер имеет в виду: «Это было бы круто, но, скорее всего, не в этом релизе».
Разработчик слышит: «Это требование, которое нужно реализовать». И начинает проектировать архитектуру под эту фичу.
Результат: переделки, срыв сроков, взаимные претензии.
5. «Клиент просит»
Менеджер имеет в виду: «Я не хочу брать на себя ответственность за это решение, поэтому прикрываюсь клиентом».
Разработчик слышит: «У нас есть реальный запрос от пользователя, который нужно удовлетворить».
Результат: реализуется странная фича, которая никому не нужна, но «клиент просил».
6. «Подумай сам»
Менеджер имеет в виду: «Я не хочу думать, предложи варианты, а я выберу».
Разработчик слышит: «Принимай решение самостоятельно, я доверяю твоему опыту».
Результат: разработчик предлагает технически оптимальное решение, менеджер его отвергает, потому что оно «не вписывается в бизнес-процессы», но виноватым остаётся разработчик.
🎭 Акт 3: Почему менеджеры так говорят (спойлер: не со зла)
Важно понимать: в 90% случаев менеджеры не пытаются специально манипулировать разработчиками. Они просто говорят на своём языке, который сформирован их профессиональной средой.
Что формирует язык менеджера:
- Необходимость сохранять лицо. Если менеджер скажет «я не знаю», он потеряет авторитет. Поэтому он говорит «надо проработать вопрос».
- Страх ответственности. Чёткие формулировки потом можно предъявить. Размытые — всегда можно переинтерпретировать.
- Привычка к компромиссам. В бизнесе всё относительно. Сегодня одно решение, завтра другое. Чёткие обещания давать опасно.
- Корпоративная культура. Во многих компаниях принято говорить красиво, длинно и ни о чём. Это считается «профессиональным».
Проблема в том, что разработчик живёт в другой системе координат. Для него «да» — это «да», «нет» — это «нет». Любая неопределённость — это баг, который нужно устранить.
🧠 Акт 4: Манипуляция или некомпетентность?
Здесь мы подходим к самому тонкому моменту.
Есть менеджеры, которые действительно используют размытость формулировок для манипуляции. Они говорят «сделай быстро», а когда быстро не получается — «я имел в виду качественно, а не быстро». Они говорят «решай сам», а потом предъявляют за неправильное решение.
И есть менеджеры, которые просто не умеют иначе. Они искренне считают, что «подумай сам» — это проявление доверия, а «в идеале хорошо бы» — это просто пожелание, а не требование.
Как отличить одно от другого?
- Манипулятор после провала всегда находит виноватого. И этот виноватый — не он.
- Манипулятор никогда не признаёт, что его слова можно было понять по-разному. Он всегда говорит: «Я же чётко сказал».
- Манипулятор избегает письменных договорённостей. Ему удобнее, чтобы всё было «на словах».
Некомпетентный менеджер — тоже может быть проблемой. Но с ним хотя бы можно договориться, если перевести общение в письменный вид и научиться задавать уточняющие вопросы.
🛡️ Акт 5: Как разработчику защитить себя (не становясь параноиком)
1. Фиксируйте всё в письменном виде
Это банально, но работает. После любого устного обсуждения пишите резюме:
«Как я понял, нам нужно сделать А, Б и В. Срок — пятница. Если я что-то упустил, поправьте».
Если менеджер не поправил — значит, согласен. Потом будет сложно сказать «я не то имел в виду».
2. Задавайте уточняющие вопросы
Не стесняйтесь переспрашивать:
- «Что именно вы имеете в виду под "срочно"? К какому часу нужно?»
- «"Подумать сам" — это значит принять решение без согласования или предложить варианты?»
- «"В идеале" — это обязательное требование или пожелание?»
Да, это бесит менеджеров. Но это лучше, чем потом переделывать.
3. Переводите «менеджерский» на «разработческий»
Учитесь расшифровывать:
- «Надо бы» = «Не нужно, пока не скажут чётко».
- «Партнёрство» = «Будем платить, когда смогут».
- «Стратегическая задача» = «Мы сами не знаем, что хотим».
4. Требуйте чётких критериев «готово»
Фраза «сделать форму обратной связи» может означать что угодно. Договоритесь заранее:
- Где она должна быть?
- Какие поля?
- Что происходит после отправки?
- Как выглядит ошибка?
Это скучно. Но это единственный способ избежать ситуации, когда вы сделали, а менеджер говорит «не то».
5. Не бойтесь говорить «я не понял»
Разработчики часто стесняются признаться, что не поняли задачу. Им кажется, что это признак непрофессионализма.
На самом деле, признак профессионализма — задавать вопросы до того, как начал делать, а не после.
🔄 Акт 6: Обратная сторона — как разработчики манипулируют менеджерами
Давайте будем честны до конца. Разработчики тоже не ангелы. И у них есть свои приёмы:
- «Это технически невозможно» — на самом деле возможно, но долго/сложно/неинтересно.
- «Надо переписать с нуля» — потому что лень разбираться в чужом коде.
- «Это займёт две недели» — хотя реально день, но хочется подстраховаться.
Разница в том, что разработчики обычно манипулируют временим и ресурсами, а менеджеры — смыслами и ответственностью.
🎯 Акт 7: Ключевые выводы
- Профессиональная деформация неизбежна. Разработчик всегда будет склонен воспринимать слова буквально, а менеджер — обтекаемо.
- Проблема не в злом умысле, а в разных языках. Менеджеры часто не осознают, как их слова звучат для разработчика.
- Письменная фиксация — единственная защита. Всё, что не записано, — не существует.
- Soft skills — это не про «умение договариваться». Это про умение переводить с одного языка на другой.
- Честность — лучшая политика. Если вы не поняли — скажите. Если менеджер не уверен — пусть признает. Только так можно построить работающие отношения.
🧘 Эпилог: Программисты и поэты
В одном старом анекдоте программиста спрашивают:
— Как ты понимаешь фразу «Я тебя люблю»?
— Это безусловный оператор перехода к выполнению блока действий с неопределённым временем окончания.
Менеджер скажет иначе:
— «Я тебя люблю» — это маркер лояльности, который мы используем для укрепления долгосрочных отношений в рамках корпоративной этики.
И оба будут правы. И оба не поймут друг друга.
Так что, коллеги, давайте договариваться на берегу. Записывайте, уточняйте, переспрашивайте. И помните: хороший менеджер — тот, кто говорит то, что думает. Хороший разработчик — тот, кто думает, прежде чем сказать.
А всё остальное — это просто синтаксические ошибки в общении.
P.S. Если вы узнали в этой статье своего менеджера — не спешите его ненавидеть. Покажите ему текст. Может быть, он просто не знает, как вы воспринимаете его слова. Иногда достаточно одного разговора, чтобы переключиться с режима «манипуляция» на режим «сотрудничество».
P.P.S. А если вы узнали себя — значит, вы уже на пути к исцелению. Добро пожаловать в реальный мир, где слова значат то, что значат. Почти всегда.